Verify what enters the release

Ask whether the dependency is needed

An agent can suggest a package that appears to solve a problem. The suggestion is a proposal, not evidence that the package exists or is suitable. Verify the exact registry, publisher, package name, and version before installation.

For a fictional CSV export, the runtime may already provide the required behavior. A new package can still be appropriate, but it adds maintenance and execution paths. Compare the implementation effort with the dependency’s ongoing responsibilities.

Review the license and supported runtime. Inspect maintenance activity and relevant advisories. A familiar name can refer to a different package in another registry. A successful install only shows that the installation completed.

Inspect installation and build behavior

Dependencies can execute code during installation or build. Limit credentials and network access in these environments. Do not expose production secrets to a job that processes an untrusted pull request.

Use a committed lockfile where the ecosystem supports it. Require the build to respect that file. Review lockfile changes with the source change, including unexpected transitive packages. Pinning improves reproducibility but does not make a vulnerable version safe.

NIST’s SSDF covers protection of software and development practices across the lifecycle. Use that broader perspective when designing the build environment. Read the framework.

Distinguish inventory from provenance

A software bill of materials, or SBOM, records components in software. It helps you identify affected releases when a component becomes a concern. It does not independently establish that the components are safe.

Provenance addresses how an artifact was produced. SLSA defines a provenance format for information about the build and its inputs. Verification must connect this information to a trusted producer and the artifact you intend to use. A file called “provenance” is not sufficient. SLSA provenance.

For the export service, record a chain you can inspect:

1. The reviewed commit identifies the accepted source.
2. The build identifies its inputs and execution environment.
3. The artifact has a stable digest.
4. The checks identify the artifact or source they examined.
5. The deployment records the artifact placed in the target environment.

Avoid rebuilding differently after approval without a defined verification process. A mutable tag such as latest can refer to a different image later.

Decide what a finding means

A vulnerability finding requires context: the affected version, reachable behavior, exposure, available fix, and consequence. Record the evidence behind any temporary exception. Give it an owner, expiry, and review trigger.

Do not suppress an entire scanner because one finding is inapplicable. Do not claim a clean result when the scan failed to complete. A timeout, unsupported package, or unavailable advisory feed is missing evidence.

Finally, plan updates after release. New advisories can affect yesterday’s accepted artifact. The service owner needs an inventory, a response process, and the capacity to produce a corrected release.

Continue with continuous vulnerability management to connect repeated scans with verified production fixes.