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

Software Dependencies & Development Tools

Parent: IA-0001

Description

This technique targets what developers import and the tools that transform source into flight binaries. Methods include dependency confusion and typosquatting, poisoned container/base images, malicious IDE plugins, and compromised compilers, linkers, or build runners that subtly alter output. Because flight and ground stacks frequently reuse open-source RTOS components, crypto libraries, protocol parsers, and build scripts, an upstream change can deterministically reproduce a backdoor downstream. Attackers also seed private mirrors or caches so “trust-on-first-use” locks in tainted packages, or abuse CI secrets and environment variables to pivot further. Effects range from inserting covert handlers into command parsers, to weakening integrity checks in update paths, to embedding telemetry beacons that exfiltrate build metadata helpful for later stages.

Mappings

EU regulation articles

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

    Software dependencies and dev-tool components must be enumerated in the manufacturer's component identification and SBOM under Annex I, Part II, (1); poisoned dependencies are surfaced by the same SBOM discipline that documents legitimate ones.

  • craAnnex I, Part II, (2)
    addresses
    moderate
    derived

    Once a poisoned dependency is identified the manufacturer must address and remediate without delay under Annex I, Part II, (2), bounding the exploit window of dependency-confusion or typosquatting attacks.

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

    Software-dependency compromise (primary mappings: Part II, (1)+(2) + Art. 13(5)) creates an explicit need for a CVD channel to receive reports from open-source maintainers and downstream users.

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

    Software-dependency compromise (primary mapping: Part II, (2)) cascades to (8) — once a remediating update is available, dissemination without delay is the timing element.

  • craArt. 13(5)
    addresses
    high
    derived

    Manufacturer due-diligence obligations apply to package registries, container base-image suppliers and CI/CD service providers that deliver software dependencies into the product build pipeline.

  • eu-space-actArt. 88(1)
    addresses
    moderate
    direct

    88(1)'s testing programme obligation can include supply-chain integrity checks (e.g., verification of dependency provenance, signed-build validation) that detect dependency-confusion or build-poisoning attempts before deployment.

  • eu-space-actArt. 88(3)
    addresses
    moderate
    direct

    Software-dependency testing (primary: Art. 88(1)) cascades to 88(3) — TLPT can include dependency provenance testing across the 3-yearly cadence.

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

    Software-dependency and dev-tool compromise is supply-chain attack surface; 92(1)'s contractual information-security obligation on supplier and service-provider relationships covers these dev-pipeline touchpoints.

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

    Dependency confusion, typosquatting, poisoned base images, malicious IDE plugins, and compromised compilers all ride supplier and service-provider relationships (registries, container registries, IDE vendors); Art. 21(2)(d)'s supplier-relationship security obligation is what constrains the trust framework.

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

    Trust-on-first-use lock-ins on tainted packages, abuse of CI secrets, and compromised compilers are paradigmatic dev-pipeline failures Art. 21(2)(e)'s network-and-information-systems development-and-maintenance + vulnerability-handling obligation is meant to detect and remediate.

  • nis2Art. 21(3)
    addresses
    moderate
    direct

    Vulnerability profile of CI runners, registries, and IDE plugin ecosystems varies dramatically by supplier; Art. 21(3) requires the entity to take those supplier-specific vulnerabilities into account when relying on third-party tooling.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    Open-source maintainers, package registries and CI/CD service providers are direct suppliers under the supply-chain policy; the policy's selection and monitoring obligations apply to them as much as to silicon vendors.

  • nis2-implAnnex 5.1.6
    addresses
    high
    derived

    Software-dependency and dev-tool suppliers (registries, foundations, CI providers) are exactly the population where Annex 5.1.6 ongoing monitoring detects upstream compromise via reports of dependency confusion, signing-key incidents and registry tampering.

  • nis2-implAnnex 5.1.7
    addresses
    high
    derived

    Annex 5.1.7 follow-up procedures are the lever that converts monitoring signals on dependency or tooling suppliers into remediation actions (mirror updates, supplier replacement, contract amendment).

  • nis2-implAnnex 6.10.1
    addresses
    moderate
    derived

    Vulnerability-handling obligations require the entity to obtain information about vulnerabilities in dependencies and toolchains, which is the metric that bounds dwell time for poisoned-dependency compromises.

  • nis2-implAnnex 6.2.1
    addresses
    high
    direct

    Dependency confusion, typosquatting, poisoned base images and malicious build plug-ins all sit inside the build-and-tooling envelope the secure-development life cycle rules govern; those rules constrain how dependencies are pinned, mirrored, signed and verified.

  • nis2-implAnnex 6.3.1
    addresses
    high
    derived

    Configuration management of build infrastructure (compiler versions, container base images, plug-in inventories) is the procedural lever that detects and blocks malicious modification of the toolchain that turns source into flight binaries.

ENISA controls

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

    A documented secure development lifecycle establishes the engineering principles that govern dependency selection, build runners, and import controls.

  • ENISA-STL-2025-03-sD.28-i03
    mitigates
    high

    SBOM generation against the entire software supply chain detects compromised dependencies, registries, and base images by surfacing what is actually shipped.

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

    Supply-chain integrity controls (hash sums, supplier audits) defeat dependency confusion, typosquatting, and compromised CI/CD runners that IA-0001.01 exploits.

Cross-reference controls

SPARTA countermeasures

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

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