Define the release boundary
Inventory the components that become part of the running service: application packages, base images, build tools, plugins, generated code and external integrations. Include the identities and systems that can change them. A dependency review limited to the application repository can miss a privileged build runner or deployment script with equivalent influence over production.
Map the path from a reviewed source change to the deployed artifact. Identify where dependencies are resolved, code executes, credentials become available and approval occurs. Treat each handover as a trust boundary. Record the source revision, build configuration and artifact digest so a release can be identified precisely instead of only by a mutable tag such as latest.
Control dependency selection and change
Use a consistent dependency-resolution process and retain the resolved versions used for each release. Evaluate package origin, maintenance, update practices and vulnerability exposure in the application’s context. A familiar package name or a clean scanner result does not establish that every downloaded component is trustworthy. Include transitive dependencies and relevant build-time components.
Define how a dependency change is reviewed, tested and promoted. Restrict unapproved package sources where feasible and protect registry credentials. Record exceptions with an accountable owner, rationale and review date. Prioritisation should consider whether a vulnerable component is present and exposed in the deployed use, while clearly documenting uncertainty rather than treating incomplete analysis as absence of risk.
Protect the build identity and execution environment
Separate untrusted contribution checks from jobs that can publish artifacts or deploy. Review who can edit pipeline definitions, approve changes and access protected credentials. Prefer narrowly scoped, short-lived credentials where supported. A build job that runs unreviewed code with production permissions can defeat otherwise careful application review.
Control runner configuration, build inputs and artifact storage. Limit unexpected network access when practical, keep build environments maintained and record relevant execution evidence. Do not place secrets in artifacts, logs or cached workspaces. Review whether an attacker who can change a dependency or pipeline step could replace a release after approval.
Use SBOMs and provenance for the right questions
A software bill of materials describes recorded components and their relationships for a defined artifact or product. State its scope, generation method and known omissions. Link it to the actual release, and retain enough version information to investigate a newly disclosed issue. An SBOM is useful inventory evidence; it is not proof that the software is free from vulnerabilities or malicious behaviour.
Build provenance describes evidence about how an artifact was produced, according to its format and implementation. Verification should bind the artifact digest to an expected builder identity and relevant build inputs. A signature must be checked against a trust policy, not merely exist. SLSA provides a framework for increasing supply-chain assurance, but claiming a level requires meeting the applicable requirements.
Make deployment and rollback controlled decisions
Promote the verified artifact rather than rebuilding an untracked variation for production. Check the release identifier, approval, configuration, access and required migration steps. Define which checks block deployment and who may accept an exception. Separate the ability to produce an artifact from the authority to expose it to users when the operating model allows.
Prepare rollback or forward recovery for the complete change. Restoring an earlier application image may not reverse a database migration, external write or incompatible message schema. Test recovery against realistic dependencies and record limits. Maintain a route for urgent security updates that preserves essential review and evidence instead of becoming a permanent bypass.
Ask for a reviewable release evidence pack
A practical pack includes component inventory, source revision, resolved dependencies, build identity, artifact digest, relevant checks, approval and recovery instructions. Define retention and access so teams can investigate a release later. Monitor for changes in dependencies and build configuration that invalidate earlier assumptions; release assurance is an ongoing process.
TRUST-IT can review an existing delivery pipeline or build these controls into software development and integration work. Deliverables can include a pipeline trust-boundary map, prioritised control changes, release acceptance criteria and an exercised recovery procedure. The aim is to make the relationship between reviewed code and deployed behaviour explainable, with remaining uncertainty visible.
Further reading
Put the guidance to work
Custom applications, APIs, databases, secure development, and practical technology roadmaps.
Software & IT consulting