DevSecOps: jak wbudować bezpieczeństwo w CI/CD

Model, w którym bezpieczeństwo wkracza na sam koniec — tuż przed wdrożeniem, w formie audytu, który albo blokuje release, albo jest ignorowany — nie działa. Jest za drogi, za wolny i skłóca zespoły. DevSecOps to prosta idea: przesunąć bezpieczeństwo w lewo, wpleść je w codzienny potok wytwarzania oprogramowania tak, by luki wyłapywać automatycznie i wcześnie, gdy poprawka kosztuje minuty. Poniżej praktyczny obraz, jak to zrobić na poziomie CI/CD.

Zasada: security jako część potoku, nie brama na końcu

Kluczowa zmiana myślowa: bezpieczeństwo nie jest osobnym etapem, przez który „trzeba przejść”, lecz zestawem automatycznych kontroli wplecionych w cały cykl — od commita, przez build, po wdrożenie. Deweloper dostaje informację o problemie tam, gdzie pracuje (w pull requeście), a nie tydzień po wdrożeniu, w mailu od audytora.

Dobrze zaprojektowany potok DevSecOps ma kilka warstw kontroli, każda tania i szybka, uruchamiana na właściwym etapie. Przejdźmy przez nie.

SCA: podatności w zależnościach

Zdecydowana większość kodu w typowej aplikacji to nie Twój kod, lecz zależności — biblioteki open source i ich zależności tranzytywne. To najczęstsze wejście dla atakującego, co pokazujemy w artykule o atakach na łańcuch dostaw oprogramowania.

Software Composition Analysis (SCA) skanuje manifesty zależności (package.json, requirements.txt, pom.xml) i porównuje wersje z bazami znanych podatności. Praktyka:

Uruchamiaj SCA na każdy pull request i cyklicznie na głównej gałęzi (nowe CVE pojawiają się dla kodu, który się nie zmienił).
Generuj SBOM (Software Bill of Materials) — spis komponentów, bez którego nie odpowiesz szybko na pytanie „czy używamy podatnej wersji X?”.
Ustaw progi: krytyczne podatności blokują merge, niższe trafiają do backlogu. Bez progów zespół utonie w alertach.

Skan sekretów: klucze nie należą do repozytorium

Zahardkodowany token API, hasło do bazy czy klucz prywatny w historii Gita to jeden z najczęstszych i najgroźniejszych błędów — raz wypchnięty sekret trzeba uznać za skompromitowany, nawet po usunięciu, bo historia repozytorium pamięta.

Wpleć skan sekretów w dwóch miejscach:

Pre-commit hook — blokuje sekret, zanim w ogóle trafi do repozytorium (najtańszy moment).
Pipeline CI — siatka bezpieczeństwa, gdyby ktoś pominął hook, plus skan całej historii przy wdrożeniu.

Sekrety powinny żyć w dedykowanym menedżerze (vault) i być wstrzykiwane w czasie działania, nie zapisywane w kodzie ani w zmiennych widocznych w logach.

SAST: analiza własnego kodu

Static Application Security Testing (SAST) analizuje kod źródłowy pod kątem wzorców podatności: wstrzyknięć SQL, XSS, niebezpiecznej deserializacji, błędów kryptografii. Działa bez uruchamiania aplikacji, więc pasuje do wczesnych etapów potoku.

SAST bywa hałaśliwy — generuje fałszywe alarmy. Żeby nie zniechęcić zespołu:

Zacznij od reguł o wysokiej pewności, stopniowo rozszerzaj.
Kalibruj — oznaczaj false positive, by narzędzie się uczyło.
Integruj wyniki w pull requeście, nie w osobnym dashboardzie, do którego nikt nie zagląda.

DAST: test działającej aplikacji

Dynamic Application Security Testing (DAST) testuje uruchomioną aplikację z zewnątrz, tak jak robiłby to atakujący — wysyła żądania i obserwuje odpowiedzi. Wychwytuje to, czego SAST nie widzi: błędy konfiguracji środowiska, problemy uwierzytelniania, brakujące nagłówki bezpieczeństwa.

DAST jest wolniejszy, więc zwykle uruchamia się go nie na każdy commit, lecz na środowisku staging — w nocnym buildzie albo przed wdrożeniem. Lekką, pasywną wersję takiej kontroli można zresztą zautomatyzować nawet naszym skanerem konfiguracji, spinając go z pipeline’em jako szybki test dymny nagłówków, HTTPS i ekspozycji.

Bezpieczeństwo obrazów i infrastruktury jako kodu

Jeśli wdrażasz kontenery, dochodzą dwie warstwy:

Skan obrazów — obraz bazowy niesie własne zależności i podatności. Skanuj obrazy w rejestrze i buduj na minimalnych bazach (distroless, alpine), by zmniejszyć powierzchnię ataku. Więcej o utwardzaniu w bezpieczeństwie Kubernetes i kontenerów.
IaC scanning — Terraform, Helm czy manifesty Kubernetes to też kod, który może zawierać błędy: publiczny bucket, zbyt szerokie uprawnienia IAM, brak szyfrowania. Skanuj konfigurację infrastruktury tak samo jak kod aplikacji.

Utwardź sam pipeline

Łatwo zapomnieć, że potok CI/CD sam jest celem — ma dostęp do kodu, sekretów i środowisk produkcyjnych. Przejęcie pipeline’u to często prostsza droga do produkcji niż atak na samą aplikację. Podstawy:

Zasada minimalnych uprawnień dla runnerów i tokenów — osobne, wąsko zakresowane poświadczenia zamiast jednego wszechmocnego klucza.
Przypinanie wersji akcji/pluginów (pinning do konkretnego commita), by aktualizacja u dostawcy nie wstrzyknęła złośliwego kodu.
Ochrona głównych gałęzi: wymagane przeglądy, podpisywanie commitów, zakaz pushowania bez review.
Izolacja środowisk — build nie powinien mieć dostępu do produkcyjnych sekretów, jeśli ich nie potrzebuje.

Klucz do sukcesu: nie zabić tempa

Największym zagrożeniem dla DevSecOps nie jest technika, lecz frustracja zespołu. Jeśli każdy commit blokuje setka alertów o niskim priorytecie, deweloperzy nauczą się je ignorować albo obchodzić kontrole. Dlatego:

Kalibruj progi — blokuj tylko to, co naprawdę krytyczne; resztę raportuj bez blokowania.
Dawaj kontekst, nie tylko alert — dobra integracja pokazuje, gdzie jest problem i jak go naprawić.
Wprowadzaj warstwy stopniowo — najpierw skan sekretów i SCA (wysoka wartość, niski szum), potem SAST, na końcu DAST i IaC.
Mierz i pokazuj efekt — spadek liczby podatności trafiających na produkcję to najlepszy argument za utrzymaniem procesu.

Podsumowanie

DevSecOps to nie zakup narzędzia, lecz przesunięcie bezpieczeństwa w lewo i wplecenie automatycznych, tanich kontroli w cały cykl wytwarzania. Rozsądna kolejność wdrażania: skan sekretów i SCA, potem SAST, następnie skan obrazów/IaC, na końcu DAST — z progami dobranymi tak, by chronić tempo zespołu. Automatyzacja wyłapuje to, co powtarzalne; na trudne, kontekstowe podatności wciąż potrzebny jest człowiek.

Jeśli chcecie zaprojektować bezpieczny potok CI/CD albo zweryfikować istniejący pod kątem realnych zagrożeń, odezwijcie się. Wspieramy zespoły deweloperskie w ramach konsultacji i doradztwa bezpieczeństwa.

Najczęstsze pytania (FAQ)

Od czego zacząć wdrażanie DevSecOps, jeśli nie mamy nic? Od dwóch rzeczy o najlepszym stosunku wartości do wysiłku: skanu sekretów (pre-commit + pipeline) oraz SCA na zależnościach. Dają dużą redukcję ryzyka przy minimalnym szumie i nie wymagają zmiany sposobu pracy zespołu. Kolejne warstwy dokładaj dopiero, gdy te dwie działają płynnie.

Czy DevSecOps zastępuje testy penetracyjne? Nie. Automatyczne kontrole w CI/CD wyłapują to, co powtarzalne i znane — podatne zależności, wzorce w kodzie, błędy konfiguracji. Nie zrozumieją logiki biznesowej ani nie połączą kilku drobnych błędów w łańcuch ataku. To wciąż zadanie dla manualnego pentestu, który uzupełnia, a nie zastępuje, automatyzację.

Czy skanery bezpieczeństwa w pipeline nie spowolnią wdrożeń? Przy dobrej konfiguracji nie. Szybkie kontrole (sekrety, SCA, lekki SAST) uruchamia się na każdy commit, a wolniejsze (pełny DAST, głęboki skan obrazów) na środowisku staging lub w nocnych buildach. Kluczem jest dobranie progów blokujących wyłącznie do rzeczy naprawdę krytycznych.

Co to jest SBOM i czy naprawdę go potrzebujemy? SBOM to spis wszystkich komponentów oprogramowania wraz z wersjami. Jego wartość widać w kryzysie: gdy wychodzi krytyczne CVE w popularnej bibliotece, z SBOM w minutę sprawdzisz, czy i gdzie jej używasz. Bez niego to godziny ręcznego przeszukiwania. Coraz częściej wymagają go też kontrahenci i regulacje.