Hva er sikkerhet i programvareleverandørkjeden?

Hva er programvareleverandørkjeden?

Programvareleverandørkjeden er alle og alt som er involvert i å få programvare fra en utviklers editor til produksjon. Tenk på den som fire stadier, hvert med sine egne risikoer.

Stadium	Hva som inngår	Hva som går galt
Kilde	Koden din, repositorier og utviklerkontoer	Stjålet påloggingsinformasjon, ondsinnede commits, lekkede hemmeligheter
Avhengigheter	Pakker med åpen kildekode, base-images, tredjepartskode	Sårbare versjoner, ondsinnede utgivelser, typosquatting
Bygg	CI-runnere, GitHub Actions, byggeverktøy, cacher	Kompromitterte actions, forgiftede cacher, stjålne pipeline-hemmeligheter
Utgivelse	Artefakter, registre, utrullinger, oppdateringer	Byttede artefakter, manipulerte oppdateringer, ingen oversikt over hva som ble levert

Hvorfor det er viktig nå

Det meste av det du leverer, har du ikke skrevet selv. En moderne applikasjon er for det meste åpen kildekode, og hver direkte avhengighet tar med seg andre som ingen i teamet ditt har valgt. Disse pakkene kjører med samme tilgang som din egen kode, og installasjonsskriptene deres kan kjøre inne i CI-pipelinen din, ved siden av hemmelighetene dine.

Historikken fra de siste årene viser hvordan dette blir utnyttet:

• SolarWinds: Bygget ble kompromittert, så et rent kildetre ga en forgiftet utgivelse.
• Log4Shell: En feil i ett loggebibliotek nådde produkter som aldri visste at de brukte det.
• xz utils: En betrodd bidragsyter smuglet en bakdør inn i et prosjekt som finnes i Linux-distribusjoner.
• tj-actions: En kapret GitHub Action kjørte angriperens kode i pipelinene som brukte den, med hemmeligheter innen rekkevidde.
• Shai-Hulud: En orm spredte seg gjennom npm-pakker og stjal tokens fra maskinene og CI-jobbene som installerte dem.

Hvordan disse angrepene fungerer steg for steg, ser du i hva er et leverandørkjedeangrep.

Slik fungerer sikkerhet i programvareleverandørkjeden

Et program trenger fire ting. Alt annet er detaljer.

1. Vit hva du leverer. Ha en nøyaktig SBOM for hver utgivelse, fra bygget som produserte den, inkludert transitive avhengigheter.
2. Styr hva som slipper inn. Fest versjoner, bruk en lockfile, begrens hvor bygg kan hente fra, og vurder nye pakker.
3. Beskytt bygget. Isoler jobber, begrens hemmeligheter, fest actions til en commit og begrens utgående trafikk, slik at en kompromittert pakke ikke kan sende tokenene dine noe sted. Se runnersikkerhet og derfor hører leverandørkjedesikkerhet hjemme i CI.
4. Fortsett å følge med på det som er levert. Nye sårbarheter berører programvare som allerede er i produksjon. Overvåk den, spor hvilke utgivelser som er berørt, og følg hver retting frem til en ny utgivelse.

Den detaljerte sjekklisten finner du i beste praksis for sikkerhet i programvareleverandørkjeden.

Rammeverk og regelverk

Navn	Hva det er	Best for
SLSA	Nivåer for byggeintegritet og provenance	Å herde måten programvare bygges på
NIST SSDF	Praksiser for sikker utvikling, SP 800-218	Et fullstendig program for sikker utvikling
NIST SP 800-161	Risikostyring for cybersikkerhet i leverandørkjeden	Risikostyring i hele organisasjonen
OpenSSF Scorecard	Automatiserte sjekker av helsen til prosjekter med åpen kildekode	Å vurdere avhengigheter
Cyber Resilience Act	EU-lov for produkter med digitale elementer	Salg i EU. Se hva er CRA

Hvilke verktøy er involvert?

Ikke noe enkelt produkt dekker alt dette. Kategorien deler seg i SCA-verktøy, SBOM-verktøy, CI/CD- og runnersikkerhet, pakkebrannmurer, application security posture management og binæranalyse. Hva hvert av dem gjør og hvem som selger dem, ser du i verktøy for sikkerhet i programvareleverandørkjeden sammenlignet og hva de koster.

Hvor du bør begynne

1. Generer en SBOM for det viktigste produktet ditt fra CI-bygget, og les den.
2. Slå på sårbarhetsvarsler for avhengigheter, og bestem hvem som eier dem.
3. Fest GitHub Actions til en commit, og gå gjennom hemmelighetene workflowene dine kan nå.
4. Begrens utgående trafikk fra byggene dine til vertene de faktisk trenger.
5. Sett opp overvåking av det du har levert, ikke bare det du bygger.

CRACIs tilnærming

CRACI begynner i bygget, fordi bygget er det ene stedet som ser alt. CRACI erstatter GitHub-hostede runnere med raskere og rimeligere runnere som registrerer hver pakke hver jobb henter, på alle nivåer i treet og inkludert pakker gjenopprettet fra CI-cacher. Egress-policyen blokkerer tilkoblinger bygget ditt ikke trenger, så den beskytter deg selv mot et angrep ingen har sett før. Deretter fortsetter CRACI å sjekke det som er levert, mot nye sårbarheter og følger hver av dem fra prioritering til en rettet utgivelse. Se sikkerhet i programvareleverandørkjeden med CRACI.

Sikkerhet i programvareleverandørkjeden: ofte stilte spørsmål

Hva er sikkerhet i programvareleverandørkjeden?

Det er arbeidet med å beskytte alt som går inn i programvaren din før den når brukerne: avhengigheter med åpen kildekode, byggesystemer, verktøy i pipelinen og utgivelser.

Hva er et eksempel på et angrep på programvareleverandørkjeden?

I SolarWinds-angrepet ble bygget kompromittert, så kundene mottok en forgiftet oppdatering fra en betrodd leverandør. I Shai-Hulud-angrepene spredte en orm seg gjennom npm-pakker og stjal tokens fra maskinene som installerte dem.

Hva er forskjellen på leverandørkjedesikkerhet og applikasjonssikkerhet?

Applikasjonssikkerhet ser på feil i koden du skriver. Leverandørkjedesikkerhet ser på det du ikke har skrevet, og på hvordan programvaren din bygges og gis ut. Et program trenger begge deler.

Er en SBOM nok for leverandørkjedesikkerhet?

Nei. En SBOM forteller deg hva du leverer, og det er grunnlaget. Du må også styre hva som slipper inn, beskytte bygget og fortsette å overvåke det du har gitt ut.

Hva er de viktigste rammeverkene?

SLSA for byggeintegritet, NIST SSDF for praksiser for sikker utvikling og NIST SP 800-161 for risikostyring i leverandørkjeden. I EU setter Cyber Resilience Act lovkrav for produkter med digitale elementer.

Hvem eier sikkerheten i programvareleverandørkjeden?

Den ligger vanligvis hos applikasjons- eller produktsikkerhet, i samarbeid med plattform- og DevOps-teamene som drifter pipelinene. Rettinger går deretter til utviklingsteamene som eier hver tjeneste.