NIST CSF 2.0 GV.SC-09: Supply Chain Security in Your Risk Program

GV.SC-09 asks that supply chain security practices are integrated into your cybersecurity and enterprise risk management programs, and that their performance is monitored through the technology product and service life cycle. It is about making supply chain risk a normal agenda item, not a side project owned by one person.

CSF is voluntary guidance. There is no CSF certification, and nobody can call a company "NIST compliant" on this basis.

What good looks like

Supply chain risk appears in the same risk register and the same leadership report as every other risk. Policies require provenance records for what you acquire. Software updates come only from authenticated, trustworthy sources. Leaders see a periodic report on how well you can show that acquired components are authentic and untampered.

How to implement it

1. Add supply chain items to your risk register: critical suppliers, key open source dependencies, build tooling.
2. Write a short acquisition rule: for software, keep a record of where it came from, which version, and how you verified it (signatures, checksums, signed releases).
3. For your own products, generate a software bill of materials at build time so you can answer what is inside.
4. Require patches and updates to come from the vendor's authenticated channel, not a forum link.
5. Report to leadership each quarter with three or four numbers: suppliers reviewed on time, components without provenance, updates applied from verified sources, open supplier issues.
6. Check that supplier staff doing maintenance on their products are approved, and that critical hardware upgrades are checked for unauthorized changes.

What to report to leadership

Leaders do not need a list of tools. They need to know whether supply chain risk is going up or down and what decision is needed. A one page quarterly view works well: the share of critical suppliers reviewed on schedule, the number of production applications with a current component inventory, how many components lack a verified source, how many supplier issues remain open past their due date, and one paragraph on the biggest exposure.

Integrating with enterprise risk

Integration means supply chain risks use the same scoring scale, the same owners and the same review meeting as other enterprise risks. If your risk register rates a payment outage as high, a payment supplier failure should be rated on the same scale and appear in the same list. Avoid a parallel spreadsheet that only the security team reads.

Trusted update sources

Write down, per product, where updates come from, and check that the channel is authenticated. For operating systems and packages that usually means vendor repositories with signature verification enabled. For hardware, it means firmware from the manufacturer with a checked hash, and approved personnel performing maintenance. Spot check once a quarter that automatic update settings still point at the approved sources.

Evidence to collect

• Risk register entries for supply chain risk.
• The acquisition policy with the provenance requirement.
• SBOMs or dependency inventories per product.
• The leadership report and meeting notes.

Try it yourself

You can see a first dependency inventory for a manifest with the free in browser scan at https://gold.safeguard.sh/scan. It is a quick way to see what a provenance record would need to cover.

Common gaps

• Supply chain risk is discussed once a year and nowhere else.
• Provenance is a policy statement with no records behind it.
• Metrics count activity (questionnaires sent) instead of results (gaps closed).

Quick check

Sources

• NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf