Anyone who works in application security (AppSec) knows the pain of vulnerability management. You work with the development team, as well as product and system owners, to get vulnerabilities mitigated or remediated, and then new scans run, and new vulnerabilities are found.
This infinite loop of toil and tension drains the development team’s time and focus and fosters resentment. People come to see security as always introducing problems and slowing down delivery of new features to production — and delivery velocity is a critical development team metric.
This is why contextual analysis is critical to AppSec. Contextual analysis can provides can provide critical information to help teams prioritize vulnerabilities and make the best use of their limited resources. That information includes:
- whether the dependency/code is reachable and in the attack path
- whether an exploit is available, and if so, at what level of maturity
- whether an exploit is used in the wild successfully, and more.
Which companies are the most important vendors in cybersecurity? Click here to see the Acceleration Economy Top 10 Cybersecurity Shortlist, as selected by our expert team of practitioner analysts.
Bring Signal to the Noise
Development teams have little time and attention to spare and, traditionally, in security, we demand both, and often for vulnerabilities with no actual context or details. This is incredibly problematic when we also realize that most vulnerabilities, often classified as Common Vulnerabilities and Enumerations (CVEs) and captured in vulnerability databases such as the National Institute of Standards and Technology National Vulnerability Database (NIST NVD), aren’t actually exploitable.
This means the vulnerabilities often don’t pose any real risk to the business, but without contextual analysis, it’s hard to tell the difference between what’s exploitable or not. This results in a lot of wasted time and a cognitive drain on the team.
Luckily, the industry is realizing the folly of the legacy approach of using base Common Vulnerability Scoring System (CVSS) scores without accounting for actual exploitability or environmental context because it’s inefficient and ineffective.
We’re starting to see greater use of resources such as Cybersecurity and Infrastructure Security Agency’s (CISAs) Known Exploited Vulnerabilities (KEV) catalog, which provides a list of known exploited vulnerabilities, emerging. This allows federal agencies and any other organization to prioritize those vulnerabilities for remediation.
CISA has also been championing the Stakeholder-Specific Vulnerability Categorization (SSVC) calculator, a collaboration with Carnegie Mellon University (CMU), as another resource organizations can use to prioritize vulnerability remediation.
We’re also seeing the emergence of the Exploit Prediction Scoring System (EPSS). Run by the same organization that runs the CVSS, the EPSS helps provide probability scores associated with CVEs. The EPSS shows the probability that a CVE will actually be exploited, going beyond just a blanket severity rating.
We’re also seeing vendors start to provide capabilities such as reachability analysis, which provides insight into whether or not vulnerable code is actually reachable within the application’s code base. This can help the security and development teams prioritize specific aspects of the code for remediation and allow development teams to perhaps seek out other, less vulnerable and exploitable components to include in their applications.
Final Thoughts
When you combine these capabilities of integrating contextual analysis to vulnerabilities through open source software (OSS) tooling, vendor products, or internally developed capabilities, you position your organization to spend your time and effort on the vulnerabilities that pose the largest risk to the organization — and therefore should be addressed first.
This drives down organizational risk, saves resources, and minimizes the strain on development teams. It also reduces the friction between development and security, with developers understanding that the items they’re being asked to address actually pose a risk and aren’t based on subjective scoring or metrics without context.
Time is limited, and it is best spent on vulnerabilities that pose real risk while not impeding development velocity and business outcomes that are enabled by software.
Want more cybersecurity insights? Visit the Cybersecurity channel:
