Säkerhetsverktyg för CI/CD i jämförelse

Varje jämförelse visar vad den andra produkten gör bra, var CRACI skiljer sig och när du skulle använda båda. För alla kategorier, se alla jämförelser.

Därför behöver pipelinen egna säkerhetsverktyg

En CI/CD-pipeline innehåller inloggningsuppgifter, hämtar kod från internet och producerar artefakterna som dina kunder kör. Det gör den till ett mål i sig. En angripare som kan ändra vad ett bygge laddar ner, eller vad det producerar, behöver inte röra din källkod alls. Kodskannrar byggdes inte för det, eftersom de läser repot, inte bygget.

Säkerhetsverktyg för CI/CD täpper till den luckan från olika håll. Vissa kontrollerar hur pipelinen är konfigurerad, vissa bevakar vad som händer på runnern medan ett jobb körs, och vissa styr själva runnern. Att veta vilken grupp ett verktyg tillhör säger mer än dess funktionslista, eftersom det avgör vad verktyget kan se och vad det kan stoppa.

Typer av säkerhetsverktyg för CI/CD

Skannrar som läser din kod

Statisk analys (SAST), skanning av hemligheter och software composition analysis (SCA) läser repot: källfiler, manifest och lockfiler. GitHub Advanced Security kombinerar till exempel kodskanning med CodeQL, skanning av hemligheter och push protection samt Dependabot-varningar från GitHub Advisory Database. De här verktygen hittar problem innan ett bygge körs. De ser inte vad bygget faktiskt hämtade eller vad det anslöt till.

Verktyg som härdar pipelinen runt bygget

Verktyg för säkerhetsläge och styrning kontrollerar pipelinens konfiguration. Cycode bevakar säkerhetspolicyer, konfigurationer och styrning för CI/CD. StepSecurity har en inventering av de tredjepartsactions du använder, med godkännandeflöden för nya, och öppnar pull requests som låser actions till commit-SHA:er och sätter GITHUB_TOKEN-behörigheter enligt minsta privilegium. De här verktygen gör pipelinen svårare att missbruka, men de arbetar med definitionen av bygget snarare än med bygget medan det körs.

Agenter som bevakar runnern

Runtime-agenter körs inne i jobbet på runners du behåller. StepSecurity Harden-Runner bevakar utgående anslutningar, processer och filskrivningar, kopplar var och en till arbetsflödessteget som orsakade den och kan blockera utgående trafik utanför en tillåtelselista. Cycodes Cimon bevakar processkörning, utgående nätverkstrafik och filåtkomst på kärnnivå med eBPF, tar fram en SBOM observerad under körning och signerar SLSA-proveniens. Agenter fungerar i många CI-system och på hostade runners, eftersom de läggs till i infrastruktur som redan finns.

Runners som styr och registrerar bygget

CRACI tar den sista vägen: det ersätter runnern. Jobb körs på CRACI med runs-on: craci, och körningar syns fortfarande i GitHub. Egress-policyn är en del av runnern, valideras innan jobbet startar och blockerar vid fel. En paketmedveten proxy registrerar varje paket som jobbet hämtade, inklusive paket som återställs från CI-cachar, så varje jobb tar fram en SBOM med en fullständighetsstatus, en nätverksspårning och proveniensdata.

Sida vid sida

"Ej angivet" betyder att vi inte kunde bekräfta det på leverantörens offentliga sidor. För detaljerna bakom varje kolumn, se CRACI vs StepSecurity, CRACI vs Cycode och CRACI vs GitHub Advanced Security.

Vilket verktyg täcker vilken CI/CD-risk

OWASP Top 10 CI/CD Security Risks är den mest använda listan över vad som kan gå fel i en pipeline. Dess tio risker är:

1. CICD-SEC-1: Insufficient Flow Control Mechanisms
2. CICD-SEC-2: Inadequate Identity and Access Management
3. CICD-SEC-3: Dependency Chain Abuse
4. CICD-SEC-4: Poisoned Pipeline Execution (PPE)
5. CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)
6. CICD-SEC-6: Insufficient Credential Hygiene
7. CICD-SEC-7: Insecure System Configuration
8. CICD-SEC-8: Ungoverned Usage of 3rd Party Services
9. CICD-SEC-9: Improper Artifact Integrity Validation
10. CICD-SEC-10: Insufficient Logging and Visibility

Inget enskilt verktyg täcker alla tio. Det här är de fyra där CRACI:s kontroller gäller:

För CICD-SEC-7 täcker CRACI runnern. Konfigurationen av dina repon och din GitHub-organisation ligger kvar hos dig. För att vara tydlig med resten: CRACI omfattar inte identitets- och åtkomsthantering (CICD-SEC-2) eller hygien för inloggningsuppgifter (CICD-SEC-6), och det styr inte flödeskontroll, pipelinebehörigheter eller tredjepartstjänster (CICD-SEC-1, 5 och 8). Skanning av hemligheter, som GitHubs Secret Protection eller Cycodes upptäckt av hemligheter, och verktygen för säkerhetsläge ovan är byggda för det.

Så väljer du ett säkerhetsverktyg för CI/CD

• Ersätta dina runners eller behålla dem. Om du vill behålla GitHub-hostade runners, egenhostade runners eller ett annat CI-system är en agent sättet att lägga till kontroller under körning. Om du är öppen för att byta runner ger en runner som CRACI egress-kontroll och en registrering av bygget utan någon agent att driftsätta.
• Granskningsläge i dag. Harden-Runner och Cimon kan bevaka trafik innan de blockerar något. CRACI:s övervaknings- eller torrkörningsläge finns på dess roadmap.
• Forensik på processnivå. Om du under en incident behöver veta vilken process som skrev vilken fil täcker en agent som bevakar processer och filer det. CRACI bevakar inte processer eller filskrivningar.
• SBOM och CRA-bevis. Om du behöver en SBOM på paketnivå för varje bygge, proveniens och bevis för Cyber Resilience Act, titta på vad varje verktyg registrerar och om det fortsätter att bevaka det som levererats. CRACI registrerar SBOM:en medan bygget körs, omvärderar bevakade SBOM:er när nya sårbarheter dyker upp och exporterar SBOM:er som CycloneDX eller SPDX.
• CI-plattformar och operativsystem. CRACI har i dag stöd för GitHub Actions, med GitLab CI och Jenkins på roadmapen, och kör Linux på x86-64 och ARM64, med Windows och macOS på roadmapen. Om du bygger på andra CI-system eller behöver Windows- eller macOS-runners nu, kontrollera först agenternas täckning.
• Kod och hemligheter. Skannrar för källkod och hemligheter täcker det ingen runner gör. CRACI har ingen SAST eller skanning av hemligheter, så planera för dem separat.

En agent på runnern eller att vara runnern

En agent läggs till i infrastruktur som någon annan har utformat. På GitHub-hostade runners installeras den av ett steg i början av varje jobb, och dess räckvidd beror på vad den infrastrukturen tillåter. Det är därför agenter kan täcka hostade runners, egenhostade flottor och flera CI-system samtidigt, och det är en verklig fördel när dina byggen är utspridda över dem alla.

En runner som själv upprätthåller policyn fungerar tvärtom. På CRACI valideras egress-policyn innan jobbet startar, avvisar okända fält och blockerar vid fel, så en policy som inte kan tillämpas ger ingen oskyddad körning. Dess källor är typade per ekosystem, med 24 inbyggda förinställningar för programvarukällor och anpassade källor för npm, PyPI, apt, apk, Go-proxyn, Nix, Cargo, OCI-register och Git, så registreringen gäller paket, inte bara värdar. På jobb som körs på CRACI ersätter det runtime-agenter i stället för att köras bredvid dem. Läs mer om CI/CD-integration och SBOM-generering under bygget, eller boka en demo för att se ett GitHub Actions-jobb köras under en egress-policy.

CRACI jämfört med varje verktyg

• CRACI jämfört med StepSecurity En agent på din runner jämfört med att vara runnern.

Sida vid sida

Flera verktyg på en sida, för när du väljer en kategori, inte en enskild produkt.

• Verktyg för säkerhet i mjukvarans leveranskedja jämförda Apiiro, Cycode, OX, Legit, Socket, Chainguard, StepSecurity med flera.

Andra kategorier

• CI/CD-plattformar och runners
• Software composition analysis
• Säkerhet i mjukvarans leveranskedja
• SBOM-hantering
• CRA-efterlevnad
• Inbyggda system och produktsäkerhet
• PSIRT och produktsäkerhet
• Öppen källkod och gör det själv
• AI och säkerhet