GV.SC-09 Supply chain security across the life cycle

What GV.SC-09 asks for across the product and service life cycle

When a customer or assessor asks how you know acquired components are genuine, the answer under GV.SC-09 is that your supply chain security practices are part of your cybersecurity and enterprise risk management programs, and their performance is monitored across the full life cycle of the products and services you buy and run. In practical terms, you need records showing where a component came from, evidence that it is authentic and has not been altered, and a monitored way to confirm that updates and hardware changes come from sources you have approved. GV.SC-09 is a Subcategory of the Cybersecurity Supply Chain Risk Management (GV.SC) Category in the GOVERN Function of CSF 2.0. It absorbs part or all of CSF 1.1 ID.SC-1, so organizations mapping an older assessment should move those answers here.

The risks are concrete: counterfeit or tampered hardware, software altered before delivery, and patches or firmware that arrive from an unverified source. The difficulty is that the evidence sits in several places at once. Provenance details are held by suppliers, build and packaging records live in engineering tools, and the state of what is actually running sits in your own inventory and deployment systems. No single team usually sees all three. A useful first step is to pick one critical product, trace it from supplier to production, and note every point where you would learn of a tampered or unauthenticated item. Confirm with each supplier which provenance and integrity records they can provide before you write them into a contract.

Because GV.SC-09 sits in the GOVERN Function, leaders are expected to set the expectation and review the results, not only the engineers who check individual parts. Decide who owns provenance requirements, which product classes they apply to first, and how exceptions are approved and reported to leadership. Expect the work to recur, since each new supplier, release and hardware refresh creates new evidence to collect. Ask any implementation partner to show, in writing, which records they will set up, which systems will hold them, and which parts remain the supplier's responsibility.

Which products, suppliers and upgrades fall under GV.SC-09

GV.SC-09 applies wherever an organization acquires technology and then depends on it staying authentic and untampered. The cards below set the boundaries: what is acquired, who controls the update path, and which upgrades need a check before they go live.

Acquired hardware and firmware

Start with the physical and low-level components you buy: servers, network devices, endpoints, storage and the firmware that runs on them. Record which items must arrive with provenance records, such as manufacturer identity, shipment chain and serial traceability. Decide which devices are critical enough that a tampering check is required at receipt and before deployment. Ask suppliers to confirm how firmware images are signed and how you can verify them.

Commercial and open-source software

Include every software product you install, whether licensed, subscribed or built from open-source components. For each one, confirm that you can obtain a software bill of materials and that you can tell whether the delivered artifact matches what the publisher or project released. Pay particular attention to components pulled in as dependencies, because they often reach production without a separate purchasing decision.

Managed services and remote maintenance

Managed service providers and vendors with remote access can change systems without your change process. Scope in any provider that installs, patches or administers in-scope systems, and list the personnel and accounts they use. Decide which maintenance tasks must be performed by approved supplier personnel, and confirm how those individuals are vetted and how their sessions are recorded.

Patch and update channels

Every update source is a potential route for tampered code, so list each one: vendor portals, package repositories, container registries and automatic update services. Assign a named team to own each channel and to approve changes to its configuration. Only patches obtained from authenticated providers should enter the environment, so document the verification step that every update passes before deployment.

Critical hardware upgrades

Hardware upgrades on critical systems, such as replacing a controller, adding a network card or swapping a storage module, can introduce unauthorized components. Define which upgrade categories trigger an integrity check, and specify what that check covers, including comparison against the expected configuration and inspection for unapproved parts. Assign the team that signs off before the upgraded system returns to production.

How an assessor tests GV.SC-09

This table compares the five Implementation Examples for GV.SC-09 by what an assessor typically asks to see, the evidence that usually satisfies it and the gaps that tend to appear. Read each row as one line of the test: the example is the expectation, the evidence is what you should be able to produce on request, and the findings show where programs commonly fall short.

Test area	Evidence an assessor expects	Common findings
Provenance records for acquired products and services	Records showing where each acquired product, component or service came from, who supplied it and when it was received, tied to the asset inventory	Records exist for hardware but not for software libraries, open-source components or cloud-delivered services
Reporting to leaders on authenticity and tampering	Recent reports or dashboard extracts sent to leadership showing verification results for critical components and any open tampering concerns	Verification is performed but never reported upward, so leaders cannot show they were informed
Patches acquired only from authenticated providers	Documented update sources for each critical platform, signature or hash verification steps and a record of rejected or unverified packages	Update mirrors or third-party repositories are used without a documented trust decision
Approved supplier personnel for maintenance	A list of approved maintenance providers and staff, access approvals, session logs and evidence that access was removed when work ended	Vendor engineers hold standing remote access with no named approval or review
Checks on critical hardware upgrades	Pre-change verification records such as firmware hash comparison or inspection results, change tickets and sign-off before deployment	Firmware and hardware changes are installed through routine change management without a tamper or authenticity check

How to implement GV.SC-09 in sequence

This sequence moves from knowing what you acquire to proving it is authentic, current and changed only by approved hands, and ends with leadership seeing the results. Each step produces a record that the next step depends on, so an assessor can trace a component from procurement to production.

Inventory acquired components and their suppliers
The asset and procurement owners list every hardware product, software package, container image, firmware image and managed service the organization acquires, with the supplier and the system it supports. This list draws on the asset inventory maintained under the ID.AM Category and the supplier register under GV.SC-04. The step is done when every production system can be traced to its acquired components and each component has a named supplier.
Define provenance requirements for acquisitions
The supply chain risk owner, working with security and engineering, writes the provenance records each acquired product or service must supply, such as origin, build source, signing identity, version and delivery chain. These requirements are written into procurement checklists and, for critical suppliers, the contract terms set under GV.SC-05. The step is done when an approved requirements document exists and procurement can refuse an intake that does not meet it.
Generate and store SBOMs for in-house and acquired software
Engineering teams produce a CycloneDX software bill of materials for each build, and the procurement team requests one from suppliers where contracts allow. Tools such as Trivy can identify OS packages and software dependencies in a target and produce them as an SBOM, and can also scan SBOMs that suppliers provide. The step is done when each release has a stored, versioned SBOM linked to the system it deploys.
Track component vulnerabilities and modifications
Security engineers load SBOMs into a component analysis platform such as OWASP Dependency-Track, which consumes and produces CycloneDX SBOMs and VEX, identifies known-vulnerable and modified components, and tracks license risk using SPDX identifiers. Findings are triaged with the system owner and linked to remediation tickets. The step is done when every production component is monitored and each finding has a documented disposition.
Allowlist authenticated patch and update sources
Platform owners list the vendors, repositories and signing identities from which patches, updates and images may be accepted, and configure systems to reject anything else. The list is approved by the security owner and reviewed when suppliers change. The step is done when the approved source list is documented, enforced in the update pipeline, and any update from an unlisted source is blocked and logged.
Approve supplier personnel for maintenance access
The system owner and the supplier manager agree which supplier staff may perform maintenance, remote support or administrative work, and under what conditions. Approved personnel receive named, time-limited access that is tied to the access management process in PR.AA. The step is done when each supplier maintenance account maps to an approved individual and session records are retained for review.
Verify critical hardware upgrades before deployment
Before a critical hardware component is installed or replaced, the operations team checks it against the provenance record and compares its identifiers and firmware with the supplier's documentation. Items that do not match are quarantined and escalated. The step is done when each critical upgrade has a signed verification record that the change board can review.
Report provenance status to leadership
The supply chain risk owner gives leaders a regular summary showing which components lack provenance records, open high-severity supplier findings, blocked update attempts and unverified hardware changes. Figures come from the SBOM, monitoring and verification records. The step is done when the report is delivered on the agreed cycle and leaders record decisions on the open items.

Evidence that proves supply chain life cycle monitoring

An assessor testing GV.SC-09 looks for records that show where components came from, whether they are authentic, and whether changes were checked. The six artifacts below connect those questions to records the organization can produce on request, and each one needs a named owner and a refresh routine between audits.

Provenance records for acquired items

Provenance records show where each acquired product, component or service came from, who supplied it, and the chain of custody to the organization. For GV.SC-09, keep a register per critical item that records the supplier, the delivery date, the verification method used on receipt and the approver. Review the register when a supplier changes ownership, when a product line is replaced, and at the scheduled supplier review. Ask your evidence owner to confirm each entry still matches the asset inventory.

SBOMs in CycloneDX form

A software bill of materials lists the components inside a product or application. Require CycloneDX output from build pipelines and from suppliers, then store each version with the release it describes. Regenerate the SBOM for every release, because an SBOM from an earlier build no longer describes what is running. OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX, which helps keep them linked to findings.

Component risk and license reports

Dependency-Track identifies components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by component using SPDX license IDs. Export these reports on a set cadence and record how each finding was triaged, accepted or fixed. Assessors look for evidence that modified components were reviewed, not just that the scanner ran. Confirm the report covers both direct and transitive dependencies in your environment.

Patch source records

GV.SC-09 expects patches to come only from authenticated providers. Keep a record for each patch that names the source URL or repository, the publisher, the checksum or signature verified, and the person who approved the install. Trivy can scan target systems for OS packages and software dependencies, which helps show what was actually installed compared with what the record says. Investigate any patch that arrived through an unrecorded channel.

Approved maintenance personnel lists

Where supplier staff perform maintenance on systems, the organization should hold a current list of approved individuals, their employer, the systems they may touch and the dates of their access. Compare the list against access logs and against the offboarding records for departing supplier staff. Ask suppliers to confirm additions and removals in writing each review cycle, and record any maintenance performed by someone not on the list.

Hardware change verification records

For critical hardware upgrades, keep a record that shows the component was checked for unauthorized changes before installation and that the check was repeated on arrival or on return from service. Store the checksum, serial number, inspection result and the reviewer's name for each device. Re-examine the record when a device is returned from a third-party repair. Confirm the checks you perform are documented in procedures that a reviewer can follow without the original engineer.

What meeting GV.SC-09 costs in money and effort

This table lists the main cost components of meeting GV.SC-09, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request, and note that the organization owns the outcome while implementation partners and independent assessors each carry a separate cost line.

Cost component	Who is paid	One-time or recurring	What drives the cost
Tooling or licenses	Software vendor or open-source project maintainers	Recurring if commercial; none for open-source licenses	Number of products and services in scope. Self-hosted open-source tools such as Dependency-Track (Apache-2.0) and Trivy (Apache-2.0) remove license fees, though hosting and staff time remain.
Engineering time for SBOM and provenance pipelines	Internal platform or DevSecOps staff, or an implementation partner under a written scope	Mostly one-time to build, then recurring to maintain	Number of build pipelines, languages, and whether SBOMs are generated at build time or after deployment. Ask a partner to quote a fixed scope.
Trusted update source and hardware upgrade checks	Internal infrastructure and procurement teams	One-time to define the process, recurring for each critical upgrade	Count of critical hardware assets and how often they change. Documented verification steps reduce repeat effort.
Evidence upkeep	Internal compliance or security staff	Recurring	Release frequency, supplier count, and how many records must show provenance and authenticity. Automated SBOM and VEX reporting lowers manual collection.
External testing or review	Independent security testing firm or assessor	Recurring, usually per cycle	Scope of supply chain testing, system complexity, and how many components are reviewed. Confirm the scope and deliverables in writing.
Auditor sampling	Independent auditor or certification body, if an external assessment is required	Recurring per assessment cycle	Sample size chosen by the auditor, number of suppliers and products in scope, and quality of records on hand. Clean, dated provenance records reduce sampling time.

Who does what for supply chain life cycle controls

Your organization owns the outcome that GV.SC-09 describes: supply chain security practices are part of your cybersecurity and enterprise risk programs, and their performance is monitored across the life cycle of the products and services you use. That ownership cannot be handed to a partner or an auditor. Your security, procurement and platform leaders decide which suppliers and components fall under the control, set the rules for accepting provenance records, and approve the patch and update policy that determines where software may come from.

Supplier requirements: Write the provenance, authenticity and update-source expectations into supplier contracts and onboarding criteria so suppliers know what evidence to provide.
Patch and update policy: Decide which authenticated sources are approved for patches and firmware, and who may approve an exception.
Maintenance personnel rules: Define which supplier staff may perform maintenance on your systems and how their access is granted and removed.
Reporting to leaders: Decide what leadership sees about component authenticity and tampering, how often, and who acts on exceptions.
Ongoing monitoring: Assign an accountable owner to review SBOM findings, provenance gaps and hardware change checks.

Before you engage anyone, confirm that you can name the owner of each of these decisions and that the policy is approved at the level your Govern documentation requires.

Where organizations fall short on GV.SC-09

GV.SC-09 asks whether supply chain security practices are monitored across the full life cycle of the products and services an organization uses. The gaps below tend to appear at the same points: when software is first inventoried, when patches arrive, when vendor staff touch systems and when hardware changes. Each card names one gap and the action that closes it.

SBOMs generated once and never refreshed

A software bill of materials captured at purchase or at the first deployment describes components that have since been patched, replaced or added. Teams then assess vulnerabilities and license risk against a stale list. Check whether SBOMs are regenerated on every build or release, whether they are ingested into a tracking tool such as Dependency-Track, and whether the tool reports components with known vulnerabilities against the current inventory.

Patches taken from unverified sources

Updates downloaded from mirrors, forums or unmanaged repositories give an attacker a path into an otherwise sound product. GV.SC-09 Implementation Examples call for acquiring patches only from authenticated providers. Check whether each patch source is documented, whether signatures or checksums are verified before installation, and whether the approved source list is enforced by the update tooling rather than left to individual administrators.

Maintenance personnel not on an approved list

Vendor engineers, contractors and remote support staff often access systems with credentials that no one has recorded against a supplier. When an incident occurs, the organization cannot say who had access or whether that access was authorized. Check that every maintenance identity is tied to an approved supplier person, that access is time-limited, and that sessions are logged and reviewed.

Critical hardware upgrades not checked

Firmware updates, replacement network devices and added storage modules can carry unauthorized changes that a routine functional test will not reveal. GV.SC-09 Implementation Examples call for checking critical hardware upgrades for unauthorized changes. Check whether upgrades to critical equipment are verified against vendor-published hashes or signatures before installation, and whether the verification result is recorded with the change ticket.

Provenance records missing for acquired products

Without a record of where a product or service came from, who built it and how it moved through distribution, the organization cannot prove authenticity later. Procurement often captures price and delivery terms but not provenance. Check that acquisition records hold the supplier, origin, build or shipment identifiers and verification method for each critical item, and that these records are retrievable during an audit.

No leadership reporting on authenticity

When leaders receive no regular view of whether components are authentic and untampered, supply chain risk stays with technical teams and is not weighed against business decisions. GV.SC-09 expects performance to be monitored and reported. Check that a recurring report covers verification failures, unverified sources, open component vulnerabilities and overdue hardware checks, and that the report reaches the people who can accept or fund the risk.

Questions buyers ask about GV.SC-09

How much does it cost to meet GV.SC-09?

No supplied figure exists for this, so the cost depends on your scope, not on a fixed price. GV.SC-09 is an outcome you prove across the life cycle of products and services, so the main cost drivers are the number of acquired products and services in scope, how many of them are critical hardware or software you patch, and how much provenance evidence your suppliers already produce. Costs fall into two groups: one-time work to define the provenance and update-source rules and set up tooling, and recurring work to collect and review evidence. A written quote should separate these two groups, list which systems and suppliers are covered, and state which parts DeployOpen would deliver versus which your own staff would keep. DeployOpen does not publish prices; a quote follows from the written scope.

How long does it take to put GV.SC-09 in place?

The timeline depends on how much provenance and update-source evidence already exists. No researched duration is available for this subcategory, so confirm the schedule in the written scope rather than relying on a general estimate. Timing usually depends on how fast you can inventory the components that matter, agree with suppliers on what records they will provide, and get leaders to accept the reporting on authentic and untampered components. Organizations with a current software bill of materials and documented patch sources typically have less to set up than those that buy hardware or software without records. Ask for the milestones, the dependencies on supplier cooperation, and the point at which evidence is first reviewed.

What does the organization have to provide for GV.SC-09?

The organization must own the decisions and the supplier relationships, because GV.SC-09 depends on what suppliers contractually provide. You need a named owner for supply chain security, an agreed list of acquired products and services, access to supplier provenance records, and a source list of authenticated patch providers. Your procurement and legal teams must be able to require provenance records and maintenance by approved supplier personnel in contracts, and your operations team must be able to run the checks on critical hardware upgrades. DeployOpen can prepare systems, documents and evidence, but it cannot make your suppliers produce records they have not agreed to supply. Confirm these inputs before the scope is signed.

Can we meet GV.SC-09 in-house without an outside partner?

Yes, an organization can meet GV.SC-09 with its own staff, and nothing in NIST's framework requires an outside partner. The work is still specialized in three places: software bill of materials and vulnerability tooling, supplier contract language, and hardware upgrade verification. Teams that already run a software inventory and patch management process usually have the closest starting point. An outside implementation partner is most useful when the team lacks capacity to deploy and maintain the tooling, or when it needs help documenting evidence in a form an assessor can test. Whichever route you take, the organization still owns the controls and their results.

What does an assessor look for in GV.SC-09 evidence?

An assessor looks for proof that the practices described in GV.SC-09 happen across the life cycle, not just a policy that states them. Typical evidence includes provenance records for acquired products and services, reports to leaders on whether components are authentic and untampered, a list of authenticated patch sources, records showing maintenance was done by approved supplier personnel, and logs of checks on critical hardware upgrades. The assessor will sample these records, compare them with your inventory and test whether they match what was actually deployed. Keep records dated and tied to specific systems so they can be traced.

How does a NIST CSF assessment differ from certification for GV.SC-09?

A NIST CSF assessment measures your practices against the framework, while certification would be issued by an independent body that tests conformity to a published standard. NIST states that it does not offer certifications or endorsements of CSF-related implementations or services and has no plans for a conformity assessment program. Any claim that you are certified to GV.SC-09 is therefore not a NIST claim. Your own assessment, or an independent assessor you engage, can report how your practices align to the subcategory, but only an independent auditor or certification body issues formal reports or certificates for other frameworks. DeployOpen prepares systems and evidence and does not issue assessments or certifications.

How the scope of a GV.SC-09 engagement is agreed

A GV.SC-09 engagement starts with a written scope that names the products, services and life cycle stages in play, such as which software products, appliances or managed services need provenance records, which build pipelines produce the artifacts, and which hardware upgrades are considered critical. Most engagements are fixed-scope, so the deliverables, timelines and responsibilities are agreed in writing before any work begins. Ask for a scope document that lists each deliverable, the systems it touches, the acceptance criteria and the parties who sign off. A quote follows from that document, so an unclear scope usually produces an unclear quote.

The client supplies most of the raw material. Before scoping, collect a current supplier list with criticality ratings, the inventory of in-scope applications and their owners, the build pipeline definitions and repository access, the existing update and patch sources, and the approved list of supplier personnel who perform maintenance. Confirm who holds administrative access to the build systems and artifact registries, and whether any network is air-gapped, since that changes how SBOM generation and vulnerability feeds can be delivered. Gaps in these inputs are the most common reason an engagement slips, so the scope should state who is responsible for each one and by when.

Be precise about the boundary of the work. DeployOpen can plan, implement, integrate and document the provenance, SBOM and update-verification controls inside your environment, and prepare the evidence that an independent assessor would later review. It does not issue audit reports, attestations or certifications, and the organization remains the owner of its GV.SC-09 controls. Ask the scope to say which assessor will review the evidence, who holds the evidence repository, and what happens to the work if the assessment finds gaps. Any open question about whether a specific assessor or framework requirement applies should be confirmed with that assessor before the scope is signed.

How DeployOpen prepares GV.SC-09 evidence

DeployOpen works on GV.SC-09 by setting up the provenance records, component checks and update controls that show your self-hosted platforms stay authentic and untampered across their life cycle. We prepare systems and evidence inside your own infrastructure, while your organization owns the control and an independent auditor or certification body issues any report.

How we scope

Engagements are fixed-scope, with the platforms, life cycle stages and suppliers in scope agreed in writing before work starts.
The written scope names which acquired products and services need provenance records and which hardware upgrades need integrity checks.
We confirm which update sources are approved and which supplier personnel may perform maintenance on each platform.
Scope also states which evidence your assessor will expect and who in your organization owns each record.

How we build

We set up SBOM generation for each platform build, using tools such as Trivy to inventory OS packages and software dependencies.
We deploy Dependency-Track to ingest CycloneDX SBOMs and VEX, flag modified or outdated components and track license risk by SPDX ID.
We configure update pipelines so patches come only from authenticated providers, with signature checks recorded in logs.
We document hardware upgrade checks for critical components so unauthorized changes are detected and escalated.

How we hand over

We deliver runbooks for generating, storing and reviewing SBOMs, provenance records and update verification logs.
We map collected evidence to GV.SC-09 and its informative references so your assessor can trace each claim to a record.
We train your named owners on running the tooling, reviewing alerts and reporting authenticity status to leadership.
Handover includes a configuration inventory and a list of open items your organization must confirm with its suppliers.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover SBOM refreshes when platforms are upgraded and review of new vendor advisories affecting tracked components.
Before any assessment, we can help prepare the evidence pack, but the assessor reviews and decides what it accepts.
Ask any provider to confirm in writing which parts of the evidence they prepare and which parts your auditor must verify.