Blog Post: Enforcing secure software development at Enterprise scale in the AI era
Triage (REQUIRED)
Please note that there is a different process for when you want to announce something via the blog. Please see announcement requests in the handbook and open an announcement request issue instead of a blog post issue.
Proposal
Link to full content with links/images/formatting: https://docs.google.com/document/d/1C-t2yGLplKD-DT1kO-zP1j87RS8hqCra81_PlsUdKeU/edit?usp=sharing.
Prior to the metamorphosis of AI in the past year, security teams were already challenged to keep up with the pace of development. Whether challenged by leaders who errantly overlooked the importance of security in the development process, or due to the gearing ratio of developers to security teams, the bar is only getting higher – if not entirely out of reach. Then enters AI. According to MIT, developers using AI are able to complete tasks 55.8% faster than those without. The speed of development is likely to only increase, and the security tools used to govern development must match the pace and evolve to close the gap.
The need to effectively manage and prioritize vulnerabilities has put immense pressure on AppSec teams. With GitLab's security policies, along with our suite of security tools, organizations can foster collaboration between AppSec and Development teams, enabling efficient vulnerability detection, triage, and remediation. Security policies also provide a mechanism for automating security compliance and managing it at scale.
As highlighted in DataDog's State of Application Security report (2023), only 3% of critical vulnerabilities warrant prioritization. Nevertheless, security scanning continues to surge, with a 50% increase over the past four years (Invicti AppSec Indicator, Spring 2023 Edition). While scanning more potential sources of vulnerabilities offers greater opportunities for early detection and issue resolution, the sheer volume of findings can overwhelm AppSec teams. Identifying what is actionable is only becoming more of a challenge as we collectively gain insight to vulnerabilities from additional scanning.
Today, there are a few common approaches to handling vulnerability triage:
CVSS Scoring: The Common Vulnerability Scoring System (CVSS) provides a standardized method for assessing vulnerability severity. By leveraging CVSS scores, organizations can prioritize vulnerabilities based on their potential impact and allocate resources accordingly.
Risk-based Scoring: Risk-based scoring allows organizations to assess vulnerabilities based on their likelihood of exploitation and potential business impact. By considering contextual factors, such as asset value, threat actor capabilities, and exploit prevalence, organizations can effectively prioritize vulnerabilities.
Threat Modeling: Threat modeling is an approach that involves identifying and evaluating potential threats to an application or system. By conducting a comprehensive analysis of the system's architecture, data flow, and potential attack vectors, organizations can prioritize vulnerabilities based on their relevance to likely threats. This approach helps allocate resources effectively by focusing on vulnerabilities that are more likely to be exploited.
Business Impact Analysis: Business Impact Analysis (BIA) is a technique used to assess the potential impact of vulnerabilities on business operations and objectives. It involves identifying critical assets, evaluating their importance to the organization, and quantifying the potential consequences of a successful attack. By considering the potential financial, reputational, and operational impact, organizations can prioritize vulnerabilities that pose the most significant risk to their core business functions.
While these are useful techniques for assessing vulnerabilities and a method for prioritization, how are they translated from theory into practice?
Security Policy Management
Security policies are the answer for decomposing business-level policies and compliance requirements into tangible operating instructions that are baked into your DevSecOps or Software Development Lifecycle. By creating rules within GitLab's security policies, organizations can define granular criteria for vulnerability assessment, ensuring that only actionable findings are flagged for further attention.
Security policies allow you to execute on your security and compliance requirements and best practices by instantiating them in code. You can create scan execution policies that enforce scanners to run within specific projects based on your needs and requirements, ensuring that any vulnerabilities and exposures are detected before merging code to production.
You can also leverage merge request approval policies (previously scan result policies) to create customized workflows to address vulnerabilities and prevent or block MRs from merging unless they’ve been thoroughly reviewed and approved based on the rules you’ve defined.
You can define granular rules within merge request approval policies based on the filters and attributes shared below. These rules can help you determine which vulnerabilities are most actionable and find a signal in the static:
Vulnerability Status: Security policies can be targeted based on the status of a vulnerability, often focused on newly detected vulnerabilities that need triage. It’s also possible to create rules based on previously detected vulnerabilities with a given severity, or to include/exclude vulnerabilities if they have been dismissed. Branch: Target enforcement only on particular branches, such as by focusing enforcement on the Default branch of critical projects, or by targeting any Protected branches. Fix available: Filter out findings from dependency and containers scanning results where a fix is not available. Often these depend on upstream changes from 3rd parties, and are not yet actionable. Issues can be created from the vulns and tracked with a Due Date to address these vulns when a fix becomes available. False positive: When our GitLab scanners determine a finding to be a False Positive (for container and dependency scanning), we’ll mark the state within the vulnerability. Security policies can then utilize this to filter false positives from the security policy oversight, allowing AppSec engineers and developers to ignore these findings and merge code undeterred. Vulnerabilities will still be available in the vulnerability report for deeper analysis if required. Age (or SLA): At times, lower severity vulnerabilities can be tolerated by organizations for a time, but should be planned and addressed within a reasonable SLA. With security policies, you can set an SLA based on the severity of a finding, such as allowing Medium vulnerabilities to be merged without requiring approvals for an SLA of 60 days (which can be addressed in a follow-up issue with a Due Date). But if the vulnerability is detected as exceeding the 60 day SLA, it will block merge requests and require the vulnerability to be addressed.
Merge request approval policy filters enable precision in security compliance
Security policies can be managed in a number of ways, but are best managed in an isolated GitLab project that ensures separation of duties between security professionals and development teams. Policies are stored in yaml. This policy-as-code approach empowers your security team and offers many benefits, including a git history of any changes to the policies for visibility, version control to more easily roll back disruptive changes, oversight and required approvals of any policy changes (if required), auditability through GitLab audit events, and concrete controls that can be shared as evidence to auditors.
Example of security policies stored in yaml
We spoke with several of our customers to learn how they manage the onslaught of vulnerabilities and assess the priority, and how they are using GitLab or other tools to achieve this. Here’s what we learned:
(Note: the following are theoretical. Will need to get some customer comments.)
[Age filter — As a federal government agency, we follow the NIST standard and have requirements to address vulns within a particular SLA. With Security Policies, we set rules to detect vulnerabilities based on the age of the finding and require action from our development teams to fix these within a given SLA – 60 days for Medium severity issues, 30 days for High Severity, and Critical issues of course must be addressed immediately]
[Fix available, false positive – we use a number of rules in our security policies to filter out dependency vulnerabilities that don’t yet have a fix available, as well as any false positive findings for secret detection scans. This saves us a lot of time evaluating MRs to validate if findings are legitimate. As many as 30 MRs per month are determined as being a false positive, which allows us to focus energy on 30 other MRs that are actually a risk.]
[We use a mix of the vulnerability report and security policies to triage issues based on priority]
[...]
Tying it all together
Managing the ever-growing influx of vulnerabilities requires a precision approach that balances thorough scanning with efficient triaging and remediation. GitLab's security policies provide a powerful solution that enables collaboration, offers flexibility in defining customized policy rules, and a means to precisely operationalize business requirements and compliance frameworks. By leveraging GitLab's security tools and applying custom filters and attributes, organizations can streamline vulnerability management and focus their efforts on addressing the most critical risks, ultimately enhancing their overall security posture, and meeting the requirements of external bodies.
With GitLab’s DevSecOps platform, we offer a robust suite of security tools. As much as 41% of organizations work with 10 or more cybersecurity vendors today, and 77% are highly likely to reduce the number of security solutions they rely on (Palo Alto’s 2022 Global Survey “What’s Next in Cyber”). Consolidation of tools is on the minds of many CISOs and GitLab helps reduce the tool chain sprawl. Beyond utilizing security policies to enforce policy-as-code at scale, we offer the core security scanning solutions – SAST, Secret Detection, SAST IaC, DAST, Dependency Scanning, API DAST, and API security. We also enable vulnerability management for AppSec teams with dynamic vulnerability reports. And we close the loop on compliance with compliance frameworks, compliance adherence reports, and audit events. Learn more about how to manage Application Security using GitLab.
Related posts:
The ultimate guide to securing your code on GitLab.com Getting started with GitLab application security
Checklist
-
Does this align with a time-sensitive release, campaign or announcement? Please add link to pertinent info such as eBook landing page -
If wide-spread customer impacting or sensitive, mention @nwoods
to give her a heads up ASAP, apply the sensitive label, and check the PR handbook in case you need to open an announcement request instead of a blog post issue -
If the post is about one of GitLab's Technology Partners, including integration partners, mention @mjoscelyn
, apply the Partner Marketing label, and see the blog handbook for more on third-party posts -
If the post is about one of GitLab's customers, mention @nicolecsmith
, apply the Customer Reference Program label, and see the blog handbook for more on third-party posts -
Indicate if this post requires additional approval from internal or external parties before publishing (please tag needed sign off DRIs as necessary) -
Please upload any images to the MR before tagging the editorial team.
Questions?
-
Please tag @Sgittlen with any questions/concerns/confusion.