M-22-18 asked producers to sign; agencies first had to know who they were
OMB’s secure software memo made a producer’s signed attestation a condition of federal use. The form drew the attention. The work that lasted was the producer-level inventory behind it and the judgment needed to use what came back.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On September 14, 2022, the Office of Management and Budget issued memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices. Implementing Executive Order 14028 of May 2021, it directed federal agencies to obtain a self-attestation from the producers of software they use. Producers were to confirm that it was developed in line with NIST’s Secure Software Development Framework (SP 800-218) and related guidance. Agencies could require further artifacts, such as a software bill of materials, where risk warranted. They could accept a plan of action and milestones from producers not yet able to attest. The memo set deadlines for collecting attestations, critical software first, and asked CISA to develop a common attestation form. Those deadlines were later extended.
Federal software security had long focused on systems after they were built: authorizations to operate, control assessments and continuous monitoring. Executive Order 14028, written after the SolarWinds compromise, added accountability for how software is made in the first place. M-22-18 was the mechanism, and it worked through procurement rather than new technical controls. Earlier in this series we looked at how the Justice Department’s civil cyber-fraud initiative attached False Claims Act risk to security representations made to government. M-22-18 multiplied the number of such representations.
For agency CIOs, contracting officers and program directors, the memo created three jobs, done in sequence by different people. The first was an inventory that recorded who produced each piece of software. The second was collecting attestations through contracts. The third was using what came back to make risk decisions. Most attention went to the second. The first and third determined whether the exercise was worth doing.
Knowing who made the software
An agency cannot ask a producer for an attestation without knowing it uses that producer’s software. That sounds trivial and was not. Software reaches agencies through direct purchases, enterprise agreements, reseller contracts, cloud services, code embedded in hardware, and components inside systems that integrators build. Asset management tools tracked licenses and devices. Many did not record the producer behind a reseller’s line item, or the version actually running.
The inventory also had to sort scope. Agency-developed software and freely obtained open source were treated differently from purchased products. NIST’s 2021 definition of critical software, covering categories such as identity and access management, operating systems, browsers, endpoint security, network control and backup, set the first wave. Mapping holdings against those categories told an agency which producers to approach first and how many there were.
Building that inventory was the hardest part for many agencies, and the most valuable. It was the same list needed to answer whether a newly disclosed flaw affected the agency, to plan renewals, and to find duplicate products bought by different offices. An agency that built it for M-22-18 had built it for several other purposes at once.
The practical method was to start from money rather than machines. Payment and contract records show which suppliers the agency pays, and resellers can be asked to name the producers behind each line item. Scanning tools then confirm what is actually installed. Reconciling the two lists exposes shadow purchases on one side and unlicensed or forgotten software on the other. Neither list alone is complete.
Collecting the attestations
Collection is a contracting task. It needs clauses that make an attestation a condition of award or renewal, a process for sending requests and tracking responses, and rules for producers who cannot attest. The memo let agencies accept a plan of action with milestones, and in some cases seek extensions or waivers. That flexibility was sensible. Many smaller producers had never documented their development practices against a formal framework, and some sold niche products no one else made.
Flexibility needed limits. Contracting officers needed guidance on which gaps were acceptable, for how long, and who signed off. Without it, plans of action risked becoming permanent substitutes for attestation. A simple register of open plans, with milestone dates and the program office responsible, kept them visible.
Duplication was the other problem. A producer selling to dozens of agencies should not complete dozens of different forms. A common form and a shared repository were designed to solve that, and agencies that waited for them avoided rework at the cost of a later start.
Using what came back
A signed form is a producer’s claim, not proof. Its value depends on what the agency does with it. Three uses matter. As a risk input, it informs decisions about where a product may be deployed and with what compensating controls. As a basis for follow-up, it gives security staff specific questions to ask. As a contractual commitment, it creates a record that can be enforced if the claim proves false, which is where the fraud risk from the earlier article bites.
Artifacts raise the bar. The memo let agencies ask for software bills of materials for higher-risk software. An SBOM helps only if someone can read it and match its components against vulnerability information. Agencies that collected SBOMs without tooling gained a folder of files. Those that loaded them into vulnerability management could answer, within hours, whether a new flaw in a common library touched them.
Judgment cannot be delegated to contracting. Only program and security staff can tell whether a producer’s plan of action is credible for the system in question, or whether a product’s role justifies asking for more evidence. Agencies that paired each critical software category with a named technical reviewer kept attestation from turning into paperwork. That pairing also gave contracting officers someone to call when a producer pushed back.
Outside government, the memo offered banks, health systems and state agencies a ready-made set of supplier questions with a recognized framework behind them. Producers that built attestation and SBOM capability for federal buyers could offer the same evidence to everyone else.
With hindsight
Implementation ran late. OMB extended the deadlines in 2023, and CISA released the final Secure Software Development Attestation Form in March 2024, with an online repository for submissions. Attestation became routine in federal software purchasing for a time. Policy then turned. In January 2026, OMB memorandum M-26-05 rescinded M-22-18 and its 2023 follow-up, ending the government-wide requirement to use the common form. It directed agencies to set their own risk-based software and hardware assurance policies, while leaving them free to request attestations or SBOMs where their risk assessment calls for them. The mandate lasted a little over three years. What agencies kept was what they had built around it: producer-level inventories, review processes and SBOM tooling. Those remain useful under the new approach, which depends even more on agency judgment.