Zaniedbywanie programistów Open Source naraża Internet na ryzyko

Oprogramowanie jest podstawą wszystkich nowoczesnych przedsiębiorstw i ma kluczowe znaczenie w każdym aspekcie działalności. Prawie każda firma będzie korzystać z oprogramowania open source, świadomie lub w inny sposób, ponieważ nawet oprogramowanie własnościowe zależy od bibliotek open source. OpenUK Raport „State of Open” z 2022 r. wykazał, że 89% firm polegało na oprogramowaniu typu open source, ale nie wszystkie z nich mają jasność co do szczegółów oprogramowania, na którym polegają.

Firmy coraz częściej domagają się większej ilości informacji na temat ich oprogramowania o znaczeniu krytycznym. Odpowiedzialne firmy szczegółowo interesują się swoim łańcuchem dostaw oprogramowania i tworzą zestawienie komponentów oprogramowania (SBOM) dla każdej aplikacji. Ten poziom informacji ma kluczowe znaczenie, aby po wykryciu luk w zabezpieczeniach w ich oprogramowaniu, mogli oni od razu mieć pewność, które oprogramowanie i wersje są używane oraz których systemów dotyczy. W takich sytuacjach wiedza to potęga!

Poleganie na wolontariuszach

Pod koniec 2021 r. pojawiła się luka w zabezpieczeniach o nazwie Log4Shell został zidentyfikowany w powszechnie używanym frameworku rejestrowania Java, Log4j. Ponieważ jest to szeroko stosowana biblioteka typu open source, luka została dobrze nagłośniona i oczekiwano poprawek. Jednakże opiekunami projektu byli wolontariusze. Mieli pracę na co dzień i nie byli wzywani do pilnych poprawek bezpieczeństwa, nawet jeśli dotyczyło to dużej liczby systemów. Szacuje się, że sama ta luka dotknęła 93% korporacyjnych środowisk chmurowych.

W tym czasie pojawiła się negatywna prasa na temat open source, ale prawda jest taka, że ​​jeśli był to komponent o zamkniętym kodzie źródłowym, luka w zabezpieczeniach mogła nigdy nie być publicznie znana, co narażało organizacje na ataki. Otwarty charakter biblioteki oznaczał, że można ją było przejrzeć, znaleźć problemy i uzyskać porady od innych. Więc tak, opiekunowie nie byli proszeni o problemy z bezpieczeństwem w swoim projekcie wolontariackim. Wielkie pytanie brzmi zatem: jak doszliśmy do sytuacji, w której duże firmy były zależne od oprogramowania, które było obowiązkiem kogoś, kto robi coś innego, aby zapłacić rachunki?

Zaniedbanie zależności oprogramowania jest ryzykownym biznesem bez względu na licencję oprogramowania, ale gdy jest to oprogramowanie typu open source i bardzo szeroko stosowane, staje się szczególnie niebezpieczne. Trzymanie się historii jednej słabości; problem istniał w kodzie od lat, ale nie został zauważony. Narzędzie, które było tak powszechnie używane, nie było w rzeczywistości tak szeroko obsługiwane — i co stało się potem to historia.

Ta historia powtarza się w kółko w tak wielu firmach, które mają krytyczne zależności, ale nie podejmują działań w celu wsparcia ani opiekunów, ani samych projektów. Posiadanie SBOM dla oprogramowania używanego przez firmę oznacza, że ​​mają pod ręką informacje. W przypadku organizacji, które dostarczają oprogramowanie innym, oczekiwanie dostarczenia SBOM wraz z kodem staje się coraz bardziej normą.

Poznaj zależności, aby ocenić ryzyko

Znajomość zależności ułatwia ocenę ryzyka związanego z każdą z nich. Te projekty open source są najłatwiejsze do oceny: czy problemy zostały rozwiązane i czy pojawiły się ostatnio jakieś wersje? Możliwość zobaczenia opiekunów i aktywności projektu dla każdego projektu daje dobry wgląd w stan projektu.

Firmy mogą odegrać swoją rolę w zmniejszaniu ryzyka, wspierając projekty, od których są uzależnione. Niektóre projekty akceptują sponsorowanie bezpośrednio przez program sponsorów GitHub, inne mogą zamiast tego docenić oferty hostingu lub audytu bezpieczeństwa. Każdy projekt open source docenia wkład. Gdyby Twoja firma sama stworzyła tę bibliotekę, inżynierowie w firmie musieliby sami naprawić każdy błąd.

Open source jest bardziej jak schemat współwłasności. Nie wszyscy musimy wielokrotnie budować to samo, ale raczej możemy przyczynić się do tego, co jest zarówno mniejszym wysiłkiem, jak i prowadzi do lepszej jakości. Jedną z najbardziej znaczących rzeczy, jakie mogą zrobić firmy, jest wykorzystanie niewielkiej ilości zasobów inżynieryjnych i przyczynić się do poprawek błędów lub funkcji do projektów które są tak istotne dla biznesu.

Utrzymywanie własnych inżynierów zaangażowanych w projekt ma wiele zalet. Poznają go i mogą obserwować nowe funkcje lub dostępność nowej wersji. Co najważniejsze, firma ma wgląd w kondycję i status zależnego projektu i jest częścią tego, co utrzymuje go w dobrym stanie, zmniejszając ryzyko dla firmy związane z problemem z zależnością. Szereg organizacji, w tym Aiven, posiada OSPO (biuro programu open source), którego personel zajmuje się współpracą, a nawet utrzymaniem projektów wykorzystywanych przez organizację. Działy te często przyczyniają się do ogólnej obecności firmy w ekosystemie open source i umożliwiają innym pracownikom angażowanie się w open source.

Innym podejściem jest wspieranie organizacji, które istnieją, aby wspierać open source. The OpenSSF (Fundacja Bezpieczeństwa Open Source) działa na rzecz poprawy bezpieczeństwa projektów open source i jest finansowany przez organizacje zależne od tych projektów. Publikuje również doskonałe zasoby edukacyjne, dzięki którym firmy mogą edukować się na temat zagrożeń związanych z używanym oprogramowaniem. Inną podobną organizacją jest Odpływ pływowy, który współpracuje z opiekunami, aby zapewnić spełnienie pewnych podstawowych wymagań, ponownie finansowany przez organizacje. Tidelift zapewnia również narzędzia i edukację, aby pomóc firmom zarządzać łańcuchem dostaw oprogramowania i stosować najlepsze praktyki w tym obszarze.

Zapewnienie bezpieczniejszej przyszłości oprogramowania

Firmy są zależne od oprogramowania, w tym oprogramowania typu open source, które jest powszechnie używane i zazwyczaj jest bezpieczniejsze niż zastrzeżone alternatywy.

To sprytne posunięcie, ale jeszcze mądrzejszym posunięciem jest posiadanie jasnej wiedzy na temat łańcucha dostaw oprogramowania i jego zależności. Kiedy pojawia się problem, w zależności od zdrowych projektów i dostępności szczegółów oprogramowania pomaga każdej organizacji. Jeśli każda organizacja to zrobiła, ryzyko wystąpienia zdarzeń, takich jak luka Log4Shell, jest zmniejszone.