It’s Time to Bite the Bullet for More Secure Software

The newly released M-22-18 memorandum from the Office of Management and Budget poses new considerations for federal agencies and organizations alike. The US government is an enormous consumer of software and software-containing products, so it’s reasonable to suggest that this is the minimum bar for what software developers should be doing to address security concerns about their software products.

On September 14, 2022, the Office of Management and Budget (OMB) released their M-22-18 memorandum on “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices.” This document builds upon previous government documents such as Executive Order (EO) 14028 (“Improving the Nation’s Cybersecurity” from May 12, 2021), the NIST Secure Software Development Framework (SSDF) SP 800-218, and the NIST Software Supply Chain Security Guidance and starts to mandate how the earlier documents are to be operationalized by US federal agencies and, in turn, their software suppliers.

The scope of the mandate is very broad. It applies to any new third-party software procured by agencies as well as software that goes through a “major version change.” Over time, this will apply to pretty much all third-party software in use at federal agencies. In addition, “software” in this context “includes firmware, operating systems, applications, and application services (e.g. cloud-based software), as well as products containing software.” So pretty much any software and any of the increasingly software-dependent devices these agencies are procuring.

Though these mandates are limited to organizations that supply software to US federal agencies, the US government is such an enormous consumer of software and software-containing products, for most software developers it is reasonable to look at this as the minimum bar for what they should be doing to address security concerns about their software products.

What does this mean for federal agencies?

The requirements for the agencies fall into two major areas: creation of their software portfolio and management of their third-party software producers’ attestations and Plans of Actions & Milestones (POA&Ms) addressing deficiencies in their secure software development practices.

Looking at the second requirement first, hopefully most agencies will find this to be a tractable problem to solve. This is an administrative task – collect attestations from third parties and track the resolution of situations where those attestations are insufficient. A lower-tech approach to this would be to use document repositories and Excel spreadsheets with vendors and their statuses. Hardly elegant, but probably not the worst technology situation you would find in a large bureaucratic agency. More advanced agencies with elaborate and mature software procurement practices may be able to slipstream this tracking into existing systems and procedures, but for most agencies this should be straightforward, if annoying.

The real challenge for many agencies will be to credibly enumerate all the third-party software they have in use – especially given the broad definition of software systems that fall under this mandate. Both private and public sector organizations have found this problem challenging, and an entire segment of the security industry has sprung up to address concerns about attack surface management (ASM). Coalfire has services that help organizations identify external attack surface – especially web application attack surface – and those are a starting point toward developing and maintaining an even more comprehensive inventory.

As part of this inventory process, agencies also need to designate the software packages they consider to be “critical” based on the guidance in M-21-30. These vendors and packages may be required to provide additional documentation – such as Software Bills of Materials (SBOMs) – demonstrating compliance with their self-attested practices and the software may be subject to additional testing.

What does this mean for organizations developing software for the US federal government?

For software developers, I see two major ways to interpret this document from OMB:

1. Just do the minimum because most of the hard stuff is optional

Reading through the document, there is currently a lot of wiggle room. For example, agencies do not need to apply these requirements to software developed in-house. Also, self-attestation is a broad requirement that allows software developing organizations to fudge on requirements – if not outright cheat. And a lot of the “harder” requirements such as publishing SBOMs or performing application threat modeling are optional or only required for “critical” software. In situations where software developers cannot attest to certain practices, they can adopt a POA&M to kick the can down the road for a period of time. In the short term, organizations that want to make few or no changes to their security practices will likely be able to squeak by with limited inconvenience.

2. Let’s bite the bullet because eventually this mandate will expand

That said, taking a longer-term view of where this latest mandate fits into the progression of federal cybersecurity efforts in general, and software assurance efforts specifically, it is reasonable to expect that currently optional activities like publishing SBOMs and performing threat modeling will become required over time. Or that one or more agency customers will decide that a provider’s software meets the criteria for being considered “critical” and thus subject to more stringent requirements. From this perspective, it makes sense to be proactive in meeting the more stringent requirements to avoid procurement delays if a new agency decides to apply more aggressive criteria.

All that said, I’d propose a third approach:

3. If we are running a sensible software security program, this is actually really easy

A good risk-based software or application security program will meet or exceed all these federal requirements, and it should be trivial to extract the required artifacts in the normal course of business. NIST’s recommendations are hardly revolutionary – they specify things like security requirements, threat modeling, and xAST scans. None of these are considered state-of-the-art in a modern risk-based secure development program. In fact, they are table-stakes. Rather than narrowly trying to address a specific set of compliance requirements, leading organizations build application security programs based on the risks their software and software-enabled services are likely to face in production environments. This makes the software more resilient to attacks and has the benefit of throwing off the required artifacts to address common concerns from both federal and private sector customers. Coalfire offers a comprehensive set of advisory services for organizations at any stage in the rollout and evolution of their application security programs, and these can easily be targeted to incorporate meeting and exceeding federal procurement requirements.

The recent OMB mandates are just the latest in a growing body of work from the federal government looking to address critical security issues in the software systems used by federal agencies. Given the purchasing power of the United States, software developers need to expect to address these requirements. Fortunately, building out a risk-based application security program should allow them to meet and likely exceed current and future federal procurement mandates.