By: Shane Fast
Modern organizations have become better over time at thinking about software security as a necessity.
We scan for vulnerabilities, monitor CVEs, review penetration test findings, and invest heavily into endpoint protection, identity controls, and cloud security.
But…
There is another growing area of software supply chain risk that many organizations still treat as an afterthought:
Open source licensing governance.
For teams working with enterprise clients, this is no longer just a legal issue buried in paperwork. It’s increasingly becoming an operational and governance concern that can affect sales, compliance reviews, government contracts, and long-term trust.
Most modern software products are built using hundreds or thousands of third-party open source components. In many applications, the majority of the code running in production did not originate internally.
This reality is a real boon for the industry, but It has also created a new category of risk, which teams do not fully understand in the software they ship.
This is not made up!
Large enterprise software vendors and cloud providers including Microsoft, Red Hat, IBM, Google, and AWS all maintain formal open source governance practices internally. They do this because licensing obligations can materially impact software distribution models, procurement approvals, compliance obligations, and contractual risk.
Over the past decade, multiple high-profile licensing disputes have forced organizations to reassess products, dependencies, and distribution practices with little warning. In many cases, the problem was surprisingly not malicious behavior. Rather it was simply a lack of visibility and governance over their software supply chain.
As enterprise customers and government procurement teams increase scrutiny around software composition, we are being asked harder questions:
- What open source software exists in your product?
- How do you manage higher-risk licenses?
- How are exceptions approved and tracked?
- How do you ensure temporary approvals are revisited?
- Is enforcement manual, or integrated into development workflows?
Many organizations still answer these questions with spreadsheets, manual reviews, and institutional memory if they do it at all.
Certainly this does not scale well.
Why This Is Accelerating
Several trends are converging at the same time:
Modern software supply chains are deeper than ever. In order to meet demands and timelines, developers must use external dependencies.
AI-assisted development is accelerating dependency sprawl. Additionally, AI recommendations are often trained into responses without scrutiny.
Enterprise customers increasingly demand software composition transparency. People have wisened up over a robust history of security pandemonium.
Governments are introducing stricter procurement expectations. Demands of privacy and security driven in equal measures by constituents and stakeholders.
Open source vendors are reevaluating commercial licensing strategies. The humans responsible for open source projects can always change their mind.
And increasingly, these trends are not exclusive to developers and security teams, but also from:
- procurement teams
- compliance programs
- legal departments
- government reviewers
This changes the conversation significantly because license governance is no longer just a development concern, it becomes part of a greater overall operation maturity.
A Simple Way to Think About Open Source Licenses
Let’s break this down into more practical concerns. Not all open source licenses are built the same. At a very high level, we can think about licenses in three broad groups:
1. Permissive Licenses
Examples include MIT, Apache-2.0, BSD, and ISC.
These licenses are generally low-friction for commercial organizations. They typically allow organizations to use, modify, and distribute software with minimal obligations beyond attribution and preservation of license notices.
These are the licenses most enterprise organizations are comfortable with.
We generally like these 😊
2. Licenses That Require Review
Examples include LGPL and MPL.
These licenses are not inherently problematic, but they may introduce obligations depending on how software is integrated, modified, or distributed.
In practice, these often require architectural awareness and review rather than outright rejection.
These are usually “pause and assess” licenses 🕵️
3. Licenses That May Introduce Significant Obligations
Examples include GPL and AGPL.
These licenses can introduce broader redistribution or source disclosure obligations depending on usage patterns and deployment models.
For some organizations, especially proprietary SaaS vendors or regulated enterprise environments, these licenses may create legal, contractual, or procurement concerns that require careful review.
The important thing to understand is this:
Most organizations do not intentionally adopt these licenses directly.
They inherit them indirectly through transitive dependencies buried somewhere in the dependency tree.
This is where governance starts becoming difficult 🙅♂️
The Governance Gap
Most organizations already have some form of vulnerability management process, but very few have an equivalent process for licensing governance which is usually a collection of spread sheets, one-time reviews, tribal knowledge, email approvals, and panicked forgotten exceptions.
That appears to work right up until an enterprise customer asks difficult questions, or legal requests evidence, or a procurement review stalls a deal, or a dependency quietly changes licensing terms.
This problem is not visibility alone, but a problem operationalization.
Mature governance is not just “Can we detect license information?”
Its “Can we demonstrate structured decision-making over time?”
That means:
- policies that are consistently enforced
- approvals that are recorded
- exceptions that are time-bound
- audit trails that are preserved
- governance embedded into delivery workflows
Not after release.
Not during an audit scramble.
But continuously, as the product is built.
What Mature License Governance Looks Like
Organizations that treat software supply chain governance seriously are increasingly moving toward a few common principles:
Policy Enforcement Inside Engineering Workflows
Instead of relying on periodic reviews, policy enforcement becomes integrated directly into CI/CD and pull request workflows.
This allows organizations to identify licensing concerns at the moment new risk enters the codebase.
In the exact same way we already handle failing tests, dependency vulnerabilities, and static analysis findings, license governance can become another automated control.
Structured Exceptions
Real-world governance always requires nuance.
Sometimes a dependency is low risk in practice, or a package is isolated architecturally, or usage is temporary, or legal has approved a specific use case among some common reasons.
The important part is not pretending exceptions never happen, rather ensuring they are documented, approved, reviewable, time-bound, and auditable.
Without that structure, organizations eventually lose track of why decisions were made in the first place.
And six months later someone is digging through Slack messages trying to reconstruct governance history from archaeology fragments and emotional damage.
Expiration-Aware Governance
One of the biggest risks in compliance programs is drift where temporary approvals quietly become permanent simply because nobody revisits them.
Strong governance programs increasingly treat expiration as a first-class concept where approvals expire, reviews resurface automatically, superseding approvals replace older ones, and unresolved exceptions reactivate enforcement.
This prevents organizations from accumulating silent risk over time, because governance that is never revisited is usually governance that no longer exists.
Ok, But What Do We Do?
We created a tool internally that we’ve open sourced to address this problem, called Periapsis.
Not as another static reporting tool, and not as a simplistic allow/deny list.
But rather as a fully featured governance layer integrated directly into the software delivery lifecycle.
To make license governance operational instead of theoretical, it includes capabilities such as:
- policy enforcement during pull requests
- structured license categorization
- exception handling with metadata
- approver tracking
- expiration-aware policies
- audit-ready artifacts
- renewable or superseding approvals
The objective is not to eliminate judgment., but rather to ensure judgment consistently happens, is recorded, and remains reviewable over time.
Governance should not live exclusively inside spreadsheets and email chains, it should exist as part of the operational system and workflow itself.
A Shift in Mindset
Most organizations already accept that vulnerability management requires tooling, processes, enforcement, and continuous review. However, license governance increasingly deserves the same level of scrutiny.
Because in modern software environments, software supply chain risk is no longer just about malicious code or exploitable vulnerabilities, but also about the contractual and legal obligations embedded throughout the software we ship, consume, and depend on every day.
And organizations that operationalize that governance well will increasingly be the organizations best positioned to earn enterprise trust in the years ahead.
