Software and Firmware Integrity Verification Function
Parent: GR
Description
• The mission should require developers of information systems, system components, or information system services to enable integrity verification of software and firmware components prior to delivery and during mission operations • Each system operated by the mission should provide the capability to verify the integrity of mission-defined software, firmware, and information • The mission should p
Mapped SPARTA techniques
4 techniques
The parent supply-chain technique spans source tampering, dependency substitution, update-metadata subversion, and hardware modification. Integrity verification of the delivered software and firmware covers the delivered-artifact face only.
The practice requires developers to enable integrity verification of software and firmware, which is the check that detects a build artifact altered anywhere between the developer and the mission. [Curation] Same reasoning as the MI-MALW-01 downgrade. Integrity verification detects alteration of an artifact after the developer signs it, but a supply chain subverted at source produces an artifact whose integrity verifies correctly. One vector covered, dominant scope not.
Hardware supply chain compromise may present as altered firmware, which the practice covers, or as a physical modification, which it does not. Partial scope coverage caps this at addresses.
An on-orbit update compromised in transit is caught by the integrity verification the practice requires developers to enable, which is the same interdiction MI-MALW-01 provides at the malware-validation gate by a different mechanism.
Cite as SafeMode Space, nasa-bpg GR-INTG-01.