Znajdowanie staniało. Reszta cyklu życia nie. Cykl życia zarządzania podatnościami ma te same etapy, z jakiegokolwiek modelu by go nie wywieść: zidentyfikować kandydatów, rozstrzygnąć, którzy są prawdziwi i jak poważni, zdecydować, co zrobić z każdym, naprawić, zweryfikować naprawę, zgłosić każdemu, komu zgłoszenie się należy, i przechować dokumentację. W naszym odczytaniu dawniej to pierwszy etap był drogi. Dziś skaner, fuzzer, platforma przeglądowa albo asystent dostarcza kandydatów szybciej, niż jakikolwiek zespół zdoła ich rozstrzygnąć, a cykl życia pęka na etapach kolejnych, tam gdzie gładko sformułowany kandydat musi stać się decyzją, której ktoś będzie później musiał bronić.
Ta notatka przechodzi przez etapy, mówi, czego na każdym z nich wymaga unijny Cyber Resilience Act, rozporządzenie (UE) 2024/2847, i mówi, gdzie sytuuje się niezależny przegląd adwersaryjny. Jej ciężar leży w etapach po pierwszym.
Identyfikacja: tam, gdzie nie sprzedajemy
Kandydaci przychodzą zewsząd: z analizy statycznej, z narzędzi do zależności i zestawień komponentów, z fuzzerów, z platform przeglądowych, od asystentów, od waszych własnych inżynierów i od zgłaszających z zewnątrz. Przegląd adwersaryjny również wytwarza kandydatów (nasze obejmowały defekty naprawione później u źródła), ale znajdowanie jest tym, co zlecenie przynosi po drodze, a nie tym, za co jest wyceniane. Praktyka ustawiona w tym miejscu konkurowałaby z waszym skanerem na liczby.
Czego wymaga tu CRA. Producent musi zidentyfikować i udokumentować podatności i komponenty zawarte w produkcie, w tym przez sporządzenie zestawienia komponentów oprogramowania (załącznik I część II pkt 1), oraz musi wskazać adres kontaktowy do zgłaszania podatności i ułatwiać wymianę informacji o potencjalnych podatnościach (załącznik I część II pkt 6). To są obowiązki producenta; ustalenia zewnętrznego recenzenta je zasilają, ale ich nie wypełniają.
Rozstrzyganie: od gładkiej opinii do szczebla dowodowego
To pierwszy etap, na którym cykl życia pęka, ponieważ wszystkie powyższe narzędzia wydają opinie o kodzie z tą samą płynnością, niezależnie od tego, czy ścieżka jest osiągalna. Rozstrzyganie jest etapem, na którym te opinie zostają albo przesądzone, albo stopniowane. Nasza reguła brzmi: najpierw wyrocznia. Twierdzenie rozstrzygalne (czy ta ścieżka się wykonuje, czy specyfikacja dopuszcza tę wartość) idzie do tego, co potrafi na nie odpowiedzieć, do wykonania, kompilatora albo specyfikacji, zanim ktokolwiek zostanie poproszony o zdanie. To, co przetrwa, jest stopniowane według szczebla dowodowego, który faktycznie osiągnęło (ślad w kodzie źródłowym, dowód z kompilacji, test, odtworzenie w działaniu, a dla każdego twierdzenia probabilistycznego wskaźnik z przedziałem i dzienniki poszczególnych prób), albo oznaczane jako tylko prawdopodobne. Waga idzie wtedy za dowodem, a nie za pewnością siebie modelu. Ustalenie to nie wyrok jest obszernym omówieniem.
Czego wymaga tu CRA. Przeprowadzanie skutecznych i regularnych testów i przeglądów bezpieczeństwa produktu (załącznik I część II pkt 3) oraz, w dokumentacji technicznej, sprawozdania z prób przeprowadzonych w celu weryfikacji zgodności produktu i procedur postępowania w przypadku wykrycia podatności (załącznik VII pkt 6). Sprawozdanie z przeprowadzonych prób jest sprawozdaniem z tego, co zbadano, w jaki sposób i co ustalono, czym dokumentacja stopniowana dowodowo jest, a lista uszeregowana według wagi nie jest. I jeszcze przez pewien czas te sprawozdania będą powstawać, zanim da się powołać na zharmonizowaną normę definiującą „skuteczne i regularne”; muszą więc bronić się własną wartością: Normy mogą się przesunąć, termin zgłoszeń nie.
Decyzja: gdy narzędzie i zespół się nie zgadzają
Drugie pęknięcie. Narzędzie zgłasza rzecz krytyczną; inżynieria mówi, że framework ją łagodzi; zespół bezpieczeństwa nie ma ani czasu, by to obalić, ani pozycji, by przeważyć nad terminem, i zgłoszenie zamyka się przez wyczerpanie. Nasze reguły zamknięcia są te ze strony adwersaryjny przegląd kodu: zliczanie głosów niczego nie ustala; tam gdzie recenzenci nie zgadzają się co do tego, co robi kod, rozstrzyga kod źródłowy; tam gdzie odrzucenie opiera się na „niepewne”, twierdzenie trafia do zachowanej kolejki z osobą odpowiedzialną, terminem ważności i kryterium ponownego otwarcia, i zostaje na nowo wystawione świeżej linii modeli. Ta kolejka istnieje po to, by niepewne nie mogło po cichu przekształcić się w ryzyko zaakceptowane. Co rozstrzyga ustalenie omawia pierwszą z tych reguł, wraz z przypadkiem, w którym przedmiotem przeglądu było nasze własne narzędzie.
Czego wymaga tu CRA. Producent musi bezzwłocznie reagować na podatności i je eliminować, w tym przez udostępnianie aktualizacji zabezpieczeń (załącznik I część II pkt 2), oraz musi wprowadzić i egzekwować politykę skoordynowanego ujawniania podatności (załącznik I część II pkt 5). Decyzja o nienaprawianiu jest decyzją, którą dokumentacja techniczna będzie musiała wyjaśnić; wpis w zachowanej kolejce, z osobą odpowiedzialną i kryterium ponownego otwarcia, jest tym wyjaśnieniem, zapisanym w swoim czasie.
Naprawa i weryfikacja
Tutaj naszą rolą jest wsparcie, a nie odpowiedzialność: możemy towarzyszyć poprawkom i weryfikować każdą naprawę wobec ustalenia, w które celuje, przy commicie, który je zamknął, odnotowaną jako osobny wynik. Naprawa zweryfikowana przez ponowne przeczytanie nie jest naprawą zweryfikowaną przez ponowne uruchomienie; dokumentacja nazywa szczebel, który osiągnęła sama weryfikacja.
Czego wymaga tu CRA. Bezpieczna dystrybucja aktualizacji oraz łatki bezpieczeństwa rozpowszechniane bezzwłocznie i nieodpłatnie, wraz z informacjami doradczymi (załącznik I część II pkt 7 i 8); publiczne ujawnianie naprawionych podatności, gdy aktualizacja jest już dostępna (załącznik I część II pkt 4).
Zgłoszenie: tam, gdzie strona trzecia zarabia na honorarium
Trzecie pęknięcie i to, po które kupujący zwykle przychodzą. Wewnętrzne uruchomienie (obojętne, na ilu modelach i jak odizolowanych) daje wasze własne słowo o waszym własnym kodzie. Z naszego doświadczenia trzy z czterech stron, które będą czytać waszą dokumentację, tego nie przyjmują: prawnicy nabywcy w badaniu due diligence, underwriter ubezpieczyciela cybernetycznego, zespół bezpieczeństwa klienta korporacyjnego. To, co kupują, to niezależność organizacyjna: dokumentacja rozstrzygnięta i podpisana przez wskazaną z nazwiska osobę spoza waszej organizacji, na którą można się powołać i która wycofuje się na piśmie, jeśli ustalenie się nie obroni. To właśnie ta cecha, której żaden zespół nie dostarczy o własnej pracy, i to jest całość tego, co sprzedajemy.
Czwarta strona, regulator, jest wyjątkiem i tnie w drugą stronę: często przyjmie waszą samoocenę, a potem rozliczy was z każdego dokumentu, który za nią stoi.
Czego wymaga tu CRA. Dwie ścieżki zgłoszeniowe, obie przez jedną platformę zgłoszeniową i obie obowiązujące od 11 września 2026 r. (artykuł 14). Dla podatności aktywnie wykorzystywanej: wczesne ostrzeżenie w ciągu 24 godzin od powzięcia wiedzy, zgłoszenie w ciągu 72 godzin oraz sprawozdanie końcowe nie później niż 14 dni po udostępnieniu środka naprawczego lub ograniczającego. Dla poważnego incydentu: te same kroki po 24 i 72 godzinach oraz sprawozdanie końcowe w ciągu miesiąca od zgłoszenia. Przegląd zewnętrzny nie jest zgłoszeniem i go nie zastępuje; może natomiast sprawić, że „co wiedzieliśmy, kiedy i jak to ustaliliśmy” stojące za zgłoszeniem będzie dokumentem, a nie rekonstrukcją. Odrębnie: produkty zaklasyfikowane jako ważne (załącznik III) lub krytyczne (załącznik IV) podlegają procedurom oceny zgodności na podstawie artykułu 32, w które może być zaangażowana jednostka notyfikowana, którą nie jesteśmy i której nic na tej stronie nie zastępuje.
Przechowywanie
Dokumentacja techniczna i deklaracja zgodności UE są przechowywane do dyspozycji przez co najmniej dziesięć lat po wprowadzeniu produktu do obrotu lub przez okres wsparcia, w zależności od tego, który z tych okresów jest dłuższy (artykuł 13 ustęp 13). Dokumentację przechowywaną przez dekadę przeczyta ktoś, kogo nie było w pokoju, z większą ilością czasu i mniejszą życzliwością niż ktokolwiek, kto ją pisał. Każde twierdzenie w naszej nazywa szczebel dowodowy, który osiągnęło, każda zbadana i uznana za solidną powierzchnia nazywa metodę i kontrolę, każde wycofanie jest zapisane, bo to właśnie dla tego czytelnika jest zbudowana.
Jedno zdanie
Narzędzia generują kandydatów. My generujemy podpisaną, stopniowaną dowodowo dokumentację, która mówi waszemu nabywcy, waszemu ubezpieczycielowi i waszemu regulatorowi, co ustalono o waszym kodzie, na jakim szczeblu, co pozostaje niepewne i kto odpowiada za to, że tak powiedział. Nie to, co jest prawdą (żaden recenzent tego nie obieca), lecz to, co zostało pokazane, i w jaki sposób.
Ograniczenia, które należą do tej strony: nie wykazaliśmy, że panel znajduje więcej rzeczywistych defektów niż jeden dobry recenzent, i tego nie twierdzimy; niezależność naszych instancji jest ograniczona procedurą i niezmierzona; nasza ława recenzencka to dwie osoby; należymy do grupy, która buduje infrastrukturę płatniczą i powierniczą, i deklarujemy to na piśmie przed każdym zleceniem; nie jesteśmy jednostką notyfikowaną i nic tutaj nie jest poradą prawną. Odesłania do rozporządzenia dotyczą rozporządzenia (UE) 2024/2847 i zostały sprawdzone z oficjalnym tekstem polskim przed publikacją tej notatki; odczytanie cyklu życia oraz twierdzenie o tym, który etap bywał dawniej drogi, są nasze. Jeśli odesłanie jest błędne, poprawiamy je tutaj, na piśmie.