Automatyzacja operacji bezpieczeństwa

Automatyzacja operacji bezpieczeństwa łączy deterministyczne skanery — Semgrep, npm audit, detect-secrets, Trivy — z agentem AI w Cursorze, Claude Code lub Codeksie, który czyta ich wynik, oddziela realne podatności od fałszywych alarmów, zamienia je w zrecenzowany pull request, bramkuje CI na naprawialnych HIGH i CRITICAL oraz szkicuje dowody SOC 2 i GDPR cytujące prawdziwe artefakty.

Twój skaner właśnie oznaczył 412 „krytycznych” odkryć w 50 obrazach kontenerów i 14 CVE w zależnościach. Jedenaście z tych CVE dotyczy pakietów wyłącznie deweloperskich, które nigdy nie trafiają na produkcję, dwa są nieosiągalne z jakiejkolwiek wywoływanej ścieżki kodu, a ten jeden, który ma znaczenie, leży pogrzebany na dole raportu. W tym czasie kanał on-call płonie, a audytor SOC 2 chce dowodów z przeglądu dostępów na piątek.

Obietnica „bezpieczeństwa z AI” rzadko oznacza nowy skaner. To asystent, który czyta wynik skanera tak, jak zrobiłby to starszy inżynier — koreluje odkrycie z twoim kodem, eliminuje to, co nieosiągalne, i zamienia resztę w zrecenzowany pull request zamiast w 200-liniowy zrzut JSON, którego nikt nie otwiera.

Co wyniesiesz z automatyzacji operacji bezpieczeństwa

• Prompt do triage dla każdej klasy skanera: odkrycia SAST z Semgrepa, CVE z npm audit, obrazy kontenerów z Trivy’ego i żywy sekret znaleziony w historii
• Mechanikę poszczególnych narzędzi do prowadzenia tej pętli w Cursorze (tryb agenta + MCP), Claude Code (bezgłowy -p w CI + hooki) i Codeksie (piaskownica CLI + automatyzacja w chmurze)
• Workflow CI, który uruchamia skanery jako twardą bramkę, a triage AI jako krok doradczy, plus zadanie Trivy blokujące merge przy naprawialnych HIGH/CRITICAL
• Zweryfikowane konfiguracje MCP dla danych bezpieczeństwa AWS i Azure, serwer GitHub MCP do otwierania PR-ów z naprawą oraz jeden skaner higieny MCP, który naprawdę warto uruchamiać
• Utwardzanie Kubernetes z aktualnymi API (Pod Security Admission, nie usunięte PodSecurityPolicy)
• Trzeźwą listę trybów awarii, żebyś nie dostarczał fałszywej pewności

Przepływ pracy: agent na szczycie prawdziwych narzędzi

Błąd, który popełnia większość opracowań o „AI SecOps”, to proszenie modelu, by był skanerem. Nie jest. Semgrep, CodeQL i Trivy są deterministyczne, szybkie i audytowalne — zostaw je. 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.

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

   # Static analysis (registry rules)
   semgrep --config=auto --json --output semgrep.json .
   
   # Dependency CVEs
   npm audit --json > audit.json
   
   # Secrets in working tree + history
   detect-secrets scan --all-files > secrets.json
   
   # Container image (if you ship one)
   trivy image --severity HIGH,CRITICAL --format json -o trivy.json myorg/api: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 triage. 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.

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.

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

Cursor

Uruchom skanery, tak by semgrep.json / audit.json / trivy.json istniały w przestrzeni roboczej, a potem wejdź w tryb agenta (Cmd/Ctrl+I). Tryb agenta czyta JSON bezpośrednio i edytuje oznaczone pliki źródłowe w miejscu, pokazując każdą zmianę jako checkpoint, który akceptujesz lub odrzucasz. Z podłączonym serwerem MCP @aws-security dodaj @aws-security do promptu, aby mógł sprawdzić, czy dana usługa jest faktycznie wystawiona do internetu.

Dodaj serwer GitHub MCP, aby agent mógł otworzyć PR z naprawą bez opuszczania 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, łata dwa prawdziwe odkrycia 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, tej w CI. Uruchom skanery, a potem przepuść prompt do triage przez -p (tryb print) z JSON-em na dysku. Claude Code potrafi sam uruchomić grep/rg, by potwierdzić osiągalność, co czyni jego priorytetyzację konkretną, a nie zgadywaną:

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

Ten sam kształt działa dla odkryć w kontenerach, gdzie użytecznym wynikiem jest ranking priorytetów, a nie zestaw poprawek:

claude -p "Read trivy.json (Trivy JSON). For each HIGH/CRITICAL: name the CVE and package, use Grep to check if the vulnerable path is reachable in our source, and assign P0/P1/P2 with a one-line justification. Output a markdown table sorted by priority." --output-format json > container-triage.json

Dodaj serwer GitHub MCP z udokumentowanym transportem HTTP, aby Claude Code mógł otwierać 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 na wyegzekwowanie reguły „żadnego automatycznego scalania poprawek bezpieczeństwa” — zablokuj każde Bash(gh pr merge*) na gałęzi o nazwie security-* i wymagaj przeglądu przez człowieka.

Codex

Codex (GPT-5.6 Sol w App/CLI/IDE/Cloud) jest najmocniejszy w wariancie zaplanowanym i bezobsługowym, a domyślna piaskownica czyni z niego bezpieczne miejsce do przeglądania każdej komendy przed uruchomieniem:

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

Dla przebiegu interaktywnego z przeglądem każdej akcji uruchom codex -a untrusted (pyta przed każdą akcją) i wklej:

Read trivy.json. For each HIGH/CRITICAL finding, check whether the vulnerable
package is actually imported and reachable in this repo, classify it P0/P1/P2
by real exploitability, and propose the smallest dependency bump that resolves
the P0s. Show me the diff before applying anything.

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

Prompty do triage, po jednym na klasę skanera

To są przepisy. Zakładają, że masz już przechwycony JSON ze skanerów. Każdy celuje w inne wejście i ta różnica ma znaczenie: odkrycia Semgrepa wymagają osiągalności skażenia, CVE wymagają osiągalności miejsc wywołania, odkrycia w kontenerach wymagają ekspozycji, a wyciekły sekret wymaga rotacji przed czymkolwiek innym.

Gotowy prompt: triage Semgrepa, realne kontra fałszywe alarmy

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.

Gotowy prompt: triage CVE w zależnościach, czy to w ogóle 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.

Gotowy prompt: triage obrazu kontenera, z 412 odkryć do 3

Read trivy.json (Trivy output for our container images) and the codebase. For
each HIGH/CRITICAL finding: (1) state the CVE and affected package; (2) grep
the repo to determine whether the vulnerable code path is actually reachable in
our app, or only present in an unused transitive dependency; (3) check whether
the affected service is internet-exposed; (4) assign a real-world priority
(P0 fix-now / P1 this-sprint / P2 backlog) and justify it in one sentence.
Output a ranked table, most urgent first. Do not just repeat CVSS scores —
tell me what to fix first and why.

Gotowy prompt: sekret w historii, najpierw rotuj, potem 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.

Jak wygląda dobry wynik triage

Prawdziwe, osiągalne odkrycie, a nie zmyślone:

P0 — CVE-2026-42945 (nginx, przepełnienie sterty w ngx_http_rewrite_module, CVSS 9.2). Dotyczy: obraz bazowy nginx:1.30.0 w 3 usługach. Osiągalne: tak — wszystkie trzy używają dyrektyw rewrite. Wystawione do internetu: tak (ingress brzegowy). Naprawa: przebuduj na nginx:1.31.0 (lub 1.30.1), który zawiera łatkę. Załataj w ciągu 24 godzin.

To CVE jest prawdziwe (wprowadzone w 2008, ujawnione w 2026, naprawione w nginx 1.31.0 / 1.30.1) — w pracy nad bezpieczeństwem używaj weryfikowalnych odkryć; nigdy nie pozwól agentowi przedstawić wymyślonego numeru CVE jako faktu.

Podłączenie do CI

Uruchamiaj deterministyczne skanery na każdym PR, a potem triage AI jako krok doradczy. Twarda bramka pozostaje deterministyczna — pipeline kończy się błędem przy naprawdę nowych wynikach o wysokiej istotności z Semgrepa lub Trivy’ego, 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

      # Advisory: AI triage summary posted to the PR, not a blocker
      - 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 }}

W przypadku obrazów największą dźwignię daje skaner przed wdrożeniami, tak by naprawialna podatność krytyczna automatycznie blokowała merge. Trivy dostarcza utrzymywaną GitHub Action; zadaniem agenta jest wpiąć ją w twój pipeline i poprawnie ustawić bramkę.

Gotowy prompt: dodaj bramkę bezpieczeństwa do workflow wdrożeniowego

Add a security gate to our GitHub Actions deploy workflow. Use the
aquasecurity/trivy-action to scan the image we just built. Configure it to FAIL
the job on HIGH or CRITICAL findings with an available fix (ignore-unfixed: true
so we don't block on unfixable noise), upload results as SARIF to the Security
tab, and run before the deploy job. Show the full job YAML and explain the
exit-code and severity settings you chose.

Poprawna bramka wygląda mniej więcej tak — zwróć uwagę, że skanuje zbudowany obraz i wywala build, a nie tylko raportuje:

- name: Scan image with Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myorg/api:${{ github.sha }}
    severity: HIGH,CRITICAL
    ignore-unfixed: true
    exit-code: '1'        # fail the build on a fixable HIGH/CRITICAL
    format: sarif
    output: trivy.sarif

Wzorzec się uogólnia: skanowanie w CI w czasie budowania, ciągłe skanowanie rejestru dla obrazów już wdrożonych oraz polityka dopuszczania na klastrze, żeby podatny obraz nie mógł zostać zaplanowany, nawet jeśli prześlizgnie się przez CI.

Utwardzanie kontenerów i Kubernetes

Rzeczywisty przepływ pracy bezpieczeństwa kontenerów

Wyzwanie: twój zespół wdraża ponad 50 obrazów tygodniowo. Ręczny przegląd jest wąskim gardłem; niezeskanowane obrazy są ryzykiem. Rozwiązaniem są warstwowe, automatyczne bramki — i polityka dopuszczania używająca aktualnych API Kubernetes.

Użyj agenta, by:

1. Wpiąć Trivy do CI jako blokującą bramkę (prompt powyżej).
2. Włączyć ciągłe skanowanie rejestru dla już wdrożonych obrazów.
3. Egzekwować Pod Security Standards na klastrze przez Pod Security Admission (wbudowanego następcę usuniętego PodSecurityPolicy) albo silnik polityk w rodzaju Kyverno / OPA Gatekeeper dla bogatszych reguł.
4. Audytować działające obciążenia względem CIS Kubernetes Benchmark.

PodSecurityPolicy (policy/v1beta1) zostało usunięte w Kubernetes 1.25 i nie istnieje na żadnym wspieranym klastrze — każdy przewodnik, który wciąż każe ci „wdrożyć pod security policies”, jest nieaktualny. Aktualnym wbudowanym mechanizmem jest Pod Security Admission poprzez etykiety przestrzeni nazw, egzekwujący trzy Pod Security Standards (privileged / baseline / restricted), w parze z NetworkPolicy do izolacji ruchu.

# namespace with Pod Security Standards enforced (replaces 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
---
# default-deny egress/ingress, then allow only what's needed
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 }

Dwa prompty pokrywają dwie sytuacje, w których faktycznie się znajdziesz. Pierwszy dotyczy jednej przestrzeni nazw, której ruch już znasz — produkuje manifesty gotowe do zastosowania od razu. Drugi to plan dla całego klastra, wraz z decyzją o RBAC i silniku polityk, którą pierwszy pomija.

Gotowy prompt: aktualna polityka dopuszczania dla jednej przestrzeni nazw

Generate Kubernetes manifests to harden the `payments` namespace for a 1.36
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).

Gotowy prompt: plan utwardzania całego klastra

Harden our EKS cluster (Kubernetes 1.36). Produce, with YAML I can apply:
1. Pod Security Admission labels enforcing the `restricted` standard on
   application namespaces (NOT PodSecurityPolicy — it's removed).
2. NetworkPolicies for default-deny plus the specific allows our services need.
3. RBAC with least-privilege ServiceAccounts.
4. A short note on whether Kyverno would buy us anything beyond PSA for our case.

For each manifest, add a one-line comment explaining what it blocks. Flag
anything that would break existing workloads on apply.

Uwaga

Standard restricted odrzuca sporo powszechnych, ale niechlujnych obciążeń (kontenery na roocie, montowania hosta, brak seccompProfile). Wdrażaj go najpierw w trybie warn/audit, przeczytaj, co zostałoby odrzucone, napraw obciążenia, a dopiero potem przełącz na enforce. Przejście od razu na enforce na żywej przestrzeni nazw to sposób, by zablokować sobie własne wdrożenia.

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

Kilka źródeł danych bezpieczeństwa warto podłączyć jako serwery MCP, by agent mógł odpytywać żywą postawę chmury zamiast pracować na nieaktualnym eksporcie. Serwer (command, args, env) jest wszędzie taki sam — różni się tylko plik konfiguracyjny i jego format: Cursor i Claude Code (.mcp.json) używają kształtu JSON mcpServers, podczas gdy Codex (~/.codex/config.toml) wyraża te same pola jako tabelę TOML [mcp_servers.<name>].

Postawa bezpieczeństwa AWS — pakiet aws-security-mcp (prawdziwy, w npm) udostępnia odkrycia Security Hub, GuardDuty i IAM:

{
  "mcpServers": {
    "aws-security": {
      "command": "npx",
      "args": ["-y", "aws-security-mcp"],
      "env": {
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

Ten sam serwer w ~/.codex/config.toml Codeksa — identyczne pola, składnia TOML:

[mcp_servers.aws-security]
command = "npx"
args = ["-y", "aws-security-mcp"]

[mcp_servers.aws-security.env]
AWS_REGION = "us-east-1"

Nie wpisuj AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY na sztywno w konfiguracji, którą możesz zacommitować. Pozwól serwerowi pobrać poświadczenia ze standardowego łańcucha AWS — przyjętej roli IAM, SSO lub ~/.aws/credentials — dokładnie tak, jak robi to AWS CLI.

Postawa bezpieczeństwa Azure — firmowy serwer Microsoftu @azure/mcp obejmuje Defender for Cloud i zapytania o zasoby:

{
  "mcpServers": {
    "azure": {
      "command": "npx",
      "args": ["-y", "@azure/mcp@latest", "server", "start"],
      "env": {
        "AZURE_SUBSCRIPTION_ID": "your-subscription-id",
        "AZURE_TENANT_ID": "your-tenant-id"
      }
    }
  }
}

Serwer GitHub MCP (github/github-mcp-server, zdalnie pod https://api.githubcopilot.com/mcp/) to trwałe połączenie dla połowy naprawczej: pozwala agentowi przeszukiwać kod w całej organizacji, czytać alerty Dependabota i skanowania sekretów oraz otwierać PR. Sięgaj po niego, gdy agent musi wielokrotnie działać na GitHubie. Nie istnieje pakiet @anthropic/* ani jednostringowe new MCPClient('github') — MCP to connect(transport), a potem callTool({ name, arguments }), a jeśli skryptujesz bezpośrednio na SDK, pakiet to @modelcontextprotocol/sdk, a klient mieszka pod @modelcontextprotocol/sdk/client/index.js.

Po stronie umiejętności umiejętność Semgrep (semgrep/skills, instalowana przez npx skills add semgrep/skills) to lżejsza opcja: uczy agenta pisać własne reguły Semgrep dla twojego kodu i uruchamiać skany, bez stawiania serwera.

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, AWS Security Hub). Gdy istnieją oba, umiejętność jest szybsza w instalacji, a serwer jest głębszy.

Nie istnieje kanoniczny trivy-mcp-server w npm, a snyk-agent-scan (dawniej mcp-scan) nie jest skanerem kontenerów — to narzędzie higieny dla twojej własnej konfiguracji MCP. Skanowanie kontenerów zostaw na CLI Trivy / GitHub Action, a każdą deklarację „MCP do bezpieczeństwa kontenerów” traktuj jako coś do zweryfikowania, zanim to wkleisz.

Przeskanuj własną konfigurację MCP

Jeśli dodajesz serwery MCP do przepływu bezpieczeństwa, zaudytuj je. snyk-agent-scan (uruchamiany przez uvx) statycznie sprawdza zainstalowane serwery MCP pod kątem prompt injection, zatruwania narzędzi i ataków typu rug-pull — ryzyk łańcucha dostaw specyficznych dla MCP. To dawny mcp-scan od Invariant Labs, przemianowany po przejęciu Invariant Labs przez Snyk w czerwcu 2025; stary pakiet mcp-scan w PyPI jest teraz tylko przekierowaniem, które instaluje i przekazuje do snyk-agent-scan, więc używaj kanonicznej nazwy:

# Scan all installed MCP server configs for malicious tool descriptions
uvx snyk-agent-scan@latest scan

# Inspect the exact tool descriptions your model is being fed
uvx snyk-agent-scan@latest inspect

To prawdziwa, aktualna komenda — i naprawdę dobry nawyk, gdy zaczynasz zależeć od zewnętrznych serwerów MCP w danych bezpieczeństwa.

Dowody zgodności: SOC 2 i GDPR

Zgodność to w większości składanie dowodów, a to dokładnie ten rodzaj ustrukturyzowanej pracy zestawieniowej, w której agent jest dobry — pod warunkiem, że skierujesz go na prawdziwe artefakty (logi dostępu, IaC, eksporty konfiguracji), zamiast prosić o stwierdzenie zgodności z niczego.

Cursor

Wrzuć do kontekstu eksport z przeglądu dostępów i IaC, podłącz @aws-security dla żywej konfiguracji i poproś o pakiet dowodów zmapowany na konkretne mechanizmy kontrolne.

Using `access-review.csv` (our quarterly IAM export) and the Terraform in
`infra/`, draft a SOC 2 evidence package for controls CC6.1 (logical access),
CC6.3 (network access), and CC8.1 (change management). For each control: cite
the specific file/line or log entry that demonstrates it, and flag any control
where the evidence is missing or weak. Do NOT claim a control is satisfied
without pointing to the artifact that proves it.

Claude Code

Claude Code potrafi przeczytać repozytorium, uruchomić git log po dowody zarządzania zmianami i złożyć pakiet w jednym przebiegu.

Map our personal-data flows for a GDPR Article 30 record. Search the codebase
and `infra/` for: where PII is collected, which datastores hold it (grep for
schema/migrations), where it crosses a service or third-party boundary (Stripe,
SendGrid, analytics), and where retention/deletion is implemented. Output a
table of data category -> store -> lawful basis (mark "UNKNOWN — needs legal
review" if not evident) -> retention. Be explicit about gaps; do not invent a
lawful basis.

Codex

Użyj Codeksa z piaskownicą tylko do odczytu do przebiegu dowodowego — ma czytać i raportować, a nie modyfikować infrastrukturę.

codex --sandbox read-only "Assemble SOC 2 CC6.1 access-control evidence from access-review.csv and infra/"

Potem poproś o raport luk, bo to ta część, na której audytor faktycznie działa:

Read `access-review.csv` and `infra/`. For SOC 2 CC6.1/CC6.3/CC8.1, produce a
gap report: control, current evidence (with file/log citation), and the single
most important gap to close. Rank gaps by audit risk. Flag any control with no
supporting artifact as a blocker.

Dyscyplina, która czyni to wiarygodnym: każda teza „spełnione” musi cytować prawdziwy artefakt. Pakiet dowodów zmyślony przez agenta polegnie w chwili, gdy audytor poprosi o źródłowy log — więc jawnie promptuj o cytaty i oznaczanie luk, jak wyżej.

Kiedy automatyzacja bezpieczeństwa z AI się psuje

Uwaga

Burze fałszywych alarmów. semgrep --config=auto jest celowo szeroki, a skanery kontenerów oznaczają setki „krytycznych”, które są nieosiągalnymi zależnościami tranzytywnymi albo nienaprawialnym szumem obrazu bazowego. Przypnij ukierunkowane zestawy reguł dla swojego stosu (--config=p/owasp-top-ten --config=p/javascript), używaj ignore-unfixed tam, gdzie to zasadne, i podaj agentowi kontekst projektu („to jest API w Expressie; req.params to jedyne niezaufane źródło”), aby poprawnie obniżał szum. Wymuś potwierdzenie osiągalności, zanim cokolwiek nazwie P0 — inaczej zautomatyzowałeś zmęczenie alertami.

Uwaga

Awarie uwierzytelnienia skanera lub chmury wyglądają jak czyste konto. Jeśli triage wraca podejrzanie pusty, serwer MCP albo CLI prawdopodobnie nie zdołał się uwierzytelnić (wygasłe SSO, zły region, brakująca rola) i nie zwrócił nic. Zweryfikuj, że narzędzie działa samodzielnie (aws sts get-caller-identity, trivy image …), zanim zaufasz podsumowaniu agenta.

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 i 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 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

Zablokowanie się przez kontroler dopuszczania. Przełączenie Pod Security Admission od razu na enforce: restricted albo zastosowanie zbyt szerokiej polityki Kyverno potrafi zablokować twoje własne wdrożenia, a nawet systemowe pody klastra. Wdrażaj etapami z warn/audit, wyłącz kube-system i przetestuj najpierw na jednej przestrzeni nazw.

Uwaga

Zmyślone CVE, dowody i API. Największym pojedynczym ryzykiem jest agent pewnie cytujący numer CVE, wynik CVSS lub artefakt zgodności, który nie istnieje — albo wywołujący w wygenerowanym SQL funkcję bazy, której nie ma, jak ai_classify_pii() czy ai_sensitivity_score(). Klasyfikacja PII odbywa się w kodzie aplikacji wywołującym prawdziwe API modelu albo przez dedykowany skaner, nigdy jako wbudowany SQL. Nigdy nie akceptuj odkrycia, którego nie możesz wyśledzić do wyniku skanera lub prawdziwego artefaktu, i uczyń z „zacytuj źródło albo oznacz jako nieznane” stałą instrukcję w każdym prompcie bezpieczeństwa.

Uwaga

Ryzyko łańcucha dostaw MCP. Złośliwy zewnętrzny serwer MCP potrafi zatruć kontekst agenta. Uruchom uvx snyk-agent-scan@latest scan po dodaniu każdego serwera i przypnij wersje.

Dokąd dalej z operacjami bezpieczeństwa

Automatyzacja zgodności z AI Zamień zbieranie dowodów SOC 2 i GDPR w powtarzalny przepływ pracy napędzany przez AI.

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

Eksploatacja: etap wdrożeniowy Gdzie bramkowanie bezpieczeństwa mieści się w szerszym pipelinie wdrożeń i utrzymania.

Ekosystem MCP Jak bezpiecznie podłączać, zawężać i audytować serwery MCP.

Pipeline'y CI/CD Budowa pipeline'u, w który wpina się twoja bramka bezpieczeństwa.

Optymalizacja kosztów chmury Trzymaj pętlę skan-i-triage tanio dzięki routingowi modeli i limitom tokenów.