{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/software-supply-chain","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/software-supply-chain/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/software-supply-chain/"},"term":{"en":"Software supply chain","da":"Softwareforsyningskæde"},"aka":{"en":[],"da":[]},"domain":["platform","security"],"cluster":"delivery","layer":"delivery","status":"current","summary":{"en":"Everything and everyone that goes into making software you run, from outside code parts to the tools that build and ship it.","da":"Alt og alle, der indgår i at lave den software, man kører, fra eksterne kodedele til de værktøjer, der bygger og leverer den."},"body":{"formal":{"en":"The chain of people, code parts from others, build tools, pipelines and delivery routes through which software is written, put together and handed to its users; an attack on any link can reach everyone further down the chain.","da":"Kæden af personer, kodedele fra andre, byggeværktøjer, pipelines og leveringsveje, som software skrives, sættes sammen og overdrages til brugerne igennem; et angreb på ét led kan nå alle længere nede i kæden."},"plain":{"en":"Like a food chain from farm to table; if one supplier's flour is poisoned, every bakery that bought it, and every customer, is affected, however clean their own kitchen is.","da":"Som fødevarekæden fra mark til bord; hvis én leverandørs mel er forgiftet, rammes alle bagerier, der har købt det, og alle deres kunder, uanset hvor rent deres eget køkken er."},"inPractice":{"en":"Attackers break into the build system of a supplier whose case-handling software is used by many Danish municipalities and hide malware in a normal update, which the municipalities install because it comes from a trusted source.","da":"Angribere bryder ind i byggesystemet hos en leverandør, hvis sagsbehandlingssystem bruges af mange danske kommuner, og gemmer malware i en almindelig opdatering, som kommunerne installerer, fordi den kommer fra en betroet kilde."},"whyItMatters":{"en":"Most software is built largely from parts written by others, so one weak supplier can open doors into many organisations at once; NIS2 and the Cyber Resilience Act therefore require organisations and software makers to manage this risk.","da":"Det meste software består i høj grad af dele skrevet af andre, så én svag leverandør kan åbne døre ind til mange organisationer på én gang; derfor kræver NIS2 og Cyberrobusthedsforordningen, at organisationer og softwareproducenter styrer denne risiko."}},"deepDive":{"en":"The underlying problem was stated by Ken Thompson in his 1984 Turing Award lecture \"Reflections on Trusting Trust\": a compromised compiler can insert a backdoor into every program it builds, including new copies of itself, so inspecting source code alone cannot establish trust. Modern frameworks decompose the chain into source, build, dependency and distribution stages and ask, for each artefact, who produced it, from what inputs, on which platform, and whether anything changed in transit. SLSA models threats at each stage and defines a Build track (L1 provenance exists; L2 signed provenance from a hosted build platform; L3 hardened, isolated builds) and, from v1.2, a Source track. in-toto supplies the attestation format - signed statements binding an artefact digest to a predicate such as SLSA provenance, an SBOM or test results - and Sigstore provides keyless signing and a transparency log for those statements. The Update Framework (TUF) addresses the distribution link with role separation, threshold signatures and expiring metadata that resist key compromise, rollback and freeze attacks.\n\nAttack mechanisms map onto those links. Source: stolen maintainer credentials or malicious commits (ua-parser-js, 2021). Maintainer social engineering: the event-stream npm package (2018) was handed to a new maintainer who added a dependency targeting a cryptocurrency wallet; the xz Utils backdoor (CVE-2024-3094) was hidden in binary test files in the repository and activated by a build script that existed only in the release tarballs, so the malicious code was injected at build time into liblzma and reached sshd on distributions that linked it via libsystemd. Build: SolarWinds' SUNBURST (2020) was inserted by malware on the build server during compilation while the source repository stayed clean. Dependencies: typosquatting and dependency confusion abuse package-manager resolution rules. Distribution: compromised update servers or signing keys, as with the 2017 NotPetya spread through M.E.Doc updates.\n\nDefences are cumulative rather than alternative. Reproducible builds let independent parties rebuild and compare digests, detecting build-time tampering; hermetic, ephemeral build environments and short-lived credentials limit what a compromised job can do; two-person review and protected branches address source threats; pinned, hash-verified dependencies with SCA and SBOMs address the dependency layer; signing and provenance verification at deployment close distribution. OpenSSF Scorecard gives heuristic risk signals for open-source projects, although none of these signals would reliably have caught the xz attack.\n\nFor governance, NIST SP 800-161r1 (2022) covers cyber supply chain risk management for acquirers, and NIST SP 800-218 (SSDF) and SP 800-204D cover producers. In the EU, NIS2 Article 21(2)(d) requires in-scope entities to address supply-chain security, including the security practices of their direct suppliers, and the Cyber Resilience Act requires manufacturers of products with digital elements to exercise due diligence on third-party components, with reporting obligations applicable since 11 September 2026 and full application from 11 December 2027.","da":"Det grundlæggende problem blev formuleret af Ken Thompson i hans Turing Award-foredrag \"Reflections on Trusting Trust\" fra 1984: en kompromitteret compiler kan indsætte en bagdør i alle programmer, den bygger, også i nye kopier af sig selv, så gennemsyn af kildekoden alene kan ikke skabe tillid. Moderne rammeværker deler kæden op i kilde, bygning, afhængigheder og distribution og spørger for hvert artefakt, hvem der lavede det, ud fra hvilket input, på hvilken platform, og om noget blev ændret undervejs. SLSA modellerer trusler i hvert led og definerer et Build-spor (L1: provenance findes; L2: signeret provenance fra en hostet byggeplatform; L3: hærdede, isolerede builds) og fra v1.2 også et Source-spor. in-toto leverer attestationsformatet - signerede udsagn, der binder et artefakts digest til et prædikat som SLSA-provenance, en SBOM eller testresultater - og Sigstore leverer nøgleløs signering og en transparenslog til disse udsagn. The Update Framework (TUF) håndterer distributionsleddet med rolleadskillelse, tærskelsignaturer og metadata med udløbstid, der modstår nøglekompromittering samt rollback- og freeze-angreb.\n\nAngrebsmetoderne følger leddene. Kilde: stjålne legitimationsoplysninger hos vedligeholdere eller ondsindede commits (ua-parser-js, 2021). Social manipulation af vedligeholdere: npm-pakken event-stream (2018) blev overdraget til en ny vedligeholder, der tilføjede en afhængighed rettet mod en kryptovaluta-tegnebog; bagdøren i xz Utils (CVE-2024-3094) var gemt i binære testfiler i repositoryet og blev aktiveret af et byggescript, der kun fandtes i udgivelsens tarballs, så den ondsindede kode blev sprøjtet ind i liblzma under bygningen og nåede sshd på distributioner, der linkede den via libsystemd. Bygning: SolarWinds' SUNBURST (2020) blev indsat af malware på byggeserveren under kompileringen, mens kilde-repositoryet forblev rent. Afhængigheder: typosquatting og dependency confusion misbruger pakkehåndteringens opløsningsregler. Distribution: kompromitterede opdateringsservere eller signeringsnøgler, som da NotPetya i 2017 spredtes via opdateringer af M.E.Doc.\n\nForsvaret er kumulativt, ikke et enten-eller. Reproducerbare builds lader uafhængige parter genbygge og sammenligne digests og afslører manipulation under bygning; hermetiske, flygtige byggemiljøer og kortlivede legitimationsoplysninger begrænser, hvad et kompromitteret job kan gøre; gennemgang ved to personer og beskyttede grene håndterer trusler mod kilden; låste, hash-verificerede afhængigheder med SCA og SBOM'er håndterer afhængighedslaget; signering og verifikation af provenance ved udrulning lukker distributionsleddet. OpenSSF Scorecard giver heuristiske risikosignaler for open source-projekter, selvom ingen af disse signaler med sikkerhed ville have fanget xz-angrebet.\n\nTil styring dækker NIST SP 800-161r1 (2022) risikostyring i cyberforsyningskæden for indkøbere, mens NIST SP 800-218 (SSDF) og SP 800-204D dækker producenter. I EU kræver NIS2-direktivets artikel 21, stk. 2, litra d, at omfattede enheder håndterer sikkerheden i forsyningskæden, herunder de direkte leverandørers sikkerhedspraksis, og Cyberrobusthedsforordningen kræver, at producenter af produkter med digitale elementer udviser rettidig omhu over for tredjepartskomponenter; indberetningspligterne har gældt siden 11. september 2026, og forordningen finder fuldt anvendelse fra 11. december 2027."},"edges":[{"type":"used-with","to":"security/supplier-management","confidence":"high","strength":"normal"}],"depth":0,"sources":[{"title":"NIST SP 800-204D - Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines","url":"https://csrc.nist.gov/pubs/sp/800/204/d/final","tier":"standard","publisher":"NIST"},{"title":"SLSA - Supply-chain Levels for Software Artifacts","url":"https://slsa.dev/","tier":"reference","publisher":"OpenSSF"}],"draft":true}