Category: Software Supply Chain Security

Secure by Design

Also known as: SbD, Secure-by-Design

Simply put

Secure by Design is an approach in which security is built into products and systems from the very beginning of their development, rather than added on later as an afterthought. It treats protecting customers as a core business priority instead of an optional technical feature. The aim is to reduce vulnerabilities before code is written or a product ships.

Formal definition

Secure by Design (SbD) is a cybersecurity and systems engineering concept that calls for security to be incorporated into systems from the outset, embedded into software architecture and design decisions before implementation, rather than bolted on after development. As articulated in CISA's joint guidance (initially published April 2023), it urges software manufacturers to prioritize customer security as a core business requirement and to take proactive steps in how products are built and shipped. Frameworks such as the OWASP Secure-by-Design Framework provide practical guidance for embedding security into architecture early in the lifecycle, and government programs (for example, the UK's Secure by Design guidance) frame it as promoting a shared security culture across project teams. Scope note: SbD is a design and development philosophy for the producer of a system or product; it addresses how security is engineered into what is built and does not, by itself, constitute a certification, attestation, or verification of a given product's security posture. It also does not, on its own, address non-security dimensions of supplier risk such as financial, operational, geopolitical, or ESG risk, and its effectiveness depends on how consistently the principles are applied in practice.

Why it matters

For third-party and supply chain risk professionals, Secure by Design reframes where accountability for product security sits. Traditionally, buyers have carried much of the burden of hardening, patching, and compensating for vulnerabilities in the products they procure. CISA's joint guidance, initially published in April 2023, urges software manufacturers to prioritize the security of their customers as a core business requirement rather than treating it as an optional technical feature. When a supplier genuinely adopts this posture, some categories of risk can be reduced upstream, before a product is shipped and integrated into a buyer's environment.

The concept matters to procurement and vendor risk teams because it offers a lens for evaluating how a supplier approaches security engineering, not just whether a supplier can point to a completed questionnaire after the fact. A vendor that embeds security into architecture and design decisions early, consistent with frameworks such as the OWASP Secure-by-Design Framework, may present a different risk profile than one that relies on post-release patching. That said, Secure by Design describes a producer's development philosophy; it is not itself a certification, attestation, or independent verification of any given product's security posture, and buyers should not treat a vendor's claim of following it as equivalent to validated assurance.

Its value in practice is also conditional. Secure by Design addresses how security is engineered into what a supplier builds, but it does not, on its own, cover non-security dimensions of supplier risk such as financial, operational, geopolitical, or ESG exposure. Its effectiveness depends heavily on how consistently the principles are applied across a manufacturer's teams and product lines, which is difficult to observe from the outside. Assessors should treat a supplier's stated commitment to Secure by Design as one input to be corroborated, not as a standalone guarantee.

Who it's relevant to

Third-Party and Vendor Risk Managers

For those assessing software and technology suppliers, Secure by Design offers a criterion for evaluating a vendor's security engineering maturity, how security is built into products rather than patched afterward. It should be treated as one qualitative input to be corroborated with independent evidence, since a supplier's claim of following Secure by Design is not itself a certification, attestation, or verification of a product's security posture.

Procurement and Sourcing Teams

Procurement functions can reference Secure by Design principles when framing security expectations for software manufacturers during sourcing and selection. It helps distinguish suppliers that prioritize customer security as a core business requirement from those treating it as an optional feature, while recognizing that the approach does not address financial, operational, geopolitical, or ESG dimensions of supplier risk.

Product Security and Systems Engineering Leaders

For organizations that build and ship software themselves, and therefore act as a third party to their own customers, Secure by Design is a development philosophy to operationalize. Frameworks such as the OWASP Secure-by-Design Framework and CISA's joint guidance provide reference points for embedding security into architecture early, though effectiveness depends on consistent application across teams and product lines.

Compliance and Governance Functions

Compliance teams may map supplier and internal expectations to Secure by Design guidance, but should be careful not to overstate its authority. Regulatory and governmental expectations differ across regions, CISA's guidance in the United States and the UK's Secure by Design guidance are examples, and adherence to the concept does not confer certification or guarantee compliance with any specific regime.

Inside SbD

Security requirements defined at design stage

The practice of specifying security and resilience requirements before or during the design of a product, system, or service, rather than retrofitting controls after development. In a third-party context, this often means embedding security expectations into supplier requirements and procurement specifications early in the sourcing lifecycle.

Default secure configuration

The principle that a product or service should be secure in its out-of-the-box state, minimizing reliance on the customer to harden it. This typically covers configuration defaults such as disabling unnecessary features and avoiding default credentials, but does not by itself address ongoing patching, operational monitoring, or the buyer's own deployment choices.

Threat modeling and risk-informed design

Identifying plausible threats and abuse cases during design so that mitigations are prioritized based on likelihood and impact. Depending on the risk tier, this may inform which supplier assurances or verifications an organization seeks, but it reflects design-time assumptions that can become stale as threats evolve.

Vendor and supplier accountability for security outcomes

The intent to shift a greater share of responsibility for security outcomes toward the producer of a product or service rather than the downstream consumer. In practice this is expressed through contractual terms, attestations, or assurance artifacts, none of which independently guarantee that secure-by-design principles were followed.

Software supply chain considerations

Attention to the provenance and integrity of software components, including third-party and open-source dependencies, that are incorporated into a product. This connects secure by design to Nth-party and software supply chain risk, but visibility typically diminishes beyond directly integrated components.

Common questions

Answers to the questions practitioners most commonly ask about SbD.

Does Secure by Design mean a product or supplier is certified as secure?

No. Secure by Design describes an engineering approach in which security is treated as a core design objective throughout the development lifecycle, rather than a certification or attestation of a finished state. It does not confer a compliance guarantee, and a supplier claiming to follow Secure by Design practices has not thereby been independently verified as secure. Distinguish a claimed design philosophy from independent validation of its outcomes, which typically requires separate assessment.

Is Secure by Design the same as Secure by Default?

Not exactly. Secure by Design refers to embedding security considerations into architecture and development decisions from the outset, while Secure by Default refers to shipping products configured with protective settings enabled without requiring the customer to harden them. The two concepts are related and often discussed together, but they address different points: one concerns how a product is designed, the other concerns the state in which it is delivered. A product can reflect one without fully achieving the other.

How can a third-party risk program evaluate whether a supplier actually applies Secure by Design?

Because Secure by Design is a set of practices rather than a certifiable status, evaluation typically relies on requesting evidence rather than accepting the claim at face value. In many programs this includes reviewing secure development lifecycle documentation, threat modeling artifacts, testing and code-review practices, and vulnerability handling processes. Depending on the risk tier, organizations may seek independent assessments or attestations, while recognizing that self-reported documentation lacks independent validation unless separately verified.

Where does Secure by Design fit within broader third-party due diligence?

Secure by Design generally addresses the information security dimension of a supplier's product development and does not, on its own, cover financial, operational, geopolitical, or ESG risk. It is typically one input among several during onboarding due diligence and, depending on the program, ongoing monitoring. It should not be treated as a substitute for a full risk assessment, and its relevance is greatest for suppliers whose software or hardware products are integrated into the organization's environment.

Can Secure by Design commitments be incorporated into supplier contracts?

In many programs, expectations aligned with Secure by Design are reflected in contractual security requirements, such as secure development obligations, vulnerability disclosure and remediation timelines, and rights to request evidence or assessments. However, a contractual commitment is an attestation of intent rather than independent verification of practice, so programs often pair such clauses with mechanisms to obtain and review supporting evidence over time.

What are the limitations of relying on Secure by Design in supplier evaluations?

Assessments of a supplier's Secure by Design practices are frequently point-in-time and can become stale as products, teams, and threats change. Much of the supporting information is self-reported unless independently validated. Visibility is also typically limited to the direct supplier, so Secure by Design practices at fourth-party or Nth-party component providers may not be observable. The concept addresses design intent and process, and does not by itself eliminate residual risk in the delivered product.

Common misconceptions

Secure by design means a product or supplier is certified secure or compliant.

Secure by design is a set of design principles and intentions, not a certification or compliance status. A supplier's claim of adhering to secure-by-design principles is typically an attestation, not independent verification, and does not confer any regulatory compliance guarantee.

Adopting secure by design eliminates the need for ongoing third-party monitoring.

Secure by design addresses the design and development phase but does not cover the full relationship lifecycle. Point-in-time design assumptions can become stale, and ongoing monitoring, patch management, and reassessment across the relationship remain necessary regardless of design-stage assurances.

Secure by design is the same as secure by default.

They are related but distinct. Secure by design concerns embedding security throughout the design and development process, while secure by default concerns the shipped configuration state of a product. A product can follow some design principles yet still ship with insecure defaults, and vice versa.

Best practices

Translate secure-by-design expectations into explicit, tiered supplier requirements within procurement and contract terms, rather than treating them as informal aspirations.

Request specific assurance artifacts (such as attestations, threat modeling summaries, or dependency inventories) and distinguish self-reported attestations from independently verified evidence when weighing their reliability.

Verify default configurations and credential practices in the delivered product rather than relying solely on the supplier's stated design intent.

Pair design-stage assurances with ongoing monitoring, reassessment, and patch-management expectations to account for point-in-time design assumptions becoming stale.

Extend inquiry to software provenance and third-party or open-source dependencies where feasible, while acknowledging that visibility typically diminishes beyond directly integrated components.

Account for jurisdictional and sector variation, as regulatory and buyer expectations around secure-by-design practices differ across regions and are not applied uniformly.