Last month, one of our services started using a package I had never seen before. It had only a handful of stars, a single maintainer, and had not been updated in more than a year. An AI assistant had suggested it for a small helper function, and a developer accepted the change without anyone specifically reviewing the new dependency.
More of our manifests and dependency files are now being created or edited with AI assistance, but ownership of that risk is unclear. We scan container images for known vulnerabilities, yet that does not catch a suspicious new package that has no CVEs and may simply have been hallucinated into a requirements file or selected without proper vetting. Image admission policies also do not necessarily inspect the libraries imported by the application inside the image.
At the moment, there is very little between an assistant suggesting a package and that package being built and deployed. How are other teams tracking AI-suggested dependencies, evaluating package reputation, and preventing unreviewed or suspicious libraries from reaching a cluster?
5 Answers
Treat AI-generated dependency suggestions like untrusted input. Have CI show a clear dependency diff, check that every package is declared and pinned, run software-composition and malware checks, and require an owner to approve exceptions. For higher-risk services, build with restricted network access and limit which secrets are available during installation and startup, so a malicious package cannot immediately exfiltrate everything if it slips through.
CVE scanning is only one layer and is often late for brand-new or deliberately typosquatted packages. Add package-risk checks for maintainer history, release activity, ownership changes, unusual install scripts, namespace similarity, popularity, and project health. Tools based on package reputation or open-source project scoring can alert or block on those signals, but use them as risk prioritization rather than an automatic substitute for review.
A vetted image registry helps with image provenance, but it will not catch a dependency added to a project before the image is built. Put controls earlier in the pipeline: require committed and pinned lockfiles, fail builds when dependencies change without an approved pull request, and restrict package downloads to approved registries or mirrors where possible. That creates an audit trail for how each library entered the build.
AI does not remove human responsibility, so the engineer who submits the change still needs to understand and review it. However, relying only on people to notice every package added by an assistant is fragile. Dependency changes should be easy to see in pull requests, and teams should require an explicit review for new or unusual libraries rather than treating them like ordinary source edits.
Popularity alone is not a reliable safety signal. I would prioritize warnings based on behavior and change risk: install or build scripts, unexpected network access, new maintainers, sudden ownership transfers, unsigned releases, typosquatting indicators, and dependencies with access to sensitive credentials. A small package with no install script may be less urgent than a popular package that executes code during installation.
Exactly. Image signing proves where the final image came from; it does not prove that every library inside the application was reviewed. You need both image-level controls and source/dependency-level controls.