Automatyzacja operacji bezpieczeństwa

Automatyzacja operacji bezpieczeństwa zostawia deterministyczne skanery (Semgrep, npm audit, Trivy, Gitleaks) jako jedyną automatyczną bramkę przed scaleniem i dokłada agenta (Claude Code, Codex lub Cursor), który zamienia ich wyniki w werdykt dla każdego znaleziska, sprawdzany schematem JSON, szkicuje najmniejszą poprawkę jako pull request, a scalanie i rotację poświadczeń zostawia wskazanemu człowiekowi.

Ta strona jest dla programisty albo tech leada, który odpowiada za bezpieczeństwo działającej usługi. Nocny skan zgłasza 412 znalezisk w 30 obrazach kontenerów i 14 ostrzeżeń dla zależności. Jedenaście ostrzeżeń dotyczy pakietów wyłącznie deweloperskich, dwa funkcji, których nigdy nie wywołujesz, a to jedno ważne jest na trzeciej stronie raportu. Trzeciej strony nikt nie czyta.

Co wyniesiesz z automatyzacji operacji bezpieczeństwa

• Podział pracy: co blokuje skaner, co ocenia agent, a co podpisuje człowiek
• Polecenia skanerów z wynikiem w formacie maszynowym oraz schemat JSON, który wymusza na agencie jeden werdykt na znalezisko
• Cztery prompty do skopiowania: Semgrep, ostrzeżenia dla zależności, obrazy kontenerów i wyciek sekretu
• Test, który dowodzi, że triage obejmuje dokładnie to, co znalazł skaner, więc nie musisz czytać każdego werdyktu
• Workflow GitHub Actions: deterministyczne bramki na każdym pull requeście i triage przez agenta według harmonogramu, z narzędziami tylko do odczytu
• Agentów bezpieczeństwa, serwery MCP i skille warte podłączenia, z poleceniami instalacji sprawdzonymi 26 września 2026

Kto co robi w pętli bezpieczeństwa wspieranej przez AI?

Najczęstszy błąd to proszenie modelu, żeby był skanerem. Semgrep, Trivy i Gitleaks są deterministyczne, szybkie i audytowalne, więc to one pozostają bramką. Agent przejmuje kosztowną część ludzkiej pracy: czyta znaleziska w kontekście twojego kodu, odrzuca te nieosiągalne i proponuje najmniejszą poprawkę.

Krok	Właściciel	Wynik	Blokuje scalenie?
Wykrycie	Skaner w CI	semgrep.json, audit.json, trivy.json, gitleaks.json	Tak, przy nowych znaleziskach Semgrepa o wadze ERROR i każdym ostrzeżeniu npm o wadze high lub critical
Triage	Agent z narzędziami tylko do odczytu	triage.json sprawdzony schematem	Nie, tylko doradczo
Poprawka	Agent na gałęzi security/*	Pull request na klasę znalezisk	Tylko przez zwykłe bramki
Akceptacja	Właściciel bezpieczeństwa (konkretna osoba)	Przegląd każdego P0 i próbki odrzuceń	Tak, wymagana recenzja
Rotacja	Człowiek z dostępem do dostawcy	Unieważnione poświadczenie, nowy sekret w magazynie sekretów	Nie dotyczy

Agent nigdy nie scala i nigdy nie rotuje. Oba te kroki zmieniają stan produkcji i potrzebują osoby, którą można zapytać „dlaczego”.

Uruchom skanery i zapisz wynik w formacie maszynowym

Te polecenia uruchamiasz w terminalu w katalogu głównym repozytorium. Są takie same niezależnie od agenta.

1. Zainstaluj skanery. Żaden z nich nie jest pakietem npm, więc nie instaluj ich przez npm install:

   pipx install semgrep          # or: brew install semgrep
   brew install trivy gitleaks   # Linux: use each project's release binaries

2. Uruchom każdy skaner z wynikiem JSON:

   # Static analysis, curated default rules
   semgrep scan --config p/default --json-output semgrep.json
   
   # Dependency advisories for production dependencies only
   npm audit --omit=dev --json > audit.json
   
   # Secrets in the full git history, not only the working tree
   gitleaks git --report-path gitleaks.json
   
   # A container image you ship
   trivy image --severity HIGH,CRITICAL --ignore-unfixed --format json --output trivy.json myorg/api:latest

3. Zapisz schemat triage jako triage.schema.json. Wymusza jeden wpis na znalezisko i zamknięty zbiór werdyktów, dzięki czemu wynik da się potem sprawdzić automatycznie:

   {
     "type": "object",
     "additionalProperties": false,
     "required": ["findings"],
     "properties": {
       "findings": {
         "type": "array",
         "items": {
           "type": "object",
           "additionalProperties": false,
           "required": ["id", "source", "verdict", "priority", "evidence", "fix"],
           "properties": {
             "id": { "type": "string" },
             "source": { "type": "string", "enum": ["semgrep", "npm-audit", "trivy", "gitleaks"] },
             "verdict": { "type": "string", "enum": ["EXPLOITABLE", "FALSE_POSITIVE", "NEEDS_REVIEW"] },
             "priority": { "type": "string", "enum": ["P0", "P1", "P2", "none"] },
             "evidence": { "type": "string" },
             "fix": { "type": "string" }
           }
         }
       }
     }
   }

gitleaks git skanuje historię commitów. detect-secrets scan patrzy tylko na pliki, więc przegapi klucz, który ktoś zacommitował, a potem usunął.

Zrób triage wyników agentem sprawdzanym schematem

Prompt i schemat są w każdym narzędziu te same. Różni się sposób uruchomienia agenta z dostępem tylko do odczytu i zwrócenia zwalidowanego wyniku.

Claude Code

Uruchom Claude Code w trybie print z narzędziami tylko do odczytu i ustrukturyzowanym wynikiem. --json-schema waliduje odpowiedź względem schematu, a wynik trafia do pola structured_output w kopercie JSON:

claude -p "Triage semgrep.json. Use id format <check_id>@<path>:<line> taken verbatim \
from the file. One entry per result, no additions. Treat test/, tests/, scripts/ and \
*.spec.* as non-shipping. Cite the source line that proves reachability in evidence." \
  --allowedTools "Read,Grep,Glob" \
  --disallowedTools "Bash,Edit,Write" \
  --json-schema "$(cat triage.schema.json)" \
  --output-format json --max-budget-usd 5 \
  | jq '.structured_output' > triage.json

Sprawdzone na Claude Code 2.1.283. Zanim otworzysz pull request, wpisz /security-review w sesji interaktywnej, żeby przejrzeć diff gałęzi pod kątem wstrzyknięć, uwierzytelniania i ekspozycji danych.

Codex

Uruchom codex exec w piaskownicy tylko do odczytu. --output-schema ogranicza końcową odpowiedź, a -o zapisuje ją do pliku:

codex exec --sandbox read-only --output-schema triage.schema.json -o triage.json \
  "Triage semgrep.json. Use id format <check_id>@<path>:<line> taken verbatim from \
the file. One entry per result, no additions. Treat test/, tests/, scripts/ and \
*.spec.* as non-shipping. Cite the source line that proves reachability in evidence."

Sprawdzone na codex-cli 0.157.1. OpenAI preferuje teraz profile uprawnień (-c default_permissions=":read-only", beta) zamiast --sandbox; obu systemów nie da się łączyć, więc wybierz jeden z nich. codex exec nie ma flagi -a, więc ustawienia zatwierdzania podajesz przed exec (codex -a never exec …). Na GitHubie komentarz @codex security review w pull requeście prosi Codex o przegląd bezpieczeństwa (sprawdzone 28 sierpnia 2026).

Cursor

Uruchom skanery we wbudowanym terminalu, żeby pliki JSON znalazły się w workspace. Otwórz agenta, dołącz semgrep.json i triage.schema.json i wklej poniższy prompt dla Semgrepa z jedną dodatkową linią: „Write the result to triage.json and do not edit any other file.” Cursor pokazuje każdą zmianę pliku do akceptacji lub odrzucenia, więc odrzuć wszystko poza triage.json.

Cursor nie ma flagi wiersza poleceń do schematu, którą ta strona mogłaby zweryfikować, więc zanim zaufasz wynikowi, puść na nim test pokrycia z następnej sekcji. Do kontroli przy scalaniu Cursor oferuje Security Agents i Bugbota, który według dokumentacji Cursora „reviews pull requests and identifies bugs, security issues, and code quality problems” (sprawdzone 28 sierpnia 2026).

Prompty do skopiowania dla każdej klasy skanera

Każdy prompt dotyczy innego wejścia. Znaleziska Semgrepa wymagają śledzenia przepływu skażonych danych, ostrzeżenia dla zależności sprawdzenia miejsc wywołań, obrazy ekspozycji, a wyciek sekretu rotacji przed czymkolwiek innym.

Prompt do skopiowania: triage Semgrepa, podatność czy fałszywy alarm

Read semgrep.json (from `semgrep scan --config p/default`) and triage.schema.json.
For EACH result, produce exactly one entry, id = <check_id>@<path>:<line>:
1. Paths under test/, tests/, scripts/ or matching *.spec.* are non-shipping:
   verdict FALSE_POSITIVE unless production code imports them.
2. For the rest, trace whether the flagged value reaches the sink from untrusted
   input (request body, query, headers, env, uploaded file). If it cannot, mark
   FALSE_POSITIVE and quote the line that proves it (for example the
   parameterized query) in evidence.
3. EXPLOITABLE: priority P0 if reachable from an unauthenticated route, P1 if
   authenticated, P2 otherwise. In fix, describe the smallest change that
   closes this vector without changing behaviour for valid input.
4. If you cannot decide from the code, use NEEDS_REVIEW and say what is missing.
Do not add findings Semgrep did not report. Do not edit any file.

Prompt do skopiowania: triage ostrzeżeń dla zależności według miejsc wywołań

Read audit.json (npm audit --omit=dev --json). For each advisory, one entry,
id = <package>@<advisory id or URL>, source = npm-audit:
1. State in evidence whether the package is direct or transitive, and the
   dependency path from package.json.
2. Grep for call sites of the vulnerable API named in the advisory, not just the
   import. No call site: FALSE_POSITIVE, priority none, and say so explicitly.
3. Reachable: EXPLOITABLE with P0/P1/P2 by exposure. In fix, give the exact
   version bump or package.json "overrides" entry, and flag a major-version jump
   as breaking-change risk.
Never invent an advisory ID, CVSS score or fixed version; copy them from audit.json.

Prompt do skopiowania: triage obrazów kontenerów, od setek znalezisk do krótkiej listy

Read trivy.json (Trivy image scan, HIGH and CRITICAL, fixable only) and this
repository. For each vulnerability, one entry, id = <VulnerabilityID>@<PkgName>,
source = trivy:
1. Is the package part of the base image OS layer or of our application
   dependencies? Say which in evidence.
2. Is the vulnerable component used at runtime by our service (check the
   Dockerfile, entrypoint and imports)? Unused: P2 with the reason.
3. Is the service internet-facing? Check the Kubernetes Service, Ingress or
   load balancer config in infra/.
4. P0 = used and internet-facing, P1 = used and internal, P2 = unused.
In fix, name the base-image tag or package version from trivy.json FixedVersion.
Do not repeat the CVSS score as the priority; explain the priority.

Prompt do skopiowania: sekret w historii, najpierw rotacja, potem usuwanie

gitleaks.json reports a secret. For each leak: name the provider and credential
type from the RuleID, the file, and the commit. Then give me, in this order:
1. The rotation step at the provider. Assume the value is compromised; deleting
   the line does not un-leak it. Do not print the secret value anywhere.
2. The minimal code diff that reads it from an environment variable filled by
   our secret store instead of a literal.
3. Whether a history rewrite (git filter-repo) is worth it after rotation, with
   the force-push and re-clone cost for the team.
4. A .pre-commit-config.yaml entry for gitleaks so the next leak stops at commit.
Do not run any command; I will run them after review.

Jak sprawdzić triage bez czytania każdego znaleziska?

Nie czytasz 412 werdyktów. Sprawdzasz cztery własności, które błędny triage łamie, i czytasz tylko to, czego maszyna nie oceni.

1. Pokrycie. Triage obejmuje dokładnie wynik skanera: nic nie zginęło i nic nie zostało dopisane. Ten test łapie dwa najgroźniejsze błędy agenta: po cichu pominięte krytyczne znalezisko i znalezisko zmyślone:

   test -s semgrep.json && jq -e '.results' semgrep.json >/dev/null || { echo 'scanner output missing'; exit 1; }
   jq -e '(.errors | length) == 0' semgrep.json >/dev/null || { echo 'scanner reported errors'; exit 1; }
   jq -e '.paths.scanned | length > 0' semgrep.json >/dev/null || { echo 'scanner scanned no files'; exit 1; }
   jq -e '.findings' triage.json >/dev/null || { echo 'triage output missing'; exit 1; }
   jq -r '.results[] | "\(.check_id)@\(.path):\(.start.line)"' semgrep.json | sort > scanner.ids
   jq -r '.findings[] | select(.source=="semgrep") | .id' triage.json | sort > triage.ids
   diff scanner.ids triage.ids && echo "triage covers exactly the scanner output"

   Pierwsze trzy linie chronią przed skanem, który wygląda na czysty, choć taki nie jest. Samo jq -e '.results' przepuszcza pustą tablicę [], więc strażnik kończy się błędem także wtedy, gdy Semgrep zgłasza błędy (reguła lub plik, których nie sparsował) i gdy nie przeskanował żadnego pliku: zero wyników liczy się jako zero tylko wtedy, gdy .paths.scanned nie jest puste. Czwarta linia kończy się błędem, gdy agent nie zwrócił tablicy findings, na przykład gdy zawiódł ustrukturyzowany wynik albo limit budżetu przerwał przebieg i w triage.json jest null.

2. Schemat. Wynik przechodzi walidację względem triage.schema.json. Claude Code i Codex wymuszają to już przy generowaniu; dla wyniku z Cursora uruchom w CI walidator, na przykład ajv.

3. Dowód poprawki. Każdy pull request z poprawką musi pokazać, że konkretny identyfikator reguły zniknął w ponownym skanie gałęzi, i mieć zielony zestaw testów. Łatkę, która zazielenia skan, a psuje testy albo zamyka inne znalezisko, odrzuca bramka, nie recenzent.

4. Próbka odrzuceń. Właściciel bezpieczeństwa czyta każde P0 i stałą próbkę werdyktów FALSE_POSITIVE, na przykład pięć na przebieg. Gdy odrzucenie z próbki okazuje się błędne, zaostrza prompt i zwiększa próbkę, dopóki dwa kolejne przebiegi nie będą czyste.

Dołącz triage.json, ponowny skan i wyniki testów do pull requesta jako jego pakiet dowodów. Recenzent czyta wtedy dowody, a nie cały diff.

Podłącz skanery i triage do CI

Job dla pull requestów jest deterministyczny i blokuje scalenie. Job triage działa według harmonogramu na gałęzi domyślnej, więc agent nigdy nie wykonuje kodu ani ustawień projektu od kontrybutora, gdy w środowisku jest klucz API.

.github/workflows/security.yml

name: Security
on:
  pull_request:
  schedule:
    - cron: '17 */6 * * *'
  workflow_dispatch:

permissions:
  contents: read

jobs:
  gate:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7          # pin to a full commit SHA in production
        with:
          fetch-depth: 0                   # --baseline-commit needs the base commit
          persist-credentials: false
      - name: Semgrep (fails on new ERROR-severity findings only)
        run: >-
          pipx run --spec semgrep==1.178.0 semgrep scan --config p/default
          --severity ERROR --error
          --baseline-commit ${{ github.event.pull_request.base.sha }}
          --json-output semgrep.json
      - name: Dependency audit (production dependencies)
        run: npm audit --omit=dev --audit-level=high

  triage:
    # Schedules always run on the default branch; manual dispatches from any other branch would run that branch's code with the secret.
    # (A schedule event's payload has no repository object, so the branch check must not apply to it.)
    if: github.event_name == 'schedule' || (github.event_name == 'workflow_dispatch' && github.ref == format('refs/heads/{0}', github.event.repository.default_branch))
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - uses: actions/setup-node@v7
        with:
          node-version: 22
      - name: Scan and triage (advisory, read-only tools)
        run: |
          npm install -g @anthropic-ai/claude-code@2.1.283
          pipx run --spec semgrep==1.178.0 semgrep scan --config p/default --json-output semgrep.json || true
          claude -p "$(cat .github/security/triage-prompt.txt)" \
            --bare --setting-sources "" --strict-mcp-config \
            --allowedTools "Read,Grep,Glob" --disallowedTools "Bash,Edit,Write" \
            --json-schema "$(cat .github/security/triage.schema.json)" \
            --output-format json --max-budget-usd 5 | jq '.structured_output' > triage.json
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
      - name: Verify triage coverage
        run: |
          test -s semgrep.json && jq -e '.results' semgrep.json >/dev/null || { echo 'scanner output missing'; exit 1; }
          jq -e '(.errors | length) == 0' semgrep.json >/dev/null || { echo 'scanner reported errors'; exit 1; }
          jq -e '.paths.scanned | length > 0' semgrep.json >/dev/null || { echo 'scanner scanned no files'; exit 1; }
          jq -e '.findings' triage.json >/dev/null || { echo 'triage output missing'; exit 1; }
          jq -r '.results[] | "\(.check_id)@\(.path):\(.start.line)"' semgrep.json | sort > scanner.ids
          jq -r '.findings[] | select(.source=="semgrep") | .id' triage.json | sort > triage.ids
          diff scanner.ids triage.ids
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: security-triage
          path: |
            triage.json
            scanner.ids
            triage.ids

Zacommituj prompt triage (pasuje prompt dla Semgrepa z sekcji wyżej) jako .github/security/triage-prompt.txt, a schemat jako .github/security/triage.schema.json. --bare, --setting-sources "" i --strict-mcp-config sprawiają, że przebieg nie ładuje CLAUDE.md, hooków z .claude/settings.json repozytorium, ustawień użytkownika ani serwerów z .mcp.json, które inaczej wykonałyby się z sekretem joba (flagi sprawdzone w Claude Code 2.1.283). Mimo to trzymaj ten job na gałęzi domyślnej: nigdy nie przenoś go na wyzwalacz pull_request, gdzie same pobrane pliki pochodzą od kontrybutora. Warunek if na poziomie joba odrzuca też workflow_dispatch uruchomiony z innej gałęzi, którym każdy z prawem zapisu mógłby inaczej wykonać prompt i skrypty ze swojej gałęzi z sekretem. Ręczne uruchomienie czyta jednak plik workflow z wybranej gałęzi, więc tam ten if też da się usunąć; twardą gwarancję daje dopiero umieszczenie ANTHROPIC_API_KEY w środowisku (environment), którego gałęzie wdrożeń są ograniczone do domyślnej. Krok Verify triage coverage uruchamia test pokrycia z poprzedniej sekcji, więc zgubiony, zmyślony albo brakujący triage kończy job błędem, zamiast trafić do artefaktu; schemat wymusza --json-schema już przy generowaniu. Artefakt zawiera scanner.ids i triage.ids obok triage.json, więc po nieudanym przebiegu widać, które identyfikatory się różnią. Job gate działa tylko w pull requestach i blokuje na znaleziskach Semgrepa o wadze ERROR, które wprowadza dany pull request (--baseline-commit pomija znaleziska obecne już na gałęzi bazowej), oraz na każdym ostrzeżeniu npm o wadze high lub critical. Job triage działa niezależnie od bramki, według harmonogramu lub po ręcznym uruchomieniu, i tylko raportuje: nie może czekać na zieloną bramkę, bo przebieg z blokującymi znaleziskami to właśnie ten, który wymaga triage.

W Codeksie zastąp krok Scan and triage w jobie triage dwoma krokami poniżej; Verify triage coverage i wysyłkę artefaktu zostaw bez zmian, bo test pokrycia czyta te same pliki semgrep.json i triage.json:

      - name: Scan (advisory)
        run: pipx run --spec semgrep==1.178.0 semgrep scan --config p/default --json-output semgrep.json || true
      - name: Triage with Codex (read-only)
        uses: openai/codex-action@v1   # tag v1.13 (2026-10-05); pin to a full commit SHA in production
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          codex-version: 0.157.1
          permission-profile: ":read-only"
          prompt-file: .github/security/triage-prompt.txt
          output-schema-file: .github/security/triage.schema.json
          output-file: triage.json

Akcja instaluje przypiętą wersję CLI, trzyma klucz API za własnym proxy i uruchamia codex exec --output-schema z plikiem schematu, więc i tutaj schemat jest wymuszany już przy generowaniu. Wejścia permission-profile i starsze sandbox wykluczają się nawzajem, więc ustaw tylko jedno z nich (wejścia sprawdzone w README openai/codex-action v1 2 października 2026). Bez akcji odpowiednikiem jest krok npm install -g @openai/codex@0.157.1, a po nim codex exec --sandbox read-only --output-schema .github/security/triage.schema.json -o triage.json "$(cat .github/security/triage-prompt.txt)", z kluczem API pobranym z sekretu.

Dla obrazów dodaj Trivy jako krok blokujący po zbudowaniu obrazu, a przed wdrożeniem:

- name: Scan image with Trivy
  uses: aquasecurity/trivy-action@v0.36.0   # never @master; pin the SHA of this tag
  with:
    image-ref: myorg/api:${{ github.sha }}
    severity: CRITICAL,HIGH
    ignore-unfixed: true
    exit-code: '1'
    format: table

Przypinaj każdą zewnętrzną akcję do SHA commita. Opiekunowie LiteLLM przypisali złośliwe wydania litellm 1.82.7 i 1.82.8 na PyPI (24 marca 2026) przejętemu krokowi Trivy w swoim CI (zgłoszenie BerriAI/litellm #24518, marzec 2026; przypisanie krokowi Trivy pochodzi ze źródła wtórnego). Pływający tag na skanerze bezpieczeństwa oddaje twoje sekrety CI łańcuchowi dostaw tego skanera.

Prompt do skopiowania: dodaj bramkę Trivy do istniejącego workflow wdrożenia

Add a container security gate to .github/workflows/deploy.yml. After the image
build step and before any deploy job, scan the image we just built with
aquasecurity/trivy-action pinned to a full commit SHA (add the tag as a comment).
Fail the job on CRITICAL or HIGH findings that have a fix (ignore-unfixed: true,
exit-code: '1'). Add a top-level permissions block with contents: read and
persist-credentials: false on checkout. Show the full diff and explain why each
setting is there. Do not change any other job.

Otwieraj pull requesty z poprawkami, nigdy ich nie scalaj automatycznie

Agent szkicuje poprawkę na gałęzi security/* i otwiera pull request przez gh pr create. Scalenie przechodzi przez ochronę gałęzi z wymaganą recenzją właściciela bezpieczeństwa, a agent nie może scalić. W Claude Code utrwal to w .claude/settings.json:

{
  "permissions": {
    "deny": ["Bash(gh pr merge *)", "Bash(git push --force *)"]
  }
}

Reguła deny dopasowuje prefiks, więc zatrzymuje prosty zapis polecenia, a nie każdy możliwy. Prawdziwą kontrolą jest ochrona gałęzi na GitHubie; reguła deny łapie pomyłki.

Prompt do skopiowania: popraw znaleziska P0 w jednym pull requeście do recenzji

Read triage.json. Take only entries with verdict EXPLOITABLE and priority P0.
Create branch security/p0-<today's date>. For each finding, apply the change in
its fix field and add or extend a test that fails before the change and passes
after it. Then re-run `semgrep scan --config p/default --json-output rescan.json`
and confirm each fixed id is absent from rescan.json. Open a pull request with
`gh pr create`; in the body, list each id, the test that proves the fix, and the
re-scan result. Do not merge. Do not touch findings that are not P0.

Którzy agenci bezpieczeństwa, serwery MCP i skille pasują do tej pętli?

Są dwa rodzaje pomocy. Agenci bezpieczeństwa przeglądają diff lub repozytorium własnym modelem dostawcy. Serwery MCP dają twojemu agentowi dane na żywo (alerty, stan chmury), których skanery nie widzą. Używaj obu i w każdym przypadku zostaw deterministyczną bramkę.

Narzędzie	Agent bezpieczeństwa lub wtyczka	Instalacja lub wywołanie
Claude Code	/security-review na diffie gałęzi; wtyczka security-guidance oznacza ryzykowne edycje na bieżąco (zobacz bramki bezpieczeństwa agentów); GitHub Action anthropics/claude-code-security-review przegląda pull requesty	claude plugin install security-guidance@claude-plugins-official
Codex	@codex security review w pull requeście na GitHubie; Codex Security (oba sprawdzone 28 sierpnia 2026)	integracja Codex z GitHubem
Cursor	Security Agents i Bugbot (sprawdzone 28 sierpnia 2026)	panel Cursora

Serwery MCP warte podłączenia, wszystkie sprawdzone 26 września 2026:

• Serwer GitHub MCP w trybie tylko do odczytu: agent czyta alerty Dependabota, code scanningu i secret scanningu w wielu repozytoriach. Token potrzebuje uprawnienia do odczytu tych typów alertów; bez niego odczyty wracają puste.

  # Claude Code: the token is not typed on the command line, but it is saved to the Claude Code config file
  claude mcp add --transport http github https://api.githubcopilot.com/mcp/readonly \
    -H "Authorization: Bearer $GITHUB_PAT"
  # Codex
  codex mcp add github --url https://api.githubcopilot.com/mcp/readonly --bearer-token-env-var GITHUB_PAT

  claude mcp add zapisuje rozwinięty nagłówek, więc PAT leży otwartym tekstem w pliku konfiguracji Claude Code. Żeby trzymać go wyłącznie w magazynie sekretów, dodaj serwer do projektowego .mcp.json; Claude Code rozwija ${GITHUB_PAT} przy starcie serwera:

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

  Cursor używa tego samego adresu URL w .cursor/mcp.json; konfigurację znajdziesz w przewodniku po serwerze GitHub MCP.

• AWS: serwer AWS Labs awslabs.well-architected-security-mcp-server (PyPI 0.2.0) raportuje stan i znaleziska GuardDuty, Security Hub, Inspector i IAM Access Analyzer. Uruchamiaj go z rolą IAM tylko do odczytu, a nie z kluczami dostępu w konfiguracji. Plik wykonywalny pakietu nazywa się awslabs.well-architected-security-mcp-server; krótsza nazwa z README projektu nie działa (sprawdzone przez uvx 26 września 2026):

  {
    "mcpServers": {
      "aws-security": {
        "command": "uvx",
        "args": ["--from", "awslabs.well-architected-security-mcp-server@0.2.0", "awslabs.well-architected-security-mcp-server"],
        "env": { "AWS_PROFILE": "security-readonly", "AWS_REGION": "eu-central-1" }
      }
    }
  }

  Codex przyjmuje te same pola jako tabelę [mcp_servers.aws-security] w ~/.codex/config.toml.

• Azure: @azure/mcp korzysta z tożsamości z az login. Przypnij wersję stabilną, bo @azure/mcp@latest wskazuje na wersję beta 3.0.0 (sprawdzone 26 września 2026): claude mcp add azure -- npx -y @azure/mcp@2.0.5 server start.

• Skill Semgrep: npx skills add semgrep/skills instaluje skille, które Semgrep publikuje w tym repozytorium; aktualną listę znajdziesz w jego README. Skill jest lżejszy niż serwer; sięgnij po niego, gdy chcesz, żeby agent pisał własne reguły Semgrepa dla twojej bazy kodu.

Każdy dodany serwer to nowa powierzchnia ataku; model zagrożeń dla agentów pokazuje, do czego atakujący może przez niego sięgnąć. Przeskanuj własną konfigurację agentów narzędziem Snyk Agent Scan (uvx snyk-agent-scan@0.6.8, wydanie z PyPI z 26 września 2026; wymaga SNYK_TOKEN). Uruchamia ono serwery stdio, żeby je zbadać, więc konfiguracje, którym nie ufasz, skanuj w piaskownicy. Pełną procedurę opisuje strona o zabezpieczaniu serwerów MCP.

Utwardź klaster przez Pod Security Admission

Polityka dopuszczania zatrzymuje podatne lub nadmiernie uprzywilejowane obciążenie, które prześlizgnęło się przez CI. PodSecurityPolicy usunięto w Kubernetes 1.25; wbudowanym następcą jest Pod Security Admission, ustawiany etykietami przestrzeni nazw:

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Prompt do skopiowania: przenieś przestrzeń nazw na standard restricted

The payments namespace runs with enforce: baseline and warn/audit: restricted.
Read the manifests in k8s/payments/ and list every workload that would be
rejected under enforce: restricted, with the exact field that fails (runAsNonRoot,
allowPrivilegeEscalation, capabilities, seccompProfile, volume types). Propose the
per-workload diff that makes it compliant. Add a default-deny NetworkPolicy plus
allows for ingress from app=api-gateway on 8443 and egress to app=postgres on
5432. Do not use PodSecurityPolicy. Do not apply anything to the cluster.

Gdzie w tym wszystkim są dowody zgodności?

Przebiegi skanerów, pliki triage i pull requesty z poprawkami to dowody, o które audytorzy SOC 2 i ISO 27001 pytają w obszarach zarządzania zmianą i podatnościami. Przechowuj je jako artefakty buildu z określonym okresem retencji. Mapowanie ich na kontrole to osobny workflow, opisany w automatyzacji zgodności regulacyjnej.

Kiedy operacje bezpieczeństwa wspierane przez AI się psują

Pusty triage, który wygląda jak czysty wynik

Wygasła sesja SSO, zły region albo brak uprawnienia do alertów sprawia, że serwer MCP lub CLI nic nie zwraca, a agent melduje „brak znalezisk”. Wyjście: niech test pokrycia kończy się błędem, gdy wyniku skanera brakuje, nie da się go sparsować albo powstał z błędami (strażniki test -s, .errors i .paths.scanned w teście pokrycia powyżej), i najpierw potwierdź poświadczenia (aws sts get-caller-identity, gh auth status).

Lawina fałszywych alarmów zasypuje prawdziwe znalezisko

Szerokie zestawy reguł i nienaprawialne CVE w obrazach bazowych dają setki znalezisk. Wyjście: przypnij zestaw reguł (p/default albo pakiety językowe, np. p/javascript), przekaż Trivy --ignore-unfixed i daj agentowi kontekst projektu („Express API; req.body, req.query i req.params to jedyne niezaufane źródła”). Każde zaakceptowane odrzucenie zapisz jako komentarz nosemgrep z uzasadnieniem, żeby nie wracało.

Poprawka zamyka skan, a nie dziurę

Łatka może zmienić nazwę zmiennej tak, że reguła przestaje pasować, a wektor ataku zostaje otwarty. Wyjście: wymagaj testu, który ćwiczy ten wektor, a nie tylko czystego ponownego skanu, i niech właściciel bezpieczeństwa czyta diff każdego P0.

Zmyślone CVE, wersje i dowody

Agent potrafi przytoczyć identyfikator ostrzeżenia, wynik CVSS albo wersję z poprawką, które nie istnieją. Wyjście: test pokrycia odrzuca znaleziska, których nie ma w wyniku skanera, a każdy prompt na tej stronie każe kopiować identyfikatory i wersje z pliku skanera. Każdy identyfikator, którego nie znajdziesz w JSON-ie, traktuj jako zmyślony.

Zablokowane wdrożenia przez politykę dopuszczania

Przełączenie działającej przestrzeni nazw od razu na enforce: restricted może zablokować twoje własne wdrożenia. Wyjście: najpierw warn i audit, popraw to, co zgłoszą, przełączaj po jednej przestrzeni nazw i nigdy nie nakładaj etykiety na kube-system.

Skaner jako furtka w łańcuchu dostaw

Narzędzia bezpieczeństwa działają z szerokim dostępem do odczytu i często z sekretami. Wyjście: przypinaj akcje i wersje skanerów, nadawaj tylko contents: read i rotuj sekrety CI, jeśli przypięte narzędzie okaże się później przejęte.

Dokąd dalej z operacjami bezpieczeństwa

Skanowanie bezpieczeństwa i testowanie podatności SAST, DAST i testy zależności przed scaleniem, czyli etap poprzedzający ten.

Planowe skany bezpieczeństwa z dowodami i bramką PR Zamień job triage w cykliczną, raportowaną pętlę.

Pakiet dowodów Co musi udowodnić pull request z poprawką, zanim zostanie scalony.

Automatyzacja zgodności regulacyjnej Mapowanie artefaktów skanów i poprawek na kontrole SOC 2 i ISO 27001.

Bramki bezpieczeństwa agentów Hooki pre-commit na sekrety, Semgrep i TruffleHog w CI oraz security review od Claude na każdym pull requeście.

Bezpieczeństwo i zgodność w organizacji Zarządzanie sekretami i egzekwowanie polityk w całej organizacji.

Reagowanie na incydenty z AI Co robić, gdy znalezisko okazuje się aktywnym incydentem.