Skanowanie SCA: jak działa i gdzie warto je uruchamiać

Co dzieje się podczas skanu SCA

Odczytanie celu. Skaner odczytuje manifesty i lockfile, takie jak package-lock.json, poetry.lock lub Cargo.lock, albo rozpakowuje obraz kontenera.
Zbudowanie listy komponentów. Przekłada to, co znalazł, na nazwy i wersje, zwykle łącznie z zależnościami przechodnimi.
Dopasowanie danych. Każdy komponent jest wyszukiwany w źródłach takich jak GitHub Advisory Database, OSV i NVD, a jego licencja jest porównywana z Państwa polityką.
Raport. Znaleziska są uszeregowane według dotkliwości, zwykle z wersją zawierającą poprawkę. W CI polityka może spowodować niepowodzenie zadania.

Szerszą praktykę, do której to należy, opisuje strona czym jest analiza składu oprogramowania.

Gdzie uruchamiać skany SCA

Jeden skan w jednym miejscu zostawia luki. Każdy etap odpowiada na inne pytanie, dlatego większość zespołów uruchamia więcej niż jeden.

Gdzie	Na co odpowiada	Czego nie widzi
Komputer programisty lub IDE	Czy ten pakiet można bezpiecznie dodać?	Wszystkiego, na czym programista go nie uruchomi
Pull request	Czy ta zmiana wprowadza znane ryzyko?	Nowych biuletynów dotyczących kodu, który się nie zmienił
Build CI	Co zawiera wydanie?	Tego, czego skaner nie widzi w buildzie
Rejestr kontenerów	Co jest w tym obrazie?	Skompilowanego kodu i narzędzi buildu, które nie zostawiają śladu
Po wydaniu	Czy coś nowego dotyczy tego, co dostarczyliśmy?	Niczego, jeśli zapis tego, co dostarczono, jest kompletny

Ostatni wiersz to ten, który większość programów pomija. Nowy biuletyn dotyczy wersji dostarczonej kilka miesięcy temu, a żaden pull request nie uruchomi dla niego skanu.

Jak czytać wyniki skanu SCA

Pierwszy skan prawdziwego projektu często zwraca setki znalezisk. Warto przejść przez nie w tej kolejności:

Zacząć od tego, co jest wykorzystywane w atakach. Znalezisko z katalogu KEV agencji CISA jest ważniejsze niż wyższy wynik CVSS bez znanego wykorzystania. Zob. jak priorytetyzować podatności.
Sprawdzić, czy ma zastosowanie. Zależności wyłącznie deweloperskie nie są dostarczane. Niektóre narzędzia dodają analizę osiągalności, aby sprawdzić, czy podatny kod w ogóle może zostać wywołany.
Naprawiać na właściwym poziomie. W przypadku znaleziska przechodniego poprawka zwykle dotyczy pakietu, który je pobiera, a pokazuje to graf zależności.
Zapisać, czego się nie naprawia. Zaakceptowane znalezisko powinno mieć uzasadnienie, inaczej kolejna osoba powtórzy tę samą pracę. Standardowym sposobem zapisu jest VEX.

Dlaczego czysty skan nie oznacza czystego oprogramowania

Widzi to, co zadeklarowane. Skaner odczytuje pliki, które ma przed sobą, więc repozytorium bez lockfile daje mu niewiele materiału, a kod pobierany przez hook instalacyjny nigdy się nie pojawia.
Widzi to, na co go skierowano. Obraz bazowy, narzędzia buildu i GitHub Actions w pipeline'ie są oddzielone od manifestu aplikacji.
Zna tylko to, co opublikowano. Nowy złośliwy pakiet nie ma jeszcze biuletynu.
Lista to nie build. Buildy rozwiązują wersje w chwili uruchomienia, więc to, co odczytał skan, i to, co zawiera wydanie, może się różnić.

To ograniczenia samego skanowania, zarówno komercyjnego, jak i open source. CRACI znalazł podatne pakiety, których Snyk i Aikido nie zgłosiły, ponieważ tych komponentów nigdy nie było w tym, co skanowały.

Skanery bezpłatne i komercyjne

Bezpłatne opcje dobrze pokrywają podstawy. Alerty Dependabot są dostępne w GitHub, OWASP Dependency-Check i Trivy to projekty open source, a Grype współpracuje z generatorem SBOM Syft. Narzędzia komercyjne dodają polityki, priorytetyzację, osiągalność i workflow obejmujący wiele zespołów. Porównanie najlepszych narzędzi SCA obejmuje 13 z nich, a ten przewodnik pokazuje, dlaczego bezpłatne generatory dają różne wyniki.

Skanowanie SCA a rejestrowanie w czasie buildu

CRACI nie jest skanerem i nie muszą Państwo rezygnować ze swojego. To runner GitHub Actions, który rejestruje każdy pakiet pobrany przez każde zadanie, na każdym poziomie drzewa, łącznie z pakietami przywróconymi z cache CI, a następnie na bieżąco ponownie ocenia SBOM-y dostarczonego oprogramowania w miarę publikowania nowych podatności. Państwa skaner obejmuje pull requesty i komputery programistów. CRACI obejmuje build i wszystko, co po nim. Zob. miejsce CRACI obok Państwa narzędzi SCA.

Skanowanie SCA: najczęściej zadawane pytania

Czym jest skan SCA?

Skan SCA odczytuje manifesty, lockfile lub obraz kontenera projektu, ustala, jakich komponentów open source projekt używa, i sprawdza je względem danych o podatnościach i licencjach.

Czy SCA to to samo co skanowanie zależności?

Prawie. Skanowanie zależności zwykle oznacza sprawdzanie zależności pod kątem znanych podatności. SCA to pojęcie szersze, które obejmuje też licencje, przestarzałe pakiety i tworzenie inwentarza, takiego jak SBOM.

Kiedy należy uruchamiać skany SCA?

Przy pull requestach, aby zatrzymać nowe ryzyka; w buildzie CI, aby opisać wydanie; i w sposób ciągły po wydaniu, ponieważ nowe biuletyny dotyczą oprogramowania, które już zostało dostarczone.

Ile trwa skan SCA?

Zwykle od kilku sekund do kilku minut, ponieważ odczytuje metadane, a nie analizuje całego kodu. Dzięki temu można go uruchamiać przy każdym pull requeście.

Dlaczego skanery SCA podają różne wyniki?

Każdy ma własne zasady tego, co odczytywać, jak nazywać komponenty i z jakich danych o podatnościach korzystać. Ten sam commit może dać różne listy komponentów i różne znaleziska.

Czy skanowanie SCA wykrywa złośliwe oprogramowanie?

Dopasowywanie biuletynów znajduje złośliwe wydania dopiero wtedy, gdy biuletyn już istnieje. Narzędzia analizujące zachowanie pakietów mogą część z nich wychwycić wcześniej. Nowy złośliwy pakiet w dniu pojawienia się nie ma biuletynu.