8 risikoer ved Git­Hub og andre kodehus

"Hva er det som er så positivt med å legge koden din tilgjengelig for enhver angriper?" spør Even Lysen.

Even Lysen koder hos Visma Consulting, og har noen tanker rundt sikkerheten i blant annet GitHub. 📸: Privat
Even Lysen koder hos Visma Consulting, og har noen tanker rundt sikkerheten i blant annet GitHub. 📸: Privat Vis mer

Utviklere vil sitte hvor de vil når de knotter på tastaturet. De vil sitte foran Rogue One-plakaten sin på kontoret hjemme, med en kaffe latte i hånden og en overpriset vegansk burrito på brygga, eller være en moderne tradisjonell utvikler på kontoret.

Mens systemene våre blir sentralisert i skyen, ønsker utviklerne å sitte distribuert i byen. Kommunikasjonen foregår over verdens mest forstyrrende programvare, Slack, og koden deles via versjoneringskontroll-programmer som GIT.

GIT er et kommandolinjeverktøy, men det finnes et hav av GUI-baserte skall du kan legge over, eller dra inn programmer som integrerer egne løsninger med GIT i bunnen. Det er ingenting som hindrer et utvikler-hus å hoste sitt eget GIT repository internt, eller kjøre de i lukkede skyløsninger. Allikevel er det mange som heller vil bruke offentlige SaaS løsninger hvor de legger kildekoden tilgjengelig for alle.

«Mens systemene våre blir sentralisert i skyen, ønsker utviklerne å sitte distribuert i byen.»

Mange utviklere som arbeider i offentlig sektor i dag benytter seg av Github eller Gitlab, men SaaS løsninger er ikke bare for kildekode lenger. Nå legger de hele bygg-pipelinen, integrert med statiske analyseverktøy, ut for «alles» øyne. Noe er selvfølgelig begrenset med tilgangstyring, men det ser ut som en trend at man skal kaste mer og mer ut i det offentlige.

Hvorfor? Hvis koden du skriver er særegen for plassen du jobber, eller utfører samfunnskritiske oppgaver, eller kanskje behandler personsensitive data, hva er det da som er så positivt med å legge den tilgjengelig for enhver angriper som er interessert i systemene dine?

Hvis din virksomhet er et mål vil en trusselagent starte med å finne ut all informasjon de kan om din virksomhet og dine ansatte. Hvis de finner kode som kjører på dine systemer vil den saumfares av både automatiske scannere og manuelle øyne. Selv om kildekoden er til systemer som ligger dypt inne i din sikre sone. Kanskje ikke akkurat denne applikasjonen ble benyttet for å komme seg inn, men den kan kanskje benyttes for å pivotere seg videre senere.

Nedenfor listes noen risikoer ved å benytte offentlig tilgjengelige kodehus og deretter en kort (og ikke komplett) guide om beste praksiser.

#1. Sikker utviklings-metodikk

For å i det hele tatt kunne utvikle sikre løsninger trenger man at sikkerhet er en del av det vanlig utviklingsløpet. Bare på denne måten vil man kunne komme så nær mål som mulig på Defense-in-depth prinsippet.

Det finnes en rekke rammeverk og strategier for dette. OWASP sin side inneholder mye om Secure Development Lifecycle (SDLC).

Andre er for eksempel Microsoft sitt SDL rammeverk som finnes både til klassiske metodikker som fossefall og mer agile metoder som SCRUM.

#2. Rammeverk

De fleste sårbarhetene som ligger på OWASP sin topp 10 liste klarer utviklere fint å implementere selv om de benytter de mest moderne utviklerrammeverkene. I tillegg skal det nevnes at det finnes et hav av flere sårbarheter som har en tendens til å snike seg inn, selv om de ikke befinner seg på noen OWASP liste. XSS (Cross-Site Scripting), CSRF (Cross-Site Request Forgery), Log Injection, XXE (XML External Entity), SQL Injection, Directory Traversal, Malicious File Uploads, DoS (Denial of Service) sårbarheter og mye mer finner vi i koden uavhengig av rammeverk.

Du skal ha svært gode utviklere som kjenner språk, rammeverk, domene og forretning ut og inn for at disse sårbarhetene ikke skal finne sted i koden. Selv den beste code-monkey kan overse bugs i kode når de kjører QA på andre.

#3. Statisk kodeanalyse

Statiske kodeanalyseverktøy er gull verdt, og med gated check-ins vil man tvinge på plass en viss grad av kodekvalitet og avdekke bugs (både sikkerhetsrelaterte og ikke).

Derimot estimeres det at statiske kodescannere klarer bare å avdekke rundt 40-45% av de sikkerhetsbugsene som finnes. Slike funn skal deretter verifiseres, eller merkes som falske-positiver. Hvis utvikleren ikke har kompetanse på sikker utvikling så kan dette være vanskelig.

#4. Risikodreven testing

De fleste driver en eller annen form for testdrevet utvikling, selv om svært få driver den slik Onkel Bob underviser den. Produkteier sier at koden må ha testdekning på f.eks. 70, 80 eller 90 prosent. Prosenten er ut i fra antall linjer kode. Her testes hva SKAL applikasjonen gjøre.

Derimot driver svært få med risikodreven testing; Hva skal applikasjonen IKKE kunne gjøre. Det er viktig å huske at «hacking» ikke handler om å bryte regler og lover. Det er motsatt. Når noen misbruker applikasjonen er det ved å bruke lover og regler applikasjonen kjører under, men som ingen har tenkt over eller testet for.

#5. Tredjepartsaktører

Når man benytter SaaS fra tredjepartsaktører utenfor landets grenser, og uten noen som helst kontrakt eller databehandleravtale, må man tenke seg nøye i forhold til hva man faktisk deler. Dette gjelder verktøy som Slack, Github, Snyk, etc.

«Du vet ikke hvem som sitter på mottakersiden.»

Du vet ikke hvem som sitter på mottakersiden. Du vet ikke hvordan de behandler backup, om de er angrepet, eller om de sikrer dine data på en forsvarlig måte. Plutselig en dag selges tjenesten du benytter og endrer bildet totalt da det kommer til angrepsflate, trusselaktører eller dine rettigheter som kunde. Du vet heller ikke alltid om tredjepartsaktørene selger eller deler data med andre.

Det kreves en god strategi som håndheves og styres med en klar visjon for at man ikke skal skyte seg i kneet ved bruk av tredjepartsaktører. Uten styring vil potensielt utviklere ta i bruk en rekke SaaS produkter fra mange forskjellige leverandører og da vil man raskt miste oversikten på hvor man har hva og hvordan sikkerheten på de forskjellige er ivaretatt (eller om noe bare er glemt bort). Selv om noe er sikkert i dag, er det ingen garanti for at det er det i morgen.

#6. Dataflyt

Skifter man fra å drive utvikling fra den interne sikre sonen til offentlige skyløsninger eller bare ta i bruk SaaS tjenester skal man være klar over at man endrer flyten av kode, og potensielt også, data totalt. Alt utviklerne sender rundt er ikke lenger innenfor din egen nettverksovervåkning, innenfor dine brannmurer og dine policies.

Skal en utvikler drive uthenting av kode, check-ins, deployments, dokumentasjonsoppdatering og generell kommunikasjon fra hvor som helst (eks. Kafeer, hoteller, kollektiv transport) må man ta stilling til hvordan man sikrer seg mot rogue access points.

Det kan være lurt å ha tydelige regler på hva man får lov til å gjøre fra ukjente access points (slik som for eksempel hoteller, tog, buss eller kafeer), og det bør legges til rette for at fjernarbeidere kan benytte VPN-oppsett eller ha sim-kort i arbeidsmaskinene sine.

#7. Hemmeligheter

Det vil kunne oppstå situasjoner der en utvikler sjekker inn konfigurasjonsfiler, brukernavn, passord, sertifikater eller kryptonøkler til det offentlige repositoriet. Det finnes scannere og checks for å hindre dette, men de er like gode som andre sikkerhetsregler og kontroller, og er ingen 100% garanti. Det må sørges for at rutiner er på plass for å kunne rulere nøkler, revoke tokens og nøkler, sertifikater, etc.

#8. Security champion

Et hvert team med utviklere bør ha en såkalt “security champion”. Dette er en person som har ansvaret for at resten av teamet bygger sikkerheten inn i løsningene de lager. At trusselmodelleringer, risikoanalyser og sikkerhetstester blir gjort.

«Ethvert team med utviklere bør ha en såkalt “security champion”.»

Det er derfor viktig at personer med denne rollen får tilstrekkelig opplæring og at de har klare retningslinjer for hva de skal gjøre. For eksempel kan virksomheten benytte OWASP ASVS for kartlegging av hvilke sikkerhetskontroller en applikasjon skal ha.

Skal man ha suksess med security champions må virksomheten ha en klar strategi som er godt kommunisert og som har metrikker de kan måle på hvert enkelt team og på hver enkelt sikkerhetskontroller. Hvis man bare velger ut en person, som allerede har mange andre oppgaver, til å være security champion, og heller ikke gir de opplæring og oppfølging, så er dette bare noe som ser fint ut på papiret.

Beste praksiser

Noen “best-practice” regler ved bruk av offentlig kodehus:

  1. Brukerkontoer: En hver bruker som publiserer kode til GitHub skal benytte en virksomhetens brukerkonto og ikke sin private konto. Kontoen som benyttes skal bare ha tilgang til virksomhetens kode.
  2. Multi-Faktor Autentisering: En hver bruker som publiserer/henter kode fra GitHub skal benytte multi-faktor autentisering. Det beste er å benytte en fysisk nøkkel som f.eks. Yubikey, eller nest best; autentiaktor app på mobilen, eller i værste fall SMS løsning.
  3. SAML Autentisering: En bedrift som skal benytte GitHub bør ha en GitHub Business Cloud plan. Dette gjør det mulig å håndheve passord policies, passord rulering, session timeouts og enterprise 2FA.
  4. Tilgang: En bedrift som skal benytte GitHub bør ha bare noen få Administratorer, og bare disse skal ha tilgang til å kontrollere et repos synlighet.
  5. Topics og Labels: Bruk Topics på GitHub repoene for å letter identifisere hvor bedriften har hvilken type teknologier. Dette hjelper til å ha kontroll på hvilke versjon og type programvare man har hvor. Bruk også Labels med gode navn og farger for lettere kontroll over historikk.
  6. Probot: Automatiser prosesser rundt GitHub ved å aktivere Probot. Her kan man f.eks. sette en compliance liste i en .yml fil. Hvis noen går inn å endrer på oppsettet på repoet vil Probot automatisk sette den tilbake til det som er bestemt standard.
  7. Risikovurdering: Det er ikke alle kodebaser som bør legges ut i offentligheten og kanskje heller burde ligge som et private repo. Før man legger ut koden skal man derfor utføre en risikovurdering på om dette bør være lukket eller ikke.
  8. Offentlige Kodebaser: Man bør konfigurere GitHub slik at organisasjonskontoer ikke kan opprette nye åpne repos. Hvis en bruker oppretter et nytt repo som han/hun setter offentlig åpnet, så vil det med en gang bli gjort privat. Dette vil gjøre at bare noen utvalgte kan sette repo til åpent.
  9. Begrens Eksterne: Opprett en konfigurasjonsfil som begrenser eller setter krav til hvem utenfor virksomheten som kan bidra med kode og endringer.

Bruk

Retningslinjer for utviklere og andre som til daglig skal bruke GitHub i sitt arbeid:

  1. Git-Secrets: Benytt funksjonalitet som git-secrets for å unngå at brukerkontoer/passord/SSH nøkler o.l. blir lastet opp i GitHub repo.
  2. Invalideringsprosesser: Når passord og tokens kommer på avveie bør man ha rutiner som raskt kan invalidere kontoene disse er linket til.
  3. GitRob / truffleHog: Benytte ovenfornevnte verktøy for auditing.
  4. ENV variabler: Benytt miljøvariabler og vault for secrets i CI/CD.
  5. SECURITY.md fil: Inkluder en SECURITY.md fil i prosjektene som inneholder Disclosure Policy, Security Update Policy, Sikkerhetskonfigurasjoner, sårbarhetshåndtering o.l.
  6. Roter SSH nøkler og tokens