On January 26, 2022, the Office of Management and Budget quietly published a nine-page memo that changed how every federal agency has to build and ship software. OMB Memorandum M-22-09, "Moving the U.S. Government Toward Zero Trust Cybersecurity Principles," is best known for killing the perimeter-based security model, but buried in its "Applications and Workloads" pillar is a hard requirement: agencies must run continuous, dedicated application security testing (AST) on every internet-facing application, backed by static and dynamic analysis, before FY2024 ended on September 30, 2024. That deadline has now passed, and CISA and the Inspectors General are actively grading agencies against it. Legacy scanning vendors like Checkmarx have spent the last two years repositioning decade-old SAST engines as "zero trust ready." This post breaks down what M-22-09 actually requires, where the compliance bar really sits in 2026, and why bolting a 2015-era scanner onto a CI/CD pipeline isn't the same as meeting the mandate.
What is OMB M-22-09, and why does a zero trust memo talk about AST?
M-22-09 is the OMB memorandum that requires every FCEB (Federal Civilian Executive Branch) agency to adopt a zero trust architecture built around five pillars: Identity, Devices, Networks, Data, and Applications and Workloads. The "Applications and Workloads" pillar is where AST lives, because zero trust treats every application as if it were already exposed to the public internet, regardless of whether it sits behind a VPN or an agency firewall. The memo's logic is straightforward: if you can't trust the network to protect an application, the application itself has to be provably hardened, which means testing it for vulnerabilities before it ships and continuously while it runs. That's why a memo about network architecture spends multiple pages on static code analysis, dynamic testing, and centralized vulnerability reporting — in a zero trust model, AST isn't a nice-to-have security control, it's one of the five load-bearing pillars.
What did agencies actually have to build by September 30, 2024?
Agencies had to stand up a documented application security testing program covering every internet-accessible application, not just a subset flagged as "high value assets." Specifically, M-22-09 directs agencies to: (1) maintain an up-to-date inventory of internet-facing applications, (2) run at least one dedicated AST capability — combining static analysis (SAST), dynamic analysis (DAST), and increasingly software composition analysis (SCA) for open-source dependencies — integrated into the CI/CD pipeline rather than run as a pre-release gate months apart, and (3) centralize vulnerability findings so CISA's Continuous Diagnostics and Mitigation (CDM) program can ingest them. The memo also expects agencies to lean on third-party penetration testing and to make testing results available for cross-agency reporting. Agencies that treated this as a one-time scan before the FY2024 deadline are now the ones failing follow-on audits in FY2025 and FY2026, because M-22-09 was never designed as a checkbox — it assumes testing is continuous and pipeline-native.
How does M-22-09 connect to EO 14028 and the SSDF?
M-22-09 doesn't stand alone — it's the zero trust half of a compliance stack that starts with Executive Order 14028, "Improving the Nation's Cybersecurity," signed May 12, 2021. EO 14028 ordered NIST to publish secure software development guidance, which became NIST SP 800-218, the Secure Software Development Framework (SSDF), and it also produced the CISA Secure Software Development Attestation Form that software vendors selling into the federal government have had to sign since 2023 under OMB M-22-18. In practice, an agency (or a vendor selling to one) has to satisfy three overlapping documents at once: EO 14028 for the software supply chain baseline, SP 800-218 for how the SDLC itself is structured, and M-22-09 for how testing gets executed and reported inside a zero trust architecture. A team that only runs SAST at merge time might satisfy an old SSDF checklist item, but it won't satisfy M-22-09's expectation of continuous, pipeline-integrated testing across the application's full lifecycle — dev, test, and prod.
Where do legacy SAST vendors like Checkmarx fall short on M-22-09?
Checkmarx's core product line was built as a static code scanner, and it still asks teams to bolt on separate modules — Checkmarx SCA, Checkmarx DAST (via its 2021 Nutcracker/Checkmarx One integration), and manual configuration for supply chain visibility — to approximate what M-22-09 actually asks for in one motion. That matters because M-22-09 doesn't just require "a SAST tool," it requires an application security program that spans static analysis, dynamic testing, and centralized reporting on a single inventory of internet-facing applications. Agencies running Checkmarx frequently report the same three gaps in FedRAMP and CDM audits: findings live in separate dashboards for SAST versus SCA versus container scanning, so there's no single source of truth to hand an Inspector General; scan cadence is still tied to scheduled jobs rather than every commit, which conflicts with the "continuous" language in the memo; and software bill of materials (SBOM) generation — now required under EO 14028 in a machine-readable format like CycloneDX or SPDX — is a bolt-on add-on rather than a native output of every scan. None of this makes Checkmarx non-compliant by definition, but it does mean agencies and contractors using it are doing significantly more manual stitching to produce the unified evidence M-22-09 auditors ask for.
What happens if an agency or contractor misses the mandate?
Missing M-22-09 doesn't trigger an automatic fine, but it does show up as a finding in annual FISMA reports to Congress and in agency Inspector General audits, both of which are public and both of which OMB uses to set budget and modernization priorities the following fiscal year. For contractors, the exposure is more direct: the CISA Secure Software Development Attestation Form under M-22-18 requires vendors to attest, in writing to the government, that their software was built following SSDF practices, and a false attestation carries False Claims Act liability — a risk that has already produced multi-million-dollar settlements in adjacent federal cybersecurity attestation cases. In practice this means the mandate reaches beyond the roughly 100 FCEB agencies covered directly by M-22-09 and into every software vendor with a GSA schedule or federal contract, because their AST evidence flows into the same attestation and audit chain.
How Safeguard Helps
Safeguard was built for exactly the evidence problem M-22-09 creates: one pipeline-native platform that runs SAST, SCA, secrets scanning, and container/IaC analysis on every commit, and emits a single, continuously updated risk inventory instead of four disconnected dashboards. Every scan automatically generates a CycloneDX/SPDX-compliant SBOM and maps findings to the exact application inventory agencies are required to maintain under the "Applications and Workloads" pillar, so the mapping between "what we test" and "what's internet-facing" is never a manual spreadsheet exercise. Because Safeguard runs in CI/CD rather than as a scheduled batch job, agencies and contractors get the continuous testing cadence M-22-09 actually specifies, not a point-in-time scan re-labeled as continuous. And because every finding, SBOM, and attestation-ready report lives in one exportable format, teams preparing FISMA reports, FedRAMP packages, or CISA Secure Software Development Attestation Forms can pull audit evidence in minutes instead of weeks of consolidating exports from separate SAST, SCA, and DAST tools. If your team is still stitching together a Checkmarx SAST module, a separate SCA tool, and a spreadsheet SBOM to answer an M-22-09 audit request, that's the exact workflow Safeguard was designed to replace.