Secure by Design Roadmap Template (CISA Pledge)

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.

Document control

Approvals

Revision history

Contents

1. Introduction and scope
2. Executive ownership
3. Secure by Design principles
4. Baseline
5. Pledge goals and commitments
6. Memory-safety roadmap
7. Avoiding product security bad practices
8. Roadmap and milestones
9. Evidence register
10. Public reporting
11. Governance, risks and review
12. Glossary and references

1. Introduction and scope

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

1.3 Basis

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

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

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

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

5. Pledge goals and commitments

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.

5.2 Goal G2: Default passwords

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

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.

5.4 Goal G4: Security patches

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

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.

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.

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.

6. Memory-safety roadmap

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

6.2 Roadmap elements

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

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.

8. Roadmap and milestones

9. Evidence register

10. Public reporting

10.1 What we publish

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

11.1 Review cadence

11.2 Risks and dependencies

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

12.1 Glossary

12.2 References

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.