Here I would like to summarize my thoughts on what constitutes a perfect vulnerability management system, what frequently gets missed, and what elements we already have in the latest ReARM release.
Table of Contents
I Not Only Vulnerabilities
First of all, a management system should cover all security findings, not only vulnerabilities. That includes things like SAST / DAST findings and policy violations, for example licensing violations.
II Security Findings vs Bugs
Not my original thoughts, but security findings are bugs.
However, I would argue that there is an important difference. This difference lies mainly in the risk posture.
Assume here that a piece of software produces a +10 score net effect (on some imaginary scoring scale) for the user. If this software contains bugs, those would lower that Net score gain below +10 and sometimes down to 0. Now, security findings are bugs that are capable of bringing the score further down into negative territory. In other words, exploited true positive security findings are events that create condition in which the user would be better off without this particular piece of software.
From this it becomes clear that a security finding may have more impact in terms of risks than a critical functionality bug that renders the whole software unavailable. This, coupled with prioritization, demonstrates the need for managing the security posture of every organization, since the risk implications are significant.
III It All Comes Down to Risk
Some organizations are not like others. If we’re talking about startups, those organizations operate with extreme risk expectations where they may essentially cease to exist at any time. These other considerations may skew their position regarding security findings.
In the real world, even larger organizations frequently find themselves too far behind when it comes to basic housekeeping in cybersecurity. As a result, the whole industry is moving towards regulation with the EU Cyber Resilience Act being the most notable piece of legislation currently in the space.
The problem is that if an organization with a disproportionate risk appetite is put somewhere in the supply chain, that inevitably taints the whole supply chain, and untangling these problems becomes increasingly difficult.
IV Dimensions of Findings
When talking about findings, one should identify their different dimensions. I’m not pretending to be able to build an exhaustive list of dimensions, but I’d like to highlight main parameters to track:
- Type: is it a vulnerability, a SAST / DAST finding, or a policy violation.
- Severity: there are dozens of scoring systems available today, many of them are multi-dimensional, and none of them is perfect. However it is important to have a single linear scale for prioritization.
- Time: when talking about vulnerabilities, there are actually at least 4 time dimensions to note here – when the vulnerability was first discovered in the world, when it was introduced in some software release within your supply chain, when it was actually discovered within your supply chain, and finally when and in which version it was resolved.
- Scope: what component and product releases are affected.
V Aggregation and Deduplication
What I observe, is that currently there are 2 competing views in the marketing regarding the subject of aggregation and deduplication:
1st -> we must be as detailed as possible, and report each single vulnerability with detailed provenance as a separate entry. Further, the CVE / GHSA system is broken and widely incomplete, meaning there are many more real vulnerabilities in the wild than what scanners may report. We should try to capture all of them.
2nd -> development teams are overwhelmed with the amount of security findings. Excessive reporting and detail brings nothing but frustration and ever growing backlog. We must limit aggressively the number of items we report.
I respect both of these points of view, and I believe that each of them has merit, but the most important factor is the maturity of an organization’s cybersecurity practices. If an organization is only starting, the 2nd approach usually makes much more sense, then gradually as security practices improve, organizations should also gradually transition to the 1st approach.
VI The Perfect Finding Management System
Summing up what was mentioned before, here are the expectations that I would put on an ideal system to manage security findings:
- It should support a large list of attributes, such as type and scores, while allowing the user to collapse the list to a linear severity metric.
- It should support aggressive aggregation, deduplication and prioritization, but at the same time support a more detailed provenance view with rich contextual information.
- It should have a built-in ontology describing each finding and ideally be able to explore exploitability / reachability.
- It should provide extensive time series data, with different time dimensions as discussed above.
- It should attribute findings to exact component and product versions within the organization with extensive provenance metadata.
- It should have extensive audit functionality with configurable scope – so that it must be possible to declare a particular finding as a false positive within the whole organization, only for a specific component or product, only for a specific branch, or only within a specific release.
- It should support import of findings from various sources that can then be subject to uniform aggregation, deduplication and prioritization rules.
- It should have clearly documented and configurable workflows.
VII What We Have Already Done in ReARM
We have implemented to a large extent points 1., 2., 4., 5., 6., and 7. from my list above. A particular strength of ReARM is attribution of findings to specific releases with provenance metadata.
Immediate improvements we are working on are related to including more metadata attributes, and additionally point 8. – workflows. Stay tuned for upcoming releases of ReARM to see this new functionality in action.