Annex 5.1.1
Mapped SPARTA techniques (42)
Techniques referencing this article
Anomaly-detection model training data is supplied through data brokers, telemetry-archive providers and ML-as-a-service vendors; the supply-chain policy governs how these data suppliers are vetted, contracted and monitored.
External SDA providers (commercial and government) are direct suppliers under the supply-chain policy; the policy governs how the entity vets, contracts with and monitors the data flows from those tracking centers.
Coordinated compromise of multiple software modules during the supply chain process is the canonical multi-supplier collusion threat the supply-chain policy is established to govern.
Hardware/firmware corruption rides through the supplier relationship that produces the affected component; the supply-chain policy is the procedural mechanism that scopes the verification regime applied at delivery.
Design flaws and errata enter through the supplier of the affected silicon, board or programmable logic; the supply-chain policy frames the security expectations on supplier-disclosed errata and supplier-conducted design review.
COTS/FOSS suppliers (foundations, vendors) are direct suppliers under the supply-chain policy; their disclosure and security-quality posture shape the known-vulnerability surface the entity inherits.
AI/ML training data is supplied through data brokers, annotation services and pretrained-model vendors; the supply-chain policy is the procedural mechanism that constrains how those data suppliers are vetted and monitored.
SDR vendors and waveform suppliers are direct suppliers under the supply-chain policy; the policy frames the integrity expectations on vendor-supplied DSP chains and configuration profiles that, if subverted, deliver covert downlinks.
Contractor and integrator development environments are direct suppliers under the supply-chain policy; the policy frames the security expectations imposed on those environments where pre-launch exfiltration occurs.
Commercial ground stations, relay networks, operations service providers and data-processing partners are direct suppliers under the supply-chain policy; the policy governs the security expectations imposed on these partner environments where multi-mission exfiltration originates.
Payload vendors, gateway operators and customer-network providers are direct suppliers under the supply-chain policy; the policy frames the integrity expectations imposed on the payload-communications channel and its endpoints.
Compromise Supply Chain is exactly the threat the supply-chain security policy is established to govern; the policy defines who the entity contracts with, the security obligations imposed on those suppliers, and the verification and audit regime applied to each tier of the parts and software pipeline.
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.
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.
ASIC/FPGA Trojans, modified bootloaders and pre-delivery board manipulation are the canonical hardware-supply-chain threats the supply-chain security policy is established to govern.
SDR vendors and waveform suppliers are direct suppliers governed by the supply-chain policy; that policy frames the integrity expectations on vendor-supplied bitstreams, flowgraphs and configuration profiles.
Constellation partners and shared-routing collaborators are suppliers under the supply-chain policy when they exchange routes, time discipline or relay services with the entity's vehicle.
Alternate commercial ground stations held in reserve are direct suppliers under the supply-chain policy; the policy's verification and contractual obligations apply to them irrespective of their reserve status.
Operators of vehicles that conduct close-proximity operations near the entity's spacecraft are functional suppliers when their proximity is contractually arranged (rideshare, OSAM, cooperative sensing); the supply-chain policy governs how the entity vets such counterparties.
OSAM servicers, cargo vehicles and visiting vehicles are functional suppliers of services delivered through a docking/berthing interface; the supply-chain policy governs how the entity contracts for and verifies the security posture of these counterparties.
The hosted-payload provider is a direct supplier under the supply-chain policy; the policy frames the integration security expectations imposed on payload code, file services and telemetry paths.
Trusted relationships, with partners, vendors and user communities, are exactly the relationships the supply-chain policy is established to govern; the policy specifies how the entity contracts with and monitors third parties whose connections it trusts.
Mission collaborators (universities, science operations centers, international partners) are direct suppliers under the supply-chain policy; the policy governs the security expectations and shared-credential discipline imposed on those collaborators.
Vendors with persistent administrative routes into mission systems (ground software, modems, identity providers) are the canonical direct-supplier population the supply-chain policy governs.
User-segment equipment suppliers, downstream processing partners and customer-gateway providers are direct suppliers under the supply-chain policy; the policy frames the security expectations imposed on the user-facing edge of the mission's distribution network.
Auxiliary-device suppliers (EGSE vendors, calibration tooling, external storage providers) are direct suppliers under the supply-chain policy, which governs the trust expectations imposed on the devices that ingest into spacecraft and support equipment.
AIT facilities, integrators and pad-side service providers are direct suppliers under the supply-chain policy; that policy governs the security regime imposed at AIT and during launch operations.
Where the entity's payload is hosted on a third-party spacecraft, the host operator is a direct supplier under the supply-chain policy; the policy governs the integration-security expectations imposed on the host bus.
Visiting-vehicle operators (cargo, OSAM, crewed) are functional suppliers when their vehicles dock or berth; the supply-chain policy governs the security expectations imposed on these counterparties.
Launch-vehicle providers, integrators and EGSE network operators are direct suppliers under the supply-chain policy; the policy frames the security expectations imposed on the integration-period interface.
Rideshare cohabitants and deployer operators are direct suppliers under the supply-chain policy; the policy governs the security expectations imposed on shared infrastructure across rideshare manifest entries.
Hardware backdoors enter through suppliers (test/scan-chain enablement, undocumented bootstrap modes, microarchitectural quirks); the supply-chain policy is the procedural mechanism that scopes the verification regime applied at delivery.
Software supply chains are the principal vehicle for backdoor introduction; the supply-chain policy frames the security expectations on supplier secure-development practices that bound this risk.
When the entity itself rents commercial ground-station services, the supply-chain security policy is the procedural framework that constrains how the entity vets, contracts with and audits its GSaaS provider, the same provider an adversary can rent into.
Third-party ground systems are direct suppliers under the supply-chain security policy; the policy is the procedural mechanism that constrains the security posture the entity accepts from its GSaaS or relay provider.
Compromise of a third-party operator's spacecraft acting as proxy or relay engages the entity's supply-chain policy when the entity uses that operator's services or shares a bus/payload; the policy bounds what the entity accepts from the host operator.
Firmware reconnaissance leans heavily on vendor reference packages and leaked manufacturing files; the supply-chain security policy is the procedural mechanism that constrains how those artefacts move between integrators and the entity.
Supply-chain reconnaissance maps the same end-to-end pathway the implementing regulation requires the entity to govern with a formal supply-chain security policy; that policy's confidentiality discipline is what prevents the adversary's pathway map from being assembled.
Hardware-supply-chain reconnaissance focuses on components, screening, test history and configuration state; the supply-chain security policy is the procedural mechanism that scopes what the entity exposes about its parts pipeline.
Software supply chains traverse the entity's supplier network; the supply-chain security policy governs the disclosure surface (vendor lists, dependency manifests, repository URLs) that recon harvests.
Supply-chain security policy is the procedural lever for tracking supplier-disclosed vulnerabilities and pushing them through to remediation; weak supplier-side disclosure inflates the known-vulnerability recon surface.
Mapping primes, subs, integrators and operations partners is exactly the supply-chain topology the implementing regulation requires the entity to govern with a formal policy; that policy bounds how relationship metadata is exposed and protected.