CISA's Secure by Design pledge crossed 350 signatories in early 2026, including most major software vendors and a growing share of mid-market firms. The pledge text is aspirational, and the operational work of actually achieving its goals continues to be where most organizations get stuck.
What does the pledge actually require?
The pledge commits signatories to demonstrate measurable progress on seven goals over a 12-month horizon: increased use of multi-factor authentication, reduction of default passwords, reduction of entire classes of vulnerabilities, increased installation of security patches, published vulnerability disclosure policy, evidence of intrusion attempts, and CVE completeness. The wording is deliberately outcome-oriented rather than control-oriented, which is why signatories interpret it differently. The most defensible interpretation is to map each goal to a measurable engineering metric, set a baseline at pledge signature, and report annual progress against the baseline. Vendors that publish their progress publicly, which CISA strongly encourages, end up with the cleanest external evidence story. The CISA Secure by Design Alert series, now at nine alerts covering specific vulnerability classes from SQL injection through path traversal, defines what "entire class reduction" means in practice and gives signatories the targets to measure against.
How do you map the goals to NIST SSDF?
The pledge goals overlap heavily with the NIST Secure Software Development Framework (SSDF), SP 800-218, and the cleanest evidence model is to satisfy SSDF and report selected metrics against the pledge. The class-reduction goal maps to SSDF PW.5 and PW.7 controls covering secure coding practices and reusable secure components. The patch installation goal maps to SSDF RV.1 and RV.2 covering vulnerability identification and remediation. The MFA and default password goals map to SSDF PO.5 covering secure infrastructure for the development environment, with the customer-facing variants tracking against application security controls. The vulnerability disclosure policy goal maps to SSDF RV.1.3 specifically. Several auditors have started accepting SSDF evidence packages as sufficient evidence for the pledge, which is the right pattern because it avoids parallel reporting overhead. Build your evidence for SSDF and the pledge mapping follows for free.
What metrics actually demonstrate progress?
The metric most often reported is reduction in shipped CVEs of a specific class. The honest measurement of this is harder than it looks because you need a stable measurement frame: same scanner, same scope, same severity threshold, year over year. Several signatories reported memory-safety CVE reductions of 60 to 80% between 2023 and 2025 by adopting Rust, Go, or compiler-level mitigations for legacy C and C++ code. Reporting the absolute number plus the methodology is more defensible than a single percentage. For the patch installation metric, the right measure is median time-to-patch for critical CVEs in customer-deployed software, with a target of under 14 days for internet-facing products and under 30 days for the broader portfolio. For default password reduction, count the number of products that ship with credentials that must be changed on first use, with a target trajectory to zero by the end of the pledge year. Concrete numbers always beat narrative.
How do procurement and government buyers use the pledge?
GSA and several state procurement programs started referencing Secure by Design pledge status in software procurement guidance during 2025, and DOD's Cybersecurity Maturity Model Certification (CMMC) Level 2 implementations frequently treat pledge signature as positive evidence during third-party assessments. The pledge alone is rarely a decisive procurement criterion, but it serves as a useful filter, particularly for shortlisting in competitive procurements. Healthcare and financial regulators have been slower to formally reference the pledge, but procurement teams in those sectors increasingly ask the question informally. The downside risk is real: signatories that publicly commit and then ship a notable security incident face heightened scrutiny. The pledge is therefore an accelerator for organizations already on a solid trajectory and a meaningful liability for organizations that sign without the underlying capability.
What is the minimum viable evidence package?
A defensible evidence package for the pledge in 2026 contains five elements. A baseline measurement for each of the seven goals at pledge signature date, captured in a versioned document with the methodology spelled out. A quarterly internal review with metrics updated and trajectory tracked, signed by the security engineering lead and the head of product. An annual public summary, typically a blog post or trust report, that publishes the progress. A copy of the vulnerability disclosure policy as published on your website, with the security.txt file linking to it. And a mapping document tying each pledge metric to the underlying SSDF control and the evidence artifact, so an auditor can trace the claim back to the source. Organizations with this package answer pledge questions in customer reviews in under an hour. Organizations without it spend weeks scrambling each time the question is asked.
How Safeguard Helps
Safeguard generates much of the evidence package automatically from the data it already collects. CVE class reduction metrics come out of the SBOM and reachability pipeline by default, tagged by vulnerability category, so the trajectory for memory-safety, injection, and authentication-class CVEs is queryable. Patch time-to-deploy metrics come from the policy gate audit trail, which records when each CVE was introduced and when it was remediated. Griffin AI generates the quarterly summary text in your tone, mapped to the SSDF controls and ready for executive review. TPRM tracks your dependencies' pledge status so your supplier risk story aligns with your customer-facing posture. The compliance evidence stops being a separate workstream and becomes a byproduct of operating the security program.