| name | SR-4(4)_supply-chain-integrity-pedigree |
| description | Employ [organization-defined] and conduct [organization-defined] to ensure the integrity of the system and system components by validating the interna |
| category | configuration |
| version | 5.2.0 |
| author | cyberstrike-official |
| tags | ["nist","sp800-53","rev5","sr-4-4","sr","enhancement"] |
| tech_stack | ["any"] |
| cwe_ids | [] |
| chains_with | ["RA-3"] |
| prerequisites | ["SR-4"] |
| severity_boost | {"RA-3":"Chain with RA-3 for comprehensive security coverage"} |
SR-4(4) Supply Chain Integrity — Pedigree
Enhancement of: SR-4
High-Level Description
Family: Supply Chain Risk Management (SR)
Framework: NIST SP 800-53 Rev 5
Authoritative information regarding the internal composition of system components and the provenance of technology, products, and services provides a strong basis for trust. The validation of the internal composition and provenance of technologies, products, and services is referred to as the pedigree. For microelectronics, this includes material composition of components. For software this includes the composition of open-source and proprietary code, including the version of the component at a given point in time. Pedigrees increase the assurance that the claims suppliers assert about the internal composition and provenance of the products, services, and technologies they provide are valid. The validation of the internal composition and provenance can be achieved by various evidentiary artifacts or records that manufacturers and suppliers produce during the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of technology, products, and services. Evidentiary artifacts include, but are not limited to, software identification (SWID) tags, software component inventory, the manufacturers’ declarations of platform attributes (e.g., serial numbers, hardware component inventory), and measurements (e.g., firmware hashes) that are tightly bound to the hardware itself.
What to Check
How to Test
Step 1: Review Documentation
Examine the System Security Plan (SSP) and related artifacts for SR-4(4) implementation details. Verify the organization has documented how this control is satisfied.
Step 2: Validate Implementation
# For cloud environments, use cloud-audit-mcp tools
# For on-premises, review system configurations directly
# Example: Check if account management policies exist
grep -r "account.management\|access.control" /etc/security/ 2>/dev/null
Step 3: Test Operating Effectiveness
Verify the control is actively functioning, not just documented. Check logs, configurations, and operational evidence.
Tools
