Want to sell software to the feds? You’ll have to build it better and swear in writing that you did

If you want to sell software products to the U.S. government, starting sometime later this year (maybe), you will not only have to follow a prescribed set of security standards in building it, you’ll also have to swear in writing that you did so.

It’s called “attestation” — the feds’ latest move in a decades-long slog toward improving the security of the software products it buys.

Which is more than welcome, but also long overdue. Federal agencies including the National Institute of Standards and Technology (NIST) and the General Services Administration (GSA) have been issuing memos, standards, and guidance documents on the problem of unsecure software at least since 2008.

Meanwhile, presidents going back to Bill Clinton in 1996 have all issued executive orders (EOs) on cybersecurity, which include calls to make software products more resilient and secure. Yet here we are, 27 years and more than a half-dozen EOs later, with porous software still a significant problem.

As Sammy Migues, founder and principal of Imbricate Security, put it, securing federal government software “has been a discussion topic for at least 40 years and on a slow boil for at least 15 years, which has led to a deluge of guidance.”

From guidance to mandates

But now it looks like the feds are moving from guidance to mandates. Attestation is a component of a cybersecurity strategy document from the Biden administration labeled “acquisition reform,” which isn’t a new concept either. The Department of Defense and the GSA issued a report nearly a decade ago calling for the same thing.

But the idea remains relevant. It comes down to the government declaring to vendors, in essence, that “if your software products aren’t secure, we won’t buy them.” And the federal government is a big enough customer that such a threat, if carried out, can change both the public and private software security landscape. Call it trickle-down security.

The impending requirement for vendors to attest that they have built their software in compliance with security standards set by the NIST Secure Software Development Framework (SSDF) would give it some legal teeth.

Attest, according to Merriam-Webster, means to “testify to the truth or genuineness of something.” Which is a lot like being under oath.

Indeed, the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) draft version of attestation form instructionsnotes that “providing this information is mandatory […] Willfully providing false or misleading information may constitute a violation of 18 U.S.C. § 1001, a criminal statute.”

Tim Mackey, head of software supply chain risk strategy within the Synopsys Software Integrity Group, wrote in a recent blog post, that the requirement to comply with the NIST SSDF is “a big deal, and if your development teams haven’t been following the guidance in the SSDF, or some of the frameworks the SSDF directly references, then it’s going to be hard to self-attest to conformance with it.”

But bureaucracy …

There is still a bureaucratic process to go through before this takes effect, however. CISA announced last week the start of a 60-day public comment period on that draft attestation form. How much those comments will modify the form or extend the time before it takes effect nobody knows.

But the current draft security requirements, based on NIST standards, include

• Developing software in secure environments
• Enforcing multifactor authentication
• Limiting access to minimize security risks
• Maintaining a secure software supply chain, which includes keeping components up-to-date
• Creating elements of a software Bill of Materials (SBOM) to document every component in an application including who made it, when, where, what licensing restrictions exist, and whether it has any known vulnerabilities.
• Using automated tools or their equivalent to test software for security vulnerabilities

The goal, according to CISA, is to “reduce the number of vulnerabilities in released software, reduce the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and address the root causes of vulnerabilities to prevent recurrences.

What are the chances that attestation will help put those goals within reach?

If history is any guide, it depends on whether what is proposed gets implemented, and how rigorously. As noted earlier, software vendors have been awash in a growing pile of recommendations, memos, standards, guidance, and orders going back decades — many of them calling for much the same as what is on the table now.

Indeed, Migues noted that President Biden’s May 2021 EO on cybersecurity has generated, among other things, “the NIST SSDF, OMB [Office of Management and Budget]-22–18, GSA Acquisition Letter MV-23–02, and this latest CISA Secure Software Development Attestation Form. It’s a lot.”

Within that form, he said, there are “31 SSDF tasks called out of 42 total. The government considers those 31 to be the minimum. And those 31 tasks break out into more than 150 ‘examples,’ more or less all of which will apply in any large organization. Again, it’s a lot.”

But he said an attestation form “that becomes part of the contractual paperwork is powerful, especially when signed by the CEO or designee and under the guidance — one hopes — of legal counsel.”

Mackey wrote that eventually all of the NIST SSDF tasks are likely to be required. So just because only about 75% are explicitly required now “doesn’t mean that you shouldn’t be building a plan to fully follow the SSDF.”

When this will actually take effect, however, falls into the “remains to be seen” category. The bureaucratic process inevitably comes with wiggle room — things like extensions, waivers, and exemptions. According to the GSA, it intends to start collecting attestations from existing federal software contractors by June 12, but Migues doubts many of them will be ready to sign them.

“Of the many thousands of software suppliers to the federal government, very few will be ready to do so that soon,” he said. “Everyone will ask for an extension while they ask many, many questions.”

Go smaller?

That may indicate that the government is trying to do too much all at once. Migues noted that the mammoth “Consolidated Appropriations Act of 2023” (1,653 pages), otherwise known as the “omnibus” bill, which passed at the end of 2022, contained a provision on the security of connected medical devices. While it doesn’t call for a formal attestation, a vendor applying to sell such devices “shall include such information as the Secretary may require to ensure that such cyber device meets the cybersecurity requirements …” the law states.

“The government did in that one small space what they’re now trying to do for all software they buy,” Migues said. “Maybe medical device software still has its problems, but the suppliers deserve credit for making current software way better than it used to be.”

He added that similar improvements have happened in the payment card industry. “Draw a frame around a problem and address it. That’s driven massive improvements over the years. In this case, the government drew a very big frame and it’ll take a lot of pushing to build some momentum,” he said.

But it’s still a worthy initiative, Migues believes. “Yes, this clarification process will push things out, but it’s a slower-than-desired start on the right road versus the ‘It passed most functional tests! Ship it!’ wrong road we’re on today.”