safemode.space
← All techniques
IA-0001.02
ST0003Initial Access
sub-technique

Software Supply Chain

Parent: IA-0001

Description

Here the manipulation targets software delivered to flight or ground systems: altering source before build, swapping signed binaries at distribution edges, subverting update metadata, or using stolen signing keys to issue malicious patches. Space-specific vectors include mission control applications, schedulers, gateway services, flight tables and configuration packages, and firmware loads during I&T or LEOP. Adversaries craft payloads that pass superficial validation, trigger under particular operating modes, or reintroduce known weaknesses through version rollback. “Data payloads” such as malformed tables, ephemerides, or calibration products can double as exploits when parsers are permissive. The objective is to ride the normal promotion pipeline so the implant arrives pre-trusted and executes as part of routine operations.

Mappings

EU regulation articles

  • craAnnex I, Part II, (1)
    addresses
    high
    direct

    Software-supply-chain compromise (primary mappings: Part II, (7) + Art. 13(5) + Art. 13(8)) makes (1)'s SBOM obligation foundational — the manufacturer cannot exercise due diligence on third-party software without a documented component inventory.

  • craAnnex I, Part II, (5)
    addresses
    moderate
    direct

    Software supply-chain compromise (primary mappings: Part II, (7) + Art. 13(5) + Art. 13(8)) makes CVD policy under (5) the procedural intake for vulnerabilities that emerge in distributed-update channels.

  • craAnnex I, Part II, (7)
    addresses
    high
    derived

    Manufacturer obligation to provide secure update-distribution mechanisms is the direct defense against altered/swapped binaries: signed, integrity-verified update channels resist signed-binary swap and update-metadata subversion.

  • craAnnex I, Part II, (8)
    addresses
    high
    direct

    Software supply-chain compromise (primary mapping: Part II, (7)) cascades to (8) — secure update distribution is paired with the timely-dissemination obligation.

  • craArt. 13(5)
    addresses
    high
    derived

    Software-supplier due-diligence is the upstream control on the build vendors, package signers and OTA distributors that software-supply-chain attacks ride through.

  • craArt. 13(8)
    addresses
    moderate
    derived

    Manufacturer obligation to provide security updates throughout the support period ensures the integrity-verified update path remains operational across the product lifetime, not just at initial release.

  • eu-space-actArt. 85(2)
    addresses
    moderate
    direct

    Use of stolen signing keys to issue malicious patches directly attacks the cryptographic-key lifecycle 85(2) places on the operator — secure generation, storage, and distribution disciplines limit signing-key exposure.

  • eu-space-actArt. 92(1)
    addresses
    high
    direct

    Software supply-chain manipulation (altering source, swapping signed binaries, subverting update metadata) is squarely within 92(1)'s contractual supply-chain security scope.

  • nis2Art. 21(2)(d)
    addresses
    high
    direct

    Software-distribution suppliers (mirrors, CDNs, signing services) are direct service providers; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around the promotion pipeline this technique abuses.

  • nis2Art. 21(2)(e)
    addresses
    high
    direct

    Subverting update metadata, swapping signed binaries at distribution edges, and version-rollback attacks on flight tables are precisely the integrity failures Art. 21(2)(e)'s secure development/maintenance and vulnerability-handling/disclosure obligations are meant to catch.

  • nis2Art. 21(2)(h)
    addresses
    moderate
    direct

    Stolen signing keys are the named attack path; cryptography policy under Art. 21(2)(h) is the obligation that governs key-pair generation, HSM custody, attestation, and rotation — directly limiting the blast radius of any single key compromise.

  • nis2Art. 21(3)
    addresses
    moderate
    direct

    Maturity of the signing service, version-rollback policy, and update-metadata integrity vary by supplier; Art. 21(3) requires the entity to consider those supplier-specific vulnerabilities when sizing software-supply-chain risk.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    Software delivered to flight or ground systems traverses the supplier network the supply-chain security policy governs; that policy is the procedural envelope around vendor identity, provenance and integrity.

  • nis2-implAnnex 5.1.6
    addresses
    high
    derived

    Software suppliers (build vendors, package signers, OTA distributors) require Annex 5.1.6 ongoing monitoring; the entity's supplier-quality posture depends on continuous oversight rather than only initial selection.

  • nis2-implAnnex 5.1.7
    addresses
    high
    derived

    Annex 5.1.7 reporting and follow-up obligations operationalize the response to software-supplier monitoring signals.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    Source manipulation before build, swapped signed binaries at distribution edges and subverted update metadata all fall inside the secure-development life cycle the entity must govern with explicit rules.

  • nis2-implAnnex 6.6.1
    addresses
    moderate
    derived

    Security-patch management procedures are the lever that ensures swapped or maliciously-signed update packages are detected and remediated through coherent change-management discipline rather than installed silently.

ENISA controls

  • ENISA-STL-2025-03-sD.21-i08
    addresses
    moderate

    Documented change management with configuration change control is the procedural barrier to silent malicious patch promotion.

  • ENISA-STL-2025-03-sD.23-i11
    addresses
    moderate

    Cryptography and key management for code-signing keys denies the stolen-signing-key vector, but IA-0001.02's dominant scope is supply-chain manipulation across the pipeline: altering source before build, version rollback to re-introduce known weaknesses, and update-metadata subversion, all of which yield artifacts that are then legitimately signed. Crypto covers one non-dominant vector, so the relationship is addresses.

  • ENISA-STL-2025-03-sD.25-i06
    addresses
    high

    A regularly performed, regression-tested update process governs the legitimate update path IA-0001.02 abuses, but regression testing validates function rather than detecting malicious patches, so this is domain relevance rather than active mitigation.

  • ENISA-STL-2025-03-sD.28-i04
    addresses
    high

    Software supply-chain integrity directly defeats binary swapping, update-metadata subversion, and stolen signing-key abuse on delivered patches.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, IA-0001.02 (SPARTA v3.2).

Built 2026-07-25 from 216 techniques, 334 regulation articles, 125 ENISA controls, 2,610 framework controls, and 90 countermeasures.