On September 14, 2022, the Office of Management and Budget (OMB) released Memorandum M-22-18, "Enhancing the Security of the Software Supply Chain through Secure Software Development Practices." The memorandum established a requirement that would affect every company selling software to the U.S. federal government: self-attestation to secure development practices.
This wasn't a suggestion. It was a mandate with teeth, and it set the stage for the most significant change in federal software procurement security in decades.
What M-22-18 Requires
The memorandum implements the software supply chain security provisions of Executive Order 14028 by requiring federal agencies to only use software from producers who attest to following secure development practices. The specific requirements:
Self-Attestation
Software producers must provide a self-attestation letter confirming that they follow the practices outlined in NIST's Secure Software Development Framework (SSDF, SP 800-218). This attestation must be signed by the CEO or a designated official.
SBOM Provision
Agencies may require software producers to provide SBOMs, and producers must be prepared to provide them upon request.
Third-Party Assessment (Alternative)
As an alternative to self-attestation, software producers can submit evidence from a third-party assessment (such as FedRAMP authorization) that covers the relevant secure development practices.
Timeline
The memorandum established a phased timeline:
- Critical software: Attestation required within specific timeframes
- All other software: Attestation required within extended timeframes
- Agencies were directed to inventory their software and identify which products required attestation
The SSDF Connection
The self-attestation is based on NIST SP 800-218, the Secure Software Development Framework. SSDF defines four groups of practices:
Prepare the Organization (PO)
- Define security requirements for software development
- Implement roles and responsibilities
- Implement supporting toolchains
- Define and use criteria for software security checks
- Implement and maintain secure environments for development
Protect the Software (PS)
- Protect all forms of code from unauthorized access and tampering
- Provide a mechanism for verifying software release integrity
- Archive and protect each software release
Produce Well-Secured Software (PW)
- Design software to meet security requirements and mitigate security risks
- Review the software design to verify compliance with security requirements
- Reuse existing, well-secured software when feasible
- Create source code by adhering to secure coding practices
- Configure the compilation, interpreter, and build processes to improve executable security
- Review and/or analyze human-readable code to identify vulnerabilities and verify compliance
- Test executable code to identify vulnerabilities and verify compliance
- Configure software to have secure settings by default
Respond to Vulnerabilities (RV)
- Identify and confirm vulnerabilities on an ongoing basis
- Assess, prioritize, and remediate vulnerabilities
- Analyze vulnerabilities to identify their root causes
What This Means for Software Producers
You Need Documentation
Self-attestation isn't just checking a box. It requires that you can document your adherence to SSDF practices. This means:
- Written secure development policies and procedures
- Evidence that developers are trained on secure coding
- Documentation of your build process and its security controls
- Records of vulnerability management and response
- Documented SBOM generation capabilities
Your Development Process Will Be Scrutinized
Agencies can request evidence supporting your attestation. If you claim to follow secure coding practices, you should be able to demonstrate:
- Code review processes
- Static and dynamic analysis in your CI/CD pipeline
- Dependency management and vulnerability scanning
- Secure build and release processes
- Incident response procedures for security vulnerabilities
SBOMs Are No Longer Optional
While the SBOM requirement is framed as something agencies "may" request, the practical reality is that most federal agencies will request them. Being unable to provide an SBOM will be a competitive disadvantage in federal procurement.
The CEO Signs It
The attestation must be signed by a senior official — typically the CEO. This elevates software security from a technical concern to an executive responsibility. CEOs who sign attestations for practices their organizations don't actually follow face significant legal risk.
Preparing for Attestation
Step 1: Gap Assessment
Map your current development practices against the SSDF requirements. Be honest about where you fall short. The SSDF is detailed enough that most organizations will have gaps, and identifying them early is better than discovering them during an audit.
Step 2: Implement Missing Practices
For each gap identified, implement the necessary practices:
- If you lack automated security testing, implement SAST/DAST in your CI/CD pipeline
- If you don't generate SBOMs, integrate SBOM tooling into your build process
- If your build environment isn't secured, implement access controls, logging, and integrity verification
- If you don't have a vulnerability disclosure process, establish one
Step 3: Document Everything
Create and maintain documentation for each SSDF practice area:
- Policies and procedures
- Tool configurations and outputs
- Training records
- Incident response plans and test results
- SBOM examples and generation processes
Step 4: Prepare the Attestation Letter
Draft the self-attestation letter using CISA's guidance. Have it reviewed by legal counsel. Ensure the signing official understands what they're attesting to.
Step 5: Establish Ongoing Compliance
Self-attestation isn't one-time. You need processes to maintain compliance as your development practices evolve, as the SSDF is updated, and as new products are developed.
The Broader Impact
While M-22-18 directly affects only federal software procurement, its impact extends far beyond the government market:
Industry benchmark. The SSDF and attestation framework will become the baseline expectation for software security, even in private-sector procurement.
Insurance requirements. Cyber insurers are likely to reference SSDF practices in their underwriting criteria.
International influence. The EU Cyber Resilience Act and other international regulations are developing along similar lines, creating a global convergence on secure development requirements.
Supply chain pressure. Federal contractors will pass these requirements down to their subcontractors and software suppliers, creating a cascade of compliance requirements through the supply chain.
Common Misconceptions
"This only applies to custom software." No — it applies to all software used by federal agencies, including commercial off-the-shelf (COTS) products and open source components incorporated into commercial products.
"Open source is exempt." Open source components used within commercial products are within scope. The commercial product vendor is responsible for attesting to the security practices that cover their entire product, including open source components.
"Self-attestation is just a checkbox." Agencies can request supporting evidence, and false attestation carries legal consequences. This is a substantive requirement, not a formality.
How Safeguard.sh Helps
Safeguard.sh directly supports the CISA self-attestation requirements by providing automated evidence of secure development practices. Our platform generates SBOMs compliant with the NTIA minimum elements, provides continuous vulnerability monitoring aligned with SSDF's "Respond to Vulnerabilities" practices, and creates audit-ready documentation of your supply chain security controls. For organizations preparing for federal self-attestation, Safeguard.sh provides the tooling to both implement and evidence the secure development practices that M-22-18 demands.