This page details the application security review process for appsec engineers. The purpose of application security reviews are to proactively discover and mitigate vulnerabilities in GitLab developed or deployed applications in order to reduce risk and ultimately help make the company's mission successful.
An application security review may include any or all of the following stages:
The results of each stage will inform the review done in the next stage. Ideally, all new features would receive some threat modeling, with the latter two stages being performed based on the risk profile. Features already in development or production can receive an appsec review as well. The testing done is dependent on the circumstances.
A security review conducted by the application security team is non-blocking. This means that the team owning the feature should continue with their development plan, and the expected time investment should be limited to the time necessary to answer questions asynchronously.
Security issues found, if any, will be triaged following the standard process. Application security reviews allow us to discover vulnerabilities that exist in GitLab before they're discovered by a third party and, if the review is done for new features, we might catch the vulnerabilities even before they make it into a release. It reduces risk, gives us a better understanding of the threat model of the given feature, and allows us to proactively mitigate vulnerabilities.
The team owning the feature should proactively involve the Stable Counterpart in Epics, Issues, and/or MRs which might require a review or their attention. This is primarily the responsibility of the team's Engineering Manager(s) and the Engineer(s) working on the Issue / MR. Ideal trigger points (in order of preference) are when the Epic/Issue/MR is created/updated, when an engineering proposal is updated, or when an engineer is working on the MR.
Teams should have a bias towards involving the Stable Counterpart, to prevent potential security-sensitive changes from being overlooked.
One of the goals of the stable counterpart is to help identify features that need security review in the area to which they are assigned. Each week Stable Counterparts should review Issue boards and recorded weekly team meetings as part of this.
An Application Security team member is on rotation each week to triage Application Security Reviews.
The application security review queue is a priority queue of application
features for security review. The priority can range from priority::1 (Critical)
to priority::4 (Low/Backlog).
Some guidelines for which features should be added to the queue are:
The idea is to capture features determined to be higher risk for
vulnerabilities. It is quite probable that all features, especially priority::4
issues, will not get a full review, but by capturing those that are at higher
risk, we can track additional statistics. For example, how many related
vulnerabilities were reported in the bug bounty program. This data can help us
to help iterate on priority.
Single Issue/MR pings that can be completed by the engineer on triage rotation do not need a separate issue. This process is primarily for tracking features over time. With that in mind, if a ping will need additional review, an issue should be created.
Separate issues will be used to track the appsec review process, as this process could outlive the original issue/merge request.
The process is the same for appsec engineers adding something to the backlog or for team members requesting a review for a GitLab feature:
Every issue should have a priority assigned to help team members plan testing. It is up to the application security engineer creating the issue to determine priority based on the data available to them. If you are not sure of the appropriate priority, be conservative and assign a higher priority. It can always be adjusted given feedback from other team members.
Guidelines for Priority (Not comprehensive, please build upon)
| Priority | Criteria |
|---|---|
| priority::1 | Red data, AuthN/AuthZ, Crypto, Single severity::1, Repeat severity::2 vulns |
| priority::2 | Orange data, Single severity::2 vulns |
| priority::3 | Yellow data |
| priority::4 | Only standard secure practices necessary |
When threat modeling should be done
during the review add the threat model::needed label to the original issue or epic and the
appsec review issue. That way we can track the adoption of threat modeling throughout GitLab. When
the threat modeling step is done the
threat model::done label should be added to all involved issues and epics. The process for
threat modeling is further defined in its own handbook page.
The engineering team has created multiple labels with the purpose of quantifying interactions done by stable counterparts and tracking the status of these interactions. Stable counterparts should add the right label depending on the status of the interaction following the conditions below:
~sec-planning::in-progress: The issue or MR is under review.~sec-planning::pending-followup: Stable counterpart expects to follow up on the review.~sec-planning::complete: Review finished with comments.~sec-planning::no-action: Review completed and no action required.