Skip to main content

Compliant Open Source Usage

A quick reference guide for organisations at Level 2 maturity—establishing governance, compliance, and an OSPO for open source consumption.

At Level 1, open source usage happens organically but without visibility or control. Level 2 is about bringing structure to that usage. The case for investing in Level 2 maturity is compelling:

  • Security incidents are expensive. Log4Shell demonstrated that organisations without software inventory couldn't quickly assess their exposure. The cost of scrambling to respond far exceeds the cost of knowing what you have.
  • Regulators are paying attention. The EU Cyber Resilience Act and similar legislation are making software supply chain management a compliance requirement, not just a best practice.
  • License violations carry real risk. Using open source without understanding license obligations can lead to litigation, forced code disclosure, or reputational damage.
  • Ad-hoc approaches don't scale. As open source usage grows, informal processes break down. An OSPO provides the coordination needed to manage open source consistently across the organisation.
  • Level 2 enables Level 3. You can't safely contribute to open source projects until you have the governance structures in place to manage that activity.

1. Creating an OSPO​

An Open Source Program Office (OSPO) centralises open source governance and enables you to move from ad-hoc usage to structured consumption. Creating an OSPO is organisational change—you'll need to build a coalition, demonstrate value, and align with existing KPIs.

See: Creating an OSPO for Kotter's 8-step change process applied to OSPO creation, including building urgency, forming coalitions, and generating quick wins.

See: OSPO Structure for staffing models, reporting lines, and organisational placement.

2. Compliance & Risk Management​

Using open source in a regulated firm requires understanding how it intersects with existing compliance frameworks. The Log4Shell incident demonstrated why open source supply chain risk needs formal controls.

See: Compliant Open Source Consumption for the three lines of defence model, the compliance function, and risk-and-control frameworks applied to open source.

See: Creating Policy for developing an open source consumption policy.

See: Cyber Resilience Act Presentation for how EU legislation is reshaping software supply chain compliance requirements.

See: Legal Aspects of Open Source for Aaron Williamson's guidance on compliance beyond license basics.

3. Software Inventory & Supply Chain Security​

You can't manage what you can't see. Knowing what open source you're using—and where—is foundational to security and compliance.

See: Software Inventory for approaches to cataloguing open source usage across your estate.

See: Supply Chain Security for vulnerability management, SBOM generation, and responding to incidents like Log4Shell.

See: SBOMs for Software Bill of Materials as an artifact.

See: ORT (Open Source Review Toolkit) Presentation for how OSPOs are using ORT for compliance and inventory.

See: FossID Presentation for SCA tooling and AI-assisted detection.

4. License Management​

Open source licenses carry obligations. Using software without understanding its license can create legal risk.

See: License Management for building an allow-list, reviewing licenses, and tooling for compliance.

See: Licenses for understanding common license types and their implications.

See: OpenChain Presentation for the ISO standard for open source license compliance.

5. Training​

Staff need to understand the firm's approach to open source consumption, including how to evaluate components and comply with policy.

See: Consumption Training for curriculum guidance on safe open source consumption.

See: Training Index for Linux Foundation courses and other resources.