Forumet SAFECode – «Software Assurance Forum for Excellence in Code» – har publisert en hvitbok om metoder for å verne kode mot å korrumperes i prosessen fra komponentinnsamling fram til distribusjon, oppdatering og vedlikehold. Medlemmene av SAFECode er Adobe, EMC, Juniper, Microsoft, Nokia, SAP og Symantec, som alle har ytt sitt bidrag til hvitboken.
Hvitboken Software Integrity Controls (pdf, 24 sider) har som undertittel An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain. Den sammenfatter tiltak som er utviklet og tatt i bruk av forumets medlemmer.
«Software assurance» – trygging av programvare – dreier seg om å avverge sårbarheter og dårlig kvalitet i koden.
_logo.svg.png){kind=logo}
Definisjonen til SAFECode lyder slik: «Tillit til at programvare, maskinvare og tjenester er fri for tilsiktede og utilsiktede sårbarheter, og at programvaren fungerer etter hensikten.»
Ifølge SAFECode er det tre faktorer som til sammen utgjør trygging av programvare: sikkerhet, integritet og autentisitet.
Under sikkerhet kommer krav som stilles i forkant av selve utviklingsprosessen, og som kontrolleres løpende. Eksempler er vern mot usikrede buffere og pålegg om å kryptere følsom informasjon i databaser.
Autentisitet dreier seg om å kunne skille mellom ekte og uekte vare, at for eksempel pakken pyntet med varemerket til Microsoft, Adobe eller Symantec virkelig er fra disse leverandørene.
Det som er temaet for hvitboken, programvareintegritet, handler om hvordan man kan verne og garantere koden gjennom hele utviklingsprosessen, fra innsamling av komponenter fra interne og eksterne kilder, gjennom utvikling av egne komponenter, oppretting og distribusjon av bygg («build»), til utvikling og distribusjon av oppdateringer, fikser og andre tillegg mens programvaren er i produksjon.
SAFECode peker på at moderne programvare utvikles gjennom kjeder av underleverandører, og at prosessen må legges opp slik at man kan stole på at det ikke underveis dukker opp kode som, tilsiktet eller utilsiktet, oppfører seg klanderverdig.
Hvitboken understreker at angrep mot forsyningskjeden ikke er spesielt utbredt i dag. Angripere er mer opptatt av å lure brukere gjennom forskjellige typer sosiale knep, og av å utnytte eksisterende sårbarheter. Det er i hvert fall erfaringen til de selskapene som har samarbeidet om hvitboken.
På den andre siden understreker SAFECode at utviklingskjeden utgjør en risiko i seg selv.
En angriper som greier å lure inn en porsjon perfekt utformet ondsinnet kode i et produkt fra Microsoft eller SAP, vil ha begått en kriminell bragd med nærmest uberegnelige følger.
Derfor er det om å gjøre for slike leverandører å kunne vise til iverksatte rutiner og kontroller som kan avverge slikt. Hvitboken redegjør for mye av dette: Den omfatter ikke bare anbefalinger til andre, men er vel så mye en redegjørelse av typen «slik gjør vi det hos oss».
Hvitboken visere hvordan integritetskontroller kan bygges inn i de tre trinnene som alle ledd i utviklingskjeden må gjennom: mottak av kode fra et tidligere ledd, egen utvikling og testing, og leveranse av ferdige komponenter, inklusiv distribusjon, oppdatering og vedlikehold.
Mange av kontrolltiltakene handler om garantier formulert i kontrakter og avtaler. Andre dreier seg om formaliserte prosedyrer for å kontrollere tilgang til kodelagre, og for å dokumentere aksess. Det vies spesiell oppmerksomhet til framstilling av nye bygg, der poenget er å forene personlig sporbarhet med automatisering. Skripter skal ta seg av det meste, men man skal også vite nøyaktig hvem som gjorde hva, og hvem som har ansvaret. Skriptene i seg selv er også kode som kvalifiserer til egne vernetiltak.
Egne anbefalinger gis for utvikling i åpen kildekode, som ikke alltid egner seg for kontrakter og avtaler, og der det trengs andre former for tillitskapende virkemidler.
En typisk erfaring er utilsiktet korrumpering av kode grunnet manglende oversikt over hvilke andre tjenester som bruker den gjeldende modulen. Hvitboken lister opp integritetskontroller som kan brukes til både å avverge at slikt skjer, og hindre at koden går videre til neste ledd i utviklerkjeden før den er rettet.
