DevSecOps dla programistow: Praktyczny przewodnik po shift-left security

Podatnosc wykryta podczas pisania kodu kosztuje programiste kilka minut naprawy. Ta sama podatnosc wychwycona na produkcji kosztuje caly sprint. A jesli atakujacy znajdzie ja pierwszy, kosztuje miliony. To glowny argument za shift-left security - przesuwaniem kontroli bezpieczenstwa jak najwczesniej w cyklu zycia oprogramowania.

DevSecOps bierze te idee i przeksztalca ja w praktyke: bezpieczenstwo nie jest oddzielna faza na koncu, ale ciaglym procesem wplecionym w kazdy etap rozwoju - od pierwszej linii kodu po wdrozenie na produkcje.

Koszt poznego bezpieczenstwa

Raport IBM Cost of a Data Breach konsekwentnie pokazuje, ze koszt naprawiania problemow bezpieczenstwa rosnie wykladniczo, im pozniej zostana wykryte:

Wniosek jest jasny: kazdy etap, o ktory przesuniesz bezpieczenstwo wczesniej, oszczedza rzad wielkosci kosztow i czasu.

Pipeline DevSecOps

Dojrzaly pipeline DevSecOps integruje kontrole bezpieczenstwa na kazdym etapie:

Omowmy kazdy etap z konkretnymi narzedziami i konfiguracja.

Etap 1: Bezpieczenstwo w IDE

Najszybsza petla zwrotna. Wychwytuj podatnosci zanim jeszcze zapiszesz plik.

Zalecane narzedzia

• Semgrep: lekka analiza statyczna z regulami spolecznosci dla podatnosci OWASP
• Snyk IDE Extension: skanowanie podatnosci zaleznosci w czasie rzeczywistym
• GitLens + GitLeaks: wykrywanie sekretow w edytorze
• ESLint Security Plugins: eslint-plugin-security dla Node.js, eslint-plugin-no-unsanitized dla DOM XSS

Przyklad: Konfiguracja ESLint Security

{
  "extends": ["eslint:recommended"],
  "plugins": ["security", "no-unsanitized"],
  "rules": {
    "security/detect-object-injection": "warn",
    "security/detect-non-literal-regexp": "warn",
    "security/detect-unsafe-regex": "error",
    "security/detect-buffer-noassert": "error",
    "security/detect-eval-with-expression": "error",
    "security/detect-no-csrf-before-method-override": "error",
    "security/detect-possible-timing-attacks": "warn",
    "no-unsanitized/method": "error",
    "no-unsanitized/property": "error"
  }
}

Etap 2: Pre-commit Hooks

Druga linia obrony. Uruchamia sie automatycznie przed kazdym commitem, blokujac niebezpieczny kod przed wejsciem do repozytorium.

Gitleaks: Wychwytuj sekrety zanim trafia do Git

Najczestszym bledem bezpieczenstwa w bazach kodu jest commitowanie sekretow - kluczy API, hasel do baz danych, tokenow. Gdy sekret trafi do historii git, jest niezwykle trudno go calkowicie usunac (nawet przy force push, forki i cache moga go zachowac).

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.0
    hooks:
      - id: gitleaks

  - repo: https://github.com/semgrep/semgrep
    rev: v1.90.0
    hooks:
      - id: semgrep
        args: ['--config', 'auto']

Instalacja i aktywacja:

pip install pre-commit
pre-commit install

Teraz kazdy git commit automatycznie skanuje w poszukiwaniu wyciekow sekretow i typowych podatnosci. Jesli cos zostanie znalezione, commit jest blokowany.

Niestandardowe reguly Gitleaks

Mozesz dodac wlasne wzorce dla sekretow Twojej organizacji:

# .gitleaks.toml
title = "Custom Gitleaks Config"

[[rules]]
id = "internal-api-key"
description = "Internal API key detected"
regex = '''INTERNAL_KEY_[A-Za-z0-9]{32}'''
tags = ["key", "internal"]

Etap 3: Bezpieczenstwo pipeline CI/CD

To jest miejsce, gdzie dzieje sie ciezka praca. Twoj pipeline CI powinien uruchamiac wiele skanow bezpieczenstwa przy kazdym pull requeście.

SAST (Static Application Security Testing)

Narzedzia SAST analizuja kod zrodlowy bez jego uruchamiania, szukajac wzorcow wskazujacych na podatnosci.

# .github/workflows/security.yml
name: Security Scan
on:
  pull_request:
    branches: [main]

jobs:
  sast:
    name: Static Analysis
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/typescript
            p/nodejs
            p/react
          generateSarif: true

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

Zestaw regul p/owasp-top-ten Semgrep wychwytuje najczestsze podatnosci: SQL injection, XSS, SSRF, path traversal, insecure deserialization i inne.

SCA (Software Composition Analysis)

SCA skanuje Twoje zaleznosci pod katem znanych podatnosci. Jest to krytyczne - ponad 80% kodu nowoczesnych aplikacji pochodzi z zaleznosci open-source.

  dependency-scan:
    name: Dependency Audit
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Snyk
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

      - name: npm audit
        run: npm audit --audit-level=high

Bezpieczenstwo kontenerow z Trivy

Jesli budujesz obrazy Docker, skanowanie ich pod katem podatnosci jest niezbedne. Trivy to najpopularniejszy skaner kontenerow open-source.

  container-scan:
    name: Container Security
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t my-app:${{ github.sha }} .

      - name: Run Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: my-app:${{ github.sha }}
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

      - name: Upload Trivy SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-results.sarif

Generowanie SBOM

Software Bill of Materials (SBOM) to kompletny inwentarz kazdego komponentu w Twojej aplikacji. Jest coraz czesciej wymagany przez frameworki zgodnosci i regulacje rzadowe (rozporzadzenie wykonawcze prezydenta USA w sprawie cyberbezpieczenstwa nakazuje SBOM dla oprogramowania federalnego).

  sbom:
    name: Generate SBOM
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM with Syft
        uses: anchore/sbom-action@v0
        with:
          format: spdx-json
          output-file: sbom.spdx.json

      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.spdx.json

Etap 4: Bezpieczne obrazy Docker

Produkcyjny obraz Docker powinien stosowac zasade najmniejszych uprawnien. Tak wyglada zahartowany Dockerfile:

# Build stage
FROM node:22-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage
FROM node:22-alpine AS runner
WORKDIR /app

# Install dumb-init before dropping root
RUN apk add --no-cache dumb-init

# Don't run as root
RUN addgroup -S app && adduser -S app -G app

# Copy only what's needed
COPY --from=builder --chown=app:app /app/dist ./dist
COPY --from=builder --chown=app:app /app/node_modules ./node_modules
COPY --from=builder --chown=app:app /app/package.json ./

# Drop to non-root user
USER app
ENTRYPOINT ["dumb-init", "--"]

# Health check
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD wget -qO- http://localhost:3000/health || exit 1

EXPOSE 3000
CMD ["node", "dist/server.js"]

Kluczowe praktyki:

1. Uzywaj multi-stage builds: etap builder ma zaleznosci deweloperskie; etap runner ma tylko kod produkcyjny
2. Nie uruchamiaj jako root: stworz uzytkownika bez uprawnien root i przejdz na niego
3. Uzywaj obrazow Alpine: mniejsza powierzchnia ataku (mniej pakietow zainstalowanych domyslnie)
4. Przypinaj wersje obrazow: node:22-alpine zamiast node:latest, aby uniknac atakow na lancuch dostaw
5. Uzywaj npm ci: deterministyczne instalacje z pliku lock, nie npm install

Etap 5: Zarzadzanie sekretami

Sekrety zakodowane na stale w kodzie sa przyczyna numer jeden naruszen w incydentach spowodowanych przez programistow.

Czego NIE robic

// NEVER do this
const API_KEY = "sk-1234567890abcdef";
const DB_PASSWORD = "supersecret123";

const client = new Client({
  connectionString: `postgres://admin:${DB_PASSWORD}@db.example.com/prod`
});

Co robic zamiast tego

// Use environment variables
const client = new Client({
  connectionString: process.env.DATABASE_URL
});

// Or use a secret manager
import { SecretManagerServiceClient } from '@google-cloud/secret-manager';

const client = new SecretManagerServiceClient();
const [version] = await client.accessSecretVersion({
  name: 'projects/my-project/secrets/db-password/versions/latest',
});
const dbPassword = version.payload?.data?.toString();

Hierarchia zarzadzania sekretami

OWASP Top 10: Krotka informacja

Kazdy programista powinien znac OWASP Top 10. Wersja skrocona:

Kompletny workflow bezpieczenstwa GitHub Actions

Kompletny, gotowy do produkcji workflow, ktory laczy wszystko powyzsze:

# .github/workflows/security.yml
name: Security Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read
  security-events: write

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

  sast:
    name: Static Analysis (SAST)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: semgrep/semgrep-action@v1
        with:
          config: p/owasp-top-ten p/typescript p/nodejs

  dependency-audit:
    name: Dependency Scan (SCA)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm audit --audit-level=high
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high
        continue-on-error: true

  container-scan:
    name: Container Scan
    runs-on: ubuntu-latest
    needs: [sast, dependency-audit]
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t app:${{ github.sha }} .
      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: app:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: '1'

  sbom:
    name: SBOM Generation
    runs-on: ubuntu-latest
    needs: [container-scan]
    steps:
      - uses: actions/checkout@v4
      - uses: anchore/sbom-action@v0
        with:
          format: spdx-json
          output-file: sbom.spdx.json

Metryki do sledzenia

Jak sprawdzic, czy Twoj program DevSecOps dziala? Sledz te metryki:

• Mean time to remediate (MTTR): jak szybko naprawiasz podatnosci po ich wykryciu
• Vulnerability escape rate: procent podatnosci, ktore docieraja do produkcji
• False positive rate: zbyt wiele falszywych alarmow prowadzi do zmeczenia alertami i ignorowania ostrzezen
• Dependency freshness: sredni wiek Twoich zaleznosci (starsze = wieksza szansa na znane CVE)
• SBOM coverage: procent projektow z aktualnymi SBOM

Pierwsze kroki: Praktyczny plan dzialania

Nie probuj wdrazac wszystkiego naraz. Podejscie fazowe dziala lepiej:

Podsumowanie

DevSecOps to nie dodawanie kolejnych narzedzi do pipeline - to uczynienie bezpieczenstwa naturalna czescia sposobu, w jaki tworzysz oprogramowanie. Celem nie jest blokowanie kazdego PR ostrzezeniami bezpieczenstwa, ale dawanie programistom szybkiego feedbacku, aby mogli naprawiac problemy, gdy kod jest jeszcze swiezy w ich pamieci.

Zacznij od podstaw: pre-commit hooks dla sekretow, skanowanie zaleznosci w CI i skanowanie kontenerow dla obrazow Docker. Nastepnie iteruj w oparciu o potrzeby Twojego zespolu.

Bezpieczenstwo to nie funkcja, ktora wdrazasz raz. To praktyka, ktora wbudowujesz w kazdy commit.

Lista kontrolna DevSecOps na start:

• Zainstalowane pre-commit hooks Gitleaks
• Pliki .env i pliki z sekretami w .gitignore
• Semgrep SAST w pipeline CI
• Snyk lub npm audit do skanowania zaleznosci
• Trivy do skanowania obrazow kontenerow
• Uzytkownik bez uprawnien root w Dockerfile
• Sekrety w zmiennych srodowiskowych lub secret manager
• Generowanie SBOM przy kazdym wydaniu
• Swiadomosc OWASP Top 10 w calym zespole