CISA launched the Secure by Design pledge in May 2024, and 68 software manufacturers signed on at the initial announcement, with hundreds more joining in the two years since. The pledge is voluntary and deliberately non-prescriptive: it asks each signatory to make a good-faith effort toward seven goals within one year and to publish a public progress report showing what changed. There is no certification, no audit, and no penalty for falling short — the entire mechanism is reputational, betting that public commitments plus a published scorecard will move vendors faster than regulation alone. Companies including BeyondTrust, Fortinet, GitLab, Cloudflare, and Dashlane have since published their one-year reports, giving the industry its first real look at what "good-faith progress" looks like in practice, from Fortinet's auto-update rollout to over a million devices to BeyondTrust's claimed progress across all seven commitments. For engineering teams outside the vendor world, the pledge still matters because its seven goals map almost one-to-one onto controls procurement teams and federal customers now expect vendors to demonstrate anyway. This post breaks down what each goal actually asks for and how a team turns it from a pledge line into engineering practice.
What are the seven goals in the pledge, specifically?
The seven goals are: measurably increase MFA usage across products; measurably reduce default passwords; measurably reduce the prevalence of one or more entire vulnerability classes; publish a vulnerability disclosure policy (VDP) that authorizes public testing; include accurate CWE and CPE fields in every CVE record the vendor issues; measurably increase customers' ability to gather evidence of intrusions (audit logging); and demonstrate progress on patch adoption or a related security-update goal. Each is phrased as "demonstrate actions taken" rather than "achieve X%" — CISA leaves the specific metric to the signatory, then publishes whatever the company reports on its Secure by Design Progress Reports page. That looseness is the pledge's biggest strength and its biggest criticism: it produces real, varied evidence, but it also means one company's "measurable reduction" isn't directly comparable to another's.
How is Secure by Design different from Secure by Default?
CISA draws a specific line between the two terms: Secure by Design means security decisions are made during development so the security burden doesn't fall on the customer after the fact — threat modeling before coding, memory-safe language choices, secure defaults baked into the architecture. Secure by Default means the product that ships requires no additional configuration to be safe — MFA already on, no default admin password, verbose logging enabled out of the box, rather than security features sold as a paid add-on or buried behind a setup wizard. A vendor can be "by design" without being "by default": a product engineered with sound architecture can still ship with a blank root password if the default configuration wasn't set with the same rigor. The pledge's goals span both — CWE-accurate CVE records is a "by design" transparency practice, while eliminating default passwords is purely "by default." Engineering teams should treat them as two separate checklists, not one.
Why does the CWE/CPE field on CVE records matter as much as it does?
It matters because an inaccurate or missing CWE field breaks every downstream tool that depends on it — reachability scanners, SCA prioritization engines, and CWE-based policy gates all key off that field to decide severity and blast radius. A CVE published with no CWE, or a generic "NVD-CWE-Other" placeholder, forces every consumer to manually reverse-engineer root cause from the advisory text, which doesn't scale across the tens of thousands of CVEs published annually. This is also one of the few pledge goals with an objectively checkable outcome: a vendor can simply audit its own CVE history in the National Vulnerability Database and count how many records carry an empty or generic CWE field, then set a target to close that gap on every future disclosure. Teams building an internal VDP-to-CVE pipeline should treat "every CVE gets a real CWE and CPE before publication" as a hard gate in the disclosure workflow, not a best-effort field a triage engineer fills in when they have time.
What counts as evidence for "reducing an entire vulnerability class"?
Evidence for this goal generally takes the shape of a root-cause engineering change, not a patch count — memory-safe rewrites that eliminate a class like CWE-787 (out-of-bounds write) instead of buffer-overflow fixes, or replacing string-concatenated SQL with parameterized queries platform-wide to eliminate CWE-89 rather than patching individual injection points as they're found. The distinction CISA draws is between "fixed this bug" and "made this bug class structurally impossible," and it's the same distinction memory-safety advocates have pushed for years: the U.S. National Security Agency and CISA jointly recommended memory-safe languages in 2023 specifically because memory-unsafe code has historically produced the majority of a codebase's critical vulnerabilities year after year. Practically, a team pursuing this goal picks one class it already tracks in its bug tracker or SAST tool — SQL injection, path traversal, XSS — and reports the before/after count over the pledge year, ideally tied to a specific engineering change (a new ORM layer, a template auto-escaping rollout) rather than a general downward trend.
How does a vendor demonstrate measurable progress without over-promising?
The published progress reports that have held up best are the ones anchored to a specific, falsifiable number tied to a specific mechanism — Fortinet's auto-update figure, or a vendor stating the percentage of its fleet with MFA enabled before and after a forced-enrollment rollout — rather than narrative claims like "we take security seriously." Because CISA doesn't audit these reports, the credibility burden sits entirely on the vendor, and a report with vague language invites the same skepticism analysts have leveled at un-scored ESG disclosures. The practical lesson for any engineering org, pledged or not, is to instrument the metric before making the claim: if the goal is reducing default passwords, count how many product installs currently ship with one before setting a target, so the one-year report is a measurement, not a guess.
How can engineering teams operationalize these principles day to day?
Operationalizing the pledge means turning each goal into a policy that runs automatically in the pipeline rather than a point-in-time attestation. NIST's Secure Software Development Framework (SP 800-218) is the closest thing to an implementation guide for the "by design" half of the pledge, breaking practices into groups like preparing the organization (PO), protecting software (PS), producing well-secured software (PW), and responding to vulnerabilities (RV) — and it's the framework most federal attestation forms, including the CISA Secure Software Development Attestation, are built around. Concretely, that looks like policy-as-code gates that block a release when a known-exploited-vulnerability (KEV)-listed CVE is present, require a signed SBOM before deployment, or flag CVE records missing a CWE field before they're published; tools like Safeguard's guardrails enforce exactly that kind of check across CI, registry, and admission control, and its SSDF and EO 14028 attestation tooling helps generate the evidence bundles these reports and attestation forms require. The pledge's real value to a non-signatory team is as a checklist for which controls to automate first.