Automatyzacja operacji bezpieczeństwa

Twój skaner właśnie oznaczył 412 “krytycznych” odkryć w 50 obrazach kontenerów, kanał on-call płonie, a audytor SOC 2 chce dowodów z przeglądu dostępów na piątek. Odkrycia są prawdziwe, ale większość to szum — i nie masz szybkiego sposobu, by stwierdzić, które trzy naprawdę mają znaczenie. To tutaj agent AI podłączony do Twoich prawdziwych narzędzi bezpieczeństwa zarabia na siebie: nie wymyślając magii, lecz czytając wyniki skanera, korelując je z Twoim kodem i tworząc dowody, które inaczej składałbyś ręcznie.

Co z tego wyniesiesz

• Wzorzec przekazywania prawdziwych wyników skanera (Trivy, Twoje narzędzie bezpieczeństwa chmury) do Cursor, Claude Code lub Codex, tak by to agent robił triage zamiast Ciebie.
• Zweryfikowane konfiguracje MCP dla danych bezpieczeństwa AWS i Azure plus jeden skaner higieny MCP, który naprawdę warto uruchamiać.
• Gotowe do wklejenia prompty do triage podatności, potoku CI bramkowanego bezpieczeństwem oraz tworzenia dowodów SOC 2 / GDPR.
• Prompt do utwardzania Kubernetes, który używa aktualnych API (Pod Security Admission, nie usuniętego PodSecurityPolicy).
• Trzeźwa lista “kiedy to się psuje”, ż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. Trwały wzorzec wygląda tak: deterministyczne narzędzie produkuje wynik czytelny maszynowo, a agent rozumuje nad tym wynikiem — priorytetyzując według możliwości wykorzystania, mapując odkrycie na dokładną linię w Twoim repo i tworząc poprawkę lub dowód.

# Trivy to prawdziwe CLI. Zeskanuj obraz do JSON, a potem przekaż JSON agentowi.
trivy image --severity HIGH,CRITICAL --format json -o scan.json myorg/api:latest

Ten scan.json to wejście, w którym agent jest naprawdę dobry. Wszystko poniżej buduje na tym kształcie: uruchom prawdziwe narzędzie, a potem promptuj agenta nad jego wynikiem.

Serwery MCP dla kontekstu bezpieczeństwa

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 pokazanego poniżej, 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 na sztywno AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY jako literałów 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 — tak samo jak robi to AWS CLI.

Postawa bezpieczeństwa Azure — serwer first-party Microsoftu @azure/mcp obejmuje Defender for Cloud oraz 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"
      }
    }
  }
}

Notatka

Nie ma kanonicznego 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. Trzymaj skanowanie kontenerów na CLI Trivy / GitHub Action (pokazane poniżej) i każdą deklarację o “MCP do bezpieczeństwa kontenerów” traktuj jako coś do zweryfikowania, zanim to wkleisz.

Zeskanuj samą swoją konfigurację MCP

Jeśli dodajesz serwery MCP do przepływu bezpieczeństwa, audytuj je. snyk-agent-scan (uruchamiany przez uvx) statycznie sprawdza Twoje zainstalowane serwery MCP pod kątem prompt injection, tool poisoning i ataków rug-pull — ryzyk łańcucha dostaw specyficznych dla MCP. To dawne mcp-scan Invariant Labs, przemianowane po przejęciu Invariant Labs przez Snyk w czerwcu 2025; stary pakiet mcp-scan w PyPI jest teraz tylko przekierowującym shimem, który instaluje i przekazuje do snyk-agent-scan, więc używaj nazwy kanonicznej:

# Zeskanuj wszystkie zainstalowane konfiguracje serwerów MCP pod kątem złośliwych opisów narzędzi
uvx snyk-agent-scan@latest scan

# Sprawdź dokładne opisy narzędzi, którymi karmiony jest Twój model
uvx snyk-agent-scan@latest inspect

To prawdziwe, aktualne polecenie — i naprawdę dobry nawyk, gdy już zależysz od zewnętrznych serwerów MCP dla danych bezpieczeństwa.

Triage podatności: od 412 odkryć do 3, które mają znaczenie

Uruchom skaner, a potem pozwól agentowi zrobić priorytetyzację, przez którą człowiek inaczej musiałby się przemęczyć. Agent czyta JSON, sprawdza krzyżowo Twój kod, by ustalić, czy podatna ścieżka jest faktycznie osiągalna, i porządkuje według realnej możliwości wykorzystania, a nie surowego CVSS.

Cursor

Otwórz repo, wrzuć scan.json do kontekstu Composera i uruchom prompt triage. Przy podłączonym serwerze MCP @aws-security dodaj @aws-security, by sprawdził, czy dotknięta usługa jest faktycznie wystawiona do internetu.

Wskazówka

Gotowy do wklejenia prompt do triage podatności:

Read scan.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.

Claude Code

Z roota repozytorium przekaż wynik skanera jako kontekst. Claude Code może sam uruchomić grep/rg, by potwierdzić osiągalność, co czyni jego priorytetyzację konkretną, a nie zgadywaną.

claude "Read scan.json and the codebase, then triage the HIGH/CRITICAL findings"

Wskazówka

Gotowy do wklejenia prompt do jednorazowego raportu triage (headless, np. w CI):

claude -p "Read scan.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 > triage.json

Codex

Uruchom wewnątrz TUI Codeksa, by móc przejrzeć każde polecenie, zanim się wykona. Codex domyślnie działa w sandboksie; trzymaj zatwierdzenia włączone dla wszystkiego, co dotyka poświadczeń lub API chmury.

codex "Read scan.json and triage the HIGH/CRITICAL findings against our source"

Wskazówka

Gotowy do wklejenia prompt do Codeksa z jawną recenzją per akcja:

Uruchom z codex -a untrusted (pyta przed każdą akcją), a potem wklej:

Read scan.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.

Jak wygląda dobry wynik — prawdziwe, osiągalne odkrycie, a nie zmyślone:

P0 — CVE-2026-42945 (nginx, ngx_http_rewrite_module heap overflow, CVSS 9.2). Dotknięte: obraz bazowy nginx:1.30.0 w 3 usługach. Osiągalne: tak — wszystkie trzy używają dyrektyw rewrite. Wystawione do internetu: tak (edge ingress). Poprawka: przebuduj na nginx:1.31.0 (lub 1.30.1), który dostarcza łatkę. Załataj w ciągu 24h.

To CVE jest prawdziwe (wprowadzone w 2008, ujawnione w 2026, naprawione w nginx 1.31.0 / 1.30.1) — używaj weryfikowalnych odkryć w pracy nad bezpieczeństwem; nigdy nie pozwól, by agent przedstawiał wymyślony numer CVE jako fakt.

Potok CI bramkowany bezpieczeństwem

Ruchem o najwyższej dźwigni jest postawienie skanera przed wdrożeniami, tak by krytyczna podatność automatycznie blokowała merge. Trivy dostarcza utrzymywaną GitHub Action; zadaniem agenta jest podłączyć ją do Twojego potoku i poprawnie ustawić bramkę.

Wskazówka

Gotowy do wklejenia prompt do potoku bramkowanego bezpieczeństwem:

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 podczas budowania w CI, plus ciągłe skanowanie rejestru dla już wdrożonych obrazów, plus polityka dopuszczenia na poziomie klastra (następna sekcja), tak by podatny obraz nie mógł zostać zaplanowany, nawet jeśli prześlizgnie się przez CI.

Utwardzanie kontenerów i Kubernetes

Przepływ bezpieczeństwa kontenerów z prawdziwego świata

Wyzwanie: Twój zespół wdraża 50+ obrazów tygodniowo. Ręczny przegląd to wąskie gardło; niezeskanowane obrazy to ryzyko. Rozwiązaniem są warstwowe, zautomatyzowane bramki — oraz polityka dopuszczenia używająca aktualnych API Kubernetes.

Użyj agenta, by:

1. Podłączyć Trivy do CI jako bramkę blokującą (prompt powyżej).
2. Włączyć ciągłe skanowanie rejestru dla już wdrożonych obrazów.
3. Wymusić Pod Security Standards na poziomie klastra przez Pod Security Admission (wbudowanego następcę usuniętego PodSecurityPolicy) lub silnik polityk jak Kyverno / OPA Gatekeeper dla bogatszych reguł.
4. Audytować żywe workloady względem CIS Kubernetes Benchmark.

PodSecurityPolicy zostało usunięte w Kubernetes 1.25 — każdy przewodnik wciąż każący Ci “wdrożyć pod security policies” jest nieaktualny. Aktualnym wbudowanym mechanizmem jest Pod Security Admission egzekwujący trzy Pod Security Standards (privileged / baseline / restricted).

Wskazówka

Gotowy do wklejenia prompt do utwardzania Kubernetes:

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

Pod Security Standard restricted odrzuca sporo powszechnych-ale-niechlujnych workloadów (kontenery root, montowania hosta, brak seccompProfile). Wdrażaj go najpierw w trybie warn/audit, przeczytaj, co zostałoby odrzucone, napraw workloady, a dopiero potem przełącz na enforce. Przejście od razu na enforce na żywym namespace to sposób, by zablokować się przed własnymi wdrożeniami.

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 zestawiającej, w której agent jest dobry — pod warunkiem, że skierujesz go na prawdziwe artefakty (logi dostępu, IaC, eksporty konfiguracji), zamiast prosić, by stwierdził zgodność z niczego.

Cursor

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

Wskazówka

Gotowy do wklejenia prompt do tworzenia dowodów SOC 2:

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 może przeczytać repo, uruchomić git log dla dowodów zarządzania zmianami i złożyć pakiet w jednym przebiegu.

Wskazówka

Gotowy do wklejenia prompt do mapowania przepływów danych GDPR:

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 sandboksem tylko do odczytu na przebieg dowodowy — powinien czytać i raportować, a nie modyfikować infrastruktury.

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

Wskazówka

Gotowy do wklejenia prompt do raportu luk zgodności:

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 deklaracja “spełnione” musi cytować prawdziwy artefakt. Pakiet dowodów, który agent zmyślił, polegnie w momencie, gdy audytor poprosi o pokazanie leżącego u podstaw logu — więc promptuj jawnie o cytowania i oznaczanie luk, jak powyżej.

Kiedy to się psuje

• Burze fałszywych alarmów. Skanery oznaczają setki “krytycznych”, które są nieosiągalnymi zależnościami tranzytywnymi lub nienaprawialnym szumem obrazu bazowego. Zawsze przekazuj ignore-unfixed tam, gdzie ma to sens, i każ agentowi potwierdzić osiągalność, zanim nazwie coś P0 — inaczej zautomatyzowałeś zmęczenie alertami.
• Awarie uwierzytelniania skanera / chmury. Jeśli triage agenta wygląda podejrzanie pusto, serwer MCP lub CLI prawdopodobnie nie uwierzytelnił się (wygasłe SSO, zły region, brakująca rola) i nic nie zwrócił. Zweryfikuj, że leżące u podstaw narzędzie działa samodzielnie (aws sts get-caller-identity, trivy image …), zanim zaufasz podsumowaniu agenta.
• Zablokowanie przez admission controller. Przełączenie Pod Security Admission od razu na enforce: restricted lub zbyt szeroka polityka Kyverno może zablokować Twoje własne wdrożenia, a nawet pody systemowe klastra. Wdrażaj etapowo z warn/audit, wyklucz kube-system i testuj najpierw na jednym namespace.
• Zmyślone CVE lub dowody. Największe pojedyncze ryzyko: agent pewnie cytujący numer CVE, wynik CVSS lub artefakt zgodności, który nie istnieje. Nigdy nie akceptuj odkrycia, którego nie możesz prześledzić do wyniku skanera lub prawdziwego artefaktu. Uczyń z “cytuj źródło albo oznacz jako nieznane” stałą instrukcję w każdym promptcie bezpieczeństwa.
• Ryzyko łańcucha dostaw MCP. Złośliwy zewnętrzny serwer MCP może zatruć kontekst agenta. Uruchamiaj uvx snyk-agent-scan@latest scan po dodaniu dowolnego serwera i przypinaj wersje.

Co dalej

• Przegląd operacji wdrożeniowych — gdzie bramkowanie bezpieczeństwem mieści się w szerszym potoku wdrożeniowym.
• Ekosystem MCP — jak bezpiecznie podłączać, ograniczać zakres i audytować serwery MCP.
• Automatyzacja potoków z AI — budowanie potoku, do którego podłącza się Twoja bramka bezpieczeństwa.