Skip to content

Update Vulnerability management process for FedRAMP SLAs

Joshua Lambert requested to merge jl-vuln-sla into master

⚠ See !114057 (merged) instead

What is being changed?

This MR makes two key changes:

  1. Sets the remediation SLA for High CVSS findings from our scanners to be a S1/P1 to comply with FedRAMP requirements. Previously they would be categorized as S2/P2.
  2. Sets the remediation SLA for S4 to 180 days only for vulnerabilities

The rationale for these changes is:

  1. Comply with FedRAMP CVSS handling requirements
  2. Relies on a Triage Bot to nudge/remind folks in particular for S4 which has a custom SLA

Why is this change being made?

It is one of GitLab's top level initiatives to achieve FedRAMP Moderate Certification. See the internal handbook page for more info on what FedRAMP is, why we're pursuing FedRAMP authorization, and key milestones on our FedRAMP journey.

FedRAMP requires specific remediation timelines for vulnerabilities:

[Cloud Services Providers] must:

  • mitigate all discovered high-risk vulnerabilities within 30 days,
  • mitigate moderate vulnerability risks in 90 days, and
  • mitigate low vulnerability risks in 180 days.

CSPs must send their Reviewer updated artifacts every 30 days to show evidence that outstanding high-risk vulnerabilities have been mitigated.

When will this change take place?

We know it will take time to complete the existing backlog of items. We are currently targeting October 1 (2022-11-01) for all issues to be within SLA. That is, between now and November 1, we should resolve:

  • All Critical and High issues currently out of SLA.
  • All Critical and High issues that will be out of SLA by November 1.
  • As many other issues that we can resolve before November 1.

What's the scope of issues it applies to?

This applies to all known security issues in the GitLab product or in GitLab Dedicated. Specifically for the FedRAMP RAR, only publicly known vulns with CVEs must be prioritized first and are the ones we should focus on resolving before November 1st. These findings mainly come from dependency scanner, container scanner, and other scanners which report on publicly known vulnerabilities in software components and dependencies. Within the same severity, all other vulnerabilities should be prioritized after publicly known CVEs.

Which GitLab teams does this impact?

All teams that maintain software components will need to be aware of the SLAs if security issues arise in their areas.

Today, a smaller set of groups is affected by out-of-SLA vulnerabilities. These teams will be impacted first.

What's expected of each impacted group? What action is needed?

Each group is responsible for the security issues identified within the components they maintain. Each group should evaluate security vulnerabilities that are, or will be, out of SLA, and plan to address the issues before the SLA expires.

What are the lists of security issues we should focus on ahead of the RAR?

See label ~"FedRAMP Milestone::Vuln Remediation" for items identified by Application Security.

What happens if a vulnerability SLA is exceeded?

Vulnerability Management is a key control that affects our ability to offer products and services to the U.S. federal government.

Exceeding vulnerability SLAs increases the risk that we lose authorization to serve federal customers (or can't obtain authorization in the first place).

If I have questions about proposed fixes, assigned severity levels, or validity, with whom do I engage with and how?

Speak with your AppSec stable counterpart. If you don't know who your counterpart is, check the groups page. If you can't find out who to speak with, contact @jritchey.

Severity levels are assigned using a structured approach based on the industry-standard CVSS rating.

Author Checklist

  • Provided a concise title for this Merge Request (MR)
  • Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
    • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added.
  • Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
    • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
    • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • If the changes affect team members, or warrant an announcement in another way, please consider posting an update in #whats-happening-at-gitlab linking to this MR
    • If this is a change that directly impacts the majority of global team members, it should be a candidate for #company-fyi. Please work with internal communications and check the handbook for examples.
Edited by Connor Gilbert

Merge request reports