Operacje bezpieczeństwa z AI

Snyk właśnie oznaczył 14 „krytycznych” CVE w drzewie zależności. Jedenaście dotyczy pakietów wyłącznie deweloperskich, które nigdy nie trafiają na produkcję, dwa są nieosiągalne z jakiejkolwiek ścieżki kodu, którą faktycznie wywołujesz, a ten jeden, który ma znaczenie, leży pogrzebany na samym dole raportu. Twój release jest zablokowany, bo znów segregujesz wszystko ręcznie. Obietnica „bezpieczeństwa z AI” rzadko oznacza nowy skaner — to asystent, który czyta wynik skanera tak, jak zrobiłby to starszy inżynier: oddziela realne, możliwe do wykorzystania podatności od szumu i zamienia te prawdziwe w zrecenzowane pull requesty, zamiast w 200-liniowy zrzut JSON, którego nikt nie otwiera.

Ten przewodnik buduje taką pętlę z narzędzi, które istnieją już dziś — Semgrep, npm audit, detect-secrets, Trivy i serwer GitHub MCP — sterowanych z Cursora, Claude Code lub Codex.

Co z tego wyniesiesz

• Prompt do segregacji, który zamienia surowy zrzut z semgrep --config=auto w uszeregowane wyniki „możliwe do wykorzystania vs fałszywy alarm” wraz z minimalnymi poprawkami
• Prompt do CVE w zależnościach, który czyta npm audit --json i mówi, które CVE są naprawdę osiągalne w Twoim kodzie
• Prompt do rotacji sekretów na wypadek, gdy detect-secrets znajdzie żywe poświadczenie w historii
• Mechanikę poszczególnych narzędzi do uruchamiania tej pętli w Cursorze (tryb agenta + MCP), Claude Code (bezgłowy -p w CI + hooki) i Codex (automatyzacja w chmurze + GitHub)
• Zadanie CI, które uruchamia krok skan-i-segregacja na każdym PR i kończy się błędem przy naprawdę nowych wynikach o wysokiej istotności

Przepływ pracy: skanuj, segreguj, naprawiaj

Błąd, który popełnia większość zespołów, to podłączenie AI tak, by zastąpiło skaner. Skaner (Semgrep, CodeQL, Trivy) jest deterministyczny, szybki i audytowalny — zostaw go. Zadaniem AI jest ta kosztowna część, którą obecnie wykonuje człowiek: czytanie wyników, eliminowanie fałszywych alarmów i proponowanie najmniejszej poprawnej poprawki. Pętla ma trzy kroki.

1. Uruchom deterministyczne skanery i przechwyć wynik czytelny dla maszyny. To są prawdziwe komendy, nie prompty — wklej je do terminala:

   # Analiza statyczna (reguły z rejestru)
   semgrep --config=auto --json --output semgrep.json .
   
   # CVE w zależnościach
   npm audit --json > audit.json
   
   # Sekrety w drzewie roboczym + historii
   detect-secrets scan --all-files > secrets.json
   
   # Obraz kontenera (jeśli go dostarczasz)
   trivy image --format json --output trivy.json myapp:latest

   semgrep instalujesz przez pip install semgrep lub brew install semgrep; detect-secrets przez pip install detect-secrets; trivy przez brew install trivy lub jego skrypt instalacyjny. Żadne z nich nie są pakietami npm — nie rób npm install.

2. Przekaż wynik do AI w celu segregacji. Tu leży właściwa wartość. Skaner mówi „potencjalne wstrzyknięcie SQL w db.ts:42”; asystent mówi, czy db.ts:42 jest osiągalne z niezaufanego wejścia, czy też jest zapytaniem parametryzowanym, które reguła błędnie oznaczyła. Użyj promptu do segregacji poniżej.

3. Zamień prawdziwe wyniki w zrecenzowany PR — nigdy w automatycznie scalany. Pozwól AI naszkicować poprawkę i treść PR, ale zatwierdza ją człowiek (lub wymagana bramka CI). Automatyczne stosowanie poprawek AI w pliku wrażliwym na bezpieczeństwo to przepis na wprowadzenie regresji z zielonym ptaszkiem.

Mechanika kroków 2 i 3 różni się między narzędziami. Komendy skanerów z kroku 1 są wszędzie identyczne.

Cursor

Otwórz repozytorium w Cursorze, uruchom skanery, by semgrep.json / audit.json znalazły się w przestrzeni roboczej, a następnie przejdź do trybu agenta (Cmd/Ctrl+I). Tryb agenta potrafi czytać pliki JSON bezpośrednio i edytować oznaczone pliki źródłowe w miejscu, pokazując każdą zmianę jako punkt kontrolny, który akceptujesz albo odrzucasz.

Dodaj serwer GitHub MCP, by agent mógł otworzyć PR z naprawą bez wychodzenia z edytora. W ustawieniach MCP Cursora (lub w .cursor/mcp.json) zarejestruj oficjalny zdalny serwer:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer ${GITHUB_PAT}" }
    }
  }
}

Teraz agent czyta semgrep.json, poprawia dwa prawdziwe wyniki i wywołuje narzędzie create_pull_request z GitHub MCP — wszystko z jednego promptu.

Claude Code

Claude Code błyszczy w bezgłowej połowie tej pętli, działającej w CI. Uruchom skanery, a następnie przepuść prompt do segregacji przez -p (tryb print) z plikami JSON na dysku:

semgrep --config=auto --json --output semgrep.json .
claude -p "Read semgrep.json. For each finding, classify exploitable vs \
  false-positive and output JSON: {file, line, verdict, reason, patch}. \
  Treat anything under test/ or scripts/ as non-shipping." \
  --allowedTools "Read,Grep" --output-format json > triage.json

Dodaj serwer GitHub MCP z udokumentowanym transportem HTTP, by Claude Code mógł otworzyć PR lokalnie lub w CI:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer ${GITHUB_PAT}"

Hook PreToolUse to właściwe miejsce, by egzekwować regułę „żadnego automatycznego scalania poprawek bezpieczeństwa” — zablokuj każdy Bash(gh pr merge*) na gałęzi nazwanej security-* i wymagaj recenzji człowieka.

Codex

Codex (GPT-5.5 w App/CLI/IDE/Cloud) jest najmocniejszy w zaplanowanym, bezobsługowym wariancie. Uruchom segregację z CLI na przechwyconym wyniku:

semgrep --config=auto --json --output semgrep.json .
codex exec "Read semgrep.json and rank findings by real exploitability; \
  propose a minimal patch for each genuinely exploitable one." \
  --ask-for-approval on-request

Do cyklicznego skanowania użyj Codex Cloud wraz z jego integracją z GitHubem: skieruj zadanie Cloud na repozytorium według harmonogramu, pozwól mu uruchomić skanery i segregację, a następnie otworzyć PR z naprawą przez podłączoną aplikację GitHub. Zostaw --ask-for-approval on-request (nie never), aby destrukcyjna naprawa wciąż zatrzymywała się na człowieku.

Prompty gotowe do skopiowania

To są przepisy. Zakładają, że masz już przechwycony JSON ze skanerów, tak jak opisano powyżej.

Wskazówka

Segregacja Semgrep — oddziel możliwe do wykorzystania od fałszywych alarmów:

Here is semgrep.json from `semgrep --config=auto`. For EACH finding:
1. Classify it as EXPLOITABLE, FALSE_POSITIVE, or NEEDS_REVIEW. Treat any
   path under test/, tests/, scripts/, or *.spec.* as non-shipping code that
   cannot be a production vulnerability on its own.
2. For EXPLOITABLE findings, trace whether the tainted value reaches the sink
   from untrusted input (request body, query param, env, file). If it can't,
   downgrade to FALSE_POSITIVE and say why.
3. Propose the smallest patch that fixes each EXPLOITABLE finding without
   changing behavior — parameterized query, output encoding, auth check.
4. Rank the EXPLOITABLE findings by real risk (reachability x impact).

Output a markdown table: file:line | rule | verdict | reason | patch summary.
Do NOT include FALSE_POSITIVE findings in the patch set.

Wskazówka

Segregacja CVE w zależnościach — czy to naprawdę osiągalne?

Here is audit.json from `npm audit --json`. For each advisory:
1. State whether the vulnerable package is a direct or transitive dependency,
   and whether it's in dependencies or devDependencies.
2. Search the codebase for actual call sites of the vulnerable API surface
   (not just the package import). A CVE in a function we never call is not a
   production risk — say so explicitly.
3. For real, reachable CVEs: give the exact `npm install pkg@version` or
   `overrides` entry that resolves it, and flag any breaking-change risk.
4. Produce two lists: "Fix now" (reachable, shipping) and "Backlog"
   (dev-only or unreachable), with one-line justification each.

Wskazówka

Sekret znaleziony w historii — rotuj, nie tylko usuwaj:

detect-secrets flagged a live <TYPE> credential at <FILE>:<LINE>, committed in
<COMMIT>. Walk me through remediation in order, with exact commands:
1. Rotate the credential at the provider FIRST (assume the committed value is
   already compromised — deleting the line does not un-leak it).
2. Replace the hardcoded value with an env var / secret-manager reference and
   show the minimal code diff.
3. Purge it from git history (git filter-repo or BFG) and note the
   force-push + team re-clone consequences.
4. Add a detect-secrets pre-commit hook config so this class of leak is
   caught before the next commit.

Notatka

Dlaczego prompt strażniczy należy do tej pętli: zanim zastosujesz jakąkolwiek poprawkę bezpieczeństwa zaproponowaną przez AI, zapytaj „Czy ta zmiana zmienia zachowanie dla prawidłowych danych wejściowych i czy zamyka konkretny wektor, który oznaczył skaner — a nie inny?”. Poprawka, która niczego nie naprawia, ale „zazielenia” wynik, jest gorsza niż brak poprawki, bo następny skan pozostaje cichy, podczas gdy dziura wciąż jest otwarta.

Serwery MCP i umiejętności do tej pętli

Dwie opcje rozszerzalności zmieniają ten przepływ pracy i nie są wymienne.

• Serwer GitHub MCP (github/github-mcp-server, zdalnie pod https://api.githubcopilot.com/mcp/) to trwałe połączenie: pozwala agentowi przeszukiwać kod w całej organizacji, czytać alerty Dependabota / skanowania sekretów i otwierać PR z naprawą. Sięgaj po niego, gdy agent musi wielokrotnie działać na GitHubie. Nie istnieje warstwa ułatwiająca w stylu @anthropic/* ani jednostringowe new MCPClient('github') — MCP to connect(transport), a potem callTool({ name, arguments }). Jeśli skryptujesz bezpośrednio na SDK, pakiet to @modelcontextprotocol/sdk, a klient mieszka pod @modelcontextprotocol/sdk/client/index.js.
• Umiejętność Semgrep (semgrep/skills, instalowana przez npx skills add semgrep/skills) to lżejsza opcja: uczy agenta, jak pisać własne reguły Semgrep dla Twojego kodu i uruchamiać skany, bez stawiania serwera. Sięgaj po umiejętność, gdy zadaniem jest „napisz i uruchom reguły”; sięgaj po serwer MCP, gdy zadaniem jest „operuj na GitHubie”.

Notatka

Zasada kciuka: umiejętność wzbogaca to, jak agent robi jedną rzecz (pisanie reguł Semgrep); serwer MCP daje mu trwałe połączenie z systemem, który nieustannie odpytuje i zmienia (GitHub). Gdy istnieją oba, umiejętność jest szybsza w instalacji, a serwer jest głębszy.

Utwardzanie klastra (aktualny Kubernetes)

Jeśli dostarczasz na Kubernetes, AI może naszkicować Twoją politykę dopuszczania — ale musi naszkicować tę aktualną. PodSecurityPolicy (policy/v1beta1) zostało usunięte w Kubernetes 1.25 i nie istnieje na żadnym wspieranym klastrze. Wspieranym następcą jest Pod Security Admission poprzez etykiety przestrzeni nazw, w parze z NetworkPolicy do izolacji ruchu.

# przestrzeń nazw z egzekwowanymi Pod Security Standards (zastępuje PodSecurityPolicy)
apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
---
# domyślne odrzucanie ruchu wyjściowego/wejściowego, potem zezwól tylko na to, co potrzebne
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payments-isolation
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payments-api
  policyTypes: [Ingress, Egress]
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: api-gateway }
      ports:
        - { protocol: TCP, port: 8443 }
  egress:
    - to:
        - podSelector:
            matchLabels: { app: postgres }
      ports:
        - { protocol: TCP, port: 5432 }

Wskazówka

Wygeneruj aktualną politykę dopuszczania:

Generate Kubernetes manifests to harden the `payments` namespace for a 1.30
cluster. Use Pod Security Admission labels (enforce: restricted) — NOT
PodSecurityPolicy, which is removed. Add a default-deny NetworkPolicy that
only allows ingress from app=api-gateway on 8443 and egress to app=postgres
on 5432. Explain any workload change the restricted profile forces (no root,
no privilege escalation, read-only root FS).

Podłączenie do CI

Uruchamiaj deterministyczne skanery na każdym PR, a potem segregację AI jako krok doradczy. Twarda bramka pozostaje deterministyczna — pipeline kończy się błędem przy naprawdę nowych wynikach o wysokiej istotności z Semgrep/Trivy, a nie na podstawie opinii AI. Zwróć uwagę na actions/checkout@v5 (Node 24; runnery v3 są wycofane z końcem czerwca 2026).

.github/workflows/security-scan.yml

name: Security Scan
on:
  pull_request:
  schedule:
    - cron: '0 */6 * * *'

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5

      - name: Semgrep (hard gate on new high-severity)
        uses: semgrep/semgrep-action@v1
        with:
          config: auto

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

      - name: Secret scan
        run: |
          pipx install detect-secrets
          detect-secrets scan --all-files | tee secrets.json

      # Doradczo: podsumowanie segregacji AI wpisane do PR, nie blokada
      - name: AI triage (advisory)
        if: github.event_name == 'pull_request'
        run: |
          semgrep --config=auto --json --output semgrep.json . || true
          claude -p "Summarize semgrep.json: rank exploitable findings, list \
            likely false positives, suggest the smallest fix for each real one." \
            --allowedTools "Read,Grep" --output-format json > triage.json
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

Kiedy to się psuje

Uwaga

semgrep --config=auto zalewa cię fałszywymi alarmami. Zestaw reguł auto jest celowo szeroki. Przypnij ukierunkowane zestawy reguł dla swojego stosu (--config=p/owasp-top-ten --config=p/javascript) i podaj AI kontekst projektu („to jest API w Expressie; req.params to jedyne niezaufane źródło”), aby mogło poprawnie obniżać szum. Nie pozwól, by ilość popchnęła cię w stronę automatycznego stosowania poprawek.

Uwaga

Serwer GitHub MCP zwraca limity szybkości lub 403 na dużych organizacjach. Przeszukiwanie kodu w wielkiej organizacji trafia we wtórne limity szybkości GitHuba, a drobnoziarnisty PAT może nie mieć zakresu security_events, więc odczyty Dependabota / skanowania sekretów zwracają pustkę. Ogranicz agenta do jednego repozytorium naraz i nadaj PAT-owi jawny dostęp repo + security_events, zanim obwinisz prompt.

Uwaga

Automatycznie zastosowana poprawka AI psuje build albo naprawia zły wektor. Właśnie dlatego krok 3 zabrania automatycznego scalania na gałęziach bezpieczeństwa. Jeśli musisz zautomatyzować, zabezpiecz to bramką: wymagaj pełnego zestawu testów oraz ponownego skanu, który potwierdza, że konkretny wynik zniknął, i utrzymuj zatwierdzanie przez człowieka na gałęziach security-* (hook PreToolUse w Claude Code lub reguła ochrony gałęzi w GitHubie).

Uwaga

Pułapka „ai_classify_pii()”. Funkcje SQL w stylu ai_classify_pii() czy ai_sensitivity_score() nie istnieją w Postgresie ani w żadnej standardowej bazie danych. Klasyfikacja PII odbywa się w kodzie aplikacji wywołującym prawdziwe API modelu albo przez dedykowany skaner — nie jako wbudowany SQL. Jeśli wygenerowane zapytanie wywołuje funkcję, której baza nie ma, AI ją zmyśliło; poproś o przepisanie z użyciem information_schema oraz osobnego kroku klasyfikacji poza pasmem.

Co dalej

Automatyzacja zgodności z AI Zamień zbieranie dowodów SOC2 / GDPR i przygotowania do audytu w powtarzalny, napędzany przez AI przepływ pracy.

Bezpieczeństwo i zgodność dla przedsiębiorstw Zarządzanie sekretami w całej organizacji, tokeny Semgrep i egzekwowanie polityk na dużą skalę.

Optymalizacja kosztów z AI Utrzymaj pętlę skan-i-segregacja tanią dzięki routingowi modeli i limitom wydatku na tokeny na każdy przepływ pracy.

Pipeline'y CI/CD Pełny pipeline, do którego podłączają się te bramki bezpieczeństwa, w Cursorze, Claude Code i Codex.