More guidance, but still no federal mandates on software supply chain security

First the good news: Software supply chain security has become an increasingly hot thing overthe past few years — hot enough to be a major plank in President Joe Biden’s May 2021 “Executive Order (EO) on Improving the Nation’s Cybersecurity.”

Perhaps partially because of that EO, SBOM has become one of the hottest acronyms in cybersecurity. A Software Bill of Materials, described as similar to a list of ingredients on a box or jar at the grocery, is a rigorous inventory of every component in an organization’s software supply chain. The idea is to keep track of everything you’re using — who made it, where it came from, whether it’s maintained and up-to-date or has been abandoned.

Which is a very worthy goal because, as has become a mantra at security conferences, you can’t protect what you don’t know you have. Experts agree that while an SBOM isn’t all you need for rigorous software supply chain security, it’s essential.

Indeed, the Biden EO calls for every software product purchased by federal agencies to come with an SBOM.

And now, just in the past couple of weeks, the National Security Agency (NSA) has issued some major guidance: “Recommendations for Software Bill of Materials Management.” The 14-page document is aimed at both creators and consumers of software to “ensure the authenticity, integrity, and trustworthiness of software products.”

All good. But it should all be tempered with the reality that these come with a number of caveats. Among them: The deadlines for compliance with the SBOM portions of the Biden EO, now coming up on its third anniversary, remain rather elastic. As in, they haven’t taken effect. They keep getting postponed. So far there is still no official ban on federal agencies buying software products without SBOMs. There is plenty of advice but no mandates.

This current document comes just two months after the NSA, along with the Cybersecurity and Infrastructure Security Agency (CISA) and the Office of the Director of National Intelligence issued recommended best practices for software vendors and suppliers on securing the software supply chain. Again, guidance, not requirements.

And the caveat in this latest NSA document is right in the title. These are recommendations., Nobody, at least not yet, is required to follow them.

Attack surface with many links

Which, coming up on three years since the Biden EO, is not so good. The need for requiring better cybersecurity supply chain risk management (C-SCRM) is obvious. As reported here and just about everywhere in the tech press, vulnerabilities in software products that are used by thousands, millions, or even billions of people and organizations can amplify the potential profit (for hackers) and the damage (to victims) exponentially when they are exploited. The first line in the executive summary of the NSA document refers to a “dramatic increase in cyber compromises over the past five years, specifically of software supply chains…”

One of the most notorious examples is the group of vulnerabilities labeled Log4Shell in the open source Apache logging library Log4j. They were present in billions of systems, services, websites and devices when they were discovered in December 2021. If you used Log4j anywhere in your organization, you were vulnerable.

At the time, CISA Director Jen Easterly called Log4Shell “one of the most serious [vulnerabilities] I’ve seen in my entire career, if not the most serious.”

Michael White, technical director and principal architect with the Synopsys Software Integrity Group, wrote in a blog post at the time that it’s “trivial [for hackers] to execute,” adding that it amounted to “a classic iceberg. There are 3 billion devices that run Java and Log4j is a very common logging library,” he wrote.

One good result of that potential disaster is that it raised awareness of the value of SBOMs. With an SBOM, an organization can simply conduct a database search to know if it’s using a library like Log4j.

That ought to be standard — not just a recommended best practice, but a requirement. Because as has become a cliché over the past decade, every business is a software business. It increasingly runs everything in modern life, from communication to transportation, entertainment, infrastructure, home security, and much more.

It’s why SBOMs have been on the radar of the federal government for a while. Indeed, the Biden EO on cybersecurity was issued six months before the discovery of the Log4Shell vulnerabilities.

But, as noted earlier, the NSA document isn’t meant to enforce that EO or any regulations coming from it.

Tim Mackey, head of software supply chain risk strategy within the Synopsys Software Integrity Group, noted that “nothing in this is regulation or legislation, and there is no guarantee that any of this aligns with anything any other entity, public or private, puts out.”

That, of course doesn’t mean the NSA guidance isn’t well-intentioned. It recommends “measures to strengthen the resilience of supply chains for software used throughout government and critical infrastructure… [to] ensure the authenticity, integrity, and trustworthiness of software products.”

That requires knowing how to “manage SBOMs as part of a [C-SCRM] strategy,” according to the NSA.

But then comes another caveat — C-SCRM strategy is still evolving. As the document puts it, “standards and best practices are evolving, but no single solution, or set of solutions, has become ubiquitous yet.”

With that disclaimer, the NSA divides the guidance into three categories:

• Risk management: Determine the authenticity, completeness, and trustworthiness of software being acquired and used. That includes comparing any risks against the mission’s risk profile to determine the software’s suitability.
• Vulnerability management: IT security teams become more proactive by identifying and resolving vulnerabilities before they can be exploited.
• Incident management: Reduce the organization’s overall risk exposure, whether that is through procurement or operationally, once an incident has occurred.

That is followed by general guidance to software suppliers and then to consumers. Among recommendations for suppliers is for both the public and private sectors to “expand SBOM research to better understand the minimum requirements for an SBOM to be beneficial, and share best practices to standardize solutions for other technology platforms susceptible to cyber supply chain attacks (for example, operational technology, cloud/SaaS operations, hardware/firmware).”

There is also an exhortation for software developers to “take ownership of their customers’ security outcomes rather than treating each product as if it carries an implicit caveat emptor.”

For software consumers, the NSA recommends the use of nearly a dozen existing resources including the Secure Software Development Framework and the Software Component Verification Standard.

Finally, there is a lengthy list of recommended functionality for tools used to create, manage, and maintain an SBOM. According to the NSA, the recommendations are based on “research and evaluation of various SBOM management tools.”

But that comes with some caveats as well — the agency doesn’t name any of those tools and notes that, “Many current tools do not include all the functionality listed below.”

While software composition analysis (SCA) tools are well-established and useful for helping create SBOMs, since they find open source components in software products, along with any known vulnerabilities and potential licensing conflicts, they don’t do it all.

The agency declined to provide any specifics about the tools it said had researched and evaluated. “We have nothing for you on this,” NSA public affairs officer Edward Bennett wrote in an email response.

All of which means the NSA’s list of 49 recommended capabilities grouped under 14 categories may be more aspirational than realistic.

The categories include capabilities for SBOM input and output, component handling, validation of SBOM components, vulnerability tracking and analysis, user interface capabilities, configuration, and setup.

But again, this is all advice, not requirements. Mackey noted that the Enduring Security Framework (ESF) is also providing guidance on SBOM creation and management. The ESF is a partnership of experts from the U.S. government, information technology, communications, and defense industrial base sectors that deals with threats to U.S. national security systems and critical infrastructure.

Which suggests that it might make sense for the NSA and ESF to collaborate, so guidance and recommendations on SBOM management won’t be fragmented and come with so many caveats.

Not to mention that after nearly three years of carrots from government, it might be time for a stick.