Vulnerability Management Policy

Policy Owner: Security Engineering Manager

Approved by: CTO, VP of Engineering

Introduction

This policy defines Sourcegraph’s process for incoming security vulnerabilities. It defines roles, responsibilities, steps and SLAs.

The document is managed through git and history can be found in the git repository. Substantial changes to this document should be approved by the CTO and VP of Engineering. Minor changes such as formatting and presentation do not require approval.

Scope

This document concerns how we handle incoming vulnerabilities and engage with Engineering teams to ensure they are fixed. It does not cover tooling and processes to find vulnerabilities. More information on how we execute this process can be found on the Vulnerability Management Process document. The policy document is the source of truth in case there are any discrepancies between the two documents. If you find conflicting information please raise it to the attention of the Security team.

Vulnerability management stages

  1. Discovery: a vulnerability from any source becomes an item to be triaged by the Security team.
  2. Triaging: Security triages the vulnerability. If confirmed, they write a technical report and engage the code owner.
  3. Engineering estimation: the code owner suggests a patch and provides an estimate of the effort to complete it within the SLA defined by the severity level assigned during the triage process.
  4. Remediation: the code owner patches the issue. Security verifies the patch.
  5. Disclosure: Security discloses the vulnerability according to our vulnerability disclosure process.

Responsibilities

The Security team is responsible for:

  • Responding to vulnerability reports from multiple sources and consolidating them in a single view for management
  • Triaging the vulnerability reports and confirming their impact and exploitability in our systems
  • Assigning a severity to confirmed vulnerabilities
  • Engaging with code owners to patch vulnerabilities
  • Verifying that vulnerabilities are properly fixed
  • Disclosing vulnerabilities
  • Adhering to the SLAs

Code or system owners are responsible for:

  • Fixing vulnerabilities in code or system owned by them
  • Suggesting patches for vulnerabilities and estimating effort to do it
  • Patching vulnerabilities
  • Adhering to the SLAs

The Security team will cooperate with and support all teams throughout the entire process.

Severity levels

The severity assessment will be done with the full context of the impact to our customers and not just the severity level in isolation, as an example a vulnerability detected in a Go library and marked as critical by a scanner does not automatically mean the severity is critical for our customers. The main factors to assess are: Exploitability, Asset Value, Likelihood and Business impact.

We classify our vulnerabilities in 4 severity levels:

  • Critical: vulnerabilities that result in a complete compromise of the infrastructure or application, unavailability of the application, or imminent compromise of highly sensitive information. Critical vulnerabilities can be exploited without elevated access or user interaction. Critical vulnerabilities can be exploited with relative ease, or low technical ability, or have the potential to be fully automated once a viable exploit has been created. Vulnerabilities that become a threat to the continuity or reputation of the business like data breach.
  • High: vulnerabilities that can have a significant impact on the operational integrity of the application, data security, authorization boundaries but require either a complex attack chain or user interaction for exploitation. High severity vulnerabilities usually have mitigating controls in place, such as requiring an admin account on the system or application to perform successful exploitation.
  • Medium: vulnerabilities that can impact the operational integrity of the application, limited unavailability or serve as a step in a complex attack chain. Medium severity vulnerabilities do not lead to high impact incidents single-handedly but can serve as an important step in complex attacks.
  • Low: vulnerabilities that leak information not considered highly sensitive, or issues that cannot be chained into attacks with high impact.
  • Informational: vulnerabilities that do not present any risk to the company. These vulnerabilities are tracked but do not require patches nor have SLAs.

1. Discovery

As our security program grows we will continue to add tooling and processes that find vulnerabilities across our systems and code. Some sources of vulnerability information that we already have or are in our immediate plans are:

  • Penetration Testing
  • Bug Bounty Program
  • Vulnerability Scanning
  • CI/CD pipeline security checks
  • Internal responsible disclosure
  • Public notifications
  • Customer notifications

Any vulnerability found from these sources becomes a ticket in our vulnerability management system.

2. Triaging

The Security team is responsible for triaging vulnerabilities. This means confirming that it’s an exploitable issue and determining its impact in our systems. The assigned Security Engineer creates a technical writeup and engages the code owner of the vulnerability.

3. Engineering estimation

Once the technical write up is ready a code owner should read the report and provide the following information:

  • High-level suggestion of a patch
  • Estimation of the effort to complete the work
  • Commitment to when the team will begin working on it

4. Remediation

Once the Engineering team begins working on the patch the Security team is readily available to provide any consultation necessary. When the patch is ready, the Security team will be engaged as reviewers to verify the patch. Once the issue is confirmed to have been fixed the code can be merged.

5. Disclosure

Once vulnerabilities are patched it is the Security team’s responsibility to properly disclose them to our users and customers.

The customer support team and the customer engineering team will be notified before our public disclosure should they need to contact customers. This should be done within 48 hours of having the patch available.

We will strive to publicly disclose the issue as soon as possible, as long as the following conditions are met:

  • Our customers have been informed;
  • CEs have worked with customers to patch or plan how instances will be patched;
  • We have patched Sourcegraph Cloud and managed instances;
  • Any critical incident response is finished.

Sourcegraph publicly discloses all vulnerabilities in code written by us, excluding vulnerabilities in 3rd party software.

A CVE ID is requested for every vulnerability. Vulnerabilities are disclosed through:

Vulnerability service level agreements

We need SLAs across this process, similarly to customer issues. Here are our SLAs for each step of this process (days are business days)

  1. Triaging: 3 days
  2. Engineering estimation:
    • Critical: 1 day
    • High: 3 days
    • Medium: 10 days
    • Low: 10 days
  3. Remediation:
    • Critical: 3 days
    • High: 10 days
    • Medium: 40 days
    • Low: 100 days

Acceptance of vulnerabilities

There are vulnerabilities that we confirm but may decide not to fix. For example small vulnerabilities that enable features, or items where the cost to fix is too great.

Once accepted, a vulnerability will be considered closed but properly documented with the reasoning why the risk was accepted. Vulnerability acceptance needs approval from higher levels of management depending on their severity:

  • Critical: Head of Product & Engineering
  • High: Head of Product & Engineering
  • Medium: Engineering Manager
  • Low: Engineering Manager

Accepted vulnerabilities are reassessed every 6 months by Security.

Exceptions

We understand that situations may arise where one or more of the parties involved cannot comply with their responsibilities and/or SLAs. If both teams cannot find an agreement on how to resolve a vulnerability, it can be escalated to the responsible exception approvers for further discussion. Raising an exception effectively means that the owner of the product is ready to accept the exceptional level of risk (above the risk appetite) posed by the vulnerability introduced by their team.

Exceptions needs approval from higher levels of management depending on their severity:

  • Critical: Head of Product & Engineering
  • High: Security Lead
  • Medium: Security Engineer
  • Low: Security Engineer