Series II: From infrastructure to agentic projects in production. Episode 12 of 20.
In the previous episode, we evaluated whether a coding agent delivers an acceptable change. But the application contains more than code written by an agent or the team: libraries, container images and tools that turn sources into an executable product. For this series' fictional B2B portal, the main decision is to accept a component only after checking its identity, version and risks, then retain the evidence alongside the released version.
The software supply chain starts before installation
A dependency is an external component that the project needs. Some are direct, chosen by the team; others are transitive, brought in by those components. An export library may install other libraries, while a container image may include operating system packages. Build tools also matter: even if they do not reach the final application, they perform operations on the project's code and files.
The software supply chain includes the sources, suppliers, services and processes through which these elements enter the product. Moving the application to the cloud or keeping it on-premises, on your own infrastructure, does not eliminate this chain. In either case, we need to know what we download and what we actually use. The inventory includes application components, the base image and relevant build tools.
A library proposed by an agent is not yet approved
Consider a hypothetical scenario: the team adds an export of requests to a CSV file, a tabular format with values separated by delimiters. The development agent proposes a library to handle delimiters and diacritics. First, we check whether existing approved components can provide the function. A new dependency creates maintenance work even if installing it takes little time.
If the library is necessary, we check its exact name in the package registry, the service distributing components, and compare it with the project's documentation. We check the official source, responsible authors or organisation, licence, available versions and update history. Popularity can guide investigation, but does not replace these checks. A package existing under the suggested name does not prove that it is the intended component.
“We Have a Package for You!”, presented at USENIX Security in August 2025, documents recommendations for nonexistent packages in code generated by the models evaluated. Its findings do not estimate the risk for every current model. They justify independent verification before installation. In the portal project, the agent can propose the library; a designated owner accepts the component and the reason for using it.
Pin the version and control installation
A lockfile records the concrete versions resolved by the package manager, the tool that installs dependencies. We keep it in the code repository and examine its changes alongside the integration request. A small change to a direct library may introduce many transitive changes.
For a JavaScript project using npm, npm ci installs from an existing lockfile and rejects a mismatch with the declared dependency list without rewriting the lockfile. We also document installation configuration. This control does not establish that the packages are safe and does not, by itself, guarantee an identical final product.
Installation runs in an isolated environment with limited access to data and secrets. We review scripts that may run during installation and enable only what the project needs. For container images, we also retain a digest, a cryptographic fingerprint of the content, so a version tag is not the only reference. Pinning components must be accompanied by regular updates; otherwise, it preserves known defects too.
SBOM: an inventory of the version we release
SBOM, short for “Software Bill of Materials”, is a structured list of software components. CycloneDX is a format that can represent components, versions and dependency relationships. For our example, we propose generating the inventory when building each releasable version and associating it with the resulting product.
An artifact is the result of a build process, such as the portal's container image. We identify it by digest and retain its SBOM, source revision and generation date alongside it. A list extracted only from the project's declarations may not describe all components present in the image. We check what the chosen tool covers, including operating system packages, manually copied code and components loaded later.
The SBOM helps the team find affected versions when an alert appears. It is not a security certification and does not eliminate vulnerabilities. Its completeness depends on the sources and generation methods. For an SME, a verifiable inventory of versions actually released is more useful than a file generated once and forgotten.
Provenance explains the path to the artifact
Provenance describes the sources and process used to produce an artifact. The approved SLSA 1.2 specification provides requirements and formats for strengthening software supply chain integrity. In the portal example, we retain the source reference, build system identity and relevant parameters to the extent that the platform can document and verify them.
A cryptographic signature must be checked against a trusted identity and the team's policy. We also verify that the evidence refers to the received artifact's digest, the expected source and the permitted process. A valid signature from an unapproved identity is insufficient. Verified provenance does not guarantee correct code or the absence of vulnerabilities either. If a component lacks this evidence, we document the limitation and acceptance decision without claiming an unmet SLSA level.
Alerts need an owner
Automated analysis compares inventoried components with available vulnerability information. A result without alerts means only that the tool reported no issues in the data and at the time of the check. It does not prove that every component is free of defects.
For each alert, we establish the affected component, released versions, relevant exploitation conditions and available remedy. A library used only during builds can still matter to process security. The owner decides on an update, replacement or justified temporary exception with a review deadline. After a change, we rerun the export tests and existing checks. An alert is not closed simply because the agent says it fixed the issue.
The minimum checklist before release
For the scenario's CSV library, the acceptance record answers five questions: is it the intended component, is the version controlled, have licensing and maintenance been assessed, does it appear in the artifact inventory, and is someone responsible for alerts? We link the answers to evidence and the approved change.
These rules apply both to components proposed by agents developing the portal and to those used by any agents integrated into the application. They have different functions, but their libraries and images still belong in the inventory. The next episode introduces CI/CD, the automated integration and delivery workflow, where these checks become repeatable steps before release.
Sources
Sources verified on 13 October 2026:
- OWASP CycloneDX, Software Bill of Materials, for components and dependency relationships.
- SLSA 1.2, Verifying artifacts and Build provenance, for provenance and artifact verification.
- npm CLI 11, npm ci, for controlled installation from a lockfile.
- Spracklen et al., We Have a Package for You!, USENIX Security, August 2025, for nonexistent packages in the configurations studied.
Want to check which components and risks enter your company's applications? Talk to i8 about software inventory and verifiable delivery.
