The tide of new vulnerabilities continued to rise in 2021. Analysis by cybersecurity firms and the National Institute of Standards and Technology’s (NIST’s) National Vulnerability Database (NVD), the number of new Common Vulnerabilities and Exposures (CVEs) set a new record for the fourth year running. Roughly 20,000 new CVEs were reported — more than 50 per day. Lots of these vulnerabilities are in open-source software components, such as Apache Log4J, or in Node.js packages hosted on the npm registry.
Not even the best-staffed application security (AppSec) teams can keep up. This makes it imperative for security organizations to effectively prioritize vulnerabilities for remediation and accept they will never patch all vulnerabilities indicated by software composition analysis (SCA) scans. Even if they could fix all vulnerabilities, this would consistently break applications and slowing software development to a crawl.
So AppSec teams create heuristics and rely on criticality ratings that are often not relevant to their applications and infrastructure. This can result in wasted time and energy fixing vulnerabilities that might present a lesser — or even zero — risk. In an alternative universe, if AppSec teams could test which vulnerabilities actually have a higher chance of impacting their specific applications then they could dramatically reduce risks while expending the same or even less energy and time on patching and then applying downstream fixes. To this security teams must combine results of both SAST and SCA, creating a picture of how data moves through applications. This semantic understanding of flow enables accurate insights into which vulnerabilities will likely result in successful attacks.
How security teams prioritize vulnerabilities today
Most application security teams and security operations teams have vulnerability management solutions. Some use heuristics and formulas to rank vulnerabilities using frameworks like MITRE ATT&CK. Inputs to these solutions and heuristics traditionally include:
- Severity score (CVSS).
- Date published.
- Exploit availability or complexity.
- Global usage levels of the vulnerable software product.
- Dependency density within the applications.
- Application type and potential for business disruption or data exfiltration.
While these benchmarks are an important starting point, they are still a 10,000-foot view far removed from the actual threat posed to an application. AppSec teams must then ask developers to demonstrate the security controls used in their methods. In the real world, most paths in an application will have security controls so manually checking paths results in many confirmed secure paths for every insecure path. It’s costly, tedious, and time-consuming.
Think about reachability
A vulnerability may evade an attack for a variety of reasons – developers may have already sanitized paths leading to the package with the CVE, or the package may take inputs that are internal and trusted by the application. This reality underscores the importance of context and understanding of how the pieces of an application and infrastructure fit together. That understanding of security context can drive smarter prioritization efforts. This context — which we call “attackability” — fits into the larger concept of “reachability.”
Think of reachability as similar to concepts like networking and graph theory. When used by InfoSec teams to understand whether a database server can reach a web server, they are essentially asking if the web server can communicate with the database server. If it can, then the database server is reachable.
In AppSec, the security pros use reachability as a way explain open-source dependencies. In its most simple form, reachability refers to whether or not the application itself can reach the dependency. If there’s evidence that the application calls the dependency, then that dependency is reachable. This tells analysts that the application uses the dependency. But it does not tell whether the dependencies and its related CVEs pose risk to the application. That’s where attackability comes in.
Attacker-Reachability improves risk prioritization
We consider attackability a more specific type of reachability that goes further to prove risk and indicate whether an attacker working from the surface of the application can reach the dependency based on data flows through the application and its components. Solutions that determine attackability make it easier to focus on real risk. The AppSec team can take this artifact to the developers to make a clear case for prioritizing an upgrade and show them the offending data flow. If it’s a complex upgrade, developers can sanitize the attackable path instead.
For a tool to see attackability, it has to map data flows that pass through both custom code and open-source dependencies. It’s a challenge for SCA tools that identify risky dependencies, but cannot determine reachability. SAST tools have been identifying data flows for attackable custom code vulnerabilities for decades, but the legacy technologies they are built on cannot follow paths through open-source libraries. We need more modern tools to view code holistically and ascertain attackability.
Prioritizing vulnerabilities by reachability or attackability, depending on the capabilities of the organization’s tooling, can drive consistent productive improvements for AppSec and development teams alike. This will empower them to ship code faster, and more securely.
Manish Gupta, chief executive officer, ShiftLeft
