zabezpieczenie
SBOM i sprawdzanie komponentów
Lista komponentów oprogramowania, które siedzą w tym, co tworzysz lub kupujesz, oraz nawyk sprawdzania jej pod kątem nowych podatności. CRA wymaga listy od producentów. Dla pozostałych to praktyka, dzięki której można odpowiedzieć na wymogi dotyczące dostawców i łatania.
- co chroni
- w ciągu doby wiesz, czy nowy błąd siedzi w czymś, co tworzysz lub uruchamiasz
- kto za to odpowiada
- szef inżynierii, a przy kupowanym oprogramowaniu szef IT
- zacznij od
- jeden produkt: generuj listę w procesie budowania, potem zestawiaj ją z nowymi zgłoszeniami
czym jest
SBOM (software bill of materials) to lista składników programu: każdy komponent w środku, z nazwą, wersją i źródłem. Prawie całe oprogramowanie składa się z cudzego kodu, także z bibliotek otwartoźródłowych. Gdy w jednej z nich znajdzie się błąd, lista pozwala powiedzieć, czy Cię dotyczy.
Potrzebują jej dwie grupy. Jeśli tworzysz i sprzedajesz w UE oprogramowanie lub produkty połączone, Cyber Resilience Act (CRA) wymaga od Ciebie prowadzenia listy w formacie do odczytu maszynowego oraz należytej staranności wobec komponentów podmiotów trzecich. Jego główne obowiązki obowiązują od 11 grudnia 2027 r. Jeśli oprogramowanie tylko kupujesz, żaden tekst przeczytany do tej strony nie każe Ci mieć listy, a NIS2 jej nie wspomina. NIS2 wymaga jednak bezpieczeństwa łańcucha dostaw i obsługi podatności. Wiedza, co jest w środku tego, co uruchamiasz, to praktyczny sposób odpowiedzi na oba wymogi.
Ważniejszy od pliku jest nawyk. Generuj listę w procesie budowania, trzymaj ją przy wydaniu, według harmonogramu zestawiaj z nowymi zgłoszeniami podatności i przy każdym trafieniu wskaż właściciela oraz decyzję. Przy kupowanym oprogramowaniu poproś dostawcę o jego listę i zapisz odpowiedź w umowie.
podstawa CRA załącznik I część II; CRA art. 13(5); NIS2 art. 21(2)(d); NIS2 art. 21(2)(e). Prowadzenie listy po stronie kupującego, harmonogram zestawiania i właściciele są praktyką.
jak powstaje i jak działa lista komponentów
- 1budowalista powstaje z kodu, który trafia do wydania
- 2zapistrzymana przy wydaniu, które opisuje
- 3zestawienieporównanie z nowymi zgłoszeniami podatności według harmonogramu
- 4decyzjawskazany właściciel ocenia każde trafienie i zapisuje decyzję
każde wydanie zaczyna listę od nowa
podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.
przykład
Wyobraź sobie firmę ze 120 osobami, która sprzedaje aplikację webową i uruchamia kilkanaście kupionych systemów.
Inżynier wypisał listę komponentów na audyt wiosną. Ogłoszono nowy błąd w popularnej bibliotece. Nikt nie potrafi powiedzieć, które produkty ją zawierają, więc trzy osoby czytają kod, a odpowiedź nadal jest zgadywaniem.
Każde wydanie buduje własną listę i zapisuje ją przy wersji. Nowe zgłoszenia są zestawiane co miesiąc, a wskazany inżynier decyduje o każdym trafieniu. Przy kupowanym oprogramowaniu umowy proszą dostawcę o jego listę.
To ilustracja, a nie opis prawdziwego przypadku.
co musi robić dla każdego przepisu
| przepis | gdzie | czego wymaga tekst | co musi robić zabezpieczenie |
|---|---|---|---|
| CRA | CRA załącznik I część II | Producent prowadzi wykaz komponentów produktu w postaci SBOM (listy składników oprogramowania), w powszechnie używanym formacie nadającym się do odczytu maszynowego, obejmujący co najmniej zależności najwyższego poziomu. | Jeśli sprzedajesz oprogramowanie lub produkty połączone, generuj listę z procesu budowania i odnawiaj ją przy każdym wydaniu. Główne obowiązki obowiązują od 11 grudnia 2027 r. |
| CRA | CRA art. 13(5) | Komponenty podmiotów trzecich, także otwartoźródłowe, wymagają należytej staranności. | Zanim komponent trafi do produktu, ustal, kto sprawdza jego źródło, utrzymanie i znane błędy, i zachowaj notatkę z tego sprawdzenia. |
| NIS2 | NIS2 art. 21(2)(d) | Bezpieczeństwo łańcucha dostaw, w tym relacje z bezpośrednimi dostawcami i usługodawcami. | Przy oprogramowaniu, które kupujesz, zapytaj dostawcę, co jest w środku i jak informuje o błędach. Przepis nie wspomina o SBOM, więc pytanie jest praktycznym sposobem spełnienia wymogu, a prawo go nie narzuca. |
| NIS2 | NIS2 art. 21(2)(e) | Bezpieczeństwo przy nabywaniu, rozwoju i utrzymaniu, w tym obsługa i ujawnianie podatności. | Użyj listy komponentów, żeby znaleźć, które Twoje produkty i systemy zawierają nowo ujawniony błąd, i zapisz, co z tym zrobiono. |
podstawa CRA załącznik I część II; CRA art. 13(5); NIS2 art. 21(2)(d); NIS2 art. 21(2)(e). CRA wiąże producentów. NIS2 nie wymienia SBOM. To, co zabezpieczenie ma robić, jest praktyką.
na co patrzeć przy wyborze
- Czy listę tworzy sam proces budowania, dzięki czemu zgadza się z tym, co wydano, czy ktoś wypisuje ją ręcznie po fakcie?
- Czy używa powszechnie stosowanego formatu do odczytu maszynowego i czy sięga poza zależności najwyższego poziomu, do tego, co one same ściągają?
- Czy zapisuje nazwę, wersję i źródło każdego komponentu oraz licencję?
- Czy da się ją według harmonogramu zestawiać z nowo ujawnionymi podatnościami, z powiadomieniem wskazanej osoby?
- Czy w ciągu doby powie Ci, które Twoje produkty lub systemy zawierają dany komponent?
- Przy kupowanym oprogramowaniu: czy dostawca da Ci swoją listę i na jakich warunkach? Wpisz odpowiedź do umowy.
- Czy przechowuje listę z każdego wydania, żebyś mógł odpowiedzieć o wersji sprzed dwóch lat?
- Jak traktuje komponenty, do których nie widać wnętrza, takie jak zamknięte pliki binarne i usługi, które wywołujesz?
podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.
trzy poziomy, od pierwszego kroku do mocnego
Każdy poziom dodaje coś widocznego. Zatrzymaj się tam, gdzie pozwala na to ryzyko, które akceptujesz.
- start
Wybierz jeden produkt i generuj jego listę komponentów w procesie budowania. Wskaż jedną osobę, która czyta trafienia.
- solidnie
Zrób to dla każdego produktu, który tworzysz, trzymaj listę z każdego wydania, zestawiaj według harmonogramu i poproś dostawców kluczowego oprogramowania o ich listy.
- mocno
Sięgnij poniżej zależności najwyższego poziomu, zapisuj należytą staranność przy każdym nowym komponencie podmiotu trzeciego i wpisz klauzulę o liście do umów z dostawcami.
podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.
gdzie się psuje
lista, której nikt nie zestawia
Wykaz leżący w katalogu nie odpowiada na żadne pytanie. Wartość bierze się z zestawiania go z nowymi zgłoszeniami podatności i reagowania na trafienia.
tylko najwyższy poziom
Pierwsza warstwa zależności to minimum, które wymienia CRA. Większość uruchamianego kodu przychodzi o jedną lub dwie warstwy niżej, więc tam, gdzie się da, sięgnij głębiej.
jednorazowy eksport
Lista zrobiona raz na audyt jest nieaktualna przy następnym wydaniu. Generuj ją w procesie budowania, za każdym razem.
alerty bez właściciela
Strumień ustaleń, którego nikt nie ma czytać, daje zaległości i fałszywe poczucie ochrony. Wyznacz właściciela i zasadę reakcji.
lista jako wyrok
Lista pokazuje, że komponent jest obecny. Nie pokazuje, że błąd jest osiągalny w Twoim produkcie. Oceń każde trafienie i zapisz decyzję.
podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.
dowód, który zostawia
| co możesz pokazać | kto jest właścicielem | odświeżanie |
|---|---|---|
| aktualna lista komponentów każdego produktu, który tworzysz, z wydaniem, do którego należy | szef inżynierii | przy każdym wydaniu |
| zapis należytej staranności przy nowych komponentach podmiotów trzecich i otwartoźródłowych | szef inżynierii | przy dodaniu komponentu |
| wyniki zestawienia z nowymi zgłoszeniami podatności, z decyzją podjętą przy każdym trafieniu | szef IT lub osoba odpowiedzialna za bezpieczeństwo | co miesiąc |
| odpowiedzi dostawców o listach komponentów i klauzule umowne, które je obejmują | szef IT | co roku |
podstawa practice. Rytm odświeżania jest Twoim wyborem.
sprawdź sam
twój następny krok
Wybierz produkt, który tworzysz lub od którego zależysz najbardziej, i sprawdź, czy ktoś potrafi dziś wypisać komponenty w jego wnętrzu.