Today, nearly every party that issues security advisories uses its own format and structure. Plus, most security advisories are only human-readable, not machine-readable.
System administrators have to read each advisory, determine if they use the products and versions listed, and evaluate the potential risk and existing mitigations. Based on their system’s exposure and the business value, they make a decision about if and when to patch.
It’s a time-consuming process that delays vulnerability remediation and increases risk. Vendors and providers of software and hardware need to disclose security vulnerabilities in a way that accelerates this process and empowers customers to use automation.
The New Standard for Security Advisories
The Common Security Advisory Framework (CSAF) 2.0 supports the automation of vulnerability management by standardizing the creation and distribution of structured machine-readable security advisories.
CSAF is an official standard of OASIS Open. The technical committee that developed CSAF includes numerous public- and private-sector technology leaders, users, and influencers.
Manufacturers can use CSAF to standardize the format, content, distribution, and discovery of security advisories. These machine-readable JSON documents enable administrators to automate the comparison of advisories against a user’s asset database or even a supplier’s software bill of materials (SBOM) database.
The automated system can filter vulnerabilities based on the products of interest and prioritize based on business value and exposure. This dramatically speeds up the evaluation process and enables administrators to focus on managing risk and fixing vulnerabilities.
CSAF, VEX, and SBOMs
Vulnerability Exploitability eXchange (VEX) is a profile in CSAF. VEX was developed in the SBOM community as a way for manufacturers to easily convey that a product is not affected by issuing a so-called negative security advisory. VEX is designed to work with SBOMs, although it is not necessary to have an SBOM to use VEX documents.
A VEX document must include information about the disposition of each vulnerability as it impacts each product. A product can be marked as under investigation, fixed, known affected, or known not affected. For those products that are marked as known not affected, VEX requires that the publisher include a justification for that status.
Being able to communicate the various statuses of a vulnerability — including under investigation and not affected — means customers can get that information without calling the vendors or manufacturers, which will be a relief to customer support. Moreover, it enables customers to better manage vulnerability risk.
When paired with an SBOM, VEX documents enable administrators to use asset management systems to quickly determine what vulnerabilities are not exploitable, which frees them to focus on any vulnerabilities that could put their businesses at risk.
Other CSAF Profiles
VEX is one of five profiles in the CSAF schema. Each profile has certain required fields and is designed to address a specific need.
The CSAF base profile serves as the foundation for all of the other profiles. It defines the default required fields for any CSAF document — primarily information about the document itself, such as who published it, when it was published, and if it has been revised.
The security advisory profile includes information that we see in most security advisories today — details about the vulnerability, products affected, and remediations.
The informational advisory profile can be used to provide information about a security issue that is not a vulnerability, such as a misconfiguration.
Finally, the security incident response profile can be used to provide information about a security breach or incident that happened at the company, or about the impact that an incident involving another party (like a contractor or component manufacturer) had on the company.
CSAF Tools and Guidance
CSAF defines conformance targets that help consumers and producers to find the right tool for their requirements. The OASIS CSAF technical committee also developed a suite of tools for using CSAF, including:
To help issuing parties to write actionable CSAF documents, there is guidance for each field, which can be found here.
