Det viktigste vi kan gjøre før vi skriver en eneste kodelinje er å blie enige om ansvarsfordelingen mellom oss og kunden, samt klassifiseringen av løsning og data: Hvilke krav stiller kunden og hvilke krav kommer fra lovverk eller andre parter? Kompetanse innenfor applikasjonssikkerhet (AppSec) bør være på banen allerede i denne fasen for å sikre at en ivaretar krav og forventninger til sikkerhet.
Vi må også vite hva vi gjør ~~dersom~~når det oppstår en sikkerhetshendelse - hvilke krav står vi ovenfor, hva må til for at disaster recovery, backup og liknende skal lykkes, og hva vil konsekvensene av nedetid være for kunden?
1 - Ansvarsfordeling
Manglende klarhet i hvem som er ansvarlig for hva kan få store konsekvenser. Dette gjelder alle prosjekter, men er spesielt viktig dersom andre selskaper enn oss og kunden er involvert. Å ha en tydelig ansvarsfordeling med tilhørende varslingsrutiner og roller er avgjørende.
Bouvet gjennomfører utviklingsprosjekter på mange ulike måter, der vi tar mer eller mindre ansvar for prosjektledelse, planlegging, utviklingsfasen, kvalitetssikring og ikke minst drift og forvaltning av løsningen. Vi har også ulike innslag av eget, kundens og tredjepartsutstyr, både under utvikling og forvaltning av løsningen.
Uavhengig av hvordan prosjektet gjennomføres er det viktig at vi har kontroll på ansvarsfordelingen. Denne skal være regulert i avtalen med kunden, og vi må sikre at vi
Har kontroll på ansvar og rollefordeling
At vi har kontaktpunkt hos alle involverte parter
Kan følge opp avvik raskt slik at vi unngår misforståelser eller problemer senere i prosjektløpet
Viktig
Rollen leveranseansvarlig har ansvar for sikkerheten i leveransen, og er ansvarlig for at dette følges opp.
Drift og forvaltning av løsning
Bouvet
Dersom vi er ansvarlige for drift og forvaltning av løsning i vår infrastruktur, vil denne komme inn under vår sertifisering på ISO 27001 - Informasjonssikkerhet. Dette medfører at vi har et større helhetlig ansvar for sikkerheten rundt løsningen, og det er viktig at leveranseteamet er klar over dette.
Alle ressurser driftet av leveranseteamet må håndteres på linje med all annen infrastruktur, så teamet må ha rutiner for patching og vedlikehold eller sikre at dette blir håndtert. Vær obs på at kunderessurser og data håndteres med egne backuprutiner, slik at vi ikke blander på tvers av kunder eller med våre egne interne data.
Sjekk gjerne med Intern-IT & Sikkerhet for å se hva de kan levere og bistå med for å forenkle leveranse og forvaltning.
Bouvets Statement of Applicability/Anvendelseserklæring (SOA) tar for seg ulike kontroller relatert til informasjonssikkerheten og hvordan vi skal forholde oss til disse. SOA kan finnes i det interne ledelsessystemet. Dersom vi tar på oss denne rollen vil din regionale kvalitetsleder kunne bistå med råd og veiledning for å sikre at alt ansvar er ivaretatt.
Kunde eller tredjepart
Dersom vi kun har ansvar for utvikling av løsningen, er det viktig at vi har gått opp grensesnittet mellom oss og organisasjonen som overtar og drifter løsningen videre:
Hvordan skal handover skje
Hvordan håndterer vi at nødvendig hardware og kapasitet er satt opp
Hvordan sikrer vi at behov for deployments, driftshendelser, feilrettinger og liknende kommuniseres til begge parter?
Tips
Dokumenter ansvarsfordeling og annen relevant informasjon i kildekodesystemet sammen med resten av det som produseres i prosjektet. Det øker synligheten og alle vet til enhver tid hvor informasjonen finnes.
De fleste organisasjoner opererer med ulike klassifikasjonsnivå på både data og systemer. Klassifiseringen gjøres ofte med bakgrunn i hvordan data brukes, hvor det lagres og hvem som kan aksessere disse. Dette er nøkkelkrav for ethvert utviklingsprosjekt og må avklares i forkant.
Klassifisering
De aller fleste organisasjoner har rutiner og prosesser for klassifisering av data, for eksempel i følgende nivå:
Åpent
Internt
Konfidensielt
Begrenset
Avhengig av denne klassifiseringen kan det foreligge ulike krav til sikring av data. Åpne data har typisk ingen begrensninger, mens data klassifisert som “begrenset” kan ha begrensninger som at en
har strenge krav til innsyn
kun kan behandle informasjonen i egne systemer
krever flerfaktor autentisering før aksess
har restriksjoner i forhold til bruk av skytjenester eller hvor data lagres
Dette avklares med kunde i oppstarten av prosjektet slik at en kan sikre nødvendig etterlevelse. Dersom kunden ikke har et forhold til dataklassifisering, bør en likevel kartlegge sensitiviteten til dataene som skal behandles for å sikre at vi innfører nødvendige tiltak.
Personvern
Dersom leveranseteamet skal behandle personsensitive opplysninger, er det viktig at teamet setter seg inn i kravene rundt dette. Datatilsynet har publisert en egen veileder for “Programvareutvikling med innebygd personvern” som gir nyttig innblikk i problemstillingen.
Viktig
Norge er underlagt kravene i GDPR gjennom Personopplysningsloven, og det er viktig at leveransene har et forhold til en del krav og definisjoner i denne. Husk også at vi kan være underlagt databehandleravtaler som kan stille strengere krav enn lovverket!
Hensikten med GDPR er å sikre enkeltpersoners rettigheter ved å stille krav til hva personopplysninger kan brukes til samt hvilke, og hvordan disse kan brukes. Lovverket definerer personopplysninger som
“enhver opplysning om en identifisert eller identifiserbar fysisk person («den registrerte»); en identifiserbar fysisk person er en person som direkte eller indirekte kan identifiseres, særlig ved hjelp av en identifikator, f.eks. et navn, et identifikasjonsnummer, lokaliseringsopplysninger, en nettidentifikator eller ett eller flere elementer som er spesifikke for nevnte fysiske persons fysiske, fysiologiske, genetiske, psykiske, økonomiske, kulturelle eller sosiale identitet”
Personvern kan virke komplekst og vanskelig, men i korte trekk så
Er en personopplysning et informasjonsfragment som kan kobles til en bestemt person
Skal du ha behandlingsgrunnlag - hvorfor skal du behandle en personopplysning
Skal personen det gjelder gi sitt samtykke til at du kan behandle informasjonen
Du skal minimere mengden informasjon du henter inn - du skal kun samle inn det du trenger
Informasjonen skal ha en levetid - du skal ikke lagre data lenger enn nødvendig
Brukeren har retten til å bli glemt - også dersom du må restore fra en tidligere backup
Dersom vi behandler denne type informasjon på vegne av kunder skal de normalt kreve at vi signerer en databehandleravtale. Dersom dette ikke er på plass må det følges opp mot leveranse- og kundeansvarlig.
Data til bruk under utvikling og testing
Dersom en bruker data i forbindelse med utvikling og testing, er det viktig å ha et forhold til klassifisering og sensitivitet. Dev-miljøer har ofte et annet sikringsnivå enn produksjonsmiljøet, og dette gjør i praksis at vi ikke alltid kan bruke relle data til utvikling.
Teamet må sjekke behovet for anonymisering av dataene før disse brukes utenfor produksjonsmiljøet, slik at en ivaretar behovet for mengden data, fyllingsgrad og kvalitet samtidig som at en ikke risikerer at kundens data kommer på avveie.
Dette er spesielt viktig dersom utvikling skjer i Bouvets infrastruktur, men med produksjonsmiljø plassert hos kunden. I slike tilfeller er det viktig at Bouvet har dokumenterte rutiner som regulerer hvor og hvordan data oppbevares og brukes, og hvordan og når disse skal slettes. Dette må gås opp i samråd med kunde slik at det ikke er noe tvil rundt ansvar, plikter og risiko.
Dersom en katastrofal hendelse oppstår må vi vite hvem som skal kontaktes, og hvilke krav løsningen og leveranseteamet må forholde seg til. Dette går ikke bare på typiske krav relatert til tilgjengelighet men også hvor lang tid en kan bruke på gjenoppretting, hvordan dette skal gjøres og hva som er akseptabelt tap av data.
Business Continuity Planning er ikke utelukkende et IT-teknisk anliggende, men det er vårt ansvar som leverandører av et IT-system å minne kunden på at systemet kan bli utilgjengelig.
Svaret fra denne planleggingen vil være med å beskrive hvilke krav som stilles til løsningens robusthet og sikkerhetsnivå, og er avgjørende for å finne riktig balanse på kostnad og ytelse hos systemet.
Her er det viktig å ha et forhold til
Kritikaliteten av løsningen
Eventuelle workarounds dersom løsningen er utilgjengelig
Konsekvenser eller merarbeid som følge av utilgjengelighet eller når løsningen igjen blir tilgjengelig.
Kundens forventninger
Har vi definert en Service Level Agreement (SLA) med kunden som legger føringer på oppetid, tilgjengelighet og liknende, eller har kunden implisitte forventninger til dette?
Dette må avklares slik at en kjenner konsekvensene nedetid vil få. I mange prosjekter benyttes det skykomponenter der en ikke har kontroll over alle variabler selv. Derfor er det viktig å tidlig i prosjektet avklare de faktiske behovene med kunden. Vi kan sikre redundans på alle fronter dersom kunden ønsker det, men det koster da deretter.
Dersom en går opp dette i forkant er det lettere å henvise til dokumentasjon og avtaler når løsningen blir utilgjengelig for å unngå dårlig stemning.
Håndtering av hendelser
Alle kunder i Bouvet skal ha et definert kontaktpunkt for hendelser i Kunder (CRM). Dersom det er andre kontaktpunkter fra teamet inn mot kunde som sikkerhetssenter (SOC) eller liknende er det lurt å dokumentere dette også slik at en kan løse oppståtte hendelser så raskt som mulig.
Dersom en hendelse oppstår og kunde eller andre har behov for kontakt med teamet, er det vanlige at leveranseleder er det formelle kontaktpunktet i Bouvet-teamet.
Backup
Backup er viktig i alle prosjekter. Selv om vi i mange prosjekter ikke har noe ansvar for drift av infrastruktur, kildekodesystemer eller andre verktøy, bør vi gjøre oss kjent med rutiner og begrensninger på området.
Dersom vi har ansvar for drift har vi også ansvar for at backup gjennomføres. Vanlige begrep her er
Recovery Time Objective (RTO) - akseptabel tid for å oppnå normaltilstand etter svikt
Recovery Point Objective (RPO) - hva er akseptabelt datatap etter svikt (målt i tid)
Løsning for backup og recovery må designes ut ifra disse kravene, og vi må sikre at dette ivaretas. En må sammen med kunden ta stilling til
Hvor mye?
Hvilken data og systemer skal være underlagt backupregimet. Kan det differensieres?
Hvor ofte?
Skal vi ta backup 1 gang i uken, hver natt, eller hver time?
Hvor langt tilbake?
Hvor lenge skal vi lagre backupene?
En vanlig tilnærming til backup er å kjøre
Daglige backups - disse lagres i 30 dager
Ukentlige backups - disse lagres i 6 måneder
Månedtlige backups - disse lagres i 2 år
Det er også viktig å ha et forhold til hvor backupene lagres, slik at en kan være best mulig rigget mot katastrofale hendelser. Dette kan løses ved å ha offline og offsite backups, altså backups lagret på eksempelvis tape og oppbevart på en annen fysisk lokasjon enn øvrige backups.
Test!
Backup som ikke testes har ingen verdi - innfør rutiner for å teste at du kan restore fra backup!
Disaster recovery
Disaster Recovery i planleggingsfasen handler om å utvikle et planverk for hva som skal gjøres for å raskest mulig komme tilbake til normaltilstand. Det kan være nyttig å tenkte på dette som “actions on”, altså; “Hvis X inntreffer, så gjør vi Y”.
Gjenoppretting
Det vil ikke være nødvendig å gjenskape tjenestene i alle disaster hendelser. Ofte kan man slippe unna med mindre omfattende og manuell feilretting. Uavhengig av dette bør man uansett ha en plan for fullstendig gjennoppretting. Har man det kan man redde seg fra de fleste situasjoner.
Kan infrastruktur gjenskapes korrekt og raskt nok?
Dokumenter ressurser, avhengigheter, og operasjonelle prosedyrer
Her vil bruk av Infrastructure as Code (IaC) være et viktig bidrag
Data og databaser
Total / bulkgjennopretting: Hvordan gjenoppretter du store mengder data / hele volumer?
Enkeltfiler: Hvordan gjenoppretter du en enkelt fil?
Støttesystemer
Husk at støttesystemer kan spille en viktig rolle i det totale systmet. Disse må også kunne erstattes eller gjennopprettes ved hendelser
Eksempelvis: Git, CI-pipeline, logging og monitorering
Scenarier som kan diskuteres
Slettet tjeneste: Hvordan gjenoppretter du en tjeneste som har blitt slettet?
Korrupt tjeneste: Reparerer eller gjenoppretter man en VM eller andre tjenester med problemer?
Utilgjengelig tjeneste: Hva skjer om tjenestene blir utilgjengelige? Her trenger du definisjonen av hva som er midlertidig / kortvarig nedetid. Skal du deploye ny tjeneste, har du allerede en som kjører som hot-swap eller går det greit uten en periode?
Kompromittert sikkerhet: Hvordan håndterer du det når et passord har blitt lekket på noe vis?
Utgått passord: hvordan gjenopptar du driften hvis et passord eller sertifikat har utløpt? (Hint: prøv å unngå dette)
Kompromittert identitet / tjenestebruker: Hva gjør du hvis en managed identitet eller en tjenestebruker har blitt kompromittert?
Utilgjengelige passord: Hva gjør du hvis key vaulttjenesten i regionen du bruker går ned? Har du backup og failover i en annen region?
Malware: Hvordan gjenoppretter du systemet etter et cryptolockerangrep? Trenger du en delvis eller total gjenoppbygging av alle tjenester?
Konfidensialitetsbrudd: Hvordan håndterer du at noen har kommet seg inn i tjenesten(e) du drifter?
Kompromittert admin: Trenger du å planlegge for hva som skjer om eieren av subscription sletter hele Azure-subscriptionen din?
Kritisk sårbarhet: Hva skjer når noen oppdager en kritisk sårbarhet i din applikasjon? Det kan være lurt å ha protokoller klare for når du skal ta et valg om du stenger tjenesten ned.
Bruken av kunstig intelligens (KI) har eksplodert de siste årene, og teknologien har kommet så langt at den kan være et nyttig verktøy for å brainstorme løsninger, skrive,feilsøke eller vurdere kode. Men hva betyr dette for sikkerheten?
Bruk av KI i prosjekter treffer en rekke problemstillinger vi må ta stilling til, deriblant:
Hvem eier kode og data? Hvem vil eie resultatet som kommer fra KI?
Hvilke muligheter har vi til å følge opp mislighold eller brudd på avtaler?
Hva kan gå galt; kan data eller kode komme på avveie, eller kan verktøyet gjøre endringer vi ikke forstår eller har kontroll på?
Håndtering av hemmeligheter
Husk at Bouvet og de fleste kunder har retningslinjer for bruk av KI som skal følges. Det er ikke lov å ta KI-verktøy i bruk uten eksplisitt godkjenning fra Bouvet eller kunde!
Hva har vi lov til
I Bouvet og på Bouvetutstyr har vi kun lov til å bruke KI-verktøy som er eksplisitt tillatt i Bouvets KI-policy; på kundens utstyr har vi kun lov til å bruke de verktøyene kunden har godkjent. Bakgrunnen for disse begrensningene skyldes kompleksiteten rundt KI-verktøy.
De kjører ofte i egne miljøer og utfører prosessering eller behandling av potensielt sensitiv informasjon og kan resultere i endringer som påvirker oss eller kunde.
SSelv om vi har den tekniske muligheten til å kjøre et KI-verktøy betyr det ikke at vi bør kjøre det. Dersom det er et verktøy som kan hjelpe utviklingsprosessen eller prosjektet du er med i; lag en BSD-sak slik at det kan bli sjekket ut.
Nytt verktøy? Tenk over følgende
Dersom du ønsker å ta i bruk et nytt verktøy er det viktig med klarhet i forhold til hvem som eier resultatet av det verktøyet produserer.
Mange gratisvarianter og ikke-enterprisevarianter av verktøy har restriksjoner i lisenser og avtaler som tillater leverandøren å bruke input for treningsformål. Dette vil aldri være akseptabelt for Bouvet, og heller ikke for kundene våre.
Vi er også nødt til å ha kontroll på hvor data og informasjon flyter slik at personvernet og forpliktelsene våre i personvernloven kan ivaretas.
Hva deler du med KI?
Dersom du har fått lov til å bruke et KI-verktøy i utviklingsprosjektet må du ha kontroll på følgende:
Hva har du lov til å dele med verktøyet?
Hva har du faktisk delt med verktøyet?
Hvordan kan du sikre at du ikke deler mer enn du har lov til?
Hvordan du bruker verktøyet i utviklingsprosjekter vil variere; noen kodeverktøy kjører som assistenter i IDE’et ditt; mens andre kobler seg opp mot f.eks. Github, analyserer koden og foreslår endringer i en egen branch basert på promptene dine.
Med mindre det er eksplisitt godkjent skal ikke verktøyet under noen omstendigheter ha tilgang til data utover kodebasen.
Sjekk at du ikke inkluderer datafiler, hemmeligheter eller annen sensitiv informasjon i repoet, og ekskluder eventuelt disse i .gitignore. Ta i bruk nøkkelhvelv der du kan for å unngå at hemmeligheter havner i repoet ved et uhell.
Lekkasje av sensitive data
Vær klar over at noen KI-verktøy kan commite og pushe kode til Github automatisk fra IDE’et ditt, og at du må sikre at sensitiv informasjon som passord, sertifikater og data ikke kommer på avveie.
Kvalitetssikring av KI-bidrag
KI-løsninger kan ha en positiv effekt på fremdrift, men må alltid behandles som kode fra tredjepart og kvalitetssikres deretter. Kode skrevet av KI vil i mange tilfeller gjøre det du ønsker, men i mange tilfeller på en mer komplisert måte, med svakheter eller sårbarheter, eller rett og slett ved å hallusinere seg frem til løsninger som aldri vil fungere i praksis.
Du som utvikler må vite hva du skal gjøre for å instruere verktøyet skikkelig, og du må være klar over hvilke begrensninger verktøyet har. For å gjøre jobben litt enklere har vi noen grunnleggende prinsipper:
KI skal ikke ta design- eller arkitekturbeslutninger. Det brukes til å løse avgrensede oppgaver innenfor en menneskestyrt arkitektur.
KI behandles som en juniorutvikler: alt den leverer skal gjennomgås, forstås og testes. KI-baserte bidrag skal være sporbare og etterprøvbare.
Oppgaver deles opp i små, vurderbare komponenter du kan kvalitetssikre fullt ut. Unngå store blokker kode uten menneskelig innsikt.
KI gjør oss i stand til å bli mer produktive, men det er viktig at vi forstår resultatene KI-verktøyene gir oss. Det har vært mange eksempler på kode som brukes mer eller mindre ukritisk, før det viser seg at den inneholder store og alvorlige svakheter som kan utnyttes for å manipulere eller hente ut data. Sikkerhetstesting bør alltid være en del av utviklingsløpet, men dette blir enda viktigere ved bruk av KI-verktøy for å skrive kode. KI-generert kode skal aldri ut i prod uten at den er gjennomgått, forstått og testet.
En bør også vurdere ulike barrierer som kan hindre uventede og negative konsekvenser, som regelbaserte filer med tilleggsinstrukser for KI, tilgangsbegrensning slik at KI eksempelvis ikke kan merge kode selv og andre tiltak som forhindrer KI fra å gjøre endringer som ikke er gjennomgått og godkjent av en utvikler.
Feilkonfigurasjon er en vanlig kilde til feil og sårbarheter, dette gjelder også for verktøy. Dersom mulig bør teamet standardisere på bruk av verktøy og utvidelser til disse, og sikre at alle har en mest mulig lik (og dokumentert) arbeidsprosess.
Alle utviklingsteam benytter ulike verktøy i utviklingsprosessen, og utvalget vil varierere fra team til team avhengig av personlige preferanser, teknologivalg, system og kundekrav og mye annet.
Et typisk team vil benytte seg av en eller annen form for
et system for versjonskontroll av koden, typisk git
et verktøy for CI/CD som kan utføre ulike oppgaver relatert til bygging, testing eller deployment
andre tjenester driftet eller konsumert av teamet, f.eks. meldingstjenester, filoverføringstjenester, generativ AI (copilots) eller liknende
Disse verktøyene kan ha stor betydning for sikkerhet og kvalitet i leveranser, så det er viktig at teamet har et forhold til hvordan disse settes opp.
IDE
Mange IDEs støtter bruk av utvidelser som legger til manglende funksjonalitet, som støtte for flere programmeringsspråk, integrasjoner mot andre verktøy og liknende. Vi må imidlertid være klar over at dette er en angrepsvektor på linje med andre økosystemer, og at vi som utviklere må ha et forhold til risikoen forbundet med utvidelsene. Det er ikke nok å bare se på nedlastingstall, vi må også se på andre indikatorer som tilbakemeldinger, historikk og liknende.
Versjonskontroll
Versjonskontroll gir kjempekontroll over alle endringer, men det er viktig at vi bruker verktøyet på en god måte. De-facto standard idag i de fleste prosjekter er git, i Bouvet hovedsaklig med repositories hostet på Github eller Azure DevOps. Repositories og branchingstrategier må konfigureres etter behov; noen prosjekter har forholdsvis enkle arbeidsflyter som består av fork-fra-main; pull request; merge-to-main, mens andre har mer komplekse flyter som involverer mange ulike branches som håndterer ting som utvikling, testing, produksjon og annet.
Github støtter også bruk av ulike actions, som kan utføre oppgaver på kode som sjekkes inn, som CI/CD, sikkerhetstesting og mye annet. Husk også på at kildekode er en del av prosjektet, og må vurderes i forhold til disaster recovery og backups!
Vær obs på at flere av punktene under krever tilleggssoftware. Vi har per idag ingen felleslisenser for utviklere i Bouvet, dette må gås opp per prosjekt avhengig av behov og krav. Dersom teamet håndterer dette på egenhånd, vær obs på lisensbetingelser og hvordan verktøy fungerer. Noen verktøy sender eksempelvis kildekode til egne servere for analyse, dette er i utgangspunktet ikke tillatt med mindre det på forhånd er avklart med kunden.
Software compostion analysis (SCA)
Software composition analysis (SCA) kan settes opp automatisk som en del av CI/CD. Vi har mange avhengigheter til komponenter laget av andre, så det er viktig å ha oversikt over eksisterende og nyoppdagede sårbarheter i det vi lager.
Testing
Å kjøre tester i CI er lurt av flere grunner, men fra et sikkerhetsperspektiv er det enkelte tester som bør være med.
Test alle aktuelle endepunkter for 401/403 responser
Test kode som håndterer autorisasjon (hvem får gjøre hva). Her vil det være en fordel om all autorisasjonslogikk skjer på et sentralisert sted i kodebasen.
Statisk kodeanalyse (SAST) bør konfigueres til å kjøres automatisk som en del av CI/CD. Man kan vurdere om et bygg skal feile dersom den statiske kodeanalysen oppdager alvorlige svakheter med koden eller lav testdekning.
Secret scanning
Sjekking av hemmeligheter - passord, nøkler og annen sensitiv informasjon som ikke skal inn i kildekoden er et viktig verktøy som kan implementeres i versjonskontrollsystemet og i CI/CD. Noen verktøy har kun varsling ved funn, andre kan også ugyldiggjøre hemmelighetene i tjenestene de er ment for.
Generativ AI (copilots)
Det eksisterer mange ulike generative AI-verktøy som kan benyttes av utviklere. Det er viktig at enhver bruk av slike verktøy avklares med kunden før de tas i bruk. Her har Bouvet gjort mye arbeid i evaluering av flere slike verktøy og har god støtte internt for å gjøre slike vurderinger om kunden skulle ha behov for det.
Et sikkerhetskontrollpunkt er et kontrollpunkt underveis i et prosjekt der en setter krav som må oppfylles før en går videre.
Avhengig av sikkerhetsnivået en leveranse ønsker å legge seg på, kan det være nødvendig å definere mekanismer for å vurdere sikkerheten på faste punkter i utviklingsløpet, såkalte sikkerhetskontrollpunkt.
Disse kan defineres mellom logiske faser i prosjektet, eksempelvis mellom design og utviklingsfasene, eller når en går fra utvikling til første release i produksjon. Andre og flere kontrollpunkter kan også defineres, helt avhengig av kravene leveranseteamet må forholde seg til.
IBM har i en studie fastslått at generelle svakheter i applikasjoner utviklet for det amerikanske forsvaret kostet langt mindre å utbedre jo tidligere de ble oppdaget.
Ved å ta i bruk sikkerhetskontrollpunkt er det ikke bare lettere å sikre etterlevelse av sikkerhet- og kvalitetskrav, men også lettere å sikre at en fanger opp svakheter tidlig. En vanlig praksis der slike kontrollpunkt benyttes er at det eksempelvis
skal foreligge et design av prosjektet før utviklingsløpet starter
at implementasjonen skal følge designet
og at en har verifisert at design og implementasjon faktisk matcher før en kan gå i produksjon
