Værktøjer og platforme til forsyningskædesikkerhed for software (2026)

Hvem denne side er til

Du har et mandat om at "sikre vores softwareforsyningskæde" og skal beslutte, hvor budgettet skal hen. Værktøjerne nedenfor arbejder forskellige steder: på tværs af dine repositories og pipelines, på build-runneren, ved pakke-registriet eller på det færdige artefakt. Vi bygger CRACI, som konkurrerer direkte i denne kategori, så tag det med i vurderingen. Vi beskriver hvert værktøj ud fra dets egen dokumentation og siger, hvor et andet værktøj passer bedre.

Hvad er forsyningskædesikkerhed for software?

Den fulde guide finder du i hvad er forsyningskædesikkerhed for software og tjeklisten med bedste praksis.

Din software er din egen kode plus alt, hvad den afhænger af: open source-pakker, base-images, build-værktøjer, CI-actions fra tredjeparter og den pipeline, der gør dem til en release. Forsyningskædesikkerhed for software er arbejdet med at vide, hvad de dele er, styre, hvor de kommer fra, og bevise, hvad der gik ind i hver release. Applikationssikkerhed leder efter fejl i den kode, du skriver; forsyningskædesikkerhed dækker det, der omgiver den.

Angribere går efter hvert led. Tre nylige hændelser viser hvor:

• En afhængighed. I marts 2024 blev der fundet ondsindet kode i version 5.6.0 og 5.6.1 af xz utils, et komprimeringsbibliotek, der leveres i Linux-distributioner (CVE-2024-3094).
• CI-pipelinen. I marts 2025 blev GitHub-actionen tj-actions/changed-files kompromitteret (CVE-2025-30066), hvilket eksponerede secrets som adgangsnøgler, personlige GitHub-adgangstokens og npm-tokens fra de workflows, der brugte den.
• Pakke-registriet. I september 2025 kompromitterede den selvreplikerende Shai-Hulud-orm mere end 500 npm-pakker. Den stjal udvikleres legitimationsoplysninger, herunder GitHub-tokens og cloud-nøgler, og brugte dem til at udgive flere inficerede pakker.

1:53

Hvilke typer værktøjer til forsyningskædesikkerhed findes der?

Intet enkelt produkt dækker hvert led, og leverandørerne nedenfor mener forskellige ting med "forsyningskædesikkerhed". De fleste løsninger hører til én af syv typer, defineret ud fra, hvor de arbejder.

Hvordan vælger du en platform til forsyningskædesikkerhed?

Start med det spørgsmål, du ikke kan besvare i dag, og vælg derefter det værktøj, der arbejder dér, hvor svaret ligger. Seks spørgsmål sorterer hurtigt i mulighederne.

• Har du brug for bredde eller dybde? En platform til application security posture management (ASPM) forbinder sig til dine repositories, pipelines og scannere og prioriterer risiko på tværs af dem alle. Et værktøj på build-niveau går dybere på ét punkt: hvad der skete, mens softwaren blev bygget.
• Vil du beholde dine runnere? Agenter som StepSecurity Harden-Runner og Cycodes Cimon tilføjer overvågning til runnere, du allerede bruger. CRACI erstatter runneren for GitHub Actions.
• Ligger risikoen i dine input? Bekymrer du dig mest om ondsindede pakker eller base-images fulde af CVE'er, går værktøjer, der screener eller hærder input, direkte efter det.
• Leverer du software, du ikke selv har bygget? Kun binæranalyse kan se ind i en pakke uden dens build.
• Hvilke CI-systemer kører du? De fleste værktøjer her dækker flere. CRACI understøtter kun GitHub Actions i dag, med GitLab CI og Jenkins på roadmappen.
• Hvad skal du bevise, og over for hvem? Kunder, revisorer og regler som EU's Cyber Resilience Act beder i stigende grad om en SBOM pr. release og en registrering af, hvordan sårbarheder blev håndteret. Et dashboard med fund er ikke det samme som dokumentation for det leverede.

Stil derefter hver leverandør på din shortlist de samme spørgsmål:

• Hvor kommer jeres komponentliste fra: manifester, kildekodeanalyse, buildet eller den færdige binærfil?
• Fortæller SBOM'en mig, når den er ufuldstændig, og eksporteres den som CycloneDX eller SPDX?
• Kan I forhindre et build i at nå en uventet host, eller kun rapportere det bagefter?
• Kan jeg senere verificere, at det artefakt, jeg udruller, er det, der blev bygget?
• Hvilke versionsstyrings- og CI-systemer understøtter I i dag, og hvilke er på roadmappen?
• Hvad er prisenheden: udviklere, bidragydere, images, builds eller et tilbud?

Hvordan klarer værktøjerne sig i forhold til hinanden?

Værktøjerne er af to slags, så der er to tabeller. Den første sammenligner platforme og build-sikkerhedsværktøjer på, hvordan de ser og styrer pipelinen. Den anden sammenligner værktøjer, der arbejder på input og output. "Ikke oplyst" betyder, at de leverandørsider, vi henviser til, ikke siger noget om det.

Platforme og build-sikkerhed

Input og output

Hvad koster værktøjer til forsyningskædesikkerhed?

Fem af de ni værktøjer nedenfor prissætter pr. udvikler, og de fleste sælger betalte planer gennem et salgsteam. CRACI tager i stedet kun betaling for build-minutter, så omkostningen følger, hvor meget du bygger, og ikke hvor mange der committer. Priserne er, som hver leverandør offentliggjorde dem i september 2026; Apiiro og Legit Security er udeladt, fordi deres sider ikke angiver priser.

Priser pr. udvikler vokser med dit team; priser pr. build-minut vokser med dine pipelines. CRACI's pris inkluderer runner-minutterne, som erstatter det, du betaler for GitHub-hostede runnere. Se CRACI's priser og runner-priser sammenlignet. Diagrammer over de offentliggjorte priser efter teamstørrelse, med runneren inkluderet, finder du i priser på forsyningskædesikkerhed sammenlignet.

CRACI

CRACI er en runner til GitHub Actions. Du ændrer runs-on til craci, og mens hvert job kører, registrerer en pakkebevidst proxy, hvad det hentede, inklusive pakker gendannet fra CI-caches. Hver SBOM har en fuldstændighedsstatus pr. job og pr. cache, en egress-politik valideres, før jobbet starter, og blokerer ved fejl, og CRACI bliver ved med at genvurdere SBOM'erne for det leverede. Bedst til teams, der leverer software og skal vise, hvad der gik ind i hver release. Vær opmærksom på: ingen SAST, secrets- eller IaC-scanning, posture-tjek eller binæranalyse og kun GitHub Actions i dag (GitLab CI og Jenkins er på roadmappen). SBOM-generering under buildet

Platforme og ASPM

Apiiro

Apiiro er en ASPM-platform. Deep Code Analysis kortlægger din arkitektur fra kode til runtime, og Risk Graph korrelerer fund fra Apiiros egne scannere og tredjepartsværktøjer til "toxic combinations". Dets forsyningskædemodul laver en fortegnelse over repositories og pipelines, herunder shadow pipelines, og markerer svag branch-beskyttelse og unormale commits. Det kobler sig på via API'er og kræver ingen ændringer i CI. Bedst til store AppSec-programmer, der vil have arkitekturkontekst på tværs af mange versionsstyringssystemer. Vær opmærksom på: Dets fortegnelse kommer fra analyse af kode, ikke fra observation af builds, og det styrer ikke, hvad et build kan nå. CRACI vs Apiiro

Cycode

Cycode er en ASPM-platform med SAST, SCA, scanning af secrets, containere og IaC, CI/CD-posture og mere end 100 connectors. Dets build-del, Cimon, er en eBPF-agent, der kører inde i dine CI-jobs. Den overvåger processer, netværks-egress og filadgang, lærer en pipelines normale adfærd, før den håndhæver den, producerer en SBOM observeret under kørsel og signerer SLSA-provenance. Cycode siger, at Cimon er gratis og open source. Bedst til én platform på tværs af kode og mange CI-systemer, med beskyttelse af builds under kørsel på runnere, du beholder. Vær opmærksom på: Cimon er en agent, der føjes til dine runnere, ikke selve runneren. CRACI vs Cycode

OX Security

OX Security er en ASPM-platform med egne scannere, samling af tredjepartsfund fra værktøjer som Checkmarx, Snyk og Black Duck samt CI/CD-posture-politikker, der markerer actions uden fastlåsning, for brede workflow-rettigheder og risikable webhooks. Dets Pipeline Bill of Materials (PBOM) er en signeret registrering pr. build af pipeline-definitioner, runner-identitet, build-argumenter og artefaktsignaturer. Bedst til posture-politikker og gating af pull requests på tværs af GitHub Actions, GitLab, Jenkins, Azure Pipelines og CircleCI. Vær opmærksom på: Dets SBOM indsamles fra tilsluttede kilder, og dets politikker tjekker pipeline-konfiguration i stedet for at begrænse, hvad et kørende job kan nå. CRACI vs OX Security og Alternativer til OX Security

Legit Security

Legit Security kortlægger hele din udviklingslivscyklus: en løbende opdateret fortegnelse over SDLC-systemer, pipelines og sikkerhedskontrollerne på dem, med hundredvis af politikker på tværs af versionsstyring, CI og registries. Det orkestrerer scannere som Snyk, Checkmarx og GitHub Advanced Security, tilføjer indbygget SAST og SCA, finder secrets i build-logs, Slack og Confluence samt i kode og opretter SBOM'er og signerede attestationer. Bedst til et sikkerhedsteam, der har arvet mange repositories og flere CI-systemer og har brug for ét governance-lag. Vær opmærksom på: Det læser konfiguration og scanneroutput via API'er, så det ser ikke et jobs netværkstrafik, mens det kører. CRACI vs Legit Security og Alternativer til Legit Security

Kusari

Kusari kommer fra teamet, der var med til at skabe GUAC, OpenSSF's graf til metadata om forsyningskæden. Dets platform bygger en vidensgraf ud fra dine SBOM'er, VEX-dokumenter og scanneroutput, viser blast radius for en ny sårbarhed, analyserer reachability og åbner AutoFix-pull requests, som den validerer først. Kusari Inspector gennemgår pull requests for ondsindede pakker, secrets og usikre workflows, og Kusari siger, at det er gratis at installere. Bedst til én graf på tværs af mange SBOM-kilder og scannere. Vær opmærksom på: En graf afspejler de SBOM'er, den bliver fodret med, og Kusaris kommer fra en generator (dets waybill-værktøjssæt eller dit eget værktøj) og ikke fra buildet. CRACI vs Kusari og Alternativer til Kusari

Endor Labs

Endor Labs er bygget op om reachability på funktionsniveau: Statisk programanalyse sporer, om din kode kan kalde en sårbar funktion i en direkte eller transitiv afhængighed, hvilket ifølge Endor Labs reducerer SCA-fund med 92 %. Analyse af opgraderingers konsekvenser, automatiserede pull requests og Endor Patches, der backporter rettelser til den version, du kører, håndterer afhjælpningen. Det dækker også AI SAST, secrets, containere, en Package Firewall foran dine registries og en SBOM Hub med reachability-baseret VEX. Bedst til teams, hvis hovedproblem er mængden af alarmer. Vær opmærksom på: Dets fortegnelse kommer fra analyse af kildekode, og det hverken kører eller begrænser dine builds. CRACI vs Endor Labs

Build- og runner-sikkerhed

StepSecurity

StepSecurity Harden-Runner er det tætteste overlap, CRACI har med nogen sikkerhedsleverandør. Det er en agent på de GitHub Actions-runnere, du allerede bruger, inklusive GitHub-hostede, og den knytter hver udgående forbindelse, proces og filskrivning til det workflow-trin, der forårsagede den. Den kan først auditere og bygge en baseline pr. job og derefter blokere egress til alt uden for en tilladelsesliste. StepSecurity sælger også Secure Registry, pull requests til hærdning af repositories og Dev Machine Guard. Bedst til teams, der vil beholde GitHub-hostede eller selvhostede runnere, eller som kører GitLab CI eller Azure DevOps. Vær opmærksom på: Dens tilladelsesliste er en liste over endpoints, og den registrerer destinationer i stedet for en SBOM på pakkeniveau. CRACI vs StepSecurity

Sikkerhed for pakker og input

Socket

Socket analyserer, hvordan open source-pakker opfører sig: install-scripts, netværks- og filsystemadgang, obfuskeret kode, kendt malware og typosquats. Det markerer risikable tilføjelser i pull requests, og Socket Firewall blokerer ondsindede pakker ved installation, med en gratis version til npm, yarn, pnpm, pip, uv og cargo. Det tilbyder også reachability-analyse. Bedst til at stoppe dårlige pakker, før de lander, også dem uden en advisory endnu. Vær opmærksom på: Det læser de manifester og lockfiles, et projekt deklarerer, og dets firewall filtrerer pakkeinstallationer, ikke resten af et jobs netværkstrafik. CRACI vs Socket

Chainguard

Chainguard bygger open source-software fra kildekoden og leverer den hærdet: container-images, det kalder zero-CVE, Java-, Python- og JavaScript-biblioteker genopbygget fra verificeret kildekode, VM-images og hærdede GitHub Actions, hver med en signeret SBOM og SLSA-provenance. For kunder med en ordre forpligter det sig til at afhjælpe kritiske CVE'er inden for 7 dage og andre alvorlighedsgrader inden for 14 dage efter en kvalificerende patch. Bedst til teams, hvis scannere bliver ved med at markere CVE'er i base-images. Vær opmærksom på: Dets SBOM'er og provenance beskriver Chainguards artefakter. Dit eget build har stadig brug for sin egen registrering, og derfor passer det godt sammen med et værktøj på build-niveau. CRACI og Chainguard

Binæranalyse

ReversingLabs

ReversingLabs Spectra Assure analyserer færdige softwarepakker uden kildekode ved hjælp af statisk binæranalyse, 16 motorer til malwaredetektion og differentiel analyse, der markerer mistænkelige ændringer mellem versioner. Det eksporterer CycloneDX- og SPDX-SBOM'er fra binærfilen og kan vurdere kommerciel software og tredjepartssoftware, før du udruller den. Bedst til en release-gate mod malware og manipulation og til software, du ikke selv har bygget. Vær opmærksom på: Det arbejder baglæns fra outputtet, så det ser ikke build-værktøjer eller testafhængigheder, som buildet hentede, men ikke leverede. CRACI vs ReversingLabs

Rammeværker og regler bag kategorien

Meget af efterspørgslen efter disse værktøjer kommer fra rammeværker og regler, der kræver en fortegnelse over komponenter, en registrering af, hvordan software blev bygget, og en proces for håndtering af sårbarheder.

• SLSA (Supply-chain Levels for Software Artifacts) er et sæt retningslinjer, der kan indføres gradvist, og som vedligeholdes som et samarbejde på tværs af brancher under Linux Foundation. Dets Build-track vurderer, hvor troværdig et builds provenance er.
• NIST SSDF (SP 800-218, version 1.1, februar 2022) fastlægger praksis for sikker softwareudvikling for at reducere sårbarheder i udgivet software.
• US Executive Order 14028, afsnit 4(e), påbød vejledning om softwareforsyningskæden, der omfatter at give en køber en SBOM for hvert produkt. Den former føderal indkøbsvejledning snarere end at binde hver leverandør direkte.
• CISA, NSA og ODNI offentliggjorde "Securing the Software Supply Chain: Recommended Practices Guide for Customers" i 2023, der dækker indkøb, test, udrulning, patching og SBOM'er.
• EU's Cyber Resilience Act (forordning (EU) 2024/2847) sætter sine rapporteringsforpligtelser i kraft den 11. september 2026 og gælder fuldt ud fra 11. december 2027.
• NIS2 artikel 21, stk. 2, nævner forsyningskædesikkerhed og håndtering af sårbarheder blandt de foranstaltninger, det kræver, og US FDA kræver en SBOM fra producenter af cyberenheder.

Ingen af disse rammeværker nævner en produktkategori. Det, de har til fælles, er dokumentation: en præcis komponentliste pr. release, en registrering af, hvordan den blev bygget, og bevis for, at sårbarheder blev sporet.

Hvor passer CRACI ind?

CRACI er en runner til GitHub Actions. Du ændrer runs-on til craci, og mens hvert job kører, registrerer en pakkebevidst proxy, hvad det hentede, inklusive pakker gendannet fra CI-caches. Hver SBOM har en fuldstændighedsstatus pr. job og pr. cache. En egress-politik, default deny eller default allow, valideres, før jobbet starter, og blokerer ved fejl. CRACI bliver ved med at genvurdere SBOM'erne for det leverede. CRACI's inventaroversigt viser præcis, hvilke softwareversioner der er udrullet til hvilke produkter, globalt. Resultatet er en SBOM pr. build, en registrering af, hvad hvert build nåede, og provenance-data fra API'et, hvilket automatiserer en væsentlig del af den synlighed i og dokumentation for forsyningskæden, som din CRA-proces har brug for.

CRACI er ikke det rigtige valg, hvis du har brug for SAST, secrets- eller IaC-scanning, posture-tjek på tværs af dine repositories, en audit-tilstand før blokering, blokeringslister for pakker (på roadmappen), binæranalyse eller andre CI-systemer end GitHub Actions i dag (GitLab CI og Jenkins er på roadmappen). Mange teams kombinerer det med et værktøj ovenfor: en ASPM-platform til kode og posture, Socket eller Chainguard til input, ReversingLabs til output. Læs mere om SBOM-generering under buildet, CI/CD-integration og priser, eller book en demo for at se et registreret build fra start til slut.

Sammenlign værktøjer for hver del af forsyningskæden

Denne side er overblikket. Hvert område har sin egen dybere sammenligning og sine egne guider.

• SBOM'er: SBOM-værktøjer sammenlignet, SBOM-generering under buildet, derfor SBOM'er fra buildet og sådan genererer du en SBOM i GitHub Actions.
• Runnere og CI/CD-sikkerhed: udbydere af GitHub Actions-runnere, værktøjer til runner-sikkerhed, sikkerhedstjekliste til CI/CD-pipelines og egress-politik til GitHub Actions.
• Afhængigheder: SCA-værktøjer sammenlignet og transitive afhængigheder forklaret og hvad software composition analysis er.
• Regulering: Værktøjer til CRA-compliance.
• Derfor buildet: derfor hører forsyningskædesikkerhed hjemme i CI og forsyningskædesikkerhed for software med CRACI og derfor har intern software og software med lav risiko også brug for det.

CRACI sammenlignet med hvert værktøj

• CRACI vs. Apiiro En risikograf fra koden over for dokumentation fra buildet.
• CRACI vs. Cycode ASPM plus en build-agent over for selve build-runneren.
• CRACI vs. OX Security PBOM fra tilsluttede værktøjer over for en registrering fra runneren.
• CRACI vs. Legit Security Sikring af SDLC'en over for registrering af buildet.
• CRACI vs. Kusari En forsyningskædegraf over for build-SBOM'er med overvågning.
• CRACI vs. ReversingLabs Binæranalyse af outputtet over for dokumentation fra buildet.
• CRACI vs. Socket Analyse af pakkers adfærd over for observation af buildet.
• CRACI vs. Chainguard Sikre input over for et sikkert, registreret build.
• CRACI vs. Xygeni En AppSec-platform med build-attestationer over for at være build-runneren.
• CRACI vs. Wiz Fund om workflowets sikkerhedstilstand over for håndhævelse inde i jobbet.
• CRACI vs. Safeguard Scanning og automatisk AI-rettelse over for registrering af selve buildet.

Forsyningskædesikkerhed for software: ofte stillede spørgsmål

Korte svar på de spørgsmål, købere stiller oftest

Hvad er løsninger til forsyningskædesikkerhed for software?

Værktøjer, der beskytter alt, hvad der går ind i din software mellem det første commit og releasen: open source-afhængigheder, base-images, build-værktøjer, CI-pipelines og de artefakter, du leverer. De vigtigste typer er ASPM-platforme, der kortlægger risiko på tværs af udviklingslivscyklussen, software composition analysis for afhængigheder, build- og runner-sikkerhed, pakke-firewalls, hærdede images, binæranalyse samt værktøjer til SBOM og provenance.

Hvad er den bedste platform til forsyningskædesikkerhed for software?

Der findes ikke én bedste, fordi hver dækker sit eget led. ASPM-platforme som Apiiro, Cycode, OX Security og Legit Security er stærkest på bredde på tværs af repositories og CI-systemer. Endor Labs fokuserer på reachability for fund i afhængigheder, Socket på ondsindede pakker, Chainguard på hærdede input og ReversingLabs på færdige binærfiler. CRACI er valget, når du har brug for en registrering af, hvad hvert GitHub Actions-build faktisk trak ind, med egress-kontrol og provenance-data.

Hvordan adskiller forsyningskædesikkerhed sig fra applikationssikkerhed?

Applikationssikkerhed leder efter fejl i den kode, dit team skriver, med værktøjer som SAST og DAST. Forsyningskædesikkerhed for software dækker det, der omgiver den kode: tredjepartskomponenter, build-systemet, CI-pipelinen og vejen fra build til release. Bagdøren i xz utils, kompromitteringen af tj-actions/changed-files og npm-ormen Shai-Hulud kom alle ind gennem forsyningskæden, ikke gennem en fejl i ofrenes egen kode.

Hvilket værktøj til forsyningskædesikkerhed skal jeg starte med?

Start med det spørgsmål, du ikke kan besvare i dag. Ved du ikke, hvilke sårbare afhængigheder du leverer, så start med SCA. Bekymrer ondsindede pakker dig mest, så kig på en pakke-firewall. Skal du bevise, hvad der gik ind i hver release, over for kunder eller EU's Cyber Resilience Act, har du brug for en registrering foretaget under buildet. Store programmer med mange repositories og CI-systemer tilføjer ofte en ASPM-platform ovenpå.

Har jeg brug for en SBOM til forsyningskædesikkerhed?

I stigende grad ja. EU's Cyber Resilience Act kræver, at producenter identificerer komponenterne i deres produkter, blandt andet ved at udarbejde en SBOM, og håndterer deres sårbarheder. Den amerikanske FDA kræver en SBOM for cyberenheder, og US Executive Order 14028 har formet føderal vejledning, der beder leverandører om en. En SBOM er kun så nyttig, som den er komplet, så spørg hver leverandør, hvor komponentlisten kommer fra, og om den fortæller dig, når listen er ufuldstændig.

Hvordan adskiller CRACI sig fra en scanner til forsyningskædesikkerhed?

Scannere læser filer bagefter: et manifest, en lockfile, kildekode eller en færdig binærfil. CRACI er en registrator. Det er runneren for dine GitHub Actions-jobs, og mens hvert job kører, registrerer det de pakker, jobbet faktisk trak ind, inklusive pakker gendannet fra CI-caches. Hver SBOM angiver sin egen fuldstændighed, en egress-politik styrer, hvad buildet kan nå, og API'et returnerer SBOM'er, netværkstraces og provenance.

Hvilke CI-systemer understøtter CRACI?

GitHub Actions i dag; andre CI-systemer er på roadmappen, blandt dem GitLab CI og Jenkins. Runnere er Linux på x86-64 og ARM64, med Windows og macOS på roadmappen. De fleste platforme på denne side dækker flere CI-systemer, så tag det med i vurderingen, hvis du også kører Jenkins eller Azure Pipelines.

Hvad koster værktøjer til forsyningskædesikkerhed?

De fleste tager betaling pr. udvikler. Pr. september 2026 koster StepSecurity Enterprise $16 pr. bidragende udvikler pr. måned, og Socket Team koster $25 pr. udvikler pr. måned, mens Cycode, OX Security og Endor Labs sælger betalte planer gennem deres salgsteam. ReversingLabs Community+ koster fast $500 pr. måned, Chainguard tilbyder op til fem images gratis, og CRACI tager kun betaling for build-minutter, $0.002 pr. vCPU-minut ($0.004 for en standardrunner med 2 vCPU), uden månedligt gebyr.