Mjukvara är kärnan i alla moderna företag och är avgörande i alla aspekter av verksamheten. Nästan alla företag kommer att använda programvara med öppen källkod, medvetet eller på annat sätt, eftersom även proprietär programvara är beroende av bibliotek med öppen källkod. OpenUK Rapporten "State of Open" från 2022 visade att 89 % av företagen förlitade sig på programvara med öppen källkod, men inte alla är tydliga med detaljerna i programvaran de litar på.
Företag efterfrågar allt mer information om sin verksamhetskritiska programvara. Ansvarsfulla företag intresserar sig i detalj för sin mjukvaruförsörjningskedja och skapar en mjukvaruförteckning (SBOM) för varje applikation. Denna informationsnivå är avgörande för att när säkerhetsbrister identifieras i deras mjukvara kan de omedelbart vara säkra på vilken programvara och versioner som används och vilka system som påverkas. Kunskap är makt i dessa situationer!
Lita på volontärer
I slutet av 2021 ringde en säkerhetsrisk Log4Shell identifierades i ett mycket använt Java-loggningsramverk, Log4j. Eftersom detta är ett allmänt använt bibliotek med öppen källkod var sårbarheten väl publicerad och korrigeringar förväntades. Men den underhållare av projektet var frivilliga. De hade dagjobb och var inte jour för akuta säkerhetsåtgärder, även om ett stort antal system påverkades. Enbart denna sårbarhet uppskattades ha påverkat 93 % av företagsmolnmiljöer.
Vid den tiden fanns det en del negativ press om öppen källkod, men sanningen är att om detta var en komponent med sluten källkod, så kanske sårbarheten aldrig har varit allmänt känd, vilket lämnar organisationer öppna för attack. Bibliotekets karaktär av öppen källkod innebar att det kunde inspekteras, problemen hittas och råd från andra. Så, ja, underhållarna var inte jour för säkerhetsproblem i deras volontärprojekt. Den stora frågan är alltså: Hur hamnade vi i en situation där stora företag var beroende av mjukvara som var ansvaret för någon som gör något annat för att betala sina räkningar?
Försummelse av mjukvaruberoende är en riskabel verksamhet oavsett licensen för programvaran, men när den är öppen källkod och mycket använd, blir den särskilt farlig. Att hålla fast vid historien om en sårbarhet; problemet hade funnits i kodbasen i flera år, men upptäcktes inte. Verktyget som användes så flitigt fick faktiskt inte så stort stöd - och vad som hände sedan är historia.
Den här historien upprepas om och om igen, över så många företag som har kritiska beroenden men som inte vidtar åtgärder för att stödja vare sig underhållarna eller projekten själva. Att ha en SBOM för programvaran som används av ett företag innebär att de har informationen till hands. För organisationer som levererar programvara till andra är förväntningarna på att leverera SBOM tillsammans med koden alltmer normen.
Känn till beroenden för att bedöma risk
Att föra med sig kunskap om beroenden gör det lättare att bedöma risken förknippad med var och en. Dessa öppen källkodsprojekt är de enklaste att bedöma: besvaras problem och har det varit några utgåvor nyligen? Att kunna se underhållare och projektaktivitet för varje projekt ger god insikt om projektets hälsa.
Företag kan bidra till att minska riskerna genom att stödja de projekt som de är beroende av. Vissa projekt accepterar sponsring direkt via GitHub Sponsors-schemat, andra kanske istället uppskattar erbjudanden om hosting eller en säkerhetsrevision. Varje öppen källkodsprojekt uppskattar bidrag. Om ditt företag hade skapat det här biblioteket själv, skulle ingenjörerna inom företaget behöva fixa varje bugg själva.
Öppen källkod är mer som ett system för delat ägande. Vi behöver inte alla bygga samma sak upprepade gånger utan kan snarare bidra, vilket både är mindre ansträngning och leder till bättre kvalitet som resultat. En av de mest effektfulla saker som företag kan göra är att använda lite av sina tekniska resurser och bidra till buggfixar eller funktioner till projekt som är så kärnan i verksamheten.
Att hålla dina egna ingenjörer involverade i ett projekt har många fördelar. De lär känna det och kan hålla ett öga på nya funktioner, eller när en ny version är tillgänglig. Avgörande är att verksamheten har insikt i hälsan och statusen för det beroende projektet och är en del av det som håller det friskt, vilket minskar risken för verksamheten för ett problem med ett beroende. Ett antal organisationer, inklusive Aiven, har ett OSPO (programkontor för öppen källkod), med personal som är dedikerad till att bidra till eller till och med underhålla de projekt som används av organisationen. Dessa avdelningar bidrar ofta till företagets allmänna närvaro i ekosystemet med öppen källkod och gör det möjligt för andra anställda att engagera sig med öppen källkod.
Ett annat tillvägagångssätt är att stödja de organisationer som finns för att stödja öppen källkod. De OpenSSF (Open Source Security Foundation) arbetar för att förbättra säkerheten för projekt med öppen källkod och finansieras av de organisationer som är beroende av dessa projekt. Den publicerar också utmärkta lärresurser så att företag kan utbilda sig själva om riskerna med programvaran de använder. En annan liknande organisation är Tidlyft, som samarbetar med underhållare för att säkerställa att vissa grundläggande krav uppfylls, återigen finansierat av organisationerna. Tidelift tillhandahåller också verktyg och utbildning för att hjälpa företag att hantera sin mjukvaruförsörjningskedja och anta bästa praxis på detta område.
Säkra en säkrare mjukvaruframtid
Företag är beroende av mjukvara, och detta inkluderar programvara med öppen källkod, som är mycket använd och vanligtvis säkrare än proprietära alternativ.
Detta är ett smart drag, men ett ännu smartare drag är att ha tydlig kunskap om mjukvaruförsörjningskedjan och dess beroenden. När ett problem uppstår, beroende på sunda projekt och att ha information om din programvara tillgänglig hjälper varje organisation. Om varje organisation gjorde detta, minskar risken för händelser som Log4Shell-sårbarheten.
