open-source-review-board ยท diff
git:20260718.7c1285c to git:20260728.fac4544
33 added, 30 removed. Audit A to A.
---
name: open-source-review-board
description: Run an open source review board that gates incoming dependencies on license compatibility, sets the policy for contributing back, and requires a security review before adoption. Use when an organization needs consistent control over which OSS it pulls in and what it publishes.
---
# Open source review board
An OSS review board is how a company keeps open source from becoming a legal and
- security liability it discovers too late. It fails when it is either a bottleneck
- everyone routes around or a rubber stamp that approves by default: dependencies
- arrive with incompatible licenses, employees push code to public repos with no
- policy, and a known-vulnerable package sits in the build because no one checked.
- The board's job is to make the safe path the easy path.
+ security liability it discovers too late. It fails when it is either a
+ bottleneck everyone routes around or a rubber stamp that approves by default:
+ dependencies arrive with incompatible licenses, employees push code to public
+ repos with no policy, and a known-vulnerable package sits in the build because
+ no one checked. The board's job is to make the safe path the easy path.
## Method
1. **Gate every new dependency on license compatibility first.** Maintain an
allow list and a deny list by license: permissive licenses like MIT, BSD, and
- Apache 2.0 usually clear; strong copyleft like GPL and AGPL needs review against
- how you distribute; anything unlicensed or with a custom license stops for a
- human. Automate the check in CI so the gate runs on every pull request, not on
- memory.
+ Apache 2.0 usually clear; strong copyleft like GPL and AGPL needs review
+ against how you distribute; anything unlicensed or with a custom license
+ stops for a human. Automate the check in CI so the gate runs on every pull
+ request, not on memory.
2. **Watch for license traps beyond the headline.** Attribution requirements,
- patent clauses, the AGPL network-use trigger, and the difference between linking
- and bundling. A permissive-looking package with a transitive GPL dependency is
- still a problem. The board reads the actual terms, not the badge on the README.
+ patent clauses, the AGPL network-use trigger, and the difference between
+ linking and bundling. A permissive-looking package with a transitive GPL
+ dependency is still a problem. The board reads the actual terms, not the
+ badge on the README.
3. **Require a security review scaled to the dependency's reach.** Scan with
- something like an SCA tool or dependency scanner for known CVEs, then judge the
- project's health: maintenance activity, how fast it patches, single-maintainer
- risk, and how much of your attack surface it touches. A parser handling
- untrusted input earns a harder look than a build-time formatter.
+ something like an SCA tool or dependency scanner for known CVEs, then
+ judge the project's health: maintenance activity, how fast it patches,
+ single-maintainer risk, and how much of your attack surface it touches. A
+ parser handling untrusted input earns a harder look than a build-time
+ formatter.
4. **Set an explicit policy for contributing back.** Decide when employees may
- submit patches upstream, who signs the contributor license agreement, and what
- must be cleared before company code goes public. A clear yes-with-guardrails
- beats a vague no that engineers quietly ignore.
- 5. **Govern what you publish as its own decision.** Releasing an internal project
- as open source needs a license choice, a security scrub for secrets and
- internal references, a trademark check, and an owner for maintenance. Publishing
- is a commitment, not a giveaway; unowned public repos rot into liabilities.
+ submit patches upstream, who signs the contributor license agreement, and
+ what must be cleared before company code goes public. A clear
+ yes-with-guardrails beats a vague no that engineers quietly ignore.
+ 5. **Govern what you publish as its own decision.** Releasing an internal
+ project as open source needs a license choice, a security scrub for secrets
+ and internal references, a trademark check, and an owner for maintenance.
+ Publishing is a commitment, not a giveaway; unowned public repos rot into
+ liabilities.
6. **Keep an inventory and re-scan continuously.** Maintain a software bill of
- materials so you know what you depend on, and re-run scans as new CVEs land. A
- dependency that was clean at adoption can become the next incident; approval is
- a moment, exposure is ongoing.
+ materials so you know what you depend on, and re-run scans as new CVEs
+ land. A dependency that was clean at adoption can become the next incident;
+ approval is a moment, exposure is ongoing.
## Signals
- Does license checking run automatically in CI, or rely on someone remembering?
- Is the security review proportional to what the dependency can touch?
- Can you produce a current inventory of every OSS package you ship?
## Boundaries
- This governs adoption, contribution, and publication policy; it does not write the
- code or decide the architecture that needed the dependency. License interpretation
- at the edges is a legal judgment: escalate genuinely ambiguous or high-stakes terms
- to counsel rather than settling them at the board.
+ This governs adoption, contribution, and publication policy; it does not write
+ the code or decide the architecture that needed the dependency. License
+ interpretation at the edges is a legal judgment: escalate genuinely ambiguous or
+ high-stakes terms to counsel rather than settling them at the board.