Open Source Software Policy Template: Approve, Track and Maintain Open Source Safely

Most organisations run far more open source than they ever approved, and without a written policy nobody owns the licence decisions, the inventory, the update cadence or the moment a component stops being maintained. This template is an editable open source software policy covering intake and approval, licence rules, security criteria, software bills of materials (SBOMs), dependency pinning and sources, vulnerability response, end of support, and contributing back. It is written for CISOs, heads of engineering, open source programme offices (OSPOs) and legal teams, and maps to ISO/IEC 27001:2022 and NIST CSF 2.0. For the discipline behind it, read the Open Source Security Guide and the Open Source Licence Compliance Guide; this page is the policy document itself. Have legal review the licence sections before adoption.

How to use this template

• Replace placeholders: text in square brackets, such as [Organisation], [OSPO] and [30 days], is yours to set. Bracketed values are suggested defaults, not external requirements.
• Must and should: "must" is mandatory; "should" is recommended, and departures need a documented reason.
• Keep lists out of the policy: the approved, conditional and prohibited licence lists (section 5) and the approved package sources (section 7) belong in a standard that the [OSPO] can update without re-approving the policy.
• Automate the checks: most rules here can be enforced in software composition analysis (SCA), the package proxy and CI. Write the policy so each rule names the control that enforces it.
• Distributed versus internal use: licence obligations differ when software is shipped to customers, run as a service, or used only internally. Keep the distinction in section 5.

1. Purpose

This policy sets how [Organisation] selects, approves, records, maintains and retires open source software, so that licence obligations are met, security risk from third-party code is known and treated, and every open source component in use has an owner and a supported version. It supports NIST CSF 2.0 outcomes ID.AM-02 (inventories of software are maintained) and PR.PS-02 (software is maintained, replaced and removed commensurate with risk).

2. Scope

This policy applies to all open source software used by [Organisation], whether incorporated into products, used to build or deploy them, or run internally, including:

• Libraries and packages pulled from public registries (for example npm, PyPI, Maven Central, NuGet, crates.io, RubyGems, Go modules) as direct or transitive dependencies.
• Container base images, operating system packages, and infrastructure as code modules.
• CI/CD components such as GitHub Actions, GitLab CI templates and build plugins.
• Standalone open source applications and tools run on [Organisation] systems.
• Open source AI models, datasets and model-serving frameworks.
• Code snippets copied from public sources into [Organisation] repositories, including code suggested by AI coding assistants.

It applies to employees, contractors and suppliers who write, build or deploy software for [Organisation].

3. Roles and responsibilities

4. Intake and approval

1. A new direct dependency, application or AI model must pass the intake checks in the table below before it is merged to a main branch or deployed.
2. Components that pass all automated checks are approved automatically and recorded. Components that fail any check require [OSPO] review, and security failures require [security team] review.
3. Transitive dependencies are covered by the automated checks in CI; they do not need individual intake requests, but they are subject to sections 5, 7 and 8.
4. Developers must not bypass intake by vendoring, copying or forking a component.

OpenSSF Scorecard checks that are most useful at intake include Maintained, Security-Policy, Code-Review, Branch-Protection, Signed-Releases, Pinned-Dependencies, Dangerous-Workflow, Token-Permissions and Vulnerabilities. See the OpenSSF Scorecard Guide.

5. Licence requirements

1. Licences must be recorded using SPDX identifiers and expressions in the SBOM and SCA tool.
2. Distributed products must ship the attribution notices and licence texts their components require, generated from the SBOM at release.
3. A change of licence in a new version of a component (for example a move to a source-available licence) must trigger re-review before upgrade.
4. The table above is the default; [Legal] owns the authoritative lists.

6. Inventory and SBOM

1. Every build of a product or service that [Organisation] ships or runs in production must generate an SBOM in SPDX or CycloneDX format, including transitive dependencies.
2. SBOMs should contain at least the NTIA minimum elements: supplier, component name, version, other unique identifiers (such as package URL), dependency relationship, SBOM author and timestamp, plus the declared licence.
3. SBOMs must be stored centrally and linked to the release, so that [Organisation] can answer "where do we use component X version Y" within [4 hours].
4. Customer requests for SBOMs must be handled by [the product security team] under [the disclosure standard].

See the SBOM Guide and SBOM operations; OWASP Dependency-Track Guide covers one way to hold SBOMs centrally.

7. Sources, pinning and build integrity

1. Packages must be fetched through [Organisation]'s approved package proxy or private repository, not directly from public registries, for CI and production builds. See the Private Package Repository and Proxy Guide.
2. Internal package names must be reserved or scoped so that a public package cannot be substituted for them (dependency confusion). See the Malicious Package and Dependency Confusion Guide.
3. Builds must use lockfiles committed to the repository, with integrity hashes where the ecosystem supports them. Version ranges must not resolve to new versions at build time without a reviewed change.
4. CI/CD actions and build plugins from third parties must be pinned to a full commit hash, not a tag or branch.
5. Container base images must be pinned by digest and rebuilt at least [monthly].
6. New package versions should not be adopted automatically until they have been public for [7 days], except for security fixes.
7. Install scripts should be disabled by default in CI where the ecosystem allows it.
8. CI tokens used for builds must have least-privilege permissions, and publishing credentials must not be available to dependency install steps.

8. Vulnerability and compromise response

1. Timescales run from when the finding is first reported by [Organisation]'s tooling. A finding may be closed as not affected only with a recorded justification (for example a VEX statement that the vulnerable code is not reachable).
2. Automated dependency update tools (for example Dependabot or Renovate) should be enabled on all active repositories. See the Dependency Update Automation Guide.
3. A component confirmed as malicious or compromised must be treated as a security incident: block it at the proxy, identify every build and host that installed it from SBOMs and logs, and rotate any credentials present where it ran. See the Malicious Open Source Package Response Playbook.

9. End of support and abandoned components

1. Each team must track the support status of the runtimes, frameworks and components its services depend on.
2. Components must be upgraded or replaced before their upstream end of life. Where that is not possible, an exception (section 12) must record the compensating controls, such as commercial extended support, isolation or a fork maintained by [Organisation].
3. A component with no release and no maintainer response for [24 months], or whose repository is archived, must be reviewed for replacement.
4. Unused dependencies must be removed; teams should review dependency lists at least [twice a year].

See the Operating System End of Life and Extended Support Guide and Unsupported PHP versions.

10. AI-generated code and models

1. Packages suggested by AI coding assistants must pass section 4 intake like any other dependency; developers must confirm that a suggested package exists and is the intended project. See the Slopsquatting and Package Hallucination Guide.
2. Open source AI models and datasets must be recorded in the inventory with their licence and source, and loaded only in formats approved by [the security team].

11. Contributing to open source

1. Contributions of [Organisation] code to external projects, and publication of new [Organisation] open source projects, require [OSPO] approval and must not include secrets, customer data or proprietary code.
2. [Organisation]-maintained projects must have a security policy (SECURITY.md), branch protection, MFA for maintainers and signed releases. See the Open Source Project Maintainer Security Guide.

12. Exceptions

1. Exceptions must be requested through [the exception process], stating the component, rule, risk, compensating controls and an expiry no later than [12 months].
2. Licence exceptions are approved by [Legal]; security exceptions by [CISO] or delegate.

13. Compliance and monitoring

The [OSPO] and [security team] must report [quarterly] on:

• Percentage of production services with a current SBOM.
• Open critical and high component vulnerabilities past target, by team.
• Components with prohibited or unknown licences in use.
• Builds pulling packages from outside approved sources (target zero).
• Components past upstream end of life without an exception.
• Third-party CI actions not pinned to a commit hash.

14. Review and approval

Implementation guidance

Rollout

1. Inventory first: generate SBOMs for production services and run licence and vulnerability scans in report-only mode. Expect unknown licences and old versions; record them, do not block yet.
2. Route through the proxy: point CI at the package proxy and turn on malicious package blocking, which has few false positives and stops the most damaging events.
3. Gate new dependencies only: enforce section 4 on new direct dependencies in pull requests before enforcing it on the existing backlog.
4. Pin CI actions and images: automated tools can rewrite tags to hashes; pair this with an update bot so pins do not go stale.
5. Turn on remediation timescales: start with KEV-listed and critical findings, then extend to high.
6. Roll back safely: if a gate blocks delivery, switch that rule back to warn for [14 days] and fix the cause, rather than adding blanket exceptions.

Framework mapping

Sources

• NIST: SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NTIA: The Minimum Elements for a Software Bill of Materials
• OpenSSF: Scorecard checks documentation
• CISA: Known Exploited Vulnerabilities Catalog

Related NHI Mgmt Group resources: Open Source Security Guide · Open Source Licence Compliance Guide · Secure SDLC Policy Template · SLSA and Build Provenance Guide · NIST Secure Software Development Framework Guide