Beveiliging softwaretoeleveringsketen voor defensie: SLSA, herkomst, ondertekening

Een uitgerold defensiebinair bestand is het einde van een lange vertrouwensketen. Het begon als broncode geschreven door een ontwikkelaar, passeerde tientallen opensourceafhankelijkheden, werd gecompileerd op een buildserver, verpakt, ondertekend en gepromoveerd naar een release-register voordat het ooit een operationeel netwerk bereikte. Elke schakel in die keten is een doelwit. Statelijke tegenstanders hebben herhaaldelijk aangetoond dat de goedkoopste weg in een verhard defensienetwerk niet de voordeur is – het is het buildsysteem of een vertrouwde afhankelijkheid, stroomopwaarts gecompromitteerd zodat de kwaadaardige code wordt geleverd, ondertekend en gezegend, door de eigen pijplijn van het slachtoffer. Beveiliging van de softwaretoeleveringsketen is de discipline om elke schakel in die keten verifieerbaar te maken, zodat een uitgerold artefact cryptografisch kan worden teruggeleid naar gereviewde broncode via een manipulatiebestendige build.

Het dreigingsmodel van de defensietoeleveringsketen

Commerciële toeleveringsketenbeveiliging en defensietoeleveringsketenbeveiliging delen dezelfde woordenschat maar een andere tegenstander. Een commercieel team maakt zich zorgen over een kwetsbare afhankelijkheid of een onbedoeld gelekt geheim. Een defensieteam moet uitgaan van een goed gefinancierde actor die maanden zal besteden aan het vooraf positioneren van een implant: het vergiftigen van een populair opensourcepakket, het compromitteren van een buildrunner of het vervangen van een gemanipuleerde compiler. De SolarWinds-inbraak – waarbij een buildsysteem-implant een achterdeur in een legitiem ondertekende productupdate invoegde – is het canonieke voorbeeld en hervormde de manier waarop defensieaankoop omgaat met de oorsprong van software.

Het dreigingsoppervlak valt uiteen in vier zones. De bronzone omvat het versiebeheersysteem en de mensen met commit-toegang. De afhankelijkhedenzone omvat elk extern pakket dat in de build wordt getrokken, direct en transitief. De buildzone omvat de buildservice, de runners en de toolchain. De distributiezone omvat ondertekening, het release-register en de uitrol. Een controlekader voor de defensietoeleveringsketen moet alle vier aanpakken – de ene verharden terwijl de andere open blijft, verschuift simpelweg het toegangspunt van de tegenstander.

Wat dit moeilijker maakt voor defensie dan voor commerciële software is het gevolgmodel. Een gecompromitteerde commerciële SaaS-update kan worden teruggedraaid; een gecompromitteerde firmware-load op een uitgerolde radio of een payload voor elektronische oorlogvoering kan onbereikbaar, persistent en operationeel catastrofaal zijn. De kosten van één gemanipuleerd artefact zijn asymmetrisch, en daarom moet het kader preventief zijn in plaats van reactief – het doel is een kwaadaardig artefact volledig onmogelijk te maken om de pijplijn te passeren, niet om het na uitrol te detecteren. De onderstaande controles zijn van bron tot uitrol geordend, juist zodat elke zone wordt gesloten voordat de volgende de uitvoer ervan erft.

SLSA: een volwassenheidsmodel voor build-integriteit

SLSA – Supply-chain Levels for Software Artifacts – is het meest breed toegepaste kader om te redeneren over build-integriteit. Het is bewust incrementeel en definieert opeenvolgende niveaus zodat een organisatie kan meten waar ze staat en wat de volgende concrete verbetering is.

Niveau 1 vereist alleen dat het buildproces herkomst produceert: een beschrijving van hoe het artefact is gemaakt. Dit alleen al onderschept fouten en biedt een basislijn voor analyse, maar de herkomst is nog niet beschermd tegen manipulatie.

Niveau 2 vereist een gehoste buildservice die herkomst genereert en ondertekent. Omdat een service in plaats van een ontwikkelaarswerkstation de attestatie produceert, wordt manipulatie door een gecompromitteerde individuele machine detecteerbaar.

Niveau 3 verhardt het buildplatform zelf: herkomst wordt onvervalsbaar en builds draaien in geïsoleerde, kortstondige omgevingen die geen toestand tussen runs meedragen. Dit is het niveau waarop een gecompromitteerde afhankelijkheid of een kwaadaardig buildscript niet langer stilletjes kan herschrijven wat de herkomst rapporteert. Voor missiesoftware moet SLSA-niveau 3 worden behandeld als de basislijn, niet als de ambitie.

De houding met de hoogste betrouwbaarheid – historisch beschreven als niveau 4 en nu uitgedrukt via aanvullende track-vereisten – voegt tweepersoonsreview van elke wijziging en hermetische, reproduceerbare builds toe. Een reproduceerbare build laat een onafhankelijke partij dezelfde broncode opnieuw bouwen en bevestigen, bit voor bit, dat ze hetzelfde artefact krijgen. Voor wapens-nabije of cryptografische componenten is reproduceerbaarheid de sterkste beschikbare verdediging tegen een gemanipuleerde toolchain.

Build-herkomst: hoe het artefact is gemaakt

Herkomst is het hart van toeleveringsketenzekerheid, en het wordt vaak verward met ondertekening. Een handtekening op een binair bestand bewijst wie het heeft vrijgegeven en dat het niet is gewijzigd sinds de handtekening werd aangebracht. Het zegt niets over de vraag of de build die het binaire bestand produceerde betrouwbaar was. Als een tegenstander de buildrunner compromitteert, kan deze een kwaadaardig artefact produceren dat vervolgens volkomen legitiem wordt ondertekend – de handtekening is geldig, het artefact is vergiftigd.

Herkomst dicht dat gat. Een herkomstattestatie is een ondertekend, machineleesbaar verslag dat de broncommit, de builderidentiteit, de buildparameters en de cryptografische digests van elke invoer en uitvoer beschrijft. Het veelgebruikte formaat is de in-toto-attestatie, die dit vastlegt als een gestructureerde verklaring die het buildplatform – niet de ontwikkelaar – ondertekent. Wanneer een verificateur het artefact later controleert, bevestigt deze niet alleen de handtekening maar ook dat de herkomst het verwachte bronrepository, de verwachte builder en een commit die de review heeft doorstaan benoemt.

Wat een verificateur controleert

Een herkomstcontrole op uitroltijd beantwoordt een precieze vraag: is dit exacte artefact gebouwd uit de bron en het proces dat we verwachten? De verificateur vergelijkt de artefact-digest met de digest die in de herkomst is vastgelegd, bevestigt dat de herkomst is ondertekend met de sleutel van het vertrouwde buildplatform, en stelt vast dat de builderidentiteit en de bron-URI overeenkomen met een toelatingslijst. Een mismatch – een artefact waarvan de herkomst een onbekende builder benoemt, of waarvan de digest niet overeenkomt – wordt geweigerd voordat het een operationele omgeving bereikt. Dit is de controle die een SolarWinds-achtige vervanging zou hebben gemarkeerd.

Herkomst maakt ook incidentrespons mogelijk die anders onmogelijk zou zijn. Wanneer een nieuwe kwetsbaarheid wordt onthuld in een buildtool of een afhankelijkheid, kan een organisatie met volledige herkomst precies opvragen welke uitgerolde artefacten zijn geproduceerd met het getroffen component, door welke builder en uit welke commit – wat een gejaagde schatting verandert in een precies antwoord over de straal van de schade. Herkomst die wordt bewaard voor de operationele levensduur van een artefact is daarom niet alleen een poort vóór uitrol, maar ook een auditmiddel dat jaren na de build zijn vruchten afwerpt.

Artefactondertekening in defensiepijplijnen

Ondertekening blijft essentieel; het is alleen op zichzelf niet voldoende. De moderne praktijk is sleutelloze ondertekening ondersteund door een transparantielog: een kortstondige sleutel wordt uitgegeven tegen een geverifieerde workload-identiteit, gebruikt om het artefact en de attestaties ervan te ondertekenen, en de ondertekeningsgebeurtenis wordt vastgelegd in een alleen-toevoegen openbaar of privaat transparantielog. Dit verwijdert de operationele last en het risico van langlevende ondertekeningssleutels die op buildservers staan.

Voor de componenten met de hoogste betrouwbaarheid – cryptografische modules, bootloaders, alles wat is verbonden met een hardware root of trust – gebruiken defensieprogramma's hardwaregebaseerde sleutels bewaard in een hardwarebeveiligingsmodule (HSM). De privésleutel verlaat nooit de HSM; ondertekeningsbewerkingen worden erbinnen uitgevoerd. Dit gaat van nature samen met secure boot, waarbij de firmware van het apparaat de handtekening van elke fase verifieert voordat deze wordt uitgevoerd, waardoor de vertrouwensketen van de toeleveringsketen helemaal tot aan het silicium wordt uitgebreid.

Afhankelijkheidsverificatie en de SBOM

Het merendeel van de code in elke moderne defensietoepassing wordt niet door het programma geschreven – het wordt erin getrokken als opensourceafhankelijkheden. Het verifiëren van die afhankelijkheden is daarom de controle met de hoogste hefboomwerking in de hele keten. Verschillende praktijken versterken elkaar hier.

Vastpinnen en hashen. Elke afhankelijkheid wordt vastgepind op een specifieke versie en een cryptografische hash, zodat de opgeloste afhankelijkheidsboom deterministisch is. Een build kan niet stilletjes afdrijven naar een nieuwe, kwaadaardige versie van een pakket omdat de hash dan niet langer overeenkomt.

Interne mirroring. Goedgekeurde pakketten worden gespiegeld naar een intern register, en builds halen alleen uit die mirror – nooit rechtstreeks uit een openbaar register tijdens de build. Dit geeft het programma een gecontroleerd doorlichtingspunt en doorbreekt de afhankelijkheid van de build van internetbereikbaarheid, wat verplicht is voor air-gapped en geclassificeerde omgevingen.

Kwetsbaarheidsscanning. Elke afhankelijkheid wordt gescand tegen kwetsbaarheidsdata zoals de OSV advisory database, en de resultaten bepalen de promotie. De uitvoer van het opsommen van elk transitief component is een software bill of materials. Voor de aankoopgedreven vereisten die nu aan dat artefact zijn gekoppeld, zie onze analyse van de software bill of materials voor defensie. De SBOM wordt gegenereerd in een standaardformaat – CycloneDX of SPDX – en als ondertekende attestatie aan het artefact gehecht zodat het met het binaire bestand meereist.

Beleidshandhaving: de toelatingspoort

Geen van deze controles doet ertoe tenzij ze een niet-conform artefact blokkeren om te worden uitgerold. Het handhavingspunt is de toelatingspoort – het moment onmiddellijk voordat een artefact wordt gepromoveerd naar een release-register of uitgerold naar een operationele omgeving. Bij deze poort voert een beleidsengine een reeks verplichte controles uit: het verifieert de handtekening van het artefact, valideert de herkomst tegen de verwachte bron- en builderidentiteiten, controleert de SBOM tegen kwetsbaarheidsdata en een lijst van verboden componenten, en bevestigt dat de wijziging de vereiste tweepersoonsreview heeft doorstaan.

De kritieke ontwerpregel is dat beleid moet blokkeren, niet slechts markeren. Een veelvoorkomende tekortkoming is om eerder in de pijplijn scanners te draaien die waarschuwingen uitzenden, terwijl de promotiestap geen harde poort heeft – waardoor een gemarkeerd artefact toch wordt verzonden wanneer een engineer onder deadlinedruk overrulet. De toelatingspoort moet falen-gesloten zijn: als de herkomst niet kan worden geverifieerd, wordt het artefact niet uitgerold. Het inbedden van deze poorten als code, gereviewd en versiebeheerd zoals elke andere pijplijnfase, is de natuurlijke uitbreiding van een DevSecOps-praktijk voor defensie, waarbij beveiligingscontroles deel uitmaken van elke sprint in plaats van een audit vóór de release.

De keten bedienen in geclassificeerde omgevingen

In een air-gapped of geclassificeerde enclave moet de hele keten draaien zonder internettoegang. Interne mirrors bevatten doorgelichte afhankelijkheden, de buildservice en het transparantielog draaien binnen de enclave, en verificatiesleutels worden via goedgekeurde kanalen verspreid. Updates van de afhankelijkheidsmirror komen aan via gecontroleerde cross-domain-overdrachten, elk met hun eigen herkomst zodat de enclave de oorsprong opnieuw kan verifiëren voordat een pakket wordt toegelaten. De toeleveringsketen vanaf de eerste sprint ontwerpen voor offline werking – in plaats van het achteraf in te bouwen – is wat het verschil maakt tussen een controlekader dat accreditatie overleeft en een dat bezwijkt bij contact met een echte geclassificeerde uitrol.