Od SBOM do bramki podatności: Syft i Grype w pipeline CI dla MSP

Dostawcy usług zarządzanych prowadzący pipeline'y CI dla klientów mogą połączyć dwa open source'owe narzędzia Anchore, Syft i Grype, w jedną bramkę dla łańcucha dostaw oprogramowania: Syft katalogsuje każdy pakiet builda w spisie materiałowym oprogramowania (SBOM), a Grype porównuje ten spis ze znanymi podatnościami, zanim build zostanie dopuszczony dalej. Ten przewodnik opisuje, co robi każde z narzędzi, jak się ze sobą łączą i gdzie samo połączenie nie wystarcza.

Najpierw wygeneruj spis, za pomocą Syft

Syft, utrzymywany przez Anchore na licencji Apache-2.0, generuje SBOM w formacie SPDX lub CycloneDX na podstawie obrazów kontenerów, systemów plików i pakietów. Anchore wydał syft v1.52.0 17 września, naprawiając dwa błędy katalogerów, które dawały niedokładne spisy: kataloger bazy RPM zgłaszał nieaktualną wersję biblioteki z jednowarstwowego obrazu Rocky Linux 10, a kataloger archiwów Java zwracał nieznaną wersję dla uber-jarów. Wydanie niesie też porządki w zależnościach: 52 zmiany usuwające sześć znanych podatności, w tym aktualizację biblioteki grpc-go, która zamknęła kilka opublikowanych rekomendacji. Poprawki katalogerów liczą się przede wszystkim dla zespołów opierających się na obrazach RPM lub uber-jarach Javy, gdzie nieaktualna lub nieznana wersja w SBOM maskowałaby to, co faktycznie sprawdza skaner dalej w łańcuchu.

Grype zamienia spis w bramkę

Grype, również utrzymywany przez Anchore, skanuje obrazy kontenerów, systemy plików i SBOM-y pod kątem znanych podatności. Na 23 września 2026 repozytorium na GitHubie pokazywało około 12 900 gwiazdek i commit sprzed dwóch dni, co wskazuje na aktywne utrzymanie. Włączony do pipeline'u CI zaraz po wygenerowaniu SBOM, Grype pozwala automatycznie oblać build, gdy pojawi się znana CVE, zamiast liczyć na to, że ktoś przypomni sobie o sprawdzeniu później. Standardowy przepływ generuje SBOM podczas builda, zwykle za pomocą Syft, a następnie uruchamia Grype na tym SBOM oraz opcjonalnie bezpośrednio na zbudowanym obrazie, sprawdzając każdy wymieniony komponent względem danych o znanych podatnościach. Próg istotności decyduje, czy zadanie się nie powiedzie: wszystko powyżej niego blokuje merge, chyba że istnieje zarejestrowany wyjątek z właścicielem i terminem.

Uczyń wyjątki widocznymi, nie cichymi

Bramka typu fail-closed ma sens tylko wtedy, gdy wyjątki są widoczne i mają właściciela. Bez spisanego procesu wyjątków zespoły albo wyłączają bramkę przy pierwszej pilnej blokadzie, albo gromadzą ciche obejścia, które niweczą sens samego skanowania. Wyjątek powinien wskazywać właściciela, powód i datę wygaśnięcia, po której ustalenie jest ponownie oceniane, a nie obowiązywać bezterminowo.

Czego bramka nie robi

Grype pokazuje, co jest znane jako podatne w tym, co ma zostać wydane; nie instaluje poprawek, nie egzekwuje zasady minimalnych uprawnień ani nie zastępuje monitorowania w czasie działania po wdrożeniu obciążenia. Zależy też od aktualności swojej bazy podatności, więc przypięcie skanera do nieaktualnego źródła danych niweczy jego cel. Przy standaryzowaniu tego podejścia w pipeline'ach wielu klientów praktycznym krokiem jest przetestowanie progów istotności najpierw w pipeline'ie nieprodukcyjnym, bo zbyt agresywny próg tylko nauczy zespoły omijania bramki. Archiwizowanie każdego SBOM razem z artefaktem builda zamienia też ten sam spis w pakiet dowodowy dla klientów lub ubezpieczycieli, bez dodatkowego kosztu skanowania. Dostawcy potrzebujący zewnętrznego wsparcia w testach penetracyjnych, ocenie podatności, reagowaniu na incydenty lub zgodności z NIS2/DORA/RODO mogą skorzystać z usług cyberbezpieczeństwa Altovar.

Co zrobić

• Dodaj Syft jako krok builda generujący SBOM w formacie SPDX lub CycloneDX dla każdego obrazu lub artefaktu i spraw, by build kończył się niepowodzeniem, gdy generowanie zwróci błąd.
• Uruchom Grype na tym SBOM, a opcjonalnie także na zbudowanym obrazie, zaraz potem, z progiem istotności przetestowanym najpierw w pipeline'ie nieprodukcyjnym.
• Spisz proces wyjątków, zanim bramka trafi do produkcji: kto może go przyznać, co musi odnotować i kiedy wygasa.
• Archiwizuj każdy SBOM razem z artefaktem builda, aby mógł później posłużyć jako pakiet dowodowy dla klientów lub ubezpieczycieli.
• Utrzymuj bazę podatności Grype na bieżąco; nieaktualne źródło danych przepuści buildy, które bramka powinna była zablokować.
• Połącz bramkę z łataniem i monitorowaniem w czasie działania, bo żadne z tych narzędzi nie obejmuje tego, co dzieje się po wdrożeniu.

Źródła: Grype na GitHubie, wydania anchore/syft.