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
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-110 and TEA-207. This module helps organise complementary guidance into one practical programme.
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.
Choose guidance by the question it answers
NIST’s Secure Software Development Framework, SP 800-218, describes high-level secure-development practices that can be integrated into different lifecycles. Its groups address organisational preparation, protection of software, production of well-secured software and response to vulnerabilities. It is useful for structuring responsibilities and supplier discussions.
Other sources answer different questions. NIST SP 800-193 focuses on platform firmware protection, detection and recovery. IEC 62443 addresses industrial product and system cybersecurity. ETSI EN 303 645 provides a consumer-IoT baseline. Coding guidance and component-specific platform documentation support implementation detail.
Select sources against the product, deployment and commitments. Do not combine labels into a claim that every framework applies identically. Record which source is authoritative for an obligation and which is supplementary engineering guidance.
Build one evidence map instead of parallel paperwork
Translate selected practices into one controlled development workflow. A threat model, security requirements, architecture review and verification record can support several relevant expectations if their scope and content are sufficient. The cross-reference should explain the relationship, including partial coverage and gaps.
Avoid claiming equivalence from similar wording alone. A process practice such as reviewing design is not the same as a technical control such as authenticating an update. Both may be needed, and each needs its own evidence. Keep ownership and acceptance criteria specific.
Use supply-chain evidence critically. An SBOM identifies components; it does not by itself establish vulnerability applicability or absence. A penetration test samples attack paths in a defined scope; it does not replace secure design and lifecycle control.
| Question | Useful starting point | Product evidence |
|---|---|---|
| How do we organise secure development? | NIST SSDF; relevant sector lifecycle requirements. | Roles, review gates, controlled source and response process. |
| How does firmware remain trustworthy? | NIST SP 800-193; platform documentation. | Boot, update, detection and recovery architecture. |
| What does this deployment require? | IEC 62443 or ETSI baseline where applicable. | Context-specific requirements and integration evidence. |
| How do we know a release is affected? | Component inventory and vulnerability assessment. | Exact versions, configuration, reachability and decision. |
Make secure development continue after release
Assign a maintained vulnerability intake, triage and escalation route. Define how reports reach engineers who can identify affected versions and evaluate physical or service impact. Prepare the ability to build, sign, test and distribute a fix before a serious report arrives.
Review root causes and response performance. A recurring parser defect may indicate weak interface validation or missing review coverage. Improve the process and verify the product change. Keep the support period, offline population and recovery limitations visible in release and product decisions.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Replace three disconnected security checklists
A team maintains separate SSDF, industrial-security and internal-security spreadsheets. They all mark “secure update” complete, but no one owns power-interruption testing or signing-key recovery.
- Define the actual secure-update claims and missing responsibilities.
- Create one evidence mapping that preserves differences between process and technical controls.
- Specify a closure gate for the identified gaps.
Show the worked answer
Break the label into claims: authorised image, protected signing authority, target compatibility, controlled installation, detection of failure and trusted recovery. Assign engineering, security, verification and operations owners. Map each selected framework expectation to the relevant requirement and record, preserving any additional scope or conditions.
Close the gaps through reviewed architecture, a key-compromise and recovery procedure, and demonstrated interruption behaviour on representative configurations. Retain raw evidence and unresolved limitations. A shared mapping reduces duplicate administration, but completion still depends on the actual practices and product controls working together.
Review criteria
- The update claim is decomposed into testable behaviours and operational duties.
- Cross-references show coverage rather than asserting blanket equivalence.
- Closure requires evidence and accountable ownership.
Check your understanding
Can one record support several frameworks?
Yes, when its scope and content satisfy the relevant expectations and the mapping identifies differences or gaps.
Does an SBOM prove the product is secure?
No. It supports component identification; applicability assessment, design controls, verification and response are still needed.
Further learning
- NIST SP 800-193 — Platform Firmware Resiliency GuidelinesPublisher source supporting this module’s framework discussion.
- 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.