Security Dashboard Review

Frequency: Daily

AppSec engineers are responsible for triaging the findings of the GitLab security tools. This role has two primary functions.

1. Validate the findings and handoff to engineering for correction
2. Provide feedback to the Secure team

Security Dashboard List

The following is a list of security dashboards that need to be reviewed:

• GitLab
• GitLab Omnibus
• Gitaly
• GitLab Pages
• GitLab Shell
• k8s-workloads
• Version
• UBI images
• release-cli
• vscode-extension
• Customers
• elastic-search-indexer
• GitLab DAST
• GitLab Terminal
• GitLab Agent
• Compensation Calculator

Validation

For each finding:

• Using the information provided and any additional information, determine if the finding is valid
• For a valid report:
  • Change the status to Confirmed
  • Click Create Issue
  • Assign Priority and Severity labels based on the finding rating and the impact on GitLab
  • Assign a Due Date
  • add labels (/label ~ command) corresponding to the DevOps stage and source group (consult the Hierarchy for an overview on categories forming the hierarchy)
  • @-mention product manager of appropriate teams for scheduling and/or the engineering managers if additional engineering feedback is required to complete the triage, based on the product categories page
    • If an appropriate engineering team is not immediately apparent, ping an Appsec manager for help identifying the owner
• For an invalid report:
  • Change the status to Dismissed
  • Leave a comment providing feedback on why the vulnerability is being dismissed. This information can be used by Secure engineers in tuning the findings of the tool and is also useful if we ever wonder why it was dismissed at some point in the future.

Dependency Updates

If a vulnerability is identified in a product dependency, the appsec engineer should follow the security development workflow to create a merge request to update the dependency in all supported versions. The merge request should be opened in the GitLab Security repo so that the dependency gets updated in supported backports as well. Vulnerabilities determined to be Critical or High should have merge requests created when identified. Medium and Low vulnerabilities will be addressed by best effort, but always within the 90-day SLA.

The goal of this process is to update dependencies as quickly as possible, and reduce the impact on development teams for minor updates. In the future, this step could be replaced by auto remediation.

If an upgrade to a new major version is required, it might be necessary for the update to be handled directly by the responsible development team.

• Complete the Validation process above.
• Create an issue in the GitLab Security repo issue tracker using the Security developer workflow template.
• Follow the template to create a merge request targeting the master branch.
• If the resulting pipeline is clean, continue with the developer checklist in preparation for merging. This must include reviews by a reviewer and maintainer.
• If the pipeline fails, work with the responsible engineering team to remediate. Depending on the cause, it may be necessary for a developer with advanced knowledge of the dependency functionality to review the change. If a developer is not immediately available, continue to track the issue/MR to ensure remediation within the defined SLA.