Cyber-Readiness and Changing Federal Government SBOM Requirements

Editor’s note: This article was originally written in March 2023, and all data and details in the post were current as of that timeframe.

From IC Insider Sonatype

By Cate Richards

Almost two years ago, President Biden’s Executive Order 14208, “Improving the Nation’s Cybersecurity,” was signed. This major step toward regulating the software supply chain in the US was spurred by the software supply chain attack on SolarWinds and since underlined by the critical Log4j vulnerability, Spring4shell vulnerability. In addition to countless others that haven’t received press coverage.

The White House mandate selected the NIST cybersecurity framework as the governing system for software development within the federal government. Crucially, it also applies to any companies selling software to the federal government.

One key guideline from NIST is a new requirement to use a software bill of materials (SBOM), which would document an inventory of all third-party components used inside any given application. After all, if you don’t know what software was used to build your software, you can’t address critical software vulnerabilities that are finding their way into major projects.

But this effort was only a first step in the goal of securing the software supply chain. We’re seeing additional regulatory next steps beyond merely gathering SBOMs.

2023 deadlines for federal agencies

The mandates from the Executive Order came to a head in a September 2022 memorandum from the Office of Management and Budget (OBM), “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices” (M-22-18). The order requires federal agencies to comply with NIST guidelines.

Specifically, the OBM requires:

• Self-attestations from software producers for critical software by June 11, 2023.
• Self-attestations from all other providers of software used by the federal agency by September 14, 2023.
• Obtaining an SBOM from software producers or a similar artifact that demonstrates conformance with secure software development best practices.

For many, a race against time has begun to adhere to these mandates — something that would simply check the box to ensure compliance. Though the debates around SBOMs continue, there is a continued march towards meeting the requirements for many.  While this is an extremely important step, we’d like to urge everyone to think critically about what’s going to come next.

Beyond SBOMs: planning for expanded regulations

More policy and format changes

In March 2022, the Biden-Harris administration released its National Cybersecurity Strategy, which proposed a number of sweeping changes. Including introducing cybersecurity liability and holding software providers responsible.

While many in the industry are playing the “wait and see” game to determine if any of those proposals will actually become law, there are already key changes and reforms taking place that we need to be talking about. Two of those major topics we expect to see in the coming year point to similar efforts to secure the software supply chain. These include:

• Zero-day vulnerability management policy to handle the next Log4j-level issue. CISA (DHS) has, for example, a vulnerability management playbook, where if there’s a cyber incident of quantitative measure, you must report it within 72 hours.
• Continuous monitoring for all software in use.

These are seen as next steps to address clear triggers for definitive action.  Just documenting components without watching for discovered vulnerabilities or having a plan cannot prevent rapid exploits.

In addition, both of the most common SBOM standards, SPDX and CycloneDX, are in active development and will likely see new releases within the year.

The path ahead needs to be cyber-readiness

An article by former DoD executives explains that an approach to cybersecurity based on frameworks and checklists is inadequate.  To sustain cybersecurity, we must see it as a problem of readiness and currency rather than simply meeting a compliance checklist.

The checklists and mandates can be the guardrails that propel action to happen with a roadmap to a minimum standard of care. However, unless the practice is focused on the mission and objectives, and incorporated into the practices and processes, sustainability becomes hard to achieve.

We expect recommendations approaching the government and other “critical infrastructure” industries like healthcare and automotive (particularly with self-driving cars) that push sustainable success to focus more on readiness and mission of the agency. In these cases, the SBOM become twofold:

1. Systems of record
2. Systems of control

We spend a lot of our time educating people in the industry that it’s more than just meeting the checklist. Effective cybersecurity needs an approach that includes software lifecycle management, and to be incorporated into the overall processes of the program.

Complex software systems need a more thorough approach

High-tech efforts increasingly rely on a huge amount of software from a long list of sources, which requires a more complete SBOM solution.

For example, one large Sonatype customer is currently looking at addressing challenges around a series of highly specialized products. With software from over 1,000 sources and individual product variations, they struggle to manage an already sophisticated landscape.

All that adds up to very different products, code, and requirements, even as they use the same basic structure. Tracking and managing all of these sources for possible issues or vulnerabilities is a difficult and ongoing task.

Take action towards cyber-readiness

Organizations merely at or below current regulatory requirements are at a competitive disadvantage. Those who count the federal government as a customer have put energy into creating SBOMs to meet the upcoming requirements. But rather than stop there and plan for the strategic use of SBOMs so you can leverage them for readiness and as a value-added benefit in your business or agency.

What to consider in an SBOM solution

Whether you are still determining how to use SBOMs, or if you are using them now, make sure it includes features able to address upcoming changes, including:

• Analysis of the contents for good and bad components, usually known as Software Composition Analysis (SCA)
• Continuous monitoring for newly discovered vulnerabilities
• Management policy to address and resolve zero-day vulnerabilities

Invest in software management tools that keep up with ongoing changes in SBOM formats, the software industry, and regulation.

For major software projects with components from multiple sources, you need more than basic tools. If your organization is in this space (as with our customer example) or moving towards it, look at SBOM management tools that can not only produce SBOMs, but also to consume 3rd Party SBOMs to status and continuously monitor them.

Cybersecurity that meets the mission

Over the coming years, multiple groups, both in the US and internationally, will define and redefine what an SBOM is and what it does. Work with a partner who will stay on top of these changes so you’re always in compliance.

Being prepared means better security and more business.  Customers are looking for groups that have built and maintained good design principles.

Sonatype can make sure that whatever changes happen that you’re prepared. To see our products in action, request a demo today.