Demo — CyberForge | DevSecOps CI/CD Hardening

Demo 01 — Security Snapshot

Raport CI/CD Security Snapshot

Tak wygląda dokument po audycie CI/CD — GitHub Actions, AWS, kontener Docker. Trzy zakładki: priorytety naprawcze, szczegóły techniczne, mapa drogowa.

📊 CI_CD_Security_Snapshot_myapp_2026-03-12.pdf Wygenerowano: audyt 2-dniowy

Platforma GitHub Actions · AWS Zakres 3 pipeline, 2 repo Data 2026-03-12

7

Znaleziska krytyczne

14

Statyczne sekrety w repo

DORA Art.16 SLSA L2 SOC 2 CC VRA

Dotknięte standardy

Lista znalezisk posortowana wg priorytetu.

Poziom	Znalezisko	Opis	Standard
■ CRITICAL	Statyczne klucze AWS IAM w GitHub Secrets	3 klucze, rotacja nieznana. Brak CloudTrail alertów na użycie poza pipeline.	DORA §16.2(a)
■ CRITICAL	Brak pinowania akcji GitHub Actions do SHA	12/15 akcji używa tagów (@v1, @v3) — podatność na supply chain attack przy przejęciu konta twórcy.	SLSA L2
■ CRITICAL	Wyciek tokenu GitHub PAT w historii Git	Commit a3f9c12 (2025-11-08): plik .env z aktywnym tokenem. Token nie unieważniony — dostęp do org do dziś.	NIS2 §21(d)
■ HIGH	Brak podpisywania artefaktów Docker (Cosign)	Obrazy na produkcji bez podpisu kryptograficznego. Audytor nie może zweryfikować provenance — blokada VRA.	DORA §16.2(b)
■ HIGH	Direct push do main bez code review	Brak branch protection rules. 3 commity w ostatnich 30 dniach ominęły review — brak separation of duties.	SOC 2 CC6.1
■ MEDIUM	Brak generowania SBOM przy buildzie	Żaden workflow nie generuje Software Bill of Materials — wymagane przez VRA enterprise i NIS2 / CRA.	NIS2 / VRA
■ MEDIUM	GITHUB_TOKEN z uprawnieniami write:all (domyślne)	Domyślna konfiguracja org: permissions: write-all. Każdy job ma pełny zapis do repo — naruszona zasada least privilege.	SLSA L1
■ LOW	Brak cyklicznego przeglądu uprawnień do repozytorium	4 konta zewnętrznych współpracowników z dostępem Write — brak procesu offboardingu i przeglądu co 30 dni...	SOC 2 CC6.2

Szczegółowe ustalenia z audytu: narzędzia, metoda wykrycia, dowód techniczny dla każdego znaleziska.

Poziom	Znalezisko	Szczegóły techniczne & dowód	Narzędzie
■ CRITICAL	Statyczne klucze AWS IAM	Secret: `AWS_ACCESS_KEY_ID = AKIA...` (prefix AKIA = długoterminowy klucz użytkownika IAM). Polityka IAM: `AdministratorAccess` — pełny dostęp do konta AWS. Ostatnia aktywność: 2026-03-01 (query do S3 prod). Rotacja: brak historii w IAM Credentials Report.	TruffleHog + AWS CLI
■ CRITICAL	Akcje bez pinowania SHA	Przykład: `uses: actions/checkout@v4` — tag v4 może zostać przesunięty przez właściciela repozytorium bez ostrzeżenia. Bezpieczna forma: `uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683`. Dotyczy 12/15 akcji w workflow.	Analiza manualna + zizmith
■ CRITICAL	Wyciek PAT w Git history	`ghp_xK9mL2...` (GitHub PAT, scope: repo:write) — wykryty w commit `a3f9c12`, plik `scripts/.env.deploy`. Token aktywny — weryfikacja: `curl -H "Authorization: token ghp_xK9..." https://api.github.com/user` → HTTP 200. Wymagane natychmiastowe unieważnienie.	TruffleHog v3
■ HIGH	Brak podpisywania artefaktów Docker (Cosign)	Obrazy budowane przez pipeline bez kroku cosign sign. Brak weryfikacji podpisu w Kubernetes admission controller — deploy możliwy z dowolnego źródła. Audytor nie może potwierdzić provenance kontenera na produkcji.	Analiza workflow
■ HIGH	Direct push do main bez code review	Branch protection rules nieaktywne na main. Git log: 3 commity bezpośrednio na main w ostatnich 30 dniach (hashe: `b4e2f1a`, `c9d3e7b`, `f1a8c2d`) — żaden nie przeszedł przez PR. Brak separation of duties wymaganego przez SOC 2 CC6.1.	Analiza Git log
■ MEDIUM	Brak generowania SBOM przy buildzie	Żaden z 3 workflow nie zawiera kroku generowania Software Bill of Materials. Syft lub Trivy SBOM możliwe do dodania jako krok po `docker build`. Brak SBOM blokuje spełnienie NIS2 / CRA Art.13 i jest częstą przyczyną odrzucenia w VRA enterprise.	Analiza workflow
■ MEDIUM	GITHUB_TOKEN z uprawnieniami write:all	Domyślna konfiguracja org: `permissions: write-all`. Każdy job ma pełny zapis do repo — naruszenie zasady least privilege. Bezpieczna konfiguracja: `permissions: contents:read, id-token:write` per-job. Zmiana: ok. 1h...	Audyt konfiguracji org

Rekomendowany plan naprawy podzielony na fazy.

Faza	Działanie	Efekt biznesowy
Faza 1 Natychmiast	Unieważnienie aktywnego tokenu PAT i kluczy IAM Revoke `ghp_xK9...` w GitHub Settings. Dezaktywacja kluczy AKIA w IAM Console. Weryfikacja brak aktywnych sesji.	Zamknięcie aktywnej luki — dostęp nieautoryzowany niemożliwy
Faza 1 Tydzień 1	Pinowanie akcji do SHA + branch protection rules Zamiana tagów na SHA w 12 akcjach. Włączenie wymaganych review na main: min. 2 approvals, blokada direct push, required status checks.	Blokada supply chain attack. Separation of duties dla SOC 2 CC6.1
Faza 2 Tydzień 1–2	Wdrożenie OIDC — eliminacja statycznych kluczy AWS GitHub OIDC provider w AWS IAM. Role z minimalnym scope per-repo, per-branch. Usunięcie zmiennych `AWS_ACCESS_KEY_ID` z GitHub Secrets.	Spełnienie DORA §16.2(a). Zero długożyciowych sekretów w CI/CD
Faza 2 Tydzień 2	Cosign + SBOM — podpisywanie artefaktów i inwentaryzacja Sigstore/Cosign krok w pipeline po docker build. Syft do generowania CycloneDX SBOM. Archiwizacja w S3 przy każdym release.	Spełnienie DORA §16.2(b), NIS2 supply chain. Odblokowanie VRA enterprise
Faza 3 Tydzień 3	Ograniczenie uprawnień GITHUB_TOKEN do least privilege Konfiguracja `permissions` per-job: `contents:read`, `id-token:write`. Wyłączenie domyślnego `write-all` na poziomie org.	Eliminacja nadmiarowego dostępu do repo — ograniczenie blast radius przy kompromitacji workflow
Faza 3 Tydzień 3–4	Izolacja runnerów + eksport logów do SIEM Efemeryczne runnery w izolowanej sieci (brak dostępu do RDS/Redis). CloudWatch log forwarding z retention 365 dni. Alerty na anomalie.	Eliminacja ryzyka lateralnego. Audit trail zgodny z DORA i SOC 2
Faza 3 Miesiąc 2	Policy-as-Code + pełny Evidence Pack OPA Rego policies jako mandatory gates. Automatyczne mapowanie dowodów na DORA/NIS2/SOC 2. Generowanie Evidence Pack PDF przy każdym...	Pełna gotowość na audyt KNF i VRA enterprise bez ręcznej pracy

📊 Pełny raport Snapshot — otrzymujesz po zrealizowaniu usługi CI/CD Security Snapshot

Materiały → Umów Security Snapshot →

Demo 02 — Pipeline Security

Pipeline CI/CD: przed i po hardeningu

Ten sam problem bezpieczeństwa — trzy platformy, trzy podejścia do hardeningu. Wybierz stack, którego używasz:

Przed hardeningiem — typowy stan

name: Deploy to Production
on: [push]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@main
        # brak pinowania wersji akcji

      - name: Configure AWS
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_KEY }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET }}
        # statyczne klucze IAM — długoterminowe

      - name: Build & Push
        run: |
          docker build -t app .
          docker push $IMAGE_NAME
          # brak podpisywania obrazu

      - name: Deploy
        run: kubectl apply -f k8s/
        # brak weryfikacji artefaktu przed deployem

✗Statyczne klucze AWS IAM w sekretach — nie rotowane, długoterminowe, nie audytowalne

✗Akcje bez pinowania SHA — podatne na supply chain attack

✗Brak podpisywania obrazów Docker — audytor nie może zweryfikować origins

✗Push na każdą gałąź wyzwala deploy — brak separation of duties

Po hardeningu — gotowy na audyt

name: Deploy to Production
on:
  push:
    branches: [main]
    # tylko main, po code review

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29
        # pinowany SHA — immutable

      - name: Configure AWS via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{vars.AWS_ACCOUNT}}:role/github-oidc
          # OIDC — zero statycznych kluczy

      - name: Build, Sign & Push
        run: |
          docker build -t $IMAGE .
          docker push $IMAGE
          cosign sign --yes $IMAGE
          # Cosign — kryptograficzny podpis

✓OIDC zamiast kluczy — krótkoterminowe tokeny, automatyczna rotacja, pełny audit trail

✓Akcje pinowane do SHA — odporne na supply chain attack, deterministyczne

✓Cosign podpisuje każdy obraz — audytor weryfikuje provenance kryptograficznie

✓Deploy tylko z main po approved PR — separation of duties udokumentowane

Przed — podatny pipeline

# azure-pipelines.yml
trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

# Sekrety jako zmienne pipeline — statyczne,
# widoczne w logach przy błędzie konfiguracji
variables:
  ARM_CLIENT_SECRET: $(arm-client-secret)
  ARM_CLIENT_ID: $(arm-client-id)
  ARM_SUBSCRIPTION_ID: 'a1b2c3d4-...'

steps:
- task: AzureCLI@2
  inputs:
    azureSubscription: 'prod-service-connection'
    scriptType: bash
    script: |
      az acr build --registry $(acrName) \
        --image myapp:$(Build.BuildId) .
      az webapp deploy --resource-group prod-rg \
        --name my-webapp
# Brak: approval gate, branch policy,
# audytu zmian w pipeline YAML

✗

Statyczne Service Principal w zmiennych — credential leak przy wpisaniu echo w skrypcie

✗

Jeden Service Connection do całego subscription prod — zasada najmniejszych uprawnień złamana

✗

Brak approval gate przed deploymentem na produkcję — każdy merge do main = automatyczny deploy

✗

Pipeline YAML edytowalny bez review — modyfikacja pipeline = nieautoryzowany dostęp do sekretów

Po — utwardzone środowisko

trigger:
  branches:
    include: [main]
  paths:
    exclude: ['**.md']

pool:
  name: 'CyberForge-Ephemeral'
  # Self-hosted, efemeryczny, izolowana sieć

# Zero statycznych sekretów — OIDC Workload Identity
steps:
- task: AzureCLI@2
  inputs:
    azureSubscription: 'wif-acr-only'
    # Service Connection z zakresem tylko do ACR
    addSpnToEnvironment: false
    scriptType: bash
    script: |
      az acr build --registry $(acrName) \
        --image myapp:$(Build.BuildId) .

- task: ManualValidation@1
  condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
  inputs:
    notifyUsers: '[email protected]'
    instructions: 'Zatwierdź deployment na prod'
    timeoutInMinutes: 60

- task: AzureCLI@2
  inputs:
    azureSubscription: 'wif-webapp-deploy-only'
    scriptType: bash
    script: az webapp deploy ...

✓

Workload Identity Federation (OIDC) — zero długożyciowych sekretów, tokeny generowane per-job

✓

Granularne Service Connections — jedno do ACR, drugie do webapp, żadne nie ma dostępu do full subscription

✓

Manual approval gate z powiadomieniem security team — wymagany przed każdym deploymentem na prod

✓

Efemeryczny self-hosted runner w izolowanej sieci — brak dostępu do Internetu po zakończeniu job

Przed — typowy .gitlab-ci.yml

stages:
  - build
  - test
  - deploy

# Sekrety jako zmienne w CI/CD Settings — plaintext
# dostępne w KAŻDYM jobie, KAŻDEJ gałęzi
variables:
  REGISTRY_TOKEN: $CI_REGISTRY_TOKEN
  DEPLOY_SSH_KEY: $SSH_PRIVATE_KEY
  KUBE_CONFIG: $KUBERNETES_CONFIG
  # wszystkie sekrety dostępne we wszystkich jobach

test:
  stage: test
  image: node:latest
  # brak pinowania — "latest" zmienia się bez ostrzeżenia
  script:
    - npm install
    - npm test
    # brak skanowania zależności przed testem

build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    # brak podpisywania — każdy może podmienić obraz
    # brak SBOM — audytor nie ma inwentarza komponentów

deploy:
  stage: deploy
  script:
    - ssh -i $DEPLOY_SSH_KEY user@prod-server
    # statyczny klucz SSH — nie rotowany, nie audytowalny
    - kubectl apply -f k8s/
    # brak weryfikacji artefaktu przed deployem
  only:
    - branches
    # deploy z KAŻDEJ gałęzi — feature też

✗Zmienne CI dostępne we wszystkich gałęziach i forkach — token rejestrowy widoczny w każdym MR z zewnątrz

✗Statyczny klucz SSH do serwera produkcyjnego — jeden wyciek = pełny dostęp do prod, bez możliwości audytu kto i kiedy

✗Brak pinowania wersji obrazów bazowych (docker:latest) — supply chain attack przez podmianę obrazu

✗Deploy z każdej gałęzi — brak separation of duties, każdy deweloper może wyzwolić deploy na produkcję

Po — utwardzony pipeline gotowy na audyt

stages:
  - scan
  - build
  - attest
  - deploy

# Zmienne maskowane i ograniczone do protected branches
variables:
  COSIGN_YES: "true"
  DOCKER_IMAGE: docker:25.0.3-dind@sha256:4a6f...
  # pinowany SHA — immutable, deterministyczny

secret-scan:
  stage: scan
  image: trufflesecurity/trufflehog:3.67.7
  script:
    - trufflehog git --fail file://.
  # blokuje merge przy wykryciu sekretu

build-sign:
  stage: build
  id_tokens:
    SIGSTORE_ID_TOKEN:
      aud: sigstore
  # OIDC token dla Cosign — bez statycznych kluczy
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - cosign sign $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - syft $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -o cyclonedx-json > sbom.cdx.json
    - cosign attest --predicate sbom.cdx.json --type cyclonedx $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy:
  stage: deploy
  environment:
    name: production
  when: manual
  # wymagane ręczne zatwierdzenie w GitLab UI
  script:
    - cosign verify $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    # weryfikacja podpisu PRZED deployem
    - kubectl apply -f k8s/
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

✓OIDC id_tokens dla Cosign — GitLab generuje krótkoterminowy token per-job, zero długożyciowych sekretów w zmiennych

✓TruffleHog jako obowiązkowy gate — każdy push skanowany pod kątem sekretów, blokada merge przy wykryciu

✓Cosign podpisuje obraz + SBOM jako attestacja CycloneDX — audytor weryfikuje provenance kryptograficznie bez dostępu do GitLab

✓Deploy z ręcznym zatwierdzeniem + weryfikacja podpisu przed deployem — separation of duties udokumentowane w GitLab audit log

📑 Szczegóły hardeningu GitHub Actions, GitLab CI i Azure DevOps?

Materiały → Umów Security Snapshot →

Evidence Pack · Demo

Przykładowy SBOM z podpisem Cosign

Poniżej plik CycloneDX o strukturze identycznej z produkcyjnym — taki dokładnie generuje pipeline automatycznie przy każdym buildzie. Audytor dostaje to zamiast deklaracji "używamy bezpiecznych bibliotek".

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-03-12T09:14:22Z",
    "tools": [
      { "name": "syft", "version": "1.4.1", "vendor": "Anchore" }
    ],
    "authors": [{ "name": "CyberForge CI Pipeline" }],
    "component": {
      "type": "container",
      "name": "myapp",
      "version": "2.4.1",
      "purl": "pkg:oci/myapp@sha256:a3b1c9d2e8f47b6...",
      "hashes": [{ "alg": "SHA-256", "content": "a3b1c9d2e8f47b6..." }],
      "properties": [
        { "name": "syft:package:foundBy", "value": "docker-image-cataloger" },
        { "name": "ci:build_id", "value": "1337" },
        { "name": "ci:git_sha", "value": "d4e5f6a7b8c9..." },
        { "name": "ci:git_ref", "value": "refs/heads/main" }
      ]
    }
  },
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.3",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{ "license": { "id": "MIT" } }],
      "hashes": [{ "alg": "SHA-256", "content": "e3b0c44298fc1c149afb..." }],
      // ↑ audytor może zweryfikować hash niezależnie od npm registry
      "externalReferences": [
        { "type": "website", "url": "https://expressjs.com" },
        { "type": "vcs", "url": "https://github.com/expressjs/express" }
      ]
    },
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{ "license": { "id": "MIT" } }],
      "hashes": [{ "alg": "SHA-256", "content": "d7ff4f98feae9a0a..." }]
      // brak znanych CVE — zweryfikowano Trivy 0.51.1 @ 2026-03-12T09:13:44Z
    },
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.13",
      "purl": "pkg:deb/debian/[email protected]",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "hashes": [{ "alg": "SHA-256", "content": "c8f1a2b3d4e5..." }]
      // pakiet OS (debian) — w 3.0.13 brak HIGH/CRITICAL CVE wg NVD
    }
    // ... 244 kolejnych komponentów (npm + debian packages + OS layers)
  ],
  "vulnerabilities": []
  // ↑ puste = skan Trivy nie wykrył CVE w tym buildzie
}

🔑 Weryfikacja podpisu Cosign · Rekor transparency log — to audytor uruchamia samodzielnie, bez dostępu do Waszej infrastruktury

$ cosign verify-attestation \
    --type cyclonedx \
    --certificate-identity "https://github.com/firma/myapp/.github/workflows/release.yml@refs/heads/main" \
    --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
    myapp@sha256:a3b1c9d2e8f47b6...

Verification for myapp@sha256:a3b1c9d2e8f47b6... --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified (Rekor)
  - The signatures were verified against the specified public key
  - Certificate identity matched workflow: release.yml @ refs/heads/main

RekorEntry: https://rekor.sigstore.dev/api/v1/log/entries/362f8ecba0f2...
IntegratedTime: 2026-03-12T09:14:38Z · LogIndex: 182736450
Issuer: https://token.actions.githubusercontent.com (GitHub OIDC)

✓ SBOM jest kryptograficznie powiązany z konkretnym SHA kontenera na prod
✓ Podpis pochodzi wyłącznie z zaufanego pipeline na branchu main
✓ Wpis w Rekor jest niezmienny — audytor może zweryfikować bez Waszej pomocy

📄

DORA / NIS2 / CRA

Art.16 DORA — inwentaryzacja zasobów ICT. Art.21 NIS2 — supply chain. CRA Art.13 — obowiązkowy SBOM dla produktów cyfrowych (2027). Jeden artefakt adresuje trzy regulacje.

🔒

Weryfikowalny bez dostępu do Waszej infrastruktury

Audytor, klient Enterprise lub bank może zweryfikować integralność SBOM samodzielnie — wystarczy publiczny Rekor log i SHA kontenera. Bez VPN, bez ticketów, bez tygodnia czekania.

▶️

Zero dodatkowej pracy dla dewelopera

Syft generuje SBOM automatycznie po buildzie Docker, Cosign podpisuje. Deweloper nie zmienia workflow. Każdy release ma kompletny inwentarz komponentów — historycznie, per build.

📚 Chcesz wiedzieć więcej o SBOM i podpisywaniu artefaktów?

Materiały → Umów Hardening Sprint →

Demo 04 — Evidence Pack

Fragment Evidence Pack — mapowanie kontroli na regulacje

To co dostaje audytor, dział compliance lub klient Enterprise. Każda kontrola techniczna z dowodem i odniesieniem do konkretnego artykułu. Wybierz regulację:

📄 Evidence_Pack_v1.4_myapp_2026-03-12.pdf Wygenerowano automatycznie

Projekt myapp · release 2.4.1 Pipeline build #1337 · main Data 2026-03-12

13

Kontroli spełnionych

11

Częściowo spełnione

+

Wymaga działań org / prawnych

DORA Art.16 NIS2 Art.21 SOC 2 CC Vendor VRA

Pokryte regulacje

Uproszczone ramy zarządzania ryzykiem ICT dla Małych Instytucji Płatniczych (MIP). Obowiązuje od 17.01.2025. Audytor KNF weryfikuje wdrożenie poniższych kontroli.

Wymóg DORA	Kontrola techniczna	Dowód techniczny	Status
Art.16 §2(a) Zarządzanie i klasyfikacja zasobów ICT	Inwentaryzacja komponentów oprogramowania (SBOM)	CycloneDX 1.5 SBOM generowany przez Syft przy każdym buildzie. Archiw w S3 z retention 365 dni. Każdy release posiada podpisany SBOM z pełną listą bibliotek, wersji i licencji.	✓ spełnione
Art.16 §2(b) Ochrona i zapobieganie incydentom ICT	Skanowanie podatności i blokada krytycznych CVE	Trivy scanner uruchamiany przy każdym PR i buildzie. Security gate blokuje merge gdy wykryto CRITICAL lub HIGH CVE bez zaakceptowanego wyjątku. Ostatni skan: 0 krytycznych, 2 wysokie (zaakceptowane z uzasadnieniem).	✓ spełnione
Art.16 §2(c) Wykrywanie anomalii i incydentów	Alerty na wycieki sekretów i anomalie w pipeline	TruffleHog skan przy każdym push — blokada przy wykryciu sekretu. GHAS: 3 alerty w ostatnich 90 dniach, wszystkie zamknięte <24h. Integracja SIEM i routing alertów runtime wymagają konfiguracji poza pipeline (Phase F).	~ częściowe
Art.16 §2(d) Zarządzanie dostępem i uwierzytelnianie	OIDC Workload Identity — eliminacja statycznych sekretów	GitHub Actions ↔ AWS via OIDC federation. Zero długożyciowych kluczy IAM w pipeline. Każdy token ważny max 3600s, scope ograniczony do konkretnego repo i brancha. CloudTrail log każdego assume-role.	✓ spełnione
Art.16 §2(e) Ciągłość działania i backup ICT	Polityki backupu konfiguracji pipeline i sekretów	Cała konfiguracja pipeline jako kod (IaC) w Git — odtworzenie środowiska <30 min. AWS Secrets Manager: automatyczny backup co 24h do drugiego regionu. Ostatni test odtworzenia: 2026-02-15, wynik: OK.	~ częściowe
Art.16 §2(f) Separation of duties i kontrola zmian	Branch protection, wymagane approvals, audit trail	Branch protection rules na main: min. 2 approvals (w tym 1 z security team), blokada direct push, required status checks (testy + security gate). Każda zmiana w pipeline YAML wymaga osobnego review przez senior engineer.	✓ spełnione
Art.16 §2(g) Testowanie odporności systemów ICT	Cykliczne testy pipeline pod kątem scenariuszy awarii	Quarterly chaos engineering: symulacja awarii runnera, rotacja sekretów pod obciążeniem, test rollback proceduralny. Wyniki archiwizowane...	~ częściowe

Dyrektywa NIS2 Art. 21 — środki zarządzania ryzykiem cyberbezpieczeństwa. Dotyczy podmiotów kluczowych i ważnych. Szczególnie istotne: bezpieczeństwo łańcucha dostaw (supply chain security).

Wymóg NIS2	Kontrola techniczna	Dowód techniczny	Status
Art.21 §2(a) Polityki bezpieczeństwa systemów informacyjnych	Policy-as-Code zdefiniowane w pipeline — integracja jako mandatory gate wdrażana w ramach Hardening Sprint	OPA Rego policies zdefiniowane i przetestowane w repozytorium: 23 reguły z pokryciem testów jednostkowych. Integracja z workflow jako blokujący gate konfigurowana per wdrożenie. Formalna dokumentacja polityk bezpieczeństwa i rejestr ryzyka wymagają osobnego procesu organizacyjnego.	~ częściowe
Art.21 §2(b) Obsługa incydentów — wykrywanie i reagowanie	Automatyczne wykrywanie w pipeline — runbooki IR wymagają procesu organizacyjnego	GHAS secret scanning + Dependabot alerts zintegrowane z Jira (auto-ticket przy HIGH/CRITICAL). MTTR z ostatnich 90 dni: 18h dla krytycznych. Formalne runbooki IR, klasyfikacja incydentów i eskalacja do regulatora wymagają konfiguracji poza pipeline.	~ częściowe
Art.21 §2(d) Bezpieczeństwo łańcucha dostaw (Supply Chain)	Pinning akcji do SHA, weryfikacja provenance artefaktów	Wszystkie zewnętrzne GitHub Actions przypięte do pełnego commit SHA (nie tag). Pipeline adresuje wymagania SLSA Level 2: podpisane provenance dla każdego buildu generowane przez zaufaną platformę. Cosign weryfikacja obrazu Docker przed deployem — blokada przy niezgodności podpisu.	✓ spełnione
Art.21 §2(e) Bezpieczeństwo w nabywaniu i utrzymaniu systemów	SAST, SCA i IaC scanning jako mandatory gates	CodeQL (SAST) uruchamiany na każdym PR — wyniki widoczne w code review. Trivy SCA: skanowanie zależności i obrazów. Checkov IaC: weryfikacja Terraform przed apply. Wszystkie 3 są required status checks.	✓ spełnione
Art.21 §2(f) Polityki i procedury oceny skuteczności środków	Metryki bezpieczeństwa pipeline — raportowanie miesięczne	Dashboard Grafana z KPI: liczba zablokowanych buildów (security gate), MTTR podatności, % pipelineów z aktywnym skanem. Raport generowany automatycznie 1. dnia każdego miesiąca do CISO.	~ częściowe
Art.21 §2(h) Bezpieczeństwo zasobów ludzkich, szkolenia	Security Champions program i onboarding deweloperów	Runbook hardeningu pipeline przekazany zespołowi. Sesja handover 4h z senior engineers. Dokumentacja operacyjna w Confluence.	~ częściowe
Art.21 §2(i) Kryptografia i szyfrowanie	Szyfrowanie sekretów w spoczynku i tranzycie	AWS Secrets Manager (AES-256, KMS CMK). TLS 1.3 na wszystkich endpointach pipeline. Rotacja kluczy KMS co 90 dni. Certyfikaty...	✓ spełnione

SOC 2 Type II — Trust Services Criteria (TSC). Najczęściej wymagany przez klientów Enterprise z USA. Poniższe kontrole pokrywają Common Criteria (CC) istotne dla środowiska CI/CD.

Kryterium SOC 2	Kontrola techniczna	Dowód techniczny	Status
CC6.1 Logical and physical access controls	Kontrola dostępu do repo i pipeline — IAM governance poza pipeline	GitHub org: SAML SSO wymagany, MFA enforced. GITHUB_TOKEN scope granularny (contents:read, packages:write). OIDC eliminuje statyczne klucze CI/CD. Fizyczne kontrole dostępu i cykliczne access reviews wymagają osobnych procedur organizacyjnych.	~ częściowe
CC6.2 Authentication prior to access	OIDC + MFA dla wszystkich punktów wejścia do pipeline	Brak statycznych kluczy w CI/CD — uwierzytelnianie wyłącznie przez OIDC federation (GitHub ↔ AWS/Azure). Konsola AWS: MFA required policy (SCP). Każde logowanie audytowane w CloudTrail z retencją 1 rok.	✓ spełnione
CC7.1 Detection of security events	Wykrywanie w pipeline — monitoring runtime i SIEM wymagają konfiguracji org	TruffleHog: skan każdego commit + historia Git. GHAS: secret scanning + code scanning. Cosign weryfikacja przed deployem. Integracja SIEM (Elastic/GuardDuty), on-call runbooki i pokrycie systemów poza pipeline wymagają osobnej konfiguracji.	~ częściowe
CC8.1 Change management	Audytowalny proces zmian w pipeline i infrastrukturze	Wszystkie zmiany przez PR (Git flow). Pipeline YAML: required review od 2 osób, w tym 1 senior security engineer. Terraform: plan review przed apply, state w S3 z versioning. Change log eksportowany do audytorów na żądanie.	✓ spełnione
CC9.1 Risk assessment — vendor management	Weryfikacja zależności i akcji w pipeline — vendor governance poza pipeline	GitHub Actions pinowane do SHA. Trivy SCA skanuje zależności npm/python/go przy każdym buildzie. SBOM + provenance jako dowód supply chain. Formalny program zarządzania dostawcami, due diligence i przegląd kontraktów wymagają osobnego procesu.	~ częściowe
A1.2 Availability — recovery procedures	Odtwarzalność pipeline i środowisk z kodu (IaC)	Pełna infrastruktura jako Terraform — czas odtworzenia <45 min (zmierzone). Runnerzy efemeryczni: auto-provisioning z AMI. GitHub Actions workflow: idempotentne, każdy run deterministyczny. RTO <2h, RPO = 0 (config w Git).	~ częściowe
PI1.1 Processing integrity	Integralność artefaktów: podpisy cyfrowe i weryfikacja	Cosign podpisuje każdy obraz Docker przy buildzie. Weryfikacja podpisu przed deployem (admission controller Kubernetes). Rekor transparency log — każdy podpis publicznie weryfikowalny...	✓ spełnione

Typowe pytania z ankiet Vendor Risk Assessment (VRA) od klientów Enterprise — banków, ubezpieczycieli, korporacji z USA i DACH. To najczęstsza blokada sprzedaży dla polskich software houseów.

Pytanie z ankiety VRA	Dowód techniczny	Szczegóły	Odpowiedź
Czy stosujecie MFA dla wszystkich użytkowników z dostępem do kodu źródłowego?	GitHub org: MFA enforced	GitHub Organization policy: „Require two-factor authentication for everyone". Weryfikacja: export listy członków org — 100% ma aktywne 2FA. SAML SSO zintegrowany z Entra ID (Azure AD). Screenshot konfiguracji w załączniku A.	✓ Tak
Jak zarządzacie sekretami i kluczami API w procesie CI/CD?	OIDC + AWS Secrets Manager	Zero statycznych kluczy w pipeline — uwierzytelnianie przez OIDC Workload Identity Federation. Sekrety aplikacyjne w AWS Secrets Manager z automatyczną rotacją co 30 dni. Audyt: brak kluczy w zmiennych środowiskowych CI (weryfikacja TruffleHog — raport w załączniku B).	✓ Tak
Czy kod przechodzi przez zautomatyzowane testy bezpieczeństwa przed wdrożeniem?	SAST + SCA + IaC scan	Required status checks blokujące merge: (1) CodeQL SAST — analiza statyczna kodu, (2) Trivy SCA — skanowanie zależności i obrazów Docker, (3) Checkov — weryfikacja Terraform. Żaden PR nie może zostać zmergowany przy aktywnym alarme CRITICAL. Logi z ostatnich 30 buildów w załączniku C.	✓ Tak
Jaką macie politykę zarządzania podatnościami w bibliotekach open source?	Dependabot + SLA naprawy	Dependabot auto-PR dla każdej biblioteki z CVE. SLA: CRITICAL ≤24h, HIGH ≤7 dni, MEDIUM ≤30 dni. Metryki z ostatnich 90 dni: 12 CRITICAL, śr. czas naprawy 11h. SBOM eksportowany przy każdym release.	✓ Tak
Czy posiadacie udokumentowany proces zarządzania zmianami w kodzie produkcyjnym?	Git flow + change log	Każda zmiana przez Pull Request z min. 2 recenzentami (1 z security team). Direct push do main zablokowany (branch protection). Wymagane: powiązanie z ticketem Jira, opis zmian, test coverage ≥80%. Eksport change logu za żądany okres — dostępny na żądanie audytora.	✓ Tak
Czy wykonujecie regularne testy penetracyjne lub security assessments?	Snapshot + roczny pentest	CI/CD Security Snapshot: kwartalny audyt konfiguracji pipeline. Zewnętrzny pentest aplikacji: planowany cyklicznie przez zespół klienta. Wyniki ostatniego Snapshotu: 0 krytycznych, 2 wysokie (naprawione), raport dostępny pod NDA.	~ częściowe
Opisz procedury reagowania na incydenty bezpieczeństwa w środowisku produkcyjnym.	Incident Response Runbook	Runbook IR dostępny w Confluence (wersja 2.1). Eskalacja: dev → senior → CISO → zarząd. Czas powiadomienia klienta: <4h od wykrycia. Testy procedury: 2x w roku...	✓ Tak

🔒 Pełny Evidence Pack — otrzymujesz po wykonaniu usługi Hardening Sprint

Materiały → Umów Hardening Sprint →

Zobacz zanim
zdecydujesz.

Raport CI/CD Security Snapshot

Pipeline CI/CD: przed i po hardeningu

Przykładowy SBOM z podpisem Cosign

Fragment Evidence Pack — mapowanie kontroli na regulacje

Demo wygląda znajomo?

Zobacz zanimzdecydujesz.

Raport CI/CD Security Snapshot

Pipeline CI/CD: przed i po hardeningu

Przykładowy SBOM z podpisem Cosign

Fragment Evidence Pack — mapowanie kontroli na regulacje

Demo wygląda znajomo?

Zobacz zanim
zdecydujesz.