DevSecOps (Development, Security and Operations) to rozszerzenie filozofii DevOps, w którym bezpieczeństwo przestaje być oddzielnym etapem na końcu projektu, a staje się odpowiedzialnością całego zespołu i wbudowuje się w każdy krok cyklu życia oprogramowania. Zamiast pukać do drzwi działu security tydzień przed wdrożeniem i błagać o „audyt”, testujesz bezpieczeństwo automatycznie przy każdym commicie. Hasło, które krąży w tym świecie, to shift left — przesuwasz kontrole bezpieczeństwa „w lewo”, czyli wcześniej w pipelinie, gdy poprawka kosztuje minuty zamiast tygodni i paniki na produkcji.
Jak to działa
W praktyce DevSecOps oznacza wpięcie narzędzi bezpieczeństwa w ten sam pipeline CI/CD, którym i tak budujesz i wdrażasz kod. Każdy push uruchamia zestaw automatycznych skanów: SAST (analiza kodu źródłowego), SCA (sprawdzanie podatności w zależnościach i bibliotekach open source), skan obrazów kontenerów, wykrywanie sekretów wrzuconych przypadkiem do repo oraz DAST (testowanie działającej aplikacji). Jeśli skaner znajdzie krytyczną podatność, build się wywala — tak samo jak przy nieudanym teście jednostkowym.
Sens jest prosty: podatność znaleziona w IDE albo na etapie pull requesta jest tania i nudna do naprawienia. Ta sama podatność znaleziona po wycieku danych jest droga, głośna i kończy się rozmową z prawnikami. DevSecOps to też kultura — deweloper, ops i security grają do jednej bramki, a nie wskazują na siebie palcami po incydencie.
Przykład z praktyki
Powiedzmy, że masz pipeline w GitHub Actions. Dorzucasz krok, który skanuje zależności i obraz kontenera narzędziem Trivy:
trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:latest
Flaga --exit-code 1 sprawia, że przy znalezieniu podatności HIGH lub CRITICAL komenda zwraca błąd i cały build pada. Podatna wersja log4j w zależnościach? Pipeline nie przepuści jej na produkcję. Do skanu kodu dorzucisz Semgrep albo SonarQube, a do wykrywania sekretów gitleaks, żeby nikt nie zacommitował klucza AWS w pliku .env.
Częste błędy i mity
Największy błąd to zalanie zespołu alertami. Jeśli skaner zgłasza 800 „krytycznych” podatności, z których połowa to false positive, deweloperzy szybko nauczą się to ignorować — i wtedy DevSecOps jest tylko teatrem. Trzeba stroić progi i priorytety.
Mit numer dwa: „kupimy narzędzie i mamy DevSecOps”. Nie. Bez zmiany nawyków i odpowiedzialności to zostanie kolejnym zielonym ptaszkiem w dashboardzie. I nie myl tego z security theater — chodzi o realne wykrywanie ryzyka, a nie o checkbox dla audytora.
Pojęcia powiązane
Warto znać: DevOps, CI/CD, shift left, SAST, DAST, SCA, IaC scanning (np. Terraform), zarządzanie sekretami, principle of least privilege oraz supply chain security.