Category: Software Supply Chain Security

Secure Development Practices

Also known as: Secure Software Development, Secure Development, Secure Coding Practices, Security Development Lifecycle (SDL)

Simply put

Secure development practices are the methods and controls that software teams build into their work so that security is considered throughout how software is designed, written, and released, rather than added at the end. They include activities such as setting security standards, following secure coding guidance, testing for weaknesses, and having a process to respond to vulnerabilities found later. These practices aim to reduce security flaws in software, but they do not guarantee that software is free of vulnerabilities.

Formal definition

Secure development practices refer to the integration of security controls, activities, and governance into the software development lifecycle (SDLC), spanning organizational preparation, protection of software and its integrity, production of well-secured software, and response to vulnerabilities. Recognized reference sets include NIST's Secure Software Development Framework (SSDF), which organizes practices under Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV); OWASP's Secure Coding Practices Quick Reference Guide; Microsoft's Security Development Lifecycle (SDL); and NCSC secure development and deployment guidance. In a third-party context, these practices are typically relevant when evaluating a supplier's software engineering rigor, but they are process- and control-oriented rather than an outcome guarantee. The SSDF and similar frameworks are advisory reference models, not certifications, and their adoption does not by itself confer assurance of a vulnerability-free product. Scope is generally limited to development and deployment activities; these practices do not, on their own, address broader vendor risks such as financial, geopolitical, or operational resilience concerns, and evidence of adopted practices should be distinguished from independent verification of their effectiveness.

Why it matters

Software increasingly enters an organization not through code it writes itself but through the products, components, and services it acquires from third parties. When a supplier embeds security into how its software is designed, written, and released, the likelihood of exploitable flaws reaching downstream customers is typically reduced. Because software vulnerabilities can propagate across every organization that deploys an affected product, the rigor of a supplier's development practices is a meaningful input to third-party and software supply chain risk assessments.

For risk and procurement teams, secure development practices offer a way to evaluate a supplier's engineering discipline rather than relying solely on the finished artifact. Frameworks such as NIST's Secure Software Development Framework (SSDF), OWASP's Secure Coding Practices Quick Reference Guide, Microsoft's Security Development Lifecycle (SDL), and NCSC secure development guidance provide reference points against which a supplier's claimed practices can be compared. These are advisory reference models, however, not certifications, and their adoption does not by itself confer assurance that a product is free of vulnerabilities.

Assessors should also recognize the limits of what this evidence conveys. Secure development practices are process- and control-oriented; evidence that a supplier has adopted them should be distinguished from independent verification that those practices are consistently applied and effective. They address development and deployment activities and do not, on their own, speak to broader vendor risks such as financial stability, geopolitical exposure, or operational resilience, which require separate evaluation.

Who it's relevant to

Third-Party Risk and Procurement Teams

When evaluating a software supplier, these teams can use secure development frameworks as a structured lens for assessing engineering rigor. It is important to treat a supplier's self-reported adoption of SSDF, SDL, or similar practices as a claim to be corroborated rather than as independent verification of effectiveness, and to recognize that these practices do not address financial, geopolitical, or operational resilience concerns that require separate assessment.

Software Security and Application Security Teams

Internal security teams apply these practices to their own development workflows and often set the benchmarks against which supplier practices are judged. Familiarity with the PO, PS, PW, and RV groupings of the SSDF, along with OWASP secure coding guidance and vulnerability response processes, helps them frame both internal standards and third-party expectations.

Compliance and Assurance Functions

These functions map supplier practices to advisory reference models and document the basis for assurance. They should be careful to distinguish adoption of a framework from certification, the SSDF and comparable models are not certifications, and to note that regulatory and sector expectations around secure development can vary across regions.

Supplier and Vendor Engineering Teams

Software vendors under assessment use these frameworks to organize and evidence their own practices, from establishing security governance and standards to maintaining a vulnerability response process. Producing clear evidence of adopted practices can support customer due diligence, though such evidence describes process and control rather than guaranteeing a vulnerability-free product.

Inside Secure Development Practices

Secure Software Development Lifecycle (SSDLC)

The integration of security activities, such as threat modeling, secure design review, static and dynamic testing, and security acceptance criteria, into each phase of the software development lifecycle rather than treating security as a final gate. In a third-party context, this typically refers to controls a supplier is expected to maintain, though the level of assurance an assessing organization has over those controls varies with the depth of due diligence performed.

Secure Coding Standards

Documented conventions intended to reduce the introduction of common vulnerability classes during development. When evaluating a vendor, the existence of such standards is typically self-attested; it does not by itself confirm that developers follow them consistently or that code is independently verified.

Software Composition and Dependency Management

Practices for identifying and managing third-party and open-source components within a product, often supported by artifacts such as a software bill of materials (SBOM). This addresses component-level provenance and known-vulnerability exposure but does not, on its own, cover the security of a supplier's proprietary code or their broader operational risk.

Testing and Verification Controls

Activities such as static application security testing, dynamic testing, dependency scanning, and independent penetration testing. These typically address information security defects in the software but do not extend to financial, operational, geopolitical, or ESG risk associated with the supplier.

Vulnerability and Patch Management

Processes for triaging discovered defects, issuing fixes, and communicating them to affected customers, often referenced within frameworks such as NIST SP 800-161 and ISO 27036 for supplier relationships. Contractual expectations for remediation timelines commonly vary by risk tier and by the criticality of the component to the acquiring organization.

Framework and Standard Alignment

Reference points that describe secure development expectations for suppliers, including ISO 27036 for information security in supplier relationships and NIST SP 800-161 for supply chain risk management practices. Alignment or mapping to such frameworks indicates intent and structure but does not by itself constitute certification or a compliance guarantee.

Common questions

Answers to the questions practitioners most commonly ask about Secure Development Practices.

Does requiring a supplier to follow secure development practices guarantee their software is free of vulnerabilities?

No. Secure development practices are process controls intended to reduce the likelihood and severity of defects introduced during design, coding, and testing; they do not eliminate vulnerabilities. Even mature programs produce software with undiscovered flaws, and adherence to a practice does not, by itself, demonstrate that any specific release is secure. Treat these practices as risk-reducing measures rather than assurance that a product is defect-free.

Is a supplier's attestation that they follow secure development practices the same as independent verification?

No. A supplier attestation is a self-reported claim, while independent verification involves an external party examining evidence and testing controls. An attestation may be a reasonable starting point for lower-risk relationships, but it does not confirm that the described practices are consistently implemented or effective. Depending on the risk tier, many programs supplement attestations with artifacts such as test results, third-party assessments, or independent code and configuration reviews.

What evidence can we reasonably request from a supplier to assess their secure development practices?

Requests typically scale with risk tier. Commonly sought artifacts include descriptions of the development lifecycle, secure coding standards, results from static and dynamic testing, dependency and component inventories, vulnerability management and patch timelines, and any independent assessments. Bear in mind that documentation describes intent and process; it does not by itself confirm consistent execution, and point-in-time evidence can become stale as the codebase and toolchain change.

How do secure development practices fit into third-party onboarding versus ongoing monitoring?

Onboarding due diligence often establishes a baseline understanding of a supplier's development controls, but a single assessment captures a moment in time. Because development practices, personnel, and dependencies evolve, many programs pair onboarding review with ongoing monitoring, such as periodic reattestation, notification of material changes, and review of new assessment reports. Relying solely on an onboarding snapshot leaves gaps as the supplier's environment changes over the life of the relationship.

How can we address secure development practices across multiple tiers of the supply chain, not just our direct supplier?

Direct contractual review generally reaches only the first tier, and visibility into fourth-party or Nth-party contributors, such as open-source components, subcontracted developers, or embedded libraries, is often limited. Programs commonly manage this by requesting component inventories from direct suppliers and flowing down expectations contractually, but such flow-down depends on the supplier's own leverage over its subcontractors and does not guarantee equivalent practices deeper in the chain.

Should secure development requirements be applied uniformly to all suppliers?

Applying identical requirements to every supplier is rarely proportionate. Many programs calibrate expectations to the risk tier, considering factors such as the criticality of the software, the sensitivity of data it handles, and its exposure. Note also that secure development practices address risks arising in the software lifecycle and do not, on their own, cover financial, operational, geopolitical, or ESG risk, which are assessed through separate controls.

Common misconceptions

A supplier's attestation that it follows secure development practices confirms those practices are actually in place and effective.

An attestation is a self-reported statement, not independent verification. Confirming that controls exist and operate as described typically requires additional evidence such as independent testing, code review, or a third-party audit, and even then the assurance is scoped to what was examined.

A SOC 2 report or framework alignment certifies that a vendor's software is secure.

A SOC 2 report is an examination of controls against selected criteria, not a certification, and it does not guarantee the security of any specific product. Framework alignment (for example to ISO 27036 or NIST SP 800-161) describes structure and intent but confers neither certification nor a compliance guarantee.

Reviewing a supplier's secure development practices at onboarding addresses their software risk on an ongoing basis.

A point-in-time assessment reflects only the state observed at that moment and becomes stale as code, dependencies, personnel, and threats change. Onboarding due diligence does not substitute for ongoing monitoring, and visibility typically weakens for components sourced from fourth or Nth parties beyond the direct supplier.

Best practices

Distinguish inherent from residual risk when evaluating a supplier's secure development posture, and set expectations by risk tier rather than applying a uniform standard to all vendors.

Seek evidence beyond self-reported questionnaires, such as independent testing results, audit reports, or an SBOM, while recognizing the scope and limitations of each artifact rather than treating any single one as conclusive.

Request and review a software bill of materials to understand third-party and open-source component exposure, and note that it addresses component provenance but not the security of the supplier's proprietary code.

Define contractual expectations for vulnerability disclosure, remediation timelines, and notification, adjusting stringency to the criticality of the component and consulting frameworks such as ISO 27036 and NIST SP 800-161 for reference.

Supplement onboarding due diligence with ongoing monitoring, since point-in-time assessments become stale as code, dependencies, and threats evolve.

Extend inquiry, where feasible, into how the supplier manages its own upstream components and subcontractors, acknowledging that visibility typically diminishes beyond the direct third party.

Account for jurisdictional and sector variation in regulatory expectations for software security rather than assuming a single regime applies globally.