Secure by Design: CISA's Seven Goals as Release Gates

Q: What is the difference between the CISA Secure by Design pledge and an engineering contract?

The pledge is a voluntary, non-binding public commitment by a software manufacturer to demonstrate measurable progress on seven outcomes within one year of signing: increased multi-factor authentication, fewer default passwords, a measurable reduction in one or more vulnerability classes, more customers installing patches, a published vulnerability disclosure policy, transparent CVE records and better customer ability to gather evidence of intrusion. CISA states on the pledge page that it does not enforce or verify adherence. An engineering contract takes each of those outcomes and names the mechanism, the measurement and the consequence: a gate in the software delivery lifecycle that fails a build, blocks a release or raises an alert when the outcome is not met. The test is whether a commitment can fail something. If it cannot, it remains a pledge whatever the document calls it, and a customer's security review will eventually find the gap.

Q: How do you turn 'reduce a class of vulnerability' into something a pipeline can enforce?

Use a ratchet. Choose one class that matters for your product: memory safety for C and C++ code, injection for web products, cross-site scripting for front ends. Measure the current count of findings for that class with static analysis and from your own CVE history, and commit that number to the repository. Any pull request that would raise the count is blocked until the new finding is fixed or explicitly justified; any pull request that lowers it updates the committed number. The class can only shrink. The ratchet has a known weakness, which is that teams can satisfy the detector by suppressing rules or moving code out of its view, so the second measurement is the CVE record: if the class keeps appearing in published advisories while the ratchet shows it falling, the detector is measuring the wrong thing and the quarterly review should change either the detector or the class.

Q: Which of the seven Secure by Design goals are product decisions rather than code decisions?

Three. Multi-factor authentication on by default with a phishing-resistant option at no extra cost, automatic updates on by default where the deployment model allows, and audit logging of security-relevant events in the baseline product tier rather than a premium one. Each of these costs margin or roadmap, and each is the kind of decision a pipeline cannot take on the organisation's behalf: a contract test can verify that audit events exist for every privileged action, but it cannot make those logs visible to a customer whose tier does not include them. CISA's Product Security Bad Practices guidance names the absence of MFA support and the withholding of security artefacts from the baseline product as bad practices in their own right. If leadership has not agreed to ship these defaults, the honest position is that those goals are pledges at your company, and the progress report should say so rather than describe activities.

Q: Where in the delivery pipeline should each gate sit?

Where the fact it checks becomes decidable, which is not the same place for every gate. Seeded-credential scanning and the vulnerability-class ratchet are decidable at pull-request time and should block merges. Known-exploited-vulnerability and critical-dependency checks are decidable at build time against the software bill of materials. Upgrade-path tests from the two previous shipped versions, the presence of an advisory record for every security fix and the audit-log contract test are decidable at release and should block it. The presence of a disclosure policy and security.txt is decidable at deployment by probing production. Two of the seven, MFA adoption and patch age across the installed base, are only measurable in production and are reviewed on a cadence rather than gated in the pipeline. Placing a gate where its fact is not yet available produces either a rubber stamp or a permanently overridden blocker.

Q: How do the Secure by Design pledge, NIST SSDF, SLSA and the EU Cyber Resilience Act relate to each other?

They are four different kinds of document and none of them is the contract. The pledge is a commitment to outcomes with a one-year clock. NIST SP 800-218, the Secure Software Development Framework, is a catalogue of practices with identifiers such as PW.5.1 and PW.9.1, final at version 1.1 since February 2022 with a version 1.2 draft published in December 2025; CISA's own bad-practices guidance cross-references SSDF identifiers for each item, which makes them the natural vocabulary for a gate table. SLSA, at version 1.2, defines levels for one property only, the integrity of builds and source, and is the right target for the signed-build step and nothing else. The Cyber Resilience Act is law, with conformity, SBOM, vulnerability-handling and incident-reporting duties, and its reporting obligations have applied since 11 September 2026 for products sold into the EU. Use SSDF identifiers as the shared vocabulary, SLSA for the build step, the bad-practices list as things the pipeline must refuse, and the pledge as the public summary.

Q: What should a release gate for security patches actually check, given that installing a patch is the customer's action?

The gate checks the thing engineering controls, which is whether the patch can be installed. Every release passes an upgrade test from at least the two previous shipped versions, including data migration and rollback, before it is called released; a security fix that fails that test is a fix that exists but has not shipped. The product decision underneath is automatic updates on by default, with an opt-out rather than an opt-in, for every deployment model where that is possible. The measurement is patch age across the installed base, and the number worth publishing is the 90th percentile rather than the median, because the median hides exactly the slow-patching customers who will be the ones breached. CISA's bad-practices list also treats shipping a release that contains a component on the Known Exploited Vulnerabilities catalogue as dangerous, so the build-time KEV check belongs alongside this gate.

Q: What are the gates you should not build?

Do not gate releases on CVSS base score alone, because the score says nothing about whether the vulnerable code is reachable in your product; exploitability signals such as the KEV catalogue and EPSS are the right inputs for a shipping decision, and a CVSS gate tends to block unreachable criticals while a KEV-listed component with a medium score ships. Do not gate on 'no critical dependencies' without a reachability check, or the gate will be permanently red and permanently overridden. Do not turn the memory-safety goal into a rewrite mandate for an existing product; CISA's guidance targets new product lines and asks for a published roadmap for existing ones, and parameterised queries shipped next sprint deliver more safety than a rewrite that stalls for two years. And do not build a gate whose only owner is the security team, because a gate without a product owner is one the product team will route around.

Q: How should a company answer a customer's Secure by Design questionnaire honestly?

With the gate table and its history rather than with the signature or the policy. For each of the seven goals, state the gate, the metric, the current value and the baseline it is measured against, and say plainly which goals are enforced in the pipeline, which are enforced in the product and which are still intentions. A questionnaire answer that says MFA is available when adoption is a small fraction of tenants, or that describes a disclosure policy as evidence for the other six goals, will not survive a serious review, and CISA's Secure by Demand guidance is explicitly teaching buyers to ask for the mechanism rather than the commitment. A mature organisation can publish its MFA share by role, its patch-age distribution, its CVEs per class per quarter and its report-acknowledgement time, and at that point the pledge is a convenient summary of a table the company already maintains.