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

Automatyzacja zgodności regulacyjnej

Twoja firma właśnie przeszła audyt SOC 2 Type II, ale zbieranie dowodów zajęło trzem inżynierom dwa pełne tygodnie. Połowa pracy polegała na kopiowaniu logów z różnych systemów do arkuszy kalkulacyjnych, pisaniu opisów narracyjnych kontroli i robieniu zrzutów ekranu konfiguracji potwierdzających egzekwowanie polityk. W następnym kwartale audytor poprosi o te same dowody ponownie, a inżynier, który wiedział, gdzie wszystko się znajduje, właśnie odszedł z firmy.

Zgodność regulacyjna nie jest opcjonalna, ale otaczająca ją praca ręczna już tak. Narzędzia AI do kodowania mogą automatyzować egzekwowanie polityk na poziomie kodu, generować ścieżki audytowe z istniejącej infrastruktury i produkować dokumentację zgodności, która pozostaje aktualna bez dedykowanego etatu.

Czego się nauczysz

Dział zatytułowany „Czego się nauczysz”
  • Automatyczne wzorce compliance-as-code egzekwujące polityki w pipeline’ach CI/CD
  • Hooki pre-commit wychwytujące naruszenia zgodności zanim kod trafi do produkcji
  • Generowanie ścieżek audytowych napędzane przez AI z historii Git, logów infrastruktury i rekordów wdrożeń
  • Prompty do generowania pakietów dowodów zgodności SOC 2, HIPAA i GDPR
  • Automatyzacja skanowania bezpieczeństwa zintegrowana z codziennym przepływem pracy deweloperskiej

Przepływ pracy Compliance-as-Code

Dział zatytułowany „Przepływ pracy Compliance-as-Code”

Główna idea: zakoduj wymagania regulacyjne jako wykonywalne reguły uruchamiane automatycznie. Zamiast udowadniać zgodność wstecz, zapobiegaj niezgodności przed wdrożeniem.

  1. Zdefiniuj wymagania zgodności jako polityki czytelne maszynowo. Przetłumacz każdą kontrolę (SOC 2 CC6.1, HIPAA 164.312, GDPR Artykuł 25) na regułę, którą można sprawdzić programowo.

  2. Wdróż egzekwowanie na wielu warstwach. Hooki pre-commit wychwytują problemy lokalnie. Bramki CI/CD blokują niezgodny kod przed scaleniem. Skanery infrastructure-as-code walidują konfiguracje wdrożeniowe.

  3. Automatycznie generuj dowody audytowe. Każde sprawdzenie egzekwujące produkuje wpis z timestampem. Te logi stają się twoją ścieżką audytową.

  4. Generuj raporty zgodności na żądanie. AI agreguje logi egzekwowania, historię Git i stan infrastruktury w raporty narracyjne, których oczekują audytorzy.

Egzekwowanie polityk w CI/CD

Dział zatytułowany „Egzekwowanie polityk w CI/CD”

Najbardziej niezawodne egzekwowanie zgodności odbywa się w pipeline CI/CD. Kod naruszający politykę nigdy nie trafia do produkcji, ponieważ pipeline go odrzuca.

Wygeneruj pipeline w trybie agenta, a następnie użyj checkpointów Cursora i przeglądu różnic, aby zweryfikować każdą wygenerowaną regułę. Reguły zgodności są z natury dopasowaniem dokładnym, więc krok wizualnego przeglądu ma tutaj większe znaczenie niż w większości przepływów pracy.

@codebase "Create a GitHub Actions workflow that enforces the following compliance
policies before any code can be merged to main:


1. All secrets must be stored in environment variables, never hardcoded
   (scan for patterns like API keys, passwords, tokens)
2. All database queries must use parameterized statements
   (no string concatenation in SQL)
3. All user-facing endpoints must have authentication middleware
4. All PII fields must be encrypted at rest (check schema definitions)
5. All changes to auth-related files require two approvals


For each check, log the result to a compliance-evidence.json artifact
with timestamp, check name, result (pass/fail), and affected files.
Generate the workflow file and any helper scripts needed."

Przed zaakceptowaniem różnicy ustaw checkpoint Cursora i sprawdź każdą wygenerowaną regułę w odniesieniu do faktycznego języka twojej kontroli. Regex, który jest nieco zbyt szeroki, oznaczy każdy PR; ten, który jest zbyt wąski, po cichu przepuści naruszenia. Checkpoint pozwala cofnąć pojedynczą złą regułę bez regenerowania całego workflow.

Hooki pre-commit do zgodności

Dział zatytułowany „Hooki pre-commit do zgodności”

Hooki pre-commit dają deweloperom natychmiastowy feedback, zanim kod opuści ich maszynę. To szybsze niż czekanie na CI i zmniejsza naruszenia zgodności u źródła.

Wygeneruj standardowy .pre-commit-config.yaml, a następnie użyj trybu agenta, aby dodać reguły specyficzne dla projektu i przejrzyj każdą z nich w różnicy przed commitem.

"Generate a pre-commit hook configuration (.pre-commit-config.yaml) that
enforces these compliance rules locally:


1. No secrets in committed files (use detect-secrets or gitleaks)
2. No TODO/FIXME comments in files under src/security/
3. All TypeScript files must have 'use strict' or strict mode enabled
4. Database migration files must include a rollback step
5. API route files must import from the auth middleware module


For each rule that fails, print a clear message explaining the violation
and how to fix it. Also create a COMPLIANCE.md that documents each hook
and the regulatory requirement it addresses."

To przenośna, niezależna od języka warstwa (framework pre-commit), którą dostaje każdy współpracownik niezależnie od tego, jakiego edytora używa.

Automatyczne generowanie ścieżki audytowej

Dział zatytułowany „Automatyczne generowanie ścieżki audytowej”

Audytorzy potrzebują dowodów, że kontrole były egzekwowane w czasie, nie tylko w momencie audytu. Automatyczna ścieżka audytowa zbiera dane o egzekwowaniu w sposób ciągły.

Ścieżka audytowa oparta na Git

Dział zatytułowany „Ścieżka audytowa oparta na Git”

Twoja historia Git już zawiera bogatą ścieżkę audytową. AI może wyodrębnić z niej zdarzenia istotne dla zgodności.

Ścieżka audytowa infrastruktury

Dział zatytułowany „Ścieżka audytowa infrastruktury”

Zmiany infrastruktury również potrzebują ścieżek audytowych. Jeśli używasz Terraform, CloudFormation lub Pulumi, każda zmiana jest już wersjonowana.

Uruchom to interaktywnie w trybie agenta, gdy przygotowujesz się do okna audytowego i chcesz czytać ustalenia na bieżąco, a następnie wejść w szczegóły konkretnych różnic Terraform w edytorze.

@codebase "Generate an infrastructure compliance report by analyzing:


1. All Terraform state changes in the past quarter
2. Security group modifications (who changed what, when)
3. IAM policy changes and their justifications from PR descriptions
4. Encryption configuration status for all data stores
5. Network access control changes


Cross-reference each change against our SOC 2 CC6.1 (logical access)
and CC6.6 (boundary protection / network controls) requirements. Flag
any changes that lack a corresponding approval in the PR process.


Output as a structured report with evidence links to specific commits."

Cursor łączy każde ustalenie z commitem, więc możesz otworzyć różnicę w edytorze i na własne oczy ocenić, czy zmiana naprawdę odpowiada uzasadnieniu z PR, zanim raport trafi do audytora.

Generowanie pakietu dowodów SOC 2

Dział zatytułowany „Generowanie pakietu dowodów SOC 2”

Audyty SOC 2 Type II wymagają dowodów, że kontrole działały efektywnie przez okres (zwykle 6-12 miesięcy). Ręczne generowanie tych dowodów to najbardziej czasochłonna część audytu.

Automatyzacja zbierania dowodów

Dział zatytułowany „Automatyzacja zbierania dowodów”

Składaj pakiet interaktywnie, abyś mógł korygować zakres w trakcie pracy agenta — otwórz w edytorze eksport z dostawcy tożsamości lub plik Terraform i potwierdź, że dowód się zgadza, zanim trafi do dokumentu.

"Generate a complete SOC 2 Type II evidence package for the past quarter.


For each Trust Service Criteria, collect the following:


CC6.1 (Logical Access Controls):
- User access reviews (export from our identity provider)
- Role-based access control documentation
- MFA enforcement evidence (percentage of users with MFA enabled)
- Privileged access inventory


CC6.2 (System Account Management):
- Service account inventory with last rotation dates
- Automated credential rotation evidence from CI/CD logs
- Account lifecycle documentation (creation, modification, termination)


CC6.6 (Boundary Protection) and CC6.7 (Data Classification / Transmission):
- Network architecture diagram (generate from Terraform)
- Data classification matrix
- Data flow diagrams for PII (encryption in transit)


CC8.1 (Change Management):
- All PRs merged to main with approval status
- CI/CD pipeline pass rates
- Deployment logs with rollback instances
- Change advisory board meeting notes (if applicable)


For each control, provide:
1. Control description
2. Evidence collected
3. Testing results (effective/deficiency)
4. Recommendations for improvement


Output as a structured document that an auditor can review directly."

Wzorce zgodności HIPAA

Dział zatytułowany „Wzorce zgodności HIPAA”

Zgodność z HIPAA wymaga konkretnych zabezpieczeń technicznych dla chronionych informacji zdrowotnych (PHI). Narzędzia AI mogą egzekwować te zabezpieczenia w kodzie.

Ochrona PHI w kodzie

Dział zatytułowany „Ochrona PHI w kodzie”
// Przykład: middleware logowania dostępu do PHI wygenerowane przez AI
import { auditLogger } from '~/lib/compliance/audit';
import { classifyData } from '~/lib/compliance/data-classification';


export async function phiAccessMiddleware(request: Request, next: Function) {
  const classification = await classifyData(request);


  if (classification.containsPHI) {
    await auditLogger.log({
      timestamp: new Date().toISOString(),
      userId: request.auth.userId,
      action: request.method,
      resource: request.url,
      dataClassification: 'PHI',
      justification: request.headers.get('X-Access-Justification'),
      ipAddress: request.headers.get('X-Forwarded-For'),
    });
  }


  return next(request);
}

Automatyzacja zgodności z GDPR

Dział zatytułowany „Automatyzacja zgodności z GDPR”

GDPR wymaga konkretnych możliwości: obsługa żądań dostępu podmiotów danych (DSAR), prawo do usunięcia, zarządzanie zgodami i rejestry przetwarzania danych.

Automatyzacja żądań podmiotów danych

Dział zatytułowany „Automatyzacja żądań podmiotów danych”

Zbuduj handler w trybie agenta i ustaw checkpoint przed zaakceptowaniem każdego adaptera magazynu danych — ścieżka usuwania jest destrukcyjna, więc chcesz przejrzeć logikę usuwania/anonimizacji w różnicy, a nie ufać jej w ciemno.

"Generate a DSAR (Data Subject Access Request) handler that:


1. Accepts a user identifier (email or user ID)
2. Searches all data stores for records associated with that user:
   - PostgreSQL (users, orders, payments, support_tickets)
   - Redis cache (session data, preferences)
   - S3 (uploaded documents, profile images)
   - Analytics events (PostHog)
   - Email service (Resend delivery logs)
3. Compiles all data into a structured JSON export
4. Generates a human-readable PDF summary
5. Logs the DSAR fulfillment for our processing records
6. Can also handle right-to-erasure by deleting/anonymizing all records


Include proper error handling for partial failures (e.g., one data store
is unreachable). The response should indicate which sources were
successfully queried and which failed, so we can retry."

Automatyzacja skanowania bezpieczeństwa

Dział zatytułowany „Automatyzacja skanowania bezpieczeństwa”

Ciągłe skanowanie bezpieczeństwa wychwytuje luki zanim trafią do produkcji. Kluczem jest integracja skanów w przepływy pracy, z których deweloperzy już korzystają, a nie dodawanie oddzielnych bramek bezpieczeństwa, które nauczą się omijać.

Skanowanie podatności zależności

Dział zatytułowany „Skanowanie podatności zależności”
.github/workflows/compliance-security.yml
name: Compliance Security Scan
on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1' # Cotygodniowe skanowanie w poniedziałek


jobs:
  dependency-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run dependency audit
        run: npm audit --json > audit-results.json
      - name: Analyze results
        run: |
          node scripts/compliance/analyze-audit.js \
            --input audit-results.json \
            --severity high,critical \
            --output compliance-evidence/dependency-scan-$(date +%Y%m%d).json
      - name: Upload compliance evidence
        uses: actions/upload-artifact@v4
        with:
          name: compliance-evidence-deps
          path: compliance-evidence/
          retention-days: 365

Analiza statyczna dla zgodności

Dział zatytułowany „Analiza statyczna dla zgodności”

Napisz reguły ESLint w trybie agenta i przetestuj je na prawdziwych plikach w edytorze — wklej znaną wadliwą instrukcję logowania i potwierdź, że reguła faktycznie się uruchamia, zanim zaufasz jej w CI.

"Create a static analysis configuration that checks for compliance-relevant
patterns in our codebase:


1. Data handling: PII must be logged with redaction, never raw values
2. Authentication: All API endpoints must check auth before processing
3. Encryption: Sensitive config values must use encrypted env vars
4. Logging: Security events must use the structured audit logger
5. Error handling: Error responses must not leak internal details


Use ESLint custom rules where possible. For checks ESLint cannot handle,
create standalone analysis scripts. Each rule should reference the
specific compliance requirement it enforces (e.g., SOC2-CC6.1, HIPAA-164.312)."

Automatyzacja raportowania regulacyjnego

Dział zatytułowany „Automatyzacja raportowania regulacyjnego”

Zaplanowane raporty zgodności

Dział zatytułowany „Zaplanowane raporty zgodności”

Automatyzuj cotygodniowe i kwartalne raporty zgodności, aby dane były zawsze aktualne.

scripts/compliance/generate-weekly-report.ts
import { getGitActivity } from './sources/git';
import { getCIResults } from './sources/ci';
import { getSecurityScans } from './sources/security';
import { getAccessReviews } from './sources/access';
import { renderReport } from './templates/weekly';


async function generateWeeklyComplianceReport() {
  const period = { start: sevenDaysAgo(), end: now() };


  const data = {
    gitActivity: await getGitActivity(period),
    ciResults: await getCIResults(period),
    securityScans: await getSecurityScans(period),
    accessReviews: await getAccessReviews(period),
  };


  const report = renderReport({
    ...data,
    controls: mapToControls(data),
    deficiencies: findDeficiencies(data),
    recommendations: generateRecommendations(data),
  });


  await saveReport(report, `weekly-${period.end.toISOString()}`);
  await notifyComplianceTeam(report.summary);
}

Kiedy coś się psuje

Dział zatytułowany „Kiedy coś się psuje”

Reguły zgodności generują fałszywe alarmy. Skaner sekretów oznacza fixture testowy zawierający fałszywy klucz API. Dodaj listę dozwolonych dla znanych fałszywych alarmów, ale przeglądaj ją kwartalnie, aby upewnić się, że nie rozrosła się do ukrywania prawdziwych problemów.

Ścieżka audytowa ma luki. Jeśli deweloperzy pushują bezpośrednio do main omijając proces PR, ścieżka audytowa pomija zatwierdzenia. Egzekwuj reguły ochrony gałęzi na poziomie repozytorium, nie tylko w CI. Zarówno GitHub, jak i GitLab obsługują wymaganie zatwierdzeń PR jako ustawienie repozytorium.

Handler DSAR pomija magazyn danych. Gdy dodawana jest nowa usługa, ktoś zapomina dodać ją do handlera DSAR. Dołącz „rejestr magazynów danych”, w którym wszystkie nowe usługi muszą się zarejestrować, i dodaj sprawdzenie CI weryfikujące, że każde połączenie z bazą danych w bazie kodu ma odpowiedni adapter DSAR.

Raporty zgodności odnoszą się do nieaktualnych polityk. Dokumentacja zgodności mówi, że rotujesz poświadczenia co 90 dni, ale faktyczny skrypt rotacji uruchamia się co 180 dni. Automatyzuj weryfikację polityk: generator raportów powinien sprawdzać faktyczne daty rotacji w odniesieniu do zadeklarowanej polityki i oznaczać rozbieżności.

Hooki pre-commit spowalniają deweloperów. Jeśli hooki zgodności trwają dłużej niż 5 sekund, deweloperzy będą je pomijać za pomocą --no-verify. Trzymaj sprawdzenia pre-commit szybkie (skanowanie sekretów, reguły lint) i przenieś wolniejsze sprawdzenia (pełny audyt zależności, skanowanie infrastruktury) do CI.

Wymagania regulacyjne się zmieniają. Gdy regulacja się aktualizuje (np. nowe wytyczne GDPR lub rewizje kryteriów SOC 2), twoje zakodowane polityki też muszą się zmienić. Subskrybuj kanały aktualizacji regulacyjnych i planuj kwartalne przeglądy reguł compliance-as-code w odniesieniu do aktualnych wymagań.

Co dalej

Dział zatytułowany „Co dalej”
Automatyzacja pipeline'ów CI/CD Zintegruj sprawdzenia zgodności ze swoją strategią automatyzacji pipeline'ów.
Operacje bezpieczeństwa Szersza automatyzacja bezpieczeństwa, w tym reagowanie na incydenty i zarządzanie podatnościami.
Monitoring i obserwowalność Monitoruj status zgodności obok kondycji aplikacji.

Zobacz co nowego na platformie.

Polityka prywatności Regulamin