Topic starter
14/09/2026 10:10 am
TL;DR: Open source components now appear in 96% of commercial codebases, and Apiiro argues that manual legal review cannot keep pace with continuous delivery, transitive dependencies, or AI-generated code that may embed copyleft-licensed snippets without manifest evidence. License compliance has shifted from a legal afterthought to an AppSec control problem, where automated policy enforcement and SBOM visibility determine whether software can ship safely.
Editorial analysis by NHI Mgmt Group, based on content published by Apiiro: “Why Open Source License Compliance Is Now Your AppSec Team's Problem”.
By the numbers:
- Open source components now appear in 96% of commercial codebases, according to Apiiro.
- The 2025 Linux Foundation survey found that 83% of organisations see clear value in open source adoption, but only 34% have defined a strategy for managing it, according to Apiiro.
- The 2025 Verizon DBIR reported that 30% of breaches now involve a third party, a 100% increase year-over-year, according to Apiiro.
Key questions
Q: What breaks when open source licence compliance is not built into the AppSec pipeline?
A: Manual review breaks first because it cannot keep up with continuous delivery, transitive dependencies, or generated code.
Q: Why do restrictive open source licences create business risk for commercial software teams?
A: Because some licences can obligate disclosure of derived work, which can conflict with proprietary distribution models, customer commitments, or acquisition plans.
Q: What do AppSec teams get wrong about open source licence compliance?
A: They often treat it as a legal review problem rather than a pipeline control problem.
Practitioner guidance
- Codify licence policy as machine-readable rules Define permissive, grey-list, and prohibited licences in a policy that your CI/CD system can evaluate automatically at build time.
- Scan transitive dependencies on every pull request Use software composition analysis to inspect nested packages and container layers, not just direct imports, so hidden obligations are caught before merge.
- Generate continuous SBOMs for each release Produce CycloneDX or SPDX output from the pipeline and retain version, origin, and licence metadata so audits do not depend on manual reconstruction.
Bottom line: Open source licence compliance has moved into the AppSec workflow because continuous delivery exposes terms that manual legal review cannot reliably catch.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:11 am
License governance has become a software delivery control, not a legal afterthought. The decisive change is that compliance decisions now need to happen at the same speed as pull requests and builds, not at quarterly review points. That moves the control plane into AppSec, where dependency visibility and policy enforcement already exist. Practitioners should treat license status as a release condition, not a post-release audit item.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should organisations handle licence risk from AI-generated code?
A: They should treat generated code as untrusted until it is compared against known open source sources and checked for copyleft similarity. Standard manifest scanning is not enough because the risky material may never appear as a declared dependency. The governance model needs snippet-level detection and human review for matched content.
👉 Read our full editorial: Open source license compliance is now an AppSec pipeline issue