Bedste praksis for forsyningskædesikkerhed for software

Kilde

• Kræv stærk godkendelse. Brug multifaktorgodkendelse på alle konti til kodehosting.
• Beskyt main-branchen. Kræv review før merge, og lad ingen pushe direkte til en release-branch.
• Hold secrets ude af koden. Scan efter dem ved hvert push, og rotér alt, der har været eksponeret.
• Behandl workflow-filer som kode. En ændring i en pipeline kan nå dine secrets, så kræv, at ejere gennemgår dem.

Afhængigheder

• Commit en lockfile, og installér fra den. Brug npm ci og tilsvarende, så builds ikke tager nye versioner med ved et uheld. En lockfile har sine grænser, men det er dér, du skal starte.
• Indfør en ventetid for nye versioner. Ondsindede releases bliver ofte fanget kort efter, de dukker op, så hvis du ikke tager en version i brug samme dag, den udgives, giver du det en chance for at ske.
• Begræns install-scripts. Slå dem fra, hvor du kan. Scripts, der kører ved installation, er den måde, npm-orme spreder sig på.
• Vurdér nye afhængigheder. Tjek navnet for typosquatting, og se på vedligeholdelse og popularitet. OpenSSF Scorecard automatiserer en del af det.
• Beskyt interne pakkenavne. Brug scopes og registry-konfiguration, så en offentlig pakke ikke kan træde i stedet for en intern gennem dependency confusion.
• Skær det væk, du ikke har brug for. Hver afhængighed er en ting mere at overvåge.

Build og CI/CD

• Fastlås GitHub Actions til et fuldt commit-hash. Tags kan flyttes, som kompromitteringen af tj-actions viste.
• Begræns, hvad hvert job kan gøre. Giv workflow-tokenet de mindste rettigheder, det har brug for, og brug kortlivede legitimationsoplysninger i stedet for langlivede secrets.
• Begræns udgående trafik. Et build har brug for pakker fra kendte kilder og udgiver til kendte steder. Blokér alt andet, så har stjålne secrets ingen steder at tage hen. Se egress-politik for GitHub Actions.
• Kør hvert job i et friskt, isoleret miljø. Intet bør følge med fra ét job til det næste, og mindst af alt fra en pull request fra en ekstern bidragyder.
• Behandl caches som input. En forgiftet cache overlever mellem builds, og det, den gendanner, er let at overse. Se GitHub Actions-cache.

Se den fulde liste i tjeklisten for CI/CD-pipelinesikkerhed og hvordan runner-sikkerhed klarer sig i sammenligning.

Release

• Generér en SBOM for hver release, fra buildet. Gem den sammen med artefaktet. Se bedste praksis for SBOM'er.
• Signér artefakter, og offentliggør provenance. Så kan forbrugere tjekke, hvor en release kommer fra. SLSA beskriver niveauerne.
• Byg kun releases i CI. En release fra en laptop har ingen pålidelig registrering bag sig.
• Brug ét artefakt fra test til produktion. Før det, du har testet, videre i stedet for at genbygge det, så registreringen forbliver retvisende.

Efter release

• Overvåg det, du har leveret. Bliv ved med at tjekke SBOM'erne for understøttede releases mod nye sårbarheder.
• Prioritér med mere end CVSS. Brug CISA KEV, EPSS og kontekst. Se sådan prioriterer du sårbarheder.
• Vid, hvor længe du var eksponeret. Build-historikken viser, hvilke releases der indeholdt en pakke, og fra hvornår.
• Hav en plan, før du får brug for den. Beslut, hvem der triagerer, hvem der retter, og hvem der taler med kunderne. Se livscyklussen for sårbarhedsstyring.
• Øv dig med et realistisk scenarie. Spørg, hvor lang tid det ville tage at finde hver release med en given pakke. Hvis svaret er dage, så start dér.

Hvad du skal gøre først

Hvornår	Gør dette
I denne uge	Multifaktorgodkendelse, lockfiles i CI, fastlåste GitHub Actions, workflow-tokens med mindste rettigheder
I denne måned	SBOM fra hvert release-build, afhængighedsalarmer med en ejer, secrets-scanning
I dette kvartal	Regler for udgående trafik fra builds, overvågning af leverede releases, en testet beredskabsplan
Derefter	Signeret provenance, en formel gennemgang af SLSA- eller NIST SSDF-dækning, SBOM'er fra leverandører

Hvad CRACI håndterer af dette

CRACI dækker buildet og alt derefter. Som din GitHub Actions-runner kører det hvert job i sin egen isolerede virtuelle maskine, registrerer hver pakke, jobbet henter, i en SBOM, markerer pakker gendannet fra CI-caches og håndhæver en egress-politik, der blokerer forbindelser, dit build ikke har brug for. Derefter bliver det ved med at tjekke det leverede, viser, hvilke builds der indeholdt en sårbar pakke, og kan blokere builds med policy gates.

Resten bliver hos dine andre værktøjer: CRACI scanner ikke kildekode eller secrets, opdager ikke nye ondsindede pakker ud fra adfærd og signerer ikke SBOM'er eller provenance. Se værktøjer til forsyningskædesikkerhed sammenlignet for, hvad der udfylder hvert hul.

Bedste praksis for forsyningskædesikkerhed: ofte stillede spørgsmål

Hvordan sikrer du en softwareforsyningskæde?

Vid, hvad du leverer, med en SBOM fra hvert release-build, styr, hvad der kommer ind, med lockfiles og vurdering, beskyt buildet ved at begrænse secrets og udgående trafik, og bliv ved med at overvåge det, du har udgivet.

Hvad skal et lille team gøre først?

Slå multifaktorgodkendelse til, installér fra lockfiles i CI, fastlås GitHub Actions til commit-hashes, og giv workflow-tokens de mindste rettigheder, de har brug for. De trin tager dage og lukker almindelige angrebsveje.

Hvordan forhindrer du ondsindede pakker?

Det gør intet enkelt trin. Vent med at tage nye versioner i brug, begræns install-scripts, og vurdér nye afhængigheder. Begrænsning af udgående trafik fra builds begrænser skaden, hvis en ondsindet pakke slipper igennem.

Hvorfor fastlåse GitHub Actions til et commit-hash?

Fordi et versionstag kan flyttes til anden kode. Et fuldt commit-hash henviser altid til den samme kode, så et kapret tag ikke når din pipeline.

Hvor ofte skal du gennemgå din forsyningskæde?

Overvågningen bør være løbende. Gennemgå din afhængighedspolitik, dine workflow-rettigheder og din beredskabsplan mindst én gang om året og efter enhver hændelse i din stack.