This article breaks down CISA’s latest publication “Transforming the Vulnerability Management Landscape”
As the conversation around vulnerability prioritization and management has heated up, organizations such as the Cybersecurity Infrastructure Security Agency (CISA) in the U.S. have weighed in on the topic.
In an article published by CISA Assistant Executive Director Eric Goldstein in November 2022 titled “Transforming the Vulnerability Management Landscape” Eric Goldstein discusses the complexity of the modern digital landscape and the accelerating pace of vulnerabilities.
Per the article, CISA outlines three critical steps to advance the vulnerability management ecosystem. They include expanding the use of the Common Security Advisory Framework (CSAF) for automated machine-readable security advisories. It also includes bolstering adoption of the Vulnerability Exploitability eXchange (VEX), which helps software consumers understand when specific products are impacted by exploitable vulnerabilities from software producers. Lastly, is to help organizations prioritize vulnerability management resources using things such as the Stakeholder Specific Vulnerability Categorization (SSCV) and CISA’s Known Exploited Vulnerabilities (KEV). We will discuss each of these steps in a bit more depth below.
Common Security Advisory Framework (CSAF)
First on the CISA list was the use of CSAF for automating machine-readable security advisories. As CISA points out, every time a new vulnerability is discovered and disclosed, software vendors must evaluate their product offerings and validate whether it is applicable and if it is what must be done to remediate it and then communicate this information to their customer base. While vendors are doing this, so are malicious actors, seeking to actively exploit the vulnerability either before the vendor can fix it directly, say in the context of SaaS, or issue a patch and then have it applied by end users, in the context of traditional on-premises software. With the accelerating pace of vulnerability discovery and disclosures as it relates to CVE’s, there is a critical need to automate and expedite this activity to get this information out to software consumers and that’s where machine-readability and automation comes into play.
CSAF is led by the OASIS CSAF Technique Committee. OASIS is a non-profit consortium that helps create and evangelize various best-practices and standards. OASIS provides some excellent resources for those looking to start understanding CSAF, such as their “What is a Common Security Advisory Framework (CSAF)” video or the incredibly comprehensive CSAF 2.0 Specification.
As defined by the specification, “CSAF supports the creation, update, and interoperable exchange of security advisories as structured information on products, vulnerabilities and the status of impact and remediation among interested parties.” These advisories are formulated in JSON format.
Traditionally, security advisories are published as static documents such as PDF files and websites and so on and are intended for human consumption. The challenge with this is the accelerating pace of vulnerability discovery and disclosure coupled with the race to remediate them before exploitation by malicious actors, making the need for machines and automation critical. There are several parallels to this situation and other areas of cybersecurity which are increasingly adopting machine-readable artifacts, such as GRC with OSCAL and traditional IT with the advent of Infrastructure and Compliance-as-Code. The modern technological landscape simply moves too fast for humans to serve as a medium.
CSAF also offers a robust set of tooling such as CSAF Parser, Visualizer, Trusted Provider and Aggregator, just to name a subset of the portfolio. Each of these tools is accompanied by an associated GitHub repository, documentation, and code base to help organizations and adopters make better use of CSAF and operationalize it as part of their cybersecurity and vulnerability management activities, both as a software consumer or producer.
CSAF schema documents primarily involve three classes of information which are the frame, aggregation and reference information for the document, product information considered relevant by the CSAF advisory creator and lastly the vulnerability information in relation to the product(s) being discussed. CSAF also natively supports referencing schemas for industry standardized things such as platform data and vulnerability classification and scoring. Examples include Common Platform Enumeration (CPE), Common Vulnerability Scoring System (CVSS) and Common Weakness Enumeration (CWE), each of which have schemas for use.
With this basic overview it is easy to see how CSAF can help usher in an age of machine-readable security advisories which can be automated and help expedite the creation, distribution, and ingestion of security advisories to benefit both software providers and consumers and empower fast decisions around cybersecurity risk in the software ecosystem.
For those looking to go beyond this information you can review the robust specification itself, or watch some of the CSAF videos which are available for review.
Vulnerability Exploitability eXchange
Building on the conversation around CSAF, CISA’s second critical step is the widespread adoption of VEX. At a high-level, VEX allows software vendors to assert whether specific vulnerabilities affect a product, as well as if they do not affect a product. The reality is that organizations face a shortage of cybersecurity talent and VEX allows organizations to prioritize their time and resources on vulnerabilities which pose risk to them, rather than vulnerabilities which may not be exploitable and pose no risk. VEX documents are shaping up be a close companion of SBOM’s, to provide clarity into the exploitability of vulnerabilities contained within SBOM’s for software products and could be produced both with and outside of SBOM’s, as new vulnerabilities may emerge despite the lack of a new software release, due to vulnerabilities being regularly discovered and disclosed.
As defined by guidance from the (NTIA), VEX’s primary use case is “to provide users (e.g., operators, developers, and services providers) additional information on whether a product is impacted by a specific vulnerability in an included component and, if affected, whether there are actions recommended to remediate.” This is a lengthy way of saying VEX adds context to vulnerabilities to inform risk management activities. Much like other leading SBOM and Software Supply Chain transparency and security guidance, VEX was born out of the NTIA’s Multistakeholder Process for Software Component Transparency. That said, it is worth noting the guidance states that while VEX was developed for a specific SBOM use case, it is not limited to use with SBOM’s or necessarily required either.
As mentioned in the introduction above, just because a vulnerability is present does not mean it is exploitable. This is critical information to know because vulnerability management programs and activities, organizations are performing risk management. In cybersecurity risk management, organizations are looking to identify, analyze, evaluate, and address cybersecurity threats based on the organization’s risk tolerance. This leads to the organization prioritizing risks based on likelihood and the severity of the risk materializing. Without knowing if a vulnerability is exploitable, it would be impossible to accurately project its likelihood.
VEX — Adding Context and Clarity
So how exactly does VEX solve this challenge? It empowers software suppliers to issue a VEX, which is an assertion about the status of a vulnerability in a specific product. VEX supports four primary status options, which are:
Not Affected — No remediation is required regarding this vulnerability
Affected — Actions are recommended to remediate or address this vulnerability
Fixed — Represents that these product versions contain a fix for the vulnerability
Under Investigation — It is not yet known whether these product versions are affected by the vulnerability. An update will be provided in a later release.
With the SBOM itself as an example, we are seeing a push towards machine readable artifacts and documentation, which enables better automation, accuracy, and speed. We are seeing similar trends in the realm of compliance with NIST’s Open Security Controls Assessment Language (OSCAL) (https://pages.nist.gov/OSCAL/), which brings traditional paper-based security controls and authorization documents into a machine-readable format.
VEX is doing something similar, avoiding the need to email security advisories or details about vulnerabilities and recommendations, and instead bringing that information into a machine-readable format to foster automation and the use of modernized security tooling that moves at a pace much closer to the current threat landscape than humans and manual activities. As the push for software supply chain transparency and security evolve, it is not hard to imagine a world where enterprise software inventories are able to be visualized in dashboards and tooling, along with their associated vulnerabilities and the actual exploitability of the vulnerabilities, all empowered by SBOM’s and accompanying VEX data.
That is a stark contrast to the modern ecosystem where most organizations do not have accurate inventories of the software components they consume and have deployed, nor the vulnerabilities associated with it. This is all despite the reality that modern software is overwhelmingly composed of open-source software (OSS) components, with some estimates reaching as high as 80–90%.
The guidance also states that while VEXes can be authored by a software supplier, they can also be authored by third parties, leaving users in a position to determine how to use the data. This makes it easy to see scenarios where security researchers and vulnerability vendors may make attempts to produce VEXes for products as part of their own product offering.
For a great talk and overview on VEX, Dr. Allan Friedman and Tom Schmidt presented “VEXed by Vulnerabilities That Don’t Affect Your Product? Try This” at a FIRST conference. (
In the presentation they cover the origins of VEX, use cases, current adoption in communities such as the Medical and ICS space as well as where the industry is headed in terms of VEX use cases and tooling.
In the presentation they point to an OSS project titled Dagger Board (https://github.com/nyph-infosec/daggerboard), which is an SBOM Vulnerability Scanning tool that ingests SBOM’s in CycloneDX and SPDX format and outputs the results in human-readable format. The tool is being adopted by some organizations in the medical community and can help organizations understand the risk levels associated with their software and dependencies they use.
VEX is a form of security advisory and is supported by the Common Security Advisory Framework (CSAF). CSAF is a definitive reference that allows for a standardized way to create, update and exchange security advisories. It allowed products and vendors to communicate vulnerabilities and the status of impact and remediation to software consumers. VEX is supported by CSAF and allows suppliers and other parties to provide the status of vulnerabilities that may affect a product. (https://oasis-open.github.io/csaf-documentation/faq.html).
Some have argued that for VEX to be useable at scale, we will need a real-time VEX, enabled by API’s and automation to eliminate the manual toil required to produce, distribute, and ingest VEX documents that provide vulnerability impact status and detailed from software producers to software consumers.
Stakeholder Specific Vulnerability Categorization (SSCV) and Known Exploited Vulnerabilities (KEV)
Building on the conversation around VEX and other resources such as the Exploit Prediction Scoring System (EPSS) is the need to help organizations prioritize vulnerabilities that pose the greatest risk.
CISA has curated and published a Known Exploited Vulnerabilities (KEV) Catalog and mandated through a Binding Operational Directive (BOD) that Federal agencies remediate KEV’s and recommends that commercial organizations do the same if they are impacted by these KEV’s. This KEV is published as a webpage but also as a CSV and JSON file. Organizations and individuals can also subscribe to the KEV catalog update bulletin which delivers email notifications when new KEV’s are added to the catalog.
The criteria for vulnerabilities to make it into the KEV catalog include that they have a CVE ID assigned, are actively being exploited in the wild based on reliable evidence and that there is clear remediation guidance for the vulnerabilities, such as vendor provided patches or updates. As discussed, the CVE program is sponsored by CISA but run by the Federally Funded Research and Development (FFRDC) MTIRE. The CVE program aims to identify, define and catalog publicly disclosed vulnerabilities. CVE ID’s are assigned by CVE Numbering Authorities and have three potential status,’ which are Reserved, Published and Rejected.
On the actively being exploited front, CISA’s KEV catalog does not use exploitability itself as criteria for inclusion in the catalog, but instead there is reliable evidence that the vulnerability either has attempted or successful exploitation. For example, there may be evidence that a malicious actor tried to execute code on a target but failed or merely did so on a honeypot system, aimed at exposing malicious activity. Unlike attempted exploitation, successful exploitation means a malicious actor successfully exploited vulnerable code on a target system thus allowing them to perform unauthorized actions of some sort on the system or network. CISA is careful to point out that Proof of Concept (PoC) exploits do not make it to the KEV catalog, given that while a researcher may have shown something could be exploited, there is no evidence that it has been, or even was attempted to be exploited in the wild.
The third criterion for KEV catalog inclusion is clear remediation guidance. This means that there are clear actions organizations can take to remediate the risk of the KEV. These could be actions such as applying vendor updates or in potential dire situations, removing the impacted product from the network entirely if there is either not an update available or the product is end-of-life and simply no longer being updated or supported. CISA also acknowledges that in the absence of relevant updates and patches organizations often will seek to implement mitigations to prevent a vulnerability from being exploited or workarounds, which are manual changes to protect a vulnerable system from exploitation until patches are available.
Building on the guidance to utilize the KEV, CISA is striving to help organizations prioritize vulnerability management resources using SSVC. SSVC was created through collaboration by CISA and Carnegie Mellon University’s Software Engineering Institute (SEI). SEI of course is no stranger to critiquing the sole use of sources such as the Common Vulnerability Scoring System (CVSS), with their somewhat damning white paper titled “Towards Improving CVSS” where they point out several of the shortcomings of the widely used CVSS for vulnerability prioritization. One irony worth mentioning as well is that despite this advocacy of frameworks such as SSVC, Federal organizations such as CISA and others still enforce the use of CVSS, despite actively partnering with organizations such as SEI who have pointed out its shortfalls and deficiencies.
As described in the SSVC guide that CISA published, SSCV is a customized decision tree model to assist in prioritize in vulnerability response for the U.S. Government and associated entities but can be used by others as well. SSVC includes four possible decisions, as depicted in the image below.
The guidance recommends organizations understand the vulnerabilities scope as that will impact the decision tree as well, for example if a vulnerability and product is pervasive across an entire enterprise or part of a critical system.
When utilizing SSVC and walking through the decision tree, several decision points are considered. These include items such as the state of exploitation, using sources such as the National Vulnerability Database (NVD) or Information Sharing and Analysis Centers (ISAC)’s. These sources usually provide insight into whether a vulnerability has no evidence of exploitation, has a PoC as previously discussed or is actively being exploited in the wild.
Next, organizations need to understand the technical impact of exploiting vulnerability. Parallels here can be drawn to CVSS’ base score concept of severity. Potential values include partial, where a malicious actor has limited control or impact on a system, or total, meaning they have total control over the behavior of the software or system that the vulnerability pertains to.
Another key consideration is whether the exploitation is automatable. It is far easier for malicious actors to scale their nefarious activities with exploits that can be automated, than those that require manual intervention and implementation. The decision values here are a simple yes or no. If the answer is yes, then the malicious actor can automate Steps 1–4 of the kill chain, as defined by the Lockheed Martin Cyber Kill Chain. Those steps are Reconnaissance, Weaponization, Delivery and Exploitation. The guidance mentions that in addition to automation, vulnerability chaining must be considered, as it is potentially required or possible to chain several vulnerabilities or weaknesses together to have a successful exploitation.
Moving on from technical impact is the consideration of Mission Prevalence, which is the impact on mission essential functions or relevant entities. The SSVC guidance defines Mission Essential Functions (MEF) as functions that are “directly related to accomplishing the organization’s mission as set forth in its statutory or executive charter.” Organizations identify MEF’s through exercises such as business continuity planning (BCP). Decision values in this consideration include Minimal, Support or Essential. Essential would be where a vulnerable component directly provides capabilities to at least one MEF or entity and would lead to mission failure. Support on the other hand means the vulnerable component supports MEF’s but does not support them directly. Lastly, Minimal is a situation where neither Essential nor Support applies.
Next in the decision tree would be Public Well-Being Impact, or the extent to which a vulnerable component or system impacts humans. SSVC utilizes the Center for Disease Control (CDC)’s definition of well-being, meaning physical, social, emotional, and psychological health of humans. Decisions here are broken out across the Impact, which can be Material or Irreversible, as well as the Type of Harm, which can run the range from physical to psychological, or even financial.
Lastly is the consideration of Mitigation Status, which measures the degree of difficulty to mitigate the vulnerability in a timely manner. The factors to consider under this item are the availability, difficulty, and type of mitigation. This can range scenarios from mitigations being publicly available or not, as well as being low or high difficulty to make the required system change and of course if a fix exists or a workaround is required as previously discussed. The guidance stresses that the value of the mitigation should not change the priority of the SSCV decision but it should be actively tracked and considered.
Below is one proposed example of the decision tree, but it can be represented in a table format as well.
As an additional resource for organizations to make use of SSVC, there is a SSVC Calculator which can be used to evaluate how to prioritize vulnerability responses in an organizations environment.
Moving Forward
While the CISA guidance prioritizes things such as automating security advisories with CSAF and informing software consumers of impact through vulnerability exploitability with resources such as VEX, it is also clear that subjective cybersecurity expertise is still required, especially in complex decision trees as recommended by SSVC. It is also critical to call out that robust tooling to handle the ingestion, integration and usage of SBOM’s and VEX artifacts is still maturing across the industry, in addition to just the adoption of producing and distributing SBOM’s and VEX artifacts themselves.
Automation will play a pivotal role in reducing cognitive load on organizations and cybersecurity teams but there will still be a persistent need for cybersecurity and software expertise to understand the broader enterprise and system context that vulnerabilities pose and how to prioritize the organizational resources to address them.