The feds may no longer buy your software if you don’t swear it’s secure

Starting sometime later this year, if you want to sell a software product to the U.S. government it won’t be enough to smile, shake the hand of the agency’s purchaser, and say you’ve built it in compliance with required best practices for both quality and security.

You’ll have to swear to it. You know, like in court — so help you God.

OK, it’s a bit less formal than that. It’s called attestation. You can do it by filling out a form. But legally it’s much the same — a statement made under oath. If you don’t tell the truth, you’ve committed a crime.

The Secure Software Development Attestation Form, published March 11 by the Cybersecurity and Infrastructure Security Agency (CISA), is momentous on another level as well. It is the first of various orders (they all use the word “shall”) in President Biden’s May 2021 Executive Order (EO) on Improving the Nation’s Cybersecurity (otherwise known as EO 14028) to have yielded a result that directly affects the software industry.

The Self-Attestation form is shaped by guidance from the Office of Management and Budget’s (OMB) Sept. 14, 2022 memo M-22–18, amended by a successor memo M-23–16 on June 9, 2023. The form’s publication sets a deadline to complete the form of 90 days for any providers of software for use in government critical infrastructure, and 180 days for all other providers of software to federal agencies.

You could say it’s about time. Even if those deadlines hold, they will take effect more than three years since the EO, which set numerous deadlines, most of them a year or less, to implement practices designed to improve the security of the software supply chain.

But then, you could also say that getting any major provisions of a presidential EO implemented during that president’s time in office is an impressive achievement. Starting more than two decades ago, Presidents Clinton, Bush, Obama, and Trump have all issued EOs or launched initiatives on cybersecurity, and while some of them have led to significant achievements — among them the creation of CISA — it would be a stretch to say they were all implemented as written. Since presidents can’t create laws—at least not directly—perhaps EOs could more accurately be called Executive Aspirations.

The long-term effect of this EO remains firmly in the “remains to be seen” category. But the arrival of the attestation requirement clearly adds a level of urgency to improving the security of software used by the government. This is not a recommendation, as has been the case so far. It’s a mandate.

That means for those that want to sell to federal agencies, there are penalties for noncompliance. The completed form must be signed by someone within the software provider’s leadership team — the CEO or designee — and false statements are punishable under 18 U.S.C. § 1001, a criminal statute.

There is an alternative to self-attestation. But it carries the same legal weight. A software producer can hire a third party to document that a product conforms to the security requirements. That third party has to be part of a “Third-Party Assessor Organization that has either been FedRAMP [Federal Risk and Authorization Management Program] certified or approved in writing by an appropriate agency official,” according to the CISA instructions.

Procurement leverage

And while, as noted, the attestation requirement applies only to software products sold to government agencies, if it works as intended it should promote better software security in the private sector as well, through so-called “procurement leverage.”

The hope is that requirements for more-rigorous security to be built into software sold to federal agencies will prompt vendors that spend the money and time to qualify will be more likely to include those same improvements into what they sell to everybody else.

Whether it will work as intended also depends in part on several caveats. Because as is the case with virtually everything involving government, the form contains various exemptions and waivers. For starters, it applies only to software products made or updated in a major way since Sept. 14, 2022. Obviously, a lot of existing software — much of it now in use within the federal government — was created before September 2022.

Second, the form isn’t required for

• Software developed by federal agencies
• Open source software that is freely and directly obtained by a federal agency
• Third-party open source and proprietary components that are incorporated into the software end product used by an agency
• Software that is freely obtained and publicly available

Those last three are exempt because free software doesn’t require a contract — therefore it can’t bind an entity to a procurement agreement.

Third, there are provisions for waivers. According to the CISA instructions, “if an agency cannot obtain a completed Self-Attestation from the software producer, an agency may still decide to use the producer’s software if the producer identifies the practices to which they cannot attest, documents practices they have in place to mitigate associated risks, and submits a plan of actions and milestones to the agency.”

Software providers not affected by waivers or exemptions are required to follow a subset of 42 practices contained in the National Institute of Standards and Technology (NIST) Secure Software Development Framework and the NIST Software Supply Chain Security Guidance. That is in response to the Biden EO’s call for NIST to issue guidance “identifying practices that enhance the security of the software supply chain.”

No SBOM required

One thing not required by the form, even though it was mentioned nearly a dozen times in the Biden EO, is for all software products sold to the federal government to include a Software Bill of Materials (SBOM)—something experts agree is a crucial element for securing the software supply chain. The purpose of an SBOM is for both the creators and users of a software product to know everything about it — who made it, where, when, who maintains it (or not), what other components it relies on to function (dependencies) and if it has any vulnerabilities or licensing requirements.

An SBOM requirement could possibly come later, since the form could still be modified. So far, the form’s requirements for the software itself include

• The product’s name, version number, and release/publish date.
• The software producer’s information, including company name, location, and website
• Numerous specific requirements to ensure that the software is developed and built in secure environments.

Among requirements for the software producer are to

• Make a good-faith effort to maintain trusted source code supply chains by employing automated tools or comparable processes to address the security of internal code and third-party components and to manage related vulnerabilities
• Maintain provenance (origin information) for internal code and third-party components incorporated into the software to the greatest extent feasible
• Use automated tools or comparable processes that check for security vulnerabilities not just to build the software but also on an ongoing basis and prior to product, version, or update releases
• Have a policy or process to address discovered security vulnerabilities prior to product release
• Operate a vulnerability disclosure program that accepts, reviews, and addresses disclosed software vulnerabilities in a timely fashion and according to any timelines specified in the vulnerability disclosure program

While that list may seem daunting, as noted, none of those activities break any new security ground. Any conscientious organization should be doing them already. Tim Mackey, head of software supply chain risk strategy within the Synopsys Software Integrity Group, noted in a recent blog that for vendors that have already incorporated those recommended best practices into their software development, “attesting to the elements in the Self-Attestation form should be simple.”

But even if it is not so simple and feels like government is using the “stick” approach, keep in mind that it has been using the “carrot” approach for decades. And building better, more trustworthy software will yield benefits — fewer repairs/updates, and potentially greater market share. Not to mention that you’ll be able to put the federal government on your prospective customer list.