Jak każdy inny gotowy produkt, oprogramowanie składa się z wielu komponentów. Każdy komponent, biblioteka, kod, plik binarny i zależność powinny zostać starannie pobrane i zweryfikowane przed użyciem, aby uniknąć przedostania się luk w zabezpieczeniach do projektu w cyklu życia oprogramowania.
Jednak zwykle tak nie jest. Jak pokazał scenariusz hackowania SolarWinds, nie wszyscy programiści przykładają szczególną wagę do zapewnienia integralności komponentów swojego oprogramowania.
Ponieważ biblioteki open source są głównym źródłem materiałów dla programistów chcących przyspieszyć wydawanie oprogramowania, weryfikacja bezpieczeństwa tych komponentów przed ich użyciem wymaga jedynie niewielkiej precyzji.
Dlatego tak ważna jest lista materiałów oprogramowania, ich automatyzacja i dokładność.
Czytaj dalej, aby znaleźć odpowiedź na pytanie co to jest zestawienie materiałów oprogramowania?
Co to jest zestawienie materiałów oprogramowania?
Zestawienie materiałów oprogramowania to spis zagregowanych zależności i komponentów zaangażowanych w dostarczanie i rozwój aplikacji.
Dziś stało się to kluczową cechą procesów DevSecOps i Cykl życia oprogramowania (SDLC).
Nowoczesne aplikacje są opracowywane z kilkoma zależnościami i komponentami pochodzącymi z różnych źródeł. Te zależności i komponenty często składają się z zastrzeżonego kodu, bibliotek oprogramowania, interfejsów API, struktur języków programowania i nie tylko.
Wszystkie te komponenty łącznie stanowią dużą część łańcucha dostaw oprogramowania, funkcjonując jako źródła usług i aplikacji wspomagających.
Aby zrozumieć, czym jest zestawienie materiałów oprogramowania, można je porównać ze zwykłym zestawieniem materiałów, które ma zastosowanie w innych branżach, takich jak produkcja. SBOM jest bardzo podobny pod tym względem, że dotyczy zagregowanych komponentów oprogramowania, a nie innych produktów fizycznych.
Obecnie fala głośnych cyberataków w branży tworzenia oprogramowania zmienia orientację organizacji zajmujących się oprogramowaniem w zakresie weryfikacji materiałów źródłowych, szczególnie jeśli chodzi o dostawców.
SBOM dają wgląd w nieodłączną strukturę i ramy, pomagając użytkownikom i organizacjom zidentyfikować funkcjonalność i potencjał naruszeń bezpieczeństwa.
Z czego powinien składać się SBOM?
Na najbardziej podstawowym poziomie SBOM to kompleksowy spis składników źródłowych oprogramowania.
Wszystkie komponenty, tj. komponenty umożliwiające działanie aplikacji, są bez wyjątku wymienione i szczegółowo opisane.
Zależności od struktur programistycznych lub składników oprogramowania pośredniego są również uwzględnione.
W przeciwieństwie do zwykłego BOM-u, który po prostu opisuje jednostki składowe, SBOM idzie o krok dalej, dostarczając dane dotyczące pochodzenia tych komponentów. Rezultatem jest drzewo zależności, które zapewnia przejrzystość i wgląd w podstawowe komponenty oprogramowania.
Zgodnie z wymaganiami Krajowej Administracji Telekomunikacji i Informacji (NTIA), standardowe SBOM muszą posiadać co najmniej następujące elementy:
Pola danych
Ta sekcja opisuje drzewo zależności oprogramowania i powinna zawierać następujące komponenty:
- Informacje o licencji
- Nazwa Dostawcy
- Autorstwo
- Znak czasu
- Wersja komponentowa
- Nazwa komponentu
Automatyzacja
Ponieważ nowoczesne procesy tworzenia aplikacji są tak złożone, nie zaleca się ręcznego generowania SBOM.
Raczej proces ten powinien zostać zautomatyzowany, tak aby SBOM był czytelny maszynowo.
Procesy
Oznacza to, że SBOM potrzebują idealnych procesów systematycznego gromadzenia danych, w tym jasno określonych struktur generowania i udostępniania SBOM.
Gdzie stosuje się SBOM?
SBOM mają zastosowanie do wszelkiego rodzaju komponentów oprogramowania, w tym oprogramowania sprzętowego, oprogramowania wbudowanego, modułów, bibliotek współdzielonych, modułów i pakietów.
Należy pamiętać, że komponenty fizyczne, takie jak chipy, urządzenia kryptograficzne i sprzęt sieciowy, pomimo ich roli w wykonywaniu oprogramowania, niekoniecznie stanowią podstawową część SBOM.
W idealnym przypadku wszystkie organizacje zajmujące się oprogramowaniem powinny udostępniać SBOM dla wszystkich swoich produktów programowych.
Oto kilka przykładów zasobów, które zazwyczaj powinny mieć SBOM:
Zależności rozwojowe
Za każdym razem programiści dołączają wewnętrzne lub otwarte komponenty innych firm, w tym zależności przechodnie.
W takim przypadku kompleksowy SBOM zapewniłby widoczność tych przechodnich zależności.
Pakiety oprogramowania.
SBOM mogą pomóc konsumentom łatwo zidentyfikować narzędzia pomocnicze, wersje aplikacji i inne pakiety kompilacji komponentów po dystrybucji oprogramowania.
Ułatwia to oznaczanie i rozwiązywanie problemów związanych z lukami w zabezpieczeniach zawierających błędy w składnikach oprogramowania.
Obrazy kontenerów.
SBOM mają również zastosowanie do obrazów kontenerów i odpowiadających im pakietów wprowadzonych na etapie kompilacji.
Zastępy niebieskie
SBOM mogą zawierać kluczowe szczegóły hosta (takie jak obraz urządzenia maszyny wirtualnej), takie jak podstawowy system operacyjny, wersja i dostawca.
Zwiększenie dokładności SBOM
Ponieważ SBOM są wirtualnym spisem komponentów oprogramowania, muszą być jak najbardziej dokładne. W przeciwnym razie ich cel zostanie pokonany.
Oto trzy sposoby poprawy dokładności SBOM:
Podpisywanie cyfrowe
Pomimo wysiłków utrzymanie 100% dokładności SBOM-ów może być trudne.
Jednym z idealnych rozwiązań jest umieszczenie podpisów cyfrowych na każdym artefakcie w SBOM, aby konsumenci mogli łatwo zweryfikować ich integralność i autentyczność.
Automatyka
Automatyzacja jest standardowym wymogiem w przypadku generowania SBOM. Przyspieszają proces, a także zapewniają większą dokładność.
Składniki oprogramowania są złożone i często składają się z setek podjednostek. Ręczne sprawdzenie tak precyzyjnych danych byłoby prawie niemożliwe. Jest to stresujące i pozostawia dużo miejsca na błędy ludzkie.
Automatyzacja może pomóc w zapewnieniu dokładności i aktualizacji SBOM. Standardy takie jak CycloneDX i SPDX można odczytywać maszynowo i obsługują zagnieżdżanie, umożliwiając programistom rozwiązywanie różnych problemów związanych z automatyzacją.
Recenzje ręczne
Narzędzia analityczne, choć skuteczne, mogą mieć ograniczoną świadomość, co zmniejsza dokładność. Na przykład może brakować części oprogramowania wymaganego do działania komponentu.
W takich scenariuszach można ręcznie przejrzeć informacje w kontekście, w ten sam sposób, w jaki karta charakterystyki materiału będzie zawierać nakładkę informacyjną.
Wniosek
Jak podkreślono wcześniej, wiele opcji pozyskiwania komponentów sprawia, że SDLC jest niezwykle złożone i naraża łańcuch dostaw na słabe punkty na każdym etapie, od kompilacji po wdrożenie.
Niektóre organizacje używają zwykłych arkuszy danych do dokumentowania użycia oprogramowania innych firm. Nie jest to skuteczny sposób na wygenerowanie dokładnego zestawienia materiałów oprogramowania, ponieważ źródło komponentów najprawdopodobniej zmienia się codziennie. W związku z tym istniejący inwentarz oprogramowania będzie nieaktualny, co utrudni użytkownikom końcowym śledzenie źródła potencjalnych luk w zabezpieczeniach.
W świetle tego generowanie dokładnych SBOMów nigdy nie było tak ważne jak dzisiaj. Wiele zagrożeń bezpieczeństwa można złagodzić poprzez ręczne przeglądanie danych, automatyzację generowania SBOM i stosowanie technik podpisu cyfrowego.
