Beste praksis for sikkerhet i programvareleverandørkjeden

Kildekode

• Krev sterk autentisering. Bruk flerfaktorautentisering for hver konto hos kodehostingtjenester.
• Beskytt hovedgrenen. Krev gjennomgang før merge, og ikke la noen pushe rett til en utgivelsesgren.
• Hold hemmeligheter utenfor koden. Skann etter dem ved hver push, og roter alt som har blitt eksponert.
• Behandle workflow-filer som kode. En endring i en pipeline kan nå hemmelighetene dine, så krev at eierne går gjennom dem.

Avhengigheter

• Commit en lockfile og installer fra den. Bruk npm ci og tilsvarende, slik at bygg ikke plukker opp nye versjoner ved et uhell. En lockfile har begrensninger, men det er der du bør begynne.
• Legg inn en venteperiode for nye versjoner. Ondsinnede utgivelser blir ofte oppdaget kort tid etter at de dukker opp, så hvis du ikke tar i bruk en versjon samme dag den publiseres, gir du det en sjanse til å skje.
• Begrens installasjonsskript. Deaktiver dem der du kan. Skript som kjører ved installasjon, er måten npm-ormer sprer seg på.
• Vurder nye avhengigheter. Sjekk navnet for typosquatting, og se på vedlikehold og popularitet. OpenSSF Scorecard automatiserer en del av dette.
• Beskytt interne pakkenavn. Bruk scopes og registerkonfigurasjon, slik at en offentlig pakke ikke kan ta plassen til en intern gjennom dependency confusion.
• Fjern det du ikke trenger. Hver avhengighet er enda en ting å overvåke.

Bygg og CI/CD

• Fest GitHub Actions til en fullstendig commit-hash. Tagger kan flyttes, slik kompromitteringen av tj-actions viste.
• Begrens hva hver jobb kan gjøre. Gi workflow-tokenet bare den tilgangen det trenger, og bruk kortlevde påloggingsdata i stedet for langlivede hemmeligheter.
• Begrens utgående trafikk. Et bygg trenger pakker fra kjente kilder og publiserer til kjente steder. Blokker alt annet, så har stjålne hemmeligheter ingen steder å gå. Se egress-policy for GitHub Actions.
• Kjør hver jobb i et nytt, isolert miljø. Ingenting bør overføres fra én jobb til den neste, minst av alt fra en pull request fra en ekstern bidragsyter.
• Behandle cacher som input. En forgiftet cache overlever mellom bygg, og det den gjenoppretter, er lett å overse. Se GitHub Actions-cache.

Hele listen finner du i sikkerhetssjekklisten for CI/CD-pipelines og sammenligningen av runnersikkerhet.

Utgivelse

• Generer en SBOM for hver utgivelse, fra bygget. Oppbevar den sammen med artefakten. Se beste praksis for SBOM.
• Signer artefakter og publiser provenance. Brukere kan da sjekke hvor en utgivelse kom fra. SLSA beskriver nivåene.
• Bygg utgivelser bare i CI. En utgivelse fra en bærbar maskin har ingen pålitelig dokumentasjon bak seg.
• Bruk én artefakt fra test til produksjon. Flytt det du har testet, videre i stedet for å bygge det på nytt, slik at dokumentasjonen forblir sann.

Etter utgivelse

• Overvåk det du har levert. Fortsett å sjekke SBOM-ene for støttede utgivelser mot nye sårbarheter.
• Prioriter med mer enn CVSS. Bruk CISA KEV, EPSS og kontekst. Se slik prioriterer du sårbarheter.
• Vit hvor lenge du var eksponert. Byggehistorikken viser hvilke utgivelser som inneholdt en pakke, og fra når.
• Ha en plan før du trenger den. Bestem hvem som prioriterer, hvem som retter og hvem som snakker med kundene. Se livssyklusen for sårbarhetshåndtering.
• Øv med et realistisk scenario. Spør hvor lang tid det ville ta å finne hver utgivelse med en gitt pakke. Hvis svaret er dager, begynn der.

Hva du bør gjøre først

Når	Gjør dette
Denne uken	Flerfaktorautentisering, lockfiler i CI, festede GitHub Actions, workflow-tokens med minste privilegium
Denne måneden	SBOM fra hvert utgivelsesbygg, avhengighetsvarsler med en eier, skanning etter hemmeligheter
Dette kvartalet	Regler for utgående trafikk fra bygg, overvåking av leverte utgivelser, en testet responsplan
Deretter	Signert provenance, en formell gjennomgang av dekningen av SLSA eller NIST SSDF, SBOM-er fra leverandører

Hva av dette CRACI håndterer

CRACI dekker bygget og alt etter det. Som GitHub Actions-runneren din kjører CRACI hver jobb i sin egen isolerte virtuelle maskin, registrerer hver pakke jobben henter, i en SBOM, merker pakker gjenopprettet fra CI-cacher og håndhever en egress-policy som blokkerer tilkoblinger bygget ditt ikke trenger. Deretter fortsetter CRACI å sjekke det som er levert, viser hvilke bygg som inneholdt en sårbar pakke, og kan blokkere bygg med policy-gates.

Resten blir værende hos de andre verktøyene dine: CRACI skanner ikke kildekode eller hemmeligheter, oppdager ikke nye ondsinnede pakker ut fra oppførsel og signerer ikke SBOM-er eller provenance. Se verktøy for sikkerhet i programvareleverandørkjeden sammenlignet for hva som fyller hvert hull.

Beste praksis for sikkerhet i programvareleverandørkjeden: ofte stilte spørsmål

Hvordan sikrer du en programvareleverandørkjede?

Vit hva du leverer med en SBOM fra hvert utgivelsesbygg, styr hva som slipper inn med lockfiler og vurdering, beskytt bygget ved å begrense hemmeligheter og utgående trafikk, og fortsett å overvåke det du har gitt ut.

Hva bør et lite team gjøre først?

Slå på flerfaktorautentisering, installer fra lockfiler i CI, fest GitHub Actions til commit-hasher og gi workflow-tokens bare den tilgangen de trenger. Disse stegene tar dager og stenger vanlige angrepsveier.

Hvordan forhindrer du ondsinnede pakker?

Ikke noe enkelt tiltak gjør det. Vent med å ta i bruk nye versjoner, begrens installasjonsskript og vurder nye avhengigheter. Å begrense utgående trafikk fra bygg reduserer skaden hvis en ondsinnet pakke slipper gjennom.

Hvorfor feste GitHub Actions til en commit-hash?

Fordi en versjonstagg kan flyttes til annen kode. En fullstendig commit-hash viser alltid til samme kode, så en kapret tagg når ikke pipelinen din.

Hvor ofte bør du gå gjennom leverandørkjeden din?

Overvåkingen bør være kontinuerlig. Gå gjennom avhengighetspolicyen, workflow-tilgangene og responsplanen minst én gang i året, og etter enhver hendelse i stacken din.