The exploitability advisory: CISA’s VEX offers fresh take on tackling known vulnerabilities

‘SBOM turns on flashing lights on the dashboard; VEX helps you figure out which to turn off’

A new twist on security advisories promises to optimize the triaging of vulnerabilities by highlighting whether flaws are not just present within software but practically exploitable, too.

Developed by the US government, the vulnerability exploitability exchange (VEX) enables “both suppliers and users to focus on vulnerabilities that pose the most immediate risk” and avoid wasting time on bugs with no impact, according to use cases (PDF) published by the US Cybersecurity & Infrastructure Security Agency (CISA) in April 2022.

RECOMMENDED Patching common vulnerabilities at scale: project promises bulk pull requests

As CISA vulnerability analyst Justin Murphy puts it: if a software bill of materials (SBOM) “turns on flashing lights on the dashboard, VEX helps you figure out which ones you have to turn off”.

Speaking at the recent Linux Security Summit in Dublin, Ireland, Murphy said this “negative security advisory” supplements the provision of a product’s ‘ingredients’ by SBOMs, which President Biden has decreed should be a precondition for the government purchase of software.

Vulnerable_code_not_in_execute_path

VEX advisories, which emerged from a National Telecommunications and Information Administration (NTIA) project, advise whether a product is ‘affected’, ‘not affected’, ‘fixed’, or ‘under investigation’ in relation to a particular bug.

As detailed (PDF) by CISA, the ‘not affected’ designation could be accompanied by ‘status justifications’ such as:

Component_not_presentVulnerable_code_not_presentVulnerable_code_cannot_be_controlled_by_adversaryVulnerable_code_not_in_execute_pathInline_mitigations_already_exist

Murphy suggested a specific scenario in which “you have a third-party dependency and it says the code is vulnerable, but since the compiler rips it out you’re not actually affected”. Alternatively, he continued, a product might use a vulnerable library but not its vulnerable functions, or contain protections around input validation.

In providing information about exploitability, suggested Murphy, VEX advisories usefully augment SBOMs and the Known Exploited Vulnerability Catalog, which CISA launched in the fall of 2021.

Machine readability

The proliferation of CVEs and therefore security advisories has made tackling known vulnerabilities a “data management problem”, said Murphy.

And the problem is complicated by the fact advisories come in various formats, hampering not just machine readability but also “human readability in some cases”.

Asking the maintainer about flaws – “will you even get a response?” – or conducting your own, time-consuming investigation are hardly superior alternatives, argued Murphy.

This context helps explain CISA’s focus on interoperability and the fact VEX advisories can be implemented in the machine-readable OASIS CSAF standard.

Name confusion

Aspirations to link SBOM and VEX data are complicated by the lack of a universally agreed upon system of common identifiers for software components, conceded Murphy.

As such, security teams are at risk of erroneously misunderstanding their stack’s exposure when, for example, separate SBOMs inadvertently use differing identifiers for the same component or the same identifier for different components.

A comprehensive component identification system probably needs to address this problem “through aliases or equivalency relationships”, suggested Murphy, perhaps using a combination of common platform enumeration (CPE), package URLs (purls), SWID tags, SWHIDS, and GitBOM.

DON’T MISS Microsoft confirms zero-day exploits against Exchange Server in ‘limited’ attacks