Mission Malware Protection Function

Boot memory compromise is established through an image the practice validates before launch, but the practice does not speak to boot-chain verification at each start, which is what the technique's persistence depends on.

Introducing executable logic that runs on the vehicle is interdicted at the update gate the practice mandates. Moderate rather than high because the technique also covers data payloads an interpreter treats as code, which update validation does not necessarily inspect.

A rootkit delivered in a software load is caught by pre-deployment validation; the recurring in-operations check the practice requires is what catches one introduced later.

A bootkit is a boot-path image, and the practice's validation obligation covers images prior to deployment and launch, which is when a bootkit must be introduced to be effective.

Compromised dependencies and development tools produce artifacts the practice validates, but the compromise sits upstream of the validation gate and may not present as malware in the delivered image.

A software supply chain compromise reaches the mission as a build artifact, and validating that artifact before deployment is the interdiction. Moderate because the practice validates for malware rather than for the full range of supply-chain subversion, such as source tampering that produces no recognisable malicious code. [Curation] Direct analogy with the worked example codified in CLAUDE.md, where IA-0001.02 was downgraded to addresses because a control covering one supply-chain vector leaves the dominant scope uncovered. Validating a delivered artifact as free from malware catches an artifact carrying recognisable malicious code; it does not catch source tampering before build, version rollback, or update-metadata subversion, which is where most of the technique lives.

The practice requires that mission software updates be validated as free from malware before deployment and at intervals during operations. Compromising an on-orbit update is the technique that validation exists to catch, at exactly the point the practice names. [Curation] Confidence reduced from high. Validating updates as free from malware catches an update that was malicious when authored, but IA-0007.01 also covers an update altered in transit after validation, which malware scanning does not detect. That half is carried by GR-INTG-01's integrity verification, so this practice interdicts the technique in part rather than in full. The mitigates stands; the certainty does not.

A software backdoor introduced in a load would be subject to validation, but a backdoor crafted as legitimate-looking code is what malware validation is weakest against, so this is addresses rather than mitigates.

Uploading an exploit or payload is the delivery step the update-validation gate is placed to intercept, though the technique describes adversary staging rather than a mission software update, so the gate may not be in the path.