Runtime Software Composition Analysis Functionality
Forward
This is a feature proposal that originated from PM. We aim to help our users perform their job in the most efficient manor possible. There is no defined timeline on this, nor has a technical assessment been performed. Feedback is always welcome on this hypothetical idea.
Problem to solve
Current SCA tooling (ours included) creates a lot of noise when alerting users to vulnerabilities. Some of these vulnerabilities are important to remediate, but a vast majority may not represent real risk to an organization; many vulnerabilities may not be exploitable in the context of deployment. This is a function of SCA tooling relying heavily on CVSS scores.
Moreover, there is no awareness of how the application is deployed or running, which causes users to encounter an influx of vulnerabilities, leaving them unable to gather enough information to assess organizational risk. SCA scan results need to provide users context for prioritization (e.g., is this vulnerability going to affect the running application).
To better serve our customers and help them with vulnerability remediation prioritization we should provide insight to the user in the form of Operational Dependency Scanning. We should be able to understand the dependencies used at runtime and their corresponding vulnerabilities, then indicate this to the user.
Intended users
There will be four primary users that can be categorized into two groups (AppSec and Development)
- Delaney (Development Team Lead) will get better insight into the Vulnerabilities her team will be responsible for remediating. This will allow her to better prioritize work for her team and allow them to focus on feature delivery, by reducing noise associated with vulnerabilities that do not directly impact an application. Delaney falls under the Development group, mentioned above.
- Sasha (Software Developer) will have an easier time remediating vulnerabilities that have been prioritized. Instead of going through a remediation process based entirely on CVSS severity, a new hierarchy of remediation will be established, with vulnerable libraries used by the running application taking the highest priority. This enables Sasha to focus on feature delivery, rather than wading through a sea of potentially unimportant vulnerabilities. Sasha falls under the Development group, mentioned above.
- Amy (Application Security Engineer) will be able to have a more accurate threat assessment for the applications her organization develops. She will be able to more easily review security fixes and verify there are no remaining threats to the organization's assets. Amy falls under the AppSec group, mentioned above.
- Alex (Security Operations Engineer) has the job of "firefighter" and is required to prevent malicious attacks and mitigate active risks. Should a zero-day be disclosed Runtime SCA will enable him to quickly assess what needs to remediated first by understanding the libraries in use in his organization's applications that are running in production. Alex falls under the AppSec group, mentioned above.
User experience goal
- Users will run their DS as they normally would
- DS would flag libraries in use
- The flag value would be accessible via the Vulnerability report (UI) and in any data streams that are currently in use to extract DS results from GitLab.
- User can apply a filter to the Vulnerability report to only see runtime vulnerabilities
- Users can filter the Dependency list to only see runtime libraries
Additionally
- Categorize each vuln as: Used, Used & Vuln, Not Used
- Add column in Vulnerability report to identify if used or not
Proposal
TBD - Spike needed.
Available Tier
Dependency Scanning is only available to GitLab Ultimate customers, so this feature would fall under that tier.
Feature Usage Metrics
We should have the following metrics:
- Total count of vulnerabilities
- Total count of libraries
- Total count of runtime libraries
- Total count of runtime vulnerabilities
- Runtime vulnerabilities remediated
- Non-runtime vulnerabilities remediated
What does success look like, and how can we measure that?
Success Metrics
- Compare the percent of vulnerabilities that have a status of
Dismiss
pre and post implementation. The hypothesis is that we should see a higher number of vulnerabilities fall under theDismiss
status. This would tell us organizations are more focused on the vulnerabilities that matter, instead of the noise that is generated simply running scan against all open-source libraries in their environment.
Acceptance Criteria
Given
this functionality has been rolled out to production
When
a user runs their Dependency Scans
Then
they should be able to clearly identify which vulnerabilities are associated with a library that is actively being used in a production application.
What is the type of buyer?
The buyer here is someone in an AppSec organization. Their main issue is the vast number of vulnerabilities they need to manage across many team, helping each team prioritize the vulnerabilities that need to be prioritized for remediation.
Is this a cross-stage feature?
This will be a cross-stage feature.
Composition Analysis will be responsible for the primary feature implementation.
Threat Insights will be responsible for propagating this information to the user via the Vulnerability report.
What is the competitive advantage or differentiation for this feature?
Major AppSec point solutions currently do not offer this type of functionality. This is something that GitLab is uniquely positioned to implement, given the breadth of our platform.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.