Sigstore za softverske pakete: kako provjeriti digitalne potpise bez ručnog upravljanja ključevima

Digitalni potpisi pomažu korisnicima paketa odgovoriti na dva praktična pitanja: je li se datoteka promijenila nakon potpisivanja i je li je potpisao identitet koji projekt navodi kao ovlaštenog potpisnika? Tradicionalne metode potpisivanja mogu pružiti te odgovore, ali često ovise o dugotrajnim privatnim ključevima, distribuciji javnih ključeva, rokovima valjanosti, postupcima opoziva i pažljivom čuvanju ključeva. Sigstore koristi drukčiji pristup. Programeru ili automatiziranom procesu objave omogućuje potvrdu identiteta putem OpenID Connecta, izradu kratkotrajnog ključa za potpisivanje, povezivanje tog ključa s kratkotrajnim certifikatom i bilježenje događaja potpisivanja u javnom dnevniku transparentnosti. Za korisnike to znači da se provjera više ne temelji na ručnom prikupljanju i održavanju pojedinačnih javnih ključeva, a pritom ostaje očuvana kriptografska veza između paketa, potpisnika i konkretnog događaja potpisivanja.

Zašto Sigstore mijenja način provjere potpisa paketa

Kod tradicionalnog dugotrajnog ključa za potpisivanje održavatelj mora zaštititi privatni ključ mjesecima ili godinama i odgovarajući javni ključ učiniti dostupnim svima koji trebaju provjeravati izdanja. Takav postupak može dobro funkcionirati, ali stvara dodatne administrativne obveze koje nisu izravno povezane sa samim paketom. Ključevi mogu isteći, izgubiti se, biti kopirani na nesigurna računala ili ostati označeni kao pouzdani i nakon što održavatelj napusti projekt. Korisnik također mora procijeniti odakle javni ključ potječe i pripada li još uvijek osobi ili organizaciji koja je uz njega navedena. Iskusni timovi za objavljivanje softvera mogu upravljati takvim problemima, no oni se lako zanemare kod manjih projekata otvorenog koda i automatiziranih sustava za izgradnju softvera.

Sigstoreov model potpisivanja temeljen na identitetu smanjuje taj teret stvaranjem privremenog ključa za pojedinačnu operaciju potpisivanja umjesto zahtjeva da potpisnik održava jedan trajni tajni ključ. Potpisnik potvrđuje identitet putem OpenID Connect izdavatelja kao što su GitHub, GitLab, Google ili Microsoft. Fulcio, Sigstoreovo certifikacijsko tijelo, provjerava podatke o identitetu i izdaje kratkotrajni certifikat koji taj identitet povezuje s privremenim javnim ključem. Privatni ključ postoji samo kratko vrijeme i nakon uporabe se odbacuje. Osoba koja provjerava potpis zato ne mora čekati da održavatelj objavljuje i neprekidno mijenja osobni javni ključ. Važni podaci postaju očekivani identitet potpisnika, izdavatelj identiteta i pouzdani Sigstoreovi korijenski certifikati koji se koriste za provjeru certifikata i dokaza o transparentnosti.

Događaj potpisivanja bilježi se i putem Rekora, Sigstoreova dnevnika transparentnosti. To je važno zato što je certifikat namjerno kratkog vijeka: provjera se može provoditi tjednima ili godinama nakon isteka certifikata. Zabilježeni dokaz pokazuje da je potpis postojao dok je certifikat bio valjan, pa osoba koja provjerava paket može potvrditi povijesni događaj potpisivanja umjesto da zahtijeva osobni certifikat koji je još uvijek važeći. Sigstoreovi alati dobivaju pouzdane korijenske podatke putem sustava The Update Framework, poznatog kao TUF, pa se korijenski certifikati i ključevi dnevnika mogu kontrolirano ažurirati. U praktičnom smislu, provjera paketa tako postaje sličnija provjeri očekivanog identiteta i zabilježenog događaja nego održavanju osobnog popisa ključeva potpisnika.

Što valjani Sigstore potpis zapravo potvrđuje

Uspješna Sigstore provjera pruža snažan dokaz da paket koji se provjerava odgovara podacima koji su izvorno potpisani. Ako se promijeni čak i mali dio datoteke, mijenja se njezin kriptografski sažetak i provjera potpisa trebala bi biti neuspješna. Provjera također obuhvaća certifikat i podatke o identitetu koji dolaze s njim, pa korisnik može zahtijevati određenu adresu e-pošte, identitet usluge ili automatizirani radni proces umjesto prihvaćanja bilo kojeg valjanog Sigstore potpisnika. To je važna razlika. Cilj nije samo dobiti poruku da je neki potpis valjan, nego potvrditi da je paket potpisao identitet koji je projekt izričito odredio za objavljivanje službenih izdanja.

Kod potpisivanja bez dugotrajnog ključa vremenski dokaz također je dio odluke o povjerenju. Kratkotrajni certifikat može već biti istekao kada korisnik provjerava stariji paket, ali to ne znači automatski da je stari potpis nevaljan. Sigstore paketi s podacima za provjeru mogu sadržavati potpis, certifikat, podatke o vremenskoj oznaci i dokaz povezan sa zapisom u dnevniku transparentnosti. Cosign koristi te podatke kako bi utvrdio je li se potpisivanje dogodilo tijekom razdoblja valjanosti certifikata i odgovaraju li zabilježeni podaci paketu koji se provjerava. Upravo je zato format bundle praktičan za obične datoteke: osoba koja provjerava potpis dobiva potrebne podatke na jednom mjestu umjesto da mora rekonstruirati događaj potpisivanja iz nekoliko nepovezanih datoteka.

Valjani potpis ne dokazuje da je paket siguran, bez programskih pogrešaka ili prikladan za određeni sustav. On potvrđuje činjenice o integritetu i identitetu potpisnika, ali ne i kvalitetu koda prije potpisivanja. Ako je kompromitiran ovlašteni račun održavatelja ili legitimni proces objave izgradi zlonamjeran kod iz izvornog repozitorija, i dalje može nastati kriptografski valjan potpis. Korisnici paketa zato bi Sigstore trebali promatrati kao jedan sloj zaštite lanca opskrbe softverom. Potvrde o podrijetlu, pregled izvornog koda, kontrola ovisnosti, skeniranje ranjivosti i reproducibilne izgradnje odgovaraju na druga pitanja i mogu nadopuniti provjeru potpisa, a ne biti zamijenjeni njome.

Kako u praksi provjeriti softverski paket potpisan Sigstoreom

Provjera počinje s tri podatka: točnom datotekom paketa, Sigstore materijalom za provjeru povezanim s tom datotekom i identitetom za koji očekujete da ju je potpisao. Za običnu datoteku ili arhivu izdanja materijal za provjeru često se isporučuje kao Sigstore bundle s nazivom koji završava nastavkom .sigstore.json. Očekivani identitet treba preuzeti iz službene dokumentacije projekta, njegova repozitorija ili sigurnosnih uputa, a ne s nepouzdane stranice za preuzimanje koja samo nudi paket. Potreban je i očekivani OpenID Connect izdavatelj. Kod automatiziranih objava identitet može biti URI radnog procesa umjesto adrese e-pošte određene osobe, čime i sam proces izgradnje postaje dio pravila provjere.

Cosign je glavni Sigstoreov alat naredbenog retka za potpisivanje i provjeru običnih softverskih datoteka. Uobičajena provjera koristi naredbu cosign verify-blob zajedno s datotekom paketa, njezinim bundleom, očekivanim identitetom certifikata i očekivanim OIDC izdavateljem. Najvažnije nije zapamtiti sintaksu naredbe, nego navesti dovoljno stroga pravila za identitet. Naredba koja prihvaća bilo koji identitet certifikata može potvrditi da je netko koristio Sigstore, ali ne potvrđuje da je izdanje potpisao očekivani projekt. U dobro definiranom postupku objavljivanja projekt navodi točan identitet ili uzorak radnog procesa kojem potrošači trebaju vjerovati, a provjera je postavljena tako da odbija potpise drugih identiteta čak i kada su ti potpisi kriptografski valjani.

Kada Cosign provjerava bundle, ne provjerava samo odvojeni digitalni potpis. Provjerava potpis u odnosu na sam paket, provjerava certifikat i zahtjeve vezane uz identitet te potvrđuje relevantne dokaze iz dnevnika transparentnosti ili vremenske oznake koristeći pouzdane Sigstore podatke. Neuspješnu provjeru treba istražiti prije instalacije paketa ili njegova premještanja u produkcijsko okruženje. Neuspjeh ne znači automatski da je datoteka izmijenjena: pogrešno naveden identitet, zastarjela lokalna konfiguracija povjerenja, neodgovarajući bundle ili oštećeno preuzimanje također mogu uzrokovati neuspjeh provjere. Praktično pravilo je jednostavno: izdanje se ne bi trebalo smatrati provjerenim dok i kriptografska provjera i provjera očekivanog identiteta ne uspiju za točno onu datoteku koja će se koristiti.

Provjera u npm-u, PyPI-ju i Maven Centralu

Neki ekosustavi paketa sada prikazuju podatke podržane Sigstoreom putem vlastitih alata, pa korisnici ne moraju uvijek ručno pokretati Cosign. npm provenance može povezati objavljeni paket s njegovim izvornim repozitorijem i okruženjem u kojem je izrađen, dok npm-ova provjera potpisa kontrolira potpise registra i dostupne potvrde o podrijetlu instaliranih ovisnosti. Za tu se svrhu koristi naredba npm audit signatures. npm dokumentacija također preporučuje korištenje novije verzije npm CLI-ja jer se formati potvrda i mogućnosti provjere nastavljaju razvijati. To je dobar primjer Sigstorea kao temeljnog mehanizma povjerenja, dok standardni alati za upravljanje paketima rezultat provjere prikazuju u obliku koji programeri mogu koristiti tijekom uobičajene kontrole ovisnosti.

PyPI podržava digitalne potvrde prema PEP-u 740 i kombinira ih s mehanizmom Trusted Publishing. Paket objavljen putem ovlaštenog automatiziranog izdavatelja može sadržavati potvrdu koja pokazuje koji je identitet izdavatelja korišten. PyPI te potvrde čini dostupnima putem svojih indeksnih API-ja, a alat pypi-attestations može provjeriti distribucijsku datoteku u odnosu na zabilježeno podrijetlo i očekivani izvorni repozitorij. Korisnici Pythona tako mogu provjeriti je li wheel ili arhiva izvornog koda objavljena putem očekivanog pouzdanog radnog procesa i odgovara li datoteka potpisanoj izjavi. PyPI pritom jasno odvaja ovu provjeru od procjene je li sam paket pouzdan: potvrda dokazuje činjenice povezane s podrijetlom, ali ne dokazuje da paket ne sadrži štetan kod.

Maven Central pokazuje zašto se uvođenje Sigstorea ne može promatrati jednako u svakom ekosustavu paketa. Njegovi aktualni zahtjevi za objavljivanje i dalje zahtijevaju GPG ili PGP potpise za datoteke koje se prenose. Istodobno Central podržava pridružene datoteke .sigstore.json i provjerava Sigstore potpise kada ih izdavatelji dostave. Java biblioteka zato može imati i tradicionalni .asc potpis i Sigstore materijal za provjeru. Za korisnike je praktična poruka da trebaju slijediti pravila i metapodatke izvora paketa koji stvarno koriste. Sigstore može ukloniti ručno upravljanje ključevima iz procesa osmišljenih oko potpisivanja temeljenog na identitetu, ali ne ukida postojeće zahtjeve za potpisivanje u ekosustavima koji i dalje zahtijevaju dugotrajne PGP ključeve.

Gdje se provjera bez dugotrajnih ključeva uklapa u proces objavljivanja 2026. godine

Sigstore je posebno koristan kada se softver automatski objavljuje iz sustava kontinuirane integracije koji može izdati OIDC token identiteta. Umjesto spremanja dugotrajnog ključa za potpisivanje kao tajne postavke procesa izgradnje, zadatak objavljivanja dobiva kratkotrajni token identiteta, pribavlja kratkotrajni certifikat za potpisivanje i potpisuje rezultat tijekom tog izvršavanja. Identitet može opisivati repozitorij i radni proces koji je izvršio objavu, pružajući korisnicima konkretnu vrijednost koju mogu provjeriti. Takav pristup smanjuje posljedice slučajnog izlaganja trajnog ključa za potpisivanje jer u postavkama procesa izgradnje možda uopće ne postoji privatni ključ koji bi se mogao ponovno koristiti. Istodobno smanjuje potrebu da redovita promjena ključeva bude središnji dio svakodnevne administracije izdanja.

Osoba koja provjerava potpis ipak mora imati jasno pravilo povjerenja. Uklanjanje ručnog upravljanja ključevima ne znači uklanjanje odluka o tome komu se vjeruje. Tim mora odrediti koji repozitorij, radni proces, servisni račun ili identitet održavatelja smije potpisivati paket. Provjera zatim treba zahtijevati upravo taj identitet i njegova očekivanog izdavatelja. Ako projekt promijeni način objavljivanja, premjesti repozitorij ili promijeni identitet koji se koristi za potpisivanje, korisnici će možda trebati ažurirati prihvaćena pravila. To je praktičniji oblik održavanja od distribucije novog osobnog javnog ključa, ali i dalje zahtijeva određeni nadzor. Prednost je u tome što pravilo izravno opisuje tko ili što smije objavljivati softver, dok se kratkotrajni kriptografski materijal automatski stvara i odbacuje.

Alate i pouzdane korijenske podatke također treba redovito održavati ažurnima. Sigstore distribuira javne podatke o povjerenju putem TUF-a kako bi klijenti mogli dobivati promjene ključeva certifikacijskih tijela i dnevnika transparentnosti bez potrebe da svaki održavatelj paketa ponovno distribuira ključeve za provjeru. Cosign 3.x koristi Sigstore bundle kao zadani način prijenosa podataka potrebnih za provjeru potpisa u nekoliko čestih scenarija, što olakšava spremanje tih podataka uz datoteke izdanja i njihovu uporabu u drugim Sigstore alatima. Organizacije koje arhiviraju izdanja zato bi trebale zajedno čuvati paket i pripadajući bundle. Očuvanje provjerene kopije relevantnih metapodataka izdanja posebno je korisno kada paket treba ponovno provjeriti dugo nakon isteka izvornog certifikata za potpisivanje.

Praktična ograničenja i razumne provjere prije prihvaćanja izdanja

Najvažnije ograničenje jest to što potpisivanje temeljeno na identitetu premješta sigurnosnu granicu prema pružatelju identiteta i procesu objavljivanja. Ako napadač preuzme kontrolu nad ovlaštenim računom programera ili radnim procesom koji ima pravo zatražiti token identiteta, može biti u mogućnosti izraditi izdanje s naizgled valjanim potpisom. Dnevnik transparentnosti pomaže jer se događaji potpisivanja mogu javno provjeravati, a neočekivani identiteti ili događaji mogu se naknadno otkriti, no zapisivanje događaja nije isto što i njegovo sprječavanje. Projekti i dalje trebaju štititi račune održavatelja snažnom autentifikacijom, ograničavati prava objavljivanja, pregledavati izmjene radnih procesa i odvajati uobičajene razvojne ovlasti od prava na objavu službenih paketa.

Podrijetlo je važno kada korisnik treba znati više od toga tko je potpisao završnu datoteku. Osnovni potpis može pokazati da je određeni identitet odobrio određeni paket, ali sam po sebi ne mora pokazati iz koje je revizije izvornog koda paket nastao ili kako je izgradnja provedena. Potvrde mogu dodati taj kontekst povezivanjem izdanja s repozitorijem, radnim procesom ili izjavom o izgradnji. npm provenance i PyPI potvrde praktični su primjeri. U okruženjima s višim sigurnosnim zahtjevima timovi mogu kombinirati Sigstore provjeru sa SLSA podacima o podrijetlu, popisima softverskih komponenti, pravilima za ovisnosti i reproducibilnim izgradnjama. Svaka od tih kontrola smanjuje drukčiju vrstu neizvjesnosti umjesto da se od jednog digitalnog potpisa očekuje odgovor na svako pitanje povezano s lancem opskrbe softverom.

Razumno pravilo provjere za 2026. godinu stoga je jednostavno: preuzimajte pakete iz očekivanog izvora, provjeravajte točno onu datoteku koju namjeravate koristiti, zahtijevajte dokumentirani identitet potpisnika i izdavatelja, čuvajte pripadajući Sigstore bundle kada je dostupan te provjerite podatke o podrijetlu kada ih određeni ekosustav omogućuje. Ako izvor paketa i dalje zahtijeva PGP, treba provjeriti i taj potpis umjesto pretpostavke da ga je Sigstore zamijenio. Glavna prednost Sigstorea nije u tome što povjerenje postaje automatsko. Prednost je u tome što softverski projekti mogu koristiti kratkotrajne vjerodajnice i provjerljive identitete umjesto da svaki održavatelj i svaki korisnik ručno upravlja mrežom dugotrajnih ključeva za potpisivanje, uz zadržavanje provjerljivog zapisa o tome tko je što potpisao i kada.