Secure by Design Is Now a Procurement Question

Guidance nobody enforces still arrives on your desk — as a spreadsheet, from procurement, with a deadline. The seven goals were written for software manufacturers and read like aspirations; by the time they reach engineering they are yes/no cells. The honest answer to most is an artefact.

What the Pledge Actually Commits a Signer To

CISA's Secure by Design pledge is structured, in its own words, around seven goals: "Each goal has the core criteria which manufacturers are pledging to work towards, in addition to context and example approaches to achieve the goal and demonstrate measurable progress." The headings: Multi-factor authentication (MFA), Default passwords, Reducing entire classes of vulnerability, Security patches, Vulnerability disclosure policy, CVEs, Evidence of intrusions.

That structure — criterion, context, example approaches — is the first thing lost in summary. An example demonstrates progress; it is not the goal. Confuse them and you answer with the wrong artefact.

No audit sits behind a signature, no attestation, no revocation. The pledge was announced on 8 May 2024 with 68 initial signatories and CISA now describes the list as "hundreds of companies" — none checked. To a buyer, the signature reports what a supplier chose to say about itself.

How a Voluntary Pledge Becomes a Contract Term

The contract term binds you; answering a questionnaire does not. That mechanism lives in a second document. CISA published Secure by Demand, the buyer-side counterpart to its manufacturer guidance. It restates three Secure by Design principles — own customer security outcomes, embrace radical transparency and accountability, build the organisational structure to achieve them — and converts the same subject matter into buyer questions.

Its procurement-lifecycle section says where obligation attaches: buyers pose questions "[b]efore procurement," then "[d]uring procurement, by integrating product security requirements into contract language, as appropriate," and afterwards "continually assessing software manufacturers' product security and security outcomes." Guidance acquires force at the second bullet — not because CISA said so, but because a counterparty wrote a term and you signed it. Consequences of a wrong answer are that term's, and CISA is nowhere in the enforcement path.

It also says why the gap exists, separating enterprise security — "practices to protect a company's own infrastructure and operations" — from product security, "actions the software manufacturer takes to ensure the products they deliver are secure against attackers" — and notes that many procurement standards address the first while "relatively few focus on" the second. An ISO 27001 certificate answers the other question; the same boundary drives Annex A scoping.

This survives the programme. Once a buyer does what Secure by Demand instructs and writes the requirements into contract language, the term binds on its own authority — CISA is not a party to it and cannot release you from it. Build a durable capability, not a response to one agency.

Click to zoom

The Pledge and Secure by Demand Are Not the Same Document

Conflating them makes teams concede requirements nobody asked for. Take the software bill of materials: absent from the pledge's seven goals, present in Secure by Demand's Software Supply Chain Security category, asking whether the manufacturer "generate[s] a software bill of materials (SBOM) in a standard, machine-readable format" enumerating "all third-party dependencies, including open source software components," and expects it to "maintain and share provenance data of third-party dependencies." CISA does ask for SBOMs — in the buyer's document, not the signer's. Sigstore and SLSA are the build-side half.

Retention hardens the same way. The pledge offers a figure as an example — "[f]or cloud service providers and SaaS products, retaining logs for a set timeframe (e.g., 6 months) at no additional charge." The buyer guide states it: "should retain and make available to customers security logs for at least six months at no additional charge." Both scope it to cloud and SaaS providers — not a target for a self-hosted control plane.

Reading the Seven Goals as Operator Requirements

A framing note: CISA wrote Secure by Demand for purchasers questioning software manufacturers. Reading the goals as obligations on whoever ships the software — an internal platform team included — is this article's reading, not CISA's addressee. It holds because the answering artefact is identical either way.

• Goal 2 — default passwords. CISA's definition is narrow: "universally-shared passwords that are present by default across a product," with the expectation that "[a]t the end of provisioning, only the customer should possess their authentication credentials." Artefact: instance-unique credential issuance, and a provisioning test that fails on a surviving shared value.
• Goal 3 — vulnerability classes. Artefact: a written, prioritised roadmap — CISA's example is "[d]eveloping a memory safe roadmap to transition to memory safe languages." Success here "may actually lead to a short-term increase in CVEs," to be "regarded as a success if that class of vulnerability is reduced over the long run."
• Goal 4 — security patches. The criterion: "measurably increase the installation of security patches by customers." Installation, by customers — so the artefact is uptake, trended, and the defaults that moved it. Lifespan communicated at time of sale is a separate example, scoped to "cases where products are end of life and security patches are no longer supported."

Ownership matters as much as the artefact: uptake telemetry to release engineering, credential issuance to provisioning, the VDP to security with legal sign-off, audit policy to the platform team. A row with no owner is answered by whoever is free — how a team ends up asserting what it cannot evidence.

Click to zoom

Goal 1 Asks for Measurable MFA Uptake, Not a Default Toggle

Goal 1's criterion, verbatim: "demonstrate actions taken to measurably increase the use of multi-factor authentication across the manufacturer's products," within one year. Increased use, measured. Two things get substituted for it. The pledge's own examples — "[e]nabling MFA by default for users and administrators" and "[s]upporting standards-based single sign-on (SSO) in the baseline version of the product" — are approaches. Secure by Demand's buyer questions are a third thing: whether the manufacturer supports "integrating standards-based single sign-on (SSO) for customers at no additional cost," and whether, where it manages authentication, it enables "MFA or other phishing-resistant forms of authentication like passkeys by default, and at no cost."

On pricing the pledge is unambiguous: "[o]ut-of-the-box, products should be secure with additional security features such as multi-factor authentication (MFA), logging, and single sign-on (SSO) available at no extra cost." SSO behind an enterprise tier is a commercial decision you may make and may not call secure by default.

For an operator this is identity architecture. A control plane on static credentials has no MFA story; one fronted by an OIDC issuer inherits whatever the identity provider enforces. Two ways to wire it: the legacy --oidc-* flags, and the structured authentication configuration file (--authentication-config, stable since Kubernetes v1.34). They are mutually exclusive — combining them is a misconfiguration and the API server exits with an error. Prefer the config file on new clusters; the excerpt shows flags because most clusters still run them.

# EXCERPT — kube-apiserver command list only. Not a complete manifest.
spec:
  containers:
    - name: kube-apiserver
      command:
        - kube-apiserver
        # ... distribution-specific flags elided ...
        - --oidc-issuer-url=https://<PLACEHOLDER-IDP-HOST>/realms/platform
        - --oidc-client-id=kubernetes
        - --oidc-username-claim=sub
        - --oidc-username-prefix=oidc:
        - --oidc-groups-claim=groups
        - --anonymous-auth=false
        # Auditing needs BOTH: policy selects what is recorded,
        # log-path enables the backend that writes it.
        - --audit-policy-file=/etc/kubernetes/audit/policy.yaml
        - --audit-log-path=/var/log/kubernetes/audit.log
        - --audit-log-maxage=30
        # ... elided ...

Evidence of Intrusions: Your Cluster Is Not Secure by Default Here

Goal 7's criterion: "a measurable increase in the ability for customers to gather evidence of cybersecurity intrusions affecting the manufacturer's products." The three familiar areas — "[c]onfiguration changes or reading configuration settings; [i]dentity (e.g., sign-in and token creation) and network flows, if applicable; and [d]ata access or creation of business-relevant data" — are an example approach, repeated by Secure by Demand as what logs "should cover." Covering them is raw material, not the criterion itself.

Kubernetes makes the gap concrete. The API server audits nothing until told what to audit: pass a policy file "using the --audit-policy-file flag. If the flag is omitted, no events are logged." Not fewer — none. An honest answer is that file, mounted on a running process.

Four levels — None, Metadata, Request, RequestResponse — set how much of each request is kept. RequestResponse records request and response bodies. For a Secret that body is the credential, so auditing Secrets there writes credential material into the log and everything downstream. Secrets belong at Metadata, which still records who read or wrote which object; Kubernetes' own example policy agrees, logging "configmap and secret changes in all other namespaces at the Metadata level." Reserve RequestResponse for RBAC objects, whose bodies carry no credentials and are the record's point.

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages: ["RequestReceived"]
rules:
  # Credential-bearing: Metadata ONLY. Never Request/RequestResponse
  # — the body IS the credential.
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "serviceaccounts/token"]

  # Configuration change and read. Bodies are the evidence here.
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources:
          ["roles", "clusterroles", "rolebindings", "clusterrolebindings"]
  - level: Request
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: ""
        resources: ["configmaps", "namespaces"]
      - group: "apps"
        resources: ["deployments", "daemonsets"]

  # Data access: the interactive paths in.
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods/exec", "pods/portforward"]

  # Noise floor down; catch the rest, identity included.
  - level: None
    users: ["system:kube-scheduler", "system:kube-controller-manager"]
    verbs: ["get", "list", "watch"]
  - level: Metadata

Retention is a separate flag. --audit-log-path "specifies the log file path that log backend uses to write audit events. Not specifying this flag disables log backend," and --audit-log-maxage "defined the maximum number of days to retain old audit log files." Size those against your own obligations, not the six-month figure both documents scope to cloud and SaaS. Rotation is a buffer; durable retention belongs downstream.

Assertions decay; checks do not. This reads a live cluster rather than a belief about one.

#!/usr/bin/env bash
# Evidence about THIS cluster — CISA asks none of these in this form.
set -euo pipefail
fail() { echo "FAIL: $1"; exit 1; }

CMD=$(kubectl --context "${1:?usage: $0 <kube-context> [domain]}" get pod \
  -n kube-system -l component=kube-apiserver \
  -o jsonpath='{.items[0].spec.containers[0].command}')

# 1. Auditing on at all — the artefact behind Goal 7. Says nothing
#    about whether the policy itself is adequate.
grep -q -- '--audit-policy-file=' <<<"$CMD" || fail "no --audit-policy-file: no events logged"
grep -q -- '--audit-log-path=' <<<"$CMD" || fail "no --audit-log-path: backend disabled"

# 2. A federated authenticator, adjacent to Goal 1. ServiceAccount
#    tokens are always accepted and not removable; this asserts an
#    extra path EXISTS, never that one was removed.
grep -qE -- '--(oidc-issuer-url|authentication-config)=' <<<"$CMD" || fail "no OIDC or auth config"

# 3. Anonymous access. Kubernetes hygiene near Goal 2, not a CISA
#    question. Default is true, so an absent flag is a finding.
grep -q -- '--anonymous-auth=false' <<<"$CMD" || fail "--anonymous-auth not false"

# 4. security.txt present and unexpired. The pledge lists this as an
#    EXAMPLE of Goal 5 progress — not a buyer question, not the goal.
if [ -n "${2:-}" ]; then
  EXP=$(curl -fsS "https://${2}/.well-known/security.txt" \
    | sed -n 's/\r$//; s/^[Ee]xpires:[[:space:]]*//p' | head -n1)
  [ -n "$EXP" ] || fail "security.txt missing its mandatory Expires field"
  END=$(date -u -d "$EXP" +%s 2>/dev/null) || fail "unparseable Expires: $EXP"
  [ "$END" -gt "$(date -u +%s)" ] || fail "security.txt expired at $EXP"
fi

echo "PASS: all checks"

Vulnerability Disclosure: The Goal You Can Close This Week

Goal 5 is the cheapest move from no to yes: a publishing task. Four properties — authorise "testing by members of the public on products offered by the manufacturer," commit "to not recommending or pursuing legal action against anyone engaging in good faith efforts to follow the VDP," provide "a clear channel to report vulnerabilities," and allow "public disclosure of vulnerabilities in line with coordinated vulnerability disclosure best practices and international standards." Only the second needs a lawyer.

A machine-readable security.txt sits on the example side — "[p]ublishing a machine-readable description of the vulnerability disclosure policy (e.g., a security.txt file) to better enable discovery by researchers." Publish the policy first, then make it findable. RFC 9116 makes two fields mandatory: Contact, which "MUST always be present," and Expires, which "MUST always be present and MUST NOT appear more than once," recommended "less than a year into the future to avoid staleness." Serve it at /.well-known/security.txt. Renew it with your certificates: an expired file publicly declares the process unmaintained.

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-06-30T23:59:59.000Z
Policy: https://example.com/security/disclosure-policy
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

The CVE Goal, and What Issuing a Record Actually Takes

Goal 6 collapses two things, and the collapse invents a blocker. It asks for "accurate Common Weakness Enumeration (CWE) and Common Platform Enumeration (CPE) fields in every Common Vulnerabilities and Exposures (CVE) record for the manufacturer's products," plus timely CVEs "for, at minimum, all critical or high impact vulnerabilities (whether discovered internally or by a third party) that either require actions by a customer to patch or have evidence of active exploitation."

Getting an ID is neither the hard part nor gated. The CVE Program states "[a]nyone can request a CVE ID for a vulnerability," directing requesters to the CNA "whose scope includes the product affected" or, where that cannot be determined, to a CNA of Last Resort. MITRE goes further: "[i]f a Supplier is not a CNA and there is a vulnerability in one of its products, the preferred method for obtaining a CVE ID is through the Supplier making an ID request from the MITRE CNA-LR."

Becoming a CNA and self-assigning is the separate, gated undertaking. CNA Operational Rules v4.2.0 require CNAs to "develop, document, and operate within a Scope Definition that describes the types of Vulnerabilities for which the CNA will assign CVE IDs," one that "MUST be completed and approved prior to a new CNA being authorized." The rules name "[o]pen source software projects, maintainers, and foundations" among CNA types, so it is not closed to non-vendors. Most internal platform teams will still judge it disproportionate — this article's reasoning, not CISA's, and nothing in Goal 6 asks for it.

The real cost is process, not authorisation: triage that reaches a severity decision quickly, someone who knows which CWE applies, and CPE strings matching how your product is identified in the field.

Failure Modes: Over-Claiming, Badge-Thinking, and Drift

Over-claiming is the expensive one. A yes becomes a contract term, enforceable whether or not the artefact exists, and the gap surfaces when someone asks for the audit log from a window with no policy mounted. Answer "not yet, here is the roadmap": a buyer can price a roadmap, never a discovery.

Badge-thinking treats the signature as the deliverable — a reading CISA already refused, by declining to verify anything and telling buyers to ask for progress reports.

Drift is the quiet one. Audit policy gets dropped in a control-plane rebuild; the security.txt Expires date passes; MFA coverage falls as a new service ships with a shared token. Enforce at admission and in CI rather than reviewing periodically — the case for policy as code. But admission rules sit adjacent to these goals, not inside them: a Kyverno policy rejecting literal credentials in manifests is hygiene, while Goal 2 concerns universally-shared passwords shipped in a product. Keep those apart, or you report a control CISA never asked for.

Exit Ramps and the Long Game

The temptation is to build for the spreadsheet in front of you. Resist: formats change and frameworks get renamed. What a serious buyer wants to know does not — who can authenticate, what was recorded when, how a stranger reports a flaw, what you published about it.

So build the evidence set, not the answers. Keep artefacts in the repository beside the systems they describe — audit policy as version-controlled YAML, the VDP and security.txt as files in the site build, the CWE/CPE runbook beside the release process — and generate responses from it. When the next framework arrives, the mapping changes and the artefacts do not. That is anti-lock-in reasoning applied to compliance, and why a golden path pays: evidence as a by-product.

A regulatory floor is moving underneath this: the EU Cyber Resilience Act puts vulnerability handling and disclosure on a legal footing rather than a pledge. A team for whom these artefacts are routine meets that with a mapping exercise; one answering from memory meets it with a programme.

Practised in proportion this is a small standing cost: a handful of artefacts, each owned, each regenerated by a job rather than remembered. Over a decade it separates a supplier who answers any buyer in an afternoon from one who reorganises engineering every time procurement forwards a spreadsheet.