How do we handle open source security vulnerabilities?

Short answer

All dependencies are scanned automatically via our CI/CD pipeline using SCA tools. Critical CVEs must be patched within a defined timeframe based on severity. Our OSS Vulnerability Response Playbook governs the triage, escalation, and remediation process.

Detailed explanation

Why this is critical

Studies show that 84% of codebases contain at least one known open source vulnerability — and the majority reside in transitive dependencies, invisible without dedicated tooling. An unpatched component can become an active attack vector within hours of an exploit being published.

Detection architecture

Our approach relies on several complementary layers:

1. CI/CD scanning (shift-left) Every pull request automatically triggers an SCA analysis. A component with a CVE above the defined threshold blocks the merge until resolution.

# Example CI pipeline integration
steps:
  - name: SCA Scan
    run: sca-tool scan --fail-on CRITICAL,HIGH
    # Blocks the build if a critical or high CVE is detected

2. Continuous monitoring in production Components in production are continuously re-evaluated against vulnerability databases (NVD, GitHub Security Advisories, OSV). Any newly published CVE triggers an alert.

3. SBOM (Software Bill of Materials) Every build artifact generates a versioned SBOM, enabling immediate identification of which products are affected when a vulnerability is disclosed.

Remediation SLAs

Patch deadlines are defined by CVSS severity level:

SeverityCVSS ScoreRemediation deadline
Critical9.0 – 10.0[XX] hours
High7.0 – 8.9[X] business days
Medium4.0 – 6.9[XX] business days
Low0.1 – 3.9Next sprint / release

⚠️ The CVSS score alone is not sufficient. The real exploitability in your context (is the vulnerable function actually called?) and the business impact must also be considered during triage.

OSS Vulnerability Response Playbook

When a critical CVE is identified, the Playbook defines the following steps:

  1. Detection — automated alert from the Security Advisory Feed or SCA tool.
  2. Triage — assess real exploitability (is the vulnerable code reachable?) and potential business impact.
  3. Escalation — notify the security team and product owner. For CVEs with CVSS ≥ 9.0, immediate escalation to the CISO.
  4. Remediation — update the component, apply a standalone patch if available, or implement a documented temporary workaround.
  5. Validation — re-scan to confirm the vulnerability has been eliminated.
  6. Communication — update the SBOM and notify affected stakeholders.

How to subscribe to alerts

To receive alerts from our Security Advisory Feed:

  • Subscribe to the #security-advisories channel on [internal communication tool].
  • Enable Dependabot / GitHub Security Alerts on your repositories.
  • Check your project’s SCA dashboard daily during active sprints.

Common pitfalls

  • Relying solely on the CVSS score — a 9.8 CVE in a library whose vulnerable function is never called in your code has a low real-world impact. Always assess contextual exploitability.
  • Ignoring transitive dependencies — the majority of vulnerabilities hide in dependencies of dependencies.
  • Keeping End-of-Life (EOL) components — a component with no active support will no longer receive security patches, even for critical CVEs.
  • Treating OSS security as a one-time event — new CVEs are published daily against existing components. This is a continuous process.

See also