Artefaktintegritet

En artefakt är den paketerade utdatan från ett bygge. En containerimage, en kompilerad binär, en JAR-fil, ett Helm-paket eller någon annan distribuerbar enhet som byggsystemet producerar. I supply chain-säkerhet är den kritiska frågan om en artefakt inte bara vad den innehåller utan om den kan spåras tillbaka till en specifik, betrodd byggshändelse.

Artefakter bör vara oföränderliga när de väl byggts. En artefakt identifierad av version 2.3.1 ska alltid referera till exakt samma bytes. Muterbara artefaktidentifierare underminerar varje nedsånds integritetskontroll. Innehållsadresserad lagring, där en artefakt identifieras av den kryptografiska hashen för dess innehåll, ger oföränderlighetvia konstruktion.

Versionshanteringsstrategi kommunicerar avsikt och möjliggör spårbarhet. Att använda git commit-SHA:n som del av artefaktversionen (myapp:a3f2c9b) gör att varje körande instans kan spåras tillbaka till den exakta källkodscommit som producerade den.

Artefaktens livscykel har fyra viktiga integritetsmoment. Skapande (bygget måste vara betrott och indata kontrollerad), lagring (registry eller artefaktlager måste skydda artefakten från modifiering), distribution (överföringen från lagring till driftsättning måste vara integritetVerifierad) och konsumering (driftsättningssystemet måste verifiera artefakten innan användning). En supply chain-attack kan rikta sig mot något av dessa moment.

Signering kopplar ett kryptografiskt bevis till en artefakt eller till metadata om den artefakten, så att varje konsument kan verifiera att artefakten producerades av en specifik part och inte har modifierats sedan den signerades. För containerimages är Cosign från Sigstore-projektet den nuvarande standarden. Cosign signerar images genom att skapa en signatur som lagras i samma OCI-registry som imagen, med ett nyckelpar eller en nyckellös identitet från en OIDC-leverantör.

Värdet av signering beror helt på kvaliteten hos signeringsidentiteten. En signatur från ett välhanterat nyckelpar eller en verifierbar OIDC-identitet bevisar vem som byggde imagen. En signatur från en nyckel som delas brett, lagras osäkert eller genereras av en opålitlig pipeline ger liten säkerhet.

Signering är inte begränsat till containerimages. Binärartefakter, release-tar-arkiv, npm-paket, PyPI-paket och Helm-paket kan alla signeras med lämpliga verktyg. Den specifika verktyget är mindre viktigt än disciplinen. Varje artefakt publicerad från en betrodd byggpipeline bör signeras, och konsumenter bör konfigureras för att verifiera signaturer innan de använder artefakten.

Ett vanligt misstag är att signera artefakter men aldrig verifiera signaturerna vid driftsättningstillfallet. Signering som inte verkställs vid konsumering ger en granskningslogg men inte en säkerhetskontroll. Kombinationen av signering vid byggtid och obligatorisk verifiering vid driftsättningstid är vad som förhindrar manipulerade artefakter från att driftsättas.

Verifiering är konsumentsidans kontroll som bekräftar att en artefakts signatur, identitet och policy är acceptabla innan artefakten används. Verifiering är där integritet blir en operativ verklighet snarare än en teoretisk egenskap. En artefakt som är signerad men aldrig verifieras ger en falsk känsla av säkerhet.

Verifiering bör ske vid konsumeringstillfallet, inte bara vid bygge eller lagring. En image som verifierades ren när den byggdes och placerades i ett registry kan ha modifierats i registryt, eller taggen den refereras av kan ha uppdaterats för att peka på en annan image.

Policybaserad verifiering gör att driftsättningssystem kan verkställa krav utöver bara närvaron av en giltig signatur. En policy kan kräva att signaturen kommer från en specifik OIDC-identitet, att imagen byggdes från ett specifikt repositorium, eller att en specifik uppsättning tester godklärdes.

Det felsätt som underminerar verifieringen är att behandla den som frivillig eller som en varning snarare än en hård port. Om ett driftsättningssystem loggar ett verifieringsfel men fortsätter att driftsätta artefakten ger verifieringen inget skydd. Verifiering bör vara en hård port i varje miljö där integritet är viktigt.

En programvarubillsförteckning (SBOM) är ett maskinläsbart lager av varje komponent inuti en programvarartefakt. För en containerimage innebär detta alla operativsystemspaket, språkbibliotek och deras exakta versioner. SBOM-format inkluderar SPDX (en Linux Foundation-standard) och CycloneDX (används brett i säkerhetsverktyg). Verktyg som Syft kan generera en SBOM från vilken containerimage som helst.

SBOM:er möjliggör snabb respons när en ny sårbarhet avslöjas. När Log4Shell tillkännagavs i december 2021 kunde organisationer med aktuella SBOM:er för alla sina artefakter omedelbart fråga vilka artefakter som innehöll log4j och vid vilken version. Organisationer utan SBOM:er fick reaktivt skanna, ofta med ofullständiga resultat.

SBOM:er stödjer användningsfall utöver incidentrespons. Licensefterlevnadsgranskning använder SBOM:en för att verifiera att varje inkluderad komponent har en acceptabel licens. Krav på transparens i leveranskedjan, som de i det amerikanska exekutiva ordern 14028, kräver SBOM:er för programvara såld till den federala regeringen.

Det operativa värdet av en SBOM beror på att den är korrekt, aktuell och tillgänglig när den behövs. En SBOM genererad vid byggtid och lagrad bredvid artefakten i registryt är omedelbart tillgänglig för varje system som behöver den. SBOM:en bör vara en förstaklass-utdata från byggpipelinen, genererad automatiskt och bifogad varje publicerad artefakt.

Proveniens är det dokumenterade registret över var en artefakt kom ifrån och hur den producerades. En provenienpost för en containerimage kan ange att imagen byggdes från commit abc123 i repositoryt github.com/myorg/myapp, med hjälp av produktionsbygge-GitHub Actions-arbetsflödet. Denna post gör att en konsument kan spåra artefakten tillbaka till dess ursprung.

SLSA (Supply-chain Levels for Software Artifacts) är det ramverk som formaliserar provenienkkrav i en uppsättning mognadsnivåer. SLSA Nivå 1 kräver grundläggande proveniensdokumentation. SLSA Nivå 2 kräver att proveniens genereras av själva byggtjänsten, inte av byggförfattaren. SLSA Nivå 3 kräver att bygget körs i en härdad, isolerad miljö med ett manipuleringsresistent proveniensskiva.

Proveniens genereras som en del av byggprocessen och signeras av byggsystemet, inte av utvecklaren. Denna separation är viktig. En utvecklare som kan ändra sin egen proveniensskiva kan skapa en falsk proveniens för en skadlig artefakt. Proveniens genererad och signerad av CI-plattformen är betrodd eftersom den kommer från bygginfrastrukturen, som utvecklaren inte direkt kontrollerar.

Provenienverifiering vid driftsättningstid gör att driftsättningssystem kan verkställa att varje artefakt de använder byggdes av en betrodd process. En policy som säger acceptera bara images byggda av produktionsbygge-arbetsflödet i main-grenen förhindrar driftsättning av images byggda utanför den betrodda pipelinen.

Intyg är signerade uttalanden om en artefakt som går utöver det binära anspråket i en signatur. Medan en signatur säger att denna artefakt signerades av denna nyckel, säger ett intyg att denna artefakt klarade följande säkerhetsskanning, eller att denna artefakts beroenden inte har några kritiska CVE:er. Intyg uttrycks som strukturerade, signerade dokument och lagras bredvid artefakten i registryt.

Intyg gör att driftsättningspolicy kan uttryckas i termer av vilka bevis artefakten bär, inte bara vem som signerade den. En driftsättningspolicy kan kräva. En giltig signatur från produktionspipelinen, ett godkänt SAST-skanningsintyg, ett godkänt SCA-skanningsintyg utan kritiska CVE:er och ett proveniensintyg som visar att bygget kom från main-grenen.

Värdet med intyg är att de för samman flera säkerhetskontrollresultat i ett enda, verifierbart paket som reser med artefakten. I stället för att kräva att driftsättningssystemet oberoende verifierar att en specifik pipeline kördes bifogar pipelinen intyg till artefakten vid byggtid, och driftsättningssystemet verifierar intygen vid driftsättningstid.

Ett vanligt misstag är att generera intyg utan en policy som kräver dem. Intyg som skapas men aldrig kontrolleras vid driftsättning ger inget säkerhetsvärde. Driftsättningspolicyn måste explicit kräva specifika intyg, och verkställningen måste vara en hård port snarare än en varning.

Cosign är ett open source-verktyg från Sigstore-projektet som tillhandahåller signerings-, verifierings- och intygsmöjligheter för containerimages och andra OCI-artefakter. Det stöder både traditionell nyckelparsignering och nyckellös signering med OIDC-identiteter, och det lagrar signaturer och intyg i OCI-registries bredvid de images de beskriver.

Nyckellös signering med Cosign fungerar genom att erhålla ett kortlivat signeringscertifikat från Sigstores Fulcio-certifikatutfärdare, med en OIDC-token från CI-leverantören (GitHub Actions, GitLab eller andra) som bevis på identitet. Certifikatet är kopplat till OIDC-identiteten och signeringshändelsen registreras i Sigstores Rekor-transparenslogg.

Cosign integreras med Kubernetes insläppskontroller genom verktyg som Sigstores policy-controller och Connaisseur. Dessa kontroller avlyssnar varje Pod-skapandebegäran, hämtar signaturer och intyg från registryt, verifierar dem mot en konfigurerad policy och tillåter eller nekar Poden baserat på resultatet.

Sigstore-ekosystemet som Cosign är en del av inkluderar Rekor (transparensloggen), Fulcio (certifikatutfärdaren) och olika integreringar med CI/CD-system och paketregistries. Att förstå Cosign i sammanhanget av detta ekosystem förklarar varför nyckellös signering är mer tillförlitlig än rå nyckelpassignering.

Förtroendekedjan är den fullständiga uppsättningen av identiteter, certifikat, policyer och verifierare som kopplar en signerad artefakt till ett driftsättningsbeslut. En förtroendekedja för en containerimage driftsätt i Kubernetes kan inkludera. GitHub Actions OIDC-identiteten som erhöll signeringscertifikatet från Fulcio. Cosign-signaturen lagrad i OCI-registryt. Rekor-transparensloggenposten. Kubernetes insläppskontrollern som hämtar och verifierar signaturen, och policyn som anger vilka identiteter som är betrodda signerare.

Förtroendekedjor måste vara explicita och granskade. En implicit förtroendekedja, där signering tekniskt sker men ingen har granskat om signeringsidentiteten är korrekt eller om verifieringspolicyn matchar de avsedda signerarna, ger en falsk känsla av säkerhet.

Rotation av element i förtroendekedjan kräver samordning. Om signeringsnyckeln roteras, eller OIDC-identiteten ändras, blir befintliga signaturer overifierbara såvida inte den nya identiteten läggs till i tillitspolicyn innan den gamla tas bort. Rotation av förtroendekedjan bör behandlas som en driftsättningshändelse. Planerad, testad i en icke-produktionsmiljö och utförd med återställningsmöjlighet.

Supply chain-attacker som riktar sig mot förtroendekedjor letar efter svaga länkar. Signeringsnycklar med bred åtkomst lagrade osäkert, verifieringspolicyer som är för tillförlåtande, insläppskontroller konfigurerade i varningsläge snarare än verkställningsläge, eller förtroenderotter som inkluderar fler identiteter än avsett. Regelbüunden granskning av förtroendekedjakonfigurationen håller kedjan tät över tid.