Skanowanie zależności w CI: SCA, SBOM i szybkie alerty

Po co w ogóle skanować zależności w CI? Kontekst biznesowy i techniczny

Rosnący udział kodu zewnętrznego i ryzyko łańcucha dostaw

Większość współczesnych aplikacji to klocki z gotowych komponentów: frameworki, biblioteki, pluginy, kontenery bazowe. Własny kod to często kilkanaście–kilkadziesiąt procent całości. Reszta to zależności, które ktoś inny napisał, ktoś inny utrzymuje i ktoś inny może niechcący (albo celowo) popsuć.

Problem nie polega tylko na tym, że biblioteka może mieć podatność. Dochodzi ryzyko tzw. software supply chain – łańcucha dostaw oprogramowania. Ataki na repozytoria pakietów (npm, PyPI, Maven Central), przejęte konta maintainerów, złośliwe aktualizacje albo typosquatting (podstawione paczki o podobnej nazwie) to dziś codzienność. Jeśli w projekcie nikt systemowo nie monitoruje zależności, podatna lub złośliwa wersja może spokojnie przeleżeć miesiącami w produkcji.

Skalę problemu wzmacnia fakt, że każdy framework ma własne zależności, te mają kolejne i tak powstaje głęboka piramida transitive dependencies. Nawet jeśli wprost deklarujesz 20 paczek, realnie projekt może używać kilkuset bibliotek. Ręczne kontrolowanie tego jest niewykonalne, szczególnie przy szybkim cyklu release’ów.

Regulacje, wymagania klientów i presja na SCA oraz SBOM

Obok czysto technicznych argumentów pojawia się presja biznesowa i regulacyjna. Coraz częściej klienci – zwłaszcza z sektora finansowego, medycznego albo administracji – pytają o SCA (Software Composition Analysis) i SBOM (Software Bill of Materials). Dla nich to nie buzzword, ale element oceny ryzyka przed podpisaniem umowy lub audytu.

Na rynku widać też wpływ inicjatyw rządowych i standardów branżowych. Koncepcja SBOM trafiła do dokumentów NIST, pojawia się w wymaganiach przy kontraktach publicznych w USA i stopniowo przenika do korporacyjnych check-list compliance. Skoro tworzysz oprogramowanie dla większych graczy, prędzej czy później padnie pytanie: „Czy generujecie SBOM i jak zarządzacie podatnościami zależności?”

Przygotowany proces skanowania zależności w CI oraz automatyczne SBOM-y w pipeline CI/CD pozwalają odpowiedzieć na te pytania bez nerwowego „gaszenia pożaru”, kompilowania ręcznych list bibliotek czy przeszukiwania repozytoriów po terminach audytu.

Skutki realne: downtime, wycieki, przestoje i reputacja

Atak na podatną bibliotekę w aplikacji nie kończy się na suchym raporcie z CVE. W praktyce oznacza:

• przestoje produkcyjne – awaryjne okna serwisowe na patchowanie lub rollbacki, często w godzinach szczytu;
• kosztowne śledztwa – analiza logów, forensyka, czas zespołu DevOps i security;
• wycieki danych – ryzyko konsekwencji prawnych (RODO, kary, notyfikacje klientów);
• stratę reputacji – nawet drobny incydent potrafi zniszczyć obraz firmy „ogarniającej” bezpieczeństwo.

Nawet jeśli konsekwencje nie są spektakularne, wystarczy kilka wymuszonych „hotfix weekendów”, żeby team zaczął traktować bezpieczeństwo jak wieczną przeszkodę. Regularne, zautomatyzowane skanowanie zależności w CI zdejmuje większość presji – podatności są wyłapywane blisko kodu, a nie dopiero w najmniej dogodnym momencie, gdy już są eksploatowane.

Dlaczego manualne i „od święta” skanowanie przegrywa z CICD

Ręczne przeglądanie listy paczek raz na kwartał może działać, jeśli masz jeden monolit i rzadkie wydania. W realnym DevOps i CICD, z dziesiątkami commitów dziennie i feature branched, taka metoda nie ma szans:

• aktualizacje bibliotek wychodzą co kilka dni, czasem kilka razy dziennie;
• nowe podatności (CVE) publikowane są non-stop, często dotyczą wersji, które już masz w produkcji;
• każdy projekt ma inny zestaw zależności, a transitive dependencies zmieniają się nawet bez twoich jawnych modyfikacji.

Bez automatyzacji w pipeline CI pojawia się spora ślepa plamka. Developerzy dodają kolejne paczki, CI buduje i deployuje, a organizacja orientuje się po miesiącach, że kilka aplikacji siedzi na mocno dziurawym log4j czy starej wersji OpenSSL. Software composition analysis w CI zamyka ten problem w miejscu, które i tak jest standardowym „przedsionkiem produkcji”: pipeline budujący i testujący każdą zmianę.

Podstawowe pojęcia: SCA, SBOM, CVE, severity i scope

Software Composition Analysis i różnica względem SAST/DAST

Software Composition Analysis (SCA) to podejście polegające na analizie komponentów zewnętrznych w projekcie: bibliotek, frameworków, kontenerów bazowych, modułów – wszystkiego, co nie jest „twoim” kodem. Kluczowe jest tu:

• identyfikowanie konkretnej wersji każdej zależności (także pośredniej);
• mapowanie jej na bazy podatności (CVE, security advisories);
• ocena ryzyka i rekomendacja aktualizacji lub mitigacji.

SCA różni się od klasycznych testów aplikacyjnych:

• SAST (Static Application Security Testing) – skanuje twój własny kod źródłowy, szuka wzorców błędów (np. SQLi, XSS);
• DAST (Dynamic Application Security Testing) – atakuje działającą aplikację „z zewnątrz”, symuluje zachowanie atakującego.

SCA nie patrzy na logikę biznesową, tylko na „skład” projektu. Efekt: błyskawicznie pokazuje, że np. używasz podatnej wersji Spring Boot, Log4j, OpenSSL czy biblioteki JWT, nawet jeśli testy funkcjonalne przechodzą na zielono.

SBOM – cyfrowa lista składników oprogramowania

SBOM (Software Bill of Materials) to nic innego jak „faktura materiałowa” twojej aplikacji: kompletna lista komponentów wraz z wersjami, licencjami i powiązaniami. W kontekście CI/CD najczęściej generuje się SBOM w jednym z dwóch formatów:

• CycloneDX – popularny, lekki format promowany m.in. przez OWASP; wspiera wiele ekosystemów, nadaje się do skanowania, raportowania i wymiany pomiędzy narzędziami;
• SPDX – standard rozwijany m.in. przez Linux Foundation; silny nacisk na licencje i compliance, szeroka akceptacja w świecie open source.

SBOM można generować na kilku poziomach:

• dla pojedynczego serwisu/aplikacji (np. mikroserwis w Node, moduł w Javie);
• dla obrazu kontenera (Docker, OCI);
• dla całego release’u (kilka usług jako zestaw).

W pipeline CI/CD SBOM pełni kilka ról: źródło prawdy o zależnościach, materiał dowodowy dla audytu oraz wejście dla skanerów, które potrafią skanować nie kod, a właśnie SBOM (np. w osobnym, nocnym jobie). Dla małego zespołu lightweight SBOM dla małych zespołów oznacza zwykle jeden plik JSON/XML na release, trzymany jako artefakt builda lub w prostym storage.

CVE, CVSS i severity: jak czytać etykiety ryzyka

CVE (Common Vulnerabilities and Exposures) to globalny katalog znanych podatności. Każdej z nich przypisany jest identyfikator typu CVE-2023-XXXX, krótki opis, czasem link do PoC oraz odnośniki do vendorów. Samo istnienie CVE przy bibliotece nie mówi jeszcze, jak bardzo groźny jest problem w twoim kontekście.

Dlatego używa się CVSS (Common Vulnerability Scoring System), który nadaje wynik liczbowy (zwykle 0–10) oraz poziom severity:

• Critical – najwyższe ryzyko, zwykle łatwo eksploatowalne, często zdalne wykonanie kodu lub pełny dostęp;
• High – poważne, ale czasem wymagają określonych warunków lub autoryzacji;
• Medium – potencjalnie szkodliwe, ale trudniejsze do wykorzystania lub o ograniczonym wpływie;
• Low – mały wpływ lub wymóg bardzo specyficznych warunków;
• None/Informational – coś, co nie jest klasyczną podatnością, ale może wymagać uwagi.

Priorytetyzacja CVE w CI wymaga połączenia severity z kontekstem użycia. Ten sam CVE o CVSS 9.8 może być krytyczny dla aplikacji wystawionej do internetu, a praktycznie nieistotny dla narzędzia używanego wyłącznie lokalnie, w izolowanej sieci.

Zależności bezpośrednie i pośrednie – gdzie siedzi większość ryzyka

Z punktu widzenia SCA liczą się dwa typy zależności:

• direct dependencies – te, które deklarujesz samodzielnie (w package.json, pom.xml, requirements.txt itp.);
• transitive dependencies – zależności zależności: biblioteki wciągane do projektu pośrednio.

Szacunki z różnych ekosystemów pokazują, że nawet 90% ryzyka bezpieczeństwa związane jest z zależnościami pośrednimi. Developerzy rzadko śledzą, co wciąga dany framework w kolejnych poziomach. Kto świadomie zarządza całą drabinką zależności Nodowych paczek czy pluginów Gradle?

Skanowanie bibliotek open source tylko na poziomie deklarowanych paczek (bez rozwoju na transitive) jest trochę jak kontrola bagażu lotniczego po samej walizce, bez zaglądania do środka. SCA i SBOM mają właśnie za zadanie zejść głębiej, zbudować pełne drzewo zależności i dopiero na nim szukać podatności.

Gdzie wpiąć SCA i SBOM w pipeline CI, żeby nie zabić flow

Typowe punkty integracji w CI/CD

Aby skanowanie zależności w CI nie stało się kolejną przeszkodą, trzeba rozsądnie wybrać momenty jego uruchamiania. Kilka praktycznych punktów w pipeline’ach:

• na push/PR (pull request, merge request) – lekki skan przy każdej zmianie; świetny punkt na szybkie feedbacki dla developera, zanim kod trafi na main;
• przed buildem artefaktu – skaner uruchamiany po zainstalowaniu zależności, ale przed zbudowaniem obrazu lub pakietu;
• przed deployem na środowisko wyższe (staging/production) – ostatnia bramka, która może zablokować wdrożenie w razie krytycznej podatności;
• w nocnych jobach – pełne, cięższe skany (np. całe repozytoria, wszystkie obrazy kontenerów, przegląd całej organizacji).

Dobrze zaprojektowany pipeline łączy te punkty w sposób stopniowy: szybkie kontrole blisko commitów, głębsze skany w bardziej luźnych oknach czasowych.

Strategia „szybko vs dokładnie” – dwa poziomy skanowania

Kluczowa zasada, żeby nie paraliżować developmentu: oddzielić skany szybkie od dokładnych. Dobry układ wygląda następująco:

• lekkie skany przy PR – narzędzie SCA działa tylko na listach zależności (lockfile, manifesty), bez pełnej analizy drzewa i bez czasochłonnych zapytań; wynik ma być w minutach, nie w kwadransach;
• pełne skany okresowe – uruchamiane np. raz dziennie/noc lub raz na kilka godzin, obejmują wszystkie moduły, kontenery, generują SBOM i raport zbiorczy.

Dzięki temu developerzy szybko dostają informację, że np. wprowadzona nowa paczka ma znaną krytyczną podatność, ale ciężkie raporty, historyczne porównania i przegląd całej organizacji nie psują codziennego rytmu pracy. W pipeline można też parametryzować głębokość skanowania (np. „fast mode” na PR, „full mode” na main).

Tryby reakcji pipeline’u: informacyjny, ostrzegawczy i blokujący

Samo skanowanie to nie wszystko – ważne, co pipeline z wynikiem robi. Typowe tryby pracy:

• informacyjny – job zawsze kończy się sukcesem, ale generuje raport i ewentualnie wysyła notyfikacje; dobry na początek, gdy dopiero uczysz się narzędzi i nie chcesz zablokować nikomu pracy;
• ostrzegawczy – przy określonych warunkach (np. nowe High/Critical) pipeline jest „na żółto”: build przechodzi, ale wymagane jest ręczne potwierdzenie lub komentarz w PR; pozwala zobaczyć, jak często i jak poważne są alerty;
• blokujący – pipeline kończy się niepowodzeniem, jeśli np. wykryto nową podatność Critical lub High powyżej ustalonego progu; to już etap, gdy zespół ma proces reagowania.

Rozsądna ścieżka dla budżetowego zespołu: przez kilka tygodni tryb informacyjny i ostrzegawczy, z równoległym porządkowaniem „starego długu” w zależnościach. Dopiero gdy typowe problemy zostaną opanowane, można włączyć blokowanie buildów – zwykle najpierw tylko dla nowych zmian (PR), dopiero później dla całego main.

Projektowanie jobów tak, by nie wydłużać buildów

Najczęstszy zarzut do SCA w CI: „skan dodaje 10–15 minut do każdego builda”. Da się tego uniknąć, jeśli pipeline jest sensownie ułożony:

Cache, równoległość i selektywne skanowanie

Żeby skanowanie nie pożerało minut na każdym buildzie, trzeba maksymalnie wykorzystać to, co CI już ma: cache, równoległe joby i warunki wykonania.

• Cache wyników i baz podatności – wiele narzędzi SCA przy każdym uruchomieniu pobiera wielkie bazy CVE. Jeśli CI za każdym razem startuje „na czysto”, skan trwa długo. Rozwiązanie: cache katalogu z bazą lub obrazu dockera z już zassanymi danymi. Aktualizację można robić np. raz dziennie w nocnym jobie.
• Równoległe joby – skan SCA nie musi czekać, aż skończy się linting czy testy. Dobrze jest uruchomić go w osobnym jobie, który startuje po instalacji zależności, a nie po całym buildzie.
• Skanowanie tylko zmienionych modułów – w monorepo nie ma sensu mielić wszystkiego na każdym PR. Prosty skrypt może określić, które projekty/manifesty się zmieniły i uruchomić skaner tylko dla nich.
• Warunkowe uruchamianie – przy drobnych zmianach (np. w dokumentacji, plikach .md) job SCA można pominąć. Wystarczy warunek typu „uruchom, jeśli zmienił się którykolwiek plik manifestu zależności lub katalog z kodem aplikacji”.

Typowy kompromis: lekkie SCA odpalane przy każdym PR na zmienione moduły, pełne skanowanie całego repo tylko z cronem, poza krytyczną ścieżką developera.

Integracja SCA z generowaniem SBOM

Żeby nie mnożyć jobów, opłaca się połączyć generowanie SBOM z SCA. Sporo narzędzi potrafi jednocześnie:

• wyciągnąć drzewo zależności z manifestu;
• porównać je z bazą CVE;
• wygenerować SBOM w formacie CycloneDX lub SPDX.

W praktyce oznacza to jeden krok w pipeline: „scan + SBOM”. SBOM trafia jako artefakt builda (lub do storage), a wynik skanowania jako raport/komentarz do PR. W późniejszym etapie można dorzucić osobny job, który czyta tylko SBOM i sprawdza go np. wobec zewnętrznej usługi – bez ponownego mielenia całego repo.

Przegląd rozwiązań SCA i SBOM: od darmowych po komercyjne

Narzędzia open source i „free tier” na start

Dla małego, oszczędnego zespołu najbardziej sensowne są narzędzia, które:

• mają gotowe integracje z popularnymi CI;
• obsługują najważniejsze dla was ekosystemy (Node, Java, Python itd.);
• oferują chociaż podstawowy SBOM.

Najczęściej wybierane opcje:

• OWASP Dependency-Check – klasyk do skanowania zależności Javy, .NET, Node, Pythona. Działa jako CLI, plugin do Maven/Gradle i w kontenerze. Plus: całkowicie darmowy, minus: bywa wolny, wymaga cache’owania bazy NVD.
• Trivy – skaner kontenerów, systemów plików i SBOM. Umi popularne języki oraz potrafi generować SBOM CycloneDX. Bardzo dobry stosunek możliwości do prostoty użycia; idealny do CI opartego na Dockerze.
• Syft + Grype – duet od Anchore: Syft generuje SBOM, Grype skanuje SBOM lub obrazy. Dobra opcja, jeśli chcesz mocno oprzeć się na SBOM w procesie.
• OSV-Scanner (Google) – skaner oparty o bazę OSV.dev, wspiera różne ekosystemy, nadaje się do szybkich skanów manifestów i lockfile’ów.

Do tego dochodzą free tier’y SaaS wbudowane w platformy:

• GitHub Dependabot / GitHub Advanced Security (free dla OSS) – automatyczne alerty na zależności, PR-y z aktualizacjami; do projektów open source bardzo sensowny „gratis”.
• GitLab Dependency Scanning (częściowo w wersji Free/Core) – podstawowe skanowanie zależności w ramach pipeline’ów GitLaba.

Rozwiązania komercyjne – kiedy mają sens

Płatne narzędzia SCA/SBOM zwykle dorzucają kilka rzeczy, które trudno odtworzyć własnymi siłami:

• lepszą bazę podatności (połączenie NVD, vendorów, researchu własnego);
• zaawansowane filtrowanie i priorytetyzację (np. czy dana podatność jest w ogóle reachable w twoim kodzie);
• wbudowane workflowy i integracje z ticketingiem, Slackiem, mailami itd.;
• dashboardy dla compliance, raporty dla klienta lub audytora.

Przykłady: Snyk, Mend (WhiteSource), GitHub Advanced Security dla prywatnych repo, GitLab Ultimate, Aqua Trivy Enterprise i sporo innych. Dla małego zespołu zakup ma sens wtedy, gdy:

• macie wiele serwisów i kontenerów oraz rosnący chaos w alertach;
• klienci lub audyt wymagają konkretnych raportów, których nie chcecie składać ręcznie;
• koszt ręcznego ogarniania open source przewyższa abonament.

Często rozsądną drogą jest hybryda: darmowe lub otwarte narzędzia na buildzie + komercyjny skaner organizacyjny „z góry”, który podgląda wszystkie projekty z jednego panelu.

Narzędzia skupione na SBOM

Jeśli priorytetem jest SBOM (np. wymagania klienta, compliance), przydają się narzędzia koncentrujące się na generowaniu i zarządzaniu listą komponentów:

• Syft – generuje SBOM z obrazu, katalogu czy repo; wspiera CycloneDX i SPDX.
• cyclonedx-cli – konwersje, walidacja SBOM, łączenie wielu plików SBOM w jeden release’owy.
• ORT (OSS Review Toolkit) – cięższa platforma do compliance i licencji, ale ma mocne wsparcie dla SBOM.

W CI SBOM może powstawać na kilka sposobów: bezpośrednio z lockfile’ów (szybciej) albo z zbudowanego obrazu (dokładniej, bo obejmuje realny runtime).

Minimalny, budżetowy setup SCA + SBOM dla małego zespołu

Założenia: mało ludzi, mało czasu, brak osobnego SecOps

Scenariusz dość typowy: zespół 3–6 devów, jedna osoba „od DevOpsa” po godzinach, brak dedykowanego security. Cele:

• mieć podstawową widoczność podatnych zależności;
• nie blokować developmentu zbyt szybko;
• móc pokazać klientowi/zarządowi, że jest proces i raport (SBOM).

Prosty zestaw narzędzi „must have”

Jedna z rozsądnych konfiguracji, którą da się postawić w kilka dni:

• Trivy – skan kontenerów i generowanie SBOM; działa jako pojedynczy binary lub obraz dockera.
• OSV-Scanner lub Dependency-Check – lekkie skany manifestów na PR, jeśli nie wszystkie projekty pakujecie w obrazy.
• Dependabot / GitLab Dependency Scanning – jeśli korzystacie z GitHuba lub GitLaba, włączenie wbudowanych alertów nic nie kosztuje.

Do tego prostą przestrzeń na SBOM (np. bucket w S3, MinIO, artefakty CI) i jeden skrypt, który wrzuca SBOM-y w ustaloną strukturę katalogów (np. /projekt/numer-builda/sbom.json).

Architektura procesu w małym zespole

Minimalny workflow może wyglądać tak:

1. PR: uruchamia się lekki skan manifestu (OSV-Scanner/Dependency-Check). Wynik ląduje jako komentarz w PR lub artefakt joba.
2. Merge do main/branch release: pipeline buduje obraz kontenera, Trivy skanuje obraz i generuje SBOM CycloneDX. SBOM trafia jako artefakt.
3. Nocny cron: osobny pipeline przechodzi po ostatnich obrazach/SBOM-ach i robi zbiorczy raport (np. lista projektów z nowymi Critical/High).
4. Raz w tygodniu: przegląd raportu i decyzje, co łatać w pierwszej kolejności.

Bez osobnego SecOpsa odpowiedzialność zwykle spada na tech leada albo devOpsa. Kluczowe, by jasno ustalić, ile czasu tygodniowo idzie na „security housekeeping” (np. 2–3 godziny) i nie próbować robić z tego pełnoetatowego programu bezpieczeństwa.

Konfiguracja pipeline: przykładowe integracje z popularnymi systemami CI

GitHub Actions – szybki start z SCA i SBOM

W GitHubie najłatwiej zacząć od wbudowanych rozwiązań, a potem dorzucić własne joby.

• Włącz Dependabot alerts i ewentualnie security updates – robi automatyczne PR-y z aktualizacjami zależności.
• Dodaj workflow, który przy pushu do main lub przy PR:
  • uruchamia lekki skan manifestu (np. OSV-Scanner z gotowego action);
  • przy buildzie obrazu dockerowego odpala Trivy do skanu obrazu + generowania SBOM.

Przykładowy szkic joba z Trivy (bez pełnego YAML-a):

jobs:
  scan-image:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:${GITHUB_SHA} .
      - name: Scan image with Trivy
        run: |
          trivy image --exit-code 0 --format table myapp:${GITHUB_SHA}
      - name: Generate SBOM
        run: |
          trivy image --format cyclonedx --output sbom.json myapp:${GITHUB_SHA}
      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

Na początek --exit-code 0 zostawia tryb informacyjny. Dopiero później można dodać reguły typu „failuj, jeśli znaleziono nowe Critical”.

GitLab CI – template’y i skan obrazów

W GitLabie da się skorzystać z gotowych template’ów do dependency scanningu, ale dla budżetowego podejścia często wygodniejsze jest własne, proste joby z Trivy.

Przykładowa struktura:

stages:
  - build
  - scan

build:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
  artifacts:
    expire_in: 1 week
    paths:
      - docker-image.tar
  after_script:
    - docker save $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA > docker-image.tar

sca_scan:
  stage: scan
  needs: ["build"]
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 0 $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - trivy image --format cyclonedx --output sbom.json $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    expire_in: 1 month
    paths:
      - sbom.json

Ten układ pozwala oddzielić build od skanowania, a jednocześnie zachować proste artefakty (sbom.json) do dalszej analizy.

Jenkins i inne „klasyki”

W Jenkinsie, Bamboo czy TeamCity zasada jest ta sama: osobny stage/step dla SCA i SBOM, najlepiej jako kontener lub pipeline step z gotowego pluginu. Typowy schemat:

• Stage „Build” – buduje aplikację/obraz.
• Stage „SCA fast” – przy PR lub gałęziach feature tylko szybki skan manifestów.
• Stage „SCA full + SBOM” – przy main/release, który:
  • skanuje obraz kodu/kontenera;
  • generuje SBOM i zapisuje jako artefakt.

Dla klasycznych systemów ważne jest dobre cache’owanie (np. workspace, biblioteki narzędzi), bo inaczej każdy run będzie długo pobierał bazy podatności i dependency graphy.

Szybkie alerty: jak nie utonąć w spamie i nie przeoczyć krytyków

Podstawowa selekcja: co w ogóle ma generować powiadomienia

Jeśli każde Medium z każdego projektu ląduje na Slacku lub w mailu, po tygodniu nikt tego nie czyta. Dlatego na start dobrze ustawić bardzo prostą zasadę:

• na Slacka/alert w czasie rzeczywistym – tylko nowe podatności Critical i ewentualnie High w serwisach wystawionych do internetu;
• do raportu okresowego – wszystko od Medium w górę;
• w tle – historyczne Low i Informational, do porządków raz na jakiś czas.

Większość narzędzi SCA/SaaS pozwala ustawić progi alertów, a przy prostych skryptach wystarczy filtr w JSON-ie/raporcie przed wysłaniem notyfikacji.

Integracje z komunikatorami i issue trackerami

Najwygodniejsze miejsce na krótkie powiadomienia to kanał w Slacku/Mattermost/Teams typu #security-alerts. Dobrze, jeśli alert zawiera od razu:

• nazwę projektu/serwisu i gałąź;
• identyfikator CVE i severity;
• zależność (nazwa + wersja);
• link do raportu lub PR-a z fixem, jeśli jest automatycznie generowany.

Druga warstwa to integracja z issue trackerem (Jira, GitHub Issues, YouTrack). Tutaj bardziej sprawdzają się reguły typu:

• twórz ticket tylko dla nowych Critical/High w produkcyjnych serwisach;

Najczęściej zadawane pytania (FAQ)

Po co skanować zależności w CI, skoro mamy testy i code review?

Testy i code review chronią głównie przed błędami w twoim kodzie. Zależności to osobny obszar ryzyka: podatna wersja Log4j, Spring Boot czy OpenSSL może być w projekcie miesiącami, nawet jeśli testy przechodzą na zielono. Ataki na łańcuch dostaw (złośliwe paczki, przejęte konta maintainerów) omijają klasyczne testy i review, bo dzieją się „poza” repozytorium aplikacji.

Skanowanie w CI sprawdza każdą zmianę pod kątem znanych podatności w bibliotekach i obrazach bazowych. Dzięki temu problem wychodzi na etapie builda, a nie dopiero przy incydencie produkcyjnym, awaryjnym oknie serwisowym i weekendowym hotfixie całego zespołu.

Czym różni się SCA od SAST i DAST?

SCA (Software Composition Analysis) analizuje to, z czego zbudowana jest aplikacja: biblioteki, frameworki, kontenery bazowe, moduły. Identyfikuje konkretne wersje komponentów i sprawdza je w bazach podatności (CVE, advisories), podpowiadając aktualizacje lub obejścia.

SAST patrzy w twój kod źródłowy i szuka wzorców błędów (np. SQL injection), a DAST „atakuje” działającą aplikację z zewnątrz. Te narzędzia uzupełniają się: SCA nie wykryje błędu w twojej logice biznesowej, ale bardzo szybko pokaże, że używasz dziurawej biblioteki JWT czy podatnego Springa, zanim ktoś to wykorzysta.

Co to jest SBOM i po co mi SBOM w pipeline CI/CD?

SBOM (Software Bill of Materials) to szczegółowa lista „składników” twojej aplikacji: wszystkie biblioteki, ich wersje, licencje i powiązania. Praktycznie jest to jeden plik (np. w formacie CycloneDX lub SPDX) generowany przy buildzie, który mówi: „ten release składa się z takich dokładnie komponentów”.

SBOM w pipeline CI/CD daje szybkie odpowiedzi przy audytach i zapytaniach klientów („z czego dokładnie zbudowany jest ten system?”) oraz pozwala automatycznym skanerom nocą przeskanować cały stos bez odpalania kolejnych buildów. W wersji „budżetowej” SBOM trzymasz jako artefakt builda w CI lub w prostym storage, bez inwestowania w drogie platformy.

Jakie realne konsekwencje ma brak skanowania zależności?

Brak SCA i SBOM zwykle kończy się kosztownymi akcjami „po fakcie”: awaryjne okna serwisowe, rollbacki w środku dnia, kilka osób z DevOps i security przekopujących logi, żeby zrozumieć, czy było naruszenie danych. Jeśli dojdzie do wycieku, dochodzą obowiązki prawne (RODO, notyfikacja klientów) i szkoda wizerunkowa.

Nawet bez spektakularnego incydentu organizacja płaci w godzinach pracy: weekendowe hotfixy, sprinty wywrócone przez „must fix” na produkcji, nerwowe kompletowanie list bibliotek pod audyt. Automatyczne skanowanie w CI jest tańsze – wymaga jednorazowego wdrożenia i potem działa przy każdym buildzie bez dodatkowego wysiłku zespołu.

Czy wystarczy skanować zależności raz na jakiś czas, zamiast w każdym pipeline?

Okresowe, ręczne skanowanie może jeszcze jakoś działać przy jednym monolicie i rzadkich wydaniach. W typowym środowisku DevOps, z dziesiątkami commitów dziennie i wieloma repozytoriami, co tydzień i tak masz inny zestaw zależności i ich wersji. Paczki aktualizują się non stop, a nowe CVE pojawiają się każdego dnia.

Skanowanie w każdym pipeline automatyzuje to, co ręcznie jest praktycznie niewykonalne. Każda zmiana kodu przechodzi przez ten sam filtr: budowa, testy, SCA. Nie trzeba organizować osobnych „akcji skanowania raz na kwartał”, które i tak zwykle kończą się długą listą zaległych problemów, trudnych do ogarnięcia naraz.

Jak zacząć skanowanie zależności w CI możliwie tanio i prosto?

Pragmatyczny start to:

• użycie darmowego lub tańszego narzędzia SCA (często dostępnego w postaci pluginu do popularnych CI, np. GitLab CI, GitHub Actions, Jenkins);
• koncentracja na kluczowych projektach produkcyjnych zamiast próby „ogarnięcia wszystkiego na raz”;
• proste reguły: blokujemy tylko krytyczne i wysokie podatności w komponentach wystawionych do internetu, resztę raportujemy.

Na początek wystarczy też generowanie jednego SBOM na release i trzymanie go obok builda. Bardziej rozbudowane integracje (centralne dashboardy, automatyczne ticketowanie) można dorzucać później, jeśli faktycznie przyniosą oszczędność czasu i mniej ręcznej pracy.

Jak priorytetyzować podatności CVE wykryte w SCA?

Sama punktacja CVSS (np. 9.8 Critical) to za mało. Liczy się kontekst: czy komponent jest w części wystawionej do internetu, czy działa tylko w wewnętrznej sieci, czy podatny kod jest w ogóle używany. Ten sam CVE może być krytyczny dla API dostępnego publicznie i prawie nieistotny dla małego narzędzia adminów.

Praktyczny i tani proces to:

• ustalenie progu „blokującego build” (np. Critical/High w usługach publicznych);
• nadawanie niższego priorytetu podatnościom w komponentach wewnętrznych, które i tak planujesz wymienić;
• łączenie SCA z prostą klasyfikacją usług (publiczne, pół-publiczne, wewnętrzne), żeby decyzje były szybkie i powtarzalne.