Risk assessments help GitLab identify, prioritize, and manage security risks. They're important to help protect customer data and meet GitLab security compliance controls, which are important for compliance standards such as SOC2 and PCI-DSS. A risk assessment should ideally be completed for every service in the Tech Stack Applications table and reviewed either quarterly or as substantial changes are made, whichever is most feasible. Additionally, risk assessments are used as part of Data Protection Impact Assessments (DPIAs).
At GitLab, our risk assessment framework is based on a combination of NIST SP 800-30 Rev. 1 and the Mozilla Rapid Risk Assessment (RRA), but customized to be collaborative, asynchronous, and done within GitLab itself. All risk assessment work is done within the Risk Assessment repository.
[Service Name]-risk-assessmentin the
Risk assessments should consider both internal and external risks. This is important because the Verizon 2019 Data Breach Investigation Report (DBIR) found 39% of breaches involved internal actors (whether intentional or accidental). By considering both internal and external risks, we can more accurately define and work to mitigate GitLab's risk surface.
Risk assessments should specifically consider risks related to fraud and abuse. This is important because fraud and abuse results in millions of lost dollars from victims every year. Fraud and abuse can also directly impact GitLab's product and service offerings. For those reasons, every risk assessment should explicitly address fraud and abuse related risks.
There may be instances where a risk cannot or won't be remediated. In such cases, follow the Risk Exception process.
assessments/directory. To contribute to a risk assessment, please create an MR to propose the change or start a discussion.
Risk assessments should be continually reviewed and revised to keep the information in risk assessments current and relevant. At a minimum, every risk assessment should be reviewed once per year or as significant changes are made to the system, whichever comes first.
To conduct a risk assessment review:
Upcoming risk assessment reviews are tracked in the Risk Assessment Review document. A risk assessment should be added after the initial MR has been merged.
Sometimes it may be appropriate to close a risk assessment. Some reasons a risk assessment may be closed are the vendor is no longer used or the type of data stored or processed changes. To close a risk assessment, open an MR and:
(CLOSED)to the end of
# GitLab Risk Assessment, to get
# GitLab Risk Assessment (CLOSED)
# GitLab Risk Assessment (CLOSED)section, write that the risk assessment is being closed, why it's being closed, and provide any supporting links.
This MR can be used as an example of this process.
Risk management is a way to identify and document most of the risks associated with how we perform our work as GitLab team-members. Every decision we make as a company involves risk and the purpose of documenting that risk is not to influence decision making or slow down processes unnecessarily, but rather to give GitLab decision makers as much information about that decision as possible so the best possible decision can be made.
Risk exceptions are a way to document when the business benefits outweigh the risks associated with a particular decision. In order to gather the evidence we need to show auditors we are making these decision with security risks in mind, we are processing exceptions through risk exception issues.
The goal with these exceptions is to make a "steel man" case for why a particular decision might increase the overall risk to the organization. This is not meant to deter the appropriate exception approver from accepting that risk, but rather to make that decision as informed as possible. There will always be times when a process meant to reduce risk in 80% of cases simply won't apply to a particular decision and this exception process will help guide all parties involved through that decision making process.