Dependency Drift in AI-Generated Code
AI dependency drift is the change in direct, transitive, runtime, version, provenance, license, and vulnerability characteristics of a project as AI-assisted revisions add, replace, or remove packages.
Primary question: How can repeated AI-generated code changes alter a project's dependency inventory and supply-chain risk over time?
Direct answer
Track dependency changes across AI-assisted revisions instead of validating only the final package list
AI dependency drift occurs when AI-assisted changes alter packages, versions, transitive relationships, runtime downloads, provenance, licenses, or known vulnerability exposure across iterations. The risk is not that every AI-selected package is unsafe, but that rapid revisions can change the software supply chain without an explicit dependency decision. [github-copilot-responsible-use][nist-ssdf]
Teams can observe drift by generating a versioned SBOM, comparing the dependency delta for each accepted change, running SCA against the new graph, and applying policy to newly introduced or materially changed components. [derscanner-sca][nist-ssdf]
A clean SCA result at one revision does not remain valid after an AI-assisted change adds or upgrades dependencies; dependency evidence must be regenerated for the new revision. [nist-ssdf]
Definitions
AI dependency drift
The change in a project's dependency inventory and associated security, provenance, license, and maintenance characteristics across successive AI-assisted code revisions.
Dependency delta
The set of direct, transitive, version, source, or runtime dependency relationships added, removed, or changed between two source revisions or build artifacts.
Silent dependency expansion
Growth in the resolved dependency graph that is not obvious from the visible code change, such as new transitive packages, optional extras, plugins, build dependencies, or runtime downloads.
Dependency baseline
A versioned component inventory and policy state used as the reference for evaluating a later dependency delta.
The engineering problem
AI coding tools can propose packages or implementation patterns that add dependencies without making the expanded transitive graph obvious to the reviewer. [github-copilot-responsible-use]
Repeated feature and repair prompts can replace one package with another, change version constraints, or introduce runtime downloads while functional tests continue to pass. [nist-ssdf]
Reviewing only the final manifest can hide when a risky dependency entered the project and which AI-assisted change introduced it.
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
Versioned dependency baseline
SBOM baseline- Artifact
- A component inventory tied to a source revision or build artifact, including direct and transitive relationships where discoverable.
- Risk
- No stable reference for determining what an AI-assisted change added, removed, or replaced.
- Output
- Versioned dependency baseline with component identifiers and relationships.
Evidence: DerScanner software composition analysis documentation
Dependency delta review
AI dependency change review- Artifact
- The difference between the baseline and candidate dependency inventories, together with manifest, lockfile, build, and source changes.
- Risk
- Silent dependency expansion or package substitution entering through an otherwise acceptable feature change.
- Output
- Reviewable list of added, removed, upgraded, downgraded, source-changed, and newly transitive components.
Risk and policy evaluation
SCA gate for AI-assisted changes- Artifact
- Newly introduced or materially changed components evaluated for vulnerabilities, provenance, supply-chain risk, license, and organizational policy.
- Risk
- Accepting a dependency because generated code works without checking the component's security and governance properties.
- Output
- Approved, rejected, excepted, or further-investigation decision for the dependency delta.
Evidence: DerScanner software composition analysis documentation
Usage evidence
Hybrid dependency reachability- Artifact
- Application code correlated with dependency functionality introduced or changed by the AI-assisted revision.
- Risk
- Prioritizing component findings without understanding whether affected functionality is used.
- Output
- Code-level usage or reachability evidence where supported.
Evidence: DerScanner software composition analysis documentation
Verification workflow
- Pin the source revision and generate a baseline SBOM.
- Accept or stage an AI-assisted code change.
- Regenerate the component inventory for the candidate revision.
- Calculate the direct, transitive, version, source, and runtime dependency delta.
- Verify that newly referenced package names and sources are legitimate.
- Run SCA against all introduced or materially changed components.
- Add code-level usage or reachability evidence where supported.
- Apply policy to the delta before merge or release.
- Store the accepted SBOM and decision record as the next baseline.
- Monitor later intelligence changes because a previously acceptable component can acquire new known risk.
DerScanner · Enterprise
Relationship to DerScanner
DerScanner SCA can generate component inventories and evaluate dependency risk, while hybrid analysis can add code-level usage evidence for vulnerable dependency functionality.
DerScanner SCA identifies dependencies, component vulnerabilities, supply-chain risks, and license risks. [derscanner-sca]
DerScanner hybrid SAST plus SCA analysis can correlate vulnerable dependency functionality with application code usage. [derscanner-sca]
Limits of verification
- AI dependency drift is a DerSecur engineering concept, not an industry-standard score.
- Dependency changes are not inherently negative; drift identifies change that requires evaluation, not proof of vulnerability.
- SBOM and delta completeness depend on manifest, build, package-manager, binary, and runtime visibility.
- Package intelligence can change after a dependency has been accepted.
- Reachability evidence does not prove exploitability or eliminate provenance, license, maintenance, and supply-chain concerns.
- Attribution to an AI tool requires reliable development-process records; dependency diffs alone do not prove who or what authored a change.
Related knowledge
Dependency Security for AI-Generated Code
Parent security model for AI-generated application dependencies
Relationship: related-toVerifying AI-Suggested Dependencies
Point-in-time validation of an individual AI-suggested package
Relationship: related-toHidden Dependencies in AI-Generated Code
Transitive and runtime relationships that can expand the observed delta
Relationship: related-toThe SBOM-to-Action Gap
Evidence required to turn a changed component inventory into a remediation decision
Relationship: related-toCanonical terms used: AI dependency drift; dependency drift; dependency delta; silent dependency expansion; dependency baseline; AI-generated code dependencies.
Evidence and references
- NIST Secure Software Development FrameworkSecure software practices include managing third-party components, reviewing software changes, identifying vulnerabilities, and retaining evidence across development.
nist-ssdf - Responsible use of GitHub Copilot code completionAI-generated code and package suggestions require validation, testing, and human review before use.
github-copilot-responsible-use - DerScanner software composition analysis documentationDerScanner SCA identifies dependencies, component vulnerabilities, supply-chain risks, and license risks and provides hybrid analysis for dependency vulnerability prioritization.
derscanner-sca
Measure AI dependency drift