DevSecOps w praktyce: 90 dni, które decydują o odporności

W poprzednim artykule z serii “DevSecOps w praktyce” [link] prezentowałem, jak wdrożyć Security by Design. Dziś chcę przejść do kolejnego etapu – wdrażania poszczególnych warstw. Uważam, że DevSecOps nie polega na implementacji pojedynczych narzędzi, lecz na budowaniu spójnej strategii – od fundamentów kodu, przez automatyzację procesów, aż po monitoring i ochronę w czasie rzeczywistym.

DevSecOps działa jak budowa nowoczesnego wieżowca - bezpieczeństwo musi być zaprojektowane od fundamentów, wbudowane w konstrukcję nośną i zintegrowane z każdym systemem budynku. Nie można go dodać później jako „dodatkowe zabezpieczenie”, tak jak nie można budować na słabych fundamentach i liczyć na stabilność całej konstrukcji. Ale jak to wygląda w praktyce, gdy jako CISO czy menedżer IT zaczynasz pierwszy dzień strategicznego wdrożenia w swojej organizacji?

W obliczu wymagań NIS2 (Network and Information Systems Directive 2 – dyrektywy UE o bezpieczeństwie systemów sieciowych i informacyjnych) oraz DORA (Digital Operational Resilience Act – rozporządzenia o cyfrowej odporności operacyjnej), które obowiązuje od 17 stycznia 2025, wdrożenie DevSecOps staje się koniecznością biznesową. To nie jest już kwestia „czy”, ale „jak szybko i efektywnie” można zbudować bezpieczną infrastrukturę cyfrową.

Opierając się na swoim doświadczeniu, pokażę, jak - od fundamentów kodu po monitoring w czasie rzeczywistym - stworzyć spójną strategię DevSecOps, która nie tylko spełnia regulacje, ale realnie zwiększa odporność organizacji.

Strategia 90-dniowego wdrożeniaDevSecOps - Od czego zacząć?

Dni 1-30: Fundamenty - kod i repozytorium jako kamień węgielny

Zaczynasz od najgłębszych fundamentów - kodu źródłowego i repozytoriów, bo to tutaj rodzą się wszystkie podatności, które później mogą zagrozić całej organizacji. Pre-commit hooks z narzędziem GitLeaks automatycznie skanują każdy commit w poszukiwaniu sekretów, haseł, kluczy API czy certyfikatów których obecność stwarzałaby zagrożenie bezpieczeństwa. Podpisy commitów umożliwiają weryfikację autora kodu, a zasady ochrony gałęzi nie pozwalają na bezpośrednie zmiany w głównym kodzie bez przeglądu.

Nowoczesne narzędzia statycznej analizy kodu, według deklaracji vendorów i testów porównawczych, osiągają znacznie niższą liczbę fałszywych alarmów niż starsze rozwiązania. Podczas gdy legacy tools generowały od 50 do 80 procent nieprawdziwych alertów, współczesne platformy w kontrolowanych testach pokazują rezultaty od 1 do 5 procent fałszywych pozytywów. Jednak niezależne badania wskazują, że w rzeczywistych środowiskach produkcyjnych wskaźniki mogą być wyższe ze względu na złożoność kodu aplikacji.

Praktyczne narzędzia jak Checkov czy tfsec automatyzują kontrolę Infrastructure as Code (IaC), sprawdzając czy konfiguracje chmurowe są bezpieczne już na etapie projektowania. To jak kontrola planów architektonicznych przed rozpoczęciem budowy - znacznie tańsze niż późniejsze przebudowy.

Już na tym etapie warto pamiętać, że narzędzia nie zastąpią ludzi. Kluczowe jest budowanie odpowiedzialności po stronie deweloperów i włączanie zasad bezpieczeństwa w codzienny proces pracy zespołu.

Dni 31-60: Konstrukcja nośna - automatyzacja build i deploy

Następny etap to konstrukcja nośna całego systemu. Container scanning z narzędziem Trivy sprawdza, czy w obrazach aplikacji nie ma znanych podatności. Skanowanie zajmuje zwykle mniej niż dwie minuty i wykrywa problemy w systemie operacyjnym, bibliotekach aplikacji i plikach konfiguracyjnych.

Kubernetes security z narzędziami typu OPA Gatekeeper wymusza polityki bezpieczeństwa w sposób automatyczny. Na przykład może zabronić uruchamiania kontenerów z prawami administratora lub wymusić użycie tylko zaufanych repozytoriów obrazów. To jak automatyczne systemy kontroli budynku, które nie pozwalają na użycie materiałów niespełniających norm bezpieczeństwa.

Software Bill of Materials (SBOM) automatycznie generuje listę wszystkich komponentów aplikacji. Ten „spis wyposażenia" będzie kluczowy przy przyszłych incydentach bezpieczeństwa i staje się wymogiem regulacyjnym zgodnie z EU Cyber Resilience Act, którego główne postanowienia będą miały zastosowanie od grudnia 2027 roku. SBOM pozwala na szybkie identyfikowanie, czy nasza aplikacja używa podatnych komponentów, podobnie jak spis wszystkich materiałów budowlanych pozwala szybko zidentyfikować problematyczne partie.

Nie każda organizacja musi wdrożyć wszystkie narzędzia naraz - ważne jest priorytetyzowanie ryzyka i dostosowanie kolejności działań do własnego kontekstu biznesowego.

Dni 61-90: Systemy bezpieczeństwa – monitoring w czasie rzeczywistym

Wdrażanie DevSecOps na tym etapie wymaga rozszerzenia działań także na mechanizmy ciągłego monitoringu. Automatyzacja security scanning stała się standardem branżowym - bez niej niemożliwe byłoby przeanalizowanie tak dużej ilości kodu i infrastruktury w sposób ekonomicznie uzasadniony.

Największa grupa ubezpieczeniowa w Polsce wykryła w 2023 roku prawie 296 tysięcy podatności. Właśnie dzięki automatyzacji firma ta może osiągać taki wynik i przeprowadzać ponad 104 tysiące analiz bezpieczeństwa rocznie.

Kolejnym krokiem jest wprowadzenie runtime security. Jest to ochrona aplikacji i systemów podczas ich działania, funkcjonująca podobnie jak systemy alarmowe budynku, które monitorują teren 24 godziny na dobę. Na rynku dostępne są różne rozwiązania, m.in. Falco dla Kubernetes monitorują w czasie rzeczywistym podejrzane działania zachodzące wewnątrz systemu operacyjnego, kontenerów i aplikacji. Najnowsza wersja Falco z 2024 roku wprowadza dodatkowo wsparcie dla eBPF (extended Berkeley Packet Filter), co zwiększa wydajność monitorowania do 30 procent przy jednoczesnym zmniejszeniu obciążenia systemów.

Kolejnym istotnym elementem są Endpoint Detection and Response oraz ochrona środowisk chmurowych, które wspierają instytucje w spełnianiu wymogów regulacyjnych i branżowych standardów. Coraz częściej stosuje się zintegrowane podejście, takie jak Cloud Native Application Protection Platform, które łączy runtime protection, zarządzanie konfiguracją i wykrywanie zagrożeń.

Podsumowanie

Połączenie fundamentów, konstrukcji nośnej i systemów monitorujących tworzy kompletną strategię DevSecOps - obejmującą zarówno prewencję, jak i bieżące reagowanie. Tylko wtedy nasz „cyfrowy wieżowiec” ma solidne fundamenty, stabilną konstrukcję i sprawne systemy alarmowe, które działają non stop.

To dopiero druga część serii DevSecOps w praktyce – w kolejnych artykułach przyjrzymy się automatyzacji i pipeline’om (bezpieczeństwo jako kod), ludziom i procesom jako fundamentom DevSecOps oraz metrykom, ROI i trendom na lata 2024 - 2025.

Dla dociekliwych:

1. Static Application Security Testing (SAST) Scanning, https://snyk.io/articles/application-security/static-application-security-testing/,
2. Why Static Code Analysis Doesn’t Belong Into Your CI, https://www.code-intelligence.com/blog/why-static-code-analysis-doesnt-belong-into-your-ci

Jakub Wasilijew
Senior Frontend Developer | Ambasador CyberOdporności
CyberShieldON

CyberShieldON – Gdy wiedza spotyka decyzję.
Tutaj cyberbezpieczeństwo to nie tylko technologia, ale też konsekwencje wyborów, ryzyko systemowe i odpowiedzialność.
Łączymy doświadczenie z projektów z refleksją nad tym, jak naprawdę działa organizacja i jak ją chronić. Dzielimy się praktyką, która wytrzymała presję, oraz pytaniami, które zmieniły kierunek działania.

To miejsce jest dla Ciebie, jeśli tworzysz systemy, zarządzasz bezpieczeństwem, projektujesz architekturę i nie zatrzymujesz się na poziomie technologicznym.

Nowe artykuły – regularnie na cybershieldon.pl

Strona www stworzona w kreatorze WebWave.