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.
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. This process is intended for such features, even if the stable counterpart will be performing the review.
The application security review queue is a priority queue of application
features for security review. The priority can range from
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
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.
Relatedlinks for any issues or merge requests associated with the feature.
appsec priority::Ppriority label based on the determined priority. See Assigning Priority.
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)
|P1||Red data, AuthN/AuthZ, Crypto, Single S1, Repeat S2 vulns|
|P2||Orange data, Single S2 vulns|
|P4||Only standard secure practices necessary|
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.