Bezpieczeństwo Pipeline DevOps w 2026: SAST, DAST, Supply Chain i Pytania Rekrutacyjne

Bezpieczeństwo pipeline DevOps wymaga osadzenia kontroli bezpieczeństwa na każdym etapie przepływu CI/CD, od hooków pre-commit po monitoring produkcyjny. Raport Datadog State of DevSecOps 2026 ujawnia, że 87% organizacji uruchamia usługi z co najmniej jedną znaną podatnością możliwą do wykorzystania, podczas gdy ataki na łańcuch dostaw oprogramowania kosztują globalną gospodarkę ponad 80 miliardów dolarów rocznie.

SAST: Analiza Statyczna Wykrywająca Podatności Przed Merge

Static Application Security Testing (SAST) analizuje kod źródłowy bez jego wykonywania. Narzędzie parsuje bazę kodu, buduje abstrakcyjne drzewo składniowe i dopasowuje wzorce do znanych sygnatur podatności. Uruchamianie SAST na każdym pull request wychwytuje SQL injection, XSS i zakodowane na stałe dane uwierzytelniające zanim kod trafi do głównej gałęzi.

Semgrep stał się de facto standardem open-source SAST w 2026 roku. W przeciwieństwie do skanerów opartych na wyrażeniach regularnych, Semgrep rozumie strukturę kodu i wspiera niestandardowe reguły w YAML.

# .github/workflows/sast.yml
name: SAST Scan

on:
  pull_request:
    branches: [main, develop]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep:latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Semgrep
        run: semgrep scan --config=auto --sarif --output=semgrep.sarif
        
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

Flaga --config=auto ładuje reguły społecznościowe odpowiadające wykrytym językom. Wyjście SARIF integruje się z zakładką GitHub Security do śledzenia znalezisk w czasie.

DAST: Testowanie Runtime Wykrywające To, Co Omija Analiza Statyczna

Dynamic Application Security Testing (DAST) atakuje działającą aplikację w celu znalezienia podatności, które ujawniają się tylko w czasie wykonania. Złamane uwierzytelnianie, błędy autoryzacji i luki w logice biznesowej wymagają rzeczywistych żądań HTTP do wykrycia. SAST nie znajdzie tego, że endpoint administracyjny nie ma odpowiedniej kontroli dostępu, ale DAST spróbuje uzyskać do niego dostęp bez poświadczeń i oznaczy ekspozycję.

OWASP ZAP pozostaje najszerzej wdrażanym narzędziem DAST typu open-source. ZAP 3.0, wydany na początku 2026 roku, dodał natywne wsparcie dla skanowania GraphQL i gRPC.

# .github/workflows/dast.yml
name: DAST Scan

on:
  deployment:
    types: [created]

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Full Scan
        uses: zaproxy/action-full-scan@v0.12.0
        with:
          target: ${{ secrets.STAGING_URL }}
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a -j -l WARN -z "-config api.disablekey=true"'
          
      - name: Upload Report
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report_html.html

DAST uruchamia się po wdrożeniu, ponieważ potrzebuje działającego celu. Środowisko stagingowe służy jako powierzchnia testowa, izolując produkcję od ruchu skanującego.

SCA: Skanowanie Zależności pod Kątem Znanych Podatności

Software Composition Analysis (SCA) skanuje zależności względem baz danych podatności takich jak National Vulnerability Database i GitHub Advisory Database. Pojedyncza podatna zależność przechodnia może eksponować całą aplikację. Raport Datadog 2026 wykazał, że 42% usług zależy od bibliotek, które nie są już aktywnie utrzymywane.

Trivy skanuje kontenery, systemy plików i repozytoria git w poszukiwaniu podatności w jednym binarnym pliku. Generuje wyjście SBOM w formatach CycloneDX i SPDX.

# .github/workflows/sca.yml
name: Dependency Scan

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * *'  # Codziennie o 6:00

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@0.28.0
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          
      - name: Upload Trivy scan results
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'trivy-results.sarif'

Zaplanowane codzienne skanowanie wychwytuje nowo ujawnione CVE nawet bez zmian w kodzie. Filtrowanie do CRITICAL i HIGH zapobiega zmęczeniu alarmami od znalezisk niskiego ryzyka.

Bezpieczeństwo Łańcucha Dostaw: SBOM i SLSA Provenance

EU Cyber Resilience Act, z obowiązkami raportowania wchodzącymi w życie we wrześniu 2026, wymaga generowania Software Bill of Materials (SBOM) dla produktów sprzedawanych w UE. SBOM wymienia każdy komponent w oprogramowaniu, włącznie z bezpośrednimi zależnościami, zależnościami przechodnimi i ich wersjami.

SLSA (Supply-chain Levels for Software Artifacts) uzupełnia SBOM, weryfikując sposób budowania oprogramowania. SBOM odpowiada na pytanie "jakie komponenty są w tym oprogramowaniu?", podczas gdy SLSA odpowiada na "czy proces budowania jest godny zaufania?"

# .github/workflows/supply-chain.yml
name: Supply Chain Security

on:
  push:
    tags:
      - 'v*'

jobs:
  build-with-provenance:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      attestations: write
    steps:
      - uses: actions/checkout@v4
      
      - name: Build container image
        run: docker build -t myapp:${{ github.ref_name }} .
        
      - name: Generate SBOM
        uses: anchore/sbom-action@v0.17.0
        with:
          image: myapp:${{ github.ref_name }}
          format: cyclonedx-json
          output-file: sbom.json
          
      - name: Sign with Cosign
        uses: sigstore/cosign-installer@v3.7.0
        
      - name: Sign image and attach SBOM
        run: |
          cosign sign --yes myapp:${{ github.ref_name }}
          cosign attach sbom --sbom sbom.json myapp:${{ github.ref_name }}
          cosign sign --yes --attachment sbom myapp:${{ github.ref_name }}

Cosign z Sigstore podpisuje artefakty przy użyciu podpisywania bezkluczykowego wspieranego przez urząd certyfikacji Fulcio. Podpis wiąże artefakt z przepływem CI, który go wyprodukował, umożliwiając weryfikację, że obraz pochodzi z zaufanego pipeline.

Wykrywanie Sekretów: Pierwsza Linia Obrony

Zakodowane na stałe sekrety pozostają najczęstszym znaleziskiem bezpieczeństwa w bazach kodu. Klucze dostępu AWS, hasła do baz danych i tokeny API commitowane do kontroli wersji powodowały naruszenia na każdą skalę. Wykrywanie sekretów uruchamia się pre-commit, aby zablokować poświadczenia zanim wejdą do repozytorium.

Gitleaks wykrywa sekrety przy użyciu wzorców regex i analizy entropii. Hook pre-commit zapobiega commitowaniu sekretów.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks
        args: ['--verbose']

# .github/workflows/secrets.yml
name: Secrets Detection

on:
  pull_request:

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          
      - name: Gitleaks scan
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Opcja fetch-depth: 0 klonuje pełną historię, pozwalając Gitleaks skanować wszystkie commity w PR, nie tylko najnowszy.

Pytania Rekrutacyjne DevSecOps: Co Pytają Rekruterzy

Rozmowy kwalifikacyjne DevSecOps oceniają zarówno wiedzę o bezpieczeństwie, jak i praktyczne doświadczenie CI/CD. Poniższe pytania pojawiają się często w rozmowach 2026 roku na stanowiska senior DevOps i platform engineering. Więcej pytań o bezpieczeństwo pipeline znajduje się w module CI/CD Pipeline Security interview.

"Jak zaimplementować shift-left security w istniejącym pipeline?"

Bezpieczeństwo shift-left przenosi testowanie wcześniej w cyklu rozwoju. Praktyczna implementacja obejmuje dodanie hooków pre-commit do wykrywania sekretów, skanów SAST na pull requestach i sprawdzeń SCA w fazie budowania. Kluczem jest inkrementalne wdrażanie: zacząć od wykrywania sekretów, ponieważ ma najniższy wskaźnik fałszywych alarmów i najwyższy sygnał, następnie dodać SCA dla znanych CVE, potem dostroić reguły SAST, aby zredukować szum przed włączeniem jako blokującej bramki.

"Wyjaśnij różnicę między SAST a DAST. Kiedy używać każdego z nich?"

SAST analizuje kod źródłowy bez wykonania. Znajduje SQL injection, XSS i niezabezpieczoną kryptografię poprzez dopasowywanie wzorców do struktury kodu. SAST uruchamia się wcześnie, na każdym PR, ponieważ potrzebuje tylko kodu.

DAST atakuje działającą aplikację. Znajduje obejścia uwierzytelniania, złamaną kontrolę dostępu i podatności typu injection, które ujawniają się tylko w czasie wykonania. DAST uruchamia się po wdrożeniu względem środowiska stagingowego.

Oba się uzupełniają. SAST wychwytuje błędy kodowania przed merge; DAST weryfikuje, że wdrożona aplikacja zachowuje się bezpiecznie. Dojrzały pipeline uruchamia oba.

"Co to jest SBOM i dlaczego jest wymagany?"

Software Bill of Materials wymienia każdy komponent w oprogramowaniu, włącznie z bezpośrednimi i przechodnimi zależnościami z dokładnymi wersjami. Wymogi regulacyjne takie jak EU Cyber Resilience Act wymagają generowania SBOM dla produktów wchodzących na rynek UE od września 2026.

Praktycznie SBOM umożliwia szybką reakcję na incydenty. Gdy pojawi się nowe CVE, zespół bezpieczeństwa może odpytać bazę danych SBOM, aby zidentyfikować każdą usługę uruchamiającą podatny komponent, zamiast ręcznie skanować wszystkie repozytoria.

"Jak zapobiegać zmęczeniu alarmami w narzędziach bezpieczeństwa?"

Zmęczenie alarmami występuje, gdy deweloperzy ignorują znaleziska bezpieczeństwa, ponieważ stosunek sygnału do szumu jest zbyt niski. Zapobieganie wymaga dostrojenia każdego narzędzia przed włączeniem blokujących bramek. Dla SAST należy wyłączyć reguły produkujące fałszywe alarmy w bazie kodu i włączać je stopniowo po oczyszczeniu. Dla SCA skupić się na znaleziskach CRITICAL i HIGH ze znanymi exploitami. Dla DAST skonfigurować skany bazowe, aby wykluczyć fałszywe alarmy z przyszłych uruchomień.

Metryką do śledzenia jest czas naprawy rzeczywistych podatności. Jeśli ta liczba rośnie, deweloperzy ignorują alarmy.

Bezpieczeństwo Kontenerów i Runtime

Skanowanie obrazów kontenerów wychwytuje podatności przed wdrożeniem. Bezpieczeństwo runtime monitoruje kontenery w produkcji pod kątem anomalnego zachowania. Kombinacja adresuje zarówno znane podatności (CVE w obrazach bazowych), jak i nieznane zagrożenia (skompromitowane kontenery, kryptominery).

Trivy skanuje obrazy jako część pipeline budowania. Falco monitoruje zachowanie runtime przy użyciu eBPF.

# .github/workflows/container-security.yml
name: Container Security

on:
  push:
    branches: [main]

jobs:
  scan-image:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
        
      - name: Scan image
        uses: aquasecurity/trivy-action@0.28.0
        with:
          image-ref: myapp:${{ github.sha }}
          format: 'table'
          exit-code: '1'
          severity: 'CRITICAL'
          ignore-unfixed: true

Flaga ignore-unfixed: true pomija podatności bez dostępnych poprawek. Zapobiega to blokowaniu wdrożeń dla CVE, których obecnie nie można naprawić.

Dla bezpieczeństwa runtime, reguły Falco wykrywają podejrzaną aktywność w działających kontenerach. Moduł container supply chain security szczegółowo omawia podpisywanie obrazów i kontrolę admisji.

Bezpieczeństwo IaC: Skanowanie Terraform i Manifestów Kubernetes

Infrastructure as Code wprowadza ryzyko bezpieczeństwa na warstwie konfiguracji. Zbyt permisywne polityki IAM, publicznie dostępne buckety S3 i niezaszyfrowane bazy danych wynikają z niezabezpieczonych domyślnych ustawień w szablonach IaC.

Checkov skanuje Terraform, CloudFormation, Kubernetes, Helm i Dockerfile pod kątem błędnych konfiguracji.

# .github/workflows/iac-scan.yml
name: IaC Security Scan

on:
  pull_request:
    paths:
      - 'terraform/**'
      - 'k8s/**'
      - 'helm/**'

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@v12
        with:
          directory: .
          framework: terraform,kubernetes,helm
          output_format: sarif
          output_file_path: checkov.sarif
          soft_fail: false
          
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: checkov.sarif

Filtr ścieżek zapewnia, że skany IaC uruchamiają się tylko przy zmianach plików infrastruktury, redukując czas CI dla zmian tylko aplikacyjnych.

Kompletny Pipeline DevSecOps na 2026 Rok

Gotowy do produkcji pipeline DevSecOps w 2026 integruje te narzędzia na każdym etapie:

• Pre-commit: Gitleaks (sekrety), opcjonalnie lokalny SAST
• Pull request: Semgrep (SAST), Trivy (SCA), Checkov (IaC)
• Build: Skanowanie obrazów kontenerów, generowanie SBOM
• Pre-deploy: Podpisywanie obrazów z Cosign, kontrola admisji z Kyverno
• Post-deploy: DAST z ZAP względem stagingu
• Runtime: Falco do monitorowania kontenerów, zarządzanie postawą bezpieczeństwa chmury

Darmowy stos (Semgrep, Trivy, ZAP, Gitleaks, Checkov, Falco) pokrywa każdą kategorię. Komercyjne narzędzia dodają centralne dashboardy, zarządzanie politykami i zmniejszony wysiłek strojenia, ale pokrycie bezpieczeństwa jest osiągalne bez kosztów licencji.

Organizacje przygotowujące się do ról DevSecOps powinny ćwiczyć budowanie tych pipeline w osobistych projektach. Moduł cloud identity and secrets management obejmuje stronę zarządzania sekretami równania.