← Back to the learning library
Before you begin: Read TFA-106 on configuration control and TFA-107 on cybersecurity. Identify the systems currently able to modify, build or sign a release.
Reading time and practice time are estimates. Examples use fictional products and illustrative engineering values, not approved product limits.
Publication basis: NIST SP 800-218, SSDF Version 1.1, February 2022. This is guidance that can support a chosen lifecycle; it is not a universal product certification scheme.
Learning objectives
By the end of this module, you should be able to:
- Explain the purpose and limits of SSDF adoption.
- Identify trust boundaries in firmware development and release.
- Connect secure implementation work to evidence and acceptance decisions.
- Turn vulnerability reports into controlled remediation and prevention.
Lesson 1
1. Use a framework to organise secure engineering
NIST SP 800-218 recommends high-level secure development practices that can be integrated into different software lifecycles. It also supports communication between software producers and purchasers. Its four practice groups are Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities.
For a fictional connected instrument, use these groups to organise an assessment of current practices and gaps. Do not treat adoption as a claim that all vulnerabilities have been removed. Identify which products, teams, repositories and release paths the assessment covers. Where a contract refers to SSDF, examine the exact requested practices and evidence rather than substituting a generic statement of alignment.
Lesson 2
2. Prepare people and decision rules
Assign responsibility for security requirements, design review, implementation assessment, release decisions and vulnerability response. The same person may perform more than one role, but the authority and review arrangements should be clear. Give engineers access to guidance and tools that fit their language, target and product context.
Define criteria for handling security findings before a release deadline arrives. Who can accept a residual issue? Which problems require a design change? What evidence demonstrates that a fix is effective? A dashboard without decision rules can produce activity without resolution. In the instrument team, a release cannot proceed merely because a finding has an owner; the required assessment and approval must actually exist.
Lesson 3
3. Protect the path from source to release
Identify who and what can change source, dependencies, build settings, generated code and signing policy. Review access for developers, automated jobs and external services. A protected main branch is insufficient if a build job can download mutable scripts or use an unrestricted signing credential.
For the example instrument, separate permission to propose a change from authority to approve and sign a release. Tie signing to an approved artifact identity and policy, with retrievable records. Protect secrets and avoid placing production keys in repositories or ordinary build workspaces. Also control recovery access: an emergency account that bypasses the normal process can become the easiest route to an unauthorised image.
Lesson 4
4. Produce software with threat-informed checks
Use product threats and trust boundaries to guide requirements, design review and implementation assessment. For the instrument, examine commands entering from a host, configuration imports, update packages and service interfaces. Test invalid and adverse sequences as well as successful operation.
Combine code review, appropriate static analysis and targeted execution tests. Assess libraries and generated components according to their role and provenance. A dependency version is not acceptable simply because it is popular or currently has no reported vulnerabilities. Record the source, build options, integration assumptions and maintenance route. Prioritise checks that could detect plausible defects in the supplied configuration.
Lesson 5
5. Make release evidence identify the actual artifact
A release record should connect the approved source, dependencies, toolchain, settings, resulting image and assessments. Use stable artifact identifiers such as cryptographic digests where appropriate. Distinguish integrity from authority: a matching digest can show that bytes are unchanged, but it does not by itself establish that those bytes were approved or came from a trusted process.
| Record | Question it helps answer | What it does not establish alone |
|---|---|---|
| Dependency inventory | What components are included? | Whether every component is exploitable or acceptable |
| Build provenance | How was this artifact produced? | Whether the input design was correct |
| Signed image | Was it signed by an accepted authority? | Whether the authorised release is free of defects |
| Verification report | What claims were assessed? | Whether untested configurations behave equivalently |
Use these records together and make their limitations visible.
Lesson 6
6. Respond to vulnerabilities across supported versions
Provide a usable reporting route and a triage process. A report should be assessed against affected versions, product configuration, reachable interfaces and possible consequences. Maintain enough component and release information to identify the field population. Distinguish “not present”, “present but not affected under stated conditions” and “affected” rather than treating a keyword match as a complete assessment.
Plan remediation with product engineering, verification and service responsibilities. Firmware patches can affect compatibility, persistent data and operating availability. Retain the decision, fix evidence and installation conditions. A vulnerability may also require temporary operational measures while a patch is prepared; these measures need clear scope and an owner.
Lesson 7
7. Use root-cause learning to prevent recurrence
After resolving an issue, ask how it entered the product and why existing controls missed it. If several parsers trust unvalidated lengths, repairing one function does not address the broader pattern. Search for related implementations and adjust review guidance, tests or architecture where justified.
Measure outcomes that help decisions: unresolved high-impact findings in supported products, time to identify affected releases, or evidence completeness for signed artifacts. Avoid targets that encourage premature closure or severity downgrading. A useful improvement has a named owner, a change to practice and a way to evaluate whether it reduces the identified failure mechanism.
Decision guide
Where should this security improvement enter the lifecycle?
| Problem | Primary focus | Concrete improvement |
|---|---|---|
| Nobody owns release exceptions | Organisational preparation | Define authority and acceptance criteria |
| Build jobs can sign arbitrary images | Protection of release assets | Restrict signing to approved artifact and policy |
| Parser checks are inconsistent | Secure production practices | Shared boundary handling and targeted assessment |
| A fixed defect appears in other branches | Vulnerability response | Affected-version review and root-cause action |
Worked example
Worked example — a trusted repository with an untrusted build dependency
An instrument team protects its source branch and reviews every firmware change. The release job nevertheless downloads a helper script from a mutable URL. That script can modify the image before signing.
The team maps the full release path, pins and verifies required build inputs, reviews the helper script and controls changes to the build environment. Signing is tied to an approved artifact identity with restricted authority. Release records capture the inputs and the evidence used to approve the resulting image.
The trust argument covers the actual production path rather than stopping at the repository. The team also examines older releases for use of the uncontrolled input and records the outcome of that assessment.
Engineering evidence
What should the work produce?
Secure development profile
Maps selected practices to roles, activities and known gaps.
Build and signing access model
Explains who can modify inputs, approve releases and invoke signing.
Artifact evidence record
Connects approved inputs, provenance, checks and released bytes.
Vulnerability and improvement record
Identifies affected products, remediation decisions and root-cause actions.
Common failure patterns
What goes wrong?
- Equating branch protection with a secure release pipeline.
- Treating an SBOM as a vulnerability conclusion.
- Allowing emergency credentials to bypass all release controls.
- Closing a vulnerability after fixing only the newest branch.
Applied exercise · approximately 25 minutes
Assess a security patch outside the normal release path
A support engineer compiles an urgent patch locally and asks the release team to sign it. The image works on one device, but the exact dependencies and build options are not recorded.
- Identify what remains unknown about the proposed artifact.
- Define a proportionate controlled route for an urgent release.
- State how the incident should improve the normal process.
Review a suggested approach
The team lacks a reliable link from approved source and dependencies to the supplied image and its relevant verification. Working on one device does not establish compatibility across the supported population. Reconstruct the change in a controlled build environment, review its scope, perform risk-informed checks and apply the authorised release decision process.
An urgent route can use expedited reviews and a focused evidence package, but its approvals and limitations must remain explicit. Afterwards, improve the process so urgent work can be produced quickly without bypassing artifact identity, signing control or affected-version assessment. Record the reason for urgency and any follow-up verification rather than implying the accelerated route had identical evidence to a routine release.
Completion criteria
- Artifact identity and assurance gaps are clearly distinguished.
- Urgency changes scheduling without concealing missing evidence.
- The proposed improvement addresses the cause of the bypass request.
This is a self-directed engineering exercise, not an accredited examination. Compare the rationale as well as the final answer.
Practical check
Questions for your next design review
- Does the assessment include tooling and automated identities?
- Can signing authority be exercised only through a controlled decision?
- Are findings connected to released configurations and supported versions?
- Does incident learning produce a specific improvement to engineering practice?
SSDF becomes useful when its practices control the actual path from product decisions to released firmware and maintained field versions.
References and further reading
- NIST SP 800-218 — SSDF Version 1.1
- TFA-106 — Configuration & Version Control
- TFA-207 — DevOps, Build & Release Engineers
- TFA-308 — Industrial Product Cybersecurity
Educational guidance only. Apply the authorised standards editions, regulations and approved procedures relevant to your product and market. Linked publications support further study; the fictional exercises do not demonstrate compliance.