Analiza osiągalności

Dlaczego powstała

Skan SCA dopasowuje wersje pakietów do biuletynów. Wie, że dana wersja zawiera błąd, ale nie wie, czy Państwa aplikacja używa fragmentu z tym błędem. Biblioteka z setkami funkcji i jednym podatnym parserem jest zgłaszana tak samo niezależnie od tego, czy ten parser jest wywoływany, a w dużym drzewie zależności składa się to na zaległości, których nikt nie jest w stanie nadrobić.

Jak działa analiza osiągalności

1. Znalezienie podatnego kodu. Narzędzie musi wiedzieć, w której funkcji znajduje się podatność. Biuletyny często tego nie podają, dlatego dostawcy utrzymują własne dane.
2. Zbudowanie grafu wywołań. Narzędzie mapuje, które funkcje wywołują które, od Państwa kodu w dół przez zależności.
3. Szukanie ścieżki. Jeśli łańcuch wywołań prowadzi od Państwa kodu do podatnej funkcji, znalezisko jest osiągalne. Jeśli nie, zostaje oznaczone jako nieosiągalne i otrzymuje niższą pozycję.

Poziomy osiągalności

Poziom	Na jakie pytanie odpowiada	Kompromis
Zależność	Czy pakiet jest w ogóle importowany?	Tani, ale eliminuje tylko nieużywane zależności
Funkcja	Czy ścieżka wywołań może dotrzeć do podatnej funkcji?	Typowy cel; wymaga grafu wywołań i danych o podatnościach dla każdej funkcji
Czas działania	Czy ten kod został załadowany lub uruchomiony na produkcji?	Dowody z prawdziwego ruchu, ale tylko dla tego, co działało w czasie obserwacji

Prawdziwy exploit wymaga czegoś więcej niż ścieżki. Dane wejściowe muszą dotrzeć do funkcji w postaci wyzwalającej błąd, a to potrafi ocenić niewiele narzędzi.

Gdzie analiza osiągalności zawodzi

• Nieosiągalne nie znaczy bezpieczne. Oznacza tylko, że narzędzie nie znalazło ścieżki. Refleksja, dynamiczne importy i ładowanie wtyczek mogą tworzyć ścieżki, których analiza statyczna nie widzi.
• Pokrycie języków jest różne. Języki kompilowane statycznie łatwiej prześledzić niż dynamiczne, a narzędzia różnią się tym, które ekosystemy obejmują analizą na poziomie funkcji.
• Dane o podatnościach są niepełne. Jeśli nikt nie przypisał biuletynu do funkcji, narzędzie nie ma czego szukać.
• Wynik zmienia się wraz z kodem. Znalezisko nieosiągalne dziś może stać się osiągalne po następnym wydaniu, więc odpowiedź wymaga ponownego sprawdzania.
• Szereguje tylko to, co zidentyfikowano. Komponentu, którego skaner nie znalazł, nie da się przeanalizować. Bez kompletnego inwentarza osiągalność porządkuje tylko część obrazu.

Jak korzystać z niej bezpiecznie

• Używać jej do ustalania kolejności, a nie do odrzucania. Najpierw naprawiać znaleziska osiągalne, a resztę planować, zamiast je zamykać.
• Nie pozwalać, by przeważała nad aktywnym wykorzystaniem. Znalezisko z katalogu KEV agencji CISA lub z wysokim wynikiem EPSS zasługuje na decyzję człowieka, nawet jeśli oznaczono je jako nieosiągalne.
• Zachować ostrożność przy usługach dostępnych z internetu. Koszt błędnej odpowiedzi jest najwyższy tam, gdzie napastnicy mogą dotrzeć do Państwa bezpośrednio.
• Zapisywać uzasadnienie. Jeśli uznają Państwo, że znalezisko nie ma zastosowania, oświadczenie VEX zachowa tę decyzję i wyjaśni klientom jej powód.

Jak osiągalność łączy się z dotkliwością, danymi o exploitach i kontekstem biznesowym, wyjaśnia strona jak priorytetyzować podatności.

Które narzędzia oferują analizę osiągalności?

Oferuje ją wiele komercyjnych narzędzi SCA, w tym Snyk, Endor Labs, Mend, Checkmarx, Semgrep i Aikido, a jej głębokość zależy od języka. Bezpłatnym przykładem dla jednego ekosystemu jest govulncheck dla języka Go. Co obejmuje każde z nich, pokazuje porównanie najlepszych narzędzi SCA.

Miejsce CRACI

CRACI nie oferuje analizy osiągalności. Działa na etapie poprzedzającym ją: pozwala ustalić, co w ogóle jest w buildzie. To runner GitHub Actions, który rejestruje każdy pakiet pobrany przez każde zadanie, łącznie z ukrytymi zależnościami pomijanymi przez skanery lockfile, i na bieżąco ponownie ocenia SBOM-y dostarczonego oprogramowania w miarę publikowania nowych podatności. Jeśli osiągalność jest Państwa najwyższym priorytetem, warto obok CRACI używać narzędzia stworzonego do tego celu. Zob. miejsce CRACI obok Państwa narzędzi SCA.

Analiza osiągalności: najczęściej zadawane pytania

Czym jest analiza osiągalności w SCA?

Sprawdza, czy Państwa kod może faktycznie wywołać podatną funkcję w zależności, aby znaleziska bez ścieżki od Państwa kodu mogły otrzymać niższą pozycję.

Czy analiza osiągalności jest dokładna?

Jest przydatna, ale nie stanowi dowodu. Znalezisko osiągalne ma prawdziwą ścieżkę, a nieosiągalne oznacza tylko, że narzędzie żadnej nie znalazło. Refleksja, dynamiczne ładowanie i luki w danych o podatnościach mogą ukryć ścieżkę.

Czy można ignorować nieosiągalne podatności?

Nie należy ich całkowicie ignorować. Warto zaplanować je po znaleziskach osiągalnych, sprawdzać ponownie po zmianach kodu i szczególnie uważać na wszystko, co jest aktywnie wykorzystywane w atakach lub działa w usłudze dostępnej z internetu.

Jaka jest różnica między osiągalnością a możliwością wykorzystania?

Osiągalność pyta, czy kod może dotrzeć do podatnej funkcji. Możliwość wykorzystania pyta, czy napastnik może użyć tej ścieżki, aby wyrządzić szkodę. Błąd może być osiągalny, a mimo to niemożliwy do wykorzystania w Państwa konfiguracji.

Czy analiza osiągalności ogranicza liczbę alertów?

Tak, to jej główny cel. To, w jakim stopniu, zależy od języka, narzędzia i tego, jaką część każdej zależności wykorzystuje Państwa kod.