Secure by Design is a software development philosophy that puts security decisions into a product's architecture at the earliest design phase, rather than bolting on patches after a vulnerability ships. The term moved from academic principle to industry mandate on April 13, 2023, when the Cybersecurity and Infrastructure Security Agency (CISA), the NSA, the FBI, and agencies from Australia, Canada, the UK, New Zealand, Germany, and the Netherlands co-published "Secure by Design: Shifting the Balance of Cybersecurity Risk." The guidance told software manufacturers to stop treating memory-safety bugs, default credentials, and SQL injection as inevitable and start treating them as design failures. A year later, at RSA Conference 2024, CISA turned the guidance into a voluntary pledge that 68 vendors signed on day one. For security teams evaluating vendors or hardening their own SDLC, Secure by Design is now a procurement checkbox, not just a philosophy.
What does "Secure by Design" actually mean?
Secure by Design means a manufacturer builds products so that customers are protected without having to buy add-on security features or configure anything themselves. CISA's April 2023 paper defines it around two core tenets: manufacturers should take ownership of customer security outcomes, and they should embrace radical transparency about defects. In practice this means a vendor chooses a memory-safe language like Rust or Go for new components instead of C, ships with multi-factor authentication enabled rather than sold as an upsell, and eliminates entire vulnerability classes (SQL injection, path traversal, cross-site scripting) through parameterized queries and safe frameworks rather than relying on developers to remember secure coding checklists on every commit.
What is the CISA Secure by Design pledge and who has signed it?
The CISA Secure by Design pledge is a voluntary, public commitment launched on May 8, 2024, in which signatories agree to make measurable progress within one year on seven specific goals. Those goals include increasing multi-factor authentication use, reducing default passwords, cutting entire classes of vulnerability, shipping more security patches automatically, publishing a vulnerability disclosure policy, increasing CVE field completeness (specifically CWE and CVSS data), and demonstrating reduced exploitation of critical vulnerability classes. The initial signing at RSAC 2024 included Microsoft, Google Cloud, AWS, Cisco, IBM, Okta, Fortinet, and roughly 60 other vendors; by early 2025 CISA reported the pledge had grown to more than 250 signatories. Each pledge goal is self-attested, which is why CISA published a companion set of "evidence" expectations in 2024 asking vendors to show artifacts like SBOMs and CVE completeness metrics rather than just checking a box.
How is Secure by Design different from Secure by Default?
Secure by Design governs how a product is built, while Secure by Default governs how it ships and behaves out of the box, and CISA treats the second as a subset of the first. A product can be designed securely (memory-safe core, minimal attack surface) but still ship insecurely if MFA is off by default or the admin console listens on 0.0.0.0 with a default password. CISA's guidance calls out exactly this gap: Microsoft's 2023 decision to enable MFA by default for Azure AD tenants, and its later expansion of free security logging that was previously an E5-tier upsell, are cited as Secure by Default moves that followed years of Secure by Design underinvestment. The distinction matters for buyers: a vendor can point to a secure architecture in a whitepaper while still requiring customers to manually flip a dozen settings to actually be protected.
What breaches show the cost of skipping Secure by Design?
Two 2021-2023 incidents are the reference cases CISA itself cites: Log4Shell and the MOVEit Transfer breach. Log4Shell (CVE-2021-44228), disclosed December 9, 2021, scored a maximum CVSS of 10.0 and existed because the Log4j library's JNDI lookup feature was enabled by design with no safe default, letting a single crafted string trigger remote code execution across an estimated 35,000+ Java packages, per Google's Open Source Insights team. The MOVEit Transfer SQL injection flaw (CVE-2023-34362), exploited by the Clop ransomware group starting May 27, 2023, stemmed from unparameterized SQL queries in a web application that a secure-by-design review would have flagged in code review; the resulting breach ultimately affected over 2,700 organizations and more than 93 million individuals according to breach-tracking aggregations reported through early 2024. Neither flaw required a novel technique — both were vulnerability classes CISA's Secure by Design pledge explicitly asks vendors to eliminate at the architecture level rather than patch reactively.
What technical practices define Secure by Design software?
The core technical practices are memory-safe languages, elimination of default credentials, secure-by-default authentication, and systematic reduction of recurring vulnerability classes. CISA's roadmap specifically calls out migrating new code to memory-safe languages (Rust, Go, C#, Java, Swift) to remove buffer overflow and use-after-free bugs, which the NSA estimated in a November 2022 advisory account for a majority of exploited memory-related CVEs in C/C++ codebases. It also calls for hardening build pipelines so a compromised CI/CD system (as in the SolarWinds Orion attack disclosed December 2020, where malicious code was inserted during the build process) can't silently inject code into shipped binaries. A growing practical requirement tied to these principles is producing a Software Bill of Materials (SBOM) in SPDX or CycloneDX format for every release, since NTIA's 2021 minimum-elements guidance and Executive Order 14028 (signed May 12, 2021) both treat SBOM availability as a baseline transparency signal that lets customers verify what a vendor actually shipped, not just what they claim to have designed.
How can security teams verify a vendor's Secure by Design claims instead of taking them on faith?
Security teams verify Secure by Design claims by demanding artifacts, not attestations: SBOMs for every release, CVE records with complete CWE/CVSS fields, and evidence of exploitability rather than raw vulnerability counts. CISA's own pledge evidence guidance, published in 2024, pushes signatories toward exactly this: quarterly published metrics on default-password elimination, MFA adoption rates, and memory-safe code migration percentages. For procurement teams, that means an RFP question like "send us your Secure by Design pledge evidence" should get a specific artifact back, not a marketing paragraph. It also means internal AppSec teams need the same discipline applied to their own products — an internally-built SBOM is only useful if someone is actually reconciling it against a live dependency graph and checking which flagged CVEs are reachable in the running application, since a 2023 Endor Labs study found roughly 65-70% of vulnerabilities in typical open-source dependency trees are in code paths that are never actually called.
How Safeguard Helps
Safeguard operationalizes Secure by Design principles instead of leaving them as a pledge on paper. Our platform generates and ingests SBOMs (SPDX and CycloneDX) automatically on every build, giving teams the transparency artifact CISA's guidance asks vendors to produce without a manual export step. Reachability analysis then cuts through raw CVE counts by determining which flagged vulnerabilities sit in code paths your application actually executes, so teams fix the small fraction that matters instead of triaging everything a scanner reports. Griffin, Safeguard's AI security analyst, correlates that reachability data with exploit intelligence to prioritize findings and explain the actual attack path in plain language. When a fix is confirmed, Safeguard opens an auto-fix pull request with the patched dependency version, turning a design-time security gap into a shipped, verifiable fix rather than a backlog ticket.