CISA Secure by Design
principles, pledge, and audit-ready evidence

The CISA Secure by Design framework explained

Secure by Design is the principles-based framework the Cybersecurity and Infrastructure Security Agency uses to shift the burden of cyber risk from software customers to software manufacturers. The framework was published in April 2023, expanded with international co-sealers in October 2023, and operationalised through a public Secure by Design Pledge in May 2024 that asks software manufacturers to commit to seven measurable goals over twelve months. CISA frames the work as an industry-wide reset rather than a single product certification: the principles describe the operating posture the manufacturer adopts, and the pledge translates the posture into measurable outcomes.

The framework is read in two directions. Software manufacturers read it as the discipline their product organisation runs against, with executive ownership, a published roadmap, a Vulnerability Disclosure Policy, complete CVE records, eliminated vulnerability classes, and annual progress reporting. Software customers read it as a procurement signal: pledge signatories carry observable obligations against the seven goals, and the framework gives customers a public reference for what to expect from a software supplier without bespoke vendor questionnaires.

The three core principles in operating practice

The framework names three principles that each carry concrete operational consequences. Programmes that read the principles as slogans miss the operating discipline; programmes that read them as obligations end up with a roadmap, a published VDP, an executive owner, and a year-over-year measurement record.

The seven goals of the Secure by Design Pledge

The pledge is the measurable instrument underneath the principles. Each goal asks for a measurable change over twelve months, with the manufacturer publishing the baseline, the target, and the methodology. The goals span identity, default credentials, vulnerability classes, patching, disclosure, CVE quality, and customer-side investigative evidence. They are weighted toward outcomes the customer can observe rather than internal manufacturer process metrics.

Manufacturer, customer, and CISA responsibility split

Secure by Design names a responsibility split that is not symmetric. The manufacturer carries the operational obligations the framework describes; the customer carries procurement and operating discipline that reads against the manufacturer posture; CISA carries the framework, the pledge, the public list of signatories, and the federal procurement guidance that aligns with the framework. The asymmetry is the point: the framework exists to move the burden, not to redistribute it evenly.

How a Secure by Design programme operates in practice

A Secure by Design programme runs as a structured engagement rather than an annual report. The work happens in phases that build on each other, and the engagement record carries forward across pledge years so the next cycle starts from the prior baseline rather than a blank page. The lifecycle below is the pattern most manufacturers run when the SbD posture is treated as a real operating discipline.

1. 1Sign or commit privately against the seven pledge goals. Establish baseline measurements per goal, name the executive owner, and set the year-one targets so the eventual pledge progress report is reproducible rather than reconstructed.
2. 2Build the secure-by-design roadmap as a living engagement record. Name each vulnerability class targeted for elimination, the mechanism, the affected products, the measurement source, and the named owner. Treat the roadmap as a tracked engagement rather than a slide deck refreshed quarterly.
3. 3Run the secure-default review across the product line. Audit the default password posture, the MFA support, the SSO availability, the audit log accessibility, and the patching default. Open findings against each gap with severity, owner, and a remediation plan that ties to the pledge goal it serves.
4. 4Operate the Vulnerability Disclosure Policy. Publish it at /security or the manufacturer-equivalent canonical URL, route inbound reports to a triaged intake, log the receipt-to-acknowledgement-to-fix-to-disclosure timeline per report, and report the aggregate VDP throughput annually.
5. 5Run CVE record discipline. File a CVE for every customer-affecting vulnerability that ships a fix, populate the CWE field, list the affected products and version ranges, link the fix advisory, and avoid the partial-CVE pattern that omits material fields.
6. 6Report progress publicly. Publish the year-one pledge progress report, the methodology, the baseline-to-target movement per goal, and the planned year-two work. The reporting itself is the accountability mechanism the framework relies on.

Failure modes that cost manufacturers the year-one review

The framework is unforgiving about a small number of patterns that look responsive on the surface and read poorly when the pledge progress report is written. The patterns below are the ones CISA names directly in the Secure by Design alerts and the pledge guidance, and the ones product security teams routinely fall into when the work is run as a marketing track rather than an operating track.

Evidence the framework expects to see, organised against the pledge

Pledge progress reports that read well are the ones that draw from a live operating record rather than from documents reconstructed at the year-end. Build the evidence pack as the work happens, retain raw evidence alongside the structured engagement record, and tie every artefact back to the principle and pledge goal it supports. The pledge progress report reads the way the underlying record reads.

How Secure by Design relates to NIST SSDF, OWASP, and the wider regime

Secure by Design is one framework inside a wider product security picture. Manufacturers operating across federal procurement, regulated industries, and global markets usually find that a single underlying body of evidence satisfies several frameworks when it is structured against principles, goals, and observable outcomes rather than against a single framework template. The relevant comparison points include:

• The NIST SSDF implementation guide covers Secure Software Development Framework (SP 800-218) practice groups and implementation work that the federal Secure Software Development Attestation Form consumes, and the CISA SSDA form guide walks through the form itself, the four practice clusters, POAMs, 3PAOs, and the False Claims Act exposure on the signing officer. SbD is the principles framework; SSDF is the practice framework underneath; SSDA is the federal evidence package. A manufacturer evidencing SSDF practices already holds most of the artefacts SbD pledge reporting asks for.
• The OWASP SAMM framework page covers the OWASP Software Assurance Maturity Model and the practice-level maturity ladder that maps cleanly to SbD operating posture. SAMM gives the maturity vocabulary; SbD gives the public commitment vocabulary.
• The OWASP ASVS framework page covers the Application Security Verification Standard. ASVS verification levels are the mechanism many manufacturers use to evidence the secure-default posture and the vulnerability-class elimination commitments under SbD goal 3.
• The SBOM guide and the VEX guide cover the supply-chain transparency artefacts that map to SbD goal 6 (CVE completeness) and the customer-facing evidence the pledge expects manufacturers to publish alongside their products.
• The SLSA framework guide covers the build-integrity scaffold (in-toto provenance, sigstore signing, hardened build platforms) that turns the SbD transparency narrative into verifiable evidence. Manufacturers running SLSA L2 or L3 hold a build-side audit trail that pairs with the SBOM, VEX, and SSDF evidence the pledge expects.
• The ISO 27001 framework page and the SOC 2 framework page cover information security management obligations that overlap with SbD principle 3 (organisational structure and leadership). A mature ISMS or SOC 2 control environment already holds most of the executive ownership artefacts SbD principle 3 expects.
• The CMMC framework page covers Cybersecurity Maturity Model Certification for the defence industrial base. Manufacturers selling into DoD-adjacent markets read SbD and CMMC together; the SbD pledge progress report and the CMMC assessment package draw from a shared evidence base.
• The CISA KEV catalog guide covers the Known Exploited Vulnerabilities catalog. SbD goal 3 (vulnerability-class elimination) reads against KEV class breakdowns; manufacturers eliminating injection, memory unsafety, or path traversal classes can demonstrate the customer-side impact by reading their progress against the KEV class distribution.
• The CISA Cybersecurity Performance Goals (CPGs) framework page covers the customer-side baseline that complements SbD. Where SbD names the manufacturer obligations, the CPGs name the prioritised cybersecurity practices the customer organisation adopts as a voluntary baseline. Both publications are CISA outputs and read against a shared NIST CSF 2.0 spine, so manufacturer-side and customer-side cyber posture can be tracked on one evidence pack.

Where SecPortal fits in the Secure by Design workflow

SecPortal is the operating layer for the Secure by Design programme, not a replacement for the manufacturer accountable for the principles or for CISA running the framework. The platform handles the SbD roadmap, vulnerability-class elimination work, default-credential audits, MFA adoption tracking, VDP intake records, CVE discipline, and the pledge progress evidence so the cycle runs as a structured workflow rather than a slide deck refreshed quarterly. The same workspace that hosts the SbD roadmap hosts the SAST, SCA, authenticated DAST, and pentest evidence the principles and pledge goals consume, so the line from artefact to outcome stays traceable.

The vulnerability-class elimination work is where most of the pledge progress lives. Findings raised against memory unsafety, injection, path traversal, command injection, and cross-site scripting classes need owners, deadlines, and verification evidence that walks back to the goal they affect. The remediation tracking workflow keeps that line auditable. The retesting workflow keeps the verification evidence paired to the original finding rather than opening a parallel record. The vulnerability prioritisation workflow sets which classes the SbD roadmap is eliminating in the next pledge year, and the security leadership reporting workflow carries the executive accountability principle 3 names.

For internal teams running the Secure by Design programme inside a software vendor, the product security teams workspace bundles the platform with security review intake, security champion portal, and PSIRT-style disclosure workflow that the SbD VDP commitment relies on. For application security functions that own the per-release authenticated DAST and SAST work that feeds the pledge roadmap, the AppSec teams workspace covers the same mechanics from the engineering-adjacent angle. For security leaders who carry the executive ownership principle 3 expects, the CISOs and security leaders workspace covers the program-level reporting model that sits on top of the SbD operating record.

Customer-side teams reading SbD as a procurement signal can use the GRC and compliance teams workspace and the vulnerability management teams workspace to track supplier SbD posture alongside their internal vulnerability programme. The vulnerability acceptance and exception management workflow is the place where unsupported supplier defaults become a documented exception rather than an undocumented inheritance.

For programmes that want continuous detection and trend evidence between annual SbD pledge cycles, the continuous monitoring capability and the code scanning capability produce the cadence and coverage record that goal 3 (vulnerability-class elimination) and goal 7 (customer evidence of intrusions) read against. For analytical context on how product security findings age across remediation cycles, the vulnerability remediation throughput research covers what tends to happen to SbD roadmap items when the cycle does not carry forward against a structured engagement record, and the security control drift research covers how secure-default postures erode between pledge progress reviews when the audit is run only at announcement time.