Vulnerability Management SOP

Vulnerability Management

This doc explains our process for identifying, classifying, tracking, and remediating security vulnerabilities across our infrastructure, applications, and dependencies.

Vulnerability Sources & Scanning

We use a variety of tools to detect vulnerabilities:

GCP Security Command Center ───> Infrastructure Misconfigurations
          GitHub Dependabot ───> Vulnerable Dependencies
         AWS ECR Image Scan ───> Container Vulnerabilities
           Manual Code Review ───> Application Logic Flaws
     External VAPT (Annual) ───> System-wide Security Issues

• GCP Security Command Center (SCC): Scans for misconfigurations and vulnerabilities in our GCP resources (GKE, Compute Engine, etc.).
• GitHub Dependabot: Enabled on all repositories to automatically scan for vulnerable dependencies in package.json, requirements.txt, etc., and create PRs with updates.
• Container Image Scanning: AWS ECR scans our Docker images for known vulnerabilities after they are pushed to the registry.
• Manual Reviews: We conduct security-focused code reviews, periodic architecture reviews, and an annual Vulnerability Assessment and Penetration Test (VAPT) with an external vendor.

Classification and Remediation SLAs

Vulnerabilities are classified using the Common Vulnerability Scoring System (CVSS):

Note: Zero-day vulnerabilities with active exploitation are always treated as Critical.

Remediation Workflow

Our workflow follows these steps:

Detection → Triage → Assignment → Fix → Verification → Closure

1. Detection: An automated tool or manual review finds a vulnerability.
2. Triage: The Security Team validates the finding, assigns a CVSS-based severity, and creates a GitHub Issue with the security-vulnerability label.
3. Assignment: The issue is assigned to the appropriate team or developer with a due date based on the SLA.
4. Fix: The developer or SRE implements the remediation (e.g., patching, upgrading a dependency, changing a configuration) and creates a PR.
5. Verification: The Security or SRE team verifies that the fix is deployed and the vulnerability is no longer present.
6. Closure: The GitHub Issue is closed with details about the resolution.

If an SLA is breached, the issue is escalated to the CTO.

Tracking & Reporting

• Tracking: We use GitHub Issues with the security-vulnerability label as our primary tracking tool.
• Reporting: The security team provides a monthly vulnerability summary to the CTO and a quarterly metrics review to leadership.
• Key Metrics: We track the number of open vulnerabilities by severity, SLA compliance rate, and Mean Time to Remediation (MTTR).

Package & Dependency Management

We maintain a controlled package registry. Developers can only use packages that have been approved.

1. New Package Installation

• Developer requests approval for a new package.
• The package is scanned for known vulnerabilities and license compliance.
• If it passes, it is added to the approved registry and available for use.
• If it fails, the request is blocked and the developer is notified.

2. Existing Package Upgrade

• When a team needs to upgrade an existing package to a newer version, the new version goes through the same scan process.
• The upgraded version must pass vulnerability and license checks before it replaces the old version in the approved registry.

3. Vulnerability in Existing Package

• All approved packages are monitored daily for newly disclosed vulnerabilities.
• If a vulnerability is found in a package already in use:
  • The affected teams are notified.
  • The team upgrades to a safe version based on the remediation SLAs (Critical/High = immediate, Medium/Low = within SLA window).
  • If no safe version exists, the package is replaced with an alternative or removed.
  • The vulnerable version is removed from the approved registry.

4. Package Removal / Deprecation

• If a package is no longer maintained, deprecated by its author, or no longer needed, it is removed from the approved registry.
• Teams using the package are notified and given a timeline to migrate to an alternative.

Source Restriction

• Packages can only be installed from authorised sources — official package registries (e.g., PyPI for Python, npm registry for Node.js) through our approved package store.
• Direct installs from unofficial sources, personal repositories, or unknown URLs are not allowed.

Daily Re-scanning

• All approved packages are re-scanned daily against the latest vulnerability databases.
• If a new vulnerability is disclosed for a package already in use, the affected teams are notified and remediation follows the standard SLAs.

Audit Logging

• Every package request, approval, rejection, and scan result is logged.
• Logs include who requested the package, when it was approved, and what scan results were found.
• These logs are available for security reviews and compliance audits.

Exception & Risk Acceptance Process

If a vulnerability cannot be remediated immediately (e.g., no patch is available), the team can request a risk acceptance.

1. The assignee documents the reason and any compensating controls.
2. The CTO must approve the risk acceptance.
3. The accepted risk is documented in a risk register and reviewed at least every 90 days.

Related Documents

• Log Management Standard (STD-012)
• Email Security Standard (STD-007)
• Endpoint Security Standard (STD-009)