En kortfattad guide för utvärdering av öppen programvara
av Open Source Security Foundation (OpenSSF) Best Practices Working Group, 2025-11-21
Innan du använder beroenden eller verktyg som är öppen källkod, bör du, som programutvecklare, identifiera och utvärdera alternativen mot dina behov. För utvärdering av en tänkbar kandidat, ställ dig följande säkerhets- och hållbarhetsfrågor (namngivna verktyg eller tjänster är endast exempel, och även bra öppen källkod kan få dåligt resultat på vissa frågor):
Inledande bedömning
| Regel |
Beskrivning |
Genomfört |
| Överväg behov |
Utvärdera om beroendet kan undvikas genom att använda befintliga komponenter. Varje nytt beroende ökar attackytan (ett skadligt nytt beroendet, eller skadliga transitiva beroenden, kan skada systemets säkerhet). |
|
| Verifiera äkthet |
Verifiera att programvaran som utvärderas är en äkta version från en trovärdig källa, inte en personlig eller angriparkontrollerad gren (fork). Detta motverkar vanliga “typosquatting”-attacker (där en angripare skapar skadliga versioner av vanliga beroenden med “nästan korrekta” namn). Kontrollera beroendets namn och länken för projektets webbplats. Verifiera fork-förhållandet på GitHub/GitLab. Kontrollera om projektet är knutet till en stiftelse. Kontrollera när projektet skapats och dess popularitet. |
|
Underhåll och hållbarhet
Övergiven programvara utgör en risk; de flesta programvaror behöver kontinuerligt underhåll. Underhålls den inte, är den sannolikt osäker.
| Regel |
Beskrivning |
Genomfört |
| Aktivitetsnivå |
Bekräfta att betydande aktivitet (t.ex. commits) har skett det senaste året. |
|
| Kommunikation |
Verifiera att det finns nya utgåvor eller tillkännagivanden från projektets förvaltare. |
|
| Förvaltardiversitet |
Verifiera att det finns mer än en förvaltare, helst från olika organisationer (för att minska risken för enskilda felkällor). Observera dock att många brett använda projekt har bara en förvaltare. |
|
| Senaste utgåva |
Bekräfta att den senaste utgåvan inte är äldre än ett år. |
|
| Versionsstabilitet |
Bedöm om versionen visar på instabilitet (t.ex. börjar med “0”, inkluderar “alpha” eller “beta”, etc.). |
|
Säkerhetspraxis
| Regel |
Beskrivning |
Genomfört |
| Bedömningsramverk |
Överväg att använda etablerade bedömningsmetoder som SAFECode:s guide Principles for Software Assurance Assessment (2019), en flernivåansats för att undersöka programvarans säkerhet. |
|
| Certifiering av bästa praxis |
Avgör om projektet har förtjänat (eller är på god väg till) ett Open Source Security Foundation (OpenSSF) Best Practices-märke. |
|
| Hantering av beroenden |
Verifiera att projektets paketberoenden är (relativt) uppdaterade. |
|
| Kodförrådsäkerhet |
Bekräfta att utvecklarna använder säkerhetsfunktioner i kodsamverkansplattformen där tillämpligt (t.ex. om de använder GitHub eller GitLab, använder de grenskydd(branch-protection)). |
|
| Säkerhetsgranskningar |
Identifiera om programvaran säkerhetsgranskats och verifiera att upptäckta sårbarheter har åtgärdats. Säkerhetsgranskningar är relativt ovanliga, se exempelvis OpenSSF:s “Security reviews”. |
|
| Säker utveckling |
Bekräfta att projektet tillämpar bästa praxis för säker programvaruutveckling enligt Concise Guide for Developing More Secure Software eller OpenSSF Open Source Security Baseline. |
|
| Säkerhetsdokumentation |
Verifiera att det finns dokumentation som förklarar varför projektet är säkert (även kallat “assurans”). |
|
| Säkerhetsrespons |
Bedöm om projektet åtgärdar fel (särskilt säkerhetsfel) i tid, om de släpper säkerhetsuppdateringar för äldre utgåvor, och om de har en LTS-version (Long Term Support). |
|
| Säkerhetspoäng |
Granska information på https://deps.dev, inklusive dess OpenSSF Scorecards-poäng och eventuella kända sårbarheter. |
|
| Testpraxis |
Utvärdera om det finns automatiserade tester i dess CI-pipeline och vad projektets testtäckning är. |
|
| Sårbarhetsstatus |
Bekräfta om den aktuella versionen är fri från kända viktiga sårbarheter (särskilt äldre). Organisationer kan överväga att implementera OpenChain Security Assurance Specification 1.1 för att systematiskt kontrollera kända sårbarheter vid införande och när nya sårbarheter avslöjas offentligt. |
|
Användbarhet och säkerhet
| Regel |
Beskrivning |
Genomfört |
| Gränssnittsdesign |
Verifiera att gränssnittet/API:et är designat för enkel användning på ett säkert sätt. Exempelvis om gränssnittet implementerar ett programmeringsspråk som SQL, stöder det parameterfrågor (eng. structured queries). |
|
| Gränssnittsstabilitet |
Verifiera att gränssnittet/API:et är stabilt eller att projektet har en policy för att undvika och/eller hantera ändringar av gränssnitt/API:er som bryter kompatibilitet. Ett instabilt API är ett betydande hinder för att uppgradera till nyare versioner (t.ex. för att åtgärda sårbarheter). |
|
| Säkra standardinställningar |
Bekräfta att standardkonfigurationen och “enkla exempel” är säkra (t.ex. kryptering påslagen som standard i nätverksprotokoll). Om inte, undvik det. |
|
| Säkerhetsvägledning |
Verifiera om det finns vägledning om hur man använder det säkert. |
|
| Rapportering av sårbarheter |
Bekräfta om det finns instruktioner för hur man rapporterar sårbarheter. Se Guide för att implementera en process för sårbarhetsavslöjande i öppen källkods-projekt för vägledning till öppen källkodsprojekt. |
|
Användning och licensiering
Licensramverk har en betydande påverkan på säkerhets- och hållbarhetsställning. Projekt som saknar tydlig licensinformation uppvisar ofta brister i andra säkerhetsmässiga bästa praxis.
| Regel |
Beskrivning |
Genomfört |
| Licenstydlighet |
Verifiera att varje komponent har en licens, att det är en allmänt använd OSI-licens om det är öppen källkod, och att den är förenlig med din avsedda användning. Projekt som inte har tydlig licensinformation är mindre benägna att följa andra goda praxis som leder till säker programvara. |
|
| Namnverifiering |
Kontrollera om ett liknande namn är populärt - det kan indikera en typosquatting-attack. |
|
| Utbredning |
Bedöm om programvaran har en betydande användning. Välanvänd programvara är mer benägen att visa på hur man använder den på säkert sätt, och fler kommer att bry sig om dess säkerhet. |
|
| Lämplighet |
Välj programvara som är en bra lösning för ditt problem. Undvik Hypestyrd utveckling: Välj inte programvara enbart för att den används av stora företag eller för att den är senaste trenden. |
|
Praktisk testning
| Regel |
Beskrivning |
Genomfört |
| Beteendetestning |
Försök att lägga till beroendet som ett test, helst i en isolerad miljö. Uppvisar det skadligt beteende, t.ex. försöker det exfiltrera känslig data? |
|
| Beroendepåverkan |
Lägger det till oväntade eller onödiga indirekta beroenden i produktionen? Till exempel, inkluderar det produktionsberoenden som bara krävs under utveckling eller test istället? Om så är fallet, är förvaltarna villiga att åtgärda det? Varje nytt beroende är ett potentiellt supportproblem eller leveranskedjeattack, och det är därför klokt att ha så få sådana som möjligt. |
|
Kodutvärdering
Även en snabb granskning av programvaran (av dig, en anställd eller någon annan), tillsammans med senaste ändringarna, kan ge dig insikt. Överväg:
| Regel |
Beskrivning |
Genomfört |
| Kodfullständighet |
Utvärdera om det finns bevis på osäker/ofullständig programvara (t.ex. många TODO-kommentarer). |
|
| Kontroll av skadlig kod |
Analysera om det finns bevis på att programvaran är skadlig. Enligt Backstabber’s Knife Collection bör installationsskript/rutiner granskas för skadlig kod, kontrollera dataexfiltrering från ~/.ssh och miljövariabler, och leta efter kodade/fördolda värden som kan exekveras. Undersök de senaste committerna för misstänkt kod (en angripare kan ha lagt till dem nyligen). |
|
| Sandlådetestning |
Överväg att köra programvaran i en sandlåda (eng. sandbox) för att försöka utlösa och upptäcka skadlig kod. |
|
| Säkerhetsimplementationer |
När du granskar källkoden, finns det bevis i koden på att utvecklarna försökt att utveckla säker programvara (som rigorös inmatningsvalidering av utomstående data som inte är betrodd samt användning av parameterfrågor)? |
|
| Säkerhetsgranskningar |
Se OpenSSF:s lista över säkerhetsgranskningar. |
|
| Statisk analys |
Vilka är de “främsta” problemen som en statisk kodanalys rapporterar? |
|
| Testvalidering |
Överväg att köra alla definierade testfall för att säkerställa att programvaran klarar dem. |
|
Ytterligare resurser
Dokumenthistorik
| Datum |
Beskrivning |
| 2023-11-21 |
Första version |
| 2025-04-23 |
Omstrukturering |
Vi välkomnar förslag och förbättringar! Öppna ett ärende eller skicka en pull request.