Skąd wziął się termin Evidence Pack

Audyt bezpieczeństwa — SOC 2, ISO 27001, audyt klienta Enterprise, weryfikacja DORA — to w dużej mierze proces zbierania i prezentowania dowodów. Audytor nie certyfikuje Twojej organizacji dlatego że napisałeś dobrą politykę. Certyfikuje dlatego że możesz udowodnić że ta polityka jest faktycznie stosowana.

Evidence Pack to termin na ustrukturyzowany zbiór artefaktów technicznych który zbiera te dowody automatycznie — przy każdym deployu, dla każdego wydania. Zamiast zbierać dokumentację ad hoc przed audytem, organizacja ma gotowe dowody jako produkt uboczny swojego normalnego procesu wytwórczego.

Co konkretnie zawiera Evidence Pack

Zawartość jest powiązana z tym co pipeline faktycznie robi i co ma wartość dowodową dla audytorów. Kluczowe elementy to:

security-report.json — skonsolidowane wyniki skanowań: SAST (CodeQL), SCA (Trivy), skanowanie sekretów (TruffleHog), skanowanie IaC (Checkov). Jeden dokument który pokazuje że testy bezpieczeństwa były uruchomione, co znalazły i jakie były bramy jakości.

sbom.cyclonedx.json — Software Bill of Materials w standardowym formacie. Pełna lista komponentów oprogramowania z wersjami i zależnościami. Odpowiada na pytanie “z czego jest zbudowany ten artefakt” — wymagane przez NIS2, coraz częściej przez klientów Enterprise.

provenance.intoto.jsonl — dowód pochodzenia artefaktu. Zawiera: co zostało zbudowane, kiedy, przez jaki workflow, z jakiego commita, w jakim środowisku. Możliwość kryptograficznej weryfikacji że artefakt pochodzi z konkretnego uruchomienia pipeline’u.

cosign-verification.log — log weryfikacji podpisu kryptograficznego artefaktu. Dowód że obraz kontenera który idzie na produkcję ma ważny podpis i nie był modyfikowany od momentu podpisania.

pipeline-run.json — metadane end-to-end całego uruchomienia: kto uruchomił, kiedy, który commit, jakie bramki przeszły, jakie nie, wersje narzędzi. Audit trail dla jednego cyklu delivery.

manifest.sha256 — skrót SHA256 wszystkich plików w paczce. Weryfikowalny podpis integralności całego Evidence Pack — audytor może sprawdzić że paczka nie była modyfikowana po wygenerowaniu.

Dlaczego audytor chce właśnie to

Audytor SOC 2 weryfikuje Trust Services Criteria — konkretnie CC8 (Change Management), CC7 (System Operations) i CC5 (Control Activities). Każde z tych kryteriów wymaga dowodów że kontrole działały przez cały okres audytowy — typowo 6 miesięcy.

Evidence Pack generowany przy każdym deployu tworzy automatycznie rejestr z całego okresu. Zamiast rekonstruować historię przed audytem — historia jest już nagrana. Audytor dostaje dostęp do archiwum i może samodzielnie zweryfikować dowolny deploy z dowolnego dnia.

Dla audytu ISO 27001 Evidence Pack adresuje Annex A kontrole dotyczące bezpiecznego SDLC (A.8.25), zarządzania podatnościami (A.8.8), zarządzania zmianami (A.8.32) i logowania zdarzeń (A.8.15).

Dla DORA — Evidence Pack jest odpowiedzią na wymóg rozliczalności z Art. 9 i 10: dokumentuje że kontrole ICT istnieją i są stosowane, a nie tylko zadeklarowane w polityce.

Evidence Pack nie zastępuje audytu — co to oznacza

Ważne zastrzeżenie które podkreślamy w każdej rozmowie: Evidence Pack to punkt wyjścia do rozmowy z audytorem, nie jej zastępstwo. Audytor SOC 2 ocenia nie tylko czy artefakty istnieją, ale czy reprezentują wystarczające dowody dla danego zakresu systemu. Ta ocena należy do audytora.

Co Evidence Pack robi: eliminuje pytanie “czy macie dowody”. Odpowiedź brzmi: tak, i są gotowe do pobrania.

Co Evidence Pack nie robi: nie zastępuje governance, polityk organizacyjnych, zarządzania incydentami, szkolenia pracowników — wszystkich elementów compliance które są poza pipeline’em CI/CD. Zgodność regulacyjna w pełnym zakresie wymaga działań organizacyjnych i prawnych których żaden pipeline nie zastąpi.

Praktyczne zastosowanieOrganizacje które mają Evidence Pack przed rozmową z audytorem spędzają pierwsze spotkanie na omawianiu zakresu i harmonogramu — zamiast na zbieraniu podstawowej dokumentacji. To różnica między audytem który zaczyna się od "pokażcie nam co macie" a audytem który zaczyna się od "widzieliśmy wasze artefakty, teraz omówimy zakres".

Dlaczego Evidence Pack jest trudny do złożenia samodzielnie

Evidence Pack nie jest osobnym narzędziem — jest wynikiem spójnego działania całego pipeline’u. Każdy artefakt musi być wygenerowany przez odpowiednią fazę (skanowanie, budowanie, podpisywanie), zebrany w jednym workflow, opatrzony manifestem SHA256 i zarchiwizowany w immutable storage z polityką retencji dopasowaną do wymagań audytowych.

Kluczowe słowo: spójny. Częściowe wdrożenie — kilka artefaktów bez integralności całego łańcucha, storage bez WORM, manifest bez kryptograficznej weryfikacji — produkuje dokumentację która na pozór wygląda jak Evidence Pack, ale nie przejdzie weryfikacji audytora który zna temat.

Organizacje które próbują złożyć to samodzielnie z dokumentacji narzędzi zazwyczaj odkrywają że integracja Cosign, Syft, SLSA provenance, DAST, storage z Object Lock i polityk retencji to kilka tygodni pracy inżynierskiej — i seria nieoczekiwanych problemów z każdą integracją. A to zanim przetestuje się że całość działa spójnie po każdej zmianie w pipeline’ie.

Co konkretnie zawiera Evidence Pack

Evidence Pack to nie jeden dokument — to zestaw artefaktów generowanych automatycznie z pipeline’u, zmapowanych na wymagania regulacyjne. Typowy Evidence Pack z hardeningu CI/CD zawiera:

Warstwa 1 — Artefakty techniczne: SBOM (CycloneDX) z pełną listą składników, podpisy artefaktów (Cosign/Sigstore), wyniki skanowania SAST/SCA (CodeQL, Trivy, Checkov), wyniki skanowania sekretów (TruffleHog), logi pipeline’u z pełnym traceability od commita do deploymentu.

Warstwa 2 — Mapowanie regulacyjne: Matryca kontroli mapowana na DORA (Art. 9, 10, 16), NIS2 (Art. 21) i SOC 2 (CC6, CC7, CC8). Każda wdrożona kontrola z odniesieniem do konkretnego wymagania.

Warstwa 3 — Dokumentacja operacyjna: Konfiguracja pipeline’u, polityka rotacji sekretów, konfiguracja branch protection rules, architektura zarządzania dostępem (OIDC federation).

Jak Evidence Pack automatyzuje odpowiedzi na audyt

Tradycyjne podejście: audytor pyta, zespół szuka dowodów, ktoś kompiluje odpowiedzi w Wordzie. Czas: tygodnie. Podejście z Evidence Pack: artefakty generują się automatycznie przy każdym deployu. Kiedy audytor pyta “pokażcie logi z ostatnich 6 miesięcy” — są. Kiedy pyta “pokażcie SBOM” — jest.

Dla firm które regularnie przechodzą Vendor Risk Assessment lub ankiety bezpieczeństwa Enterprise — to jest różnica między 3 tygodniami pracy a 3 dniami.

Evidence Pack nie jest certyfikacją — nie zastępuje SOC 2 Type II ani ISO 27001. Jest natomiast najsilniejszym dowodem technicznym jaki możesz przedstawić przed uzyskaniem certyfikacji. Wiele firm używa go jako “mostu” — odpowiada na VRA z Evidence Pack, równolegle przygotowując się do formalnej certyfikacji.

Co dostajesz zamiast składania samemu CI/CD Hardening Sprint wdraża cały pipeline od skanowania po archiwizację Evidence Pack — w 2–4 tygodnie. Po wdrożeniu dokumentacja audytowa generuje się automatycznie przy każdym deployu, bez angażowania zespołu. Każdy artefakt ma kryptograficznie weryfikowalną integralność. Audytor dostaje Evidence Pack, nie obietnicę że zaraz coś zbierzemy.