A company scans its source code before every release but allows a compromised CI account to replace a signed application artifact after testing. The source passes security review while the delivered program contains unreviewed code. Secure software delivery needs more than vulnerability scanning: it must establish which components were used, which identity built the artifact, which controls protected that process and whether production receives the verified result.
The ISC2 Software Development Security domain covers development assurance and software security. The existing secure SDLC specialist addresses lifecycle principles. This article focuses on artifact provenance, software bills of materials (SBOMs), pipeline identity and supply-chain decisions that link development teams with procurement, operations and incident response.
Build a component inventory with clear ownership
An SBOM can document software components, versions and dependency relationships for a particular delivered product under supported formats. It helps identify where a newly disclosed vulnerability might matter, but a component name alone cannot prove the vulnerable code is reachable or that the binary was built exactly from an approved source commit. Record product/version identity, generation method and how inventory is updated.
Review direct and transitive dependencies, vendor packages, container base images and embedded firmware where relevant. An application may use a library only in testing, or may bundle it into production with different risk. The inventory should support triage rather than become a false claim of comprehensive runtime observation.
Separate source integrity from build integrity
A protected source branch is useful, but the build system may fetch external packages, execute scripts and publish artifacts with powerful credentials. Identify which external inputs can change the result without a reviewed source diff. Pin supported dependency versions and verify integrity or signatures where appropriate, while keeping update processes maintainable.
A compromised build runner can produce malicious output from apparently clean source. The pipeline therefore needs hardened execution, controlled credentials, monitored administrative access and a recoverable process for replacing compromised components.
Use short-lived pipeline identities where possible
A build process should not keep a broad permanent token with permission to modify repositories, publish packages and deploy to production indiscriminately. Separate read, build, publish and deploy actions into scoped identities or stages. Where supported, use short-lived workload federation and approvals for release-critical operations.
A temporary workflow permission can still be dangerous when a pull request from an untrusted contributor can reach it. Threat-model which branches, contributors and tools may invoke a secret-bearing step before enabling automation.
Design artifact provenance and verification
A cryptographic signature or attestation can help verify origin and integrity when its issuer, identity, protected key and verification policy are trustworthy. Signing a malicious artifact does not turn it into secure software; the signature proves a statement about who signed it and what bytes were signed. An attestation may add verified build-process claims, but consumers must check those claims against an actual deployment policy.
Require production deployment to reference the reviewed artifact identity, not rebuild an unpinned release from a moving branch. Test that a modified artifact or wrong signing identity is rejected in a nonproduction environment.
Turn vulnerability disclosures into targeted action
When a supplier reports a critical library issue, use the SBOM and dependency evidence to identify possibly affected products, versions and deployments. Then assess reachability, compensating controls and business impact. A package update requires testing; replacing software in a safety-critical system without change control can create a larger operational hazard.
The supplier-risk specialist supports the contractual and continuous-assurance aspects of this investigation. A software component is both a technical dependency and a supplier relationship.
Preserve reproducibility and an incident response route
If a signing key or runner is compromised, responders need to know which artifacts were produced during the suspect period, where they were deployed, and how to revoke trust or release safe replacements. Retain logs, build inputs, artifact digests and approvals under appropriate access and retention rules. A new good build alone may not remove the untrusted package already installed on customer systems.
Reproducible builds or strong provenance processes can improve confidence where feasible, but complexity and tool support vary. Document what was truly verified rather than claiming every generated byte can be reproduced automatically.
Test the delivery boundary as part of release QA
In a safe lab, introduce an intentionally altered artifact, an unauthorized publishing identity and a dependency manifest with a known outdated component. Verify which stage blocks each condition and which alert reaches the right owner. Then demonstrate the approved path using a known artifact digest, review record and integrity evidence.
A CISSP software supply-chain design succeeds when source review, build isolation, component transparency, artifact trust and production authorization reinforce each other. It is not enough to know a list of controls; the organization must prove the code that was reviewed is the code it actually delivered.