divyanshukumar0014/shipproofSOC-2-Nachweise, die sich in GitLab CI selbst sammeln: Jeder Merge erzeugt ein signiertes Bundle, ein OPA-Gate blockiert Releases bei fehlenden Belegen, und Prüfer erhalten einen Link statt Screenshots.
SOC-2-Nachweise, die sich selbst in GitLab CI sammeln: Jeder Merge erzeugt ein signiertes Bundle, ein Open-Policy-Agent-Gate blockiert Releases mit fehlenden Nachweisen, und ein Auditor erhält einen einzigen Paket-Link statt Screenshots.
Live-Auditor-Dashboard · GitLab-Projekt · Demo-Nachweise · Roadmap
Ich habe ShipProof gebaut, weil Enterprise-Vertriebsprozesse bei der Infosec-Prüfung immer wieder ins Stocken geraten. Wenn ein Auditor SOC-2-Type-II-Nachweise für das Change-Management anfordert, verbringen Entwickler oft zwei Wochen damit, Screenshots in Jira, Slack und Drive zusammenzusuchen.
Ich wollte, dass Nachweise direkt in der Deployment-Pipeline leben. Jeder Merge-Commit in ShipProof erzeugt automatisch ein kanonisches, signiertes Nachweis-Bundle, das Testläufe, Semgrep-SAST-Scans, Gitleaks-Secret-Erkennung, Syft-Software-Stücklisten und CODEOWNERS-Genehmigungen abdeckt.
Meine zentrale Designregel ist strikt: Ein LLM darf Nachweise zusammenfassen oder Issue-Beschreibungen entwerfen, aber niemals ein Release genehmigen. Das Release-Gate ist eine in Rego geschriebene Open-Policy-Agent-Auswertung. Fehlt ein Artefakt oder sieht eine Genehmigung wie ein reiner Gummistempel aus, schlägt das Gate fail-closed fehl, stoppt das Release und legt ein Issue mit dem Lösungspfad an. Wenn das Gate zustimmt, erhält der Auditor einen einzigen Link zu einer statischen Seite oder einer authentifizierten API.
Ich habe ShipProof gegen den GitLab-DevOps-Lifecycle abgebildet. Es automatisiert alle neun Phasen nativ:
| Phase | Was ich in der Pipeline automatisiert habe |
|---|---|
| plan | Geschlossene Lücken-Work-Item-Verwaltung. Gate-Ablehnungen öffnen automatisch strukturierte Tracking-Issues mit Wiederholungszählern; nachfolgende erfolgreiche Pipelines lösen die Issues automatisch auf und schließen sie mit Verweisen auf die Fix-Commits. |
| create | Code-Review und Quellverwaltung. CODEOWNERS schützt Policy-Dateien; das Gate lehnt Gummistempel-Genehmigungen unter fünf Minuten ab; automatisierte MR-Notizen leiten das Review an; Duo-Flows erzählen MR-Kommentare. |
| verify | pytest, Semgrep SAST und Gitleaks laufen in der Verify-Phase und zeichnen Artefakt-Hashes auf. |
| package | Syft erzeugt CycloneDX-SBOMs in der Package-Phase und hasht das Artefakt in das Bundle. |
| secure | Das deterministische OPA-Gate prüft Signaturen, Ketten-Hashes und Gummistempel-Regeln vor dem Release. |
| release | Der Compliance-Gate-Job blockiert das Deployment in die Produktion; Deploy-Jobs erfordern ein Allow-Verdikt. |
| configure | Cloud-Run-Deployment-Manifeste werden aus Umgebungsvariablen gerendert, ohne Secrets zu committen. |
| monitor | Post-Deploy-Prüfungen verifizieren, dass die Digests der laufenden Container-Images mit dem bundle-genehmigten Commit übereinstimmen. |
| govern | Ein unveränderliches hash-verkettetes Ledger speist Auditor-Pakete, Lücken-Issues und das GitLab-Pages-Dashboard. |
Ich habe ShipProof mit Python 3.11 und Node.js 20 entwickelt.
python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt
Führe meine Testsuite und Typprüfungen aus:
OPA_BIN=/tmp/opa pytest -q && ruff check src tests demo-app scripts && mypy --strict src scripts
Sammle ein lokales Bundle für jeden Commit:
PYTHONPATH=src python -m comply.collect --sha aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa --out /tmp/bundle.json
Der Collector gibt eine einzelne JSON-Zeile an stdout aus und schreibt das vollständige Bundle zusammen mit policy/inputs.json auf die Festplatte. Wenn Nachweise fehlen, zeichnet das Bundle einen Deny-Status auf.
PYTHONPATH=src python -m comply.collect --sha <40-hex-sha> --out evidence/bundle.json \
--mr-iid 42 --pipeline-id 1001 --project group/project \
--pipeline-file pipeline.json --approvals-file approvals.json
In CI bereitet scripts/gate_bridge.py die Datei pipeline.json vor, während scripts/fetch_approvals.py Review-Daten aus der GitLab-API abruft. Fehlende Dateien werden als fehlender Status erfasst und nicht als bestanden angenommen. Jedes stderr-Log enthält die Bundle-Korrelations-ID, und Secrets werden als *** maskiert.
PYTHONPATH=src python -m comply.gate --bundle evidence/bundle.json --ledger logs/ledger.jsonl
Exit-Code 0 zeigt ein Allow-Urteil an. Exit-Code 1 zeigt eine Ablehnung mit einem strukturierten Fehler an, der die fehlgeschlagene Kontrolle benennt. Exit-Code 2 zeigt ungültige Argumente an. Wenn das Gate in CI blockiert, löst die Pipeline python -m comply.gap aus, um ein Tracking-Issue zu eröffnen.
PYTHONPATH=src python -m comply.packet --ledger logs/ledger.jsonl --release all \
--out packet.json --csv packet.csv --pdf packet.pdf
Der CSV-Export enthält elf Spalten: bundle_id,commit_sha,mr_iid,pipeline_id,control,proof_type,status,artifact_sha,approver_ids,policy_sha,created_at. Das PDF wird aus derselben JSON-Quelle über Print-CSS gerendert.
AUDITOR_TOKEN=local-only PYTHONPATH=src uvicorn comply.api:app --port 8000
Abfragen von Bundles mit Bearer-Authentifizierung:
curl -H "Authorization: Bearer local-only" "localhost:8000/api/v1/bundles?mr_iid=42"
Die API stellt Endpunkte für Bundle-Abfragen, Release-Pakete und Hintergrund-PDF-Exporte bereit, geschützt durch Bearer-Tokens und ein Ratenlimit von 60 Anfragen pro Minute.
cd auditor && npm install && npm run build
Die Oberfläche ist mit React 19, TypeScript und Tailwind CSS aufgebaut. Sie wird als statische Website mit Hash-Routing exportiert, sodass sie direkt auf GitLab Pages ohne Server-Rewrites ausgeführt werden kann. Wenn keine Backend-API vorhanden ist, werden Beispieldaten aus public/fallback/demo-packets.json verwendet.