Utvikle on Sikkerhet.bouvet.no - For Security Champions i Bouvet

Forsyningskjedesikkerhet

Mon, 01 Jan 0001 00:00:00 +0000

Når vi bygger software har vi avhengigheter til en hel haug med ulike tredjepartspakker fra økosystem som npmjs, nuget, PyPi og liknende. I CI/CD-pipelines har vi actions og kode som gjennomfører testing, bygging, deployment og liknende. Alt dette er kode og komponenter som kommer fra tredjepart, der vår grad av sikkerhet er prisgitt hvordan disse aktørene jobber. En svakhet i en avhengighet kan resultere i at vårt prosjekt lekker data, at kode manipuleres eller brukes til ondsinnede handlinger.

Versjonskontroll

Mon, 01 Jan 0001 00:00:00 +0000

Git er idag standard i de fleste prosjekter som kjøres i Bouvet, men skulle du havne i et prosjekt som bruker noe annet vil mange av prinsippene likevel være overførbare. Git i seg selv er selve versjonskontrollverktøyet som håndterer historikk og versjonering, mens Github håndterer alt rundt som CI/CD, sikkerhetstesting og liknende. Azure DevOps har mange de samme funksjonene som beskrives under; selv om Github er brukt som eksempel bør du anta at det samme gjelder for Azure DevOps.

Datavalidering

Mon, 01 Jan 0001 00:00:00 +0000

Datavalidering er grunnleggende i alle utviklingsprosjekter. Formålet er å sikre at data har forventet struktur, innhold og kvalitet før de brukes videre i systemet.

Feil eller ondsinnet data kan føre til:

sikkerhetssårbarheter, som injeksjon og XSS
funksjonelle feil og ustabil drift
feil beslutningsgrunnlag i rapportering og analyse
redusert kvalitet i AI-modeller og evaluering

OWASP Top 10 har over tid vist at mangelfull validering av input er en gjentakende årsak til alvorlige sårbarheter. Hovedregelen er enkel: data skal valideres ved tillitsgrensen, uansett kilde.

Sikkerhetspraksiser

Mon, 01 Jan 0001 00:00:00 +0000

Det finnes mange ulike typer sårbarheter og svakheter vi må forholde oss til når vi utvikler nye applikasjoner. Organisasjonen Open Worldwide Application Security Project (OWASP) publiserer en prioritert liste over vanlige applikasjonssårbarheter som brukes av mange team som et praktisk utgangspunkt.

OWASP Top 10 er ikke en komplett sikkerhetsstandard, men en nyttig prioritering av hva som typisk går galt i virkelige prosjekter.

Gjeldende punkter i OWASP Top 10

Per i dag er siste publiserte versjon OWASP Top 10:2025:

Utviklingsmiljø, verktøy og byggmiljø

Mon, 01 Jan 0001 00:00:00 +0000

Utviklingsmiljøet og byggmiljøet er noe av det viktigste vi har i et utviklingsprosjekt. Disse miljøene er både en produktivitetsfaktor og en kritisk del av angrepsflaten. Noen team utvikler og bygger lokalt på egen laptop, mens andre bruker dedikerte utviklings- og byggmiljø basert på skytjenester eller on-prem utviklingsservere. Uavhengig av løsning er det noen grunnprinsipper som bør være på plass: tydelig eierskap, dokumenterte valg, standardiserte oppsett og jevnlig oppfølging.

Verktøy

Et typisk team benytter seg av:

Dokumentasjon

Mon, 01 Jan 0001 00:00:00 +0000

Dokumentasjon er ofte nedprioritert under leveranse, men manglende dokumentasjon skaper reell risiko. Kildekode beskriver hvordan noe fungerer, men ikke hvorfor valg ble tatt, hvilke trusler som er vurdert, eller hvilke forutsetninger løsningen er avhengig av.

Sikkerhetskontekst som kun finnes i hodet på enkeltpersoner er en sårbarhet. Sikkerhetsmekanismer som ikke er dokumentert risikerer man at fjernes uten at noen forstår konsekvensen. Trusselmodeller som ikke er skrevet ned kan heller ikke vedlikeholdes eller revideres.

Hemmeligheter

Mon, 01 Jan 0001 00:00:00 +0000

Hemmeligheter er representert i utviklingsprosjekter i form av connection strings, passord, nøkler, sertifikater og alt annet som regnes som sensitiv informasjon vi ikke ønsker at andre skal få kjennskap til.

Det finnes mange ulike tilnærminger til hvordan disse skal håndteres, og dette har også endret seg etter hvert som nye tjenester dukker opp. For skyløsninger har tjenester som Azure Key Vault og liknende nærmest blitt en standard, da disse tjenestene håndterer flere aspekter av hvordan en bruker og forvalter hemmeligheter.

Sikkerhetstesting

Mon, 01 Jan 0001 00:00:00 +0000

Sikkerhetstesting bør alltid være et element av alle leveranser. Mange assosierer sikkerhetstesting med penetrasjonstesting, men det er mye mer enn dette. Noen former for testing kan gjøres automatisk som del av CICD, andre er mer manuelle og skjer typisk mot en deployert løsning.

Før en setter i gang med sikkerhetstesting er det viktig å sette seg inn i hva dette kan gi deg - det finnes ingen enkelttiltak som løser alle sikkerhetsproblemer, og heller ingen enkelt testmetode som avdekker alle svakheter. Sikkerhetstesting er også et av områdene som ofte krever spesifikk kompetanse for at resultatene skal bli gode og/eller tolket korrekt.