This is a Controlled Document
Inline with GitLab's regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.
Please read this procedure in its entirety and reach out to
# sec-assurance channel if you have any questions.
In accordance with expectations set by the FedRAMP PMO, GitLab must follow a formal process to track and request approval from our sponsoring Agency Authorizing Official (AO) for any vulnerabilities that cannot or should not be remediated within SLAs due to scenarios described in the Scope section below. These are called vulnerability Deviation Requests (DRs) and are formally reported to our AO every month using GitLab's Plan of Action & Milestones (POA&M) (internal only). Deviation requests for risk adjustments (severity downgrades), false positives, and operational requirements require Authorizing Official (AO) approval.
Vulnerabilities (CVEs) impactful to the FedRAMP production environment (authorization boundary) to include:
See DR Template Definitions below.
Assets: Only the assets and scan types listed here are in-scope. Do not submit a DR for a scan type (e.g. SAST) or asset not included within the production authorization boundary.
|GitLab Team Members||Submit the completed DR using the appropriate GitLab issue template, provide evidence|
|Security (Vulnerability Management)||Complete technical review and approval of DR|
|ISSO (Dedicated Compliance)||Complete compliance review of DR and upgrade to POA&M if approved|
|Authorizing official (AO)||Approve or deny DR (ultimate decision maker)|
Anyone at GitLab can submit a deviation request (DR) via a GitLab issue in this private project. DRs must be submitted in a timely manner and should never be used as a method to avoid late SLAs. All DRs are reviewed and approved by security, compliance, and our AO and they must meet the definitions and critieria defined within the issue templates.
To open a DR the applicable issue template must be selected and all information must be completed prior to submitting the issue for internal review. Each DR will undergo three rounds of review:
If denied, a remediation plan must be developed and this item will remain on the POA&M.
If approved, the ISSO will notify all involved parties via the GitLab issue with any additional instructions (like updating scanners).
The following definitions were adopted from the FedRAMP PMO:
Remediation SLO::Breaching SLOis applied.
FedRAMP Vendor Dependencylabel also applied per the instructions.
|Step||Description||Label applied to the Vulnerability Issue||Label applied to the Deviation Request Issue|
|1||Discover a deviation request is required for a FedRAMP-applicable vulnerability issue||
|2||Submit a Deviation Request using the appropriate issue template for review by security engineer||label remains unchanged||
|3||Security (Vulnerability Management team) performs a technical review of the vulnerability and classification/justification provided in the Deviation Request||If approved, label remains unchanged or if denied,
|4||Security Compliance reviews and if approved, tracks vulnerability deviation on POA&M and discusses with Authorizing Official during next monthly meeting||If approved label remains unchanged or if denied
|5||Security Compliance seeks Authorizing Official approval during next monthly meeting||If approved
Multiple CVEs can be grouped in a single DR if they are Vendor Dependencies for the same container image or package version (e.g. Red Hat ubi8 version 8.6-latest). For other DR types, vulnerabilities can be grouped if all of the following criteria are met:
Deviation requests are often not permanent as patches are eventually made available by vendors or deployed according to risk adjusted SLAs. Patches can also be released in the middle of the DR approval process. If a patch has been released and deployed, please provide evidence in the deviation request issue indicating that the vulnerability is now in production. Once provided, the issue can be closed. Acceptable evidence can include:
Once the issue is closed, apply the label
FedRAMP DR Status::Vuln Remediated.
There are no exceptions allowed to this procedure.