Planowe skany bezpieczeństwa z dowodami i bramką PR

Planowe bezpieczeństwo łączy deterministyczne skanery z osobno ograniczoną analizą agenta. Agent może śledzić autoryzację, izolację tenantów, granice zaufania i logikę biznesową, lecz każde znalezisko pozostaje niezweryfikowane do reprodukcji lub review. Pierwszy przebieg jest read-only; zaakceptowane patche używają izolowanej gałęzi, dowodów CI i bramki security ownera.

Pytanie scorecardu: Jak skanujesz bazę kodu pod kątem głębokich podatności i długu architektonicznego?

Maksymalna odpowiedź: Planowane przebiegi skanera i agenta zachowują dowody, kierują patche przez PR i dodają evale regresyjne dla zaakceptowanych napraw.

Warstwy skanu

Warstwa	Co wykrywa	Wymagany dowód
Dependency, secret i SAST	Znane podatne wersje, sekrety, wzorce kodu	Wersja narzędzia, rule ID, plik i linia
Analiza agenta	Autoryzacja cross-file, tenant isolation, niebezpieczne przejścia stanu	Ślad przez konkretne call sites i testy
Ludzki security triage	Exploitability, wpływ biznesowy, priorytet	Decyzja accept/reject z ownerem i powodem
Regression suite	Powrót zaakceptowanej podatności	Test czerwony przed i zielony po naprawie

Model nie zastępuje SAST, dependency i secret scanningu, penetration tests ani threat modelingu. Narracja o niskiej pewności nie powinna otwierać lawiny patchy.

Kontrakt bezpiecznego joba

Schedulerem może być CI, obsługiwana funkcja cloud agent albo wewnętrzny runner. Zapewnij:

dedykowaną tożsamość read-only dla pierwszego przebiegu;
jawne repo/ref i limit czasu;
brak sekretów produkcji i dostępu do danych klientów;
schemat outputu i limit findings;
zasady retencji fragmentów kodu i telemetrii;
routing do triage, nie bezpośredniego merge lub deploy.

task: scheduled-security-review
ref: default-branch
mode: read-only
max_findings: 10
focus: [authorization, tenant-isolation, injection, secrets, race-conditions]
output: security-findings.json
on_accept:
  create_isolated_branch: true
  require: [regression-test, ci, security-owner-review]
forbidden: [production-access, exploit-live-target, direct-merge, deploy]

To kontrakt niezależny od narzędzia, nie plik konfiguracyjny konkretnego vendora.

Prompty do skopiowania

Przejrzyj repo read-only pod kątem autoryzacji, tenant isolation,
injection, wycieków sekretów i niebezpiecznych przejść stanu.
Dla każdego kandydata wskaż plik i linię, prześledź osiągalną ścieżkę,
wymień brakujące dowody i zaproponuj bezpieczny test reprodukujący.
Nie atakuj żywych systemów, nie edytuj plików i zwróć maks. 10 findings.

Dla zaakceptowanego FINDING_ID dodaj najpierw czerwony test regresyjny
w izolowanej gałęzi, potem zaproponuj najmniejszy patch.
Uruchom bramki security i testy; zwróć komendy, exit codes,
pozostałe ryzyko i ownera wymaganego przed merge.

Gdy skanowanie zawodzi

Confidence jest uznawany za walidację. Pewność modelu nie jest dowodem. Wymagaj śladu, bezpiecznej reprodukcji, outputu narzędzia lub review specjalisty.

Skan może dotknąć produkcji. Usuń credentials i ścieżki sieciowe przed strojeniem promptów.

Patch zmienia test, aby ukryć błąd. Zachowaj reprodukcję i recenzuj zmiany testów niezależnie.

Te same findings wracają co tydzień. Zapisuj dyspozycje z fingerprintem i terminem ważności; otwieraj ponownie po zmianie kodu lub dowodów.

Weryfikacja workflow

Skanery deterministyczne i przebieg agenta mają zapisane wersje.
Pierwszy przebieg nie może pisać do repo ani dotykać produkcji.
Każde finding wskazuje kod i oznacza brakujące dowody.
Zaakceptowany fix ma test regresyjny i output CI.
Nazwany security owner zatwierdza merge wrażliwych napraw.
Większa naprawa tworzy intent.md i wraca do cyklu.

Routing zaakceptowanej pracy

Etap Maintain opisuje scheduling, a Deploy — bramki review i release.

Q17 · Ciągłe evale Zachowuj zaakceptowane błędy jako przypadki regresyjne.

Governance i autonomia Przypisz tożsamość, dowody i poziom działań.