Stückliste
fremforge legt die Werkzeuge unter jeder Kontrolle bewusst offen. Kundinnen und Kunden, die einer Prüfung nach BSI C5, ISO 27001, BaFin oder ENISA-Vorgaben unterliegen, brauchen den Prüfpfad auf Werkzeugebene, und uns ist es lieber, dass du in unserem Quellcode suchen kannst, als dass du eine Blackbox zurückentwickeln musst.
Diese Seite ist das maßgebliche Inventar. Die kürzere Tabelle in der Übersicht der Sicherheitsfunktionen ist eine Teilmenge zum schnellen Nachschlagen; hier steht der vollständige Datensatz: Versionen, Bezugsquellen, wo jede Komponente läuft, die mitgelieferte Lieferketten-Attestierung und die Lizenz.
Integrität der Lieferkette
Jede Abhängigkeit, jedes Container-Image und jedes Binary in diesem Inventar durchläuft die Upstream-Kontaktregel von fremforge:
- Auf GitHub gehosteter Code fließt über den nativen Pull-Mirror von Forgejo unter
frem.sh/<canonical-org>/<repo>(Synchronisierung alle 8 Stunden). Kunden-Workflows, dieuses: actions/checkout@v4auflösen, landen beifrem.sh/actions/checkout; auf dem kritischen Pfad der Kundin oder des Kunden gibt es keinen direkten Abruf von github.com. - Container-Images (docker.io / ghcr.io / quay.io / public.ecr.aws) werden über einen internen EU-Mirror zwischengespeichert. Produktionsmanifeste verweisen nie direkt auf eine Upstream-Registry.
- Release-Binarys, die nicht als OCI ausgeliefert werden (z. B.
opengrep,cosign), werden in winzige Cache-Images verpackt, die aus demselben internen EU-Mirror ausgeliefert werden. Renovate verfolgt die Upstream-Version des GitHub-Releases und öffnet wöchentlich einen Bump-PR.
CI prüft Dockerfiles und Manifeste auf jede Referenz, die den Mirror umgehen würde, sodass jede Upstream-Abhängigkeit über den Cache in der EU aufgelöst wird statt direkt aus einer öffentlichen Registry.
CI- und Lieferketten-Werkzeuge
| Werkzeug | Version | Einsatz | Lizenz | Bezugsquelle |
|---|---|---|---|---|
| Forgejo | v15.x | Repository-Hosting, Code-Review, Actions-Runner-Protokoll, SSO-Authentifizierungsquellen | GPLv3 | Interner EU-Mirror (fremforge-Build) |
| forgejo-runner (act_runner) | v13.2.0 | Registrierung kurzlebiger Runner auf einer ECS-VM pro Commit | MIT | Interner EU-Mirror |
| Gitleaks | v8.x | Secret-Scan beim Pre-Receive | MIT | Interner EU-Mirror |
| OpenGrep | v1.22 | SAST bei jedem PR (FOSS-Nachfolger von Semgrep nach dessen Lizenzwechsel) | LGPLv2.1 | Interner EU-Mirror |
| Trivy | v0.74 | Image-Scan in der Kunden-CI + CVE-Prüfung, die ins Runner-Image eingebaut ist | Apache 2.0 | Interner EU-Mirror |
| osv-scanner | Latest | CVE-/GHSA-Scan der Abhängigkeiten zum PR-Zeitpunkt | Apache 2.0 | Interner EU-Mirror |
| Syft | Latest | SBOMs in CycloneDX 1.6 + SPDX 2.3 bei jedem PR-Scan (beide werden beim Einspeisen akzeptiert) | Apache 2.0 | Interner EU-Mirror |
| cosign | Latest | Signieren + Verifizieren von Images (Kunden-CI über cosign-verify.yaml) | Apache 2.0 | Interner EU-Mirror |
| Fulcio | v1.8.5 (Helm 2.9.0) | Selbst gehostete Code-Signing-CA unter sign.frem.sh. Root-CA im DEW KMS von T Cloud Public (HSM nach FIPS 140-2 Level 3). NICHT der öffentliche Sigstore-Fulcio: fremforge betreibt seinen eigenen | Apache 2.0 | Interner EU-Mirror |
| Sigstore TSA | Latest | Zeitstempelstelle nach RFC 3161 unter tsa.frem.sh. Schlüssel im DEW KMS. NICHT die öffentliche Sigstore-TSA | Apache 2.0 | Interner EU-Mirror |
| gitsign | Latest | Git-Client auf Kundenseite; an OIDC gebundenes Commit-Signieren gegen den eigenen Fulcio | Apache 2.0 | Installation auf Kundenseite (brew install sigstore/tap/gitsign) |
| Renovate | Latest | Gehosteter Bot für Abhängigkeits-Bumps, Cron alle 15 Minuten, Opt-out pro Repository | AGPLv3 | Interner EU-Mirror |
| kaniko | Latest | Rootless Container-Build in Kunden-Workflows (Alternative zu BuildKit, wenn die Kundin oder der Kunde nicht privilegiert laufen kann) | Apache 2.0 | Interner EU-Mirror |
| ClamAV | Latest | Malware-Scan beim Upload (LFS-Objekte, Anhänge, Paket-Uploads) und der optionale Scan im Dependency-Proxy. Die Signaturquellen stehen unter Erkennungsinhalte | GPLv2 | Interner EU-Mirror |
| scorecard | Latest | Wöchentlicher OpenSSF-Best-Practice-Lauf pro Repository | Apache 2.0 | Interner EU-Mirror |
openssl + python3 (stdlib) | n/a | Verifikation der von fremforge ausgestellten Veröffentlichungs-Attestierungen auf Kundenseite: Die DSSE-Umschläge sind mit einem reinen Ed25519-Schlüssel signiert, sodass die Verifikation ein kleines Rezept mit curl/jq/openssl/python3 ist (siehe SLSA-Provenienz), nicht das Upstream-Werkzeug slsa-verifier | — | Werkzeuge, die mit der Distribution kommen |
Erkennungsinhalte
Die Regeln, Advisory-Datenbanken und Malware-Signaturen, gegen die die Scanner abgleichen. Jeder Inhalt ist festgelegt oder wird im angegebenen Rhythmus aktualisiert, und keiner wird während eines laufenden Scans abgerufen.
| Inhalt | Verwendet von | Lizenz | Bezugsquelle |
|---|---|---|---|
| GitLab sast-rules, nur die Ordner pro Sprache (C#, Go, Java, JavaScript, Python, Scala) | SAST und /opt/sast-rules im gehosteten Runner-Image | MIT; die Go-Regeln Apache-2.0 (abgeleitet von gosec). Der Rest des Upstream-Repositorys, der Inhalte unter anderen Lizenzen enthält, wird beim Build gelöscht, und der Build scheitert, wenn eine behaltene Datei eine andere Lizenz als MIT, Apache-2.0 oder BSD trägt | frem.sh-Pull-Mirror, festgelegter Commit |
0xdea semgrep-rules, rules/c | SAST für C und C++ | MIT | frem.sh-Pull-Mirror, festgelegter Commit |
| SAST-Regeln von fremforge | SAST für JavaScript und TypeScript, Python, Bash, PHP, Ruby, Rust, Kotlin und Swift | MIT | Quellcode von fremforge |
Trivy-Schwachstellendatenbanken (trivy-db, trivy-java-db) | Container-Image-Scanning, trivy fs bei Pull Requests | Apache-2.0 für den Datenbank-Build; jeder Eintrag behält die Bedingungen seiner Quelle (GitHub Advisory Database, Sicherheitsdaten von Red Hat und SUSE: CC-BY-4.0) | Interner EU-Mirror, täglich aktualisiert |
| OSV-Datenbank, Offline-Kopie | Abhängigkeits-Scanning, schädliche Pakete, Paketrichtlinien, Audits im Dependency-Proxy | CC-BY-4.0; jeder Eintrag behält die Bedingungen seiner Quelle | Interner Mirror des OSV-Exports, täglich aktualisiert |
| Go-Schwachstellendatenbank | Go-Erreichbarkeit (govulncheck) | CC-BY-4.0 | Der Go-Export des OSV-Mirrors, täglich aktualisiert |
| GitHub Advisory Database | Über OSV und die Trivy-Datenbanken | CC-BY-4.0 | Über die OSV- und Trivy-Mirrors |
| Signaturen von SaneSecurity | ClamAV-Malware-Scan | Bedingungen von SaneSecurity: kostenlos, spendenfinanziert | Ein öffentlicher SaneSecurity-Mirror, alle 4 Stunden |
| YARA-Forge Core | ClamAV-Malware-Scan | Detection Rule License 1.1; kommerzielle Nutzung mit Namensnennung der Regelautoren erlaubt | Alle 4 Stunden, Upstream-Releases wöchentlich |
| Signaturen von Linux Malware Detect | ClamAV-Malware-Scan | GPLv2 | Alle 4 Stunden, Upstream täglich |
| EICAR-Testsignatur | Smoke-Test des Malware-Scans | Frei nutzbar (EICAR) | Statisch, wird mit dem Scanner ausgeliefert |
Plattformgrundlage
| Schicht | Werkzeug / Anbieter | Einsatz | Lizenz / Einordnung |
|---|---|---|---|
| Container-Registry | T Cloud Public SWR | Alle fremforge-Images. Einzige Quelle für Pulls zur Laufzeit; Mirror für jede Upstream-Registry | Anbieter (Deutsche Telekom, eu-de) |
| Kubernetes | T Cloud Public CCE Turbo (Cloud Native Network 2.0) | Plattform-Workloads (Forgejo, Control-Plane-Monolith, Jobs). ENI + Security Group pro Pod über Yangtse CNI. CI-Runner laufen hier nicht; siehe die ECS-Zeile unten | Anbieter (Deutsche Telekom, eu-de) |
| Rechenleistung für gehostete CI-Runner | T Cloud Public ECS (kurzlebige VM pro Commit) | Eine kurzlebige ECS-VM pro Commit/PR; eigener Kernel (durch den Hypervisor isoliert), nach dem Job abgeräumt; VPC-Security-Group pro VM (kein eingehender Verkehr, VM-zu-VM verboten, ausgehender Verkehr über den SSRF-geschützten Runner-Proxy) | Anbieter (Deutsche Telekom, eu-de) |
| Objektspeicher (Betreiber) | T Cloud Public OBS | WORM-Anker der Audit-Kette, SBOM-Archiv, Datenexport, OpenTofu-State | Anbieter (Deutsche Telekom, eu-de) |
| Relationale Datenbank | T Cloud Public RDS (PostgreSQL 15) | API-Zustand, Mandanten- und Befundtabellen, Audit-Kette | Anbieter (Deutsche Telekom, eu-de) |
| In-Memory-Cache | T Cloud Public DCS Redis | Rate-Limit-Zähler, gesehene IPs beim Token-Austausch, Sitzungs-Cache | Anbieter (Deutsche Telekom, eu-de) |
| Schlüsselverwaltung | T Cloud Public DEW | MASTER_ENCRYPTION_KEY, Fulcio-Root-CA, TSA-Signierschlüssel | Anbieter (HSM nach FIPS 140-2 Level 3, Deutschland) |
| Function-as-a-Service | T Cloud Public FunctionGraph | Geplante Cron- und Aufräum-Workloads | Anbieter (Deutsche Telekom, eu-de) |
| Log- und Metrikebene | T Cloud Public LTS + CES | Anwendungslogs, Stichwortalarme, SLO-Metriken | Anbieter (Deutsche Telekom, eu-de) |
| Edge / CDN | Bunny CDN | TLS-Terminierung, Caching an EU-Edges, Edge-Regeln, Rate-Limit-Untergrenze | Anbieter (Hauptsitz Slowenien, in der EU ansässig, kein US-Unterauftragsverarbeiter) |
| Transaktions-E-Mail | Lettermint | Authentifizierungs-E-Mails, Abrechnungshinweise, Benachrichtigungen | Anbieter (NL, DSGVO-konform ansässig) |
| Betriebspostfach | mailbox.org | Eingehende Admin-Mails an *@frem.sh | Anbieter (Deutschland) |
| Zahlungsabwicklung | Mollie | Karte + SEPA-Lastschrift | Anbieter (NL, DSGVO-konform ansässig) |
| Buchhaltung | Dinero | Rechnungsstellung + Buchhaltung | Anbieter (DK, DSGVO-konform ansässig) |
| Externe Verfügbarkeitsprüfung | updown.io | Verfügbarkeitsprüfungen von außerhalb des Netzes (API, Forgejo, Kuma, Marketing, Authentik) | Anbieter (FR) |
Jeder Anbieter auf dieser Liste ist vertraglich in der EU ansässig, ohne US-Unterauftragsverarbeiter im Datenpfad. Den vollständigen AVV und die Kette der Unterauftragsverarbeiter findest du auf der Trust-Seite.
Was wir bewusst nicht verwenden
| Anbieter / Werkzeug, den wir meiden | Warum |
|---|---|
| github.com (direkt) | EU-Souveränität + Schrems II + die Upstream-Kontaktregel. Ausschließlich gespiegelt. |
| GitHub Advanced Security (CodeQL usw.) | Proprietäre Erkennungsregeln, die du nicht prüfen kannst. Wir verwenden OpenGrep + Trivy + osv-scanner: alles OSS, alles prüfbar. |
| Microsoft 365, Entra, Defender | Ebenso. Das Produkt fremforge hat keinerlei Microsoft-Fußabdruck. (Die Unternehmens-IT von fremverk ist eine getrennte Identitätswelt.) |
| Öffentliches Sigstore Fulcio/Rekor (sigstore.dev) | In den USA gehostet; der Verifikationspfad würde die EU verlassen. Wir betreiben unseren eigenen Fulcio + TSA in eu-de mit der Root-CA im DEW KMS. Bewusst kein Rekor / Transparenzprotokoll: Der Integritätsbaustein ist stattdessen die Zeitstempelung über die TSA. |
| AWS, GCP, Azure | Unter Kontrolle US-amerikanischer Cloud-Anbieter. T Cloud Public wird von der Deutschen Telekom auf einem von Huawei abgeleiteten Stack betrieben; der OpenTofu-Provider ist der für OTC gepflegte Fork (opentelekomcloud/opentelekomcloud, nie huaweicloud/huaweicloud). |
| Cloudflare, Fastly, Akamai | Edge unter Kontrolle US-amerikanischer Cloud-Anbieter. Bunny CDN hat seinen Hauptsitz in der EU und ist vertraglich in der EU ansässig. |
| Google Fonts, jsDelivr, über unpkg-CDN geladene Assets | Ein CDN eines Drittanbieters legt Verkehrsmuster gegenüber Edges in den USA offen. Alle Schriften, JS und CSS werden selbst unter www.frem.sh/fonts/ über Bunny EU gehostet. |
| Langlebige Zugangsdaten von Dienstkonten in Kunden-Workflows | OIDC-Token-Föderation (Workflow-OIDC) + agentennative Authentifizierung ersetzen sie. Langlebige Schlüssel sind ein optionaler, veralteter Weg mit einem Hinweisbanner zur Abkündigung. |
So nutzt du diese Stückliste in deinem eigenen Audit-Paket
Für eine RFP-Antwort oder einen Lieferantenfragebogen: Verlinke direkt auf diese Seite. Die URL ist stabil: https://docs.frem.sh/security/bill-of-materials/.
Für Nachweise nach BSI C5 oder ISO 27001: Frag bei security@frem.sh den datierten PDF-Schnappschuss an. Auf Anfrage können wir außerdem eine SBOM der Plattform selbst im CycloneDX-Format erstellen (nicht nur pro Release), nützlich für den Abgleich transitiver CVEs.
Für die laufende Verifikation: Jedes Release jeder fremforge-Komponente veröffentlicht eine mit Syft erzeugte CycloneDX-SBOM, und die SLSA-L2-Provenienz auf Kundenseite legt den Digest jedes attestierten Assets fest. Die Provenienz ist ein mit Ed25519 signierter DSSE-/in-toto-Umschlag (<asset>.intoto.jsonl); verifiziere ihn gegen den veröffentlichten Trust Root von fremforge mit dem Rezept aus curl/jq/openssl/python3 unter SLSA-Provenienz.
Abweichungen: Diese Stückliste wird derzeit von Hand gepflegt. Schreib an security@frem.sh, wenn du vor einem Audit einen aktuellen Schnappschuss brauchst.
Verwandte Themen
- Trust-Seite: AVV, Liste der Unterauftragsverarbeiter, Compliance-Nachweise.
- Hinweise zu Drittanbietern im Runner-Image: Lizenzhinweise, das Quellcode-Angebot für opengrep und die Namensnennung für Advisory-Daten und Malware-Signaturen.
- Sicherheitsfunktionen im Überblick: was jedes Werkzeug tatsächlich tut, mit Direktlinks.
- SBOMs: wie CycloneDX-/SPDX-SBOMs auf Kundenseite erzeugt werden.
- SLSA-Provenienz: wie die Veröffentlichungs-Attestierung serverseitig mit dem Ed25519-Schlüssel der Plattform signiert wird, wie du sie verifizierst und warum sie bewusst nicht als SLSA-Level bezeichnet wird.
- Offenlegung von Schwachstellen:
security@frem.sh, SLA von 24 h für die Eingangsbestätigung.