Version: 2026-06-05
Summary
- Every new dependency is new third-party code.
- Existing project code and standard technology should be preferred.
- Release builds install from lockfiles; updates happen in pull requests.
- Dependency updates should be separate pull requests or at least separate commits.
- AI agents must not run dependency updates on the side.
- No latest images and no main/master actions in production-adjacent paths.
Topic
Third-party code, automatic updates, and software supply chain in customer projects.
Starting Point
AI tools can quickly propose packages, libraries, GitHub Actions, Docker images, Composer packages, npm dependencies, browser plugins, and convenience scripts. This can be helpful, but it also makes adding third-party code too easy.
Supply-chain risk is not limited to malicious packages. It also includes abandoned dependencies, unexpected install scripts, license issues, broken transitive updates, unaudited CI actions, and base images that change without review.
Risk
A small implementation task can silently become a dependency change. That mixes two different risks in one review: the actual feature and a supply-chain decision.
Recommendation
Keep dependency changes visible and separate. A release build should install exactly what was reviewed. Package managers must use lockfiles. CI actions and container images must be pinned to stable versions or SHAs where appropriate.
AI may propose a dependency, but the project decides whether it is needed. The first question should be whether existing project technology can solve the problem well enough.
Review Checklist
- Is the dependency actually necessary?
- Is the source reputable and maintained?
- Does it run install scripts or code generation?
- Did the lockfile change deliberately?
- Are CI actions and images pinned?
- Is the update separated from feature work?
- Is rollback clear?
Wall rules
Release builds install from lockfiles, not from hope.
CI actions are executable third-party code.
No latest images in production-adjacent builds.
New dependencies with install scripts are executable third-party code.
Composer updates are code changes, not maintenance noise.
Less third-party code, less attack surface.
Dependency updates are separate changes. Do not merge them on the side.
Every new dependency is new third-party code.
Open questions for a project
- Which registries and vendors are allowed?
- How are emergency security updates handled?
- Who reviews new dependencies?
- Which lockfile changes require special attention?