Når løsningen er designet og koden er skrevet er det "bare" å deploye, så er vi i mål, eller hva? Vi bruker ofte CICD-løsninger for å bygge og deploye, samt kjøre tester og mye annet.
Dersom noen kan kompromittere pipelines, byggagenten som bygger løsningen eller forbindelsen mot ressursene vi deployer til vil vi ha store problemer.
Selv om det er vanskelig å dekke alt i noen få korte artikler, forsøker vi likevel å gi et innblikk i problemstillinger en bør ta opp i leveranseteamet.
1 - CI/CD
CI/CD er den overordnede rammen for automatisering av bygg, verifikasjon og deployering. En god pipeline gir sporbarhet, kvalitetssikring og kontrollert utrulling på tvers av miljøer.
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.
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.
Bygging handler om å produsere et reproduserbart artefakt som kan verifiseres og stoles på før deploy. Valg av byggmiljø, avhengigheter og signering er sentrale kontrollpunkter.
Bygging er steget der kildekode blir til et deploybart artefakt. Målet er at artefaktet skal kunne reproduseres, kontrolleres og spores tilbake til en konkret commit og pipeline-kjøring.
Denne artikkelen fokuserer på selve byggingen. Overordnet pipeline-styring er beskrevet i CI/CD, og utrulling til miljø er beskrevet i Deployering.
Byggmiljø og byggeagenter
Byggagenter kommer ofte i to hovedformer:
skyleverandørstyrte agenter
selvstyrte agenter (i sky eller on-premise)
Skyleverandørstyrte agenter gir ofte lavere driftskost og enklere vedlikehold. Selvstyrte agenter gir mer kontroll, men også fullt ansvar for hardening, patching og tilgangsstyring.
Uansett modell er byggmiljøet et høyrisikopunkt. Dersom byggmiljøet kompromitteres kan alle artefakter som produseres på det miljøet bli upålitelige.
Krav til trygg bygging
Et robust byggoppsett bør minimum ha:
Reproduserbarhet: Samme input skal gi samme artefakt. Unngå skjulte avhengigheter og udokumenterte manuelle steg.
Pinned avhengigheter: Lås versjoner eksplisitt, og unngå “latest” i bygg.
Isolasjon: Skill byggjobber mellom prosjekter med ulike risikonivå.
Kontroll på byggverktøy: Kompilatorer, baseimages og plugins bør versjonstyres og godkjennes.
Sporbarhet: Artefaktet må kunne kobles til commit, pipeline-kjøring og byggkonfigurasjon.
Ja, signering hører naturlig hjemme i bygg-fasen. Signering bør gjøres rett etter at artefaktet er produsert og verifisert.
Praktiske kontroller:
Signer artefakter: Signer containere, binærer og pakker med en kontrollert nøkkel.
Verifiser signatur ved deploy: Utrulling bør stoppe dersom signatur mangler eller er ugyldig.
Generer SBOM: Lag oversikt over innholdet i artefaktet for sporbarhet og sårbarhetshåndtering.
Bygg provenance-attestering: Dokumenter hva som bygde artefaktet, fra hvilken kilde og under hvilke forutsetninger.
Bygging for KI-systemer
For KI-løsninger omfatter bygging mer enn vanlig programmerkode. Treningsmodeller, støttefiler, datarepresentasjoner og kjørbare miljøer som brukes til å kjøre modellen må også håndteres kontrollert gjennom hele prosessen.
Versjoner modellartefakter: Behandle modellversjoner på lik linje med kodeversjoner.
Signer modell- og inferensartefakter: Bruk samme integritetskrav for modeller som for øvrige artefakter.
Dokumenter datasett- og modellversjoner: Beskriv tydelig hva som inngår i hver release.
Unngå dynamisk nedlasting i produksjon: Ikke last ned modellfiler utenfor styrt release-flyt.
Deployering handler om kontrollert flytting av et verifisert artefakt til kjøremiljøer. Målet er trygg utrulling, rask rollback og forutsigbar drift.
Deployering starter etter at artefaktet er bygget og verifisert. Hovedprinsippet er at samme artefakt promoteres mellom miljøer, uten ny bygging underveis.
Denne artikkelen fokuserer på utrulling til miljøer. Selve pipeline-styringen er dekket i CI/CD, og detaljer om trygg artefaktproduksjon i Bygging.
Prinsipper for trygg deploy
For å redusere drifts- og sikkerhetsrisiko bør deployprosessen bygge på:
Promotering av samme artefakt: Ikke bygg på nytt per miljø.
Verifikasjon før utrulling: Deploy skal stoppe dersom nødvendige kontroller ikke er bestått.
Automatisert og idempotent utrulling: Samme deploykommando skal gi samme resultat.
Sporbarhet: Hver utrulling skal kunne kobles til artefakt, commit og godkjenning.
Hva en deployprosess bør dekke
En moden deployprosess bør minimum dekke:
Miljøforflytning (dev-test-prod): Tydelige gates mellom miljøer.
Godkjenning og endringskontroll: Krav til godkjenning før produksjon.
Release-strategi: Støtte for blue/green, canary eller rolling deploy der det er hensiktsmessig.
Rollback: Definert og testet prosedyre for rask reversering.
Smoke-tester etter deploy: Verifiser at løsningen faktisk fungerer i målmiljøet.
Observabilitet: Overvåkning og varsling som fanger feil tidlig etter utrulling.
Tilgangsstyring og miljøsikkerhet
Deploy-tilgang må behandles som en privilegert operasjon:
Minst privilegie for deploy-identiteter: Gi kun tilgangene som er nødvendige for utrulling.
Skille mellom roller: Skille roller for utvikling og produksjonsutrulling der det er mulig.
Begrens trigging av produksjonsdeploy: Begrens hvem som kan starte deployering til produksjon.
Sporbarhet på utrullinger: Logg hvem som deployet hva, når og til hvilket miljø.
Deploy av KI-systemer
For KI-løsninger må deployprosessen også håndtere modellatferd og datadrevet risiko:
Modellutrulling med kontroll: Bruk gradvis utrulling (for eksempel canary) for å redusere konsekvens ved feil modelloppførsel.
Tydelig versjonskobling: Kjørende løsning skal kunne kobles til eksakt modellversjon, kodeversjon og konfigurasjon.
Verifisering i målmiljø: Kjør relevante kvalitets- og sikkerhetssjekker også etter deploy, ikke bare i bygg.
Driftsovervåkning: Følg med på modellkvalitet, responstid og eventuelle tegn til drift i data eller output.
Rask tilbakeføring: Ha klar prosedyre for å bytte tilbake til tidligere modellversjon ved avvik.
