Tillid

Gældende fra: 2026-05-19 – Version: 1.13

Senest opdateret: 2026-10-07

Overblik #

fremforge er EU-suveræn Git-hosting bygget på upstream Forgejo og drevet af fremverk ApS (Danmark). Alle flader kører i Den Europæiske Union. Ingen kundedata forlader EU’s jurisdiktion.

Al behandling (repositorier, CI, revision, fakturering, godkendelse, udgående e-mail og indgående korrespondance i fælles postkasser) foregår hos selskaber uden amerikansk moderselskab. Ingen underdatabehandlere med amerikansk moderselskab på nogen vej. Se produktets DPA §11.3 for hele forpligtelsen.

Denne side er det autoritative sted at se, hvor dine data ligger, hvem der behandler dem, hvilke certificeringer der gælder, og hvordan du får fat i os.

Dataansvarlig #

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

Hosting og regioner #

Underdatabehandlere #

Den aktuelle liste over underdatabehandlere vedligeholdes her. Enhver ændring varsles 30 dage i forvejen på sikkerhedsmailinglisten og på denne side.

Bot-beskyttelse involverer ingen tredjeparts databehandler. Formularerne til oprettelse og login i produktet bruger selvhostet Altcha (MIT-licens, HMAC-signeret proof-of-work), der kører i processen inde i api-monolitten på samme T Cloud Public-cluster; intet JavaScript-widget fra tredjepart og ingen ekstern underdatabehandler. Derudover gælder kontroller på serversiden (throttling og rate limits pr. IP) på tværs af alle flader. Der er ikke slået nogen Web Application Firewall til på edge; se §Beskyttelse på edge nedenfor.

Beskyttelse på edge – DDoS-afbødning, ingen WAF #

Alle fremforges flader (frem.sh for Forgejo og Git, API’et samt www-, docs-, status- og CLI-sitet) ligger bag Bunny CDN’s edge, som står for afbødning af volumetriske DDoS-angreb og rate limiting pr. IP. Der er ikke slået nogen Web Application Firewall (WAF) til på edge for nogen af fremforges flader, og det har der ikke været siden før lanceringen. Det er et bevidst valg. Under testen før lanceringen gav OWASP Core Rule Set en høj andel falske positiver på Forgejos forespørgsler (stier i Git-protokollen, ruter til diffs i pull requests, hentning af rå blobs med hex-strenge som id’er, query-strenge i signerede URL’er) og på API’ets formulardata. En overivrig WAF, der ødelægger legitime Git-operationer eller forløb i Forgejo-UI’et, ville have været et dårligere resultat for kunderne end den resterende risiko på edge-laget. Beskyttelsen ligger i stedet i applikationen: hemmelighedsscanning i pre-receive, Altcha-proof-of-work ved oprettelse og login, rate limits pr. IP og pr. organisation i API’et, godkendelse med signerede tokens på alle webhook-modtagere og integritetshashen i revisionskæden. Denne tilgang er beskrevet i DPA bilag A.2 og tages op igen ved hver kvartalsvise driftsgennemgang.

Isolering af hostede runnere – én engangs-ECS-VM pr. commit #

De CI-jobs, du pusher til fremforge, kører på T Cloud Public Elastic Cloud Server (ECS): hvert commit eller hver pull request får sin egen virtuelle engangsmaskine, som oprettes på ny og slettes, når jobbene for det commit er færdige. Der er to uafhængige lag af isolering:

• Compute / kerne – en dedikeret VM pr. commit. Jobbene for hvert commit kører i en ECS-VM med sin egen Linux-kerne, isoleret af hypervisoren. To kunder – og to commits – deler aldrig kerne eller maskine, så teknikker til at bryde ud af en container via kernen (cgroup-escape, escape via bind-mount af /proc, eBPF, eksponering af /sys) har ingen grænse mellem organisationer at krydse: der er ingen delt kerne at bryde ud i. Isoleringsenheden er en hel VM, ikke en container – en stærkere grænse end den model med containere på delt kerne, som almindelig Kubernetes (også CCE) bruger til runner-pods. VM’en slettes, når jobbene for det commit er færdige, så intet – build-cache, klonet kode, indsatte secrets – lever videre til et andet commits jobs eller til nogen anden kunde.
• Inden for ét commit kan jobs dele maskinen. Efterfølgende jobs i samme workflow-kørsel (fx build og derefter deploy på samme commit) kan køre på samme VM, som slettes, når de er færdige. Det er bevidst: det er den samme gennemgåede kode i begge jobs, og en ny maskine pr. job koster omkring 40 sekunders ekstra ventetid ved hvert trin i en pipeline. Konsekvensen, der er værd at sige ligeud, er, at et build-trin, der kører kode fra tredjepartsafhængigheder, deler maskine med et senere trin i samme commit. Behandl derfor en pipeline som ét tillidsdomæne, og afgræns de loginoplysninger, et deploy-trin skal bruge, til den pipeline. Isoleringen mellem organisationer og mellem commits ovenfor påvirkes ikke af dette.
• Netværk – en VPC Security Group pr. VM. Hver runner-VM ligger bag sin egen VPC Security Group: ingen indgående adgang, trafik mellem VM’er (inden for subnettet) afvises, og udgående trafik er begrænset til den SSRF-beskyttede udgående runner-proxy, Forgejo-API’et og DNS. Isoleringen håndhæves på VPC- og hypervisorlaget, ikke af en NetworkPolicy i clusteret, som afhænger af, at en CNI-agent opfører sig korrekt. Sammen med den tvungne udgående proxy og dens SSRF-blokeringsliste betyder det, at lateral bevægelse fra en runner-VM til noget som helst uden for kundens egen jobkontekst afvises på både VM- og VPC-laget.

Hvis T Cloud Publics isoleringsmodel for et af lagene ændres i en retning, der svækker ovenstående (fx hvis VM’er pr. job erstattes af containere på delt kerne, eller hvis grænsen med en Security Group pr. VM fjernes), opdateres denne side inden for 30 dage efter ændringen, og alle aktive kunder underrettes i henhold til DPA §14.

Arvede certificeringer #

Gennem T Cloud Public:

• ISO/IEC 27001 – ledelsessystem for informationssikkerhed
• ISO/IEC 27017 – sikkerhedskontroller specifikt for cloud
• ISO/IEC 27018 – beskyttelse af personoplysninger i cloud
• BSI C5 Type 2 – den tyske føderale basislinje for cloudsikkerhed
• TISAX – sikkerhedsvurdering for den tyske bilindustri
• GDPR-overholdende behandling i datacentre i EU

fremverks egen plan for certificering #

På ikrafttrædelsesdatoen har fremverk ikke selvstændige ISO 27001-, SOC 2- eller BSI C5-certificeringer. fremverks sikkerhed bygger på (i) de arvede certificeringer hos underdatabehandlerne nævnt ovenfor, (ii) de tekniske og organisatoriske foranstaltninger i sikkerhedsbilaget til databehandleraftalen og (iii) fremverks program for informationssikkerhed og sikkerhedstest, som er beskrevet i samme sikkerhedsbilag.

fremverk har forpligtet sig til at:

• Påbegynde ISO 27001 Stage 1-audit inden for 18 måneder fra ikrafttrædelsesdatoen og opnå certificering inden for 24 måneder.
• Påbegynde en SOC 2 Type II-parathedsvurdering inden for 24 måneder.

Kunder, der har brug for direkte certificering før disse milepæle, kan indgå aftale under Enterprise-on-Demand med milepælene for certificeringsparathed skrevet ind i ordreformularen. Se DPA §12.1.

Gennemsigtighed om myndigheders adgang #

På ikrafttrædelsesdatoen har fremverk modtaget nul anmodninger fra myndigheder om adgang til Kundens personoplysninger. Hele rapporten – herunder erklæringen for den delvise periode, der dækker driften før lanceringen – er offentliggjort på frem.sh/trust/transparency/. De følgende rapporter dækker hele kalenderår og offentliggøres i 1. kvartal året efter.

Når fremverk modtager et bindende retligt krav fra en myndighed, en domstol eller politiet, gør fremverk følgende:

• Gennemgår anmodningen for retlig gyldighed, jurisdiktion og proportionalitet;
• Anfægter enhver anmodning, der er for vidtgående, mangler retligt grundlag eller er i strid med EU-retten (herunder GDPR art. 48 for anmodninger fra lande uden for EU/EØS);
• Underretter den berørte kunde inden for 24 timer efter modtagelsen, medmindre det er retligt forbudt;
• Giver kunden rimelig mulighed for at søge et beskyttelsespåbud eller på anden måde bestride anmodningen.

Se DPA §11A.

DSA-transparensrapport (artikel 15) #

fremforge er en hostingtjeneste som defineret i forordning (EU) 2022/2065 (retsakten om digitale tjenester, DSA). Den årlige rapport efter art. 15 om antallet af anmeldelser efter notice-and-action, påbud fra myndigheder i medlemsstaterne, indholdsmoderering på eget initiativ og udfaldet af klager efter art. 20 er offentliggjort på frem.sh/trust/dsa/ – adskilt fra rapporten om myndigheders adgang ovenfor. Samme URL indeholder det halvårlige tal for gennemsnitligt antal modtagere i EU pr. måned, som art. 24, stk. 2, kræver.

Schrems II – internationale overførsler #

Der sker ingen international overførsel af Kundens personoplysninger på nogen behandlingsvej. Al behandling (repository-indhold, CI-kørsler, revisionslogs, metadata om godkendelse, faktureringsposter, data om betalingsmidler, udgående transaktionsmails og indgående korrespondance i fælles postkasser) foregår inden for EU/EØS hos selskaber uden amerikansk moderselskab. Der kræves ingen garanti efter GDPR artikel 46, ingen standardkontraktbestemmelser (SCC) og ingen vurdering af overførselsrisiko (TIA).

Dataophold på edge-PoP’er (Bunny CDN) #

Alle Bunny-pullzones foran frem.sh er sat op til kun at levere fra PoP’er i EU – ingen caching i USA, Australien eller Asien. Det håndhæves i OpenTofu på hver pullzone-ressource via routing { zones = ["EU"] }. Opsætningen af pullzones ligger i kildekoden her:

• Forgejo-pullzone: fremforge/forgejo/.infrastructure/main.tf – søg efter zones = ["EU"]
• API-pullzone: fremforge/monolith/.infrastructure/bunny.tf – samme linje
• Pullzones for de statiske sites (www, docs, status, cli) arver den samme routing-blok fra det fælles modul i fremverk/cloudplatform/modules/static-site/main.tf:103-112.

En tofu plan mod en hvilken som helst pullzone-stak viser den aktive værdi af routing.zones, så enhver afvigelse fra ["EU"] ville vise sig som en forskel i planen. Dokumentationen vil kunne gennemses direkte i browseren, når kildekoden er hostet på den kundevendte Forgejo-instans (på https://frem.sh/fremforge/...); indtil da er dokumentationen af revisionskædens anker og integritetsverifikationen offentliggjort på docs.frem.sh/security/audit-chain/.

Om topdomænet #

frem.sh er et ccTLD for Saint Helena (.sh), som administreres af en registry-operatør registreret i Storbritannien. Det er alene et forhold på DNS-niveau. Ingen kundedata, ingen tilstand fra kontrolplanet og ingen backups forlader T Cloud Public EU-DE. Suverænitetsgarantierne (databehandlerens identitet, listen over underdatabehandlere, dataophold) er fastlagt i databehandleraftalen og påvirkes ikke af, hvor DNS hostes.

Ingen eksponering for CLOUD Act på nogen behandlingsvej. Alle Kundens personoplysninger behandles inden for EU/EØS af selskaber uden amerikansk moderselskab. Se DPA §11.3 for hele forpligtelsen.

Fodnote om kortnetværk. Mollies PCI-DSS-attesterede kæde for kortbehandling involverer Visa Europe Services Inc. (britisk filial) og Mastercard Europe SA (Belgien) – driftsselskaber i EU, hvis øverste moderselskaber (Visa Inc., Mastercard Inc.) er registreret i USA. Udsagnet »intet amerikansk moderselskab« gælder fremverks egen kæde af underdatabehandlere på driftsselskabsniveau; kortnetværkene er Mollies under-underdatabehandlere efter PCI-DSS-netværksreglerne. Kunder, der foretrækker nul eksponering for amerikanske moderselskaber på betalingsvejen, kan betale med SEPA Direct Debit (ingen kortnetværk involveret). Se underdatabehandlere – fodnote om kortnetværk.

Verificér selv revisionskæden #

Hver admin-handling, der ændrer tilstand i din organisation, registreres i en SHA-256-hashkæde pr. organisation, og kædens hoved WORM-forankres hvert andet minut i T Cloud Public OBS-lager med Object Lock (opbevaring i 3 år, fysisk umuligt at slette inden for opbevaringsperioden). Du kan gennemgå hele kæden fra ende til anden uden at skulle tage fremverks ord for det.

Med fremforge-CLI’et:

# 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

Eller med rå curl mod det samme endpoint, som CLI’et kalder:

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}'

Et sundt svar indeholder "integrity_status": "ok" og en worm_anchor-blok, hvor agrees_with_db_walk: true bekræfter, at kæden i databasen stemmer med hovedet, der er forankret i OBS. Et brud (hash_mismatch / prev_hash_mismatch) returnerer id’et på den række, der fejler, og årsagen – lavet til at kunne læses af en revisor. Det fulde skema, exitkoder og trusselsmodellen findes i docs.frem.sh – revisionskædens integritet.

Opbevaring af operatørens loginoplysninger #

Admin-loginoplysningerne til opstart (den domæneafgrænsede root-AK/SK til T Cloud Public, der kun bruges til første oprettelse af IAM, OBS-buckets og service-linked agencies) opbevares på operatørens laptop med fuld diskkryptering via FileVault og filrettighederne chmod 600, roteres hvert kvartal, sendes aldrig via chat eller skærmdeling og kan tilbagekaldes på under 10 minutter via OTC-konsollen. Almindelige udrulninger bruger afgrænsede deployer-nøgler pr. komponent, ikke root-loginoplysningerne.

Sikkerhedskontakt #

• Rapportér sårbarheder: security@frem.sh
• Politik for offentliggørelse: sikkerhed
• PGP-nøglens fingeraftryk: DBA3 184D 0EFA E4C2 51ED EB46 53FA 57F8 698C 3488 (offentlig nøgle – RFC 4880 ASCII-armored, RSA-4096, udløber 2031-05-14). Brug den til krypterede sårbarhedsrapporter til security@frem.sh. Nøglen offentliggøres kun fra frem.sh/.well-known/; vi uploader den ikke til offentlige nøgleservere (så vi undgår en tillidsrod hos tredjepart). Spejl på /pgp.txt for nemheds skyld.

Offentliggørelse af sårbarheder #

En maskinlæsbar politik for offentliggørelse er offentliggjort på frem.sh/.well-known/security.txt i henhold til RFC 9116, herunder safe harbour for research i god tro, omfang og kanal for rapportering. Rapporter fra penetrationstest udført af tredjepart stilles, når de er bestilt, til rådighed for kunder under NDA efter skriftlig anmodning i henhold til DPA §12.1; aftaler under Enterprise-on-Demand kan fastsætte en bestemt testfrekvens i ordreformularen.

Offentliggørelse af hændelser #

Post-mortems for enhver hændelse, der påvirker kundedata eller tilgængelighed, offentliggøres på denne side inden for 14 dage i henhold til vores sikkerhedspolitik.

Sikkerhedsopdateringer #

fremforge forpligter sig til følgende maksimale tid til patch af sikkerhedssårbarheder i platformen, målt fra upstreams rettede release eller offentliggørelsen af advisoriet, alt efter hvad der kommer sidst.

Ekstraordinære nødreleases uden for planen må forventes. Det ugentlige vedligeholdelsesvindue er et loft, ikke et gulv. Sikkerhedspatches udskydes aldrig for at respektere en organisations vedligeholdelsesvindue; det står i AUP’en og citeres ordret i sikkerhedsbilaget til databehandleraftalen.

Exit og dataportabilitet #

Alt kan eksporteres – repositorier, issues, pull requests, Actions-logs, revisionsspor og SLSA-attesteringer – via API’et i standardformater. Der er ingen indlåsning via opbevaring og intet gebyr for eksport.

Selvbetjent eksport, der afslører manipulation. Enhver admin i en organisation kan til enhver tid starte en fuld pakke fra admin-UI’et. Pakken leveres som én zip-fil med et SHA-256-manifest, der dækker hver fil i arkivet (manifest.json + archive.tar.gz.sha256), så kunden kan bekræfte, at indholdet ikke er manipuleret efter download. Pakken indeholder git bundle-filer for repositorierne, LFS-manifester, Actions-logs, udsnit af revisionsloggen og SLSA-attesteringer. Til sammenligning er GitHubs eksport af en organisation en række REST API-kald, som er tilgængelige for organisationens ejere, og som giver et arkiv beregnet til import i GitHub Enterprise Server (GitHub docs, læst 17. oktober 2026). fremforge leverer den på alle planer, til alle kunder, hver dag. Manifestet er signeret med vores SLSA-builder-nøgle (DSSE-envelope, manifest.json.intoto.jsonl); kunderne verificerer med den samme tillidsrod på https://www.frem.sh/.well-known/slsa-trust-root.json, som er offentliggjort til SLSA-build-attesteringer. Verifikation af manifestet kræver slet ikke Sigstore – hverken den offentlige instans eller den selvhostede Fulcio og TSA, som vi bruger som en ekstra signatur på build-attesteringer. Se docs.frem.sh/data-export for pakkens opbygning, opskrifter på verifikation og API-endpoints.

Tidsfrister og procedurer for offboarding af en organisation står i databehandleraftalen.

Cookies og sporing #

fremforge sætter kun strengt nødvendige cookies på produktets flader, hvor du er logget ind, og ingen cookies overhovedet på hjemmesiden, dokumentationen, statussiden og sider uden login. Der er ikke brug for et samtykkebanner: ikke fordi vi har gemt spørgsmålet væk, men fordi vi ikke sætter cookies, der ville kræve samtykke.

Produktets flader med login sætter fire førstepartscookies, som alle er strengt nødvendige efter artikel 5, stk. 3, i e-databeskyttelsesdirektivet:

Hjemmeside, dokumentation og status (www.frem.sh, docs.frem.sh, status.frem.sh) er statiske sites bygget med Hugo uden cookies, uden analyse, uden indlejringer og uden nogen form for sporing. Det kan du selv tjekke i din browsers udviklerværktøjer.

Kald til tredjepart fra produktets UI er slået fra som standard: ingen Gravatar, ingen fødererede avatarer, ingen skrifttyper eller scripts fra et CDN og ingen analyse fra tredjepart. Avatarer gemmes lokalt; skrifttyper leveres fra samme origin som forgen.

Det er et bevidst valg i produktet, ikke et minimum for at overholde reglerne. Den fulde oversigt over cookies og de registreredes rettigheder står i produktets privatlivspolitik.

Ændringer af sikkerhedsforanstaltninger #

Bilag A til databehandleraftalen oplister de tekniske og organisatoriske foranstaltninger, fremverk anvender, og fastslår, at væsentlige ændringer af dem meddeles her. Ændringer fra 2026-10-04 og frem står nedenfor med de nyeste øverst; tidligere ændringer findes i databehandleraftalens ændringslog. En ændring, der forringer en forpligtelse, træder i kraft 30 dage efter et varsel til alle kundens administratorer, med opsigelsesretten i §17 i vilkårene; de øvrige træder i kraft ved offentliggørelsen. Hver version linker til sin tekst.

Ændringer af denne side #

Ændringer versioneres i Git og annonceres på sikkerhedsmailinglisten. Datoen øverst på siden angiver den seneste indholdsmæssigt betydende ændring.

Ændringslog #