bezpieczne wytwarzanie oprogramowania

co chroni: oprogramowanie, które wydajesz i które kupujesz, przed lukami wbudowanymi albo kupionymi
kto za to odpowiada: szef inżynierii
zacznij od: jeden produkt, jeden proces wydania, jedno miejsce na wynik

czym jest

Bezpieczne wytwarzanie oznacza, że bezpieczeństwo jest częścią tego, jak oprogramowanie jest projektowane, pisane, testowane i wydawane. Obejmuje oprogramowanie, które piszesz, które zamawiasz i, według NIS2, które kupujesz.

NIS2 wymienia je jako bezpieczeństwo przy nabywaniu, rozwoju i utrzymaniu i zostawia metodę Tobie. CRA jest dokładniejsze wobec producentów produktów: stawia wymagania bezpieczeństwa produktom z elementami cyfrowymi i nakłada obowiązek budowania zgodnie z nimi. AI Act stawia wymóg cyberbezpieczeństwa systemom AI wysokiego ryzyka. Jeśli nie tworzysz oprogramowania dla innych, pytanie dotyczy głównie oprogramowania kupowanego i narzędzi wewnętrznych.

Zacznij od jednego produktu i jednego procesu: kto zatwierdza wydanie, jakie sprawdzenia je poprzedzają i gdzie zapisuje się wynik. Potem dodaj listę komponentów, bo każde późniejsze ogłoszenie luki zaczyna się od pytania, który z Twoich produktów ją zawiera.

podstawa NIS2 art. 21(2)(e); CRA załącznik I część I. Proces i kolejność są praktyką.

jak sprawdza się wydanie

1przegląd projektuwymagania i ryzyka ogląda się przed napisaniem kodu
2sprawdzenia w budowaniuautomatyczne kontrole działają przy każdej zmianie
3zatwierdzenie wydaniawskazana osoba podpisuje albo obchodzi zasadę z powodem
4zapis wydaniasprawdzenia, osoba zatwierdzająca i lista komponentów są przechowywane
5po wydaniuna ogłoszenie nowej luki odpowiada się z zapisu

co obejmują sprawdzenia w budowaniu

własny kodbłędy i pomyłki w tym, co napisał zespół
używane bibliotekiznane luki w kodzie napisanym gdzie indziej
obrazy kontenerówto, co leży pod aplikacją
sekretyklucze i hasła pozostawione w repozytorium

podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

przykład

Wyobraź sobie firmę ze 120 osobami, która dostarcza jeden produkt kilkuset klientom.

słabo

Testy bezpieczeństwa odbywają się w ostatnim tygodniu przed wydaniem. Każdy może przejść obok nieudanego sprawdzenia bez śladu. Nikt nie wie, jakie biblioteki są w zeszłorocznej wersji, więc gdy ogłoszono lukę, pierwszy dzień idzie na ustalanie tego.

solidnie

Sprawdzenia działają w budowaniu i w przeglądzie projektu. Wydanie wymaga wskazanej osoby zatwierdzającej, obejście ma powód w zapisie, a każde wydanie przechowuje listę komponentów. Gdy ogłoszono lukę, zespół odpowiada z tej listy, które produkty ją zawierają.

To ilustracja, a nie opis prawdziwego przypadku.

co musi robić dla każdego przepisu

przepis	gdzie	czego wymaga tekst	co musi robić zabezpieczenie
NIS2	NIS2 art. 21(2)(e)	Bezpieczeństwo przy nabywaniu, rozwoju i utrzymaniu systemów sieci i informacyjnych.	Spisz, jak oprogramowanie jest tworzone albo kupowane, kto zatwierdza wydanie i co sprawdza się przed uruchomieniem.
CRA	CRA art. 13(1)	Producenci: produkt zaprojektowany, opracowany i wytworzony tak, by spełniał wymagania bezpieczeństwa z załącznika I części I.	Jeśli sprzedajesz oprogramowanie lub produkty z połączeniem, wbuduj wymagania w projekt i testuj je przed wydaniem.
CRA	CRA załącznik I część I	Brak znanych możliwych do wykorzystania podatności w chwili wydania, bezpieczne ustawienia domyślne, kontrola dostępu, ochrona danych, ograniczona powierzchnia ataku i rejestrowanie zdarzeń.	Zamień listę w sprawdzenia przed wydaniem, które ktoś zatwierdza podpisem.
AI Act	AI Act art. 15	Systemy AI wysokiego ryzyka: odpowiedni poziom dokładności, solidności i cyberbezpieczeństwa.	Przetestuj system pod kątem ataków na jego dane i model oraz zachowaj wyniki przy zapisie wydania.

podstawa NIS2 art. 21(2)(e); CRA art. 13(1); CRA załącznik I część I; AI Act art. 15. To, co zabezpieczenie ma robić, jest praktyką.

na co patrzeć przy wyborze

Czy pasuje do sposobu pracy zespołu: hostingu kodu, potoku budowania i systemu zgłoszeń?
Czy sprawdza własny kod, używane biblioteki i obrazy kontenerów oraz zgłasza sekret pozostawiony w repozytorium?
Czy wydanie można zablokować, gdy jest otwarte poważne ustalenie, i czy osoba z uprawnieniami może to obejść, z powodem zapisanym w systemie?
Czy zachowuje zapis, co weszło w każde wydanie, tak by po ogłoszeniu luki odpowiedzieć, które produkty ją zawierają?
Czy programista widzi ustalenie i wskazówkę naprawy w narzędziu, którego już używa?
Jak obsługuje oprogramowanie kupowane lub zamawiane: czy możesz poprosić dostawcę o ten sam dowód?
Kto zatwierdza wyjątki i gdzie jest ich lista?
Czy oddziela dane i poświadczenia testowe od produkcyjnych?

podstawa praktyka

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 zapisz, kto zatwierdza wydanie, co sprawdza się przed nim i gdzie zapisuje się wynik.
solidnie
Uruchamiaj sprawdzenia w budowaniu, zapisuj każde obejście z powodem i właścicielem i przechowuj listę komponentów dla każdego wydania.
mocno
Blokuj wydanie przy poważnym otwartym ustaleniu, proś dostawców kupowanego oprogramowania o ten sam dowód i co kwartał przeglądaj listę wyjątków.

podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

gdzie się psuje

sprawdzenia tylko na końcu

Testy bezpieczeństwa w ostatnim tygodniu przed wydaniem znajdują problemy, które kosztują najwięcej. Wstaw sprawdzenia do budowania i do przeglądu projektu.

cudzy kod to niczyja praca

Większość tego, co trafia do klienta, napisano gdzie indziej. Ktoś musi wiedzieć, jakie biblioteki są w każdym wydaniu, i śledzić luki w nich.

bramka, którą każdy może ominąć

Sprawdzenie, które można obejść bez śladu, jest radą. Wyjątki mają być rzadkie, mieć właściciela i być zapisane.

kupione oprogramowanie bez pytań

Nabywanie jest częścią tego samego artykułu NIS2. Zapytaj dostawców, jak tworzą i łatają oprogramowanie, i zapisz odpowiedź.