FOSS-säkerhet har blivit något av en snackis, och det är inte så konstigt. När alla kan kika på koden – visst känns det transparent och tryggt, men öppna dörrar lockar ju också nyfikna tjuvar. Och just supply chain-attacker har seglat upp som den nya mardrömmen för utvecklare och företag som bygger på fri och öppen källkod. Det handlar inte längre bara om att skydda egna servrar eller lösenord, utan om att förstå hela ekosystemet som ens mjukvara vilar på. I takt med att fler organisationer förlitar sig på FOSS för både små och stora projekt, ökar också attackytan dramatiskt. Plötsligt räcker det inte med att ha koll på sin egen kod – du måste också lita på andras, och där kan det bli riktigt snårigt. Det är därför samtalet om FOSS-säkerhet har blivit högaktuellt, och varför det är dags att djupdyka i vad hoten egentligen innebär.
Vad tusan är en supply chain-attack, egentligen?
Du har hört det förr: kedjan är aldrig starkare än den svagaste länken. Det gäller verkligen här. Supply chain-attacker handlar om att angripare slinker in i mjukvarans leveranskedja – kanske via ett beroende, ett paket, eller till och med en build-server – och planterar skadlig kod. När du senare laddar ner eller uppdaterar din favorit-FOSS så följer boven med på köpet. Lite som att någon smyger in en trasig länk i din cykelkedja precis innan du ska ut och cykla. Angriparna utnyttjar ofta automatiserade verktyg och CI/CD-pipelines för att sprida sin kod så snabbt och osynligt som möjligt. Ofta märks attacken inte förrän långt senare, när skadan redan är skedd. Det kan handla om allt från stöld av API-nycklar till att bakdörrar installeras, eller att användardata läcker ut. Och eftersom ekosystemet av beroenden är så komplext blir det svårt att ens upptäcka var hotet har smugit sig in. Det är därför supply chain-attacker är så svåra att förhindra – och så effektiva för angriparna.
NotPetya, SolarWinds & npm: Skräckexempel i repris
Kommer du ihåg NotPetya? Eller SolarWinds-skandalen? De är nästan skolboksexempel på supply chain-attacker. NotPetya spreds via en manipulerad uppdatering till ett ukrainskt bokföringsprogram och slog ut företag över hela världen – inklusive stora svenska bolag. SolarWinds var ännu mer raffinerat: angriparna lyckades smyga in kod i ett populärt systemövervakningsverktyg, vilket ledde till att tusentals företag och myndigheter blev infekterade. Och npm – det lilla JavaScript-paketet event-stream som blev infekterat 2018 – visar att även små, skumma paket kan ställa till det för tusentals projekt. Det räcker att en maintainer tappar fokus eller säljer sitt projekt till någon med tvivelaktiga avsikter för att hela ekosystemet ska bli sårbart. Det är lätt att tro att just ditt projekt ändå är för litet för att bli en måltavla. Men angripare har blivit smarta, och ibland räcker det med ett enda beroende för att nå tusentals användare. Till och med populära paket som log4j har visat sig vara sårbara, och effekterna kan bli enorma när något går snett i leveranskedjan.
Falsk trygghet: Öppen källkod granskas väl av massorna?
Det låter så bra: ”Öppen källkod är säkrare för att alla kan granska koden.” Men så är det ju inte alltid. Visst, någon kan hitta sårbarheter, men många beroenden lever i skymundan. Vem läser ens igenom alla rader i ett bibliotek du drar in via pip eller npm? Ofta blint litar vi på crowd intelligence – tills det smäller. Många projekt har bara en eller ett par aktiva maintainers, och ibland är de överhopade med arbete. Sårbarheter kan ligga oupptäckta i månader eller år, speciellt i äldre eller mindre populära paket. Det är lätt hänt att man importerar ett bibliotek som i sin tur har ytterligare fem-tio beroenden, och plötsligt har man en lång kedja med potentiella risker. Bara för att koden är öppen betyder det inte att den faktiskt blir granskad – särskilt inte när det saknas incitament eller resurser för att göra en ordentlig genomgång. Den verkliga tryggheten kommer först när någon faktiskt tar sig tid att titta på vad som döljer sig under huven.
Så skyddar du dig (utan att bli paranoid)
Okej, nu till det viktiga. Hur håller du din FOSS-miljö säker utan att sluta använda öppen källkod? Här är några smarta knep och riktiga verktyg du kan ta till:
- Inventera dina beroenden – Använd verktyg som OWASP Dependency-Check, GitHub Dependabot eller Snyk för att hålla koll på nya sårbarheter i dina paket. Dessa verktyg kan automatiskt skanna dina projekt och flagga för kända problem, vilket sparar tid och minskar risken för obehagliga överraskningar.
- Uppdatera ofta – Det kanske låter tråkigt, men att ligga steget före med uppdateringar hindrar många attacker. Automatisera gärna processen och se till att du har ett arbetssätt där patchar kan rullas ut snabbt, utan onödiga manuella steg.
- Signera och verifiera builds – Med Sigstore och Cosign kan du signera dina artifacts och se till att ingen manipulerat dem på vägen. På så sätt kan du kontrollera att det du laddar ner verkligen kommer från en betrodd källa, och att ingen har mixtrat med paketet.
- Kör kodgranskning på riktigt – Särskilt när du drar in nya beroenden. Titta på aktivitetsnivå, antal stjärnor på GitHub, och om projektet har aktiva maintainers. Läs igenom issues och pull requests för att se hur sårbarheter hanteras och om det finns en levande community kring projektet.
- Minimera attackytan – Ta bara in det du verkligen behöver. Färre beroenden, mindre risk att något går snett. Fundera på om du verkligen behöver hela ramverket eller om enstaka moduler räcker. Ju mindre, desto bättre när det gäller säkerhet.
Det kan också vara värt att sätta upp interna policies för hur och när beroenden får introduceras, samt att dokumentera vilka paket som används i era projekt. En tydlig process minskar risken för att någon av misstag lägger till onödiga eller osäkra moduler.
Supply chain-skydd: Inte bara teknik, utan kultur
Det är lätt att stirra sig blind på tekniska lösningar. Men den största skillnaden gör ofta kulturen. Om teamet snackar öppet om risker, tar ansvar för säkerhet och vågar flagga när något känns fel – då har ni redan vunnit mycket. Många attacker utnyttjar slarv, stress eller rutinmässigt klickande på ”accept” utan att läsa. Att bygga en sund säkerhetskultur kräver att alla förstår varför det är viktigt att ta sig tid för kodgranskning och att ifrågasätta även till synes små förändringar. Uppmuntra alla i teamet att komma med förslag och rapportera misstankar, och belöna dem som upptäcker potentiella problem. Att skapa rutiner för säkerhetsgenomgångar och att ha återkommande diskussioner om hotbilden gör att säkerhet blir en naturlig del av vardagen, inte bara något som ligger på en enskild säkerhetsansvarig. En levande säkerhetskultur är svår att hacka sig förbi.
Hoten utvecklas – häng med i svängarna
Säkerhet är ingen engångsinsats. Nya attackmetoder poppar upp, och gamla knep får nytt liv. Följ med i branschsnacket, läs bloggar som Krebs on Security eller Hackernoon, och delta i FOSS-communityns diskussioner. Det kanske låter överdrivet, men den som bara slår sig till ro blir snabbt omsprungen. Det finns forum, nyhetsbrev och Slack-kanaler där säkerhetsexperter delar nya sårbarheter och trender i realtid. Att hålla sig uppdaterad kan kännas tidskrävande, men det är ofta där du får nys om nya risker innan de blir allmänt kända. Delta i CTF-tävlingar eller bug bounty-program för att hålla kompetensen vass. Och kom ihåg: hotbilden förändras, men med rätt nätverk och kunskap är du alltid bättre rustad än den som blundar för utvecklingen.
Vår och sommar: Högsäsong för kod och attacker
Det märks ofta när hackare vädrar morgonluft – efter stora konferenser, eller när många utvecklare rullar ut nya versioner (hej, vårreleaser!). Särskilt under hackathons kan tempot bli högt och säkerheten hamna i skymundan. Många team kör ”sista minuten”-ändringar, plockar in nya beroenden utan att riktigt hinna kolla vad de faktiskt gör, och prioriterar funktion framför säkerhet. Ta några minuter extra att kolla dina beroenden innan du pushar nästa gång. Det kan vara skillnaden mellan en lyckad release och ett supportmaraton i midsommarnatten. Semestertider är dessutom extra känsliga – när folk är borta eller har fokus på annat kan det vara lätt att missa varningssignaler. Planera in säkerhetsgenomgångar i samband med stora releases, och se till att det alltid finns någon med koll på plats – även när solen skiner som mest.
Sammanfattning? Nej tack – säkerhet är en pågående resa
Att skydda sig mot supply chain-attacker inom FOSS handlar om att hitta en balans. Mellan tillit och kontroll, mellan snabbhet och noggrannhet. Och kanske framför allt: att inse att även det öppna, fria och transparenta behöver en stor dos vaksamhet. Det finns ingen slutdestination där allt är säkert – det handlar om att hela tiden justera, reagera på nya hot och uppdatera sina rutiner. Precis som kodbasen ständigt utvecklas, måste också säkerhetstänket göra det. Gör säkerhet till en naturlig del av utvecklingsprocessen och bygg ett mindset där du alltid ifrågasätter, förbättrar och lär nytt. Bara då kan du fortsätta dra nytta av FOSS – utan att behöva ligga sömnlös över nästa stora attack.
