Did CISA do their homework?

On November 10, CISA issued a blog post called “TRANSFORMING THE VULNERABILITY MANAGEMENT LANDSCAPE”. It got a lot of attention and widespread approval. It describes three techniques whose implementation will, according to the post, lead to “more efficient, automated, prioritized vulnerability management.” While these should be of interest to both software (and intelligent device) suppliers and end users, the recommendations are aimed primarily at the suppliers – since they need to take the initiative in all three of these areas.

Since the third recommendation, use of the new SSVC vulnerability categorization framework (which, not at all coincidentally, is CVSS spelled backwards) isn’t closely related to the first two, I’ll just focus on those two, although SSVC strikes me as a very good idea.

CISA’s first recommendation is that software suppliers should “Publish machine-readable security advisories based on the Common Security Advisory Framework (CSAF).” CSAF is currently on v2.0, which is also its first versoin. CSAF is the replacement for the Common Vulnerability Reporting Format (CVRF) version 1.2, which has been available since 2017. CVRF was developed and maintained by the CSAF technical committee of OASIS. I don’t know the full story, but at some point the committee presumably decided that the new version they were contemplating was going to be so different from CVRF that they should just name it after the committee. Sounds like a smart move to me. After all, it’s all about branding.

Unfortunately, branding alone isn’t enough when it comes to a machine-readable advisory format. You need two more things. First, you need at least one software tool to create the advisories, for use by suppliers who aren’t intimately familiar with the format. If you spend five minutes looking through the CSAF format, I think you’ll agree that it would take a lot of study for someone with no prior knowledge of, or experience with, CSAF to create an advisory without the help of a tool. Currently, the only available tool is Secvisogram, a CSAF editor (this was also the only available tool when the VEX working group approved CSAF as the VEX format in the spring of 2021). It will count brackets for you and perform similar tasks, but you need a full understanding of the CSAF format in order to use the tool to create a CSAF document.

There are a small number of mostly very large organizations – including Oracle, Cisco and Red Hat – that have announced support for CSAF 2.0. However, I could only find actual CSAF files published by Red Hat (and Red Hat labels the CSAF 2.0 format as “beta”, even though it was finalized and approved more than a year ago). Presumably, those organizations have been able to make the substantial investment of time required to create CSAF advisories (I know that Cisco and Red Hat have been part of the CSAF technical committee for years).

However, CISA’s blog post didn’t limit its recommendations just to large, well-resourced companies. They clearly want all software and device suppliers, large and small, to start issuing CSAF vulnerability advisories. And this is where I see a problem: Expecting every supplier of any size, large or small, to start creating CSAF advisories without having to invest a huge amount of time learning the CSAF format requires a “CSAF for Dummies” tool. I define this as a tool that prompts the user for the information they want to represent in the advisory – the CVE or CVEs in question, the affected products and versions, remediation advice for each affected version (which might include a patch or upgrade, but might also include something else), etc. To use the tool, the user shouldn’t need to understand the details of the format; they should just be required to answer questions about what they want in the advisory.

Currently, no such tool is available for CSAF (one is under development, and evidently has been for a long time); if a supplier wants to create CSAF advisories now, they have to go Full Monty and learn CSAF well enough to be able to use Secvisogram intelligently. And there are clearly a number of required fields – like “product name” (and the related concept of “product tree”) and “branches” – whose meaning is anything but self-evident. Any supplier wishing to create CSAF documents will need to have a good understanding of the huge number of options available for creating these and other fields, as well as understand how versions are represented, which is anything but straightforward.

Second, a machine-readable advisory format, in order to be usable, requires tools that read the format. And here the story is the same: There are no tools that read CSAF documents, even a simple parser tool. There is a parser tool under development, but that’s all. And frankly, a parser tool isn’t going to do end users a lot of good. Since most medium-to-large organizations utilize some tool or tools to manage vulnerabilities on their network (the tool may go under the name “scanner”, “vulnerability management”, “configuration management”, “asset management”, and probably other names as well), just parsing a CSAF file so that it’s readable by ordinary humans doesn’t get the information into their vulnerability management tool, where it’s needed. At the moment, the user is going to have to key the information in by hand, unless they’ve created their own tool to do this.

You probably get the idea: CSAF is a machine-readable vulnerability reporting format, but currently no machine can create or read CSAF documents – which raises the question what “machine readable” means in practice. If CSAF 2.0 had just been recently released, I wouldn’t be too bothered by this fact. Indeed, I wasn’t bothered a year ago that there weren’t any tools for it, since it was then only three months since CSAF 2.0 had been approved (although it had been under development for at least a couple of years).

But to be honest, the fact that it’s a year later and there still aren’t tools available for producing or utilizing CSAF documents makes me wonder why that’s the case and when this situation will change. The VEX working group has been repeatedly assured that such tools are under development (as we were 18 months ago, when we decided to base the VEX format on CSAF); and it’s certainly true that they’re under development. But I won’t recommend that any software supplier even start learning to create CSAF documents until someone can provide me a firm date by which a CSAF creation tool will be ready (and the date had better be before say July 1, 2023. Anything beyond that isn’t a firm date; it’s a wish and a prayer).

Of course, it still won’t help when there’s a CSAF creation tool, if there aren’t also CSAF consumption tools. And those need to be something more than a parser, as described above. But I’ll cut CSAF some slack: If there’s a parser ready by next July 1 along with a CSAF production tool, I’m willing to stipulate that it might not take a huge additional effort to put together the required interfaces to vulnerability management tools (in fact, the tool vendors themselves might create them). So, by the end of 2023, end user organizations might be able to actually utilize CSAF advisories, if the production and parser tools are ready by July 1.

Getting back to the CISA blog post, it seems clear that CISA should never have advised that suppliers start putting out CSAF vulnerability advisories without also warning them that a) they need to be prepared to invest a lot of time learning the CSAF format, and b) they have to understand that currently no end user organization will be able to do anything with the advisories when they get them.

CISA’s second recommendation was “Use Vulnerability Exploitability eXchange (VEX) to communicate whether a product is affected by a vulnerability and enable prioritized vulnerability response”. So how about this? Are there tools to produce and utilize VEX documents? Fortunately, the picture is much brighter there. There is at least one open source tool now, Dependency-Track, that both creates and reads VEX documents. Plus, I know of at least one other tool today, Stack Aware, that reads VEX documents. Moreover, I’ve been told there are a number of other tools, for both creating and ingesting VEX documents, that will be available soon.

So, it seems that CISA’s second recommendation was a good one. However, there’s one small problem in what they recommended: They only mentioned the CSAF based VEX format. Since that format is just a subset of the full CSAF format (and that subset still hasn’t been spelled out, beyond a short NTIA document that I prepared the first draft of in 2021, but which I now realize isn’t complete), any tools to create or read CSAF VEX documents will need to wait on tools that do the same for all CSAF documents  – thus, what I just said about CSAF documents in general applies directly to CSAF VEX documents as well.

However, there is another VEX format. In January 2022, Steve Springett and Patrick Dwyer, co-leaders of the OWASP CycloneDX (CDX) project, surprised everyone (including me, who had by then become friends with Steve) by announcing that CycloneDX v1.4 includes VEX capability. I can confirm that the CDX VEX implementation is quite straightforward, so it doesn’t surprise me that there are already tools both to read and write CycloneDX VEX documents.

So, CISA provided great advice in their second recommendation: Software suppliers should create VEX documents in CDX format, since there are currently tools both to create and read them. In fact, the same applies to the first recommendation: The CycloneDX format can be used to create Vulnerability Disclosure Reports (VDR) just as easily as it can be used to create VEX documents. As long as they’re not committed to CSAF and nothing else, a supplier will be able to “Publish machine-readable security advisories” per CISA’s recommendation.

Funny how these things work out… 

Reminder: I'll be doing a podcast that will discuss VEX in depth on Wednesday, Nov. 30 at 10AM ET. I'll be able to discuss these issues in a lot more detail. Hope you can join me!

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.