Technology Portfolio Management (TPM) Best Practices

Overview

Open source software occupies a unique and particularly complex position in the Technologies Inventory family. It is not a marginal category that affects only technically sophisticated organizations — it is pervasive across virtually every enterprise technology stack, present as a direct dependency in development frameworks and runtime environments and as a transitive dependency embedded dozens of layers deep in the components that organizations believe they are simply purchasing or consuming. The governance challenge of open source is not only that it is widely used; it is that its use creates governance obligations — license compliance, security vulnerability management, supply chain risk management, SBOM maintenance — that many organizations have not formally recognized as obligations they bear.

Open source is not free in the governance sense. Every open source component the organization uses carries a license that imposes specific obligations on how the software may be used, modified, and distributed. Some licenses are permissive, imposing minimal obligations. Others are copyleft, imposing obligations that can require the organization to release its own code under the same license if the open source component is modified or distributed. The consequences of license obligation failures range from public embarrassment to litigation to mandatory code disclosure. And separate from license obligations, the security vulnerability profile of open source components — particularly transitive dependencies that the organization may not even be aware it is using — represents a significant and well-documented attack surface that sophisticated adversaries actively exploit.

Best Practice

Govern open source software as a first-class technology category with its own dedicated inventory type — the Open Source Components Inventory — its own governance standards, its own assessment dimensions, and its own compliance obligations, all maintained with the same rigor applied to any other category in the Technologies Inventory family. Do not treat open source governance as a supplementary concern addressed only when a specific compliance issue arises. Treat it as a continuous governance discipline with defined ownership, defined standards, and defined reporting, maintained across the full portfolio of open source components the organization uses.

Benefit(s)

Treating open source software as a first-class governance category rather than an informally managed technical choice produces the compliance, security, and strategic governance outcomes that open source’s pervasive presence in the enterprise technology stack requires. License compliance is governed rather than assumed. Security vulnerability exposure is tracked and remediated systematically rather than discovered in the aftermath of incidents. Supply chain risk is assessed and managed rather than ignored. And the organization can respond confidently to customer, regulatory, and partner requests for SBOM data, software provenance information, and open source compliance attestations because the governance disciplines required to produce those responses are maintained continuously rather than assembled on demand from incomplete information.