Sicherheitsfunktionen im Überblick
Alles, was fremforge mitbringt, in einer Tabelle zum schnellen Überfliegen. Jede Zeile verlinkt auf die eigene Seite mit Konfiguration, Ablauf für Übersteuerungen und der Dokumentation des zugrunde liegenden Werkzeugs.
fremforge ist bewusst transparent, was die Open-Source-Werkzeuge unter jeder Maßnahme angeht: Kundinnen und Kunden, die nach BSI C5, ISO 27001, BaFin oder ENISA-regulierten Vorgaben geprüft werden, brauchen den Prüfpfad auf Werkzeugebene, und wir möchten lieber, dass du in unserem Quellcode suchen kannst, als dass du eine Blackbox zurückentwickeln musst. Der Unterschied liegt in der Integration (Hooks, RBAC, Audit-Kette, Datenhaltung in der EU, kein Microsoft, kein AWS), nicht im Scanner.
Kontrollen beim Code-Push
| Maßnahme | Was sie tut | Werkzeug | Pro Mandant konfigurierbar |
|---|---|---|---|
| Push-Schutz | Secret-Scan beim Pre-Receive; weist Commits mit Zugangsdaten ab, bevor sie in die Git-Historie gelangen | Gitleaks v8 (über 120 Muster) | Übersteuerungsregeln + Umgehung pro Muster |
| Branch-Schutz | Regeln pro Branch: erforderliche Reviewer, Status-Checks, Pflicht zu signierten Commits, Sperre von Force-Pushes | In Forgejo integriert | Ja (pro Branch) |
| Zwei-Faktor-Auth | TOTP für jedes Benutzerkonto; WebAuthn-Pflicht auf Organisationsebene verfügbar (die Registrierung von WebAuthn durch Benutzer erfolgt auf der Sicherheitsseite der Forgejo-Benutzereinstellungen). Pro Organisation erzwingbar | In Forgejo integriert + eigene Durchsetzungs-Hooks | Ja (organisationsweit erzwingen, Opt-in pro Benutzer) |
| OIDC-MFA-Verifizierung | Prüft bei jeder Anmeldung kryptografisch über den OIDC-Claim amr (RFC 8176), dass dein IdP MFA bestätigt hat. Ersetzt das alte, vom Operator bestätigte Kontrollkästchen „IdP-MFA vertrauen“: Das Token sagt ["pwd","mfa"], oder es ist keine MFA | Eigene Middleware zur Claim-Prüfung | Richtlinie für erforderliche amr-Werte pro Mandant |
| SSO-Break-Glass | Ist dein IdP nicht verfügbar, falsch konfiguriert oder die SSO-Verbindung gestört, können benannte Owner der Organisation den Zugriff über einen getrennt verwalteten Break-Glass-Zugang wiederherstellen. Im Audit-Log erfasst | Eigenentwicklung (von fremforge geschrieben) | Benannte Owner pro Mandant |
| Schlüsselloses Commit-Signieren (sigstore / gitsign) | An OIDC gebundenes Signieren: Deine IdP-Identität (Entra, Okta, Google Workspace, Authentik) signiert den Commit über ein 10-Minuten-Zertifikat von Fulcio. Forgejo zeigt Verified by sigstore: <email> via <IdP> an. Root-CA in T Cloud Public DEW KMS (FIPS 140-2 Level 3 HSM, Deutschland). Fulcio unter sign.frem.sh, TSA unter tsa.frem.sh. Bewusst kein Rekor / kein Transparenzprotokoll: nur TSA-verankerte Zeitstempel, damit Signaturen in keinem Protokoll Dritter landen | Selbst gehosteter Fulcio v1.8.5 + TSA auf T Cloud Public eu-de, gitsign auf Kundenseite | Organisations-Admin → Allowed OIDC issuers + Strenge |
| Commit-Signieren mit SSH-Schlüssel | Commits mit demselben SSH-Schlüssel signieren, den Forgejo für den Push verwendet. Das Badge „Verified“ erscheint direkt in der Weboberfläche. Funktioniert neben dem schlüssellosen Signieren; der Organisations-Admin legt die Strenge fest | OpenSSH + allowedSignersFile von Forgejo | Pro Benutzer aktivierbar |
| Commit-Signieren mit GPG | Der übliche Ablauf mit git commit.gpgsign. Öffentlichen Schlüssel in den Benutzereinstellungen hochladen; Forgejo prüft und zeigt das Badge „Verified“ an | GnuPG + in Forgejo integriert | Pro Benutzer aktivierbar |
Codequalität und Schwachstellen-Scanning
Diese Scanner laufen zentral auf den eigenen Scannern von fremforge, bei jedem Pull Request und auf dem Standard-Branch. Du musst keine Workflow-Datei in deinen Repositorys installieren. Die Ergebnisse stehen unter Sicherheit › Befunde.
| Maßnahme | Was sie tut | Werkzeug | Konfigurierbar |
|---|---|---|---|
| SAST | Statische Analyse bei jedem PR und auf dem Standard-Branch, zentral auf den eigenen Scannern von fremforge ausgeführt: keine Workflow-Datei in deinem Repository, die du installieren oder pflegen musst. Erkennt Injection, XSS, fest codierte Secrets und gefährliche APIs in C, C++, C#, Go, Java, JavaScript und TypeScript, Kotlin, PHP, Python, Ruby, Rust, Scala, Swift und Bash | OpenGrep mit den GitLab-sast-rules, den C/C++-Regeln von 0xdea und den eigenen Regeln von fremforge | Blockier-Schweregrad; deine eigenen OpenGrep-Regeln, jede vor dem Einsatz an ihrem eigenen Beispiel geprüft |
| Secret-Scanning | gitleaks bei jedem Pull Request (der Check fremforge/secret-scan) und ein wöchentlicher Durchlauf über die vollständige Historie jedes Repositorys; der Push-Schutz blockiert Secrets bereits beim Push | Gitleaks | Pull-Request-Check ein oder aus |
| IaC-Scanning | Prüfungen auf Fehlkonfigurationen mit trivy config (Dockerfile, Compose, Kubernetes, Helm, Terraform und mehr) bei jedem PR, als Check fremforge/iac-scan mit eigenem Befund-Tab, dazu die eigenen Rego-Checks deiner Organisation; blockiert nur bei dem, was ein PR hinzufügt; Befunde im Compliance-Bericht nach CIS-Benchmark und NIS2-Bereich gruppiert | Trivy | Modus und Schwellenwert unter Sicherheit › Richtlinien › Scanner |
| Abhängigkeits-Scanning (OSV) | CVE/GHSA-Scan der Abhängigkeiten bei jedem PR, zentral auf den eigenen Scannern von fremforge ausgeführt. Zeigt behebbare CVEs mit dem vorgeschlagenen Upgrade | osv-scanner | Schwellenwert für den Schweregrad |
| Erreichbarkeit | Markiert jeden Befund zu Abhängigkeiten und Images als erreichbar, nicht erreichbar oder unbekannt, mit dem Nachweis (Datei und Zeile oder die betroffene Funktion), und sortiert Listen, Empfehlungen und den Digest danach. Go: govulncheck auf den Binaries in deinen Images. JavaScript und TypeScript: Jelly, auf Import-Ebene, sofern die Advisory keine Funktionen nennt. Python, Java und Kotlin: Import-Ebene, auch über andere Pakete hinweg, nie unreachable. Nichts wird ausgeblendet oder verworfen; was einen Merge blockiert, bleibt unverändert, solange du nichts anderes einschaltest | govulncheck, Jelly, Import-Leser von fremforge | Optionaler SLA-Multiplikator (1-4) für nicht erreichbare Befunde; optional „Pull Requests bei nicht erreichbaren Befunden nicht blockieren“ |
| Bekanntermaßen ausgenutzt | Markiert Befunde, deren CVE in der EU-Schwachstellendatenbank der ENISA oder im KEV-Katalog der CISA als ausgenutzt gelistet ist: ein Badge und ein Filter, vor EPSS eingeordnet, nie mit verlängerter SLA, bei AutoFix zuerst. Beide Listen werden täglich aktualisiert | Spiegel von ENISA EUVD + CISA KEV | - |
| Sicherheitskorrekturen | Ein Klick öffnet einen Pull Request, der eine verwundbare Abhängigkeit auf die niedrigste Version anhebt, die jede offene Advisory behebt (die Ökosysteme unter Unterstützte Ökosysteme), oder die FROM-Basis eines Images anhebt; Fix all pro Repository. Wird nie automatisch gemergt. Optionale KI-Korrekturen für eine kurze Liste von SAST-Regeln verwenden ausschließlich deinen eigenen Modellanbieter und sind standardmäßig aus | Gehostetes Renovate; dein eigener KI-Anbieter für SAST-Korrekturen | Grenzen pro Repository und pro Organisation; KI-Korrekturen standardmäßig aus |
| Regelbasierte Korrekturen | Korrektur-PR öffnen bei einem Secret-Befund verschiebt die Zugangsdaten in eine Umgebungsvariable (Go, Python, JavaScript, TypeScript); bei sechs IaC-Checks setzt es die Eigenschaft auf ihren sicheren Wert. Eine feste Regel, keine KI: Nichts verlässt fremforge. Vorher auf Syntax geprüft und erneut gescannt, nie automatisch gemergt | gitleaks und Trivy, die Scanner, die den Befund gemeldet haben | Grenzen pro Repository und pro Organisation |
| Container-Image-Scanning | Der zentrale Scanner von fremforge führt Trivy aus (ohne Installationsschritt): trivy fs und trivy config bei jedem PR, trivy image auf jedem Image in deiner Registry und jedem Image, das über den Dependency-Proxy gezogen wird. Die Befunde stehen unter Sicherheit › Befunde › Container-Images, verknüpft mit Image und Commit. Eine Sperraktion für Images (none, warn, block_pull) gilt für Befunde ab dem Image-Schwellenwert, standardmäßig hoch | Trivy | Sperraktion, Schwellenwert und Ignore-Dateien |
| Lizenz-Scanning | Lizenzerkennung mit Trivy bei jedem PR, zentral auf den eigenen Scannern von fremforge ausgeführt. Ordnet die Lizenz jeder Abhängigkeit einem von 7 Schweregraden der SPDX-Richtlinie zu (permissiv → reziprok → eingeschränkt → verboten); blockiert den Merge bei Befunden ab dem eingestellten Schwellenwert. Zu finden unter Sicherheit › Befunde › Lizenzen | Trivy | Blockier-Schweregrad + SPDX-Allowlist + Verwerfen pro Befund |
| OpenSSF Scorecard | Wöchentliche Best-Practice-Bewertung pro Repository. Kein Workflow pro Repository: läuft wöchentlich auf isolierter Plattforminfrastruktur mit einem schreibgeschützten Bot pro Mandant, der nur Lesezugriff auf Repositorys hat; unveränderte Repositorys werden übersprungen, und nur das Score-JSON wird aufbewahrt. Zeigt Lücken (Branch-Schutz, MFA-Pflicht, festgelegte Abhängigkeiten, Abdeckung durch Code-Reviews) als Spalte auf der Seite Repos | scorecard | Wöchentlicher Rhythmus + Überspringen bei unverändertem HEAD |
| Schädliche Pakete | OSV-Advisories MAL-*, abgeglichen mit der SBOM des Standard-Branches jedes Repositorys und den Sprachpaketen in jedem veröffentlichten Container-Image, nach jedem Push und täglich. Immer kritisch; Pulls eines Images mit offenem Befund werden abgewiesen | osv-scanner + Trivy | Verwerfen mit Begründung und Enddatum |
| Paketrichtlinien | Eine Richtlinie pro Organisation entscheidet, welche Registry-Pakete heruntergeladen werden dürfen: Schwachstellen-Schwellenwerte (Schweregrad, CVSS, EPSS, Korrektur verfügbar), SPDX-Lizenzlisten, Erlaubt- und Verboten-Listen mit Versionsbereichen und ein Mindestalter. Ausnahmen muss eine zweite Person freigeben. Durchsetzen weist mit 403 ab, Schatten (der Standard) protokolliert; eine Datei, die bekannte Malware bündelt, wird in jedem Modus abgewiesen. Container-Images: nur Schatten | Syft + osv-scanner | Modus, Regeln, Übersteuerungen pro Typ, Ausnahmen |
| Malware-Scan bei Uploads | ClamAV über Git-LFS-Objekte, Web-Anhänge und Paket-Uploads. Der Dependency-Proxy scannt geholte Pakete und Image-Layer mit ClamAV, wenn deine Organisation das einschaltet (standardmäßig aus) | ClamAV mit Signaturen von SaneSecurity, YARA-Forge Core und Linux Malware Detect | Übersteuerung bei bekannten Fehlalarm-Signaturen |
| Sicherheitsprüfung für Workflows | Eine Pre-Receive-Prüfung parst jede geänderte Workflow-YAML und weist Pushes ab, die Folgendes einführen: docker://-Verweise auf nicht freigegebene Registrys, gefährliche Injection-Muster aus pull_request_target + script, nicht festgelegte uses:-Verweise auf nicht gespiegelte Organisationen | Eigene Regeln (von fremforge geschrieben) | Übersteuerung der docker-URI-Allowlist pro Mandant |
| IP-Allowlist | Eine Liste erlaubter CIDR-Bereiche pro Organisation für jede HTTPS-Oberfläche: Web-Admin, fremforge-API, Weboberfläche der Repositorys, Forgejo-REST-API, Git über HTTPS, LFS und Paket-Registrys. Git über SSH ist nicht abgedeckt. Vorschau im reinen Audit-Modus und 24-Stunden-Break-Glass für Owner | Eigene Regeln (von fremforge geschrieben) | CIDR-Liste pro Mandant + Schalter für Runner |
Herkunftsnachweise in der Lieferkette
| Maßnahme | Was sie tut | Werkzeug | Konfigurierbar |
|---|---|---|---|
| SBOMs | SBOMs in CycloneDX 1.6 und SPDX 2.3, zentral bei jedem PR erzeugt (beide Formate werden beim Einspeisen akzeptiert). Beim Veröffentlichen eines Release wird die SBOM, die für diesen Commit bereits vorliegt, an das Release gebunden, statt neu zu scannen; eine Release-SBOM braucht also keinen Build und erscheint sofort. Abfragbar unter Sicherheit › Komponenten › SBOMs | Syft | Aufbewahrungszeitraum + Release-Refs |
| Signierte Veröffentlichungs-Attestierung | Ein in-toto/SLSA-Provenienz-DSSE-Umschlag, serverseitig von fremforge bei den Forgejo-Webhooks release.published / package erzeugt: keine Workflow-Datei in deinen Repositorys. fremforge hasht jedes Asset und signiert mit einem Ed25519-Schlüssel der Plattform (keyid fremforge-slsa-builder-v1, builder https://frem.sh/runner-controller/v1), hochgeladen neben dem Asset als <asset>.intoto.jsonl, dazu eine zweite, schlüssellose Signatur über den selbst gehosteten Fulcio + RFC3161-TSA von fremforge als <asset>.sigstore.json. Kein öffentliches Sigstore, kein Rekor, kein Transparenzprotokoll. Lokal mit dem veröffentlichten Trust Root verifizieren, siehe SLSA-Provenienz. Bewusst nicht als SLSA-Level bezeichnet: Sie bestätigt, was VERÖFFENTLICHT wurde, nicht wie es gebaut wurde; die Herleitung und was fehlt, stehen unter SLSA-Provenienz | Eigener serverseitiger Signierer (Node-stdlib crypto, Ed25519-DSSE) + selbst gehostetes Sigstore | — |
| Cosign: Images signieren und verifizieren | Der zentrale Pull-Request-Check fremforge/cosign-verify prüft die Signaturen von per Digest festgelegten Images, entweder aus den eigenen Workflows deiner Organisation über das Sigstore von fremforge oder aus dem öffentlichen Sigstore, und sagt, wenn er nicht prüfen konnte. Er ist nur informativ. Die Signaturrichtlinie für Images kann außerdem beim Pull signierte Images mit deinen vertrauenswürdigen Identitäten verlangen. Kunden-CI signiert mit ihrer eigenen OIDC-Identität: keine langlebigen Signaturschlüssel | cosign + selbst gehosteter Fulcio | Signaturrichtlinie (Schatten oder durchsetzen) |
| Festlegen von Workflows | Ein täglicher Scan listet jedes uses: in .forgejo/workflows/, .gitea/workflows/ und .github/workflows/ auf, das auf einen Tag oder Branch statt auf einen 40-stelligen Commit-SHA zeigt, und jedes docker://-Step-Image, das per Tag statt per Digest referenziert wird; ein Klick öffnet einen Pull Request, der die Actions festlegt | Eigenentwicklung (von fremforge geschrieben) | — |
| Action-Mirror | uses: actions/checkout@v4 wird zu frem.sh/actions/checkout aufgelöst: ein in Forgejo integrierter Pull-Mirror des Upstreams mit 8-stündiger Synchronisierung. Kein Abruf von github.com zur Build-Zeit auf dem kritischen Pfad der Kundschaft. Zu den gespiegelten Organisationen gehören actions, docker, pnpm, aws-actions, azure, google-github-actions, peter-evans, softprops, sonarsource, step-security, dorny | In Forgejo integrierter Pull-Mirror (Auflösung von Actions nur in der EU) | (Vom Operator verwaltet; für Kundinnen und Kunden transparent) |
| Kompatibilität mit dem Marketplace | Die 20 meistgenutzten Actions aus dem GitHub Marketplace, geprüft auf unveränderte Funktion in fremforge: GITHUB_TOKEN, GITHUB_SHA, GITHUB_REF, GITHUB_API_URL usw. werden identisch befüllt | Forgejo-Actions-Laufzeit | — |
| Abhängigkeits-Updates | Versions-Updates durch Renovate für jede aufgenommene Organisation, jede Nacht, dazu Jetzt ausführen. Erkennt veraltete Abhängigkeiten, Action-Versionen und Container-Basis-Images. Repositorys können sich abmelden | Renovate + eigene Orchestrierung | Opt-out pro Repository |
Laufzeitisolation (gehostete CI-Runner)
| Maßnahme | Was sie tut | Werkzeug | Konfigurierbar |
|---|---|---|---|
| Sandbox für gehostete Runner | Ein Commit = eine eigene VM = ein Kernel. Die Plattform startet pro Commit eine frische, kurzlebige ECS-VM, registriert forgejo-runner --ephemeral, sodass jede Registrierung von genau einem Task verbraucht wird, und zerstört die VM, sobald die Jobs dieses Commits abgeschlossen sind. Keine zwei Kunden und keine zwei Commits teilen sich je einen Kernel; Jobs desselben Commits können sich die VM teilen, behandle eine Pipeline also als eine Vertrauensdomäne. Jede VM hat ihr eigenes ENI + ihre eigene Security Group (Netzwerkisolation) und keine IAM-Agency (kein Zugriff auf Plattform-APIs von innen). Ein separater Aufräum-Mechanismus beendet verwaiste VMs, deren Runner sich nie registriert oder nie fertig geworden ist. Dasselbe Modell wie bei den gehosteten Runnern von GitHub und GitLab | T Cloud Public ECS + ENI pro VM + forgejo-runner (act_runner) | VM-Flavor (Obergrenze für CPU/RAM), Parallelitätsgrenze pro Mandant |
| Parallelitätsgrenze pro Mandant | 2 parallele Jobs pro Nutzer garantiert (mindestens 10, höchstens 60), und bis zu 60, wenn Kapazität frei ist (GitHub-hosted: Free 20, Pro 40, Team 60). Mehr auf Anfrage | Durchsetzung auf Plattformebene | Übersteuerung pro Mandant |
| Kontingent an Runner-Minuten | seat_cap × 1000 min/month. Testmandanten haben ein pauschales Kontingent von 500 Minuten, siehe Abrechnung. Mandanten mit aktivierter Überschreitung laufen weiter; bei anderen wird die Zuteilung verweigert | Prüfung vor der Zuteilung gegen die gemessene Nutzung | Übersteuerung der Obergrenze pro Mandant |
| Egress-Proxy | Kunden-Workflows erreichen das öffentliche Internet über den Egress-Proxy der Runner (nur SSRF-Sperre, CGNAT-tolerant, entspricht dem Verhalten von GitHub-hosted) | Eigener Proxy (von fremforge geschrieben, auf Hono-Basis) | — |
| Laufzeit pro Job | Standardmäßig 60 Minuten pro Job, harte Obergrenze 360 Minuten. Ein separater Aufräumer löscht verwaiste VMs, mit einer absoluten Grenze von 6 h 10 min | Separater Aufräumer | timeout-minutes auf Step-Ebene |
Secrets und Zugriffskontrolle
| Maßnahme | Was sie tut | Werkzeug | Konfigurierbar |
|---|---|---|---|
| Deploy-Secrets | Verschlüsselte Secrets pro Umgebung. Im Ruhezustand AES-256-GCM mit einem MASTER_ENCRYPTION_KEY in DEW KMS. Nur innerhalb der Runner-VM entschlüsselt, die sie braucht. Die Schlüsselrotation unterstützt ein Zwei-Schlüssel-Fenster (aktuell + vorheriger) für die Rotation im laufenden Betrieb | Eigenentwicklung (Node crypto) + Eingrenzung pro Umgebung + DEW KMS | Pro Umgebung / pro Repository / pro Organisation |
| RBAC + Eingrenzung pro Mandant | Das RBAC von Forgejo + die Mandanten-Schicht von fremforge; alle Endpunkte der Plattform-API setzen tenant_id aus dem JWT durch, keine Datenlecks zwischen Mandanten. Organisations-Admin → Mitglieder | Forgejo + API-Middleware von fremforge | Granularität pro Team |
| OIDC-Single-Sign-on | Bevorzugter IdP-Weg. Verbinde Okta, Entra, ADFS, Google Workspace, Authentik, Keycloak, Auth0 oder jeden anderen OpenID-Connect-Anbieter für eingehende Föderation. Domain-Verifizierung, Just-in-time-Bereitstellung von Benutzern, Zuordnung von Gruppen zu Teams. Eingerichtet unter Organisations-Admin → SSO → Auth-Quellen | In Forgejo integrierte OIDC-Auth-Quelle | IdP-Konfiguration pro Mandant |
| SAML-2.0-Single-Sign-on | Noch nicht verfügbar. Verbinde Entra ID oder ADFS stattdessen über OIDC | — | — |
| Benutzerbereitstellung mit SCIM 2.0 | Übertrage Benutzer aus deinem IdP per SCIM 2.0 in deine fremforge-Organisation. Bearer-Token-Authentifizierung pro Mandant, Rotationsfenster mit zwei Tokens, idempotentes CRUD auf Forgejo-Benutzer. Funktioniert mit jedem SCIM-kompatiblen IdP | Eigene API-Endpunkte unter /<slug>/scim/v2/* | SCIM-Token pro Mandant |
| SSH-CA | Der SSH-Zugriff auf Git verwendet ein von einer CA signiertes Zertifikat statt roher Schlüssel-Fingerprints. Zertifikat pro Benutzer mit TTL; über die Admin-Oberfläche der Organisation widerrufbar | OpenSSH-CA + von fremforge verwaltete Zertifikatsausstellung | TTL + Widerruf pro Benutzer |
| Authentifizierungsrichtlinie | Bündel von Durchsetzungsschaltern pro Organisation: hardwaregestützte Schlüssel (nur WebAuthn, kein TOTP), maximale PAT-Lebensdauer (Obergrenze unterhalb des Plattformstandards von 90 Tagen), signierte Commits erforderlich (unsignierte Pushes blockieren), SSH deaktiviert (nur HTTPS), 2FA erforderlich, Anmeldung nur per SSO (lokale Forgejo-Anmeldung mit Benutzername und Passwort blockieren). Entspricht den Unternehmensrichtlinien von GHEC. Jeder Schalter erzeugt bei einer Änderung ein Audit-Ereignis | Mitgeführte Forgejo-Patches + Durchsetzungs-Hooks von fremforge | Richtlinienbündel pro Mandant |
| Allowlist für E-Mail-Domains | Allowlist von E-Mail-Hostmustern pro Organisation. Ist sie aktiviert, können Mitglieder nur Adressen im Stil @acme.com hinzufügen, die den eingestellten Mustern entsprechen. Schließt bei forensischer Prüfung den Weg „Commits als attacker@arbitrary-domain.com ausgeben“. Bestehende E-Mail-Adressen werden nicht automatisch entfernt; die OIDC-Anmeldung ist ausgenommen (der IdP bestätigt). Muster unterstützen exakte Angaben und *.subdomain | Eigene Regeln + Bunny-Edge-Intercept auf /user/settings/account/email | Muster pro Mandant + Schalter zum Durchsetzen |
| Workflow-Secrets | Actions-Secrets auf Organisations- und Repository-Ebene, in jeden CI-Job als Umgebungsvariablen eingespeist. Forgejo speichert sie verschlüsselt; der fremforge-Admin leitet CRUD mit Audit-Ereignissen weiter (der Wert wird nie in der fremforge-Datenbank oder im Audit-Log gespeichert). Ein Secret über dasselbe Formular zu überschreiben, ist der Rotationsablauf | In Forgejo integrierte Secrets + Admin-Proxy von fremforge | Pro Organisation / pro Repository / pro Umgebung |
| Workflow-OIDC für Cloud-Authentifizierung | Runner-VMs erhalten pro Job ein frisches OIDC-JWT mit aud=fremforge. Die Vertrauensrichtlinien der Kunden-Cloud stützen sich darauf für den Austausch kurzlebiger Zugangsdaten (keine langlebigen AWS-Schlüssel, GCP-Service-Account-JSONs oder Azure-Client-Secrets in Workflow-Secrets) | Eigener OIDC-Issuer, signiert mit dem Runner-OIDC-Schlüssel von fremforge (Rotation alle 180 Tage; manuell, automatische Rotation noch nicht ausgeliefert) | — |
| Agent-native Authentifizierung | Drei IdP-seitige Muster für nicht menschliche Aufrufer: (1) Direktes JWT-Bearer aus dem IdP der Kundschaft: ein JWT einer Entra-Workload-Identity, eines Okta-Service-Accounts oder Google-Service-Accounts direkt als Authorization: Bearer an einem beliebigen /api/v1/*-Endpunkt; (2) RFC 8693 Token Exchange + OBO: POST /_app/api/v1/auth/token-exchange akzeptiert subject_token und optional actor_token; die Person ist der actor im Audit und der Agent ein Detail der Zeile (fields.agent), ohne eigene Agent-Identität; (3) RFC 6749 client_credentials: POST /_app/api/v1/oauth/token für Apps ohne IdP. Audience-Bindung pro Mandant (https://frem.sh/<slug>), Claim-Prüfungen pro Quelle (tid/hd), UNIQUE auf Datenbankebene verhindert, dass zwei Mandanten denselben Issuer für direktes Bearer beanspruchen | Eigenentwicklung (auth_sources + oauth_clients + Token-Exchange-Pipeline mit jose) | Opt-in pro Quelle; Scope-Obergrenze pro Client |
DevOps-Beobachtbarkeit
| Maßnahme | Was sie tut | Werkzeug | Konfigurierbar |
|---|---|---|---|
| DORA-Dashboard | Die vier klassischen DORA-Kennzahlen, Deployment frequency, Lead time for changes, Change-failure rate, MTTR, berechnet über ein rollierendes 30-Tage-Fenster aus den für deinen Mandanten erfassten Deployment-Ereignissen. Eingespeist über den Forgejo-Webhook release und ein manuelles POST /_app/api/v1/dora/deployments für Workflows, die keine Releases taggen. Sichtbar unter Organisations-Admin → DORA | Eigenentwicklung (von fremforge geschrieben, auf der Mandanten-Datenbank) | Rollierendes Fenster + manuelles Einspeisen |
| Sicherheitsübersicht | Sicherheit › Übersicht: offene Befunde pro Scanner, mit Links in jeden Tab, und die Einrichtungs-Checkliste | Eigener Aggregator | — |
| Nutzungsübersicht der Runner | Runner-Minuten pro Monat + Tabelle der Dauer pro Job unter Organisationsverwaltung → Build und Deployment → CI-Nutzung. Speist über die Tabelle metering_events die Rechnungspositionen | Eigenentwicklung (Aggregation über runner_jobs) | — |
KI-Haltung
| Maßnahme | Was sie tut | Werkzeug | Konfigurierbar |
|---|---|---|---|
| Eigene KI: agent-nativer Zugriff | fremforge ist KI-agnostisch. Claude Code, Cursor, Windsurf, Codex CLI oder Aider der Kundschaft arbeiten auf derselben Git- und REST-Oberfläche wie Menschen (maschinenlesbare OpenAPI-Spezifikation). Zusammen mit der agent-nativen Authentifizierung (direktes IdP-JWT-Bearer, RFC 8693 Token Exchange + OBO, RFC 6749 client_credentials) authentifizieren sich Agenten als vollwertige Principals, ohne sich das PAT eines Menschen zu leihen. Kein an die Forge gebundenes KI-Produkt, keine agentischen Funktionen, die einen bestimmten Anbieter verlangen | Standardkonforme Git- und REST-Schnittstellen | Von der Kundschaft gesteuert |
| KI-Integrationen (BYOK) | Organisations-Admin → KI-Integrationen: Hinterlege deinen eigenen Schlüssel eines KI-Anbieters (Anthropic, OpenAI, Mistral und andere). Ermöglicht: KI-PR-Review (entwirft Review-Kommentare zum Diff), KI-Erklärungen für Renovate (verständliche Zusammenfassungen des Changelogs in Abhängigkeits-PRs) und das Gateway /_app/api/v1/orgs/<slug>/ai/complete für LLM-Aufrufe aus Workflows | Eigenes Gateway (von fremforge geschrieben) | Anbieter + Schlüssel pro Organisation |
Compliance und Audit
| Maßnahme | Was sie tut | Werkzeug | Konfigurierbar |
|---|---|---|---|
| Audit-Log | Jede zustandsändernde Operation (Push, Rollenänderung, Anlegen eines Secrets, Übersteuerung eines Runners, Änderung der Abrechnung) wird mit Akteur, Zeitstempel und Vorher/Nachher protokolliert. Zweistufige Aufbewahrung: abfragbare heiße Stufe (90 / 180 / 365 / 730 Tage, pro Mandant einstellbar) + 3-jähriges Archiv mit kryptografischer Kette in T Cloud Public OBS WORM | Eigenentwicklung, nur anhängend (Tabelle audit_events) | Aufbewahrungszeitraum pro Mandant |
| Audit-Kette | Hash-verkettetes Audit-Log + lineare Hash-Kette, alle 2 Minuten in T Cloud Public OBS WORM verankert. Ein Prüf-Cron kontrolliert die Integrität der Kette stündlich + vollständiger Durchlauf alle 30 Minuten. Kundinnen und Kunden können prüfen, dass „kein Ereignis nachträglich gelöscht oder verändert wurde“ | Eigenentwicklung (von fremforge geschrieben, an BSI C5 ausgerichtet) | — |
| SIEM-Streaming | Echtzeit-Stream von Audit-Ereignissen an einen Endpunkt der Kundschaft (Splunk HEC, Sentinel, ELK, OpenSearch, generischer HTTPS-Webhook). Relay in der EU, keine Daten verlassen die Region eu-de. Zustand der Endpunkte pro Mandant für Operator und Mandanten-Admin sichtbar | Eigener Forwarder + Tabelle siem_endpoints | Endpunkt-Konfiguration pro Kunde |
| Datenexport (DSGVO-Portabilität) | Selbstbedienungs-Export der Mandantendaten: Repositorys (als Git-Bundles), Issues, Pull Requests und Releases (NDJSON), Paketinventar, Scan-Befunde, Zustand der Paketrichtlinien, signierte Attestierungen, SBOMs von Repositorys und Container-Images, Audit-Ereignisse (NDJSON), mit einem DSSE-signierten Manifest. Download über eine signierte OBS-URL, 7 Tage gültig. Erforderlich für die Portabilität nach Art. 20 DSGVO + Offboarding | Eigener Exporter | Jederzeit auslösbar |
| Lebenszyklusrichtlinien | Automatisierte Aufbewahrung und Löschung pro Mandant: Archivierung veralteter Repositorys, Verhalten bei der Obergrenze für Runner-Minuten, Aufbewahrungszeitraum des Audit-Logs, Karenzzeit bei Sperrung eines Mandanten, SLA für die Datenlöschung zum Vertragsende | Eigenentwicklung (Tabelle tenant_lifecycle) | Richtlinie pro Mandant |
| Repository-Mirroring (eingehende Migrationen) | Spiegle Repositorys der Kundschaft von GitHub, GitLab, Bitbucket oder jedem anderen Git-Host per Pull-Mirror in fremforge, mit Authentifizierung über Zugangsdaten + regelmäßiger Synchronisierung. Wird bei schrittweisen Migrationen genutzt; der Mirror kann nach abgeschlossener Umstellung entfernt werden | In Forgejo integrierter Pull-Mirror + Admin-Proxy von fremforge | Quelle + Intervall pro Repository |
| Benachrichtigungseinstellungen | Organisationsweite Ereignisweiterleitung: welche Audit-Ereignisse Mail, Webhook oder SIEM auslösen, welche Rollen bei kritischen Befunden alarmiert werden, Eskalationskontakte bei Abrechnungsereignissen | Eigenentwicklung (Tabelle notification_preferences) | Weiterleitung pro Mandant |
| Offenlegung von Schwachstellen | security.txt veröffentlicht, security@frem.sh mit 24-Stunden-SLA für die Eingangsbestätigung, öffentliche Dankesseite, Richtlinie gegen Klagen bei Forschung in gutem Glauben | — | — |
| Behebungsfrist (SLA) | SLA-Pill pro Organisation neben jedem offenen Befund. Standardfristen (Kritisch 7 Tage / Hoch 30 Tage / Mittel 90 Tage / Niedrig keine), pro Mandant verschärfbar. An NIST SP 800-40r4 ausgerichtet | Eigenentwicklung (von fremforge geschrieben) | Verschärfung pro Mandant |
Was wir ausdrücklich nicht tun
| Anti-Funktion | Warum |
|---|---|
| Keine Microsoft-Präsenz (kein GitHub, kein Azure AD, kein Office 365, kein Defender, kein GHAS CodeQL) | EU-Souveränität + Schrems II, siehe Trust |
| Kein in den USA gehostetes Sigstore / Fulcio / Rekor im Verifikationspfad | Ebenso. fremforge betreibt einen eigenen Fulcio + TSA auf T Cloud Public eu-de mit der Root-CA in DEW KMS (FIPS 140-2 Level 3 HSM, Deutschland). Kein öffentliches Sigstore, kein Rekor / Transparenzprotokoll: Zeitstempel bewusst nur über die TSA |
| Keine Abhängigkeit von AWS, GCP oder einer anderen von den USA kontrollierten Cloud auf dem kritischen Pfad der Plattform | Ebenso |
| Keine von Drittanbieter-CDNs geladenen Schriften (Google Fonts usw.) | Selbst gehostet unter www.frem.sh/fonts/ über den EU-Edge von Bunny |
| Keine proprietären Scanner von Drittanbietern: Jeder Scanner ist Open Source oder eine Eigenentwicklung von fremforge, und jedes Regelwerk, jede Advisory-Datenbank und jede Quelle für Malware-Signaturen dahinter ist mit ihrer Lizenz in der Stückliste benannt | Der Prüfpfad der Kundschaft verlangt Transparenz mit benannten Werkzeugen |
| Keine langlebigen Zugangsdaten von Service-Accounts in Kunden-Workflows | Für Cloud-Authentifizierung nur OIDC; langlebige Schlüssel sind ein optionaler, veralteter Weg |
Werkzeugtransparenz: die vollständige Stückliste
Wenn du das für eine Ausschreibung, ein BSI-C5-Audit oder eine interne Sicherheitsprüfung brauchst: Die maßgebliche Liste, mit Versionen, Bezugsquellen und den Plattformkomponenten, steht unter docs.frem.sh/security/bill-of-materials/. Die folgende Tabelle ist ein Auszug zum schnellen Nachschlagen.
| Schicht | Werkzeug | Wo eingesetzt | Lizenz |
|---|---|---|---|
| Kern der Quellcodeverwaltung | Forgejo v15 | Repository-Hosting, Code-Review, Actions-Runner-Protokoll | GPLv3 |
| CI-Runner-Binary | forgejo-runner (act_runner) v13.2.0 | Kurzlebige ECS-VM pro Job | MIT |
| Secret-Scanning | Gitleaks v8 | Pre-Receive-Hook | MIT |
| SAST | OpenGrep v1.21 | Analyse zur PR-Zeit | LGPLv2.1 |
| CVE-Scanning von Containern | Trivy | Kunden-CI + im Runner-Image enthalten | Apache 2.0 |
| Abhängigkeits-Scanning | osv-scanner | Analyse zur PR-Zeit | Apache 2.0 |
| SBOM-Erzeugung | Syft | Workflow beim Release-Tag | Apache 2.0 |
| Images signieren + verifizieren | cosign | Prüfung beim Pull und der informative Pull-Request-Check fremforge/cosign-verify | Apache 2.0 |
| Schlüsselloses Code-Signieren: CA | Fulcio v1.8.5 (Helm-Chart 2.9.0) | Selbst gehostet auf T Cloud Public eu-de unter sign.frem.sh | Apache 2.0 |
| Schlüsselloses Code-Signieren: TSA | Sigstore TSA (Zeitstempelstelle) | Selbst gehostet auf T Cloud Public eu-de unter tsa.frem.sh | Apache 2.0 |
| gitsign auf Kundenseite | gitsign | Git-Client der Kundschaft; an OIDC gebundenes Commit-Signieren | Apache 2.0 |
| Abhängigkeits-Updater | Renovate | Gehosteter Bot, 15-Minuten-Cron, Opt-out pro Repository | AGPLv3 |
| Image-Build (rootless) | kaniko | Container-Build in Kunden-Workflows | Apache 2.0 |
| Malware-Scanning | ClamAV | Scan beim Pre-Receive + LFS-Upload | GPLv2 |
| OpenSSF-Best-Practice-Bewertung | scorecard | Wöchentlich pro Repository | Apache 2.0 |
| CDN + WAF der Plattform | Bunny CDN | Edge in der EU, kein Cloudflare/Fastly | (Anbieter mit Sitz in der EU, kein US-Unterauftragsverarbeiter) |
| Cloud-Plattform | T Cloud Public (Deutsche Telekom) | Compute, Speicher, Netzwerk, Datenbank | (Anbieter, ausschließlich Region eu-de) |
| E-Mail (transaktional) | Lettermint (NL) | Authentifizierungs-E-Mails, Rechnungen, Benachrichtigungen | (Anbieter in der EU) |
| Postfach | mailbox.org | Betriebliches Postfach | (Anbieter in der EU) |
| Zahlungen | Mollie (NL) | Abrechnung | (Anbieter in der EU) |
| Buchhaltung | Dinero (DK) | Rechnungsstellung | (Anbieter in der EU) |
Jeder Anbieter auf dieser Liste ist vertraglich in der EU ansässig, ohne US-Unterauftragsverarbeiter im Datenpfad. Die vollständige Kette aus AVV und Unterauftragsverarbeitern steht auf der Trust-Seite.
Roadmap (nach Bedarf)
| Funktion | Status | Auslöser |
|---|---|---|
Eigenes KMS für MASTER_ENCRYPTION_KEY (von der Kundschaft bereitgestellter DEW-CMK im eigenen T-Cloud-Public-Konto) | Entworfen | Erste verbindliche Kundenzusage |
| SLSA-Build-Provenienz (Erfassung des Ausgabe-Digests zur Build-Zeit, sodass sich die signierte Aussage auf einen tatsächlichen Build-Lauf bezieht: die Voraussetzung, um überhaupt ein SLSA-Level zu beanspruchen; beide Klauseln von Build L3 sind bereits erfüllt) | Abgegrenzt | Nachfrage der Kundschaft |
| MCP-Signierung + Verifizierer für die Lieferkette von KI-Agenten | Entworfen | Fertigstellung eines Branchenstandards |