Internet stoi na open source. Dane o lukach są rozproszone po ponad 40 bazach

OSV, baza Open Source Vulnerabilities prowadzona przy Google, sama nie trzyma biuletynów. Zbiera je z innych źródeł. Na jej stronie głównej widać liczniki ekosystemów, które wyglądają jak spis wszystkiego, z czego zbudowane jest współczesne oprogramowanie: npm z 228 732 biuletynami, Chainguard z 1 023 658, Wolfi z 288 261, MinimOS z 144 169, GIT ze 108 035, Debian z 68 356, Ubuntu z 65 370. To liczby biuletynów na ekosystem, nie unikalnych błędów. Ta sama wada może wystąpić w kilku z nich.

Właśnie na tym nakładaniu się źródeł opiera się cały pomysł. Serwis opisuje siebie jako "open, precise, and distributed approach to producing and consuming vulnerability information for open source", zbudowane na schemacie OpenSSF OSV. Schemat istnieje po to, żeby lukę można było przypisać "precisely to open source package versions or commit hashes", a nie do mglistych nazw produktów. Wpis CISA o OSV mówi wprost o koszcie narzędziowym: "requires a Google Cloud Platform and Google Group account."

Prawdziwe incydenty pokazują, dlaczego precyzja na poziomie wersji ma znaczenie.

Log4Shell, CVE-2021-44228, dostał 10.0 w skali CVSS. Jak podaje analiza ryzyk open source firmy Safeguard, przez ponad rok po pojawieniu się poprawki wykorzystywali go "ransomware crews and state-sponsored actors". Backdoor w XZ Utils, CVE-2024-3094, też dostał 10.0. Znaleziono go przypadkiem 29 marca 2024. Współpracownik posługujący się nazwą "Jia Tan" przez ponad dwa lata budował historię commitów i zaufanie. Kod zdążył trafić do Debiana testing i do przedwydań Fedory 40/41. Heartbleed, CVE-2014-0160, ujawnił klucze prywatne na około 500 000 serwerów w kwietniu 2014. Włamanie do Equifax w 2017 roku zaczęło się od niezałatanej luki w Apache Struts, CVE-2017-5638, a koszty ugód i naprawy sięgnęły 1,4 mld dolarów.

Łatanie nie jest wąskim gardłem

Opracowanie Safeguard zwraca uwagę na rozróżnienie, które ginie w pulpitach z ocenami zagrożeń: problemem rzadko jest brak poprawki. Problem w tym, że organizacje nie potrafią ustalić, które działające usługi faktycznie wywołują podatną funkcję. Łatanie spada więc na dalszy plan w kolejce, w której wszystko wygląda równie pilnie. Katalog Known Exploited Vulnerabilities prowadzony przez CISA obejmuje tylko CVE z potwierdzonym aktywnym wykorzystaniem. W 2025 roku przekroczył 1 300 pozycji, a dużą część stanowią szeroko wbudowane komponenty open source, takie jak Apache, OpenSSL i Spring.

Głębokość zależności jeszcze to pogarsza. Raport Synk State of Open Source Security z 2020 roku, cytowany przez Safeguard, wykazał, że przeciętny projekt w JavaScripcie ciągnie za sobą 683 zależności, z czego 79% to zależności przechodnie. Raport Synopsys Open Source Security and Risk Analysis z 2024 roku oszacował open source na 70% do 90% kodu we współczesnych aplikacjach. Przewodnik SentinelOne ujmuje ten sam problem jako kwestię zarządzania: skuteczne programy wymagają mapowania zależności, automatycznego egzekwowania polityk, które oznacza lub blokuje kompilacje, oraz oceny ryzyka, żeby zdecydować, co naprawić najpierw, gdy brakuje ludzi i czasu.

Do tego dochodzi warstwa ludzka. W marcu 2016 roku deweloper Azer Koçulu usunął left-pad, jedenastolinijkowy pakiet npm, w sporze o nazwę. W ciągu kilku godzin kompilacje w ekosystemie JavaScriptu się posypały, dopóki npm nie przywrócił pakietu. Log4j siedział w szacunkowo setkach tysięcy aplikacji, a utrzymywał go głównie niewielki zespół wolontariuszy. Główny opiekun Volkan Yazıcı mówił publicznie, że zespół zajął się reakcją na Log4Shell praktycznie bez wynagrodzenia. Na pracę wolontariuszy nie ma SLA.

Licencje niosą własne ryzyko. Software Freedom Conservancy pozwał Vizio w 2021 roku w sprawie kodu GPL w jego telewizorach. W lutym 2024 roku sąd apelacyjny w Kalifornii orzekł, że warunki GPL można wyegzekwować jako prawa kontraktowe beneficjenta trzeciego.

Naprawa kodu to jedno zadanie. Znalezienie go to drugie

Narzędzia wokół warstwy bazowej się konsolidują. OSV-Scanner, instalowany przez Go, skanuje SBOM-y, pliki lock, katalogi projektów i obrazy kontenerów. Dostarcza też gotowe workflow GitHuba, żeby potoki CI/CD mogły sprawdzać nowo dodane zależności w pull requestach i uruchamiać regularne skany w całym projekcie. API odpowiada na zapytania po hashu commita albo po wersji pakietu, z przykładowymi wywołaniami dla SHA commita lub dla jinja2 2.4.1 w PyPI. OSV-Scanner ma też tryb naprawy ze strategiami w miejscu i relock dla package-lock.json.

Nie każdy projekt goni za tym samym wskaźnikiem. typed-lm, projekt w Rustcie opublikowany na GitHubie, idzie inną drogą. Zamienia gęste modele dekoderowe, w tym Llama, Qwen2, Qwen3, Mistral, Gemma, Gemma2 i Gemma3, w typowane API routingu semantycznego, które zwraca wartości logiczne, wybory i wyniki zamiast generowanego tekstu. README twierdzi, że pojedynczy przebieg w przód oznacza milisekundy, a nie sekundy, i publikuje tabele opóźnień dla jednej karty RTX 3070 z wagami F16. Na CPU podaje, że prefill 1024 tokenów spada z 28,23 sekundy do 13,13 sekundy przy włączonym CPU flash i MKL, i zaleca checkpoint GGUF Q4_K_M z funkcją mkl. To liczby publikowane przez projekt, niezweryfikowane niezależnie.

Ekonomia pod tym wszystkim jest nieustalona. W sierpniu 2026 roku deweloper Debamitro opisał wywiad z Christianem Hammondem, założycielem i prezesem ReviewBoard, i wyszedł z nieoczywistym wnioskiem: firmy płacą za ReviewBoard "not because it is open source, but despite it being open source." Klienci płacą za wsparcie, a niektórzy za wersję hostowaną. Hammond powiedział mu też, że użycie ReviewBoard spada w części firm, które rezygnują z przeglądów kodu, i przekonywał, że języki programowania, a ogólnie oprogramowanie bazowe, powinny być open source.

To zostawia problem luk tam, gdzie był: rozłożony po ponad czterdziestu bazach ekosystemów, z których większość utrzymują ci sami nieopłacani lub słabo finansowani ludzie, którzy w ogóle piszą ten kod. Agregacja pomaga. Nie zamyka jednak luki między opublikowanym biuletynem a organizacją, która wie, czy podatna funkcja działa na produkcji.