The gap between an organisation’s approved open-source rules and the actual licences flowing through repositories and pipelines. It usually appears when manual review, exceptions, and fragmented tooling make policy enforcement inconsistent across the software lifecycle.
What License Policy Drift Means in Practice
License policy drift is rarely a single-event failure. It usually emerges when the policy says one thing about approved open-source usage, but repository reality, dependency updates, transitive packages, or pipeline exceptions gradually move in a different direction.
The important point is that drift is measured against the organisation’s intended licensing position, not against whether the code is technically buildable. A project can remain functional while quietly accumulating licence obligations that no longer match the approved policy baseline.
Why License Policy Drift Happens
Drift often begins with manual exception handling, where teams approve one-off cases without a durable record or expiry. It also appears when ownership is split across development, security, procurement, and legal teams, so no single control point continuously reconciles policy with actual dependency intake.
Fragmented tooling makes the problem worse. A scanner may identify direct dependencies, while a separate pipeline step, package mirror, or build cache introduces another licence-bearing component that is not evaluated in the same way.
Over time, that gap can widen through ordinary software change. New libraries, renamed packages, version upgrades, and transitive pulls can all change the effective licence profile even when no one intentionally changes policy.
How License Drift Affects Governance and Delivery
License policy drift creates more than legal uncertainty. It weakens the organisation’s ability to prove that open-source usage is governed, reviewed, and aligned to approved rules across the software lifecycle.
For engineering teams, drift can slow releases when licences are discovered late and must be remediated under time pressure. For governance teams, it can create false confidence if the policy documentation looks current while the actual artefact inventory does not.
The practical impact is consistency. Mature programmes treat licence policy as an operational control, not a document, and they expect the policy baseline, dependency inventory, and exception record to stay aligned as code changes.
What Good Control Looks Like
Effective control depends on continuous comparison between approved rules and real dependency data. That means the organisation needs a current view of direct and transitive licences, a repeatable exception process, and a clear owner for policy decisions across repositories and pipelines.
When OWASP SAMM is used well, it helps teams embed governance into the delivery process instead of treating licence review as an after-the-fact checkpoint. For supply-chain integrity, SLSA is useful because provenance and build traceability make it easier to understand what actually entered the artefact stream.
Organisations also need an operational baseline for control rigor. NIST SP 800-53 Rev 5 Security and Privacy Controls provides the broader control context for access, configuration, audit, and integrity practices that support consistent licence governance.
Risk and Threat Considerations
License policy drift can expose organisations to compliance failures, unexpected disclosure obligations, and delivery disruption when a previously approved dependency becomes unacceptable. The risk is often cumulative: one exception is manageable, but repeated exceptions and untracked transitive changes can make the compliance picture unreliable.
Failure mechanism: A licence enters the build through a direct dependency, transitive package, fork, mirror, or exception path that bypasses the organisation’s approved review flow, leaving policy and reality out of sync.
Impact: The organisation may ship software under terms it did not intend to accept, miss remediation windows, or discover the issue only when release, legal review, or customer diligence forces a delay.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP SAMM, SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP SAMM | Governance — Governance | Governance practice for embedding security decisions into software delivery. |
| Recommendation — Embed licence review into the delivery lifecycle and keep exception handling current. | ||
| SLSA | PROVENANCE — Provenance | Build provenance helps verify what components and sources entered the artefact stream. |
| Recommendation — Require provenance evidence for builds so dependency changes are traceable. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Auditability supports detecting licence-rule drift and exception gaps. |
| CM-8 — System Component Inventory | Accurate inventories are needed to compare approved policy against actual software components. | |
| Recommendation — Log dependency and exception changes so licence drift can be reviewed quickly. Maintain an inventory of components and licences across repositories and pipelines. | ||
Practitioner Guidance
Why practitioners should care: Treat license policy drift as a living control problem, not a periodic legal review. If the approved policy cannot be reconciled continuously with repository and pipeline output, the organisation is relying on assumptions rather than evidence.
Governance implication: Assign a clear owner for exception approval, expiry, and periodic policy reconciliation so that open-source intake, build tooling, and legal review all feed the same operating picture.
Practitioner takeaway: The strongest control is not stricter wording in the policy, it is a repeatable mechanism that keeps approved licences, actual artefacts, and exception records aligned.