1 godzina temu
Open source daje przedsiębiorstwom większą swobodę technologiczną, ale wraz z kodem przekazuje im coś jeszcze: część odpowiedzialności za komponenty, których same nie stworzyły i nad których dalszym rozwojem często nie mają żadnej kontroli.
Skala tej zależności jest ogromna. Census III, przygotowany przez Linux Foundation, OpenSSF i badaczy związanych z Harvardem, powstał na podstawie ponad 12 mln obserwacji wykorzystania bibliotek open source w 2023 roku. Dane dostarczyły cztery firmy zajmujące się analizą składu oprogramowania: FOSSA, Snyk, Sonatype i Black Duck. To nie jest statystycznie reprezentatywny obraz całej gospodarki, ponieważ baza pochodzi z systemów klientów tych firm, ale należy do najbardziej rozbudowanych empirycznych analiz wykorzystania open source w środowiskach produkcyjnych.
Najciekawszy wynik nie dotyczy jednak liczby bibliotek, ale ludzi, którzy je rozwijają.
Badacze przeanalizowali 47 spośród 50 najczęściej używanych projektów spoza ekosystemu npm. W 17 proc. z nich jeden programista odpowiadał za ponad 80 proc. commitów wykonanych w 2023 roku. W 40 proc. projektów taki udział przypadał najwyżej na dwóch deweloperów, a w 64 proc. — na czterech.
Powstaje osobliwa asymetria. System obsługujący działalność dużej organizacji może być formalnie otwarty, szeroko używany i rozwijany publicznie, a jednocześnie jego istotny element pozostaje zależny od pracy kilku osób. Otwartość kodu ogranicza zależność od jednego właściciela technologii, ale nie eliminuje zależności jako takiej.
Cena pojawia się poza licencją
Dobrze widać to w danych Black Duck. W audytach OSSRA 2026 open source znaleziono w 98 proc. z 947 przeanalizowanych komercyjnych baz kodu. Przeciętna badana aplikacja zawierała 1180 komponentów open source, o 30 proc. więcej niż rok wcześniej. W 87 proc. baz wykryto co najmniej jedną znaną podatność, a w 78 proc. przynajmniej jedną podatność wysokiego ryzyka.
Tych liczb nie należy ekstrapolować na cały rynek. Black Duck analizuje projekty trafiające do jego usług audytowych, więc próba jest selektywna. Pokazuje jednak mechanizm istotniejszy niż sam odsetek podatności: wraz ze wzrostem liczby zależności rośnie obszar, nad którym trzeba zachować kontrolę.
Koszt open source nie mieści się więc wyłącznie w utrzymaniu kodu. Obejmuje także wiedzę o tym, co adekwatnie znajduje się w środowisku, w których wersjach, z jakimi zależnościami, na jakich licencjach i według jakiej procedury zostanie zastąpione, gdy projekt straci wsparcie.
Log4j pokazał, iż problemem bywa brak wiedzy
Incydent Log4Shell z 2021 roku jest pod tym względem bardziej pouczający niż sama skala podatności. Cyber Safety Review Board, po analizie informacji z kilkudziesięciu organizacji, wskazał, iż przedsiębiorstwa miały problemy z szybkim ustaleniem, gdzie podatny Log4j znajdował się w ich środowiskach. Część organizacji była zależna od informacji przekazywanych przez własnych dostawców.
Co istotne, choćby Software Bill of Materials nie okazał się wówczas prostym rozwiązaniem. Organizacje korzystające z SBOM, z którymi rozmawiał Board, nie raportowały wykorzystania tych dokumentów do odnalezienia podatnych instalacji Log4j. Problemem były m.in. niespójne dane, brak informacji o wersjach i niedostateczna automatyzacja.
Sam spis komponentów ma więc ograniczoną wartość, jeżeli organizacja nie potrafi przełożyć go na działanie.
XZ Utils w 2024 roku pokazał drugą stronę tego samego problemu. Złośliwy kod trafił do archiwów źródłowych wersji 5.6.0 i 5.6.1 jednej z powszechnie używanych bibliotek. Incydent został wykryty stosunkowo wcześnie i nie objął stabilnych wersji Red Hat Enterprise Linux, ale odsłonił ryzyko znajdujące się wcześniej niż klasyczna podatność: możliwość naruszenia samego procesu tworzenia komponentu.
Odpowiedzialność staje się bardziej formalna
Cyber Resilience Act dodatkowo podnosi znaczenie wiedzy o łańcuchu oprogramowania. Od 11 września 2026 roku producenci objęci regulacją muszą zgłaszać aktywnie wykorzystywane podatności i poważne incydenty bezpieczeństwa, z pierwszym ostrzeżeniem wymaganym co do zasady w ciągu 24 godzin. Dla open-source software stewards odpowiednie obowiązki raportowe zaczną obowiązywać 11 grudnia 2027 roku.
Nie oznacza to, iż open source staje się mniej atrakcyjny. Wręcz przeciwnie: dostęp do kodu, interoperacyjność i możliwość zmiany dostawcy pozostają realnymi atutami. Nie należy jednak mylić swobody wyboru z brakiem kosztu.
Najbardziej dojrzałe pytanie nie brzmi już więc, czy technologia jest otwarta czy zamknięta. Ważniejsze jest, kto odpowiada za jej aktualizację, bezpieczeństwo i ciągłość rozwoju — oraz czy ta odpowiedzialność została rzeczywiście przypisana, czy tylko domyślnie pozostawiona organizacji.
