Secure by Design: A Guide for Manufacturers (CISA)

Per CISA Secure by Design Principle 3: organizational structure. Requirements include (a) Senior Leader Accountability for product security + (b) Security Engineers Embedded in Product Teams + (c) Internal Cybersecurity Sales Force for product security + (d) Maintain Security Within the Lifecycle including legacy + (e) Memory Safety Roadmap.

• CISA SBD evidence for CISABD-3

• customer security ownership + transparency partial

Per CISA Secure by Design Principle 1: take ownership of customer security outcomes. Requirements include (a) Secure by Default Configuration + (b) Eliminate Default Passwords + (c) Free Security Features for All Tiers + (d) Automatic Security Updates + (e) Reduce hardened configurations as buyer responsibility + (f) maintain transparency on security claims.

• CISA SBD evidence for CISABD-1

• customer security ownership + transparency partial

Use memory-safe programming languages (Rust, Go, Java, C#, Python) for new development. Create roadmaps to migrate existing code from C/C++ to memory-safe alternatives.

• Memory safe language adoption plan
• SAST evidence
• Threat model artifacts
• SBOM

• C/C++ legacy code unaudited
• No threat modelling
• Dependencies pinned without scanning

Use parameterized queries or prepared statements for all database interactions. Eliminate SQL injection as a class of vulnerability.

• Memory safe language adoption plan
• SAST evidence
• Threat model artifacts
• SBOM

• C/C++ legacy code unaudited
• No threat modelling
• Dependencies pinned without scanning

Use web template frameworks that automatically escape output by default. Eliminate cross-site scripting (XSS) as a class of vulnerability.

• Memory safe language adoption plan
• SAST evidence
• Threat model artifacts
• SBOM

• C/C++ legacy code unaudited
• No threat modelling
• Dependencies pinned without scanning

Implement phishing-resistant authentication (FIDO2/WebAuthn, PKI) as the default. Support passwordless authentication where feasible.

• Memory safe language adoption plan
• SAST evidence
• Threat model artifacts
• SBOM

• C/C++ legacy code unaudited
• No threat modelling
• Dependencies pinned without scanning

Adopt and implement the NIST Secure Software Development Framework (SSDF) or equivalent. Document and attest to secure development practices.

• Memory safe language adoption plan
• SAST evidence
• Threat model artifacts
• SBOM

• C/C++ legacy code unaudited
• No threat modelling
• Dependencies pinned without scanning

Conduct threat modeling for all major features and architectural changes. Use established methodologies (STRIDE, PASTA, attack trees).

• Memory safe language adoption plan
• SAST evidence
• Threat model artifacts
• SBOM

• C/C++ legacy code unaudited
• No threat modelling
• Dependencies pinned without scanning

Maintain up-to-date inventory of all dependencies. Automate vulnerability scanning of dependencies. Promptly update or replace vulnerable components.

• VDP policy
• CVE issuance procedure
• SBOM publication pipeline
• Security advisory archive

• No CNA enrollment
• SBOM not published
• Advisories vague

Issue CVEs for security defects with CWE root cause and accurate severity, supporting customer triage.

• CNA assignment or coordination
• Advisory template with CWE and CVSS
• Past advisories with root cause

• Marketing-led advisories without CWE

Provide customers with logs and telemetry sufficient to detect intrusion, by default and without paywalls.

• Default log content documentation
• Pricing showing logs included
• Log retention defaults

• Audit logs only in premium tier

Adopt a documented secure SDLC aligned to NIST SSDF, with threat modeling, secure coding, and security testing.

• SSDF mapping
• Threat models for major features
• SAST, DAST, SCA tooling output

• Threat models created once and never updated

Generate, maintain, and share an SBOM for each product release; track upstream provenance.

• SBOM in CycloneDX or SPDX
• Distribution mechanism to customers
• Upstream provenance attestation

• No SBOM for legacy products
• SBOM shared only on request

Track, evaluate, and contribute back to open source dependencies; respond to OSS vulnerabilities quickly.

• OSS policy
• Dependency monitoring tool output
• Upstream contribution records

• Forked OSS with no upstream sync

Track and publish customer-facing metrics such as MFA adoption, patch adoption, and incident reduction.

• Public transparency report
• Internal dashboard
• Year-over-year trend

• Only internal metrics, never published

No hardcoded credentials, keys, or tokens in shipped products; rotate compromised secrets promptly.

• Secret scanning in CI
• Architecture decision records
• Rotation procedures

• Secrets in firmware images

All product interfaces, including local console and management protocols, require authentication.

• Interface inventory with auth status
• Test evidence
• Deprecation plan for anonymous access

• Local console without auth
• Telnet still available

Provide customers built-in mechanisms for backup, configuration export, and recovery without dependency on the vendor.

• Backup feature documentation
• Restore tests
• Customer guidance

• Restore requires vendor services engagement

Aim to make hardening guides shorter over time by moving controls into secure defaults.

• Hardening guide version history
• Defaults migration backlog
• Customer-friendly setup wizard

• Hardening guide growing year over year

Publicly sign the CISA Secure by Design Pledge and report progress against the seven goals.

• Signed pledge confirmation
• Public progress page
• Internal pledge-to-goal mapping

• Signed pledge with no internal owner

Provide and require MFA, particularly phishing-resistant options, for privileged or administrative use by default.

• MFA enforcement default in latest version
• Phishing-resistant option availability
• Sign-in telemetry

• MFA available but opt-in
• No phishing-resistant option for admins

Adopt memory-safe languages, parameterized queries, and other patterns that eliminate vulnerability classes rather than just individual bugs.

• Roadmap for memory-safety adoption
• Static analysis coverage report
• Architecture decision records

• Legacy C/C++ components without roadmap

Configure products with secure defaults out of the box; insecure modes require explicit, informed opt-in.

• Default configuration documentation
• UI screenshots showing secure defaults
• Deprecation plan for insecure defaults

• Legacy auth or TLS 1.0 enabled by default

Make security patches easy, automatic where appropriate, and free for the life of the supported product.

• Auto-update configuration
• Patch policy
• Support lifecycle commitment

• Patches behind paid support tier
• No automatic update channel

Maintain a public VDP that authorizes good-faith research and provides a safe channel for reporting.

• Published VDP
• Safe harbor language
• Intake mailbox and SLA

• No safe harbor
• Researchers threatened legally

Per CISA Secure by Design Principle 2: transparency. Requirements include (a) publish CVE disclosures including root cause + impact + (b) accept responsibility for product security flaws + (c) transparency on Memory Safety transition + (d) transparency on Vulnerability Disclosure Policy + (e) maintain Secure Development Lifecycle transparency.

• CISA SBD evidence for CISABD-2

• customer security ownership + transparency partial