Secure by Design

Glossary

## What does secure by design actually mean? Secure by design is a software development philosophy in which security is treated as a core design requirement, evaluated and addressed during system architecture and design decisions, rather than tested for and patched after the fact. The term describes **an approach to engineering, not a single control or product feature**. A system built secure by design has its trust boundaries, authentication model, data flows, and failure modes considered before implementation begins, so that vulnerabilities born from a flawed architecture — the kind static analysis and penetration testing struggle to catch — get addressed at the point where they're cheapest to fix. This stands in contrast to the more common pattern where security requirements arrive as a checklist late in the SDLC, or as findings from a scan run against code that's already in production. ## Secure by design vs. secure by default: what's the difference The two terms are frequently used together, and CISA itself pairs them, but they describe different things. **Secure by design is about the development process**: are threat models built, are architectural risks assessed, are [secure coding patterns](https://apiiro.com/glossary/secure-coding-standards) enforced from the start. **Secure by default is about the delivered product's configuration state**: does the software ship with multi-factor authentication enabled, strong password policies enforced, and unnecessary attack surface (default admin accounts, open ports, permissive default roles) turned off out of the box. A product can be built through a rigorous secure-by-design process and still ship insecure defaults if configuration hardening wasn't part of the release criteria — which is why CISA's guidance treats them as complementary, not interchangeable, principles. ## The principles behind CISA's Secure by Design initiative CISA's Secure by Design initiative, launched in **2023** alongside the NSA and international partners, asks software manufacturers to sign a voluntary pledge built around three overarching principles: taking ownership of customer security outcomes rather than treating vulnerabilities as customers' problem to configure around; practicing radical transparency and accountability, including honest vulnerability disclosure and clear CVE/CWE labeling; and building the organizational leadership and structure needed to prioritize security investment at the executive level. The pledge itself commits signatories to measurable, time-bound goals — such as increasing MFA adoption, reducing default passwords, cutting entire classes of vulnerability (like SQL injection and path traversal), and publishing a vulnerability disclosure policy — evaluated over a one-year period. **It does not carry regulatory force**; it is an attestation of intent tracked publicly by CISA. ## What building secure by design looks like at the architecture stage In practice, secure-by-design work starts before a repository has a single commit. Teams define trust boundaries and data classification during [architecture review](https://apiiro.com/glossary/security-architecture-review), run structured [threat modeling](https://apiiro.com/glossary/application-threat-modeling) — using methodologies like STRIDE or attack trees — against the proposed design, and set security requirements (authentication scheme, encryption at rest and in transit, least-privilege service accounts) as acceptance criteria alongside functional ones. This is where an [application security architecture](https://apiiro.com/glossary/application-security-architecture) practice earns its keep: architectural decision records capture why a service was given a particular trust level, and those decisions get revisited whenever the design changes materially, not just at initial sign-off. The discipline maps closely to the [NIST Secure Software Development Framework (SSDF)](https://apiiro.com/glossary/nist-ssdf), which formalizes "prepare the organization" and "protect the software" practices that assume security decisions happen at design time, and it echoes obligations increasingly written into [federal software supply chain regulation](https://apiiro.com/blog/8-key-nist-guidelines-in-new-federal-regulations-to-be-aware-of/). ## How Apiiro enforces secure-by-design principles before code ships Secure by design breaks down when there's no way to see design-stage risk at the speed engineering teams actually move. [Apiiro](https://apiiro.com/product)'s deep code analysis reads architecture directly out of pull requests — new services, changed data flows, altered trust boundaries, introduced third-party dependencies — and correlates that material change against a risk graph spanning code, cloud, identity, and pipeline context. That means a design decision that increases blast radius, such as a new service touching sensitive data without an authentication control or a workload gaining excessive cloud permissions, **surfaces as a risk before merge rather than as a finding months later**. Because the graph carries context from design through runtime, teams get design-stage enforcement without needing a manual architecture review gate on every change.

Is secure by design a regulatory requirement or a voluntary best practice?

It's voluntary. CISA's pledge is an attestation of intent with no enforcement mechanism or legal penalty for signatories that fall short. That said, it increasingly influences government procurement expectations and aligns with frameworks like NIST SSDF that agencies do require contractors to follow.

How does secure by design relate to threat modeling?

Threat modeling is the practical mechanism that makes secure by design possible. It's the structured exercise — identifying trust boundaries, attack surfaces, and abuse cases during architecture review — that turns "build security in from the start" from a principle into specific design requirements and mitigations.

Can a legacy codebase become secure by design retroactively?

Yes, but not through a single remediation pass. Teams typically threat model existing high-risk components, prioritize architectural fixes by exploitability and blast radius, and enforce secure-by-design requirements on all new development going forward, gradually narrowing the gap rather than re-architecting everything at once.

What's the difference between secure by design and shift left security?

Shift left is about moving security testing and tooling earlier in the pipeline — SAST, SCA, and secrets scanning running at commit or build time. Secure by design goes earlier still, addressing security at the architecture and requirements stage, before any code exists for those tools to scan.