The OSBR Handbook
Sign in

Supply Chain & Risk

This is the standard the Quality Gate's Security lens holds work to for two questions that turn out to be the same question: what third-party code do we ship, and how do we decide how much risk in it we are willing to live with? It sits beside the Security Policy and Application Security standard — those cover the controls we build and the code we write; this covers the code we import, and the register that governs the risks we knowingly accept. Most breaches don't start in the code we wrote; they arrive through the code we depended on, or through a risk nobody wrote down. Deviations are allowed, but — as everywhere in the handbook — they must be deliberate and justified in the project's design notes.

Owning our supply chain is where OSBR's values become operational. Be Nice: the safest dependency is the one we never added, so we don't drag in a tree to save a few lines a teammate then has to reason about. Be Kind: a known-vulnerable package or an unwritten risk is a hazard we would be handing to our clients and to whoever maintains this next, so we keep the surface known, pinned, and scanned. Be Strong: when a dependency has a flaw and no patch yet, we say so plainly, put a name against the residual risk, and decide in the open rather than shipping past it in silence.

How to read this policy

1. Goal

Ship software whose every third-party component is known, pinned, scanned, current, and attestable, and carry every risk we accept named, assessed, and signed for. Concretely, when a CVE lands or a package is compromised, we can answer three questions in minutes, not days:

  1. Do we use it? — we have an SBOM.
  2. Where, and at exactly which version? — we have committed lockfiles.
  3. Is what we built actually what we shipped? — we have provenance.

And when a flaw has no fix yet, we can answer a fourth: who decided to live with it, and until when? — we have a risk register (§4). An unknown or unpatched dependency is treated as a live risk to the client, not a backlog item.

2. Responsibility

Risk is not a separate team's job; it is a shared reflex. These duties build on the frameworks OSBR already aligns to: the OWASP Top 10, specifically A06

Vulnerable & Outdated Components; the NIST SSDF (SP 800-218) practices PW.4 (reuse well-secured components) and PS.3 (protect each release with provenance); and the ISMS risk-management cycle of ISO/IEC 27001
 (clauses 6.1.2, 6.1.3, 8.2–8.3).

3. Supply-chain security

3-1. Lockfiles and exact versions

3-2. Software Composition Analysis (SCA) in CI

Every pipeline MUST scan dependencies for known vulnerabilities on each pull request and MUST fail the build on findings above the project's agreed threshold (default: High and Critical). See the CI/CD Pipeline standard for where this gate sits in the flow.

The two layers earn their keep together: native auditors are fast and ecosystem-aware; a cross-ecosystem OSV/Dependency-Check pass catches what a single package manager misses and gives one consistent report across a polyglot repo.

3-3. Secrets scanning

A leaked credential is a supply-chain failure in the other direction — our secret, out the door. Scanning MUST happen at two points:

If a credential is committed it MUST be revoked immediately (per the Security Policy), not merely deleted from the branch — history and forks retain it.

3-4. Version pinning for images and tools

3-5. Dependency updates — automated, but merged by a human

Stale dependencies are how A06 happens. Updates are automated; merging stays human.

3-6. SBOM, provenance, and integrity

Every release MUST be able to say what's in it and prove it built it.

SBOM answers what, provenance answers how it was built, signing answers is this the real one. Each is cheap to add in CI once and pays off the first time an advisory names a package we might use.

3-7. Remediation time-frames by severity

When a known vulnerability affects a dependency we ship, the clock starts at disclosure (advisory published, or bot PR opened). Severity uses the advisory's CVSS rating.

Severity Remediate within
Critical 3 business days (patch, or documented mitigation + isolation)
High 7 business days
Medium 30 days
Low Next regular update cycle

3-8. Minimize the dependency surface

The safest dependency is the one you didn't add — a security posture and OSBR's vendor-neutrality stance at once, since fewer external lock-ins mean more of the system we can actually reason about.

4. The risk register that governs accepted risk

Sections 3-1 to 3-8 keep the surface small and current, but no control reduces risk to zero, and some risks — a flaw with no patch, a control we chose not to build — we knowingly carry. Those decisions live in one risk register per project: the single place OSBR decides how much security is enough for a given project, by assessed risk, recorded and kept current. This is the OSBR-scale application of the ISMS risk cycle in ISO/IEC 27001

, with the how-to drawn from ISO/IEC 27005
 and NIST SP 800-30 Rev. 1.

4-1. Start from an information-asset inventory

You cannot assess risk to assets you have not listed. Before assessing risk, a project MUST hold a current inventory of the information assets it touches — the protected assets enumerated in the Security Policy (source code and accounts; user data and uploads; access logs and metrics; communication history), made concrete for this project.

4-2. Keep one register, and keep it current

There MUST be exactly one risk register per project, and it MUST be the single source of truth for security-risk decisions. A register that is out of date is worse than none, because it manufactures false confidence. It SHOULD live where the project already works (a repository file or the tracker), version-controlled so its history is auditable. Each entry MUST carry all of:

Field What it captures
Description The risk as a scenario: threat source → what it does → which asset → the harm. Vague entries ("security", "AWS") are not risks.
Likelihood How probable, on a scale the project has defined (§4-3).
Impact How bad if it happens, on the same defined scale.
Countermeasures The controls in place or planned to reduce likelihood and/or impact.
Residual risk (named and accepted) The risk that remains after countermeasures — stated explicitly, formally accepted by a named person (§4-4).
Owner The single named risk owner (§2).
Re-evaluation date When this entry is next reviewed, even if nothing triggers it sooner (§4-6).

An unpatched dependency held past the §3-7 clock is exactly such an entry: the description names the CVE and the asset it exposes, the countermeasures record the mitigation, and the residual risk is signed with an expiry.

4-3. Assess by likelihood × impact; make control weight proportional

Score each risk by likelihood × impact, following the method of NIST SP 800-30 Rev. 1 (prepare → conduct → maintain). A qualitative scale (Low / Medium / High on each axis) is the sensible default for an SME project — fast, good enough to rank, readable by everyone.

4-4. Name and accept residual risk — with a sign-off

No control reduces risk to zero. What remains is residual risk, and OSBR's rule is that it is never left implicit.

4-5. Treat, then record what you chose

For each risk, choose a treatment and record it: reduce (add countermeasures), avoid (don't do the risky thing), transfer (a managed service or insurance carries it), or accept (per §4-4). This is the treatment vocabulary of ISO/IEC 27005

. The register records the choice and its rationale so a future reader — or an auditor — can see why the control weight is what it is.

4-6. Re-evaluation triggers

The register is a living document. A project MUST re-evaluate the affected entries — and add new ones — whenever any of the following happens, without waiting for the scheduled date:

Absent a trigger, every entry is still re-evaluated on its re-evaluation date (§4-2). Risk assessment is a loop, not a one-time gate — the "maintain the assessment" step of NIST SP 800-30 and the continuous monitoring of the ISO/IEC 27005 cycle.

References

Supply-chain standards & frameworks

Vulnerability data

Auditing & updates

Secrets scanning

SBOM, provenance & signing

ISMS risk management (the frame)

Risk assessment method, register & quantification

Related OSBR standards