Branża IT zwleka z SBOM-ami, podczas gdy powinna pracować nad najlepszymi praktykami

Ludzką naturą jest sprzeciwianie się przepisom: nawet jeśli wiemy, że coś jest najlepsze, nie lubimy, gdy nam to narzuca się.

Rząd Stanów Zjednoczonych nałożył regulacje dotyczące zestawień materiałów oprogramowania (SBOM), w ramach których opracowano „przepisy” na oprogramowanie. Zasadniczo kluczowe elementy umożliwiające stworzenie mądrzejszego sposobu identyfikowania potencjalnych problemów związanych z bezpieczeństwem. Nic dziwnego, że istnieją negatywne reakcje i uczucia na temat tej organizacji.

W odpowiedzi Rada ITI, wpływowa osoba w przestrzeni technologicznej, określiła SBOM jako „niegotowe” i że cała rozmowa musi być bardziej „dojrzała”, zanim branża IT będzie mogła rozważyć dodatkowe obciążenie związane z tworzeniem i utrzymywaniem tych rejestrów – zwłaszcza Regulamin nie określa kryteriów, jakie będą stosowane.

To bardzo wątpliwe podejście. Sektor IT nie powinien opierać się temu rozporządzeniu, ale powinien go przyjąć z radością, przewodzić jego wdrażaniu i stworzyć wokół niego dojrzałą debatę, a nie tylko czekać, aż to nastąpi.

Stan SBOMów
Zestawienia materiałów nie są nowym pomysłem. Znane również jako listy składników lub receptury produktów, są powszechne w produkcji – zorganizowana, ujednolicona lista wszystkiego, co jest potrzebne do wytworzenia produktu.

W produkcji elementy te są niezbędne do planowania operacji zakupowych, a także stanowią pierwszy punkt kontaktowy w przypadku błędu lub innego problemu. Jeśli składnik okaże się wadliwy, łatwo jest ustalić, w którym produkcie zastosowano ten składnik i zainicjować wycofanie produktu z rynku lub podjęcie innych odpowiednich działań.

SBOM to lista wszystkich komponentów open source i komponentów innych firm zawartych w oprogramowaniu, ale to także coś więcej: zawiera numery wersji, licencje i status poprawek każdego komponentu. Podobnie jak w produkcji, staje się to kluczowym materiałem referencyjnym, gdy coś pójdzie nie tak. Firmy korzystające z oprogramowania typu open source mogą natychmiast zidentyfikować, gdzie mogą znajdować się luki w zabezpieczeniach, jeśli coś pójdzie nie tak.

Jest to ważne, ponieważ niezależnie od tego, jak profesjonalne jest oprogramowanie typu open source, opiera się ono na fundamencie społeczności i zawsze należy pamiętać o entuzjastach. Tak więc, choć największe nazwiska w branży technologicznej mogą opracowywać narzędzia oparte na zasadach open source i hostować je na platformach open source, opierają się na kodzie, który mógł zostać zrzucony razem w ramach projektu pobocznego i nie jest tak aktywnie utrzymywany jak inny kod.

Luka Log4Shell jest doskonałym przykładem. Log4j, jak sama nazwa wskazuje, służy do rejestrowania błędów i zdarzeń oraz raportowania ich administratorom. Jeśli ktoś odwiedzi witrynę internetową i otrzyma błąd 404, zostanie to prawdopodobnie zarejestrowane przez Log4j – jeśli wystąpi kilka takich błędów, oznacza to problem. Jego użyteczność sprawiła, że ​​stał się wszechobecny, co, przewrotnie, sprawiło, że stał się nieco niejasny — wirtualny program używany wszędzie, o którym nikt tak naprawdę nie pomyślał. Kiedy odkryto, że Log4j może służyć do wstrzykiwania kodu, oznaczało to, że miliony serwerów mogą zostać zaatakowane i przejęte. Baza danych podatności NIST przyznaje Log4Shell ocenę CVSS (Common Vulnerability Scoring System) na poziomie 10, co jest najwyższą możliwą oceną.

Wszechobecność Log4j oznaczała, że ​​z drugiej strony łatwo było stwierdzić, czy łatka jest potrzebna, czy nie, ponieważ prawie każdy serwer wymagał aktualizacji. W przyszłości luki w zabezpieczeniach mogą nie być tak powszechne, ale nadal są powszechne, co czyni SBOM niezwykle cennymi.

Potrzeba przewodzenia, a nie stawiania oporu
Większość sprzeciwu wobec regulacji SBOM dotyczyła raczej praktyczności niż zasad. „Obecnie dostępne narzędzia branżowe generują SBOM o różnym stopniu złożoności, jakości i kompletności. Obecność wielu, czasem niespójnych lub nawet sprzecznych, wysiłków wskazuje na brak dojrzałości SBOM” – stwierdzono w odpowiedzi Rady ITI.

Prawdą jest, że istnieje wiele sposobów tworzenia SBOM, dlatego nie ma jednego standardu, którego mogłaby obecnie przestrzegać każda firma i organizacja. Ale to właśnie w tym kierunku powinni przewodzić giganci technologiczni, a nie wstrzymywać sprawy. Zamiast po prostu kpić i mówić, że to niemożliwe, powinna zdecydować i przyjąć najlepszy standard, a także, jeśli to konieczne, poszukać sposobów na wypełnienie luki między tymi różnymi standardami.

W przypadku niepowodzenia tego scenariusza najgorszy scenariusz polega na tym, że SBOM są wymagane bez standardu, co oznacza, że ​​każdy, kto potrzebuje je utworzyć, po prostu wybiera metodę i wykorzystuje ją w celu spełnienia wymogów rozporządzenia. Standaryzacja w końcu nadejdzie, jak zawsze, gdy jedno narzędzie zostanie przyjęte przez większość branży i zwycięży po prostu dzięki większej popularności. Zajmie to jednak czas, a może nawet lata i będzie kosztowne dla firm, które muszą zmienić swoje systemy.

W tym czasie możemy zauważyć kolejną lukę obejmującą całą platformę Log4Shell. Jeśli tak się stanie, rząd USA będzie mógł wskazać na swoje regulacje i powiedzieć, że wymusił tę zmianę na branży. Jeżeli wdrożone protokoły SBOM nie sprostają zadaniu i nie zapewnią niezbędnej reakcji, branża będzie narażona na coś, co jest mniej lub bardziej nieuniknione.

SBOM będą kluczem do usunięcia kolejnej dużej luki w zabezpieczeniach i będą niezwykle przydatne w walce o złagodzenie skutków mniejszych luk. Problemów z przyjęciem SBOM nie należy dziś postrzegać jako bariery; Zamiast tego branża informatyczna powinna opracować harmonogram i współpracować w celu rozwiązania tych problemów, zamiast wycofywać się z jakichkolwiek prób legislacyjnych. Wysiłki wywierające presję powinny skupiać się na tym, jak to może zadziałać, a nie na tym, czy w ogóle może to nastąpić.