Hvad er forsyningskædesikkerhed for software?

Hvad er softwareforsyningskæden?

Softwareforsyningskæden er alle og alt, der er involveret i at få software fra en udviklers editor til produktion. Tænk på den som fire stadier, hver med sine egne risici.

Stadie	Hvad det indeholder	Hvad der går galt
Kilde	Din kode, dine repositories og udviklerkonti	Stjålne legitimationsoplysninger, ondsindede commits, lækkede secrets
Afhængigheder	Open source-pakker, base-images, tredjepartskode	Sårbare versioner, ondsindede releases, typosquatting
Build	CI-runnere, GitHub Actions, build-værktøjer, caches	Kompromitterede actions, forgiftede caches, stjålne pipeline-secrets
Release	Artefakter, registries, deployments, opdateringer	Udskiftede artefakter, manipulerede opdateringer, ingen registrering af det leverede

Derfor er det vigtigt nu

Det meste af det, du leverer, har du ikke selv skrevet. En moderne applikation er for det meste open source, og hver direkte afhængighed trækker andre med, som ingen på dit team har valgt. Disse pakker kører med samme adgang som din egen kode, og deres install-scripts kan køre inde i din CI-pipeline, lige ved siden af dine secrets.

De seneste års hændelser viser, hvordan det bliver udnyttet:

• SolarWinds: Buildet blev kompromitteret, så et rent kildetræ producerede en forgiftet release.
• Log4Shell: En fejl i ét logbibliotek nåede produkter, der aldrig vidste, at de brugte det.
• xz utils: En betroet bidragyder smuglede en bagdør ind i et projekt, der findes i Linux-distributioner.
• tj-actions: En kapret GitHub Action kørte angriberens kode i de pipelines, der brugte den, med secrets inden for rækkevidde.
• Shai-Hulud: En orm spredte sig gennem npm-pakker og stjal tokens fra de maskiner og CI-jobs, der installerede dem.

Se hvad er et forsyningskædeangreb for, hvordan disse angreb virker trin for trin.

Sådan virker forsyningskædesikkerhed for software

Et sikkerhedsprogram har brug for fire ting. Alt andet er detaljer.

1. Vid, hvad du leverer. Hav en præcis SBOM for hver release, fra det build, der producerede den, inklusive transitive afhængigheder.
2. Styr, hvad der kommer ind. Fastlås versioner, brug en lockfile, begræns, hvor builds kan hente fra, og vurdér nye pakker.
3. Beskyt buildet. Isolér jobs, begræns secrets, fastlås actions på commit, og begræns udgående trafik, så en kompromitteret pakke ikke kan sende dine tokens nogen steder hen. Se runner-sikkerhed og derfor hører forsyningskædesikkerhed hjemme i CI.
4. Bliv ved med at holde øje med det leverede. Nye sårbarheder rammer software, der allerede er i produktion. Overvåg den, spor, hvilke releases der er ramt, og følg hver rettelse hele vejen til en ny release.

Den detaljerede tjekliste finder du i bedste praksis for forsyningskædesikkerhed for software.

Rammeværker og regler

Navn	Hvad det er	Bedst til
SLSA	Niveauer for build-integritet og provenance	At hærde, hvordan software bygges
NIST SSDF	Praksis for sikker udvikling, SP 800-218	Et komplet program for sikker udvikling
NIST SP 800-161	Risikostyring af cybersikkerhed i forsyningskæden	Risikostyring i hele organisationen
OpenSSF Scorecard	Automatiserede tjek af open source-projekters sundhed	Vurdering af afhængigheder
Cyber Resilience Act	EU-lov for produkter med digitale elementer	Salg i EU. Se hvad er CRA

Hvilke værktøjer er involveret?

Intet enkelt produkt dækker det hele. Kategorien deler sig i SCA-værktøjer, SBOM-værktøjer, CI/CD- og runner-sikkerhed, pakke-firewalls, application security posture management og binæranalyse. Se værktøjer til forsyningskædesikkerhed sammenlignet og hvad de koster for, hvad hver type gør, og hvem der sælger den.

Hvor du skal starte

1. Generér en SBOM for dit vigtigste produkt ud fra dets CI-build, og læs den.
2. Slå sårbarhedsalarmer for afhængigheder til, og beslut, hvem der ejer dem.
3. Fastlås dine GitHub Actions på commit, og gennemgå de secrets, dine workflows kan nå.
4. Begræns udgående trafik fra dine builds til de hosts, de faktisk har brug for.
5. Sæt overvågning op af det, du har leveret, ikke kun det, du bygger.

Sådan griber CRACI det an

CRACI starter ved buildet, fordi buildet er det ene sted, der ser alt. Det erstatter dine GitHub-hostede runnere med hurtigere og billigere runnere, der registrerer hver pakke, hvert job henter, i alle lag af træet og inklusive pakker gendannet fra CI-caches. Egress-politikken blokerer forbindelser, dit build ikke har brug for, så den beskytter dig, selv mod et angreb, ingen har set før. CRACI bliver derefter ved med at tjekke det leverede mod nye sårbarheder og følger hver enkelt fra triage til en rettet release. Se forsyningskædesikkerhed for software med CRACI.

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

Hvad er forsyningskædesikkerhed for software?

Det er arbejdet med at beskytte alt, hvad der går ind i din software, før den når brugerne: open source-afhængigheder, build-systemer, pipeline-værktøjer og releases.

Hvad er et eksempel på et angreb på softwareforsyningskæden?

I SolarWinds-angrebet blev buildet kompromitteret, så kunder modtog en forgiftet opdatering fra en betroet leverandør. I Shai-Hulud-angrebene spredte en orm sig gennem npm-pakker og stjal tokens fra de maskiner, der installerede dem.

Hvad er forskellen på forsyningskædesikkerhed og applikationssikkerhed?

Applikationssikkerhed ser på fejl i den kode, du skriver. Forsyningskædesikkerhed ser på det, du ikke har skrevet, og på, hvordan din software bygges og udgives. Et sikkerhedsprogram har brug for begge dele.

Er en SBOM nok til forsyningskædesikkerhed?

Nej. En SBOM fortæller dig, hvad du leverer, og det er fundamentet. Du skal også styre, hvad der kommer ind, beskytte buildet og blive ved med at overvåge det, du har udgivet.

Hvad er de vigtigste rammeværker?

SLSA for build-integritet, NIST SSDF for praksis for sikker udvikling og NIST SP 800-161 for risikostyring i forsyningskæden. I EU stiller Cyber Resilience Act lovkrav til produkter med digitale elementer.

Hvem ejer forsyningskædesikkerhed for software?

Den ligger som regel hos applikations- eller produktsikkerhed i samarbejde med de platform- og DevOps-teams, der driver pipelinerne. Rettelser går derefter til de engineering-teams, der ejer hver service.