Przejdź do głównej zawartości
AI Developer Toolkit

Standardy bezpieczeństwa i zgodność

Standardy bezpieczeństwa w pracy wspomaganej przez AI opierają się na czterech egzekwowalnych warstwach: granicy danych, którą każde narzędzie wystawia jako ustawienie (tryb prywatności, zarządzane reguły deny, piaskownica), plikach reguł wspartych tymi regułami, powierzchniach audytowych, które narzędzia faktycznie emitują, oraz bramkach CI blokujących niezrecenzowane migracje, wyciekłe sekrety i znaleziska OWASP. Zamieniają dowody SOC 2, GDPR i HIPAA w przechodzący test.

Twój zespół bezpieczeństwa właśnie wstrzymał wdrożenie AI, a pytania są zasadne: dokąd trafia nasz kod źródłowy, czy deweloper może wkleić do promptu dane osobowe klienta i czy potrafisz udowodnić audytorowi SOC 2, kto dokładnie co uruchomił? Trzy tygodnie przed audytem Type II asesor chce też dowodu, że kod generowany przez AI jest recenzowany przed wdrożeniem, i że serwery MCP zainstalowane przez zespół w zeszłym sprincie nie wynoszą po cichu plików. W tym samym czasie deweloperzy scalają PR-y pisane przez agenty w tempie trzy razy szybszym niż rok temu.

Ogólnikowe rady w stylu „pisz jasne prompty” nie odpowiadają na żadne z tych pytań. Poniżej jest konkretny, egzekwowalny zestaw: ustawienia, które przełączasz, konfiguracje, które commitujesz, powierzchnie audytowe, które te narzędzia faktycznie wystawiają, oraz skanery i polityki wpinane w CI — tak, by zgodność była przechodzącym testem, a nie kwartalnym pożarem, i żeby kontrole nadążały, nie stając się wąskim gardłem, które wszyscy obchodzą.

Co daje ta konfiguracja bramkowania zgodności

Dział zatytułowany „Co daje ta konfiguracja bramkowania zgodności”
  • Dokładne ustawienie prywatności i retencji danych do wyegzekwowania w Cursorze, Claude Code i Codeksie, tak by kod źródłowy nie był przechowywany ani używany do treningu
  • Zacommitowany, egzekwowany maszynowo plik polityki dla każdego narzędzia, który blokuje odczyty .env, niebezpieczną powłokę i niezatwierdzone serwery MCP — a nie stronę na wiki, którą wszyscy ignorują
  • Prawdziwą konfigurację audytu i telemetrii dla każdego narzędzia, bez wymyślonych kluczy ustawień, zmapowaną na rodziny kontroli SOC 2, GDPR i HIPAA
  • Działające skanowanie łańcucha dostaw MCP przy użyciu Snyk Agent Scan (dawniej Invariant MCP-Scan) wpięte we wszystkie trzy narzędzia
  • Hook PreToolUse i konfigurację pre-commit skanującą diffy pod kątem sekretów i danych osobowych, zanim cokolwiek opuści maszynę, na prawdziwym OSS (gitleaks, detect-secrets, trivy)
  • Gotowe prompty produkujące uruchamialne artefakty: zestaw reguł Semgrep, przegląd OWASP Top 10:2025, szablon PR bramkowany CODEOWNERS, middleware audytowe SOC 2 CC7.1 i politykę Open Policy Agent blokującą niezrecenzowane migracje generowane przez AI
  • Sekcję trybów awarii pokrywającą pułapki, które faktycznie znajdują audytorzy i red teamy

Gdzie narzędzia AI dotykają twojej granicy zgodności

Dział zatytułowany „Gdzie narzędzia AI dotykają twojej granicy zgodności”

Dla audytu liczą się trzy powierzchnie:

  • Wyciek danych na zewnątrz. Twoje prompty zawierają kod źródłowy, a czasem sekrety. Dla poufności SOC 2 i dla HIPAA potrzebujesz udokumentowanej postawy zerowej retencji u każdego dostawcy. Privacy Mode i plan Enterprise Cursora gwarantują zerową retencję danych (zob. trust.cursor.com); Anthropic i OpenAI oferują to samo w warstwach API i enterprise. Udokumentuj, w jakim trybie działa każde narzędzie — ten dokument jest dowodem kontroli.
  • Ścieżka audytowa. Musisz pokazać, kto co uruchomił. Każde narzędzie wystawia inny mechanizm. Żadne nie ma magicznej flagi audit_logging: true — prawdziwe powierzchnie to OpenTelemetry, opakowywanie komend powłoki i logi administracyjne platformy.
  • Łańcuch dostaw. Serwery MCP działają z uprawnieniami twoich narzędzi. W ocenie popularnych otwartoźródłowych implementacji serwerów MCP przeprowadzonej przez Equixly w 2025 roku 43% zawierało podatności na wstrzyknięcie komend, 30% pozwalało na nieograniczone pobieranie URL-i, a 22% wynosiło pliki poza przeznaczony katalog. Traktuj każdy serwer MCP jak niezweryfikowaną zależność.

Krok 1: zamknij granicę danych w każdym narzędziu

Dział zatytułowany „Krok 1: zamknij granicę danych w każdym narzędziu”

Te kontrole różnią się istotnie między narzędziami, więc skonfiguruj każde. Cel jest identyczny: nie dopuścić do przechowywania kodu i sekretów oraz sprawić, by wrażliwe pliki nigdy nie trafiły do kontekstu.

Wyegzekwuj Privacy Mode na poziomie zespołu, tak by nikt nie mógł go wyłączyć, a potem trzymaj wrażliwe pliki poza indeksowaniem i kontekstem przez .cursorignore.

  1. Panel zespołu -> Settings -> włącz Privacy Mode i przełącz Enforce (członkowie nie mogą go już wyłączyć). Privacy Mode jest domyślnie włączony w Enterprise i daje ZDR u wszystkich dostawców modeli.
  2. Na urządzeniach firmowych wdróż politykę MDM Allowed Team IDs, aby użytkownicy nie mogli zalogować się na konto prywatne bez Privacy Mode.
  3. Zacommituj .cursorignore, żeby sekrety i infrastruktura nigdy nie były indeksowane ani wysyłane jako kontekst:
# .cursorignore — never index or send to models
.env
.env.*
**/secrets/**
**/*.pem
**/*.key
terraform.tfstate*
**/credentials.json

Dla obciążeń regulowanych poproś dział sprzedaży o włączenie CMEK (klucze szyfrujące zarządzane przez klienta), aby embeddingi i dane Cloud Agents były szyfrowane twoim kluczem. Jeśli twoja polityka w ogóle zabrania przechowywania kodu, po prostu nie włączaj Cloud Agents — każda inna funkcja Cursora nadal działa. Cursor Business i Enterprise mają atestacje SOC 2 Type II, które dołączasz do dokumentacji zarządzania dostawcami.

Krok 2: reguły prowadzą, listy deny egzekwują

Dział zatytułowany „Krok 2: reguły prowadzą, listy deny egzekwują”

Stary jednoplikowy .cursorrules jest przestarzały. Używaj Project Rules Cursora (.cursor/rules/*.mdc), CLAUDE.md Claude Code wraz z zacommitowanymi ustawieniami projektu oraz AGENTS.md Codeksa. Plik reguł to wskazówki, których model zwykle przestrzega; to listy deny z kroku 1 faktycznie je egzekwują. Używaj obu.

Utwórz .cursor/rules/security.mdc. Frontmatter alwaysApply: true wstrzykuje go do każdej sesji:

---
description: "Security & data-handling rules"
alwaysApply: true
---


- Privacy Mode must stay enabled; never sign in with a personal account.
- Never write API keys, passwords, tokens, or connection strings into code. Read them from `process.env`.
- Never put customer PII (names, emails, SSNs, MRNs) in fixtures, logs, or prompts. Use `@faker-js/faker` for test data.
- When discussing a schema with PII columns, use anonymized column names.
- Reference `.env.example` for environment variable names, never `.env`.
- Mark AI-assisted code with a `// AI-assisted` comment so review and CODEOWNERS can track it.
- Redact secrets before logging; encrypt sensitive data at rest and in transit.

Wskazówki o obchodzeniu się z sekretami to podłoga. Plik reguł zarabia na siebie, gdy koduje twoje standardy, tak by generowany kod był domyślnie bezpieczny, a nie domyślnie prawdopodobny:

// .cursor/rules/security.mdc, CLAUDE.md, or AGENTS.md — standards section
SECURITY CODING STANDARDS:


Authentication:
- All API endpoints must use the authMiddleware from /src/middleware/auth.ts
- JWT tokens expire after 15 minutes, refresh tokens after 7 days
- Password hashing uses bcrypt with cost factor 12


Input Validation:
- All request bodies validated with Zod schemas before processing
- File uploads limited to 10MB, allowed types: jpg, png, pdf
- URL parameters must be validated as UUIDs where applicable


Database:
- ALL queries must use parameterized statements (Drizzle ORM or prepared statements)
- Never construct SQL strings with string concatenation
- Database connections use least-privilege service accounts


Output:
- All HTML output must be escaped (handled by React/template engine)
- API responses must not include internal error details in production
- Set Content-Security-Policy, X-Frame-Options, X-Content-Type-Options headers

Krok 3: włącz dowody audytowe, które narzędzia naprawdę emitują

Dział zatytułowany „Krok 3: włącz dowody audytowe, które narzędzia naprawdę emitują”

To ta część, którą większość zespołów psuje, wklejając klucze konfiguracyjne, które nie istnieją. Oto, co każde narzędzie faktycznie wspiera.

Claude Code nie ma ustawienia audit_logging. Obserwowalność to OpenTelemetry, a audyt na poziomie komend to prefiks powłoki. Włącz oba w ~/.claude/settings.json (managed settings na kontrolowanym hoście w przedsiębiorstwie):

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel-collector.internal:4317",
    "CLAUDE_CODE_SHELL_PREFIX": "/usr/local/bin/audit-logger.sh"
  }
}

CLAUDE_CODE_ENABLE_TELEMETRY=1 strumieniuje metryki i logi do twojego kolektora (a stamtąd do SIEM-u); CLAUDE_CODE_SHELL_PREFIX opakowuje każdą komendę Bash, więc audit-logger.sh <command> ją zapisuje. Ten log komend to twój dowód dostępu i aktywności dla SOC 2.

Mapowanie SOC 2, GDPR i HIPAA na te powierzchnie

Dział zatytułowany „Mapowanie SOC 2, GDPR i HIPAA na te powierzchnie”

Audytorzy nie akceptują „ufamy deweloperom”. Każda powierzchnia powyżej odpowiada konkretnej rodzinie kontroli:

  1. SOC 2 (CC6 dostęp, CC7.1 wykrywanie). Pobieraj logi dostępu i użycia z powierzchni administracyjnej każdego narzędzia: Admin API i analityki zespołu w Cursorze, Claude Code przez Claude for Enterprise (SSO, RBAC, API zgodności) oraz Compliance API Codeksa. Dla własnych usług wygeneruj middleware audytowe pod CC7.1 promptem poniżej.

  2. GDPR (minimalizacja danych, prawo do usunięcia). Trzymaj dane osobowe całkowicie poza promptami — .cursorignore, permissions.deny i piaskownica z kroku 1 to załatwiają. Przy usuwaniu Compliance API Codeksa oraz eksporty enterprise Cursora i Anthropic pozwalają zlokalizować i rozliczyć każdy rekord powiązany z użytkownikiem. Nigdy nie używaj danych produkcyjnych jako fixture’ów testowych; generuj dane syntetyczne.

  3. HIPAA (obchodzenie się z PHI). Nigdy nie wysyłaj chronionych informacji zdrowotnych do modelu bez podpisanego BAA obejmującego dokładnie tę powierzchnię. Domyślnie używaj syntetycznych pacjentów i redaguj PHI, zanim trafi do promptu.

Generuj syntetyczne dane testowe utrzymywanym @faker-js/faker (stary samodzielny pakiet faker jest przestarzały, a jego API faker.datatype.* już nie istnieje):

import { faker } from '@faker-js/faker';


export function syntheticPatient() {
  return {
    id: faker.string.uuid(),
    name: faker.person.fullName(),
    dob: faker.date.past({ years: 80 }),
    mrn: `TEST-${faker.number.int({ min: 100000, max: 999999 })}`,
    conditions: ['Synthetic Condition A', 'Synthetic Condition B'],
  };
}

Krok 4: przeskanuj serwery MCP, zanim im zaufasz

Dział zatytułowany „Krok 4: przeskanuj serwery MCP, zanim im zaufasz”

Zanim jakikolwiek serwer MCP trafi na maszynę dewelopera, przeskanuj go. Narzędziem jest Snyk Agent Scan (dawny MCP-Scan od Invariant Labs, dziś utrzymywany przez Snyka). Działa przez uvx — to narzędzie w Pythonie, więc nie rób npm install.

  1. Przeskanuj konfigurację kandydata (albo cały mcp.json) pod kątem zatruwania narzędzi, prompt injection i toksycznych przepływów:

    Okno terminala
    uvx snyk-agent-scan@latest ~/.cursor/mcp.json

    Stary punkt wejścia uvx mcp-scan@latest wciąż działa — jest teraz przekierowaniem, które instaluje snyk-agent-scan i przekazuje dalej CLI.

  2. Przeczytaj ustalenia. Oznaczony serwer może mieć nieograniczone narzędzie fetch przyjmujące dowolne URL-e albo opis narzędzia zawierający ukryte instrukcje (atak zatruwania narzędzia). Nie instaluj go, dopóki to nie zostanie rozwiązane.

  3. Zarejestruj sam skaner jako serwer MCP, żeby agent mógł skanować na żądanie:

Dodaj go w Settings → MCP → Add Server albo edytuj ~/.cursor/mcp.json bezpośrednio, żeby konfiguracja podlegała przeglądowi w kontroli wersji:

{
  "mcpServers": {
    "security-analyzer": {
      "command": "uvx",
      "args": ["snyk-agent-scan"],
      "env": { "SNYK_TOKEN": "${SNYK_TOKEN}" }
    }
  }
}

Konsumowany jest wyłącznie SNYK_TOKEN (do skanów uwierzytelnionych) — nie wymyślaj tu SECURITY_SCAN_MODE ani SEMGREP_APP_TOKEN. Semgrep uruchamiaj jako osobny krok, a nie jako zmienną środowiskową skanera.

Krok 5: zablokuj sekrety i dane osobowe, zanim opuszczą maszynę

Dział zatytułowany „Krok 5: zablokuj sekrety i dane osobowe, zanim opuszczą maszynę”

Używaj prawdziwych, utrzymywanych skanerów — a nie ręcznie sklecanej klasy wyrażeń regularnych. gitleaks (binarka w Go) i detect-secrets (pip install detect-secrets) łapią poświadczenia; trivy łapie podatne zależności i błędy konfiguracji. Wepnij je w dwa miejsca: hook PreToolUse Claude Code, który blokuje commit, jaki agent właśnie chce wykonać, oraz CI jako zabezpieczenie ostatniej szansy.

Hook to miejsce, w którym trzy narzędzia się rozjeżdżają — Claude Code potrafi zablokować wywołanie narzędzia w locie; Cursor i Codex opierają się na pre-commit plus CI.

Cursor nie ma hooka blokującego commit, więc egzekwuj na warstwie gita konfiguracją pre-commit, którą dziedziczy każdy klon:

.pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.5.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']

Uruchom pre-commit install raz na klon (albo wymuś to w bootstrapie repozytorium). Teraz każdy commit — wspomagany przez AI czy nie — jest skanowany, zanim wyląduje.

Prompty, które produkują uruchamialne artefakty, a nie dokumenty

Dział zatytułowany „Prompty, które produkują uruchamialne artefakty, a nie dokumenty”

Sensem AI jest tutaj artefakt gotowy do wdrożenia — zestaw reguł, poprawka, plik polityki — a nie dokument, który go opisuje. Zakotwicz prompty w konkretnym stosie, żeby wynik dał się uruchomić.

Zestaw reguł Semgrep to stała bramka. Do pełnego przeglądu jednego modułu względem aktualnej listy OWASP poproś o przegląd wprost:

Przy pojedynczym pull requeście użytecznym wynikiem jest werdykt, na którym recenzent może działać, a nie lista kategorii:

Ta sama dyscyplina zamienia kwartalną listę kontrolną zgodności w powtarzalny przebieg:

Uruchamiaj je w dowolnym narzędziu — przepływ jest identyczny, różni się tylko punkt wejścia. W Cursorze otwórz diff i wywołaj na nim tryb agenta albo przekaż go Background Agentowi przy każdym PR. W Claude Code uruchom claude -p "<prompt>" na gałęzi, żeby czytał drzewo robocze, albo wepnij to w hook. W Codeksie podaj PR przez integrację z GitHubem lub codex exec w CI. Przypnij model: Claude Fable 5 do przeglądów o najwyższej stawce, Opus 5 do tańszego premium rozumowania albo odpowiednia warstwa GPT-5.6 Sol/Terra/Luna w ChatGPT Codex. Pełny rozkład warstw znajdziesz w porównaniu modeli.

Egzekwowanie polityk w CI

Dział zatytułowany „Egzekwowanie polityk w CI”

Dowody audytowe są najmocniejsze, gdy powstają automatycznie. Trzymaj twardą bramkę deterministyczną, a przeglądowi AI pozwól doradzać — dokładnie tak jak przy każdym innym skanerze.

Deterministyczne zabezpieczenie ostatniej szansy jest identyczne niezależnie od tego, które narzędzie napisało kod:

.github/workflows/security-scan.yml
name: Security Scan
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with: { fetch-depth: 0 }
      - name: Secret scan
        uses: gitleaks/gitleaks-action@v2
      - name: Dependency & misconfig scan
        uses: aquasecurity/trivy-action@v0.36.0
        with: { scan-type: 'fs', severity: 'HIGH,CRITICAL', exit-code: '1' }
      - name: AI-attribution check
        run: |
          count=$(git diff --name-only origin/${{ github.base_ref }}... \
            | xargs grep -l "AI-assisted\|AI-generated" 2>/dev/null | wc -l)
          if [ "$count" -eq 0 ]; then
            echo "::warning::No AI-assisted attribution found in changed files"
          fi

Przegląd AI działa obok tego. Zwróć uwagę, jak zbudowana jest bramka: claude -p zwraca tekstową odpowiedź modelu, a nie kod wyjścia zależny od istotności, więc z --output-format json odpowiedź ląduje w .result, a to krok jq -e oblewa zadanie:

.github/workflows/security-review.yml
security-review:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v5
      with:
        fetch-depth: 0
    - name: AI Security Review
      run: |
        claude -p --output-format json "Review the git diff for security issues:
        $(git diff origin/main...HEAD)


        Check for:
        1. SQL injection vulnerabilities
        2. Missing authentication/authorization
        3. Hardcoded secrets or credentials
        4. Unvalidated user input
        5. Insecure cryptographic operations
        6. Missing rate limiting on new endpoints


        Return ONLY JSON: {\"issues\": [{\"severity\", \"file\", \"line\", \"description\", \"fix\"}]}" \
          | jq -e '.result | fromjson | all(.issues[]; .severity != "Critical" and .severity != "High")'

W Codeksie odpowiednikiem jest automatyzacja wyzwalana zdarzeniami PR, która publikuje ustalenia z powrotem jako recenzję, zamiast oblewać krok:

When a PR is opened, perform a security review:
1. Analyze all changed files for OWASP Top 10:2025 vulnerabilities
2. Check new dependencies against known vulnerability databases
3. Verify authentication is required on all new endpoints
4. Confirm input validation exists for all new user-facing parameters
5. Post findings as a PR review comment with inline annotations

Bramką o największej dźwigni dla zespołów pracujących z AI jest ta, której nikt nie buduje ręcznie: blokowanie niezrecenzowanych zmian schematu. Migracje generowane przez agenta to dokładnie to miejsce, w którym pomyłka typu confused deputy staje się incydentem ujawnienia danych.

Historia zaliczeń i oblań tego zadania to twój dowód ciągłej zgodności — wskaż audytorowi log Actions, zamiast składać arkusz ręcznie. To także odpowiedź na „nasze audyty trwają tyle samo co wcześniej”: uruchamiaj sprawdzenia przy każdym PR, a kwartalny audyt stanie się formalnością.

Kiedy korporacyjne kontrole bezpieczeństwa AI zawodzą

Dział zatytułowany „Kiedy korporacyjne kontrole bezpieczeństwa AI zawodzą”
  • „Telemetria jest włączona, ale SIEM jest pusty”. CLAUDE_CODE_ENABLE_TELEMETRY=1 musi być ustawione przed tym, jak zadziałają zmienne eksportera OTEL, a endpoint kolektora musi być osiągalny z hosta dewelopera. Przetestuj najpierw na lokalnym kolektorze; zablokowany firewall wyjściowy po cichu gubi dane.
  • uvx snyk-agent-scan nic nie zgłasza na serwerze, który podejrzewasz. Skany statyczne nie widzą zachowania w czasie działania, a zbyt szeroki serwer MCP może odczytać dokładnie te pliki, które chroni twoja lista deny. Połącz skan z kontrolami piaskownicy powyżej (brak sieci, brak zakresu w systemie plików), użyj deniedMcpServers / allowedMcpServers w managed settings i obserwuj faktyczne wywołania narzędzi serwera — czysty skan jest konieczny, ale niewystarczający.
  • Skaner sekretów blokuje każdy commit. Fixture’y testowe o wysokiej entropii i przykładowe klucze wywracają gitleaks i detect-secrets. Wygeneruj baseline (detect-secrets scan > .secrets.baseline) i zacommituj go albo dodaj zawężony .gitleaksignore — nigdy nie wyłączaj skanu w całości.
  • Redakcja psuje prawidłowe prompty. Agresywna redakcja regexem zamienia user@example.com w przykładzie kodu w [REDACTED] i psuje kontekst agenta. Redaguj na ścieżce diffu i commita, a nie w prompcie, który deweloper właśnie pisze; lepiej trzymać dane osobowe poza kontekstem (pliki ignore) niż czyścić je po fakcie.
  • Bramka Rego blokuje uzasadnione hotfiksy. Wbuduj furtkę w samą politykę (linia MIGRATION-RISK: accepted by), a nie w nadpisanie administracyjne. Nadpisanie, które omija kontrolę, jest ustaleniem audytowym; udokumentowany, oznaczony wyjątek to kontrola, która działa.
  • Deweloper omija politykę. Konto prywatne albo --dangerously-skip-permissions sprawia, że twoje zacommitowane reguły są bez znaczenia. Właśnie dlatego krok 1 ma znaczenie: egzekwuj Privacy Mode plus Allowed Team IDs (Cursor), disableBypassPermissionsMode plus managed settings (Claude Code) i RBAC (Codex) na poziomie organizacji, a nie repozytorium.
  • „Ustawienia audytu” Cursora się nie pojawiają. One nie istnieją na poziomie użytkownika. Jeśli potrzebujesz audytu per deweloper, potrzebujesz powierzchni administracyjnej planu Enterprise plus logowania komend na hoście — nie ma na to JSON-a po stronie klienta.
  • Agent wypuszcza sekret do promptu. To incydent wycieku danych, a nie błąd w kodzie. Hook UserPromptSubmit i reguły deny Read(./.env*) zapobiegają temu u źródła; każde naruszenie traktuj jako zgłaszalne w ramach planu reagowania na incydenty.
  • PHI przecieka, bo „ZDR” wzięto za BAA. Zero Data Retention zapobiega treningowi i przechowywaniu; nie jest umową Business Associate Agreement. Nie ma BAA, nie ma PHI — kropka.
  • Zespół bezpieczeństwa w ogóle nie zatwierdzi narzędzi AI. Przynieś na spotkanie raport SOC 2 dostawcy, umowę powierzenia przetwarzania i warunki zerowej retencji, zamiast argumentować korzyściami. Plany enterprise dają gwarancje umowne, a tam, gdzie wymagana jest absolutna izolacja, lokalny model zostawia kod na maszynie.
  • Każdy zespół koduje wymagania bezpieczeństwa inaczej. Scentralizuj treść reguł z kroku 2 w jednym współdzielonym repozytorium i dystrybuuj ją — pakietem w monorepo albo submodułem Gita — tak by standardy rozjeżdżały się w jednym miejscu, a nie w dwunastu.

Dokąd dalej z bezpieczeństwem i zgodnością

Dział zatytułowany „Dokąd dalej z bezpieczeństwem i zgodnością”
Prywatność i obchodzenie się z danymi Codzienne nawyki stojące za tymi kontrolami i to, co dzieje się z kodem, którego dotyka agent.
Automatyzacja zgodności Automatyzacja zbierania dowodów i ścieżek audytowych w CI.
Operacje bezpieczeństwa Skanowanie w czasie działania, triage podatności i reagowanie na incydenty.
Testy bezpieczeństwa Budowanie i uruchamianie skanów, na których bramkuje ten artykuł.
Dobre praktyki MCP Utwardzanie, zawężanie i debugowanie zweryfikowanych serwerów MCP.
Zarządzanie kosztami Budżety, warstwy modeli i kontrola zużycia w zespołach.

Autor:

Zobacz co nowego na platformie.

Polityka prywatności Regulamin Ustawienia cookie