M-22-18 asked producers to sign; agencies first had to know who they were

The week

In September 2022 the White House told the companies that sell software to federal agencies to put their names, in writing, to how that software was made. Every agency runs on software it did not write: email, payroll, identity systems, the browser on every desk, almost all of it from outside companies.

OMB, the Office of Management and Budget, is the part of the White House that sets management rules for federal agencies. On September 14, 2022, it issued memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices. The “software supply chain” is everything and everyone involved in producing a piece of software: the company that sells it, the programmers who write it, the outside code libraries they borrow, and the tools they use to package it. A weakness anywhere along that chain can end up inside the product a customer installs.

Where the memo came from

The memo implemented Executive Order 14028, signed in May 2021, which set out to improve the nation’s cybersecurity. That order followed the SolarWinds compromise, discovered in December 2020. Attackers had tampered with the build process of a widely used network management product, so that routine updates carried their access into customers’ networks. The Log4Shell flaw, disclosed in December 2021, sat in a free logging library embedded in countless products. It showed how hard it was for organizations to tell whether they were exposed to a flaw in a component they had never knowingly bought.

Under the order, the National Institute of Standards and Technology (NIST) had published two documents in February 2022. One was its Secure Software Development Framework, known as the SSDF or NIST SP 800-218. The other was companion guidance on software supply chain security. The SSDF is a recognized checklist of good habits for building software safely. It groups them under four headings: preparing the organization, protecting the software, producing well-secured software, and responding to vulnerabilities.

What the memo required

M-22-18 directed federal agencies to obtain a self-attestation from the producers of software they use. An attestation is a formal, signed statement; here, the producer confirms that its software was developed in line with the SSDF and related guidance. The memo defined software broadly, to include firmware, operating systems, applications and cloud-based application services, as well as products containing software.

The requirement applied to software developed after the memo’s date, and to existing software when it received a major version change. Software that agencies developed themselves was outside its scope, although agencies were expected to follow secure development practices for it. A minimum attestation had to name the producer, describe the products covered and state that the producer followed the practices itemized in a standard form. An assessment by a FedRAMP-certified or agency-approved third-party assessor, using the NIST guidance as its baseline, could stand in for a self-attestation.

The memo gave agencies room to go further or to bend. Where risk warranted, they could require additional evidence, called artifacts, such as a software bill of materials, or SBOM. An SBOM is an ingredients list for software: it names the components and outside code packaged inside a product. Agencies could also ask for evidence that a producer ran a vulnerability disclosure program, a published way for outsiders to report flaws. For producers not yet able to attest, agencies could accept a plan of action and milestones. That is a written commitment describing what the producer would fix and by when, and the memo said it was not to be posted publicly.

The clock

The deadlines ran in a deliberate order. Within 90 days, agencies were to inventory all software subject to the memo, with a separate inventory of critical software. Within 120 days, they were to set up a process for telling vendors about the requirements and a single agency system for holding the attestations. Within 180 days, they were to plan training for staff who would review them. Attestations for critical software were due within 270 days, and for all covered software within a year.

OMB asked the Cybersecurity and Infrastructure Security Agency (CISA), the federal government’s lead civilian cyber defense agency, to develop a common attestation form within 120 days. The aim was to spare producers a different questionnaire from every customer. It also set out steps toward a shared repository for attestations and artifacts. Those deadlines were later extended.

Agencies that could not keep up could ask OMB for an extension, at least 30 days before the relevant deadline and with a plan for meeting it. Waivers were reserved for exceptional circumstances and limited periods, and the OMB director would decide on them in consultation with the national security advisor. The memo also noted that the FAR Council, which writes the government’s standard procurement rules, planned to propose a rule on a uniform attestation form.

On paper, it was a procurement memo. In practice, it asked agencies a question many could not answer quickly: who, exactly, makes the software we run?

Take a program director at a mid-sized federal agency in the autumn of 2022. She runs a benefits system that hundreds of thousands of people depend on. A memo arrives saying that, before long, every company whose software her program uses must sign a statement about how that software was built. Her first reaction is reasonable: fine, send the letters. Her second, a few days later, is less comfortable. Which companies? The system was assembled by an integrator a decade ago, runs on products bought through a reseller, and sits on servers whose firmware came from yet another supplier. Nobody has a single list.

That gap between the instruction and the reality is the real story of M-22-18. The memo is remembered for a form. The work that mattered was everything around the form.

The memo’s own timetable said as much. The first deadline asked nothing of vendors. Within 90 days, agencies were to inventory their software. Everything else depended on that list, and the list was where many agencies stalled.

Why the government started asking how software is made

Federal software security had long focused on systems after they were built. Agencies granted authorizations to operate, a formal sign-off that a system’s risks are understood and accepted before it goes live. They ran control assessments, checking that required safeguards such as passwords, logging and encryption were in place. They practiced continuous monitoring, watching systems for trouble once they were running. All of that is like inspecting a finished house: you check the locks, the smoke alarms and the wiring you can see.

What that approach could not easily reach was how the house was built. If a supplier’s own development process was compromised, a perfectly inspected system could still be carrying a hidden flaw delivered through a routine update. Executive Order 14028, written after the SolarWinds compromise, added accountability for how software is made in the first place. In that attack, a widely used product’s own updates had carried the attackers’ access into customers’ networks.

M-22-18 was the mechanism, and it worked through procurement rather than new technical controls. Instead of telling agencies to install a new tool, it told them to make suppliers stand behind their development practices as a condition of doing business. The important shift was that security moved partly from the server room into the contract file.

What a producer was promising

The common form that CISA eventually published asked producers to attest to a short list of practices drawn from the SSDF. In outline, they covered four areas. The software had to be built in secure environments, with separated build systems, logged and monitored access, and multi-factor authentication for people working on them. The producer had to make a good-faith effort to keep a trusted supply chain for its source code. It had to keep provenance data, a record of where its own and third-party code came from. And it had to use automated tools to check for security vulnerabilities, and act on what they found.

Each of those maps to a known attack. SolarWinds was a build environment compromise. Malicious packages slipped into public code libraries are a source code supply chain problem. Log4Shell was a provenance problem for most of its victims, because they did not know where the library was. Unscanned code is how ordinary flaws ship. The form was short, but it was aimed at real failure modes.

The legal weight of a signature

The Justice Department’s Civil Cyber-Fraud Initiative, launched in October 2021, attached False Claims Act risk to security representations made to government. The False Claims Act lets the government pursue companies that make false statements to obtain federal money, with damages that can be multiplied. It also lets whistleblowers, often current or former employees, bring cases on the government’s behalf and share in any recovery.

The initiative produced real cases. In 2022 the aerospace contractor Aerojet Rocketdyne settled a whistleblower suit over its cybersecurity representations for $9 million. In 2024 Pennsylvania State University settled allegations that it had not met the cybersecurity requirements in its defense contracts. M-22-18 multiplied the number of such representations. Every signed attestation was another statement a producer could later be held to, which is why producers’ lawyers read the form as closely as their engineers did.

The case against self-attestation

The strongest criticism was that a self-attestation proves little. A producer signs that it follows good practices, and the buyer cannot see inside its build systems to check. Critics argued that the exercise would reward companies with good paperwork over companies with good engineering. Smaller producers also bore a heavier relative burden, since documenting practices against a federal framework takes legal and engineering time that large vendors can absorb more easily.

Those criticisms had force, and the memo’s eventual rescission in 2026 echoed them. They do not touch the argument of this piece. Whatever the form was worth, the agency could not use it without knowing which producers to ask, and could not act on it without someone qualified to read it. Those two capabilities were valuable under the mandate, and they stayed valuable after it ended.

The three jobs hidden inside one memo

For agency CIOs, contracting officers and program directors, the memo created three jobs, done in sequence by different people:

1. An inventory that recorded who produced each piece of software.
2. Collecting attestations through contracts.
3. Using what came back to make risk decisions.

Most attention went to the second. It was visible, it had a form, and it had deadlines. The first and third determined whether the exercise was worth doing. An agency that collected beautiful paperwork from the wrong list of suppliers, or filed it away unread, had spent effort without reducing risk.

Each job has a different owner. The inventory usually sits with the CIO’s office and IT asset managers. Collection belongs to contracting officers, who write and manage contracts. Using the results needs security staff and program owners, who understand what a system does and what would happen if it failed. M-22-18 required all three groups to work from the same facts, which is harder than it sounds in any large organization.

The memo assigned overall responsibility to agency CIOs, working with the offices that need the software and with chief acquisition officers. That placement mattered. A CIO can require a shared inventory and name reviewers. A CIO cannot make contracting officers change their clauses without the acquisition side agreeing, and the memo forced that conversation in agencies where it had rarely happened.

Job one: 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.

Why the list is so hard to build

Software reaches agencies through many doors:

• Direct purchases from the company that makes the product.
• Enterprise agreements, large umbrella deals covering many products.
• Reseller contracts, where a middleman sells products made by others.
• Cloud services, where the software runs in someone else’s data center and is used over the internet.
• Code embedded in hardware, such as the built-in software inside a network switch or a printer.
• Components inside systems that integrators build, where a contractor assembles a solution from many parts.

Asset management tools, the systems that keep track of what an organization owns, tracked licenses and devices. Many did not record the producer behind a reseller’s line item, or the version actually running. An invoice might say “enterprise security bundle” without naming the four companies whose products were inside it. A device record might list a server without saying which version of its operating system was installed. For attestation purposes, both details mattered.

Sorting what was in scope

The inventory also had to sort scope. Agency-developed software and freely obtained open source were treated differently from purchased products. That meant the list needed a column most organizations had never kept: where the software came from, and whether the agency paid for it.

OMB’s June 2023 update, M-23-16, sharpened the rules and added columns. Attestations were due from the producer of the end product the agency used, not from the makers of every open-source or proprietary component inside it. Proprietary software that is free and publicly available, such as a web browser, was out of scope, though agencies still had to assess its risk. Free demonstrations and pilots of products that are normally paid for stayed in scope. Whether software built by a contractor counted as agency-developed was left to the CIO to decide, based on how closely the agency controlled its development.

The update also clarified timing. Software developed before the original memo was in scope if it had a major version change afterward, or if it was a hosted service that deployed continuous updates. That second test brought most cloud services in, since they are updated constantly. An inventory that ignored subscriptions would miss much of what the memo covered.

In practical terms, a usable inventory row needed several fields beyond a product name. It had to record the producer of the end product, the route by which it was acquired and whether it was paid for. It also had to note whether it was hosted, its version or update model, whether it fell in a critical software category, and the contract it was bought under.

NIST’s 2021 definition of critical software set the first wave. It covered categories such as identity and access management, the systems that decide who can log in and what they can reach. It also covered operating systems, browsers, endpoint security (the protective software on laptops and servers), network control and backup. These are the products that, if compromised, give an attacker the keys to everything else. Mapping holdings against those categories told an agency which producers to approach first and how many there were.

Start from the money

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, which inspect networks and computers to see what is installed, then confirm what is actually running.

Reconciling the two lists exposes problems on both sides. On the money side, you find shadow purchases: software bought on a card or through a small contract that IT never knew about. On the machine side, you find unlicensed or forgotten software: products still running long after anyone remembers buying them. Neither list alone is complete.

Suppose an agency pulls a list of software suppliers from its finance records and a list of producers from its network scans. When the two lists are matched, many names appear on both, but not all. The remainder are the interesting part: suppliers paid for products nobody can find running, and producers whose software is running with no clear purchase behind it. Each of those gaps is a question worth asking, quite apart from any attestation.

Firmware and devices

The memo’s definition of software included firmware and products containing software. That brought in network switches, firewalls, storage arrays, printers and the management controllers built into servers. These products are bought as hardware, often through infrastructure contracts, and their software is updated on a different rhythm from applications. Network scans may identify the device but not the firmware producer or version.

The practical fix was to treat each device model as a software product in the inventory, with its own producer and firmware version. That is tedious for a large estate. It also exposes devices running firmware that has not been updated in years, which is a risk with or without an attestation requirement. The weakness on hardware that OMB later cited when it rescinded the memo was visible here from the start.

Contracts that many agencies use

Government-wide and multi-agency contracts complicated the picture. M-22-18 made the agency that awarded a contract usable by others responsible for implementing its requirements on that contract. For a small agency buying through a large shared vehicle, that meant some collection work might be done upstream. It did not remove the need to know what had been bought, because the buying agency still had to show which products it used and under which vehicle.

Why size changes the work

The inventory looked different by type of organization. A cabinet department with many semi-independent components had to reconcile several asset systems, several contracting shops and several security teams, often with different naming conventions for the same product. A small independent agency might have one contracting office and a few hundred products, but also one or two people to do all of it. The large department’s problem was consistency. The small agency’s problem was capacity.

Why this was the most valuable part

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.

A complete, producer-level software inventory is not an IT housekeeping chore. It is what lets an organization answer, quickly and with confidence, “are we exposed?” on the morning a major security flaw makes the news.

Job two: collecting the attestations

Collection is a contracting task. It needs three things:

• Clauses that make an attestation a condition of award or renewal, so that signing is part of winning or keeping the business.
• A process for sending requests and tracking responses, because hundreds of producers will reply at different speeds, in different ways.
• Rules for producers who cannot attest.

Writing the clauses

Good clauses anticipate the moments when the requirement applies. Award is the obvious one. Renewal is another, since the memo covered renewals. Major version changes are a third, and they are easy to miss, because a new version may arrive through a routine update without any contract action at all. A clause that requires the producer to provide a fresh attestation, or confirm the existing one still applies, at each major version keeps the record current.

Resellers need their own wording. A reseller is not the producer and cannot sign for one. The contract should require the reseller to obtain the producer’s attestation, or a link to a published one, and to tell the agency promptly if a producer refuses. Without that clause, the contracting officer ends up chasing a manufacturer with whom the agency has no direct relationship.

Confidentiality also needs attention. The memo said that documentation provided instead of a full attestation, such as a list of unmet practices and a plan of action, should not be posted publicly by the producer or the agency. That is sensitive information about a product’s weaknesses. The agency system that holds it needs access controls to match.

Flexibility, and its limits

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. Refusing to deal with them would have meant switching off systems with no replacement.

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. Anyone who has managed a long list of “temporary” exceptions knows how that goes: each one is reasonable on its own, and together they become the norm.

The 2023 update tightened this. An agency that accepted a producer’s plan of action could keep using the software, but had to request an extension from OMB at the same time and include a copy of the plan. If the agency found the documentation unsatisfactory, or did not request the extension, it had to stop using the software. Where several agencies relied on the same producer’s plan, OMB could name a lead agency to coordinate with that producer. The effect was to turn plans of action from a local judgment into a governed exception with central visibility.

A simple register of open plans, with milestone dates and the program office responsible, kept them visible. It need not be sophisticated. A shared table showing the producer, the product, what is missing, the promised date and the named owner is enough to let a senior official ask, each quarter, which promises have slipped.

What collection cost, and who paid

Collection had real costs on both sides. Producers needed engineering time to document their practices and legal time to review a statement that carried False Claims Act exposure. Large producers could spread that cost across their whole customer base. Small and specialist producers could not, and some were likely to price the work into their bids or think twice about federal business.

Agencies paid in staff time. Contracting officers had to send requests, chase replies and file responses. Program offices had to answer questions about which products they used. Security staff had to review exceptions. The memo provided no new money for that work, so it competed with everything else on the same desks, and smaller agencies felt the squeeze first. A shared repository and a common form were the main ways to cut those costs, which is why their delays mattered.

Avoiding the paperwork pile-up

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. That was a real trade-off. Moving early showed seriousness but risked asking suppliers twice; waiting reduced friction but delayed the inventory and review work that could have started regardless.

The sensible middle path was to separate the two. The inventory and the review arrangements did not depend on the form at all, and could begin at once. Only the act of sending requests needed to wait.

The memo also encouraged producers to make their attestations product-inclusive, covering a company or product line rather than a single item, so that one statement could serve every agency. Agencies benefited when producers published their attestations and simply linked to them. The agency then had to retain only the link, which cut storage and tracking work.

Job three: 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, meaning extra safeguards added to make up for a known weakness.
• As a basis for follow-up. It gives security staff specific questions to ask: you say you check outside code for known flaws; how, and how often?
• As a contractual commitment. It creates a record that can be enforced if the claim proves false, which is where the False Claims Act risk bites.

Reading an attestation critically

Each area of the form suggests a follow-up for the products that matter most. For the build environment, ask whether build systems are separated from the corporate network and whether developers need phishing-resistant multi-factor authentication to reach them. For source code, ask how the producer vets the open-source packages it pulls in. For provenance, ask the producer to show, for a given release, which components and versions went into it. For vulnerability checking, ask which tools run, at what point in the release process, and what happens when they find something.

The answers do not need to be perfect. They need to be specific. A producer that answers in detail, and can show artifacts such as scan summaries or a vulnerability disclosure policy, has given the agency something to weigh. A producer that repeats the wording of the form has not.

For the most critical products, the memo let agencies go further and require a third-party assessment rather than a self-attestation. That costs the producer real money and time, and agencies that asked for it on low-risk products would have strained relationships for little gain. Reserving it for identity systems, security tools and similar categories kept the demand proportionate.

What an SBOM is for

Artifacts raise the bar. The memo let agencies ask for software bills of materials for higher-risk software. Modern software is rarely written from scratch; it is assembled, with a large share made of shared components, often open-source libraries that thousands of products use. When a serious flaw is found in one of those libraries, every product containing it may be affected. An SBOM tells you which products contain which ingredients.

The memo required SBOMs to follow the formats in the National Telecommunications and Information Administration’s 2021 report on minimum elements, or later CISA guidance. Those minimum elements include the supplier, the component name and version, unique identifiers, the relationships between components, and when and by whom the SBOM was made. The two formats most producers use are SPDX and CycloneDX, both of which machines can read.

An SBOM helps only if someone can read it and match its components against vulnerability information, the public lists of known security flaws. Agencies that collected SBOMs without tooling gained a folder of files. Those that loaded them into vulnerability management, the systems and processes that track and fix known weaknesses, could answer, within hours, whether a new flaw in a common library touched them.

The matching problem

The hard part of using SBOMs is matching names. A component listed one way in a producer’s SBOM may be listed differently in a vulnerability database, and a mismatch produces either a missed exposure or a false alarm. Standard identifiers for packages reduce the problem but do not remove it. Agencies that used SBOMs well assigned someone to tune the matching and to work through the false positives, rather than expecting the tool to be right out of the box.

False positives have a second cause. A product may contain a vulnerable component without using the vulnerable part of it. Producers can publish statements, known as VEX documents, saying whether a given flaw actually affects their product. An agency that consumes both SBOMs and those statements spends less time chasing flaws that cannot be exploited in its environment.

Suppose two agencies wake up to news of a flaw in a popular component. The first has SBOMs stored as attachments in a contracts system; staff spend days emailing suppliers to ask whether their products are affected. The second has the same SBOMs loaded into a searchable tool; by lunchtime it knows which systems contain the component and has asked those suppliers for fixes. The documents were identical. Only one agency had made them useful.

Judgment cannot be outsourced to the contract file

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. A missing control in a desktop utility is not the same as a missing control in the system that manages every employee’s login.

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, and it gave producers a technical counterpart who could discuss evidence in detail.

The memo anticipated this by requiring agency CIOs to assess training needs and plan training for staff who would review attestations and artifacts. Training was the least visible deadline and among the most important. A reviewer who has never seen an SBOM, or never asked a producer how its build environment is protected, cannot add much to a signed form.

A ready-made question set for banks and hospitals

Outside government, the memo offered banks, health systems and state agencies a ready-made set of supplier questions with a recognized framework behind them. Most organizations already ask vendors about security, often through long questionnaires of their own invention. Being able to point to the SSDF gave those questions a common reference, which helps both sides: buyers ask for something recognizable, and suppliers can answer once in a standard way.

Producers that built attestation and SBOM capability for federal buyers could offer the same evidence to everyone else. For a regional bank or a hospital system, that means suppliers who sell to government may already have documentation worth requesting.

Which rules apply to whom

The memo bound only federal executive agencies. Other sectors meet the same questions through their own rules, and the fit differs.

• Banks. In June 2023 the Federal Reserve, the FDIC and the OCC issued joint guidance on managing risks from third-party relationships. It applies to the banking organizations those agencies supervise. Supplier evidence on secure development fits naturally into the due diligence and monitoring it describes.
• Credit unions. The NCUA was not a party to that guidance, and it has long lacked direct authority to examine credit unions’ technology vendors. Credit unions therefore depend even more on what they can obtain from suppliers by contract.
• Broker-dealers and investment advisers. The SEC’s 2024 amendments to Regulation S-P required covered firms to oversee service providers that handle customer information, including arrangements for those providers to report incidents promptly.
• Health systems. Since 2023, federal law has required makers of networked medical devices to include an SBOM in premarket submissions to the FDA. Hospitals can ask device makers for those SBOMs. HIPAA governs patient data through business associate agreements, but it does not require secure development attestations.

Counsel should confirm how each of these rules applies to a given organization. The broader point is that the SSDF gives a common vocabulary across all of them, which reduces the number of different questionnaires a supplier must answer.

State and local agencies

State and local governments were not bound by M-22-18. Many of them buy the same commercial products as federal agencies, sometimes through the same resellers, and their suppliers may already hold an attestation prepared for federal customers. A state CIO could ask for it at little cost to the supplier. The harder part, as in federal agencies, is knowing which producers to ask. States that run central IT for many agencies face the cabinet-department problem of reconciling several asset systems; smaller counties face the capacity problem.

Where the federal approach fits poorly

A regional bank or a community hospital cannot demand attestations with the force of the federal government. A supplier may decline, or charge for the work. Smaller buyers get further by asking for documents suppliers already have, such as a published attestation, an SBOM produced for federal customers or an independent assessment report, than by sending their own forms. They also get further by joining with peers, through industry groups or shared assessment programs, so that one supplier answers once for many buyers.

The business case maps neatly onto the concerns of any board:

• Cost. A producer-level inventory exposes duplicate products and forgotten licenses, and makes renewal negotiations better informed.
• Risk. Knowing what you run, and what is inside it, shortens the time between a flaw being announced and your organization knowing whether it is exposed.
• Accountability. Signed supplier statements create a clear record of who promised what, which matters if something goes wrong.
• Regulators. Examiners and auditors increasingly ask how organizations manage third-party technology risk. A documented process is a much better answer than a scramble.

The three jobs, done well and done badly

Done well, the three jobs leave an organization with:

• One inventory, shared by IT, contracting and security, that records the producer and the running version of each product, including those bought through resellers or embedded in hardware.
• Contract clauses that make supplier evidence a standard condition rather than a special request, triggered at award, renewal and major version changes.
• A visible register of supplier gaps, with dates and owners, reviewed regularly by someone senior.
• SBOMs loaded into tools that can be searched when a new flaw is announced, with someone responsible for tuning the matching.
• A named technical reviewer for each category of critical software, trained to read the evidence.

Done badly, they produce familiar failures:

• Treating the form as the finish line. A signed attestation filed and forgotten changes nothing about risk.
• Building the list from one source. Contract records alone miss software nobody bought formally; scans alone miss what is paid for but hidden inside bundles and services.
• Ignoring subscriptions. Hosted services that update continuously were squarely in scope, and they rarely show up in a device scan.
• Letting exceptions drift. Plans of action without dates and owners become permanent.
• Collecting artifacts with nowhere to put them. A folder of SBOMs is not a capability.
• Leaving it all to contracting. Contracting staff can gather evidence; they cannot judge whether it is good enough for a particular system.

A few measures show which side of that line an organization is on. The share of software spending that can be traced to a named producer and a running version. The time taken, in the last real event, to determine exposure to a newly announced flaw. The number and age of open supplier exceptions. And the share of critical software categories with a named reviewer. Each can be reported quarterly with modest effort, and each moves only when the underlying work is done.

Inventory, exceptions and named reviewers as the measure of M-22-18

Whether you lead a federal agency, a bank or a health system, these questions test whether your organization could meet the spirit of M-22-18:

1. Can we produce, today, a list of every company whose software we run, including software bought through resellers and built into hardware?
2. When a serious flaw is announced in a widely used component, how long does it take us to know whether we are affected? Hours, days or weeks?
3. How many supplier exceptions are open, how old is the oldest, and who owns each one?
4. If we collect SBOMs, where do they go, and can we search them?
5. Who, by name, judges whether a supplier’s security evidence is good enough for our most important systems?

With hindsight

Implementation ran late. In June 2023, OMB’s update M-23-16 reset the clock. Attestations for critical software became due three months after OMB approved CISA’s common form, and for all other covered software six months after. The update also clarified scope and tightened the rules on plans of action, requiring an OMB extension request for each one an agency accepted.

CISA released the final Secure Software Development Attestation Form in March 2024. A week later it launched an online repository, a central place where producers could file their attestations once rather than sending them to each agency separately. Under the revised timeline, the collection deadlines fell in mid-2024 for critical software and later that year for everything else. Attestation became routine in federal software purchasing for a time.

What the incidents of those years tested

Events between 2023 and 2024 showed both the reach and the limits of the approach. In March 2023, a widely used business phone application from 3CX was found to have been trojanized through its own build process, the kind of failure the form’s build environment practices targeted. Two months later, the Cl0p group exploited a previously unknown flaw in the MOVEit Transfer file-sharing product, and several federal agencies were among the many organizations affected. An attestation could not have prevented a flaw nobody yet knew about. An accurate inventory did tell agencies within hours whether they ran the product.

In March 2024, a backdoor was discovered in XZ Utils, an open-source compression library, before it had spread widely. Open-source components were outside the attestation requirement, which placed responsibility on the producers of end products. The episode showed why SBOMs mattered: the practical question for every organization was which of its products contained that library.

The mandate ends

Policy then turned. On January 23, 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. The new memo described M-22-18 as imposing unproven and burdensome software accounting processes that put compliance ahead of genuine security investment, and faulted it for neglecting threats from insecure hardware. It directed agencies to set their own risk-based software and hardware assurance policies. The mandate lasted a little over three years.

The rescission did not abandon the foundations. M-26-05 told agencies to continue maintaining a complete inventory of software and hardware. It left them free to keep using the attestation form. They could also write contract terms requiring a producer to provide a current SBOM on request, including, for cloud platforms, an SBOM of the production environment. It pointed agencies to the SSDF, to a draft update of SBOM minimum elements that CISA published in August 2025, and to CISA’s framework for hardware bills of materials.

The mandate ended, but the work it prompted did not. What agencies kept was what they had built around the mandate: producer-level inventories, review processes and SBOM tooling. Those remain useful under the new approach, which depends even more on agency judgment. A risk-based policy asks each agency to decide for itself which suppliers deserve closer scrutiny. That decision is only as good as the agency’s knowledge of what it runs and its ability to weigh evidence. The agencies that treated M-22-18 as an inventory and judgment exercise are well placed; those that treated it as a forms exercise have less to show.

The critics of self-attestation were partly vindicated. The rescission adopted their view that a uniform form was a blunt instrument. The defenders were partly vindicated too, since the new memo kept the inventory requirement and the tools the old one had produced.

Outside government, the arc carries a useful message. Compliance requirements change; mandates are issued, extended and withdrawn. The capabilities built to meet them can outlast them, if they were built to be used. Knowing who makes your software, keeping track of the promises suppliers have made, and having named people who can judge whether those promises are good enough are valuable whatever the current rules say. When the next requirement arrives, whether from a regulator, a customer or a board, an organization with those foundations in place will be adjusting a process rather than starting one.