A Swedish SaaS team reviews a dependency update. The package page looks healthy, the repository is active and a provenance indicator is visible. The update is approved. Later, someone asks which artifact entered the production image and whether its provenance was actually verified during that release.
The team has a screenshot, but no answer tied to the installed version. This is the gap between recognising a security signal and building a control that produces useful release evidence.
For businesses buying software development, package provenance is worth discussing because dependencies become part of the delivered product. The useful question is specific: can the supplier explain the origin and acceptance decision for the package bytes that this release contains?
What trusted publishing changes
npm trusted publishing uses an identity relationship with a supported CI provider to authenticate publication without a long-lived publishing token. Its documentation also distinguishes publishing permissions and describes conditions under which provenance is generated automatically. Those conditions depend on the provider and public repository/package requirements. npm trusted publishing documentation
Keep authentication and evidence separate in your assessment. A publishing workflow can be authorised while the package's code is still harmful. Conversely, absence of provenance is not sufficient evidence that an otherwise legitimate dependency is malicious.
The architecture decision is how these signals affect your own release policy. That policy should be understandable to the people who approve dependencies and to the team that must handle an urgent exception.
Start with the version that actually enters the build
A package homepage represents a project. A release consumes particular versions of that project and its transitive dependencies. Record the lockfile, registry origin and artifact identity used for the build. An approval that names only a library without its version is difficult to audit later.
Run verification against the installed dependency set in the controlled build environment. npm documents npm audit signatures as a mechanism for checking registry signatures and provenance attestations after installation. Keep the result associated with the release and investigate verification errors rather than replacing the check with a screenshot. Viewing and verifying npm provenance
This does not mean every dependency decision requires manual archaeology. Automate repeatable checks and reserve human review for changes, failures and policy exceptions that need judgment.
A signature does not review the code
Cryptographic evidence can establish a relationship between an artifact and a recorded build process. It does not decide whether an installation script should access the network, whether a new transitive dependency is necessary or whether a maintainer's change matches your product's requirements.
Ask the delivery team to show what changed between the approved and proposed dependency sets. Focus on added packages, changed install behaviour, unexpected registry locations and altered publishing identity. The goal is to make a significant change visible early enough for someone to decide what it means.
Keep the policy proportional. A development-only tool with limited access has a different exposure from a runtime component parsing customer uploads. The same dependency can also have a different risk profile when used in a build environment holding powerful credentials.
Make exceptions expire instead of becoming invisible
Some essential packages will not offer the evidence your preferred policy expects. A blanket ban may be impractical, but a permanent undocumented bypass destroys the policy's value. Create a reviewable exception with an owner and a reason tied to a specific version or range.
Record what compensating work was done. That might include inspecting the artifact contents, limiting install-script execution, reviewing an upstream change or isolating the build. Avoid describing any single measure as a universal substitute for provenance.
The exception should return to review when the package changes or the agreed period ends. If the original owner leaves the team, another owner must inherit it. Otherwise the highest-risk decisions become the least visible parts of the dependency graph.
Treat your own published packages as supplier deliverables
Companies that distribute an SDK or shared component should apply the same scrutiny to their output. The package users install may contain generated files that differ from the repository source. Include a review of the packaged contents, not just the source diff.
If you adopt trusted publishing, verify the actual allowed publishing workflow and remove obsolete credentials according to a controlled transition. For compatible arrangements, consider whether a staged release and maintainer approval fit the organisation's operating model. Confirm current provider support rather than assuming every CI system behaves alike.
Our deployment identity article examines who may deploy a workload. The broader guide to verifiable build provenance covers evidence across the build chain. This package-level check connects those controls to what downstream users receive.
A pilot should deliberately encounter an uncomfortable package
Choose one application and its real dependency set. Build a policy report with clear categories: verified evidence, unsupported verification, explicit exception and failed verification. Do not collapse the last three into a generic warning that everyone learns to ignore.
Then test the delivery workflow with a harmless controlled fixture that fails a required check. Confirm that the release stops, that the error identifies the dependency and that the documented exception route requires the right person. Also prove that a legitimate update can proceed without unnecessary manual work.
Measure review time, coverage and the number of unresolved exceptions. Avoid claiming a percentage reduction in supply-chain risk from the number of green badges. A useful result is that a team can explain its release decisions and respond quickly when evidence changes.
Ask for evidence you can use after handover
The final deliverable should include the policy, automated checks, release-linked reports, exception ownership and a procedure for investigating a suspect version already deployed. Decide how to identify affected applications without rebuilding the entire inventory during an incident.
TuniCyberLabs can integrate these controls into custom software development and application maintenance. Discuss a dependency verification pilot with your package manager, CI provider and release model. The aim is a product whose shipped dependencies have an explainable acceptance history.