Sikkerhet i programvareleverandørkjeden, registrert fra hvert bygg
Programvareleverandørkjeden din møter produktet ditt i CI-bygget. CRACI kjører GitHub Actions-jobbene dine på sikre runnere og registrerer hver avhengighet de henter inn, styrer hva hvert bygg kan nå og fortsetter å spore sårbarheter i det du har levert.
Sikre runnere for GitHub Actions
Bytt runs-on til craci, så kjører GitHub Actions-jobbene dine på CRACIs runnere, og kjøringene vises fortsatt i GitHub. Hver jobb får sin egen isolerte virtuelle maskin på Linux x86-64 eller ARM64, driftet i Europa. Bygg kjører omtrent dobbelt så raskt som på GitHub-hostede runnere, takket være raskere maskinvare, kortere køtid og caching.
En SBOM registrert fra hvert bygg
CRACI registrerer, den skanner ikke. En pakkebevisst proxy på runneren ser hver pakke jobben henter inn fra npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder, i tillegg til download-presets for Yocto og OpenEmbedded, inkludert pakker gjenopprettet fra CI-cacher. SBOM-en til hver jobb har en fullstendighetsstatus og eksporteres som CycloneDX eller SPDX med transitive avhengigheter og den deklarerte lisensen til hver komponent.
Styr hva et bygg kan nå
En egress-policy bestemmer hvilke verter en jobb kan koble seg til: default deny eller default allow, 24 innebygde presets for programvarekilder, typede egendefinerte kilder for pakkeregistre og Git, og eksplisitte nettverksregler. Policyen valideres før jobben starter og blokkerer ved feil, og brudd utløser et varsel. En kompromittert avhengighet eller et kompromittert byggesteg kan ikke i det stille sende data til en vert du aldri har godkjent.
Provenance for det du leverer
Det offentlige REST-API-et returnerer SBOM-er, nettverksspor og provenance for hver jobb, alt registrert fra det samme bygget. Dokumentasjonen kommer fra selve bygget, uten et ekstra steg i workflowen.
Sårbarhetssporing etter utgivelse
CRACI vurderer SBOM-ene for det du har levert, på nytt etter hvert som nye sårbarheter publiseres, og samler funn på tvers av bygg og repositorier. Sikkerhetsteamene prioriterer dem og sender hvert funn videre til teamet som eier rettingen. Policy-gates kan stoppe et bygg på grunn av funn eller en lisens, VEX støttes, leverandørers SBOM-er overvåkes side om side med dine egne bygg, og inventarvisningen viser hvilke programvareversjoner som er tatt i bruk i hvilke produkter.
Dokumentasjon for kunder og revisorer
Kunder, revisorer og regelverk ber stadig oftere om en SBOM per utgivelse og en oversikt over hvordan sårbarheter er håndtert. CRACI eksporterer SBOM-er som CycloneDX eller SPDX, inkludert sårbarhetene som er funnet i komponentene, og et offentlig REST-API returnerer SBOM-er, nettverksspor og provenance. Den samme dokumentasjonen støtter EUs Cyber Resilience Act, NIS2, FDAs SBOM-krav og kontrollene for leverandørkjeden i ISO 27001.
Spørsmålene en hendelse i leverandørkjeden reiser
Når en pakke, en CI-action eller et register blir kompromittert, går de første timene med til å finne ut om du er berørt. Dette er spørsmålene team stiller, og der CRACIs registrering av bygget gir svar.
| Spørsmålet | Slik svarer CRACI |
|---|---|
| Hentet noen av byggene våre inn den kompromitterte pakkeversjonen? | SBOM-en til hvert bygg viser pakkene jobben faktisk hentet, så du søker i registrerte bygg i stedet for å skanne repositoriene på nytt. |
| Hvilke av produktene og utgivelsene våre er berørt? | Overvåkede SBOM-er vurderes kontinuerlig på nytt, og inventarvisningen kobler programvareversjoner til produktene de er tatt i bruk i. |
| Kan et byggesteg ha sendt hemmeligheter et sted? | Nettverkssporet til hver jobb registrerer tilkoblingene den opprettet, og egress-policyen blokkerer verter utenfor policyen før de nås. |
| Er denne SBOM-en fullstendig nok til å levere fra seg? | SBOM-en til hver jobb oppgir fullstendigheten sin: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. |
| Hvem retter det, og kan vi bevise at det ble håndtert? | Funn prioriteres og sendes videre til de ansvarlige teamene, og SBOM-er eksporteres som CycloneDX eller SPDX med sårbarhetene som er funnet i komponentene. |
CRACI dekker bygget og det det leverer. Kodeskanning, skanning etter hemmeligheter og reachability-analyse forblir hos verktøyene dine for applikasjonssikkerhet. GitHub Actions støttes i dag, med andre CI-systemer på veikartet.
Sikkerhet i programvareleverandørkjeden: spørsmål og svar
Hva det dekker, hvorfor det hører hjemme i CI/CD, og hvor CRACI passer inn
Hva er sikkerhet i programvareleverandørkjeden?
Sikkerhet i programvareleverandørkjeden beskytter alt som går inn i programvaren din mellom første commit og utgivelsen: åpen kildekode-avhengigheter, base-images, byggeverktøy, CI-actions fra tredjeparter, selve CI-pipelinen og artefaktene du leverer. Det handler om å vite hva disse delene er, styre hvor de kommer fra og bevise hva som gikk inn i hver utgivelse.
Hvorfor sikre programvareleverandørkjeden i CI/CD?
Release-bygget er der avhengighetene dine løses, lastes ned og pakkes. Et produksjonsbygg er ikke det samme som bygget på en bærbar maskin: Versjonsintervaller, foranderlige tagger og cacher gjør at det kan hente inn noe annet. En registrering gjort mens release-bygget kjører, er den eneste pålitelige oversikten over hva som ble levert, og bygge-runneren er der du kan styre hva bygget kan nå.
Hvordan skiller CRACI seg fra en skanner for leverandørkjedesikkerhet?
Skannere leser filer i etterkant: et manifest, en lockfile, kildekode eller en ferdig binærfil. CRACI er runneren for GitHub Actions-jobbene dine, så den observerer bygget mens det skjer og registrerer pakkene hver jobb faktisk hentet inn, inkludert pakker gjenopprettet fra CI-cacher. Hver SBOM oppgir sin egen fullstendighet, en egress-policy styrer hva bygget kan nå, og API-et returnerer SBOM-er, nettverksspor og provenance.
Erstatter CRACI GitHub Actions-workflowene mine?
Nei. CRACI erstatter runneren, ikke GitHub Actions. Du endrer runs-on til craci, og workflowene, triggerne og kjørehistorikken din blir værende i GitHub.
Hvilke CI-systemer og plattformer støtter CRACI?
GitHub Actions i dag; andre CI-systemer står på veikartet, blant dem GitLab CI og Jenkins. Runnerne er Linux på x86-64 og ARM64, med Windows og macOS på veikartet.
Gjør CRACI SAST, skanning etter hemmeligheter eller reachability-analyse?
Nei. CRACI registrerer og styrer bygget, sporer sårbarheter i det du har levert, og produserer dokumentasjonen. Å skanne din egen kode etter feil eller hemmeligheter, og reachability-analyse, er oppgaver for et verktøy for applikasjonssikkerhet.
Hvor lagres byggedataene mine?
CRACI driftes i Europa, på europeisk bare metal-infrastruktur, og data oppbevares i 180 dager som standard, med tilpasset oppbevaringstid på Enterprise. CRACI lagrer ikke kildekoden din. CRACI er ISO 27001-sertifisert; detaljene finner du i Trust Center.
Se hva byggene dine faktisk henter inn
Book en demo og se SBOM-en, nettverkssporet, egress-policyen og provenance-dataene CRACI registrerer for et GitHub Actions-bygg
Book en demo