CI/CD
Continuous Integration og Continuous Delivery (CI/CD) er praksis for å automatisere flyten fra kodeendring til kjørende løsning. Pipelines gir en standardisert prosess for bygging, verifikasjon og utrulling, og reduserer risikoen for manuelle feil.
Poenget med CI/CD er ikke bare fart, men kontroll. Hver kjøring bør være sporbar, kunne gjentas og ha tydelige stoppunkt før noe går til produksjon.
Prinsipper for CI/CD
En trygg CI/CD-praksis bygger på noen enkle grunnprinsipper:
- Minst mulig tilgang: Pipeline skal bare ha tilgangene den faktisk trenger.
- Sporbarhet: Du skal kunne se hva som ble kjørt, av hvem og mot hvilken kode.
- Automatiske regler: Kvalitets- og sikkerhetskrav bør ligge i pipeline, ikke i hodet på folk.
- Kontrollert flyt: Produksjon bør ha egne kontrollpunkt med tester og godkjenning.
- Skille mellom miljøer: Bygg, test og produksjon bør ikke dele identitet og tilganger.
Sikkerhetskontroller i pipeline
En pipeline bør minimum ha:
- Skann for hemmeligheter: Finn hardkodede nøkler, tokens og annen sensitiv informasjon.
- Skann avhengigheter: Finn kjente sårbarheter i tredjepartsbiblioteker.
- Statisk kodeanalyse (SAST): Finn vanlige svakheter tidlig.
- Automatiserte tester: Kjør enhets-, integrasjons- og relevante sikkerhetstester.
- Kjøringslogg: Ta vare på logger og metadata for revisjon.
Kritiske funn bør stoppe utrulling, ikke bare gi en advarsel.
Branching og promote-modell
Branching henger tett sammen med CI/CD, men detaljene hører hjemme i Git-artikkelen.
I CI/CD-sammenheng er hovedpoenget:
- kode til produksjon bør gå via pull request og beskyttet hovedgren
- utrulling til produksjon bør kreve passerte kontroller og godkjenning
Hemmeligheter og credentials i pipeline
Hemmeligheter som brukes i pipeline må håndteres med særlig forsiktighet:
- Aldri i kode: Nøkler og tokens skal ikke ligge i repo.
- Bruk sikker lagring: Bruk dedikert secret-løsning i plattformen.
- Roter jevnlig: Bytt nøkler og tokens med faste intervaller.
- Unngå lekkasje i logger: Sørg for at hemmeligheter ikke havner i logg.
Tredjepartskomponenter i pipeline
Pipeline-konfigurasjonen er en del av forsyningskjeden. Tredjepartskomponenter i pipeline (actions, orbs, templates, byggeimages) kjører med pipeline-tilganger og må behandles som kode du selv har ansvar for.
Det innebærer at en kompromittert eller ondsinnet tredjepartskomponent kan:
- eksfiltrere secrets og credentials som er tilgjengelige i kjøringen
- manipulere artefakter som bygges, uten at dette er synlig i koden din
- endre atferd ved oppdatering av en tag som peker på ny kode uten at du har godkjent endringen
Tiltak:
- Pin til commit-hash, ikke tag: En tag kan flyttes uten at du merker det.
- Begrens tilgang for actions: Gi en komponent bare de rettighetene den faktisk trenger.
- Revider tredjeparts actions: Gjennomgå kildekoden til actions du tar inn, spesielt de som håndterer secrets eller deployer til prod.
- Bruk interne eller offisielle actions: Foretrekk actions fra den samme organisasjonen, eller fra verifiserte aktører med god historikk.
- Overvåk endringer: Bruk Dependabot eller tilsvarende til å varsle når actions oppdateres, slik at oppdateringen er eksplisitt og sporet.
- Bruk av KI i pipeline: Vær sikker på at du forstår risiko og potensielle utfordringer før du vurderer å bruke KI-baserte actions i pipeline.
Det generelle bildet for forsyningskjedesikkerhet er beskrevet i Forsyningskjedesikkerhet.
AI i CI/CD
For KI-løsninger bør samme pipeline-prinsipper gjelde for kode, modeller, datasett og konfigurasjon. Utrulling bør stoppes hvis verifikasjon ikke er bestått.
Detaljer om trygg bygging av artefakter (inkludert signering) er beskrevet i Bygging, og trygg utrulling til miljøer i Deployering.
Praktisk opptak i team
Implementering av CI/CD bør gjøres trinnvis:
- Start med grunnleggende bygging og testing, legg til sikkerhetskontroller gradvis.
- Dokumenter pipeline-konfigurasjonen som kode slik at den kan revideres og versjoneres.
- Gi teamet tid til å lære verktøyet og praksisen før du innfører strengere krav.
- Følg opp funn i praksis. Alarmer uten oppfølging gir lite verdi.