Automatyczne usuwanie podatności: od znaleziska do poprawki

Co oznacza automatyczne usuwanie podatności

Usuwanie podatności to wyeliminowanie znanej podatności z oprogramowania: aktualizacja danego pakietu, zastosowanie łatki lub zastąpienie komponentu. Automatyczne usuwanie przekazuje mechaniczną część tej pracy oprogramowaniu. Czyta ono znalezisko, ustala, która wersja je naprawia, zmienia manifest, lockfile lub kod i proponuje zmianę, najczęściej jako pull request.

W przypadku zależności zewnętrznych, w których znajduje się większość znanych podatności współczesnego kodu, pętla wygląda tak samo w każdym narzędziu:

1. Inwentarz. Wiedzieć, które pakiety i w jakich wersjach znajdują się w każdej dostarczanej rzeczy.
2. Dopasowanie. Porównywać ten inwentarz z biuletynami i robić to dalej, gdy pojawiają się nowe.
3. Priorytetyzacja. Zdecydować, co naprawić najpierw, według dotkliwości, wykorzystania i narażenia.
4. Poprawka. Wybrać naprawioną wersję, zaktualizować i dostosować kod, jeśli aktualizacja coś zepsuje.
5. Weryfikacja. Zbudować i przetestować zmianę, a następnie potwierdzić, że dostarczono naprawioną wersję.
6. Zapis. Zachować ślad tego, czego to dotyczyło, kiedy to naprawiono i w którym wydaniu.

Automatyzacja jest najmocniejsza w krokach 2, 4 i 6, gdzie praca jest powtarzalna. Najsłabsza jest tam, gdzie dane wejściowe są błędne, a danymi wejściowymi do wszystkiego innego jest krok 1.

Cztery rodzaje automatycznego usuwania

Podejście	Co robi	Przykłady	Gdzie się kończy
Boty aktualizujące zależności	Otwierają pull requesty, które podnoszą podatną zależność do naprawionej wersji	Dependabot security updates, Renovate	Działają na podstawie manifestów i lockfile w repozytorium; aktualizacja łamiąca zgodność nadal wymaga człowieka, który dostosuje kod
Pull requesty z poprawkami SCA	Otwierają pull requesty z aktualizacjami dla znalezisk zgłaszanych przez komercyjne narzędzie SCA	Snyk, Black Duck, Aikido, Endor Labs	Zakres jest różny: niektóre narzędzia naprawiają tylko zależności bezpośrednie, inne dodają łatki lub backporty
Poprawki kodu z AI	Generują zmianę kodu dla znaleziska, często alertu analizy statycznej	GitHub Copilot Autofix	Niedeterministyczne sugestie, które wymagają przeglądu; zob. usuwanie z pomocą AI
Automatyczne usuwanie w infrastrukturze	Cofa błędną konfigurację lub łata hosta po uruchomieniu reguły	Narzędzia do stanu bezpieczeństwa chmury i punktów końcowych	Obejmuje działającą infrastrukturę, a nie zależności w dostarczanym oprogramowaniu

Pierwsze trzy naprawiają dostarczany kod i wszystkie zakładają to samo: że lista podatnych pakietów, które naprawiają, jest właściwą listą.

Każda poprawka zależy od inwentarza

Narzędzie do usuwania podatności może naprawić tylko te podatności, o których wie, a wie o tych, które zawiera jego inwentarz. Większość inwentarzy jest odtwarzana z plików: manifestów, lockfile, zainstalowanych pakietów lub gotowego obrazu kontenera. Takie odtwarzanie pomija różne rzeczy w przewidywalny sposób.

• Pakiety, których pliki nie deklarują. Narzędzia pobierane przez build, obrazy bazowe, wtyczki i wszystko, co instaluje skrypt, nigdy nie pojawiają się w lockfile, więc nigdy nie powstaje dla nich pull request z poprawką.
• Wersje inne niż w lockfile. Build może rozwiązać inną wersję niż ta, którą czyta skaner, zwłaszcza bez zacommitowanego lockfile. Poprawka oparta na błędnej wersji to pewna siebie błędna odpowiedź.
• Pakiety przywrócone z cache. Zależność z cache nie łączy się ponownie z rejestrem, więc to, czego użył build, może pozostawać w tyle za tym, co mówi repozytorium.

Rozwiązaniem jest wyjście od tego, czego build faktycznie użył. SBOM z buildu jest rejestrowany podczas działania buildu, więc wymienia pakiety pobrane przez zadanie, łącznie z przechodnimi, a nie to, czego według manifestu powinno ono potrzebować. Usuwanie, które zaczyna od tego miejsca, naprawia to, co jest dostarczane.

Co automatyzować, a co zostawić ludziom

Większość zespołów, którym usuwanie podatności działa, dzieli je tak:

• Zautomatyzować znajdowanie i dopasowywanie. Nowe biuletyny pojawiają się każdego dnia. Ręczne ponowne sprawdzanie względem nich każdego dostarczonego buildu się nie skaluje, a to dokładnie ten rodzaj pracy, który oprogramowanie wykonuje dobrze.
• Zautomatyzować propozycję. Wybór naprawionej wersji i otwarcie zmiany to czynności mechaniczne. Warto grupować powiązane aktualizacje, aby recenzenci widzieli jeden pull request zamiast dwudziestu.
• Uzależnić scalenie od testów. Automatycznie scalać aktualizacje bezpieczeństwa na poziomie patch objęte testami. Aktualizacje łamiące zgodność i wszystko, co nie ma pokrycia testami, zostawić człowiekowi.
• Zostawić decyzje oceniające ludziom. To, czy podatność w ogóle dotyczy Państwa produktu i czy ryzykowna aktualizacja jest warta wykonania w tym tygodniu, to decyzje. Należy je zapisywać, na przykład jako oświadczenie VEX, aby to samo pytanie nie padało dwa razy.

Jak ocenić narzędzie do usuwania podatności

Zanim powierzą Państwo narzędziu otwieranie pull requestów w swoich repozytoriach, warto zapytać:

1. Skąd pochodzi jego lista podatności: z plików w repozytorium, ze skanowanego obrazu czy z samego buildu?
2. Czy naprawia zależności przechodnie, czy tylko deklarowane zależności bezpośrednie?
3. Jak wybiera naprawioną wersję: minimalną załataną, najnowszą czy przypiętą przez Państwa?
4. Czy poprawka jest budowana i testowana, zanim ją Państwo zobaczą, czy pull request jest jej pierwszym uruchomieniem?
5. Czy potrafi grupować i planować aktualizacje, aby nie zalewać recenzentów?
6. Czy zapisuje, których wydań to dotyczyło i kiedy dostarczono każdą poprawkę?

Jaką rolę pełni dziś CRACI

CRACI uruchamia Państwa zadania GitHub Actions na własnych runnerach i rejestruje pakiety faktycznie pobrane przez każde zadanie, łącznie z zależnościami przechodnimi i pakietami przywróconymi z cache, z określonym stanem kompletności dla każdego zadania. Ten zapis to inwentarz, od którego powinien zaczynać proces usuwania podatności.

CRACI stale ponownie ocenia monitorowane SBOM-y, więc gdy pojawi się nowy biuletyn, widzą Państwo, których dostarczonych buildów dotyczy w różnych repozytoriach. Zespoły bezpieczeństwa wykonują triaż każdego znaleziska i przekazują je zespołowi odpowiedzialnemu za poprawkę, a CRACI obsługuje VEX do zapisywania, jak podatność wpływa na Państwa produkt. SBOM kolejnego buildu pokazuje następnie, czy build naprawdę użył naprawionej wersji. Pełny opis tej funkcji znajdą Państwo na stronie śledzenie podatności.

Zgodnie z unijnym Cyber Resilience Act producenci muszą bez zwłoki zajmować się podatnościami i je usuwać, także przez aktualizacje bezpieczeństwa. Zapis tego, co zawierał każdy build i kiedy dostarczono każdą poprawkę, to dowód, którego potrzebuje ten proces.

Automatyczne usuwanie podatności: najczęściej zadawane pytania

Czym jest automatyczne usuwanie podatności?

Automatyczne usuwanie podatności to oprogramowanie, które zamienia znalezisko w poprawkę bez ręcznej pracy człowieka: ustala naprawioną wersję, zmienia manifest, lockfile lub kod i proponuje zmianę, zwykle jako pull request. O tym, co zostanie scalone, nadal decyduje człowiek lub polityka, której zespół ufa.

Jaka jest różnica między usuwaniem a łagodzeniem podatności?

Usuwanie eliminuje podatność, na przykład przez aktualizację do naprawionej wersji lub zastosowanie łatki. Łagodzenie zmniejsza ryzyko, gdy podatność nadal istnieje, na przykład przez wyłączenie danej funkcji lub zablokowanie ścieżki ataku. Łagodzenie daje czas; usuwanie zamyka znalezisko.

Czy usuwanie podatności można w pełni zautomatyzować?

Częściowo. Znajdowanie buildów, których to dotyczy, dopasowywanie biuletynów i proponowanie podniesienia wersji to czynności mechaniczne, które dobrze się automatyzują. Decyzja, czy aktualizacja łamiąca zgodność jest bezpieczna lub czy podatność w ogóle dotyczy Państwa produktu, nadal wymaga oceny. Większość zespołów automatyzuje propozycję, a przy scalaniu zostawia człowieka wspieranego testami.

Czy Dependabot wykonuje automatyczne usuwanie podatności?

Dependabot security updates otwierają pull requesty, które aktualizują podatną zależność do minimalnej załatanej wersji, dla alertów zgłaszanych przez GitHub na podstawie grafu zależności repozytorium. To automatyczne usuwanie w zakresie tego, co deklarują manifesty i lockfile. CRACI vs Dependabot wyjaśnia, gdzie to, co zadeklarowane, różni się od tego, co dostarczone.

Na co zwrócić uwagę przy wyborze narzędzia do usuwania podatności?

Skąd pochodzi jego lista podatności, czy obsługuje zależności przechodnie, jak wybiera wersję z poprawką, czy poprawka jest budowana i testowana, zanim ją Państwo zobaczą, oraz czy zapisuje, co i kiedy naprawiono. To ostatnie ma znaczenie przy audytach i dla CRA, który wymaga od producentów usuwania podatności bez zwłoki.