Apply CISA Secure by Design: principles, pledge goals and evidence

Secure by Design is a CISA initiative aimed at software manufacturers, not their customers. Its core document, "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software", was first published in April 2023 and revised on 25 October 2023 by CISA with 17 US and international partners. It argues that the burden of security should move from customers to manufacturers, and sets out three principles with tactics for each.

On 8 May 2024 CISA launched the Secure by Design Pledge with 68 signers. Signers commit to a good-faith effort toward seven goals and to publish measurable progress within a year, or tell CISA what they tried. On 10 October 2026 the pledge page still invited enterprise software manufacturers to join, CISA's signer page listed 393 companies, and a progress-reports page linked company reports. The pledge is voluntary and not legally binding, and CISA states that it does not enforce or verify adherence.

Around the pledge, CISA publishes Product Security Bad Practices (version 2.0, January 2025, with the FBI), Secure by Design Alerts on classes such as SQL injection, cross-site scripting, OS command injection, directory traversal and default passwords, memory-safety guidance, and Secure by Demand guides for buyers. Its CISA Vulnerability Review of fiscal years 2024 and 2025, published on 26 August 2026, again stresses reducing entire classes of vulnerability rather than fixing individual flaws after discovery.

Each principle has an explanation and a list of ways to demonstrate it in the CISA document. The table gives the engineering reading of each one.

The CISA document defines secure by default as products that resist prevalent exploitation techniques out of the box, without added charge, and that make customers aware when they move away from safe defaults. Secure configuration should be the baseline, and security features should not be sold as extras.

It also recommends replacing hardening guides, which list the changes a customer must make to become secure, with loosening guides, which ship the product secure and explain the risk of each change a customer might make. A practical reading: treat each step in a hardening guide as a default that should probably change.

• No shared default credentials; first-run setup creates instance-unique credentials or a time-limited setup token.
• MFA available to every user and required for administrators; SSO in the base plan.
• Audit logs of authentication, administration and configuration changes in the base plan.
• Dangerous features off by default, with a warning that names the risk when they are turned on.
• Automatic security updates where the deployment model allows it.

Each goal is phrased as something to demonstrate within one year of signing. The table restates it and turns it into actions and evidence. The site guides in the last column cover the engineering detail.

Product Security Bad Practices lists 13 practices CISA and the FBI call dangerous for software used in critical infrastructure or national critical functions. Version 2.0 added insecure cryptography, hardcoded credentials and undefined support periods. The document is non-binding, but it is the clearest list of what CISA considers indefensible, and most items can be checked automatically.

CISA's "The Case for Memory Safe Roadmaps" (6 December 2023, with the NSA, the FBI and agencies in Australia, Canada, the UK and New Zealand) asks manufacturers to publish a roadmap for eliminating memory-safety vulnerabilities. Product Security Bad Practices version 2.0 sets the expectation that new product lines use memory-safe languages where alternatives exist and that existing products have a published roadmap by the end of 2025, prioritizing components such as network-facing code and cryptographic operations. Products with an announced end of support before 1 January 2030 are excluded. On 24 June 2025 the NSA and CISA added "Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development", which covers adoption barriers and incremental approaches.

For engineering, a roadmap is a list of components with dates: which new code is written in a memory-safe language, which C or C++ components are rewritten or isolated first, and which compiler and runtime hardening applies meanwhile. The guides at /domains/appsec/platform-security/memory-safety-c-cpp/ and /domains/appsec/platform-security/rust-unsafe-ffi/ cover the hardening and the boundary between Rust and C.

Keep one register per product that names, for each goal, the actions taken, a metric with its baseline and current value, the script or query that produces it, and the evidence a customer could read. It doubles as the outline of a public progress report. The example is fictional.

# Evidence register for the seven Secure by Design pledge goals. One entry per goal and product.
product: Ledgerly (fictional SaaS)
period: 2026-01-01/2026-12-31
goals:
  - goal: mfa
    actions: [MFA required for admins at first sign-in, passkeys offered to all users, SSO in the base plan]
    metric: {name: admins with any MFA, baseline: 61%, current: 100%, source: mfa_adoption.sql}
    evidence: [quarterly MFA adoption export, release note announcing admin MFA]
  - goal: default-passwords
    actions: [installer generates a random per-instance admin password, setup token expires after first use]
    metric: {name: product lines shipping a shared default password, baseline: 1, current: 0}
    evidence: [installer test test_no_shared_default_password, appliance build checklist]
  - goal: vulnerability-classes
    classes: [CWE-89, CWE-79]
    actions: [ORM-only data access enforced by a lint rule, auto-escaping templates with no raw-HTML helper]
    metric: {name: new CVEs with CWE-89 or CWE-79, baseline: 4 per year, current: 0 in two quarters}
    evidence: [lint rule and CI run, CWE trend from our CVE records]
  - goal: security-patches
    actions: [automatic updates on by default for the agent, SaaS patched by us]
    metric: {name: agents on a supported version 30 days after release, baseline: 48%, current: 91%}
    evidence: [version telemetry report]
  - goal: vdp
    actions: [VDP with safe harbor published, security.txt on every domain]
    evidence: ["https://ledgerly.example/security/policy", "https://ledgerly.example/.well-known/security.txt"]
  - goal: cves
    actions: [CNA scope covers all products, CVE policy published, CWE and CPE in every record]
    metric: {name: our CVE records with CWE and CPE, baseline: 40%, current: 100%, source: check_cve_records.py}
    evidence: [CVE policy page, CI job output]
  - goal: evidence-of-intrusions
    actions: [audit log of admin, configuration and authentication events in the base plan, 13-month retention]
    evidence: [audit log documentation, log schema]

The pledge gives "aggregate statistics of MFA adoption over time, broken down by user type and MFA type" as an example of measurable progress. The query reports, per user type, the share of active users with any second factor, with a phishing-resistant factor (WebAuthn passkeys or security keys) and with SMS only, as of a given date. Run it monthly and keep the history. With a sample of four admins and five active standard users it returned 75%, 25% and 25% for admins and 40%, 20% and 20% for standard users.

-- MFA adoption by user type and strongest factor (Secure by Design pledge goal 1).
-- users(id, role, active); mfa_factors(user_id, kind, enrolled_at) with kind in ('sms', 'totp', 'webauthn').
WITH strongest AS (
  SELECT u.id,
         u.role,
         MAX(CASE f.kind WHEN 'webauthn' THEN 3 WHEN 'totp' THEN 2 WHEN 'sms' THEN 1 ELSE 0 END) AS level
  FROM users AS u
  LEFT JOIN mfa_factors AS f
    ON f.user_id = u.id AND f.enrolled_at < :as_of
  WHERE u.active = 1
  GROUP BY u.id, u.role
)
SELECT role,
       COUNT(*) AS users,
       ROUND(100.0 * SUM(level > 0) / COUNT(*), 1) AS any_mfa_pct,
       ROUND(100.0 * SUM(level = 3) / COUNT(*), 1) AS phishing_resistant_pct,
       ROUND(100.0 * SUM(level = 1) / COUNT(*), 1) AS sms_only_pct
FROM strongest
GROUP BY role
ORDER BY role;

The CVE goal asks for accurate CWE and CPE fields in every CVE record for your products, and Bad Practice 11 calls a missing CWE dangerous. The script reads each record's CNA container from the CVE Services API and fails when problemTypes has no CWE or affected has no CPE. Run it in CI over the CVE IDs your organization published.

Run against public records on 10 October 2026, it passed CVE-2024-3094 (CWE-506, six CPEs) and CVE-2026-34480 (CWE-116, one CPE), and failed CVE-2021-44228, whose CNA record has CWEs but no CPE, and CVE-2023-22894, whose CNA record has neither. CPE is optional in the CVE record format; the pledge asks for it anyway because scanners match on it.

"""Check that your published CVE records carry a CWE and a CPE (Secure by Design pledge goal 6).

Usage: python check_cve_records.py CVE-2026-0001 CVE-2026-0002 ...
Reads the CNA container of each record from the CVE Services API (CVE JSON 5.x).
"""
import json
import sys
import urllib.request

API = "https://cveawg.mitre.org/api/cve/"


def cna_container(cve_id):
    with urllib.request.urlopen(API + cve_id, timeout=30) as resp:
        return json.load(resp)["containers"]["cna"]


def check(cve_id):
    cna = cna_container(cve_id)
    cwes = sorted(
        {d["cweId"] for p in cna.get("problemTypes", []) for d in p.get("descriptions", []) if "cweId" in d}
    )
    cpes = sorted({c for a in cna.get("affected", []) for c in a.get("cpes", [])})
    problems = []
    if not cwes:
        problems.append("no CWE in problemTypes")
    if not cpes:
        problems.append("no CPE in affected[].cpes")
    return cwes, cpes, problems


if __name__ == "__main__":
    failed = 0
    for cve_id in sys.argv[1:]:
        cwes, cpes, problems = check(cve_id)
        status = "OK  " if not problems else "FAIL"
        failed += bool(problems)
        print(f"{status} {cve_id} cwe={','.join(cwes) or '-'} cpes={len(cpes)} {'; '.join(problems)}")
    sys.exit(1 if failed else 0)

Secure by Design is guidance. Several obligations ask for overlapping outcomes, but none of them is satisfied by citing the pledge, and the pledge does not satisfy them. Map each obligation separately, as described in /frameworks/control-mapping-and-evidence/.

• Signing the pledge and publishing a statement, with no metric or baseline behind each goal.
• Counting CVEs as failure. CISA notes that better reporting can raise CVE counts in the short term; measure the trend by CWE class instead.
• Keeping security features in premium tiers. Logging, SSO and MFA in the base product are central to secure by default.
• Treating a hardening guide as a fix. Each manual hardening step is a default that should change.
• Writing a memory-safety roadmap with no component list or dates.
• Mapping the pledge to the CRA or another obligation as if it were equivalent.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. CISA: Secure by Design Alerts
2. CISA and partners: Shifting the Balance of Cybersecurity Risk (Secure by Design principles). Revised 25 October 2023.
3. CISA: Secure by Design Pledge (goals and scope)
4. CISA: Secure by Design Pledge signers
5. CISA: Announcement of the pledge with 68 signers (8 May 2024)
6. CISA and FBI: Product Security Bad Practices. Version 2.0 (17 January 2025).
7. CISA and partners: The Case for Memory Safe Roadmaps. 6 December 2023.
8. NSA and CISA: Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development. 24 June 2025.
9. CISA Vulnerability Review: fiscal years 2024 and 2025. 26 August 2026.
10. UK DSIT: Software Security Code of Practice. Published 7 May 2025, updated 15 January 2026.
11. CVE Services API: CVE record by ID (CVE-2024-3094)

Reference information

Tags

Memory safetySecure defaults and frameworksAppSec programs

SDLC phase

Security program

Role

AppSec engineersSecurity leaders

Download this guide as Markdown

Continue exploring