Know what you are protecting
Modern software is assembled from source code, open-source packages, build services, containers and deployment automation. A weakness in any link can affect the released system. An inventory of components is important, but it does not prove that the software was built from the expected source or that a vulnerable component can be replaced safely.
Map the path from source to production. Include source control, developer access, dependencies, build runners, artifact repositories, signing services, deployment identities and production configuration. Assign owners to each stage and identify where untrusted input can enter.
This map often reveals hidden dependencies: a shared automation account, an unmaintained build image or a package downloaded directly during deployment.
Treat the SBOM as inventory
A software bill of materials lists components and relationships in a software artifact. It can help teams identify where a disclosed vulnerability may be present and support supplier conversations. Its value depends on accuracy, freshness and the ability to connect a component to deployed systems.
An SBOM is not a security score. It does not show that a build was protected, that a component is exploitable in context or that the organisation can respond. It also needs handling controls because detailed component information may be sensitive.
Add provenance
SLSA defines provenance as verifiable information about where, when and how a software artifact was produced. Build provenance can connect an artifact to its source and build process. Verification then checks whether the evidence satisfies the organisation's policy before release or deployment.
Provenance is strongest when it is generated by a protected build service rather than written manually. The required assurance should match the consequence of compromise. Not every internal utility needs the same control as an identity, payment or public infrastructure service.
Protect the delivery process
NIST's Secure Software Development Framework groups practices around preparing the organisation, protecting software, producing well-secured software and responding to vulnerabilities. Practical controls include:
- multi-factor authentication and least privilege for source and build systems;
- reviewed changes and protected branches;
- pinned and verified dependencies;
- isolated, reproducible build environments where practical;
- immutable artifacts promoted between environments;
- signed evidence and policy-based verification; and
- rehearsed vulnerability and incident response.
Secrets should not be stored in source or baked into artifacts. Build and deployment identities need narrow permissions and short-lived credentials where possible.
Make response part of the design
When a vulnerability is disclosed, teams need to know which products are affected, whether the vulnerable function is reachable, who owns the decision and how quickly a safe release can move. Define severity, exception and escalation processes before pressure arrives.
Track the time to identify affected services, decide on treatment and deploy a fix. Review recurring dependency risks and unsupported components.
Avoid compliance theatre
A generated SBOM, a signed file or a scanner result is evidence for a question, not proof that the entire supply chain is safe. Controls must work together and be tested against realistic failure and compromise scenarios.
Algoza can help map delivery dependencies, define proportionate supply-chain controls and integrate evidence into release decisions.