Vertrouwen

Ingangsdatum: 2026-05-19 - Versie: 1.13

Laatst bijgewerkt: 2026-10-07

Samenvatting #

fremforge is EU-soevereine Git-hosting, gebouwd op upstream Forgejo en geëxploiteerd door fremverk ApS (Denemarken). Elk onderdeel draait in de Europese Unie. Geen enkel klantgegeven verlaat de EU-jurisdictie.

Elke verwerking (repositories, CI, audit, facturatie, authenticatie, uitgaande e-mail, inkomende correspondentie in gedeelde mailboxen) gebeurt bij partijen zonder Amerikaanse moedermaatschappij. Nul subverwerkers met een Amerikaanse moedermaatschappij, op welk pad dan ook. Zie §11.3 van de verwerkersovereenkomst (DPA) van het product voor het volledige beleid.

Deze pagina is de officiële referentie voor waar je gegevens staan, wie ze verwerkt, welke certificeringen van toepassing zijn en hoe je ons bereikt.

Verwerkingsverantwoordelijke #

fremverk ApS CVR: 39150689 Ringager 4C, 2. tv, 2605 Brøndby, Denemarken E-mail: compliance@frem.sh · info@fremverk.com

Hosting en regio’s #

Subverwerkers #

De actuele lijst van subverwerkers wordt hier bijgehouden. Elke wijziging wordt 30 dagen van tevoren aangekondigd via de security-mailinglijst en op deze pagina.

Voor botbestrijding wordt geen externe verwerker ingezet. De registratie- en inlogformulieren van het product gebruiken zelf gehoste Altcha (MIT-licentie, met HMAC ondertekende proof-of-work), die in hetzelfde proces draait als de api-monoliet op hetzelfde T Cloud Public-cluster; geen widget-JavaScript van derden, geen externe subverwerker. Daarnaast gelden over het hele platform server-side controles (throttling en rate limits per IP-adres). Aan de edge is geen Web Application Firewall ingeschakeld; zie §Edge-bescherming hieronder.

Edge-bescherming – DDoS-mitigatie, geen WAF #

Elk onderdeel van fremforge (frem.sh voor Forgejo en Git, de API, en de sites www, docs, status en cli) staat achter de edge van Bunny CDN, die volumetrische DDoS-aanvallen afslaat en rate limiting per IP-adres toepast. Op geen enkel onderdeel van fremforge is aan de edge een Web Application Firewall (WAF) ingeschakeld, en dat is al zo sinds vóór de livegang. Dat is een bewuste keuze. Tijdens de tests vóór de lancering gaf de OWASP Core Rule Set veel fout-positieven op de verzoeken van Forgejo (paden van het Git-protocol, diff-routes van pull requests, ophalen van raw blobs met hexadecimale identifiers, querystrings van ondertekende URL’s) en op de formulierinhoud van de API. Een te agressieve WAF die legitieme Git-operaties of de Forgejo-UI breekt, zou voor klanten slechter uitpakken dan het resterende risico op de edge-laag. De bescherming zit daarom in de applicatie: pre-receive scan op secrets, Altcha-proof-of-work bij registratie en inloggen, rate limits per IP-adres en per tenant in de API, authenticatie met ondertekende tokens op elke webhook-ontvanger, en de integriteitshash van de auditketen. Dit beleid staat in DPA bijlage A.2 en wordt bij elke kwartaalreview van de operatie opnieuw beoordeeld.

Isolatie van gehoste runners – wegwerp-ECS-VM, één per commit #

CI-jobs die je naar fremforge pusht, draaien op T Cloud Public Elastic Cloud Server (ECS): elke commit of pull request krijgt een eigen wegwerp-VM, die vers wordt aangemaakt en wordt vernietigd zodra de jobs van die commit klaar zijn. Er zijn twee onafhankelijke isolatielagen:

• Compute / kernel – een eigen VM per commit. De jobs van elke commit draaien in een ECS-VM met een eigen Linux-kernel, geïsoleerd door de hypervisor. Nooit delen twee klanten, of twee commits, een kernel of een machine, dus kernelgebaseerde container-escapes (cgroup-escape, escape via een bind-mount van /proc, eBPF, blootstelling van /sys) hebben geen grens tussen tenants om over te steken: er is geen gedeelde kernel om naar uit te breken. De isolatie-eenheid is een complete VM, geen container – een sterkere grens dan het containermodel met gedeelde kernel dat gangbare Kubernetes (ook CCE) voor runner-pods gebruikt. De VM wordt opgeruimd (verwijderd) zodra de jobs van die commit klaar zijn, zodat niets – buildcache, gekloonde code, geïnjecteerde secrets – overgaat naar de jobs van een andere commit of naar een andere klant.
• Binnen één commit kunnen jobs de machine delen. Opeenvolgende jobs van dezelfde workflowrun (bijvoorbeeld build en daarna deploy op dezelfde commit) kunnen op dezelfde VM draaien, die wordt vernietigd als ze klaar zijn. Dat is bewust: het is in beide jobs dezelfde gereviewde code, en een verse machine per job kost bij elke stap van een pipeline ongeveer 40 seconden extra opstarttijd. Het gevolg, en dat zeggen we liever ronduit: een buildstap die code van externe afhankelijkheden uitvoert, deelt een machine met een latere stap van dezelfde commit. Behandel een pipeline daarom als één vertrouwensdomein, en beperk elke credential die een deploystap nodig heeft tot die pipeline. De isolatie tussen tenants en tussen commits hierboven verandert hierdoor niet.
• Netwerk – een VPC Security Group per VM. Elke runner-VM staat achter een eigen VPC Security Group: geen inkomend verkeer, verkeer tussen VM’s (binnen het subnet) geweigerd, en uitgaand verkeer beperkt tot de tegen SSRF beveiligde uitgaande runner-proxy, de Forgejo-API en DNS. De isolatie wordt afgedwongen op de VPC-/hypervisorlaag, niet op een NetworkPolicy-laag binnen het cluster die afhangt van een CNI-agent die zich correct gedraagt. Samen met de verplichte uitgaande proxy en de SSRF-blokkeerlijst daarvan wordt laterale beweging van een runner-VM naar iets buiten de eigen jobcontext van de klant geweigerd, zowel op VM- als op VPC-niveau.

Als het isolatiemodel van T Cloud Public voor een van beide lagen zo verandert dat het bovenstaande zwakker wordt (bijvoorbeeld als VM’s per job worden vervangen door containers met een gedeelde kernel, of als de grens van de Security Group per VM verdwijnt), wordt deze pagina binnen 30 dagen na de wijziging bijgewerkt en wordt elke actieve klant geïnformeerd volgens DPA §14.

Overgenomen certificeringen #

Via T Cloud Public:

• ISO/IEC 27001 – managementsysteem voor informatiebeveiliging
• ISO/IEC 27017 – beveiligingsmaatregelen specifiek voor de cloud
• ISO/IEC 27018 – bescherming van persoonsgegevens in de cloud
• BSI C5 Type 2 – Duitse federale basislijn voor cloudbeveiliging
• TISAX – zekerheidsstandaard van de Duitse auto-industrie
• AVG-conforme verwerking in datacenters in de EU

De eigen certificeringsroadmap van fremverk #

Op de ingangsdatum heeft fremverk geen eigen ISO 27001-, SOC 2- of BSI C5-certificering. Het beveiligingsniveau van fremverk berust op (i) de hierboven genoemde overgenomen certificeringen van de subverwerkers, (ii) de technische en organisatorische maatregelen in de beveiligingsbijlage van de DPA, en (iii) het programma voor informatiebeveiliging en beveiligingstests van fremverk dat in de beveiligingsbijlage van de DPA is beschreven.

fremverk heeft zich ertoe verplicht:

• binnen 18 maanden na de ingangsdatum te beginnen met de ISO 27001 Stage 1-audit en binnen 24 maanden gecertificeerd te zijn;
• binnen 24 maanden te beginnen met een SOC 2 Type II-readiness assessment.

Klanten die vóór die mijlpalen een directe certificering nodig hebben, kunnen een Enterprise-on-Demand-contract sluiten waarin de mijlpalen voor certificeringsgereedheid in het Order Form worden vastgelegd. Zie DPA §12.1.

Transparantie over overheidstoegang #

Op de ingangsdatum heeft fremverk nul verzoeken van overheden om toegang tot persoonsgegevens van klanten ontvangen. Het volledige rapport – inclusief de verklaring over de periode vóór de lancering – staat op frem.sh/trust/transparency/. Latere rapporten beslaan volledige kalenderjaren en verschijnen in Q1 van het jaar daarna.

Ontvangt fremverk een bindend juridisch bevel van een overheidsinstantie, rechtbank of opsporingsdienst, dan:

• toetst fremverk het verzoek op rechtsgeldigheid, bevoegdheid en proportionaliteit;
• vecht fremverk elk verzoek aan dat te ruim is, geen wettelijke grondslag heeft of in strijd is met EU-recht (waaronder art. 48 AVG voor verzoeken van buiten de EU/EER);
• informeert fremverk de betrokken klant binnen 24 uur na ontvangst, tenzij dat wettelijk verboden is;
• geeft fremverk de klant redelijkerwijs de gelegenheid om een beschermingsbevel te vragen of het verzoek op een andere manier aan te vechten.

Zie DPA §11A.

DSA-transparantieverslag (artikel 15) #

fremforge is een hostingdienst in de zin van Verordening (EU) 2022/2065 (Digital Services Act). Het jaarlijkse verslag op grond van art. 15 – over het aantal meldingen en de afhandeling ervan, bevelen van autoriteiten van lidstaten, contentmoderatie op eigen initiatief en de uitkomst van klachten op grond van art. 20 – staat op frem.sh/trust/dsa/, los van het rapport over overheidstoegang hierboven. Op dezelfde URL staat ook het halfjaarlijkse gemiddelde aantal maandelijkse afnemers in de EU dat art. 24(2) vereist.

Schrems II – internationale doorgiften #

Op geen enkel verwerkingspad worden persoonsgegevens van klanten internationaal doorgegeven. Alle verwerking (inhoud van repositories, CI-runs, auditlogs, authenticatiemetadata, factuurgegevens, gegevens van betaalmiddelen, uitgaande transactionele e-mail en inkomende correspondentie in gedeelde mailboxen) vindt plaats binnen de EU/EER, bij partijen zonder Amerikaanse moedermaatschappij. Er is geen waarborg volgens artikel 46 AVG, geen SCC en geen transfer impact assessment nodig.

Residentie van edge-PoP’s (Bunny CDN) #

Elke Bunny-pullzone vóór frem.sh is zo ingesteld dat hij alleen vanaf PoP’s in de EU levert – geen caching in de VS, Australië of Azië. Dat wordt in OpenTofu op elke pullzone-resource afgedwongen met routing { zones = ["EU"] }. De configuratie van de pullzones staat in de broncode op:

• Forgejo-pullzone: fremforge/forgejo/.infrastructure/main.tf – zoek op zones = ["EU"]
• API-pullzone: fremforge/monolith/.infrastructure/bunny.tf – dezelfde regel
• De pullzones van de statische sites (www, docs, status, cli) nemen hetzelfde routing-blok over uit de gedeelde module in fremverk/cloudplatform/modules/static-site/main.tf:103-112.

Een tofu plan op een willekeurige pullzone-stack toont de actieve waarde van routing.zones, dus elke afwijking van ["EU"] zou als verschil in het plan opduiken. Het controleerbare bewijs wordt direct doorzoekbaar zodra de broncode op de Forgejo-instantie voor klanten staat (op https://frem.sh/fremforge/...); voorlopig staat de officiële documentatie over het anker van de auditketen en de integriteitscontrole op docs.frem.sh/security/audit-chain/.

Over het TLD #

frem.sh is een ccTLD van Sint-Helena (.sh), beheerd door een in het Verenigd Koninkrijk geregistreerde registry-operator. Dat is uitsluitend een feit op DNS-niveau. Geen klantgegevens, geen status van het control plane en geen back-ups verlaten T Cloud Public EU-DE. De soevereiniteitsgaranties (identiteit van de verwerker, lijst van subverwerkers, dataresidentie) staan in de DPA en worden niet beïnvloed door waar de DNS wordt gehost.

Op geen enkel verwerkingspad is er blootstelling aan de CLOUD Act. Alle persoonsgegevens van klanten worden binnen de EU/EER verwerkt door partijen zonder Amerikaanse moedermaatschappij. Zie DPA §11.3 voor het volledige beleid.

Voetnoot over kaartnetwerken. De PCI-DSS-gecertificeerde keten voor kaartbetalingen van Mollie omvat Visa Europe Services Inc. (Britse vestiging) en Mastercard Europe SA (België) – Europese entiteiten waarvan de uiteindelijke moedermaatschappijen (Visa Inc., Mastercard Inc.) in de VS zijn opgericht. De claim “geen Amerikaanse moedermaatschappij” geldt voor de eigen keten van subverwerkers van fremverk op het niveau van de exploiterende onderneming; de kaartnetwerken zijn sub-subverwerkers van Mollie volgens de netwerkregels van PCI-DSS. Wil je op het betaalpad helemaal geen blootstelling aan een Amerikaanse moedermaatschappij, betaal dan via SEPA-incasso (zonder betrokkenheid van kaartnetwerken). Zie subverwerkers – Voetnoot over kaartnetwerken.

Controleer de auditketen zelf #

Elke beheeractie die de status van je organisatie wijzigt, wordt vastgelegd in een SHA-256-hashketen per tenant. De kop van die keten wordt elke twee minuten WORM-verankerd in T Cloud Public OBS Object Lock-opslag (bewaartermijn 3 jaar, binnen die termijn fysiek niet te verwijderen). Je kunt de keten van begin tot eind nalopen zonder fremverk op zijn woord te hoeven geloven.

Met de fremforge-CLI:

# Install (one-liner; see docs.frem.sh/get-started/cli/ for manual download + SHA-256 verify)
curl -sSfL https://cli.frem.sh/cli/install.sh | sh

export FREMFORGE_TOKEN='<your PAT, audit:read scope>'
fremforge audit-verify <your-org-slug> --human

Of met kale curl tegen hetzelfde endpoint dat de CLI aanroept:

curl -sSf \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  https://frem.sh/_app/api/v1/orgs/<your-org-slug>/audit/integrity \
  | jq '{integrity_status, walked_rows, verified_count, last_verified_hash, worm_anchor}'

Een gezond antwoord bevat "integrity_status": "ok" en een worm_anchor-blok waarin agrees_with_db_walk: true bevestigt dat de keten in de database overeenkomt met de in OBS verankerde kop. Bij een breuk (hash_mismatch / prev_hash_mismatch) krijg je de id van de betreffende rij en de reden terug – bewust zo opgezet dat een auditor het kan lezen. Het volledige schema, de exitcodes en het dreigingsmodel staan in docs.frem.sh – integriteit van de auditketen.

Beheer van operatorcredentials #

De bootstrap-beheercredentials (de root-AK/SK van T Cloud Public op domeinniveau, die alleen worden gebruikt om IAM, OBS-buckets en service-linked agencies voor het eerst aan te maken) staan op de laptop van de operator, met volledige schijfversleuteling via FileVault en bestandsrechten chmod 600. Ze worden elk kwartaal geroteerd, nooit via chat of schermdeling verstuurd, en kunnen binnen 10 minuten worden ingetrokken via de OTC-console. Gewone deploys gebruiken afgebakende deployer-sleutels per component, niet de root-credential.

Beveiligingscontact #

• Kwetsbaarheden melden: security@frem.sh
• Disclosurebeleid: beveiliging
• Vingerafdruk van de PGP-sleutel: DBA3 184D 0EFA E4C2 51ED EB46 53FA 57F8 698C 3488 (publieke sleutel – RFC 4880 armored, RSA-4096, verloopt 2031-05-14). Gebruik deze voor versleutelde meldingen van kwetsbaarheden aan security@frem.sh. De sleutel wordt alleen gepubliceerd vanaf frem.sh/.well-known/; we uploaden hem niet naar publieke keyservers (zo vermijden we een vertrouwensanker van derden). Voor het gemak staat er een kopie op /pgp.txt.

Melden van kwetsbaarheden #

Een machineleesbaar disclosurebeleid staat op frem.sh/.well-known/security.txt volgens RFC 9116, met een safe harbour voor onderzoek te goeder trouw, de scope en het meldkanaal. Rapporten van pentests door derden, als die worden uitgevoerd, stellen we volgens DPA §12.1 op schriftelijk verzoek onder NDA beschikbaar aan klanten; in Enterprise-on-Demand-contracten kan in het Order Form een vaste testfrequentie worden afgesproken.

Openbaarmaking van incidenten #

Post-mortems van elk incident dat klantgegevens of beschikbaarheid raakt, publiceren we binnen 14 dagen op deze pagina, volgens ons beveiligingsbeleid.

Beveiligingspatches #

fremforge verplicht zich tot de volgende maximale termijnen voor het patchen van beveiligingslekken in het platform, gerekend vanaf de upstream release met de fix of de publicatie van de advisory, wat het laatst is.

Noodreleases buiten het schema zijn te verwachten. Het wekelijkse onderhoudsvenster is een bovengrens, geen ondergrens. Beveiligingspatches worden nooit uitgesteld vanwege een onderhoudsvenster van een tenant; dat staat in de AUP en wordt letterlijk aangehaald in de beveiligingsbijlage van de DPA.

Vertrek en dataportabiliteit #

Alles is exporteerbaar – repositories, issues, pull requests, Actions-logs, audittrail, SLSA-attestaties – via de API, in standaardformaten. Er is geen lock-in via bewaring en er zijn geen exportkosten.

Selfservice-export, aantoonbaar ongewijzigd. Elke tenantbeheerder kan op elk moment vanuit de beheer-UI een volledige bundel aanmaken. De bundel wordt geleverd als één zip met een SHA-256-manifest over elk bestand in het archief (manifest.json + archive.tar.gz.sha256), zodat de klant kan bevestigen dat de inhoud na het downloaden niet is gewijzigd. De bundel bevat git bundle-bestanden van de repositories, LFS-manifests, Actions-logs, een auditfragment en SLSA-attestaties. Ter vergelijking: de organisatie-export van GitHub is een reeks REST-API-aanroepen, beschikbaar voor eigenaren van de organisatie, die een archief oplevert dat bedoeld is om in GitHub Enterprise Server te importeren (GitHub-documentatie, geraadpleegd op 17 oktober 2026). fremforge levert het in elk plan, aan elke klant, elke dag. Het manifest is ondertekend met onze SLSA-buildersleutel (DSSE-envelop, manifest.json.intoto.jsonl); klanten verifiëren met hetzelfde vertrouwensanker op https://www.frem.sh/.well-known/slsa-trust-root.json dat voor SLSA-buildattestaties is gepubliceerd. Voor het verifiëren van het manifest is helemaal geen Sigstore nodig – niet de publieke instantie, en ook niet de zelf gehoste Fulcio en TSA die we als tweede handtekening op buildattestaties gebruiken. Zie docs.frem.sh/data-export voor de opbouw van de bundel, verificatierecepten en de API-endpoints.

De termijnen en procedures voor het offboarden van een tenant staan in de DPA.

Cookies en tracking #

fremforge zet alleen strikt noodzakelijke cookies op de onderdelen van het product waar je bent ingelogd, en nul cookies op de website, de documentatie, de statuspagina en anonieme pagina’s. Een toestemmingsbanner is niet nodig: niet omdat we de vraag hebben weggestopt, maar omdat we geen cookies zetten waarvoor toestemming nodig is.

Onderdelen van het product waar je bent ingelogd zetten vier first-party cookies, allemaal strikt noodzakelijk in de zin van artikel 5(3) van de e-privacyrichtlijn:

Website, documentatie en status (www.frem.sh, docs.frem.sh, status.frem.sh) zijn statische sites, gebouwd met Hugo, zonder cookies, zonder analytics, zonder embeds en zonder enige vorm van tracking. Controleer het zelf in de ontwikkelaarstools van je browser.

Aanroepen naar derden vanuit de product-UI zijn standaard uitgeschakeld: geen Gravatar, geen gefedereerde avatars, geen fonts of scripts via een CDN, geen analytics van derden. Avatars worden lokaal opgeslagen; fonts komen van dezelfde origin als de forge.

Dit is een bewuste productkeuze, geen minimale compliance-eis. De volledige cookie-inventaris en de rechten van betrokkenen staan in het privacybeleid van het product.

Wijzigingen in beveiligingsmaatregelen #

Bijlage A van de DPA somt de technische en organisatorische maatregelen op die fremverk toepast, en bepaalt dat wezenlijke wijzigingen daarin hier worden gemeld. Wijzigingen vanaf 2026-10-04 staan hieronder, de nieuwste eerst; eerdere wijzigingen staan in het wijzigingslogboek van de DPA. Een wijziging die een toezegging afzwakt, gaat in 30 dagen na een kennisgeving aan elke beheerder bij de klant, met het opzeggingsrecht uit Terms §17; de overige gaan in bij publicatie. Elke versie linkt naar de bijbehorende tekst.

Wijzigingen op deze pagina #

Wijzigingen worden in Git geversioneerd en aangekondigd via de security-mailinglijst. De datum bovenaan deze pagina is die van de laatste inhoudelijke wijziging.

Wijzigingslogboek #