Varje containeravbildning du kör är en mjukvara som du litar blint på om du inte har gjort något för att verifiera den. Den kom från ett register, den passerade genom en byggpipeline, och någonstans längs den vägen kunde vem som helst med åtkomst ha bytt ut den mot något annat. Containersignering är hur du täcker den luckan. Du kopplar en kryptografisk signatur till en avbildning, och ditt kluster vägrar att köra något som inte innehåller en giltig.
Länge var detta något som säkerhetsmedvetna team gjorde medan alla andra sköt upp. Det förändras snabbt. Regler som EU:s Cyber Resilience Act och ramverk som Supply Chain Levels for Software Artifacts (SLSA) , utvecklade av Google, driver upp leveranskedjans integritet på prioriteringslistan, och för organisationer som levererar programvara i container har signerade bilder med tvångsverifiering blivit en prioritet för 2026 snarare än ett projekt som en gång skulle kunna ske.
Två verktyg dominerar samtalet: Notation, från CNCF Notary Project, och Cosign, från Sigstore-projektet. Folk tenderar att rama in valet som en jämförelse av funktioner. Det är mer användbart att förstå det som ett val mellan två olika modeller av förtroende, eftersom det är det som faktiskt avgör vilken som passar din organisation.
Vad de två verktygen har gemensamt
Innan skillnaderna finns är det bra att se den gemensamma grunden, eftersom den är större än man kan förvänta sig.
Både Notation och Cosign signerar OCI-artefakter, inte bara containeravbildningar. Båda lagrar signaturen i ditt register som en separat artefakt kopplad till avbildningen, med hjälp av OCI 1.1 Referrers API , så signaturen följer med avbildningen och behöver inte en separat databas. Båda verifierar mot en digest snarare än en tagg, vilket är viktigt eftersom taggar kan flyttas och en digest inte kan. Och båda ansluts till samma verkställighetslager i Kubernetes, så oavsett vilket du väljer kan du gata distributioner på en giltig signatur.
Faktum är att de två kan samexistera på samma image. Vissa organisationer signerar med Cosign i sin CI-pipeline för enkelhetens skull och signerar igen med Notation för formell releasesignering, och kräver sedan båda signaturerna innan något driftsätts. Verktygen utesluter inte ömsesidigt. Men för de flesta team som väljer en primär metod är det förtroendemodellen som beslutet fattas.
Cosign: Identitetsbaserad, nyckelfri och snabb att implementera
Cosigns huvudfunktion är nyckelfri signering, och den är verkligen smart. Istället för att hantera en långlivad signeringsnyckel autentiserar signeraren sig via en OIDC-identitetsleverantör, samma typ av inloggning som ditt CI-system redan har. En Sigstore-tjänst som heter Fulcio utfärdar ett kortlivat X.509-certifikat , giltigt i cirka 10 minuter, och binder den identiteten till ett kortlivat nyckelpar. Både signaturen och certifikatet loggas till en transparenslogg som heter Rekor, vilket skapar en verifierbar registrering av vem som signerade och när, även efter att nyckeln är borta.
Attraktionen är uppenbar. Det finns ingen signeringsnyckel att lagra, rotera, skydda eller förlora, eftersom nyckeln aldrig lagras. För ett team utan en dedikerad PKI- funktion eliminerar detta den enskilt svåraste delen av signeringen. Cosign har också förstklassigt stöd för att koppla SBOM:er och SLSA-proveniensattesteringar, och det bredaste ekosystemet av Kubernetes-verktyg kring det. Om du bygger en modern proveniens- och attesteringspipeline och vill agera snabbt är Cosign ofta den snabbaste vägen.
Avvägningen är själva förtroendemodellen. Nyckellös signering binder förtroende till en identitet som verifierats av en extern OIDC-leverantör, och i sin standardform lutar den sig mot Sigstores publika infrastruktur. Du kan hosta Fulcio och Rekor själv för att göra det internt, men att göra det är ett verkligt operativt arbete. Och identitetsbaserat förtroende, även om det är kraftfullt, är något annat än nyckelförvaringsmodellen som många efterlevnadssystem skrivits kring.
Notering: Enterprise PKI och nycklar du kontrollerar
Notation använder den metod som stora företag har använt för kodsignering i årtionden. Du signerar med ett X.509-certifikat utfärdat av en certifikatutfärdare du litar på, vanligtvis din egen, och verifieringen kontrollerar signaturen mot den certifikatutfärdaren genom en förtroendepolicy som du definierar. Signaturerna använder COSE-formatet och lagras, precis som Cosign, som OCI-artefakter i registret. Notations förtroendepolicyer kan finjusteras till specifika register, databaser eller identiteter, vilket passar organisationer som behöver delegerad och segmenterad signeringsbehörighet.
Det som gör Notation till den naturliga modellen för ett reglerat företag är just denna förankring i din egen PKI. Signeringsnyckeln är en långlivad organisatorisk tillgång under din kontroll, inte en kortlivad autentiseringsuppgift knuten till en extern identitetstjänst. Notations plugin-modell integreras med nyckelhanteringssystem och hårdvarusäkerhetsmoduler, så signeringsnyckeln kan finnas i en HSM och aldrig lämna den. För organisationer med efterlevnadskrav kring nyckelförvaring, den typ som kommer med FIPS- validering eller FedRAMP, är den hårdvarubaserade, organisationsstyrda nyckeln ofta den enda modellen som uppfyller kraven. Den passar också bra in i miljöer där extern offentlig infrastruktur är utesluten men en intern CA redan finns.
Kostnaden, i förhållande till nyckelfri Cosign, är att du är tillbaka till att hantera nycklar och en PKI. Det är ett verkligt ansvar. Men för ett företag som redan använder PKI är det inte nytt arbete, det är befintlig kapacitet som tillämpas på en ny yta, och det ger dig en förtroendemodell som direkt kopplas till hur dina revisorer redan tänker. Återkallelse av certifikat hanteras via standard PKI-mekanismer som CRL eller OCSP , vilket innebär att ett komprometterat signeringscertifikat kan återkallas och bilder som signerats med det kan flaggas eller blockeras genom att uppdatera din förtroendepolicy. Det kopplas direkt till hur företagets säkerhetsteam redan hanterar incidenter med kodsigneringscertifikat.
Den delen folk glömmer: Signering är bara halva jobbet
Här är misstaget som i tysthet undergräver många signeringsinsatser. En signatur på en avbildning gör ingenting i sig själv. Om ingenting i ditt kluster kontrollerar den, körs en osignerad eller manipulerad avbildning lika enkelt som en signerad. Säkerheten finns bara i verkställighetsögonblicket.
Tillämpning i Kubernetes sker genom åtkomstkontroll, och det lönar sig att tänka på det i lager. En gate före driftsättning, implementerad med en åtkomstkontrollant som Kyverno, Sigstore Policy Controller eller OPA Gatekeeper i kombination med Ratify, inspekterar varje bild när den ska släppas in och avvisar allt utan en giltig signatur mot din policy.
Körningsmiljön kan lägga till ett andra lager: nyare versioner av containerd stöder en bildverifierare som kontrollerar signaturer vid pull-tillfället, innan en bild tillåts köras på en nod. Utöver det kan en promotionsgate kräva en giltig signatur innan en bild flyttas från staging till produktionsregistret, och regelbundna körtidsrevisioner kan bekräfta att det som redan körs fortfarande verifierar mot gällande policy.
Dessa åtkomstkontroller körs vanligtvis i ett av två lägen, och skillnaden spelar större roll än den låter. I revisionsläge genererar en misslyckad verifiering en varning men avbildningen driftsätts fortfarande. I enforcement-läge blockerar en misslyckad verifiering driftsättningen helt. Revisionsläge är rätt ställe att börja, så att du kan se vad som skulle avvisas utan att något går sönder, men revisionsläge är inte skydd.
Hela poängen med signering är att nå verkställighetsläget med tillförsikt, och att för att komma dit på ett säkert sätt innebär att man gradvis rullar ut policyn, namnrymd för namnrymd, med en tillräckligt tillförlitlig signeringspipeline för att legitima avbildningar aldrig ska misslyckas.
Det är också här valet av verktyg möter verkligheten. Oavsett vilket du väljer levererar signaturerna bara värde när verkställighetslagret är aktivt, finjusterat och tillräckligt pålitligt för att faktiskt blockera. Ett signeringsprogram som aldrig lämnar granskningsläget är en riktig katastrof.
Hur krypteringskonsulting kan hjälpa
Att skapa containersignering som uppfyller kraven från CRA och SLSA är delvis ett verktygsbeslut och delvis en fråga om vart förtroendet faktiskt finns. För de flesta företag pekar svaret mot signering förankrad i PKI som du kontrollerar, med nycklar skyddade i hårdvara, och det är helt klart vad vi gör.
CodeSign Secure , vår kodsigneringslösning, ger dig en styrd signeringsprocess för dina programvaruartefakter, inklusive containeravbildningar, med de policykontroller, åtkomststyrning och nyckelskydd som en PKI-baserad metod i Notation-stil är beroende av. Istället för att signera nycklar utspridda över CI-körare och utvecklarmaskiner, sker signeringen genom ett kontrollerat system med en tydlig revisionslogg, vilket är precis den status som revisorer och leveranskedjeramverk förväntar sig att se.
Vad Codesign Secure bidrar med inom containersignering
Det här inlägget har ägnat större delen av sin tid åt Notation och Cosign, så det är värt att vara konkret om vad vår egen plattform tillför, eftersom en förtroendemodell bara är så bra som signeringsprocessen som omger den. CodeSign Secure är en centraliserad signeringsplattform byggd för moderna DevOps-miljöer.
Den integreras med de CI/CD-system som de flesta team redan kör, inklusive Azure DevOps, Jenkins och GitLab, och den placerar varje signeringsoperation bakom åtkomstkontroller och godkännandearbetsflöden så att signeringen förblir styrd snarare än spridd över byggagenter.
Signeringsnycklar lagras i en FIPS 140-2 nivå 3-hårdvarusäkerhetsmodul, och plattformen fungerar med de HSM:er som företag redan använder, inklusive Entrust nCipher, Thales Luna, Utimaco och Securosys, oavsett om det är lokalt eller i molnet. Åtkomst styrs genom integration med Microsoft Active Directory och Keycloak, med rollbaserad åtkomstkontroll och anpassningsbara arbetsflöden.
Policyer tillämpas på plattformsnivå, så ingenting signeras om det inte uppfyller de kriterier du definierar, från certifikattyp till de godkännanden som krävs i varje steg. Separation av uppgifter är inbyggd, eftersom en utvecklare kan begära en signatur men en releaseansvarig eller säkerhetsansvarig måste godkänna den innan signaturen tillämpas, vilket eliminerar risken för att ett enskilt komprometterat konto signerar och levererar programvara på egen hand.
Eftersom den signerar ett brett utbud av format, inklusive Docker-containrar och OCI-avbildningar tillsammans med firmware-binärfiler, körbara filer och paket, passar den det containersigneringsfall som det här inlägget handlar om, såväl som resten av en organisations signeringsbehov, och den kopplas till vanliga verktyg som Signtool, Jarsigner och JSign.
Den använder klientsidig hashning och säker tidsstämpling så att signaturer förblir giltiga även efter att ett certifikat har löpt ut, och den registrerar varje signeringshändelse, tillsammans med godkännanden och avslag bakom den, i granskningsloggar som matar SIEM-verktyg som Grafana, Loki och Splunk via OpenTelemetry. Det ger säkerhetsteam det bevisspår som leveranskedjeramverk förväntar sig att se.
Den kan köras som en helt hanterad molntjänst med inbyggd HSM-säkerhet eller lokalt med nycklar som lagras i molnet eller lokala HSM:er, så att distributionsmodellen kan matcha dina begränsningar. Den signerar också med post-kvantumalgoritmer direkt på HSM:en, inklusive ML-DSA (Module-Lattice-Based Digital Signature Algorithm) och LMS (Leighton-Micali Signatures), och den stöder dubbla signaturer som parar ihop en klassisk RSA- eller ECDSA -signatur med en post-kvantumsignatur för en gradvis övergång.
Eftersom signering av företagsavbildningar bara är så pålitlig som certifikatutfärdaren bakom den, ger PKI-as-a-Service dig en modern, välskött certifikatutfärdare för att utfärda och hantera de signeringscertifikat som förankrar din förtroendepolicy, utan bördan av att själv bygga och underhålla den infrastrukturen. Detta är roten till förtroende som en Notation-distribution verifierar mot, och att göra det rätt är det som gör hela kedjan trovärdig.
För att skydda signeringsnycklarna själva isoleras de i en hårdvarusäkerhetsmodul med HSM-as-a-Service , så att en signeringsnyckel inte kan kopieras från en byggserver eller extraheras från en pipeline. För organisationer med FIPS- eller FedRAMP-skyldigheter kring nyckelförvaring är hårdvarubaserade nycklar vanligtvis inte valfria, och att para ihop dem med ditt signeringsarbetsflöde är det som gör att du kan uppfylla dessa krav snarare än att arbeta runt dem.
Om du funderar på hur du ska signera dina containeravbildningar och var du ska rota förtroendet, eller om du vill ha hjälp med att ta ett signeringsprogram hela vägen till tvångsverifiering, kontakta oss . Vi kan hjälpa dig att designa det och bygga PKI- och nyckelskyddet under det.
Slutsats
Frågan om Notation kontra Cosign handlar egentligen inte om vilket verktyg som har flest funktioner. Det handlar om vilken förtroendemodell som passar just din organisation. Cosigns nyckelfria signering är snabb att implementera och utmärkt för moderna pipelines med många attesteringar, särskilt för team som hellre inte vill köra en PKI alls. Notations Enterprise-PKI-metod passar organisationer som redan hanterar certifikat, behöver nycklar som de kontrollerar och kan placera i hårdvara, och uppfyller kraven på efterlevnadssystem som bygger på nyckelförvaring. Många organisationer använder båda, för olika steg i samma pipeline.
Oavsett vad du väljer gäller två saker. Signaturen måste vara förankrad i en förtroendemodell du kan stå bakom, och den måste upprätthållas vid inträdet, inte bara framställas och glömmas bort. En signerad bild som ingenting verifierar är inte säkrare än en osignerad.
Reglering av leveranskedjan kommer inte att lätta, och trycket att bevisa var din programvara kommer ifrån kommer bara att öka. De organisationer som medvetet infört signering och verkställighet i år, med sitt förtroende förankrat i den infrastruktur de kontrollerar, är de som kommer att behandla nästa efterlevnadskrav som en redan markerad ruta snarare än en brand att släcka.
