Licensrisikoen, Der Gemmer Sig i Jeres Homebrew-installationer
Open source-licenser som GPL og AGPL udgør en reel juridisk risiko for kommerciel software — og de sniger sig ind via afhængigheder, som ingen har gennemgået. Sådan lukker I hullet uden at bremse udviklerne.
Stort set alle sikkerhedssamtaler om Homebrew ender ved CVE'er og farlige værktøjer. Næsten ingen når frem til licensering — før jura finder et copyleft-licenseret bibliotek gemt inde i et kommercielt produkt, som regel under en revision, eller værre, midt i en due diligence-proces ved et virksomhedsopkøb.
Det er et dårligt tidspunkt at opdage det på. Det er også fuldt ud til at forebygge.
Risikoen ingen holder øje med
Når en udvikler installerer en pakke, accepterer vedkommende samtidig den licens, pakken bliver leveret under — uanset om de er klar over det eller ej. Som regel er det uproblematisk: MIT, Apache, BSD. Nogle gange er det ikke. En afhængighed med GPL- eller AGPL-licens medfører reelle juridiske forpligtelser for, hvordan I må distribuere software, der bruger den — og de forpligtelser spørger ikke om lov, før de hægter sig fast i jeres kodebase.
Det, der tager de fleste virksomheder på sengen: det er sjældent selve pakken, udvikleren installerede. Det er noget, den pakke stille og roligt afhænger af. Ingen har valgt det, ingen har gennemgået det — og når det dukker op ved en revision, sidder det allerede indbygget i et produkt, der er sendt ud.
Kontroller på pakkeniveau fanger ikke det her, fordi de svarer på det forkerte spørgsmål. At blokere nmap, fordi det er et netværksscanningsværktøj, er en sikkerhedsbeslutning om ét bestemt værktøj. Intet i den model holder øje med en licensklausul begravet tre afhængigheder nede.
Hvorfor det bliver dyrt
Licensrisiko viser sig ikke som en hændelse. Den viser sig som et opkøb, der går i stå, et compliance-fund uden nem løsning, eller en besked til udviklingsteamet om at rive en afhængighed ud og erstatte den, efter produktet allerede er sendt ud. Alt sammen sværere og dyrere end at forhindre installationen fra starten. Og det er ikke noget, IT kan afgøre alene — hvilke licenser der er acceptable, er en juridisk beslutning.
Det er selve hullet: jura fastsætter politikken, men har ingen måde at håndhæve den på det ene tidspunkt, hvor det faktisk betyder noget — ved installationen.
At lukke hullet
EnterpriseBrew gør en licenspolitik til noget, der rent faktisk håndhæves, ikke bare et dokument, ingen kigger på. Juraafdelingen beslutter, hvilke licensvilkår der er uacceptable — GPL, AGPL, hvad politikken end siger — og hver eneste installation i hele virksomheden bliver automatisk tjekket op mod den regel, inklusive alt det, pakken stille trækker med sig. I kan også vende modellen om: definer de godkendte licenser, så bliver alt andet blokeret som standard.
Uanset hvilken model I vælger, gælder reglen hele virksomheden — det er ikke en teamindstilling, man kan fravælge. En sikkerhedsundtagelse til én udvikler giver mening. En juridisk undtagelse til én bærbar gør ikke — forpligtelsen opstår i det øjeblik koden bruges, ikke i det øjeblik nogen opdager det.
Resultatet
I stedet for at opdage et licensproblem, efter produktet er sendt ud, bliver pakken aldrig installeret. Jura definerer politikken én gang. IT skal ikke overvåge den manuelt, og udviklere skal ikke være licenseksperter for at være compliant — tjekket sker automatisk, før noget som helst når en maskine.
Den næste revision bliver ikke et stressende kapløb for at finde ud af, hvad der er installeret, og hvad det udsætter jer for. Svaret er allerede håndhævet.