# Secure by Design Roadmap: [Manufacturer or product line]

> Public-facing commitments and internal roadmap for a software manufacturer
> that adopts Secure by Design: how the organisation applies the three
> principles of the joint guidance *Shifting the Balance of Cybersecurity
> Risk: Principles and Approaches for Secure by Design Software* (CISA and
> partner agencies, October 2023), works towards the seven goals of the
> CISA *Secure by Design Pledge* (May 2024), publishes a memory-safety
> roadmap following *The Case for Memory Safe Roadmaps* (December 2023), and
> avoids the practices listed in *Product Security Bad Practices* Version 2
> (CISA and FBI, January 2025). Each goal has a commitment, measures,
> evidence and a public reporting plan. Worked examples use *Corvid
> Commerce*, a fictional SaaS company. Replace every `[bracketed]` value and
> every row marked *Example*. This is a documentation format, not legal
> advice; review any public statement with counsel before publication.

<!--
Guidance: How to use this template
- Secure by Design is a business commitment, not a security team project.
  The accountable owner should be a named executive (section 2).
- Write commitments as measurable outcomes for customers ("share of tenants
  with MFA enabled"), not as activities ("we will run training").
- Fill section 4 (baseline) with real numbers before you set targets. A
  public target without a baseline cannot be shown to be met.
- Separate what you publish (section 10) from internal detail. Publish
  progress and method; keep exploitable specifics internal.
- The pledge is voluntary and asks signers to show measurable progress
  within a year of signing. You can use this roadmap without signing.
-->

## Document control

<!-- Guidance: Name the executive owner and the products covered. The roadmap is only credible if someone with budget authority signs it. -->

| Field | Value |
|---|---|
| Document ID | [SBD-ROADMAP-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@head-of-product-security] |
| Accountable executive | [@cto or @ceo] |
| Approvers / reviewers | [@ciso], [@cpo], [@legal-counsel], [@communications-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal; section 10 extract is Public] |
| Products in scope | [*Example:* Corvid Storefront (SaaS), Corvid Checkout SDK (JavaScript), Corvid Edge Agent (on-premises connector, C++)] |
| Pledge status | [*Example:* Signed YYYY-MM-DD / Not signed; roadmap adopted voluntarily] |
| Roadmap horizon | [YYYY-MM to YYYY-MM] |
| Public report cadence | [*Example:* Every 6 months] |
| Next review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Accountable executive | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Chief product officer | [@name] | [Decision] | YYYY-MM-DD |
| Legal counsel | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record each change to commitments and targets. Changing a public target silently damages trust; record the change and the reason. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft with baseline measures |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Targets agreed with product leadership |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; public summary published |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Introduction and scope](#1-introduction-and-scope)
2. [Executive ownership](#2-executive-ownership)
3. [Secure by Design principles](#3-secure-by-design-principles)
4. [Baseline](#4-baseline)
5. [Pledge goals and commitments](#5-pledge-goals-and-commitments)
6. [Memory-safety roadmap](#6-memory-safety-roadmap)
7. [Avoiding product security bad practices](#7-avoiding-product-security-bad-practices)
8. [Roadmap and milestones](#8-roadmap-and-milestones)
9. [Evidence register](#9-evidence-register)
10. [Public reporting](#10-public-reporting)
11. [Governance, risks and review](#11-governance-risks-and-review)
12. [Glossary and references](#12-glossary-and-references)

## 1. Introduction and scope

<!-- Guidance: Explain what the roadmap covers and why. Pitfall: scoping only the flagship product; customers judge the weakest product they run. -->

### 1.1 Purpose

This roadmap states how [Manufacturer] takes responsibility for the
security outcomes of its customers. It turns the Secure by Design
principles into dated, measurable commitments per product, and it defines
the evidence and reporting that show progress. It is the manufacturer-level
counterpart to product-level documents such as threat models and security
reviews.

### 1.2 Products in scope

| Product | Type | Deployment | Customers | Primary languages | Notes |
|---|---|---|---|---|---|
| [*Example:* Corvid Storefront] | Enterprise SaaS | Multi-tenant cloud | About 2,300 merchants | TypeScript, Go | Main revenue product |
| [*Example:* Corvid Checkout SDK] | Library | Embedded in customer web pages | About 1,100 merchants | TypeScript | Distributed through a public registry |
| [*Example:* Corvid Edge Agent] | On-premises software | Installed on customer servers to connect point-of-sale systems | About 400 merchants | C++, some Rust | Customer-managed updates; memory-unsafe code |

### 1.3 Basis

| Source | Version and date | Use |
|---|---|---|
| CISA and partner agencies, *Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software* | Updated edition, October 2023 (first edition April 2023) | Three principles (section 3) |
| CISA, *Secure by Design Pledge* | Launched May 2024 | Seven goals (section 5) |
| CISA, NSA, FBI and partner agencies, *The Case for Memory Safe Roadmaps* | December 2023 | Roadmap elements (section 6) |
| CISA and FBI, *Product Security Bad Practices*, Version 2 | January 2025 | Practices to avoid (section 7) |
| NIST SP 800-218, SSDF Version 1.1 | February 2022 | Development practices behind the commitments |

Check cisa.gov/securebydesign for the current versions and the status of
the pledge before publishing. CISA updates this guidance, and new joint
publications appear regularly.

### 1.4 Related documents

- SSDF Practice Attestation (`security/ssdf-practice-attestation`): task-level evidence for development practices
- OWASP SAMM Assessment (`security/samm-assessment`): programme maturity baseline and roadmap
- Vulnerability Disclosure Policy (`security/vulnerability-disclosure-policy`): the public policy for goal 5
- PSIRT Vulnerability Handling (`security/psirt-vulnerability-handling`): CVE and advisory process for goal 6
- SBOM and VEX Policy (`security/sbom-vex-policy`): component transparency
- Secure Coding Standard (`security/secure-coding-standard`): rules that remove vulnerability classes

## 2. Executive ownership

<!-- Guidance: The third principle asks leaders to own security as a business outcome. Name the person, the forum and the resources. Pitfall: delegating ownership to the CISO alone, who rarely controls product priorities. -->

| Item | Commitment |
|---|---|
| Accountable executive | [*Example:* Chief technology officer, named publicly in the summary] |
| Board or executive forum | [*Example:* Quarterly product security review at the executive committee; annual board briefing] |
| Product incentives | [*Example:* Secure by Design measures included in product leadership objectives] |
| Resourcing | [*Example:* 15% of engineering capacity reserved for security and resilience work per quarter] |
| Decision rule | [*Example:* Security defaults are not traded for feature dates without executive sign-off recorded in the decision log] |
| Customer voice | [*Example:* Customer advisory board reviews secure default changes before release] |

Policy statements:

1. The accountable executive MUST approve this roadmap and each change to a
   public commitment.
2. Product leadership MUST include progress on section 5 commitments in
   quarterly business reviews.
3. Security work items on the roadmap SHOULD NOT be deferred more than one
   quarter without executive approval and a recorded reason.

## 3. Secure by Design principles

<!-- Guidance: For each principle, state how the organisation will apply it in its own words, and link to the commitments that implement it. Pitfall: copying the principle names and adding nothing measurable. -->

| ID | Principle (joint guidance) | How we apply it (*Example*) | Implemented by |
|---|---|---|---|
| SBD-P1 | Take ownership of customer security outcomes | Security features are on by default and included in every plan at no extra cost; we remove insecure legacy options on a published schedule | Goals G1, G2, G4, G7; section 7 |
| SBD-P2 | Embrace radical transparency and accountability | We publish complete CVE records, a vulnerability disclosure policy, a memory-safety roadmap and progress reports | Goals G5, G6; sections 6 and 10 |
| SBD-P3 | Lead from the top | A named executive owns this roadmap; progress is reviewed at executive level and resourced explicitly | Section 2; section 11 |

### 3.1 Secure by default

Secure by default means the product is safe in the state the customer
receives it, without extra configuration or cost. Corvid Commerce applies
these rules (*Example*):

- Single sign-on and MFA are available in every plan, not only enterprise
  tiers.
- New tenants start with the most restrictive sensible settings; loosening
  a setting shows the risk in the interface and is logged.
- Security logs needed to investigate an intrusion are included in the base
  product and retained for a stated period.
- Hardening guides are replaced by safe defaults wherever possible; a
  remaining guide describes how to loosen settings, not how to secure them.

### 3.2 Secure product development

Secure by Design depends on development practice. This roadmap relies on the
SSDF practices recorded in the SSDF Practice Attestation and on the maturity
targets in the SAMM assessment. Commitments in section 5 that depend on a
development practice name it in the dependency column of section 8.

## 4. Baseline

<!-- Guidance: Measure before committing. Use the same formula you will report later. Pitfall: choosing metrics only because they are easy to improve. -->

*Example* baseline measured on YYYY-MM-DD for Corvid Commerce.

| Goal | Measure | Formula | Storefront | Checkout SDK | Edge Agent |
|---|---|---|---|---|---|
| G1 MFA | MFA adoption | Active users with MFA / active users | 41% | n/a | 0% (local accounts only) |
| G2 Default passwords | Products or modes shipping with a shared default credential | Count | 0 | n/a | 1 (setup console) |
| G3 Vulnerability classes | Share of vulnerabilities in targeted classes | Vulnerabilities in target classes / all vulnerabilities, trailing 12 months | 38% (injection, access control) | 25% (cross-site scripting) | 61% (memory safety) |
| G4 Security patches | Customers on a supported, patched version within 30 days of release | Customers on patched version at day 30 / customers | 100% (SaaS) | 58% | 34% |
| G5 VDP | Published policy meeting all pledge criteria | Yes or No | Partial | Partial | Partial |
| G6 CVEs | CVE records with CWE and CPE fields | Records with both fields / records published | 70% | 70% | 70% |
| G7 Intrusion evidence | Security event types available to customers | Available event types / event types in the logging catalogue | 55% | n/a | 20% |

## 5. Pledge goals and commitments

<!-- Guidance: One subsection per pledge goal. Each states the goal in your own words, the commitment, the measure, the target and the evidence. Pitfall: targets that do not move the measure from section 4. -->

The pledge asks signers to make a good-faith effort to show measurable
progress on seven goals within a year of signing, and to document how they
did it. The goal summaries below are original paraphrases; read the pledge
for the exact criteria and examples.

### 5.1 Goal G1: Multi-factor authentication

**Goal (paraphrase).** Increase, in a measurable way, the use of MFA across
the manufacturer's products.

| Commitment ID | Commitment | Measure | Baseline | Target | Due |
|---|---|---|---|---|---|
| G1-C1 *(Example)* | Make phishing-resistant MFA (passkeys and security keys) available in all Storefront plans | Plans with phishing-resistant MFA / plans | 1 of 3 | 3 of 3 | YYYY-MM-DD |
| G1-C2 *(Example)* | Require MFA for all administrator accounts in new tenants; prompt existing administrators with a dated opt-out | Administrator accounts with MFA / administrator accounts | 63% | 95% | YYYY-MM-DD |
| G1-C3 *(Example)* | Support customer single sign-on in Edge Agent instead of local accounts | Edge Agent installs using single sign-on / installs on supported version | 0% | 50% | YYYY-MM-DD |

### 5.2 Goal G2: Default passwords

**Goal (paraphrase).** Make measurable progress towards removing default
passwords from the manufacturer's products.

| Commitment ID | Commitment | Measure | Baseline | Target | Due |
|---|---|---|---|---|---|
| G2-C1 *(Example)* | Replace the Edge Agent setup console default credential with a one-time setup code that expires | Releases shipping with a shared default credential | 1 | 0 | YYYY-MM-DD |
| G2-C2 *(Example)* | Offer an update path that forces credential change on existing installs | Existing installs still using the default credential | [Unknown; measure through update telemetry with customer consent] | 0 | YYYY-MM-DD |

### 5.3 Goal G3: Reducing entire classes of vulnerability

**Goal (paraphrase).** Act to significantly and measurably reduce the
prevalence of one or more classes of vulnerability across the products.

| Commitment ID | Commitment | Measure | Baseline | Target | Due |
|---|---|---|---|---|---|
| G3-C1 *(Example)* | Use parameterised data access only, enforced by a static analysis rule that blocks merges (SQL injection, CWE-89) | Injection vulnerabilities found per quarter | 4 | 0 | YYYY-MM-DD |
| G3-C2 *(Example)* | Central authorisation library for all tenant data access (broken access control, CWE-284 family) | Services using the library / services | 60% | 100% | YYYY-MM-DD |
| G3-C3 *(Example)* | Context-aware output encoding by default and a strict content security policy in the SDK (cross-site scripting, CWE-79) | Cross-site scripting vulnerabilities per quarter | 2 | 0 | YYYY-MM-DD |
| G3-C4 *(Example)* | Memory-safety roadmap for Edge Agent (section 6) | Share of Edge Agent vulnerabilities that are memory-safety issues | 61% | Below 20% | YYYY-MM-DD |

### 5.4 Goal G4: Security patches

**Goal (paraphrase).** Increase, in a measurable way, how many customers
install security patches.

| Commitment ID | Commitment | Measure | Baseline | Target | Due |
|---|---|---|---|---|---|
| G4-C1 *(Example)* | Automatic updates on by default for new Edge Agent installs, with a maintenance window the customer controls | Installs on patched version at day 30 | 34% | 80% | YYYY-MM-DD |
| G4-C2 *(Example)* | Publish security fixes for the SDK as patch releases compatible within the major version, with a clear upgrade notice | Merchants on patched SDK version at day 30 | 58% | 85% | YYYY-MM-DD |
| G4-C3 *(Example)* | Separate security updates from feature updates for supported versions | Security fixes released without feature changes / security fixes | 50% | 100% | YYYY-MM-DD |

### 5.5 Goal G5: Vulnerability disclosure policy

**Goal (paraphrase).** Publish a vulnerability disclosure policy that
authorises good-faith testing of the products by the public, commits not to
pursue legal action against good-faith researchers, gives a clear reporting
channel and allows public disclosure in line with coordinated disclosure
practice.

| Commitment ID | Commitment | Measure | Baseline | Target | Due |
|---|---|---|---|---|---|
| G5-C1 *(Example)* | Publish a policy using Vulnerability Disclosure Policy (`security/vulnerability-disclosure-policy`) that covers all three products and includes a safe harbour statement | Pledge criteria met / 4 criteria | 2 of 4 | 4 of 4 | YYYY-MM-DD |
| G5-C2 *(Example)* | Publish a `security.txt` file on each product domain | Domains with a valid file / product domains | 1 of 3 | 3 of 3 | YYYY-MM-DD |

### 5.6 Goal G6: CVEs

**Goal (paraphrase).** Be transparent in vulnerability reporting: include
accurate CWE and CPE information in every CVE record for the products, and
issue CVEs promptly at least for critical or high-impact vulnerabilities
that need customer action or are actively exploited.

| Commitment ID | Commitment | Measure | Baseline | Target | Due |
|---|---|---|---|---|---|
| G6-C1 *(Example)* | Become or partner with a CVE Numbering Authority to publish records for all three products | Qualifying vulnerabilities with a CVE / qualifying vulnerabilities | 75% | 100% | YYYY-MM-DD |
| G6-C2 *(Example)* | Add root-cause CWE and product CPE to every record, reviewed by a second person | Records with CWE and CPE / records | 70% | 100% | YYYY-MM-DD |
| G6-C3 *(Example)* | Publish machine-readable advisories alongside CVE records, per PSIRT Vulnerability Handling (`security/psirt-vulnerability-handling`) | Advisories in machine-readable form / advisories | 0% | 100% | YYYY-MM-DD |

### 5.7 Goal G7: Evidence of intrusions

**Goal (paraphrase).** Increase, in a measurable way, the customer's ability
to gather evidence of intrusions that affect the products.

| Commitment ID | Commitment | Measure | Baseline | Target | Due |
|---|---|---|---|---|---|
| G7-C1 *(Example)* | Include authentication, administrative and API-key events in base Storefront plans at no extra cost, retained for [12] months | Event types available / catalogue event types | 55% | 100% | YYYY-MM-DD |
| G7-C2 *(Example)* | Stream logs to customer security tools through a standard export | Plans with log export / plans | 1 of 3 | 3 of 3 | YYYY-MM-DD |
| G7-C3 *(Example)* | Add local security event logging with tamper evidence to Edge Agent | Event types available / catalogue event types | 20% | 80% | YYYY-MM-DD |

## 6. Memory-safety roadmap

<!-- Guidance: Required for products with significant code in memory-unsafe languages such as C and C++. Follow the six elements of the joint guidance. Pitfall: a roadmap that rewrites nothing; start with the most exposed components found by threat modelling. -->

*The Case for Memory Safe Roadmaps* asks manufacturers to publish how they
will reduce and eventually eliminate memory-unsafe code. *Product Security
Bad Practices* Version 2 adds that manufacturers of products used in
critical infrastructure or national critical functions should publish such
a roadmap for existing products by the end of 2025, with exceptions for
products whose announced end of support is before 1 January 2030. That
date has passed; an in-scope product without a published roadmap is already
outside the expectation. Check the current text for the exact scope.

### 6.1 Inventory of memory-unsafe code

| Component | Language | Size (*Example* KLOC) | Exposure | Risk rank | Plan |
|---|---|---|---|---|---|
| [*Example:* Edge Agent protocol parser] | C++ | 42 | Parses network input from point-of-sale devices | 1 | Rewrite in Rust (phase 2) |
| [*Example:* Edge Agent update client] | C++ | 18 | Downloads and verifies update packages | 2 | Rewrite in Rust (phase 3) |
| [*Example:* Edge Agent local store] | C++ | 25 | Local file handling | 3 | Harden; replace in phase 4 |
| [*Example:* Image processing service] | Go with a C library | 6 (C library) | Processes merchant-uploaded images | 2 | Replace library with memory-safe alternative (phase 2) |

### 6.2 Roadmap elements

| Element | Commitment (*Example*) |
|---|---|
| 1. Phases with dates and outcomes | Phase 1 evaluate memory-safe languages and pilot (YYYY-MM); phase 2 rewrite parser and replace image library (YYYY-MM); phase 3 rewrite update client (YYYY-MM); phase 4 remaining components (YYYY-MM) |
| 2. Date for memory-safe languages in new code | From YYYY-MM-DD all new components are written in a memory-safe language; exceptions need CTO approval |
| 3. Internal developer training and integration | Rust training for the Edge Agent team; build, debugging and tooling integrated in CI; code review guidelines for the new language |
| 4. External dependency plan | Inventory C and C++ dependencies from the SBOM; prefer memory-safe alternatives; contribute or fund upstream where none exist |
| 5. Transparency plan | Publish progress every [6] months: share of code in memory-safe languages, components migrated, lessons learned |
| 6. CVE support plan | Every CVE record carries an accurate CWE so customers and researchers can track memory-safety defects over time (links to G6-C2) |

### 6.3 Interim mitigations

While migration runs, reduce exploitability of the remaining code:

- Enable compiler and platform hardening options and keep them enforced in
  the build (see SSDF task PW.6.2 in the attestation).
- Fuzz all parsers that handle external input, continuously, with crash
  triage in the defect tracker.
- Sandbox high-risk components with reduced privileges.
- Track memory-safety defects as a separate category in vulnerability
  metrics (measure for G3-C4).

## 7. Avoiding product security bad practices

<!-- Guidance: Use the three categories of the CISA and FBI bad practices list as a self-check. Record the status per product. Pitfall: answering for the newest product only. -->

*Product Security Bad Practices* Version 2 groups practices that
significantly raise risk into three categories: product properties,
security features, and organisational processes and policies. The list is
addressed to products used in service of critical infrastructure or
national critical functions, but its practices are a sound baseline for any
enterprise product. Use the list at cisa.gov as the checklist; the rows
below summarise example areas in original words. The memory-safety roadmap
expectation (BP-01) is covered in section 6.

| Check ID | Category | Area (summary) | Storefront | Checkout SDK | Edge Agent | Action |
|---|---|---|---|---|---|---|
| BP-01 *(Example)* | Product properties | New product lines in memory-unsafe languages, or existing products without a published memory-safety roadmap | Compliant | Compliant | Gap | Section 6 |
| BP-02 *(Example)* | Product properties | User input placed directly into queries or commands | Compliant | n/a | Compliant | G3-C1 |
| BP-03 *(Example)* | Product properties | Default passwords | Compliant | n/a | Gap | G2-C1 |
| BP-04 *(Example)* | Product properties | Known exploited vulnerabilities left in shipped components | Compliant | Compliant | Gap | G4-C1 |
| BP-05 *(Example)* | Product properties | Open-source components with critical vulnerabilities at release, and no inventory to find them | Gap (no runtime SBOM) | Compliant | Compliant | SBOM and VEX Policy (`security/sbom-vex-policy`) |
| BP-06 *(Example)* | Product properties | Hardcoded credentials or secrets in source code | Compliant | Compliant | Gap (test key in repository history) | Secret scanning and rotation |
| BP-07 *(Example)* | Product properties | Deprecated cryptographic algorithms or unencrypted sensitive data | Compliant | Compliant | Gap (legacy cipher option) | Remove option in next major release |
| BP-08 *(Example)* | Security features | MFA not available in the base product | Gap (1 of 3 plans) | n/a | Gap | G1-C1, G1-C3 |
| BP-09 *(Example)* | Security features | Customers cannot get evidence of intrusions without paying more | Gap | n/a | Gap | G7-C1, G7-C3 |
| BP-10 *(Example)* | Organisational processes and policies | No published vulnerability disclosure policy that meets the pledge criteria | Gap | Gap | Gap | G5-C1 |
| BP-11 *(Example)* | Organisational processes and policies | CVEs not issued in time for critical or high impact vulnerabilities, or records missing CWE (pledge goal 6 also asks for CPE) | Gap | Gap | Gap | G6-C1, G6-C2 |
| BP-12 *(Example)* | Organisational processes and policies | Support period not clearly communicated for on-premises products | n/a | n/a | Gap | Publish support period per major version |

## 8. Roadmap and milestones

<!-- Guidance: Combine the commitments into one plan with dependencies. Pitfall: all milestones in the last quarter; spread them so that progress reports show movement. -->

| Item ID | Commitment(s) | Milestone | Dependency | Owner | Due | Status |
|---|---|---|---|---|---|---|
| SBD-RM-001 *(Example)* | G5-C1, G5-C2 | Disclosure policy and `security.txt` published | Legal review | [@psirt-lead] | YYYY-MM-DD | In progress |
| SBD-RM-002 *(Example)* | G6-C1, G6-C2 | CVE process with CWE and CPE review live | CNA arrangement | [@psirt-lead] | YYYY-MM-DD | Open |
| SBD-RM-003 *(Example)* | G1-C1, G1-C2 | Phishing-resistant MFA in all plans; administrator MFA required | Identity service release | [@identity-lead] | YYYY-MM-DD | Open |
| SBD-RM-004 *(Example)* | G2-C1, G2-C2 | Edge Agent one-time setup code | Edge Agent release train | [@edge-agent-lead] | YYYY-MM-DD | Open |
| SBD-RM-005 *(Example)* | G3-C1, G3-C2, G3-C3 | Class-elimination controls enforced in CI | SSDF PW.5, PW.7 practices | [@appsec-lead] | YYYY-MM-DD | In progress |
| SBD-RM-006 *(Example)* | G4-C1, G4-C3 | Automatic updates default in Edge Agent | Signed update channel | [@edge-agent-lead] | YYYY-MM-DD | Open |
| SBD-RM-007 *(Example)* | G7-C1, G7-C2 | Base-plan security logs and export | Logging pipeline capacity | [@platform-lead] | YYYY-MM-DD | Open |
| SBD-RM-008 *(Example)* | G3-C4 | Memory-safety phase 2 complete | Training (section 6.2 element 3) | [@edge-agent-lead] | YYYY-MM-DD | Open |
| SBD-RM-009 *(Example)* | All | First public progress report | Sections 9 and 10 | [@head-of-product-security] | YYYY-MM-DD | Open |

```mermaid
flowchart LR
  B["Baseline measured"] --> P["Commitments approved"]
  P --> Q1["Quarter 1: VDP, CVE process"]
  Q1 --> Q2["Quarter 2: MFA, setup codes, class controls"]
  Q2 --> R1["Public progress report 1"]
  R1 --> Q3["Quarter 3: auto-updates, logs, memory-safety phase 2"]
  Q3 --> Q4["Quarter 4: targets reviewed"]
  Q4 --> R2["Public progress report 2"]
```

## 9. Evidence register

<!-- Guidance: Every commitment needs evidence that an outsider could check, or that an auditor could inspect under NDA. Pitfall: evidence that is only a slide deck. -->

| Evidence ID | Commitment | Evidence | Public or internal | Location | Date |
|---|---|---|---|---|---|
| EV-001 *(Example)* | G1-C2 | MFA adoption metric export with formula and query | Internal; figure published | [Metrics store link] | YYYY-MM-DD |
| EV-002 *(Example)* | G2-C1 | Release notes and installer test showing no default credential | Public | [Release notes URL] | YYYY-MM-DD |
| EV-003 *(Example)* | G3-C1 | Static analysis rule configuration and blocked-merge statistics | Internal | [Repository link] | YYYY-MM-DD |
| EV-004 *(Example)* | G4-C1 | Version distribution of Edge Agent installs | Internal; figure published | [Dashboard link] | YYYY-MM-DD |
| EV-005 *(Example)* | G5-C1 | Published disclosure policy | Public | [Policy URL] | YYYY-MM-DD |
| EV-006 *(Example)* | G6-C2 | CVE records with CWE and CPE fields | Public | [CVE list query] | YYYY-MM-DD |
| EV-007 *(Example)* | G7-C1 | Product documentation of log event types and retention | Public | [Docs URL] | YYYY-MM-DD |
| EV-008 *(Example)* | G3-C4 | Share of Edge Agent code in memory-safe languages | Public | [Progress report URL] | YYYY-MM-DD |

## 10. Public reporting

<!-- Guidance: Radical transparency means sharing progress, including misses. Pitfall: reports that only list achievements; customers notice and stop trusting them. -->

### 10.1 What we publish

| Item | Content | Cadence |
|---|---|---|
| Secure by Design summary | Accountable executive, principles, commitments and targets | On approval and on each change |
| Progress report | Measure per commitment against baseline and target, with a short explanation of misses | Every [6] months |
| Memory-safety roadmap | Phases, dates, share of code migrated, lessons learned | Every [6] months |
| Vulnerability disclosure policy and CVE records | As published through normal channels | Continuous |
| Product security documentation | Default settings, log events, update behaviour | With each release |

### 10.2 Publication rules

1. Legal and communications MUST review each public report before release.
2. Reports MUST state the measurement formula and date for each figure.
3. A missed target MUST be reported with the reason and the new date; it
   MUST NOT be removed silently.
4. Reports SHOULD NOT include details that would help an attacker, such as
   unpatched vulnerability specifics or internal architecture.
5. Archive each report so that customers can compare progress over time.

### 10.3 Progress report outline

1. Executive statement from the accountable executive.
2. Summary table of the seven goals: baseline, current, target, status.
3. Highlights and misses with reasons.
4. Memory-safety roadmap update.
5. Changes to commitments since the last report.
6. How to contact the product security team.

## 11. Governance, risks and review

<!-- Guidance: Keep the roadmap alive with a fixed review rhythm and a risk list. Pitfall: commitments that depend on one team with no backup. -->

### 11.1 Review cadence

| Forum | Frequency | Inputs | Outputs |
|---|---|---|---|
| Product security working group | Monthly | Metric dashboards, roadmap status | Escalations, corrections |
| Executive committee | Quarterly | Progress against targets | Resourcing decisions, approved changes |
| Board or risk committee | Annually | Annual summary | Oversight confirmation |
| Full roadmap review | Annually | Baseline refresh, new guidance from CISA and partners | Revised commitments |

### 11.2 Risks and dependencies

| Risk ID | Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| SBD-R-001 *(Example)* | Customers resist forced MFA for administrators | Medium | Medium | Dated opt-out, customer communication, support for single sign-on | [@product-lead] |
| SBD-R-002 *(Example)* | Rust skills shortage delays memory-safety phase 2 | Medium | High | Training budget, external mentoring, phased scope | [@edge-agent-lead] |
| SBD-R-003 *(Example)* | Automatic updates cause customer outages | Low | High | Staged roll-out, rollback, customer-controlled maintenance window | [@release-manager] |
| SBD-R-004 *(Example)* | Public targets missed and reported negatively | Medium | Medium | Realistic targets from baseline; transparent explanation | [@communications-lead] |

### 11.3 Exceptions

A product may be excluded from a commitment only with a written exception
approved by the accountable executive. Each exception states the reason,
the compensating measure, the expiry date and whether it is disclosed in
the public report. Products with an announced end-of-support date may be
excluded from long-term commitments, but not from vulnerability disclosure
and CVE commitments.

## 12. Glossary and references

<!-- Guidance: Keep terms consistent with CISA usage. -->

### 12.1 Glossary

| Term | Meaning in this document |
|---|---|
| Secure by Design | Products designed and built so that security is a core business requirement, not an add-on |
| Secure by default | Products that are safe as delivered, without extra configuration or charges |
| Manufacturer | The organisation that develops and sells or supplies the software |
| Pledge | The voluntary CISA Secure by Design Pledge with seven goals for enterprise software manufacturers |
| Memory-safe language | A programming language that prevents classes of memory errors such as buffer overflows and use-after-free by design |
| CVE | Common Vulnerabilities and Exposures record identifying a publicly disclosed vulnerability |
| CWE | Common Weakness Enumeration entry describing the type of weakness behind a vulnerability |
| CPE | Common Platform Enumeration name identifying the affected product |
| VDP | Vulnerability disclosure policy |

### 12.2 References

| Reference | Use |
|---|---|
| CISA and partners, *Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software*, October 2023 (cisa.gov/securebydesign) | Principles (section 3) |
| CISA, *Secure by Design Pledge*, May 2024 (cisa.gov/securebydesign/pledge) | Goals (section 5) |
| CISA, NSA, FBI, ASD's ACSC, CCCS, NCSC-UK, NCSC-NZ and CERT NZ, *The Case for Memory Safe Roadmaps*, December 2023 | Memory-safety roadmap (section 6) |
| CISA and FBI, *Product Security Bad Practices*, Version 2, January 2025 | Practices to avoid (sections 6 and 7) |
| NIST SP 800-218, SSDF Version 1.1, February 2022 | Development practices |
| SSDF Practice Attestation (`security/ssdf-practice-attestation`) | Evidence of development practices |
| OWASP SAMM Assessment (`security/samm-assessment`) | Maturity baseline |
| Threat Model (`security/threat-model`) | Ranking of memory-unsafe components |
| Software Supply Chain Security Assessment (`security/supply-chain-security`) | Signed updates and provenance |

## Standard and licence note

Based on the joint guidance *Shifting the Balance of Cybersecurity Risk:
Principles and Approaches for Secure by Design Software* (October 2023),
the CISA *Secure by Design Pledge* (May 2024), *The Case for Memory Safe
Roadmaps* (December 2023) and *Product Security Bad Practices* Version 2
(January 2025), published by CISA with US and international partner
agencies. Material authored by CISA is generally a work of the United
States Government and not subject to copyright in the United States. The
joint documents are marked TLP:CLEAR, a sharing marking that allows
distribution subject to standard copyright rules; it is not a licence, and
co-sealed documents may contain partner-agency material that keeps its own
rights. For that reason no text from these documents is reproduced here.
Principle names, goal names, the six roadmap elements
and category names are cited; goal descriptions and all other text are
original paraphrases. Check the current versions and the pledge status at
cisa.gov/securebydesign before relying on this roadmap or publishing a
summary. Corvid Commerce is a fictional company. Original text written for
this collection. Template licence: MIT.