Co to jest zestawienie materiałów oprogramowania (SBOM)?

Zestawienie materiałów oprogramowania (SBOM) to szczegółowa, kompleksowa lista wszystkich składników aplikacji, w tym korzystania z oprogramowania typu open source, zależności komponentów, licencji i znanych luk w zabezpieczeniach. SBOM zapewniają spis każdego pojedynczego komponentu, który składa się na aplikację, podobnie jak lista składników w przepisie. SBOM zaczęły zyskiwać na popularności w 2018 r. jako wspólny wysiłek społeczności zajmującej się bezpieczeństwem informacji, a w ostatnich latach były w dużej mierze napędzane przez Narodową Administrację Telekomunikacji i Informacji (NTIA) oraz rząd USA.

SBOM są bardzo ważnymi dokumentami, które dostarczają krytycznych informacji dla organizacji, które chcą zminimalizować i zmniejszyć ryzyko operacyjne, prawne i związane z łańcuchem dostaw oprogramowania, ale wiele organizacji nadal boryka się z wyzwaniami związanymi z wdrożeniem SBOM do istniejących procesów lub nie zdaje sobie sprawy z ich korzyści. W tym artykule przyjrzymy się, w jaki sposób SBOM mogą pomóc organizacjom stać się lepiej poinformowanymi o oprogramowaniu, z którego korzystają i dlaczego SBOM powinny być stosowane jako najlepsza praktyka.

Dowiedz się, jak UpGuard pomaga firmom uzyskać lepszy wgląd w luki w zabezpieczeniach oprogramowania >

Dlaczego SBOM są ważne?

Ponieważ przeciętna firma korzysta z ponad 130 aplikacji SaaS w codziennych operacjach, a większe przedsiębiorstwa mogą korzystać z ponad 200 aplikacji dziennie, SBOM stają się jeszcze bardziej istotne dla zmniejszenia zagrożeń bezpieczeństwa. Im więcej aplikacji jest używanych przez organizację na co dzień, tym większe narażenie na ryzyko jest dla niej narażone. Gdyby pojedyncza aplikacja lub komponent został naruszony z powodu luki w zabezpieczeniach, mogłoby to potencjalnie zagrozić całemu łańcuchowi dostaw oprogramowania.

SBOM pomagają organizacjom identyfikować zagrożenia operacyjne i bezpieczeństwa związane z określonym oprogramowaniem, a także uzyskiwać dalszy wgląd w skład oprogramowania. Organizacje mogą lepiej zarządzać lukami w zabezpieczeniach, przestrzegać licencji i wykonywać inne ważne zadania związane z zarządzaniem oprogramowaniem, wiedząc dokładnie, co znajduje się w oprogramowaniu. SBOM stają się coraz ważniejszym narzędziem w świecie cyberbezpieczeństwa, cykli życia oprogramowania (SDLC) i procesów DevSecOps.

W maju 2021 r. rząd federalny USA wydał rozporządzenie wykonawcze 14028, które wymaga, aby wszystkie agencje rządowe USA zajmowały się wyłącznie dostawcami oprogramowania, którzy zapewniają SBOM. To nowe prawo było częścią większych wysiłków w zakresie cyberbezpieczeństwa, mających na celu zabezpieczenie krajowej infrastruktury cyfrowej i skłonienie większej liczby dostawców oprogramowania do zapewnienia bezpiecznego tworzenia produktów. EO 14028 zachęca również dostawców do spełniania federalnych standardów bezpieczeństwa cybernetycznego, ponieważ kontrakty rządowe są potencjalnie lukratywnymi możliwościami.

Nowoczesne aplikacje i usługi są zbudowane z różnych komponentów i zależności pochodzących z wielu źródeł. Te składniki i zależności mogą obejmować oprogramowanie typu open source, zastrzeżony kod, niestandardowe interfejsy API, struktury języków programowania i biblioteki oprogramowania. Wszystkie źródła, które składają się na aplikacje, są uważane za część łańcucha dostaw oprogramowania.

Zestawienie materiałów oprogramowania różni się od metadanych oprogramowania tym, że metadane oprogramowania mogą dostarczać więcej informacji na temat szerszego zastosowania i celu aplikacji, podczas gdy SBOM koncentrują się na poszczególnych składnikach w aplikacji i ich zależnościach.

Organizacje polegają również na swoich SBOM-ach w celu rozwiązania następujących kwestii:

Zgodność z prawem
Wydajność w zakresie cyberbezpieczeństwa
Zarządzanie ryzykiem
Reagowanie na incydenty
Efektywność operacyjna
Zarządzanie lukami w zabezpieczeniach

Co zawierają SBOM-y?

Krajowa Administracja Telekomunikacji i Informacji (NTIA) wydała wytyczne szczegółowo określające minimalne elementy SBOM, w tym następujące podstawowe obszary:

Nazwy i wersje komponentów: Każdy składnik oprogramowania musi być zidentyfikowany i wymieniony, w tym jego nazwa, numer wersji, informacje o licencji, nazwa dostawcy, autor i znacznik czasu wygenerowania danych SBOM. Dzięki tym informacjom organizacje mogą upewnić się, że korzystają z najnowszych i najbezpieczniejszych wersji każdego składnika. Jeśli komponent lub podskładnik zostanie zaktualizowany, SBOM musi zostać zaktualizowany i ponownie wydany.
Zależności oprogramowania: SBOM musi zawierać drzewo zależności między składnikami oprogramowania, w tym zależności przechodnie, w celu utrzymania funkcjonalności oprogramowania i wspierania wydajnych praktyk zarządzania zależnościami. Jeśli zależność ulegnie zmianie lub składnik stanie się nieaktualny, SBOM musi zostać zaktualizowany w celu odzwierciedlenia takich zmian.
Automatyzacja: NTIA zaleca minimalne poziomy automatyzacji generowania SBOM i przesyłania danych, aby inne systemy mogły zrozumieć i wykorzystać wygenerowane dane SBOM. Ponieważ aplikacje mogą być niezwykle złożone, NTIA zdecydowanie odradza generowanie SBOM przy użyciu procesów ręcznych.
Procesy: SBOM wymagają ciągłych procesów zbierania danych, które definiują, w jaki sposób są generowane SBOM-y, w jaki sposób uzyskuje się do nich dostęp i kto ma uprawnienia do ich dostępu.
Licencje na oprogramowanie typu open source: Jeśli oprogramowanie korzysta z licencji na oprogramowanie typu open source, ważne jest, aby udokumentować typ licencji każdego składnika, a także warunki i postanowienia, aby zapobiec problemom prawnym. Organizacje mogą upewnić się, że przestrzegają warunków określonych przez twórców komponentu, śledząc wszystkie licencje. Ponadto dane licencyjne umożliwiają organizacjom śledzenie luk w zabezpieczeniach lub luk w zabezpieczeniach kodu open source i korygowanie ich, zanim doprowadzą do naruszenia bezpieczeństwa cybernetycznego.
Znane luki w zabezpieczeniach: Lista znanych luk w zabezpieczeniach dla każdego składnika pomaga organizacjom ograniczyć potencjalne ryzyko i poprawić ogólne bezpieczeństwo oprogramowania. Te informacje umożliwiają zespołom IT ustalanie priorytetów aktualizacji i poprawek w celu utrzymania bezpiecznego środowiska oprogramowania.

Standardowe formaty SBOM

Istnieje kilka standardowych formatów tworzenia i udostępniania SBOM-ów. Ustandaryzowane formaty zapewniają spójność danych SBOM w całym łańcuchu dostaw oprogramowania, promując pełną przejrzystość i współpracę między różnymi interesariuszami. Do najczęściej używanych obecnie formatów SBOM należą:

CycloneDX, opracowany przez Open Web Application Security Project (OWASP)
Software Identification Tags (SWID), opracowany przez NIST

Software Package Data Exchange (SPDX), opracowany przez ISO/IEC zgodnie z ISO/IEC 5962

Korzyści z wdrożenia SBOM

Wdrażanie SBOM może być trudnym procesem, ale może przynieść wiele korzyści, które mogą pomóc organizacjom w lepszym utrzymaniu bezpieczeństwa i zminimalizowaniu ryzyka w dłuższej perspektywie, w tym:

Ulepszone postawy zabezpieczeń: SBOM zapewniają dalszą głębię i wgląd w składniki oprogramowania, co pomaga organizacjom identyfikować, śledzić i korygować znane luki w zabezpieczeniach.
Zgodność z licencjonowaniem: SBOM pomagają organizacjom spełnić wymagania licencyjne, śledząc wszystkie używane komponenty zastrzeżone i typu open source. Te informacje licencyjne pomagają również organizacjom w spełnianiu wymagań prawnych i norm regulacyjnych.
Przejrzystość łańcucha dostaw: Tworzenie przejrzystości oprogramowania jest szczególnie ważne dla organizacji, które zaczynają się rozwijać. Zrozumienie źródła pochodzenia każdego oprogramowania pozwala organizacjom właściwie ocenić wiarygodność i bezpieczeństwo każdego komponentu.
Efektywne audyty oprogramowania: Audyty oprogramowania powinny być przeprowadzane regularnie w celu oceny zgodności, skuteczności, krytyczności i konieczności produktu. SBOM pomagają ułatwić ten proces, dostarczając wyczerpującą listę każdego użytego komponentu, oszczędzając czas i zasoby potrzebne do ukończenia audytu.
Skuteczne zarządzanie ryzykiem i lukami w zabezpieczeniach: Śledzenie każdego komponentu używanego w aplikacjach pozwala firmom identyfikować potencjalne zagrożenia i łagodzić je lub korygować, zanim będą mogły zostać wykorzystane.

Wyzwania związane z wdrażaniem SBOM

Podczas gdy SBOM mogą pomóc w utrzymaniu porządku w ekosystemie IT firmy, wiele procesów jest nadal standaryzowanych i definiowanych. Ze względu na to, że tworzenie i stosowanie SBOM jest nadal różnorodne, organizacje mogą napotkać pewne początkowe wyzwania i nieefektywność, takie jak:

Złożone procesy wdrażania i utrzymania: Większe przedsiębiorstwa, które korzystają z szerokiej gamy i liczby produktów programowych i baz kodu, mogą napotkać poważne wyzwania związane z pozyskiwaniem SBOM dla każdej aplikacji. Z kolei dostawcy oprogramowania są również zobowiązani do dodatkowej pracy przy generowaniu SBOM-ów, zwłaszcza gdy oprogramowanie jest aktualizowane. Oprogramowanie, które jest często aktualizowane, oznacza, że SBOM również muszą być często aktualizowane.
Brak standaryzacji: Ponieważ SBOM są wciąż stosunkowo nową praktyką, nadal występują problemy ze standaryzacją, które mogą prowadzić do niespójności między formatami i problemów z kompatybilnością między typami narzędzi i platform używanych podczas generowania danych.
Duże zapotrzebowanie na zasoby: Duża ilość pracy wymagana do wygenerowania i utrzymania SBOM oznacza, że dostawcy muszą poświęcić na to zadanie znaczną ilość czasu i zasobów. Ponadto w każdym zespole ds. bezpieczeństwa konieczne będzie przeszkolenie specjalnego personelu, co może stanowić wyzwanie dla mniejszych organizacji o wyższych priorytetach. Organizacje korzystające z oprogramowania będą również potrzebowały dedykowanych zespołów lub osób do śledzenia SBOM, aby uwzględnić je w procesach zamówień i audytu.
Bezpieczeństwo danych SBOM: Każdy dokument SBOM zawiera krytyczne informacje o komponentach oprogramowania, które mogą prowadzić do nowych możliwości naruszenia zarówno dla dostawcy, jak i organizacji korzystającej z aplikacji. Dane SBOM muszą być poufne i bezpieczne, a nowe wewnętrzne procesy bezpieczeństwa definiują bezpieczeństwo danych.
Brak możliwości integracji: Ponieważ SBOM nadal nie są powszechną praktyką, integracja jego procesów z istniejącym tworzeniem i wdrażaniem oprogramowania może nie być możliwa lub może być niezwykle trudna. Jednak więcej możliwości integracji oprogramowania można osiągnąć, ponieważ coraz więcej organizacji wdraża SBOM do swoich procesów.
Udział dostawców: W sytuacji, gdy organizacje mogą potencjalnie współpracować z setkami lub tysiącami dostawców, którzy dostarczają aplikacje, nakłonienie dostawców zewnętrznych do przyjęcia nowych procesów i opracowania zaktualizowanych, dokładnych SBOM może okazać się trudne, zwłaszcza jeśli nie widzą korzyści lub uważają, że dodatkowa praca jest niepotrzebna. Ponadto dostawcy oprogramowania mogą nie chcieć podawać szczegółów komponentów, jeśli uważają, że ujawniają poufne, zastrzeżone informacje.