Verktøy og plattformer for sikkerhet i programvareleverandørkjeden (2026)

Hvem denne siden er for

Du har fått oppdraget med å "sikre programvareleverandørkjeden vår" og må bestemme hvor budsjettet skal gå. Verktøyene nedenfor virker på ulike punkter: på tvers av repositoriene og pipelinene dine, på byggerunneren, ved pakkeregisteret eller på den ferdige artefakten. Vi lager CRACI, som konkurrerer direkte i denne kategorien, så ta det med i vurderingen. Vi beskriver hvert verktøy ut fra verktøyets egen dokumentasjon og sier hvor et annet verktøy passer bedre.

Hva er sikkerhet i programvareleverandørkjeden?

Hele guiden finner du i hva er sikkerhet i programvareleverandørkjeden og sjekklisten med beste praksis.

Programvaren din er din egen kode pluss alt den er avhengig av: pakker med åpen kildekode, base-images, byggeverktøy, CI-actions fra tredjeparter og pipelinen som gjør dem om til en utgivelse. Sikkerhet i programvareleverandørkjeden er arbeidet med å vite hva disse delene er, styre hvor de kommer fra, og bevise hva som gikk inn i hver utgivelse. Applikasjonssikkerhet ser etter feil i koden du skriver; leverandørkjedesikkerhet dekker det som omgir den.

Angripere går etter hvert ledd. Tre nylige hendelser viser hvor:

• En avhengighet. I mars 2024 ble det funnet ondsinnet kode i versjonene 5.6.0 og 5.6.1 av xz utils, et komprimeringsbibliotek som leveres i Linux-distribusjoner (CVE-2024-3094).
• CI-pipelinen. I mars 2025 ble GitHub Action-en tj-actions/changed-files kompromittert (CVE-2025-30066), og det eksponerte hemmeligheter som tilgangsnøkler, personlige GitHub-tilgangstokens og npm-tokens fra workflowene som brukte den.
• Pakkeregisteret. I september 2025 kompromitterte den selvreplikerende Shai-Hulud-ormen mer enn 500 npm-pakker. Den stjal utvikleres påloggingsinformasjon, inkludert GitHub-tokens og skynøkler, og brukte dem til å publisere flere infiserte pakker.

1:53

Hvilke typer verktøy for sikkerhet i programvareleverandørkjeden finnes?

Ikke noe enkelt produkt dekker hvert ledd, og leverandørene nedenfor mener ulike ting med "leverandørkjedesikkerhet". De fleste løsninger faller inn under en av sju typer, definert av hvor de virker.

Hvordan velger du en plattform for sikkerhet i programvareleverandørkjeden?

Begynn med spørsmålet du ikke kan svare på i dag, og velg deretter verktøyet som virker der svaret ligger. Seks spørsmål skiller alternativene raskt.

• Trenger du bredde eller dybde? En plattform for application security posture management (ASPM) kobles til repositoriene, pipelinene og skannerne dine og prioriterer risiko på tvers av alle. Et verktøy på byggenivå går dypere på ett punkt: hva som skjedde mens programvaren ble bygget.
• Vil du beholde runnerne dine? Agenter som StepSecurity Harden-Runner og Cimon fra Cycode legger til overvåking på runnere du allerede bruker. CRACI erstatter runneren for GitHub Actions.
• Ligger risikoen i det du bygger på? Hvis du er mest bekymret for ondsinnede pakker eller base-images fulle av CVE-er, går verktøy som kontrollerer eller herder innsatsfaktorene rett på problemet.
• Leverer du programvare du ikke har bygget? Bare binæranalyse kan se inn i en pakke uten tilgang til bygget.
• Hvilke CI-systemer kjører du? De fleste verktøyene her dekker flere. CRACI støtter bare GitHub Actions i dag, med GitLab CI og Jenkins på veikartet.
• Hva må du bevise, og overfor hvem? Kunder, revisorer og regelverk som EUs Cyber Resilience Act ber i økende grad om en SBOM per utgivelse og en oversikt over hvordan sårbarheter ble håndtert. Et dashbord med funn er ikke det samme som bevis på hva som ble levert.

Still deretter hver leverandør på kortlisten de samme spørsmålene:

• Hvor kommer komponentlisten deres fra: manifester, kildeanalyse, bygget eller den ferdige binærfilen?
• Sier SBOM-en fra når den er ufullstendig, og eksporteres den som CycloneDX eller SPDX?
• Kan dere hindre et bygg i å nå en uventet vert, eller bare rapportere det i etterkant?
• Kan jeg senere verifisere at artefakten jeg ruller ut, er den som ble bygget?
• Hvilke kildekontroll- og CI-systemer støtter dere i dag, og hvilke står på veikartet?
• Hva er prisenheten: utviklere, bidragsytere, images, bygg eller et tilbud?

Hvordan står verktøyene seg mot hverandre?

Verktøyene faller i to grupper, så det er to tabeller. Den første sammenligner plattformer og verktøy for byggesikkerhet på hvordan de ser og styrer pipelinen. Den andre sammenligner verktøy som virker på det som går inn og ut. "Ikke oppgitt" betyr at leverandørsidene vi viser til, ikke sier noe om det.

Plattformer og byggesikkerhet

Inndata og utdata

Hva koster verktøy for sikkerhet i programvareleverandørkjeden?

Fem av de ni verktøyene nedenfor prises per utvikler, og de fleste tilbyr betalte planer via salg. CRACI tar i stedet bare betalt for byggeminutter, så kostnaden følger hvor mye du bygger, ikke hvor mange som committer. Prisene er slik hver leverandør publiserte dem i september 2026; Apiiro og Legit Security er utelatt fordi sidene deres ikke oppgir priser.

Pris per utvikler vokser med teamet ditt; pris per byggeminutt vokser med pipelinene dine. Prisen til CRACI inkluderer runnerminuttene, som erstatter det du betaler for GitHub-hostede runnere. Se priser for CRACI og runnerpriser sammenlignet. Diagrammer over de publiserte prisene etter teamstørrelse, med runneren inkludert, finner du i priser for sikkerhet i programvareleverandørkjeden sammenlignet.

CRACI

CRACI er en runner for GitHub Actions. Du endrer runs-on til craci, og mens hver jobb kjører, registrerer en pakkebevisst proxy hva den hentet, inkludert pakker gjenopprettet fra CI-cacher. Hver SBOM har en fullstendighetsstatus per jobb og per cache, en egress-policy valideres før jobben starter og blokkerer ved feil, og CRACI fortsetter å revurdere SBOM-ene for det som er levert. Passer best for team som leverer programvare og må vise hva som gikk inn i hver utgivelse. Vær obs på: ingen SAST, skanning av hemmeligheter eller IaC, sjekker av sikkerhetstilstand eller binæranalyse, og bare GitHub Actions i dag (GitLab CI og Jenkins står på veikartet). SBOM-generering under bygget

Plattformer og ASPM

Apiiro

Apiiro er en ASPM-plattform. Deep Code Analysis kartlegger arkitekturen din fra kode til kjøretid, og Risk Graph kobler funn fra Apiiros egne skannere og verktøy fra tredjeparter til "toxic combinations". Leverandørkjedemodulen kartlegger repositorier og pipelines, inkludert skygge-pipelines, og flagger svak grenbeskyttelse og unormale commits. Den kobles til gjennom API-er og krever ingen CI-endringer. Passer best for store AppSec-programmer som vil ha arkitekturkontekst på tvers av mange kildekontrollsystemer. Vær obs på: Oversikten kommer fra analyse av kode, ikke fra observasjon av bygg, og den styrer ikke hva et bygg kan nå. CRACI vs Apiiro

Cycode

Cycode er en ASPM-plattform med skanning av SAST, SCA, hemmeligheter, containere og IaC, CI/CD-sikkerhetstilstand og mer enn 100 konnektorer. Byggedelen, Cimon, er en eBPF-agent som kjører inne i CI-jobbene dine. Den overvåker prosesser, nettverks-egress og filtilgang, lærer seg den normale atferden til en pipeline før den håndheves, produserer en SBOM observert under kjøring og signerer SLSA-provenance. Cycode sier at Cimon er gratis og åpen kildekode. Passer best for én plattform på tvers av kode og mange CI-systemer, med kjøretidsbeskyttelse av bygg på runnere du beholder. Vær obs på: Cimon er en agent som legges til på runnerne dine, ikke selve runneren. CRACI vs Cycode

OX Security

OX Security er en ASPM-plattform med egne skannere, samling av funn fra tredjepartsverktøy som Checkmarx, Snyk og Black Duck, og CI/CD-policyer for sikkerhetstilstand som flagger actions som ikke er festet, for vide workflow-tillatelser og risikable webhooks. Pipeline Bill of Materials (PBOM) er en signert oversikt per bygg over pipeline-definisjoner, runner-identitet, byggeargumenter og artefaktsignaturer. Passer best for policyer for sikkerhetstilstand og sperrer på pull requests på tvers av GitHub Actions, GitLab, Jenkins, Azure Pipelines og CircleCI. Vær obs på: SBOM-en samles inn fra tilkoblede kilder, og policyene sjekker pipeline-konfigurasjon i stedet for å begrense hva en kjørende jobb kan nå. CRACI vs OX Security og OX Security-alternativer

Legit Security

Legit Security kartlegger hele utviklingslivssyklusen din: en kontinuerlig oppdatert oversikt over SDLC-systemer, pipelines og sikkerhetskontrollene på dem, med hundrevis av policyer på tvers av kildekontroll, CI og registre. Det orkestrerer skannere som Snyk, Checkmarx og GitHub Advanced Security, legger til innebygd SAST og SCA, finner hemmeligheter i byggelogger, Slack og Confluence i tillegg til kode, og lager SBOM-er og signerte attestasjoner. Passer best for et sikkerhetsteam som har arvet mange repositorier og flere CI-systemer og trenger ett styringslag. Vær obs på: Det leser konfigurasjon og skannerutdata gjennom API-er, så det ser ikke nettverkstrafikken til en jobb mens den kjører. CRACI vs Legit Security og Legit Security-alternativer

Kusari

Kusari kommer fra teamet som var med på å lage GUAC, OpenSSF-grafen for leverandørkjedemetadata. Plattformen bygger en kunnskapsgraf fra SBOM-ene, VEX-dokumentene og skannerutdataene dine, viser skadeomfanget av en ny sårbarhet, analyserer reachability og åpner AutoFix-pull requests som den validerer først. Kusari Inspector gjennomgår pull requests for ondsinnede pakker, hemmeligheter og usikre workflows, og Kusari sier at det er gratis å installere. Passer best for én graf på tvers av mange SBOM-kilder og skannere. Vær obs på: En graf gjenspeiler SBOM-ene den mates med, og Kusaris kommer fra en generator (verktøysettet waybill eller ditt eget verktøy), ikke fra bygget. CRACI vs Kusari og Kusari-alternativer

Endor Labs

Endor Labs er bygget rundt reachability på funksjonsnivå: Statisk programanalyse sporer om koden din kan kalle en sårbar funksjon i en direkte eller transitiv avhengighet, noe Endor Labs sier kutter SCA-funn med 92 %. Analyse av oppgraderingskonsekvenser, automatiserte pull requests og Endor Patches, som backporter rettinger til versjonen du kjører, håndterer utbedringen. Det dekker også AI SAST, hemmeligheter, containere, en Package Firewall foran registrene dine og en SBOM Hub med reachability-basert VEX. Passer best for team der hovedproblemet er mengden varsler. Vær obs på: Oversikten kommer fra analyse av kildekode, og det verken kjører eller begrenser byggene dine. CRACI vs Endor Labs

Bygge- og runnersikkerhet

StepSecurity

StepSecurity Harden-Runner er den nærmeste overlappingen CRACI har med noen sikkerhetsleverandør. Det er en agent på GitHub Actions-runnerne du allerede bruker, inkludert GitHub-hostede, og den knytter hver utgående tilkobling, prosess og filskriving til workflow-steget som forårsaket den. Den kan revidere først og bygge en baseline per jobb, og deretter blokkere egress til alt utenfor en tillatelsesliste. StepSecurity selger også Secure Registry, pull requests for herding av repositorier og Dev Machine Guard. Passer best for team som vil beholde GitHub-hostede eller selvhostede runnere, eller som kjører GitLab CI eller Azure DevOps. Vær obs på: Tillatelseslisten er en liste over endepunkter, og den registrerer destinasjoner, ikke en SBOM på pakkenivå. CRACI vs StepSecurity

Pakke- og inndatasikkerhet

Socket

Socket analyserer hvordan pakker med åpen kildekode oppfører seg: installasjonsskript, nettverks- og filsystemtilgang, obfuskert kode, kjent skadevare og typosquats. Det flagger risikable tillegg i pull requests, og Socket Firewall blokkerer ondsinnede pakker ved installasjon, med en gratisversjon for npm, yarn, pnpm, pip, uv og cargo. Det tilbyr også reachability-analyse. Passer best for å stoppe dårlige pakker før de lander, også dem som ennå ikke har noen advisory. Vær obs på: Det leser manifestet og lockfilene et prosjekt deklarerer, og brannmuren filtrerer pakkeinstallasjoner, ikke resten av nettverkstrafikken til en jobb. CRACI vs Socket

Chainguard

Chainguard bygger programvare med åpen kildekode fra kilden og leverer den herdet: container-images selskapet kaller zero-CVE, Java-, Python- og JavaScript-biblioteker gjenoppbygd fra verifisert kildekode, VM-images og herdede GitHub Actions, hver med en signert SBOM og SLSA-provenance. For kunder med en bestilling forplikter det seg til å utbedre kritiske CVE-er innen 7 dager og andre alvorlighetsgrader innen 14 dager etter en kvalifiserende patch. Passer best for team der skannerne stadig flagger CVE-er i base-images. Vær obs på: SBOM-ene og provenance beskriver artefaktene til Chainguard. Ditt eget bygg trenger fortsatt sin egen oversikt, og derfor passer Chainguard godt sammen med et verktøy på byggenivå. CRACI og Chainguard

Binæranalyse

ReversingLabs

ReversingLabs Spectra Assure analyserer ferdige programvarepakker uten kildekode, med statisk binæranalyse, 16 motorer for skadevaredeteksjon og differensialanalyse som flagger mistenkelige endringer mellom versjoner. Det eksporterer CycloneDX- og SPDX-SBOM-er fra binærfilen og kan vurdere kommersiell programvare og programvare fra tredjeparter før du ruller den ut. Passer best for en utgivelsessperre mot skadevare og manipulering, og for programvare du ikke har bygget. Vær obs på: Det jobber baklengs fra resultatet, så det ser ikke byggeverktøy eller testavhengigheter bygget hentet, men ikke leverte. CRACI vs ReversingLabs

Rammeverk og regelverk bak kategorien

Mye av etterspørselen etter disse verktøyene kommer fra rammeverk og regler som krever en oversikt over komponenter, en oversikt over hvordan programvaren ble bygget, og en prosess for å håndtere sårbarheter.

• SLSA (Supply-chain Levels for Software Artifacts) er et sett retningslinjer som kan innføres trinnvis, vedlikeholdt som et bransjeovergripende samarbeid under Linux Foundation. Build-sporet graderer hvor pålitelig provenance fra et bygg er.
• NIST SSDF (SP 800-218, versjon 1.1, februar 2022) beskriver praksiser for sikker programvareutvikling for å redusere sårbarheter i utgitt programvare.
• US Executive Order 14028, Section 4(e), påla veiledning for programvareleverandørkjeden som blant annet omfatter å gi en kjøper en SBOM for hvert produkt. Den former føderal veiledning for offentlige anskaffelser i stedet for å binde hver leverandør direkte.
• CISA, NSA og ODNI publiserte "Securing the Software Supply Chain: Recommended Practices Guide for Customers" i 2023, som dekker anskaffelse, testing, utrulling, patching og SBOM-er.
• EUs Cyber Resilience Act (Regulation (EU) 2024/2847) setter rapporteringsforpliktelsene i kraft 11. september 2026 og gjelder fullt ut fra 11. desember 2027.
• NIS2 Article 21(2) nevner leverandørkjedesikkerhet og sårbarhetshåndtering blant tiltakene det krever, og amerikanske FDA krever en SBOM fra produsenter av cyber devices.

Ingen av disse rammeverkene nevner en produktkategori. Det de har til felles, er dokumentasjon: en nøyaktig komponentliste per utgivelse, en oversikt over hvordan den ble bygget, og bevis på at sårbarheter ble fulgt opp.

Hvor passer CRACI inn?

CRACI er en runner for GitHub Actions. Du endrer runs-on til craci, og mens hver jobb kjører, registrerer en pakkebevisst proxy hva den hentet, inkludert pakker gjenopprettet fra CI-cacher. Hver SBOM har en fullstendighetsstatus per jobb og per cache. En egress-policy, standard avvis eller standard tillat, valideres før jobben starter og blokkerer ved feil. CRACI fortsetter å revurdere SBOM-ene for det som er levert. Inventarvisningen i CRACI viser nøyaktig hvilke programvareversjoner som er rullet ut til hvilke produkter, globalt. Resultatet er en SBOM per bygg, en oversikt over hva hvert bygg nådde, og provenance-data fra API-et, noe som automatiserer en betydelig del av innsynet i leverandørkjeden og dokumentasjonen CRA-prosessen din trenger.

CRACI er ikke det riktige valget hvis du trenger SAST, skanning av hemmeligheter eller IaC, sjekker av sikkerhetstilstand på tvers av repositoriene dine, en revisjonsmodus før blokkering, blokkeringslister for pakker (står på veikartet), binæranalyse eller andre CI-systemer enn GitHub Actions i dag (GitLab CI og Jenkins står på veikartet). Mange team kombinerer det med et verktøy over: en ASPM-plattform for kode og sikkerhetstilstand, Socket eller Chainguard for det som går inn, ReversingLabs for det som kommer ut. Les mer om SBOM-generering under bygget, CI/CD-integrasjon og priser, eller book en demo for å se et registrert bygg fra start til slutt.

Sammenlign verktøy for hver del av leverandørkjeden

Denne siden er oversikten. Hvert område har sin egen dypere sammenligning og egne guider.

• SBOM-er: SBOM-verktøy sammenlignet, SBOM-generering under bygget, hvorfor SBOM-er fra bygget og slik genererer du en SBOM i GitHub Actions.
• Runnere og CI/CD-sikkerhet: leverandører av GitHub Actions-runnere, verktøy for runnersikkerhet, sjekkliste for sikkerhet i CI/CD-pipelinen og egress-policy for GitHub Actions.
• Avhengigheter: SCA-verktøy sammenlignet, transitive avhengigheter forklart og hva software composition analysis er.
• Regelverk: verktøy for CRA-samsvar.
• Hvorfor bygget: derfor hører leverandørkjedesikkerhet hjemme i CI og sikkerhet i programvareleverandørkjeden med CRACI, og hvorfor intern programvare og programvare med lav risiko også trenger det.

CRACI sammenlignet med hvert verktøy

• CRACI mot Apiiro Risikograf fra koden mot dokumentasjon fra bygget.
• CRACI mot Cycode ASPM pluss en byggagent mot selve byggrunneren.
• CRACI mot OX Security PBOM fra tilkoblede verktøy mot en registrering fra runneren.
• CRACI mot Legit Security Sikring av SDLC mot registrering av bygget.
• CRACI mot Kusari Leverandørkjedegraf mot SBOM-er fra bygget med overvåking.
• CRACI mot ReversingLabs Binæranalyse av resultatet mot dokumentasjon fra bygget.
• CRACI mot Socket Analyse av pakkeatferd mot observasjon av bygget.
• CRACI mot Chainguard Sikre innsatsfaktorer mot et sikkert, registrert bygg.
• CRACI mot Xygeni AppSec-plattform med byggattestasjoner mot å være byggrunneren.
• CRACI mot Wiz Funn om workflow-oppsettet mot håndheving inne i jobben.
• CRACI mot Safeguard Skanning og automatisk AI-retting mot registrering av selve bygget.

Sikkerhet i programvareleverandørkjeden: ofte stilte spørsmål

Korte svar på spørsmålene kjøpere stiller oftest

Hva er løsninger for sikkerhet i programvareleverandørkjeden?

Verktøy som beskytter alt som går inn i programvaren din mellom første commit og utgivelsen: avhengigheter med åpen kildekode, base-images, byggeverktøy, CI-pipelines og artefaktene du leverer. Hovedtypene er ASPM-plattformer som kartlegger risiko gjennom utviklingslivssyklusen, software composition analysis for avhengigheter, bygg- og runnersikkerhet, pakkebrannmurer, herdede images, binæranalyse og verktøy for SBOM og provenance.

Hva er den beste plattformen for sikkerhet i programvareleverandørkjeden?

Det finnes ikke én beste, fordi hver av dem dekker et eget ledd. ASPM-plattformer som Apiiro, Cycode, OX Security og Legit Security er sterkest på bredde på tvers av repositorier og CI-systemer. Endor Labs fokuserer på reachability for avhengighetsfunn, Socket på ondsinnede pakker, Chainguard på herdede innsatsfaktorer og ReversingLabs på ferdige binærfiler. CRACI er valget når du trenger en oversikt over hva hvert GitHub Actions-bygg faktisk hentet inn, med egress-kontroll og provenance-data.

Hvordan skiller sikkerhet i programvareleverandørkjeden seg fra applikasjonssikkerhet?

Applikasjonssikkerhet ser etter feil i koden teamet ditt skriver, med verktøy som SAST og DAST. Sikkerhet i programvareleverandørkjeden dekker det som omgir den koden: komponenter fra tredjeparter, byggesystemet, CI-pipelinen og veien fra bygg til utgivelse. Bakdøren i xz utils, kompromitteringen av tj-actions/changed-files og npm-ormen Shai-Hulud kom alle inn gjennom leverandørkjeden, ikke gjennom en feil i ofrenes egen kode.

Hvilket verktøy for sikkerhet i programvareleverandørkjeden bør jeg begynne med?

Begynn med spørsmålet du ikke kan svare på i dag. Hvis du ikke vet hvilke sårbare avhengigheter du leverer, begynner du med SCA. Hvis ondsinnede pakker bekymrer deg mest, bør du se på en pakkebrannmur. Hvis du må bevise hva som gikk inn i hver utgivelse, overfor kunder eller for EUs Cyber Resilience Act, trenger du en oversikt tatt under bygget. Store sikkerhetsprogrammer med mange repositorier og CI-systemer legger ofte til en ASPM-plattform på toppen.

Trenger jeg en SBOM for sikkerhet i programvareleverandørkjeden?

I økende grad, ja. EUs Cyber Resilience Act ber produsenter identifisere komponentene i produktene sine, blant annet ved å utarbeide en SBOM, og håndtere sårbarhetene deres. Amerikanske FDA krever en SBOM for cyber devices, og US Executive Order 14028 formet føderal veiledning som ber leverandører om en. En SBOM er bare så nyttig som den er fullstendig, så spør hver leverandør hvor komponentlisten kommer fra, og om den sier fra når listen er ufullstendig.

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 en registrerer. Det er runneren for GitHub Actions-jobbene dine, og mens hver jobb kjører, registrerer det pakkene jobben faktisk hentet inn, inkludert pakker gjenopprettet fra CI-cacher. Hver SBOM angir sin egen fullstendighet, en egress-policy styrer hva bygget kan nå, og API-et returnerer SBOM-er, nettverksspor og provenance.

Hvilke CI-systemer støtter CRACI?

GitHub Actions i dag; andre CI-systemer står på veikartet, blant dem GitLab CI og Jenkins. Runnere er Linux på x86-64 og ARM64, med Windows og macOS på veikartet. De fleste plattformene på denne siden dekker flere CI-systemer, så ta det med i vurderingen hvis du også kjører Jenkins eller Azure Pipelines.

Hva koster verktøy for sikkerhet i programvareleverandørkjeden?

De fleste tar betalt per utvikler. Per september 2026 koster StepSecurity Enterprise $16 per bidragende utvikler per måned og Socket Team $25 per utvikler per måned, mens Cycode, OX Security og Endor Labs tilbyr betalte planer via salg. ReversingLabs Community+ er en fast pris på $500 per måned, Chainguard tilbyr opptil fem images gratis, og CRACI tar bare betalt for byggeminutter, $0.002 per vCPU-minutt ($0.004 for en standard runner med 2 vCPU), uten månedsavgift.