Component Provenance

Control Statement

Software and hardware components deployed into the estate shall resolve to a verified origin, and the organization shall maintain a current inventory of what those components contain.

Purpose. To know where deployed components came from and what is inside them, so that a compromise disclosed anywhere can be located here.

Discussion

Provenance and contents are two different questions and both are required. Provenance answers where a component came from; the inventory answers what it carries. A correctly signed package containing a vulnerable transitive dependency has verified provenance and unknown content, and an agency holding only the first cannot answer the question that actually arrives — *are we running this?* — when a component compromise is disclosed. The practical measure of this control is time to answer that question across the whole estate, which is why that is its outcome metric rather than inventory completeness.

Goals and Metrics

A metric that cannot come out badly is not a metric. Each of these is capable of reporting that the control is not working.

Accountability

Exactly one role is accountable, and every other role carries at least Informed — no control in the published catalog leaves a role with zero relationship to it. That is a stated property of how these were authored, not a coincidence, and not a claim that every role's work is worth equal attention here.

Inputs and Outputs

Activities

1. L2Record the origin of each deployed software and hardware component.
2. L2Verify signatures or equivalent origin evidence before deployment.
3. L2Maintain an inventory of what each deployed component contains.
4. L3Extend the inventory to transitive dependencies rather than to direct components alone, since disclosure typically names a dependency.
5. L3Raise a finding for artifacts whose origin cannot be verified, and define whether deployment may proceed and under whose authority.
6. L3Keep the inventory current at deployment rather than reconstructing it on demand, since reconstruction under disclosure pressure is slow and incomplete.
7. L3Extend provenance to firmware and hardware components, where verification is hardest and substitution is least visible.
8. L4Measure time to answer "are we running this component, and where" across the estate, and treat that interval as the control's real capability.
9. L4Measure inventory coverage against the deployed estate, distinguishing components inventoried from components merely recorded.
10. L5Automate inventory generation into the deployment pipeline, so currency is a property of deploying rather than a periodic exercise.

Measurement

Evidence and Assessment

Related Guidance

Position in the Chain

Derived from the other controls’ own declarations, so the two directions cannot disagree.

Where This Control Is Used

Derived, in every case, from the declaration at the other end: the forms whose techniques name this control, the artifacts whose producing and consuming controls include it, the layers whose control lists name it, and the roles its own accountability chart puts to work. Nothing here is authored on this page, so the sheet cannot claim an edge the other end does not.