Ryzyko Licencyjne Ukryte w Waszych Instalacjach Homebrew

Niemal każda rozmowa o bezpieczeństwie Homebrew prędzej czy później schodzi na CVE i niebezpieczne narzędzia. Prawie żadna nie dochodzi do licencji — dopóki dział prawny nie znajdzie biblioteki na licencji copyleft ukrytej w produkcie komercyjnym, zwykle podczas audytu albo, co gorsza, w trakcie due diligence przy przejęciu firmy.

To zły moment na takie odkrycie. To też coś, czemu da się całkowicie zapobiec.

Ryzyko, którego nikt nie pilnuje

Kiedy deweloper instaluje pakiet, tym samym akceptuje licencję, na jakiej jest on dystrybuowany — świadomie czy nie. Najczęściej nie ma problemu: MIT, Apache, BSD. Czasem jest. Zależność na licencji GPL lub AGPL niesie ze sobą realne zobowiązania prawne dotyczące tego, jak możecie dystrybuować oprogramowanie, które z niej korzysta — a te zobowiązania nie pytają o zgodę, zanim przyczepią się do waszego kodu.

To, co najczęściej zaskakuje firmy: rzadko chodzi o pakiet, który deweloper faktycznie zainstalował. Chodzi o coś, od czego ten pakiet po cichu zależy. Nikt tego nie wybrał, nikt tego nie sprawdził — a kiedy wychodzi to na jaw podczas audytu, jest już wbudowane w wydany produkt.

Kontrole na poziomie pakietów tego nie wyłapują, bo odpowiadają na złe pytanie. Zablokowanie nmap, bo to narzędzie do skanowania sieci, to decyzja bezpieczeństwa dotycząca jednego konkretnego narzędzia. Nic w tym modelu nie pilnuje klauzuli licencyjnej zakopanej trzy zależności głębiej.

Dlaczego to drogo kosztuje

Ryzyko licencyjne nie objawia się jako incydent. Objawia się jako wstrzymane przejęcie, ustalenie audytowe bez łatwego rozwiązania albo polecenie dla zespołu inżynieryjnego, żeby wyrwał i zastąpił zależność, gdy produkt jest już wydany. To wszystko jest dużo trudniejsze i droższe niż zapobiegnięcie instalacji od razu. I nie jest to decyzja, którą IT może podjąć samodzielnie — o tym, które licencje są akceptowalne, decyduje dział prawny.

Na tym polega prawdziwa luka: prawnicy ustalają politykę, ale nie mają jak jej wyegzekwować w jedynym momencie, w którym to naprawdę ma znaczenie — przy instalacji.

Zamykanie luki

EnterpriseBrew zamienia politykę licencyjną w coś, co jest faktycznie egzekwowane, a nie w dokument, którego nikt nie czyta. Dział prawny decyduje, które warunki licencyjne są niedopuszczalne — GPL, AGPL, cokolwiek mówi polityka — a każda instalacja w całej firmie jest automatycznie sprawdzana pod kątem tej reguły, łącznie z tym wszystkim, co dany pakiet po cichu ze sobą ciągnie. Można też odwrócić model: zdefiniować licencje zatwierdzone, a wszystko inne zostanie domyślnie zablokowane.

Niezależnie od wybranego modelu, to reguła obowiązująca całą firmę, a nie ustawienie zespołu, z którego ktoś może się wyłączyć. Wyjątek bezpieczeństwa dla jednego inżyniera ma sens. Wyjątek prawny dla jednego laptopa — nie ma, bo zobowiązanie powstaje w momencie użycia kodu, a nie w momencie, gdy ktoś to zauważy.

Efekt

Zamiast odkrywać problem licencyjny po wydaniu produktu, dany pakiet po prostu nigdy się nie instaluje. Dział prawny definiuje politykę raz. IT nie musi jej ręcznie pilnować, a deweloperzy nie muszą stawać się ekspertami od licencji, żeby zachować zgodność — sprawdzenie odbywa się automatycznie, zanim cokolwiek trafi na maszynę.

Kolejny audyt przestaje być gonitwą z czasem, żeby ustalić, co jest zainstalowane i na co was to naraża. Odpowiedź jest już wyegzekwowana.