More than 300 software manufacturers have now put their name on a document that, on paper, has no legal teeth: the Cybersecurity and Infrastructure Security Agency's Secure by Design Pledge. When CISA unveiled the pledge at the RSA Conference in San Francisco on May 8, 2024, 68 companies — including Microsoft, Google, AWS, Cisco, and IBM — signed on the spot. Two years and several progress-report cycles later, the signatory list has grown roughly fivefold, CISA has published its first rounds of self-reported progress data, and security teams are still asking the same question: does a voluntary pledge actually change how software gets built?
The answer, based on what CISA's own tracking shows, is "somewhat" — and the gaps in that answer are exactly where independent verification tools are becoming non-negotiable for any vendor claiming to take the pledge seriously.
What the pledge actually asks for
The Secure by Design Pledge is the operational layer of a broader Secure by Design initiative that CISA and international partners (including the UK's NCSC, Australia's ACSC, and Canada's CCCS) first published as joint guidance in April 2023. The pledge itself distills that guidance into seven concrete, time-bound commitments. Within one year of signing, a manufacturer agrees to demonstrate measurable progress on:
- Multi-factor authentication — increasing the use of MFA across the company's products, ideally by default rather than as an opt-in.
- Eliminating default passwords — reducing hardcoded and factory-set credentials across product lines.
- Reducing entire classes of vulnerability — showing measurable reduction in prevalence of vulnerability classes such as SQL injection, cross-site scripting, or memory-safety flaws, including through adoption of memory-safe languages.
- Increasing patch uptake — taking actions that measurably increase the rate at which customers actually install security patches, not just publish them.
- Publishing a vulnerability disclosure policy — a VDP that authorizes good-faith external testing of the manufacturer's products.
- Improving CVE record quality — ensuring accurate CWE (weakness) and CPE (platform) fields are populated in every CVE the company publishes.
- Improving intrusion evidence — increasing customers' ability to gather forensic evidence, largely through better default logging.
Every one of these goals is framed around outcomes a customer can measure, not intentions a vendor can claim. That framing is deliberate: CISA has been explicit that Secure by Design is a response to a market that has, for decades, priced security as an optional add-on rather than a baseline expectation.
The catch: no verification, no enforcement
CISA states plainly on its own pledge page that the commitment is voluntary and that the agency "does not enforce nor verify adherence" to it. Signing the pledge, or appearing on CISA's public list of signatories, is not an attestation from CISA that a company's products are secure — it is a public statement of intent, full stop.
That distinction matters more than it might sound. The pledge's first progress reports, published as companies hit their one-year anniversaries, are self-reported. There is no third-party audit requirement, no standardized scoring rubric across vendors, and no penalty defined for a company that signs, gets press coverage for signing, and then makes little measurable progress. Coverage of the initial cohort's one-year reports — including retrospectives from signatories like Fortinet and Trend Micro — has generally shown real movement on the easier goals (VDP publication, CVE field hygiene) and much slower, harder-to-quantify movement on the goals that require re-architecting product lines, particularly the vulnerability-class-reduction goal tied to memory-safe language adoption.
That asymmetry is not surprising. Publishing a VDP is a policy change. Rewriting a C++ codebase in Rust, or retrofitting default MFA into a decade-old product line, is a multi-year engineering program. CISA's own memory-safety guidance has been pointed on this: the agency has repeatedly called out continued use of memory-unsafe languages like C and C++ in new development as a root cause of a disproportionate share of critical vulnerabilities, despite the availability of memory-safe alternatives such as Rust, Go, Java, C#, and Swift.
Why this is a supply chain security story, not just a policy story
For security teams evaluating vendors, the pledge's honor-system structure creates a specific, practical problem: a signature on CISA's list tells you a vendor made a promise, but it tells you nothing about whether that promise shows up in the artifact you actually run in production. Two vendors can both be pledge signatories in good standing while shipping products with wildly different real-world exposure — one with a mature SBOM practice and rapid patch cadence, the other with stale dependency trees and default credentials still present in edge deployments.
This is precisely the gap that has pushed procurement and third-party risk teams toward requiring independent, artifact-level evidence rather than relying on pledge membership as a proxy for security posture. Executive Order 14028 already pushed federal buyers toward requiring SBOMs; the Secure by Design pledge's goals around vulnerability classes and patch uptake are functionally unverifiable without exactly the kind of component-level visibility an SBOM provides. A vendor can claim progress on "reducing prevalence of vulnerability classes" — but proving it requires being able to show, release over release, which components changed, which vulnerability classes disappeared, and which reachable code paths were actually eliminated rather than merely patched around.
That's also where the pledge's biggest blind spot sits: CVE counts and vulnerability-class claims say nothing about exploitability. A vendor can report a large reduction in raw CVE count while leaving the handful of actually-reachable, actually-exploitable flaws untouched. Counting fixed CVEs is not the same as reducing real risk, and there is currently no mechanism in the pledge that distinguishes the two.
What to watch as the pledge matures
A few developments are worth tracking heading into the next progress-report cycle. First, whether CISA moves from a pure honor system toward some form of standardized, comparable reporting format — right now, progress reports vary widely in depth and specificity from one signatory to the next, making cross-vendor comparison nearly impossible for procurement teams. Second, whether the vulnerability-class-reduction goal gets a more concrete measurement standard, since "measurable progress" currently leaves enormous room for interpretation. Third, whether federal procurement language starts referencing pledge status directly, which would raise the stakes on signatories that have made public commitments but limited demonstrable progress.
None of that changes the underlying reality for security and compliance teams today: the pledge is a useful signal of intent, but it is not a substitute for verifying a vendor's — or your own organization's — actual software supply chain posture.
How Safeguard Helps
Safeguard gives security teams the artifact-level evidence that a pledge signature alone can't provide. Our platform generates and ingests SBOMs across your codebase and third-party dependencies, so you have an accurate, continuously updated component inventory to measure real progress against — not self-reported claims. Reachability analysis then separates theoretical CVE counts from the flaws that are actually exploitable in your running code, which is exactly the distinction the pledge's vulnerability-class goal glosses over. Griffin AI, Safeguard's reasoning engine, triages that reachable risk against business context and prioritizes what genuinely matters, and our auto-fix PRs let teams close the highest-priority gaps in minutes instead of quarters. Whether you're a vendor trying to substantiate your own Secure by Design progress or a buyer trying to verify a supplier's claims, Safeguard turns "we pledged to improve" into evidence you can actually audit.