Hoppa till innehåll
← Tillbaka till bloggen
policyefterlevnadlicenserhomebrewenterprise

Licensrisken Som Gömmer Sig i Era Homebrew-installationer

Öppen källkod-licenser som GPL och AGPL innebär en verklig juridisk risk för kommersiell mjukvara — och de smyger sig in via beroenden som ingen har granskat. Så här täpper ni till gapet utan att sakta ner utvecklarna.

EnterpriseBrew Team··3 min läsning

Nästan alla säkerhetsdiskussioner om Homebrew hamnar förr eller senare i CVE:er och farliga verktyg. Nästan ingen kommer fram till licensiering — förrän juristerna hittar ett bibliotek med copyleft-licens inbäddat i en kommersiell produkt, oftast vid en revision eller, ännu värre, under en due diligence inför ett företagsförvärv.

Det är ett dåligt tillfälle att upptäcka det på. Det är också fullt möjligt att förhindra.

Risken ingen bevakar

När en utvecklare installerar ett paket godkänner hen samtidigt licensen paketet levereras under, medveten om det eller inte. Oftast är det inget problem: MIT, Apache, BSD. Ibland är det det. Ett beroende med GPL- eller AGPL-licens medför verkliga juridiska skyldigheter kring hur ni får distribuera mjukvara som använder det — och de skyldigheterna frågar inte om lov innan de fastnar i er kodbas.

Det som tar de flesta företag på sängen: det är sällan paketet utvecklaren faktiskt installerade. Det är något det paketet i tysthet är beroende av. Ingen valde det, ingen granskade det — och när det dyker upp i en revision sitter det redan inbyggt i en levererad produkt.

Kontroller på paketnivå fångar inte det här, eftersom de svarar på fel fråga. Att blockera nmap för att det är ett nätverksskanningsverktyg är ett säkerhetsbeslut om ett specifikt verktyg. Ingenting i den modellen bevakar en licensklausul begravd tre beroenden ner.

Varför det blir dyrt

Licensrisk visar sig inte som en incident. Den visar sig som ett förvärv som stannar upp, ett revisionsfynd utan enkel lösning, eller ett besked till utvecklingsteamet att riva ut och ersätta ett beroende efter att produkten redan levererats. Allt det är svårare och dyrare än att förhindra installationen från början. Och det är inget IT kan avgöra på egen hand — vilka licenser som är acceptabla är en juridisk fråga.

Det är själva gapet: juristerna sätter policyn, men har inget sätt att genomdriva den där det faktiskt spelar roll — vid installationstillfället.

Att täppa till gapet

EnterpriseBrew gör en licenspolicy till något som faktiskt tillämpas, inte bara ett dokument som ligger orört. Juristerna avgör vilka licensvillkor som är oacceptabla — GPL, AGPL, vad policyn nu säger — och varje installation i hela företaget kontrolleras automatiskt mot den regeln, inklusive allt paketet i tysthet drar med sig. Ni kan även vända på modellen: definiera godkända licenser, så blockeras allt annat som standard.

Oavsett vilken modell ni väljer gäller regeln hela företaget — det är inget teaminställning man kan välja bort. Ett säkerhetsundantag för en enskild utvecklare är rimligt. Ett juridiskt undantag för en enskild dator är det inte — skyldigheten uppstår i det ögonblick koden används, inte när någon råkar upptäcka det.

Resultatet

Istället för att upptäcka ett licensproblem efter att produkten redan levererats installeras paketet aldrig. Juristerna definierar policyn en gång. IT behöver inte bevaka den manuellt, och utvecklare behöver inte bli licensexperter för att hålla sig compliant — kontrollen sker automatiskt, innan något ens når en maskin.

Nästa revision blir inte en stressad jakt på vad som är installerat och vad det exponerar er för. Svaret är redan genomdrivet.

Relaterade inlägg