Czym jest analiza składu oprogramowania (SCA)? Jak działa

Jak działa SCA

Identyfikacja komponentów. Narzędzie odczytuje to, na co je skierowano: manifesty i lockfile w repozytorium, zainstalowane pakiety albo zawartość obrazu kontenera lub pliku binarnego. Wynikiem jest inwentarz komponentów i wersji, często eksportowany jako SBOM.
Dopasowanie do znanych ryzyk. Każdy komponent jest wyszukiwany w bazach podatności, takich jak GitHub Advisory Database, OSV i NVD, a jego deklarowana licencja jest sprawdzana względem Państwa polityki.
Priorytetyzacja. Znaleziska są szeregowane według dotkliwości, a niektóre narzędzia dodają analizę osiągalności, aby sprawdzić, czy Państwa kod w ogóle może wywołać podatną funkcję.
Naprawa. Wiele narzędzi sugeruje wersję z poprawką lub otwiera pull request, tak jak Dependabot i Renovate. W przypadku podatnej zależności przechodniej poprawka zwykle dotyczy pakietu, który ją pobiera, a pokazuje to graf zależności.

Co znajduje SCA

Znane podatności w używanych przez Państwa wersjach, wraz z opisującymi je biuletynami.
Ryzyko licencyjne, na przykład licencję copyleft w produkcie własnościowym.
Przestarzałe i nieutrzymywane pakiety, które nie otrzymają poprawek bezpieczeństwa.
Złośliwe pakiety, w narzędziach, które analizują także zachowanie pakietów, a nie tylko dopasowują biuletyny.

SCA a SAST

SCA i statyczne testowanie bezpieczeństwa aplikacji (SAST) są często sprzedawane razem, ale dotyczą innego kodu i odpowiadają na inne pytania.

	SCA	SAST
Co analizuje	Komponenty open source i zewnętrzne, od których Państwo zależą	Kod pisany przez Państwa zespół
Co znajduje	Znane podatności, problemy licencyjne, przestarzałe pakiety	Błędy w Państwa kodzie, takie jak wstrzyknięcia lub niebezpieczna obsługa danych wejściowych
Co odczytuje	Manifesty, lockfile, zainstalowane pakiety, obrazy lub pliki binarne	Kod źródłowy
Skąd bierze się nowe znalezisko	Ze zmiany zależności lub nowego biuletynu dla już dostarczanej wersji	Ze zmiany w Państwa kodzie
Typowy wynik	Podatne komponenty z wersjami zawierającymi poprawkę oraz SBOM	Miejsca w kodzie z błędem i sugerowaną poprawką

Potrzebne są oba. Kod bez znalezisk SAST może nadal zawierać podatną zależność, a czyste drzewo zależności nie mówi nic o Państwa własnym kodzie. Pełne porównanie zawiera strona SAST vs SCA. Jedna różnica ma znaczenie dla sposobu ich uruchamiania: znalezisko SAST pojawia się, gdy zmienia się Państwa kod, natomiast znalezisko SCA może się pojawić w wydaniu dostarczonym kilka miesięcy temu, w dniu publikacji nowego biuletynu.

Gdzie kończy się SCA

Każdy wynik SCA zależy od pierwszego kroku: identyfikacji komponentów. Komponentu, którego narzędzie nigdy nie zidentyfikowało, nie można dopasować, uszeregować ani naprawić, i nie pojawia się on też jako luka. Typowe martwe punkty:

To, czego nie mówią pliki. Większość narzędzi SCA odczytuje manifesty i lockfile. Brakujący lub nieaktualny lockfile, pakiety przywrócone z cache CI, narzędzia buildu, pobrania i skrypty instalacyjne nigdy nie trafiają do inwentarza. Zob. dlaczego lockfile nie jest zapisem tego, co dostarczono.
Narzędzia się nie zgadzają. Dwa skanery skierowane na ten sam commit zwracają różne listy komponentów, ponieważ każdy ma własne zasady tego, co odczytywać i jak to nazywać. Zob. czego nie widzą generatory SBOM open source.
Pliki binarne. Oprogramowanie dystrybuowane jako gotowy plik binarny deklaruje niewiele lub nic, co mógłby zobaczyć czytnik manifestów.
Tylko znane podatności. Dopasowywanie znajduje to, co opublikowano. Nowy złośliwy pakiet lub nieujawniona luka nie mają jeszcze biuletynu.
Migawka. Skan w pull requeście opisuje tamten moment. Nowe biuletyny dotyczące wersji już działających na produkcji wymagają czegoś, co stale sprawdza to, co dostarczono.

To nie jest wada jednego produktu. Tak działa skanowanie, komercyjne 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.

Rejestrować build, zachować SCA

CRACI zamyka lukę w identyfikacji od strony buildu. 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, w SBOM określającym własną kompletność. Na bieżąco ponownie ocenia SBOM-y dostarczonego oprogramowania w miarę publikowania nowych podatności, a historia buildów pokazuje, które wcześniejsze buildy zawierały podatny pakiet.

CRACI celowo nie wykonuje SAST ani analizy osiągalności. Zespoły uruchamiają go obok narzędzia SCA lub SAST, które obejmuje pull requesty i ich własny kod. Zob. porównanie narzędzi SCA, miejsce CRACI obok Państwa narzędzi SCA lub proszę umówić demo, aby porównać zarejestrowany SBOM z obecnym skanem.

Analiza składu oprogramowania: najczęściej zadawane pytania

Czym jest SCA w cyberbezpieczeństwie?

Analiza składu oprogramowania (SCA) to praktyka znajdowania komponentów open source i zewnętrznych w Państwa oprogramowaniu oraz sprawdzania ich pod kątem znanych podatności, problemów licencyjnych i przestarzałych wersji. Obejmuje kod, od którego Państwo zależą, w odróżnieniu od kodu, który Państwo piszą.

Czym SCA różni się od SAST?

SAST analizuje kod pisany przez Państwa zespół pod kątem błędów, takich jak podatności na wstrzyknięcia. SCA analizuje komponenty, od których Państwo zależą, pod kątem znanych podatności i problemów licencyjnych. Odpowiadają na inne pytania, dlatego większość programów bezpieczeństwa stosuje oba.

Co oznacza skanowanie SCA?

Skan SCA odczytuje manifesty, lockfile, zainstalowane pakiety lub obraz kontenera projektu, ustala, jakie komponenty się w nim znajdują, i dopasowuje je do danych o podatnościach i licencjach. Wynikiem jest lista znalezisk, często z SBOM zidentyfikowanych komponentów.

Czy SBOM to to samo co SCA?

Nie. SBOM to inwentarz: lista komponentów w wydaniu. SCA to analiza: identyfikowanie komponentów i sprawdzanie ich pod kątem ryzyka. Wiele narzędzi SCA przy okazji tworzy SBOM, a SBOM może zasilać monitorowanie podatności po wydaniu.

Jakie są ograniczenia SCA?

Analizuje tylko komponenty, które potrafi zidentyfikować, zwykle na podstawie manifestów i lockfile. Pakiety przywrócone z cache CI, narzędzia buildu, pobrania i pliki binarne bez metadanych pakietów mogą zostać pominięte. Znajduje znane podatności, a nie nieznane, a skan jest migawką, chyba że narzędzie stale sprawdza to, co dostarczono.

Jakie są najlepsze narzędzia SCA?

To zależy od tego, czego Państwo potrzebują ponad podstawy: analizy osiągalności, wykrywania złośliwych pakietów, polityki licencyjnej czy workflow programistów. Co obejmuje każde z 13 narzędzi SCA i gdzie się kończy, pokazuje nasze porównanie.