Secure-development guidance landscape
Navigate complementary secure-development frameworks and assemble a coherent practice covering governance, threat modelling, implementation, supply chain, verification and vulnerability response.
After this module, you should be able to:
- Distinguish organisational, product and system security guidance
- Map overlapping frameworks to one operating lifecycle
- Include threat modelling, SBOM and vulnerability management
- Choose evidence proportionate to product risk and market
Use frameworks as complementary lenses, not competing checklists.
Secure-development guidance comes from standards bodies, regulators, cybersecurity agencies and industry groups. Examples address organisational practice, systems security engineering, software development, IoT baselines, industrial control, supply chains and vulnerability disclosure.
A useful programme maps these sources to one lifecycle and one evidence set. Product context determines applicability: a constrained controller, mobile app, cloud service and manufacturing station have different attack surfaces but share identities, dependencies and response obligations.
Translate the framework into controlled engineering work.
| Area | Question | Typical evidence |
|---|---|---|
| Governance | Who owns risk, exceptions, suppliers and release decisions? | Policy, plan, roles and training |
| Design | Which assets, threats, boundaries and security objectives apply? | Threat model and security architecture |
| Implementation | How are code, tools, secrets and dependencies controlled? | Secure build and review records |
| Verification | How are controls and abuse cases challenged? | Security test evidence |
| Post-market | How are inventories, vulnerabilities and updates managed? | SBOM, monitoring and response records |
Apply the current controlled source
This module is an orientation. Confirm the applicable edition, amendments, adopted regional version, contractual commitments and sector-specific interpretations before defining compliance.
Use a risk-based application sequence.
- 1. Define product scope, markets, threat context and applicable obligations
- 2. Select a primary lifecycle framework and map complementary guidance to it
- 3. Create threat models and turn risk decisions into testable security requirements
- 4. Control components, build environments, credentials and release provenance
- 5. Verify controls with analysis, abuse testing and independent challenge
- 6. Maintain SBOMs, vulnerability intake, triage, coordinated disclosure and recoverable updates
Worked application: connected measurement device
The organisation uses NIST SSDF to structure secure development, a product-specific threat model for device and cloud assets, an SBOM for component monitoring and an IoT or sector baseline for market expectations. One traceability set connects threats, requirements, architecture, tests and release decisions.
Build evidence that explains the reasoning.
Framework, scope, roles, activities and tailoring.
Assets, trust boundaries, abuse cases and risk decisions.
Owned, testable controls across system components.
Components, versions, suppliers and released artefacts.
Analysis, fuzzing, penetration and recovery tests.
Monitoring, assessment, disclosure, fixes and deployment.
Common failure patterns
Multiple checklists create duplication and unclear ownership.
Inventory exists without continuous vulnerability assessment.
Late testing substitutes for secure architecture and development.
The device cannot update safely across its support lifetime.
Further learning
- NIST SP 800-218 · SSDFA risk-based set of secure software development practices.
- CISA · Secure by DesignPrinciples for making customer security a core product requirement.
- NTIA · Software Bill of MaterialsFoundational SBOM resources and ecosystem work.
Use the standard to strengthen decisions, not decorate them.
Make scope, tailoring, responsibilities, technical reasoning and objective evidence explicit—and always work from the current authorised text.