On September 2022, the United States Office of Management and Budget (OMB) issued a landmark memo regarding the steps needed to secure your software supply chain to a degree acceptable by the US federal government. Any company that wishes to do business with the government and any federal agency producing software needs to comply with the requirements and timeline put forth in the M-22-18 memo.
M-22-18 focused on the security and integrity of the software supply chain, paying particular attention to the role of SBOMs. It included a list of requirements and a timeline for implementing the needed steps for compliance.
The memo established two main documents produced by NIST: the Secure Software Development Framework (SSDF), SP 800-218, and Software Supply Chain Security Guidance as NIST’s guidance on secure software development. The memo also outlines software producers’ responsibility to self-attest to their compliance with NIST’s guidance before federal agencies are free to use their products. This self-attestation is to take the form of a signed self-attestation “common form”. Three categories of software require this self-attestation form: new software purchases, major version upgrades, and software renewals.
M-22-18 required CISA to establish this standard self-attestation “common form” within 120 days from the date of that memorandum (September 14, 2022). Those 120 days have passed in January 2023 but the form is still in draft form even though the comment period for it closed on June 26, 2023. That is roughly when the OMB Memo originally directed agencies to begin collecting attestations for critical software.
Based on some of the comments received for that common attestation form, OMB saw fit to release an amendment to M-22-18 on June 9, 2023. This amendment is titled M-23-16. The new memorandum extends the timeline published on M-22-18 for agencies to collect attestations from software producers. Agencies are now required to collect the self-attestation “common form” from software producers for “critical” software no later than three months after the CISA common self-attestation form is approved by OMB. All other software producers have six months after the self-attestation form is approved by OMB.
Since this standard self-attestation form appears to be taking center stage, let’s examine what is included in it in a little more detail. We’ll also look at who exactly is meant to sign it and what would such a signature mean.
Secure Software Self-Attestation Common Form
Following the chain of regulation from EO 14028 to NIST’s guidance papers to the OMB memos, it’s clear the government aims to protect everyone, both federal agencies and private sector companies, from software supply chain vulnerabilities and intrusions. Since the private sector hasn’t done enough about it (in the government’s view) the government has set out to create new regulations that everyone (who sells to the federal government) has to follow.
Of course, even if you don’t sell to the federal government (yet) it’s in your best interests to follow these rules and self-attest you’re ‘secure’ since such companies are going to be a more attractive business partner. Who would want to do business with a company that can’t confirm they’re doing everything they can to protect their product and users?
Since we already established that the NIST guidance is the basis for the new regulation and best practices it’s no surprise that the same suggestions that appear, for example, in the SSDF appear in the self-attestation form as well.
Here’s a short example from the draft document:
Taken from the Secure Software Self-Attestation Common Form draft
We can see the requirement on the left followed by the related EO section and then by the SSDF practices and tasks. This is a pretty comprehensive list of requirements (a page and a half) that would not necessarily be fully clear if the reader is not in the business of cybersecurity and/or DevOps or DevSecOps.
The document requires the signee for the company to PERSONALLY attest that all requirements outlined in the form are consistently maintained and that the company will notify impacted agencies if any element on the list is no longer valid.
The document doesn’t specify who in the company is supposed to sign the document but as this form is the requirement for the company to do business with the federal government and its agencies it stands to reason that the CEO is the person who should take responsibility here. The CEO will probably not sign it blindly and ask their CTO and CISO to verify (possibly in writing) that the company does follow all these guidelines and requirements.
Since there is no established product or mode of operation to collect and attest to all these requirements, in a sense each company signing needs to ‘re-invent the wheel’ for itself and hope that nothing bad happens.
If something bad does happen then the federal government would go after the signee to show and prove that they can back up all the forms’ requirements.
What Happens If I Don’t Sign?
First, this whole attestation thing is currently only relevant if your software is being used by a federal agency, if you intend to sell your software to the federal government, or, if your software is being used by a vendor whose software is either in use or is intended to be sold to the federal government.
Notice I said ‘currently’ since there is every indication that SSDF compliance, either as a self-attestation or in some other verifiable form, is going to become a new ‘best practice’ in the field of software production.
So, assuming that your company falls within the group mentioned above and you can’t find your way to sign this document with a clear conscience, all is not yet lost. As long as you can explain where the attestation shortcoming is and offer a satisfactory Plan of Action and Milestones (POA&M) the federal agency in question can still buy/use your product and pursue an extension for your software on your behalf from OMB.
The bad news is that with or without a POA&M plan you’ll eventually need to provide a full attestation form which means you need to be able to verify to a federal court that all steps required by the form were followed by your company and that your software development process is at least as secure as the form’s requirements.
The only software that is currently exempt from this form of attestation is federal-agency-developed software and freely available software, AKA open-source software. Of course, most software supply chain security holes can be traced in some way to some open-source package in your code but there is a real issue in trying to force open-source developers and maintainers, who work for free, to provide a legally binding guarantee for their software. It should be up to anyone using open-source software to verify its safety both in general and when it comes to the software it’s embedded into in particular.
Worse Case Scenario
This whole software supply chain security conscientiousness started after the famous SolarWinds hack. Without going into too many details, at the time of the hack, more than 18,000 clients of the company were impacted including 9 federal agencies.
It’s only now, years later that we’re starting to see some of the legal results from this incident. The SEC, U.S. Securities and Exchange Commission, is going after the company as a whole as well as after several C-level executives. This can be seen as an example of the government’s intentions should such an incident or a similar one befall a software producer who attested to their secure development practices and yet fell victim to a hack.
In the case of SolarWinds, the company is fully backing up any employee who gets targeted by such legal action. Knowing the U.S. legal system, such cases are likely to take years and cost a lot of money. Fines are not out of the question and could reach sums in the millions based on an estimation of the damages suffered.
You can imagine that not all companies, particularly small and medium ones, are as staunchly protective of their employees as SolarWinds is. The problem is that if the accused party is the company’s CEO there’s a real chance that market trust in the company and its product is going to severely suffer. Facing the SEC without the backing of a large company with deep pockets could ruin an unsuspecting CEO as well as their company. Of course, the intent is to get people to take their responsibility to secure development seriously but the fear may get people to err on the side of self-preservation. That means that people would rather hide cyber security incidents if they think they cannot win a potential SEC case or they worry the cost and bad publicity of such a case would be so severe that it’s better to hide them regardless of the court case outcome.
How Can I Sign?
The NIST SSDF guidance is full of suggestions and best practices but light on practicalities. Since each company is unique, it’s quite difficult to bring forth a product or system that would work for everyone. In this case, the private sector is stepping in to fill the vacuum, creating an ecosystem to help you follow the requirements.
For example, Scribe built a platform based on the concept of creating attestations, signing them, and offering the ability to verify them. We’ll soon release a document tailor-made to the CISA self-attestation form, demonstrating how the Scribe solution can help you in each section of the requirements. Stay tuned.
Trying out Scribe’s platform is free. I encourage you to give it a try and see how you can fit the platform to your requirements and sign CISA’s self-attestation form with a clear conscience at the same time.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
