The Cybersecurity and Infrastructure Security Agency on Thursday released a set of documents to guide prioritization of software vulnerability remediation by agencies and other organizations. But use of the guidance is largely contingent on vendors providing the information necessary to conduct such a process.
In a blog post on “transforming the vulnerability management landscape,” CISA Executive Assistant Director Eric Goldstein encouraged enterprises to use “Stakeholder Specific Vulnerability Categorization”—a process first articulated by CISA with the Software Engineering institute at Carnegie Mellon University—for deciding which system bugs they should fix first.
Agencies are under a binding operational directive to receive and address vulnerability reports from security researchers within specific timelines, and are deciding what evidence they might require from software vendors attesting to secure development practices, under a May 2021 executive order on improving national cybersecurity.
Goldstein noted that CISA used the SSVC methodology in coming up with its catalog of hundreds of known exploitable vulnerabilities, which agencies are also required—under a different binding operational directive—to reference when applying a framework for addressing weaknesses they already know are in their enterprises.
But not all software vulnerabilities are readily known—or logged as a common vulnerability and exposure, or CVE—on public databases. And in Goldstein’s vision for advancing vulnerability management practices, use of the SSVC prioritization methodology is third in a three-step process.
“First, we must introduce greater automation into vulnerability management, including by expanding use of the Common Security Advisory Framework. Second, we must make it easier for organizations to understand whether a given product is impacted by a vulnerability through widespread adoption of vulnerability exploitability exchange,” he said, outlining steps one and two.
The Common Security Advisory Framework, or CSAF, is a machine-readable format software vendors can use to advise customers of vulnerabilities that exist in their code. A vulnerability exploitability exchange—or VEX—is a document the vendor can use to explain how they might have neutralized particular vulnerabilities, so that users don’t have to worry about them still being in their products. A vendor could also highlight the presence of a vulnerability with a VEX, so that users can prioritize patching it.
The VEX can be particularly helpful when used in tandem with a software bill of materials, Goldstein noted.
The May 2021 executive order, issued in reaction to the SolarWinds hack, was intended to give agencies more visibility into the software they procure. But implementation of the order through the National Institute of Standards and Technology and the Office of Management and Budget left it up to agencies themselves to determine whether they should ask vendors for evidence, such as SBOMs, when considering their software purchases.
The prioritization system CISA released for managing vulnerabilities instructs users to assess five factors: exploitation status, technical impact, automatability, mission prevalence and public well-being impact.
CISA has said it is working through the General Services Administration’s Federal Risk and Authorization Management Program to get cloud services to do their part in fixing vulnerabilities, but that it is still the agency’s responsibility to communicate directly with vendors when bugs are identified in their systems.