Bezpieczeństwo weryfikowane raz w roku przed audytem to za mało. Każdy commit powinien być automatycznie sprawdzany pod kątem podatności i sekretów.
Klasyczny schemat wygląda tak: developerzy piszą kod, code review skupia się na logice biznesowej, na bezpieczeństwo patrzy się przed release'em albo przed audytem ISO. W tym czasie luki istnieją w kodzie produkcyjnym tygodniami lub miesiącami. DevSecOps przesuwa tę kontrolę w lewo - do momentu, gdy zmiana jest jeszcze w gałęzi deweloperskiej, przed merge'em.
Co GitLab daje out-of-the-box
GitLab ma wbudowane narzędzia bezpieczeństwa dostępne jako szablony CI/CD. Wystarczy kilka linii w .gitlab-ci.yml. Uwaga na tiery: SAST i Secret Detection działają na wszystkich planach GitLab (w tym bezpłatnym). Dependency Scanning, Container Scanning i Security Dashboard wymagają planu GitLab Ultimate.
include:
- template: Security/SAST.gitlab-ci.yml
- template: Security/Secret-Detection.gitlab-ci.yml
- template: Security/Dependency-Scanning.gitlab-ci.yml
- template: Security/Container-Scanning.gitlab-ci.yml- SAST - analizuje kod źródłowy w poszukiwaniu znanych wzorców podatności
- Secret Detection - szuka przypadkowo commitowanych sekretów: kluczy AWS, tokenów API
- Dependency Scanning - sprawdza zależności (npm, pip, Maven) pod kątem znanych CVE (wymaga GitLab Ultimate)
- Container Scanning - skanuje obrazy Docker (wymaga GitLab Ultimate)
Security jako brama do merge'a
Wyniki skanowania bezpieczeństwa powinny blokować merge request z tym samym statusem co nieudane testy jednostkowe. Jeśli SAST znajdzie podatność krytyczną - merge nie przechodzi.
# Blokuj merge jeśli SAST znajdzie high/critical
sast:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
allow_failure: falseZewnętrzne narzędzia - i dlaczego NIGDY nie używaj "latest"
- Hadolint (GPL-3.0, open source) - linter dla Dockerfile
- Semgrep (CLI LGPL-2.1, reguły Apache 2.0, open source) - SAST z tysiącami gotowych reguł
- Trivy (Apache 2.0, open source, Aqua Security) - skaner podatności dla kontenerów, systemów plików i IaC
- Snyk (freemium/komercyjny) - wymaga konta Snyk i tokenu API. Nie jest w pełni open source
hadolint:
stage: test
image: hadolint/hadolint:v2.12.0 # pinuj wersję!
script:
- hadolint Dockerfile
semgrep:
stage: test
image: semgrep/semgrep:1.77.0 # nie :latest
script:
- semgrep scan --config=auto --error .
trivy-scan:
stage: test
image: aquasec/trivy:0.69.3 # patrz: atak z marca 2026
script:
- trivy image --exit-code 1 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHADlaczego nie używać :latest - lekcja z marca 2026: 19 marca 2026 roku atakujący (grupa TeamPCP) przejęli dostęp do infrastruktury Trivy i opublikowali złośliwą wersję v0.69.4 - zarówno jako konkretny tag, jak i jako obraz :latest. Każdy pipeline odwołujący się do :latest zaczął uruchamiać złośliwy kod zbierający poświadczenia AWS, klucze SSH i tokeny Kubernetes. Okno ekspozycji wynosiło ~12 godzin. CVE-2026-33634, krytyczny. Szczegóły: advisory Aqua Security.
Zasada: pinuj obrazy do konkretnego tagu wersji. Dla najwyższego bezpieczeństwa używaj digests SHA256: aquasec/trivy@sha256:... - to jest prawdziwie niezmienne.
OIDC i bezpieczeństwo deploymentu
Zamiast statycznych kluczy AWS IAM jako zmiennych CI/CD - użyj OIDC. Pipeline dostaje tymczasowe poświadczenia ważne tylko przez czas trwania jobu, bez żadnych stałych sekretów.
deploy:
id_tokens:
AWS_ID_TOKEN:
aud: https://gitlab.com
before_script:
- CREDS=$(aws sts assume-role-with-web-identity \
--role-arn "$AWS_ROLE_ARN" \
--web-identity-token "$AWS_ID_TOKEN")Pomożemy skonfigurować GitLab Security od podstaw lub przeprowadzić audyt istniejącej konfiguracji.