Writing Good Legislation is Hard

It’s hard to write good legislation. Recently H.R.7900 - National Defense Authorization Act for Fiscal Year 2023 came out. It includes the following text:

At first glance, the intent seems reasonable. Vendors need to include an SBOM for their software and services, and any known vulnerabilities (according to the National Vulnerability Database and possibly other databases in the future) need to be addressed or have some sort of plan to deal with it by repairing, mitigating, or resolving it.

Unfortunately, there are several major problems with this piece of legislation, ranging from poorly or undefined terms to some truly perverse incentives being created for vendors.

The first issue is that the same rules and processes are being applied to both “end product or service” equally. An end product typically has a finite amount of software included (basically whatever it is they ship to you for installation). A service may have a nearly infinite chain behind it, e.g. many PaaS vendors (Heroku, OpenShift) run on top of Amazon AWS and rely on the services it provides (EC2, ELB, RDS, S3, etc.). The language here is unclear. I assume they want an SBOM of just the service and not underlying services it relies upon, but this isn’t clear.

A second major problem is that (currently) the NVD only regurgitates the current CVE, and CVE has a very limited focus historically. Even with growth the program still is handling less than 20,000 vulnerabilities per year. The Python PyPi library has 350,000 packages. NPM has 2 million. The world of software is well into the millions of OpenSource libraries and programs, to say nothing of the commercial worlds. Or the services world. To say only a fraction of known public vulnerabilities are included in CVE and thus the National Vulnerability Database would be a gross understatement. CVE also does not cover backdoors or other “intentional” flaws, and cloud services are only given limited coverage at this time.

Hopefully, some of the gaps with CVE and the National Vulnerability Database can be addressed by the use of additional vulnerability databases in the future. I assume they will need to be freely available like the National Vulnerability Database is (or else the vulnerability database vendor gains a large set of forced customers).

One piece of good news: there’s no mention of specific SBOM standards. Any technical standard specified may be obsolete in a few years, so this is good, and there is already some good work on current best practices from the National Telecommunications and Information Administration.

The good news: If you have a mature security and development program, you are most likely already compliant or can achieve compliance without too much additional work.

• SBOM - most vendors already generate SBOMs internally for license compliance and security vulnerability management; the only added requirement will be to provide the SBOM to the government.
• Vulnerability management - most vendors already track security issues (via submissions to them, bug bounties, watching third party sources, etc.) in the software they write and include as dependencies. The only added requirement here will be to provide information on the vulnerabilities and their remediation plans to the government.
• Shipping updates - vendors should be able to ship updates in a timely manner using efficient, automated processes where possible (e.g. build pipelines). If anything, this can be used as an opportunity to ensure that SBOM creation and vulnerability management are properly integrated so that up-to-date data can be provided to the government.

While it isn’t a given that this legislation will pass and be enacted, it is clear that the US Government (and indeed, many companies) are rapidly approaching a time where they will demand SBOMs, statements on vulnerabilities, and timelines around remediation in order to buy services and products.

The Cloud Security Alliance has a number of projects and papers that deal with these areas, such as the DevSecOps Working Group and the Global Security Database, which is aimed at providing better vulnerability information.