The team reviewed its source carefully. The release job downloaded an updated third-party action under a familiar tag, built the app and deployed it. The running artifact included code nobody on the team had reviewed. The gap was in the route from source to product, not the feature diff.
Supply-chain security asks whether the software you ship is the software you intended to consume, build and release. It connects dependency identities, build authority, artifact provenance and verification. Those controls complement secure coding and behavior tests; an authentic artifact can still contain a vulnerability or a bad business rule.
This chapter of The AI Software Factory follows a hypothetical merchant app release. Open-source evaluation selects dependencies; agent security constrains interactive workers. Here the question is how accepted source and dependencies become an identifiable artifact customers actually receive.
Map the chain that produces the artifact
A release can depend on application source, direct packages, transitive packages, build tools, operating images, third-party actions, generated assets and deployment configuration. An AI agent may add or alter any of those during implementation.
List the relevant inputs and where they are obtained. Identify which references are fixed and which can move. A dependency tag, an unpinned image or a setup script fetched from a changing URL can alter a build even when application source remains unchanged.
The map should follow the actual repository process. Do not create a parallel release system just to attach a security label. Inspect the existing package graph, build runner, artifact store and deployment path, then identify the material gaps.
For the hypothetical app, the important question might be a third-party action with broad token access. For another app, it might be a downloaded binary or an externally generated asset. The control should address the input that can change the accepted artifact, not merely the most visible package manifest.
Inventory dependencies with useful identities
A dependency inventory should record what is present and how it entered the product. Name, version and source help identify affected releases when a problem appears. Transitive dependencies matter because the app may consume them without naming them directly.
A lockfile can retain a resolved dependency graph within its ecosystem. It improves reproducibility, but it does not prove that every resolved package is safe. The initial resolution and later updates still require an acceptance process.
A software bill of materials can communicate included components, depending on how it is generated and its scope. The inventory should identify whether it covers application packages, the build environment or both. An attractive file with missing components can provide false confidence.
Use the inventory operationally. If a component becomes affected by a vulnerability, which apps and artifacts include it? If the answer requires searching dozens of unmaintained projects manually, the inventory has not connected to the app registry the factory needs.
Pin references and review what they pin
A moving reference can change without a new application review. GitHub’s secure-use reference recommends pinning actions to a full commit SHA for an immutable reference and auditing action source. Pinning reduces one change path; it does not establish that the pinned code is benign.
Choose the accepted version deliberately. Confirm the reference belongs to the intended source and inspect the behavior relevant to its authority. A build action that can read deployment credentials deserves more attention than a formatter operating on safe files.
Updates should be intentional and maintainable. Pinning forever can preserve a known vulnerable version. A dependency update process should propose a new identity, show the reason and run relevant checks before acceptance.
The goal is controlled change, not immobility. A factory needs both stable inputs for a release and a practical route for replacing those inputs when evidence changes. The component catalog can retain owners and retirement plans so updates do not depend on whoever remembers the original installation.
Constrain the build’s authority
A build executes code from the repository and its dependencies. If it has broad credentials, an untrusted input can affect more than the artifact. The build identity should have only the authority required for its stage.
Separate checks on untrusted contributions from privileged release work. A pull request may need tests without access to production secrets. The accepted release job may need deployment authority under the repository’s normal gates. Joining those contexts casually can expose the privilege to code that has not been accepted.
GitHub’s secure-use guidance discusses risks around privileged workflow triggers and untrusted checkout. Its warning supports inspecting the actual workflow context and data flow, not simply assuming a familiar trigger name is safe in every configuration.
Build caches and shared state also deserve attention. One job can influence a later job through files or cached artifacts. Isolation and validated cache use can reduce that path. The exact protection depends on the runner and tooling, and should be tested within the actual release setup.
Provenance explains how an artifact was produced
Provenance records the builder, process and inputs associated with an artifact. It gives a consumer something to compare with the expected release path. A bare statement that “CI built this” lacks the identity and conditions needed for that comparison.
The approved SLSA 1.2 specification includes build and source tracks. Its build-track overview distinguishes existing provenance, signed hosted-build provenance and hardened build controls. The documentation was read October 7, 2026; the older 1.1 page is marked retired.
For a small app factory, a first useful provenance record can identify source revision, builder and artifact digest. The team should understand who can create or alter that record and whether it is trustworthy enough for the intended decision. A freely editable note provides documentation without strong tamper resistance.
Do not claim a SLSA level merely because a file named provenance exists. The specification defines requirements, and a level claim needs evidence against the applicable track and version. A practical pilot can improve its release record without claiming certification or a level it has not assessed.
Verification gives provenance a purpose
A signed record needs a verification policy. Which builder and source are expected? Which identity is trusted? Which artifact does the record describe? What happens when the evidence is missing or mismatched?
The release path should compare the actual artifact with those expectations before promotion. Otherwise provenance becomes an attachment nobody uses. A mismatch should produce a visible failure and a defined investigation route rather than a fallback that accepts the artifact anyway.
The verifier itself needs an independent basis. A build script that can alter its own expected identity can make a false record look valid. Retain policy and trusted roots through the existing controlled configuration, with appropriate review for changes.
Verification supports origin and process claims within its scope. It does not prove that the source is vulnerability-free. SLSA’s own scope explanation distinguishes supply-chain controls from code quality, producer trust and transitive dependency guarantees. Keep those limits visible when describing what the checks established.
Build once and promote the identified result
If a preview receives one artifact and production rebuilds from changing inputs, the review may not apply to the product deployed. Retaining and promoting an accepted artifact where the tooling supports it reduces that gap.
Record the artifact digest or equivalent identity with the checks and release decision. The deployment result should say which artifact is active. A source revision remains important, but it is not always sufficient to identify the output when environment and dependency inputs can vary.
For the hypothetical merchant app, the preview could verify a known report calculation against safe data. Production promotion should retain the same identified application artifact under the host’s normal process, while recording environment-specific configuration separately.
A deployed artifact can still behave differently because configuration or external state differs. Cloud-native development addresses that complete release path. Supply-chain identity narrows uncertainty about the software; live verification still needs to inspect the intended customer behavior.
Vulnerability scanning needs a response owner
A scanner can identify known issues within the components and rules it understands. Its output needs triage: does the affected code exist in the app, can the condition be reached and what repair is appropriate?
A clean scan is not proof of complete security. Unknown vulnerabilities, configuration problems and incorrect access rules may remain. A noisy scan can also overwhelm a small operator if every finding produces the same undifferentiated alert.
Assign an owner and response process. A dependency update should identify affected apps, proposed version, compatibility risk and required checks. A temporary mitigation should have a retained scope and revalidation condition rather than become an unexplained permanent exception.
The open-source evaluation guide considers maintenance and replacement burden before adoption. That early decision affects how expensive a later security response becomes. An unmaintained dependency can make a known problem difficult to repair even when the scanner found it promptly.
Treat AI-added dependencies as proposals
An agent may install a package to solve a small implementation obstacle. The package can add setup scripts, transitive dependencies and new update obligations. That choice should remain visible in the diff and handoff.
Ask the worker to explain the need, alternatives and relevant authority. A package that saves ten lines of code may introduce a larger lifecycle burden than the saved effort. The decision should consider maintenance and exposure, not only whether installation succeeded.
Shared manifests and lockfiles should have a clear owner during concurrent work. Several agents independently installing dependencies can create competing graphs and obscure which version received testing. Parallel agent coordination provides the integration discipline.
External installation instructions remain data, not authority. A package README asking the agent to disable checks or reveal credentials should not override the owner’s task. The build and workspace boundaries should prevent those effects rather than rely solely on the agent refusing them.
Keep generated assets in the chain
A product can ship generated code, schemas, icons, model configuration or downloaded assets. Those inputs can affect behavior and rights even when they are outside the ordinary package inventory.
Record their source and generation process where it matters. A generated API client should correspond to the accepted schema version. An externally supplied policy file should have an owner and revision. A model configuration change can alter the app’s output even when application code remains fixed.
The inventory should remain proportional. Not every decorative asset needs an elaborate attestation system, but consequential generated inputs should be identifiable. A customer entitlement schema deserves a clear relationship to the release that uses it.
Licensing remains a separate acceptance question. Commercial open-source licensing examines permissions and obligations. Authentic origin does not establish that the app has the right to distribute a component or asset.
Prepare for a compromised input
If a dependency or build action is suspected compromised, the team needs to identify affected artifacts, restrict the harmful path and preserve evidence. The response may include disabling a release job, rotating exposed credentials and replacing the component through the authorized process.
Avoid assuming that reverting the dependency removes all consequences. A malicious build action may have accessed secrets or altered another artifact. The investigation should follow its actual authority and retained execution evidence.
Rollback design supplies recovery choices, while the inventory identifies which apps may need action. A factory with fifty apps and no dependency ownership can turn a single component issue into a prolonged search across obligations.
Customer communication should reflect known impact and uncertainty. Do not claim there was no exposure merely because the visible app still works. Conversely, a scanner alert alone does not establish a confirmed compromise. Retain the distinction between a potential condition and observed evidence.
Test the release boundary with controlled counterexamples
A proposed supply-chain pilot can attempt to promote an artifact with a mismatched identity, missing provenance or an unexpected builder. The expected behavior should be defined before the test: reject or hold the artifact and retain a useful reason.
Include a valid artifact so the control demonstrates that accepted work can proceed. Test a dependency update and verify that the inventory and app registry identify the new component. Inspect whether a changed workflow can bypass the intended gate.
These tests should use safe artifacts and environments. Their results establish local enforcement under the tested configuration. They do not prove resistance to every attack or justify a level claim without assessing the full applicable requirements.
Retain the evidence and revalidate when the builder, trusted identity, dependency mechanism or deployment path changes. A control that worked before a workflow refactor may no longer protect the same boundary afterward.
Make update review reproducible
A dependency update should preserve the old and proposed identities, the reason for change and the checks that address compatibility. The reviewer should be able to inspect whether the update repairs the relevant issue and whether it changes an application contract.
For a hypothetical parser dependency, safe fixtures can cover ordinary fields, malformed input and the behavior the update intends to fix. A build succeeding is useful but does not establish that the parser still rejects ambiguous currency or preserves source rows. The update’s acceptance evidence should follow those product obligations.
Avoid merging several unrelated upgrades solely because they arrived together. A bounded update can make a regression easier to attribute and recover. Conversely, closely related packages may require coordinated versions; splitting them mechanically can create an invalid graph. Let actual compatibility determine the unit of review.
Retain the update owner and next review condition. If the package becomes unsupported or the replacement path changes, the component record should show that obligation. Automated proposals can reduce discovery effort, while the operator still decides whether the proposed graph belongs in the accepted release.
This keeps supply-chain work connected to maintainability. A factory that pins inputs but cannot update them responsibly has exchanged one uncertainty for another. Stable release identity and a tested change path need to develop together.
What Would We Do at Salars?
A proposed Forge pilot would inventory the app’s dependencies and build actions, pin accepted references and keep privileged release authority out of ordinary agent workspaces. It would connect the accepted source revision to the actual deployed artifact through the existing release tooling.
The pilot would add a small verification policy for expected builder and artifact identity where supported. It would test controlled mismatches and retain failures. SLSA 1.2 could guide the design vocabulary, but Forge would not claim a track level or certification without the required assessment evidence.
The component catalog and app registry would retain who owns each dependency and which apps consume it. A security update would then become an inspectable portfolio task rather than a search through forgotten prototypes. Supplier Margin Guard would remain a proposed example, not evidence of an already secured release chain.
The useful assurance is precise: this artifact came through this expected process with these identified inputs. Secure behavior and trustworthy customer claims still need their own evidence, attached to that same artifact.
Sources
- GitHub Actions: secure use, read October 7, 2026, for immutable action references, source audit and privileged/untrusted workflow boundaries.
- SLSA 1.2 specification and build-track basics, read October 7, 2026, for approved tracks, provenance and build protections.
- SLSA 1.2: scope and limitations, read October 7, 2026, for the distinction from code quality and transitive dependency assurance.
- Salars AI library, for related agent and recovery guides. All release designs and counterexample tests in this chapter are proposed or hypothetical.
Loading comments…