CyberShieldON » DevSecOps w praktyce: Security as Code

W poprzednim artykule z serii "DevSecOps w praktyce" omawialiśmy 90cio dniową strategię wdrożenia, link DevSecOps w praktyce: 90 dni, które decydują o odporności. Po 90 dniach budowania fundamentów - od GitLeaks w repozytorium, przez Trivy w kontenerach, po Falco monitorujący runtime - nadchodzi moment prawdy. Wszystkie te narzędzia muszą zacząć ze sobą rozmawiać, współpracować i działać jako jeden, spójny system. To właśnie jest istota Security as Code.

Czym właściwie jest Security as Code?

Wyobraź sobie, że bezpieczeństwo Twojej organizacji nie zależy już od tego, czy ktoś pamięta o sprawdzeniu konfiguracji, czy inżynier security ma dziś dobry dzień, albo czy procedura została wykonana w prawidłowej kolejności. Security as Code to podejście, w którym każda decyzja i reguła bezpieczeństwa jest zapisana w kodzie i jak przepis kulinarny dokładnie określa składniki i kolejność działań.

Gdy bezpieczeństwo jest zapisane w kodzie, nie można o nim zapomnieć - wykonuje się automatycznie za każdym razem. Można je wersjonować, więc widzisz, kto, kiedy i dlaczego zmienił regułę. Można je testować, zanim trafi do produkcji. I można je powielać - ten sam standard bezpieczeństwa w dziesiątkach lub setkach projektów jednocześnie.

Wartość dla CISO i menedżera IT

Z perspektywy zarządzania ryzykiem to przełom. Tradycyjnie bezpieczeństwo opierało się na check listach, które ktoś może przeoczyć, manualnych kontrolach, które nie skalują się z rozwojem organizacji, oraz założeniu, że ludzie będą pamiętać - co w długiej perspektywie nigdy nie działa.

Security as Code eliminuje te problemy. Gdy masz 50 aplikacji i każda wymaga skanowania pod kątem podatności przed wdrożeniem, nie potrzebujesz 50 osób sprawdzających to ręcznie. Potrzebujesz jednej, dobrze napisanej reguły, która wykona to automatycznie - za każdym razem, bez wyjątków.

Od pojedynczych narzędzi do orkiestry

GitLeaks sprawdza sekrety, Trivy skanuje kontenery, Falco monitoruje runtime. Prawdziwa siła pojawia się dopiero wtedy, gdy te narzędzia działają w jednym, zsynchronizowanym pipeline’ie CI/CD (Continuous Integration/Continuous Deployment - ciągła integracja/ciągłe dostarczanie). Developer zapisuje kod, GitLeaks blokuje commit z hasłem. Kod trafia do pipeline’u, gdzie SAST (Static Application Security Testing - statyczne testowanie bezpieczeństwa) skanuje kod źródłowy. Budowany jest kontener, który Trivy sprawdza pod kątem podatnych bibliotek. Przed wdrożeniem polityki Infrastructure as Code weryfikują konfigurację. W produkcji Falco monitoruje, czy nic podejrzanego się nie dzieje.

Każdy krok jest zautomatyzowany, każdy ma jasne kryteria pass/fail. I co najważniejsze – inżynierowie ds. bezpieczeństwa nie muszą ręcznie weryfikować każdego z releasów.

Security as Code brzmi świetnie w teorii. Ale w dużej organizacji, gdzie każdy zespół ma swoje narzędzia, procesy i swoje „tak zawsze robiliśmy” - wdrożenie jednolitego pipeline’u to wyzwanie.

Centralizacja procesów - wyzwanie dużych organizacji

W organizacji z wieloma zespołami deweloperskimi każdy ma swoje ulubione narzędzia. Jeden zespół używa SonarQube do analizy kodu, inny Checkmarx, jeszcze inny ręcznie przegląda kod przed wdrożeniem. Jeden skanuje kontenery narzędziem komercyjnym, inny używa darmowego Trivy, a trzeci w ogóle tego nie robi. Każdy zespół ma własną definicję tego, co oznacza „bezpieczny kod”, własny backlog błędów bezpieczeństwa i własne priorytety.

Na pierwszy rzut oka wygląda to jak elastyczność i autonomia. W praktyce jednak to chaos, który kosztuje organizację fortunę. Koszty rozproszonego środowiska są ukryte, ale bardzo realne. Zespół bezpieczeństwa musi nauczyć się obsługi pięciu różnych narzędzi do skanowania i konsolidować raporty z dziesięciu różnych źródeł. Specjalista ds. zgodności nie ma pewności, czy wszystkie zespoły rzeczywiście skanują kod, bo każdy raportuje w innym formacie. A CISO nie wie, gdzie jest prawdziwe ryzyko, bo porównywanie „jabłek do gruszek” między zespołami jest niemożliwe.

Zunifikowane środowisko zmienia zasady gry. Jedna platforma bezpieczeństwa, jeden format raportów, jeden standard tego, co musi być spełnione przed wdrożeniem, ale dotarcie do tego punktu wcale nie jest proste.

Automatyzacja przyspiesza, nie spowalnia

Automatyzacja bezpieczeństwa spowalnia jedynie w pierwszych tygodniach. Organizacja uczy się nowych narzędzi, dostrajania reguł, budowania współpracy między Dev i Sec. Warto jednak pamiętać, że jest to inwestycja, która zwraca się z nawiązką. Automatyzacja nie spowalnia rozwoju - eliminuje chaos, który wcześniej ukrywał problemy i zmuszał do przepychania ich na ostatnią chwilę.

Zunifikowany pipeline to nie tylko kwestia technologii. To zmiana, która wymaga zaangażowania zarówno zespołów deweloperskich, jak i bezpieczeństwa. Organizacje, które przeszły przez ten proces nie wracają już do starego świata manualnych kontroli i rozproszonego chaosu.

Pipeline CI/CD krok po kroku

Najlepszy sposób na zrozumienie, jak działa Security as Code w praktyce, to przeanalizowanie konkretnego przykładu. Wyobraź sobie dewelopera w zespole e-commerce, który właśnie naprawił błąd w module płatności. Zapisuje zmiany w kodzie i uruchamia standardową procedurę wdrożenia. To, co dzieje się w następnych minutach, to orkiestra zautomatyzowanych kontroli bezpieczeństwa, które działają bez ludzkiej interwencji.

Pierwsza linia obrony: Lokalna maszyna dewelopera

Zanim kod w ogóle opuści komputer dewelopera, uruchamia się GitLeaks skonfigurowany jako pre-commit hook. Narzędzie skanuje każdą linijkę w poszukiwaniu haseł, kluczy API, tokenów dostępowych czy certyfikatów. Jeśli znajdzie coś podejrzanego, blokuje zapisanie zmian natychmiast. Deweloper dostaje komunikat błędu, zanim zdąży wrzucić kod do wspólnego repozytorium. To pierwsza bramka bezpieczeństwa - działa jeszcze zanim kod trafi do zespołu.

Druga linia: Repozytorium kodu

Kod trafia do GitLaba lub GitHuba, gdzie automatycznie uruchamia się pipeline CI/CD. Pierwszy krok to SAST (Static Application Security Testing - statyczne testowanie bezpieczeństwa aplikacji). Narzędzie analizuje kod źródłowy bez jego uruchamiania, szukając typowych błędów bezpieczeństwa, jak SQL injection czy cross-site scripting. W ciągu kilku minut dostajemy raport czy kod jest bezpieczny, czy wymaga poprawek.

Równolegle uruchamia się dependency scanning. To narzędzie sprawdza wszystkie biblioteki zewnętrzne, z których korzysta aplikacja. Sprawdza bazę znanych podatności CVE i odpowiada na pytanie: czy któraś z tych bibliotek ma krytyczną lukę bezpieczeństwa? Jeśli tak, build zostaje zatrzymany.

Trzecia linia: Budowanie i pakowanie

Aplikacja zostaje spakowana do kontenera Docker. Zanim trafi on dalej, skanuje go Trivy. Narzędzie analizuje system operacyjny wewnątrz kontenera, wszystkie zainstalowane pakiety i warstwy obrazu. Sprawdza, czy nie używamy przestarzałej wersji Alpine Linux z krytycznymi podatnościami, czy wszystkie zależności są aktualne, czy nie ma znanych exploitów.

Równocześnie uruchamiają się testy Infrastructure as Code. Narzędzia jak Checkov lub tfsec sprawdzają konfigurację chmurową, która będzie użyta do wdrożenia. Czy bucket S3 jest publiczny przez pomyłkę? Czy szyfrowanie dysków jest włączone? Czy firewall pozwala na dostęp tylko z określonych adresów IP? Te reguły są zapisane jako kod i wykonują się automatycznie.

Czwarta linia: Decyzja o wdrożeniu

Wszystkie kontrole zakończyły się sukcesem. Każda bramka bezpieczeństwa świeci na zielono. Dopiero teraz pipeline daje sygnał: można wdrażać do produkcji. Ostateczną decyzję podejmuje człowiek - świadomie, w oparciu o wyniki testów i pełny obraz sytuacji.

Co dzieje się, gdy coś się nie powiedzie?

Jeśli którykolwiek z kroków wykryje problem, build zatrzymuje się natychmiast. Deweloper dostaje szczegółowy raport: co jest nie tak, w której linijce kodu, jakie jest ryzyko i jak to naprawić. Nie musi czekać tygodnia na feedback od security teamu. Dostaje go w kilka minut, może poprawić i spróbować ponownie.

W tradycyjnym podejściu te wszystkie kontrole wymagałyby dni pracy security engineer’ów. W Security as Code wykonują się automatycznie w kilkanaście minut. Security team nie jest już wąskim gardłem, bo zajmuje się tylko wyjątkami i bardziej złożonymi analizami. Rutynowe sprawdzenia robi za nich pipeline.

To jest praktyczna realizacja filozofii „shift-left security” - przenosimy bezpieczeństwo na sam początek procesu, zamiast odkrywać problemy na końcu. I to jest różnica między organizacją, która reaguje na incydenty, a organizacją, która im zapobiega.

Podsumowanie

Pipeline to tylko początek historii. Prawdziwa przewaga pojawia się, gdy wszystkie te dane trafiają do jednego miejsca, gdzie można je analizować i priorytetyzować. W ten sposób przechodzimy od reaktywnego monitoringu do strategicznego zarządzania bezpieczeństwem.

W kolejnym artykule pokażę, jak zbudować centralną konsolę bezpieczeństwa, która łączy dane z wielu źródeł w jeden spójny obraz. Zobaczysz, jak dzięki niej zespół bezpieczeństwa przestaje walczyć z raportami, a zaczyna realnie wspierać rozwój biznesu.

Jakub Wasiljew
Solution Architect| 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