Förtroende

Gäller från: 2026-05-19 – Version: 1.13

Senast uppdaterad: 2026-10-07

Sammanfattning #

fremforge är EU-suverän Git-hosting byggd på Forgejo från uppströms och drivs av fremverk ApS (Danmark). Varje yta körs i Europeiska unionen. Inga kunduppgifter lämnar EU:s jurisdiktion.

Varje behandlingsyta (repon, CI, granskning, fakturering, autentisering, utgående e-post, korrespondens till inkommande delade brevlådor) körs hos aktörer utan amerikanskt moderbolag. Inga underbiträden med amerikanskt moderbolag på någon väg. Se produktens DPA §11.3 för den fullständiga hållningen.

Den här sidan är den officiella referensen för var dina uppgifter finns, vem som behandlar dem, vilka certifieringar som gäller och hur du når oss.

Personuppgiftsansvarig #

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

Hosting och regioner #

Underbiträden #

Den aktuella förteckningen över underbiträden förs här. Varje ändring meddelas 30 dagar i förväg på säkerhetsutskicket och på den här sidan.

Skyddet mot bottar involverar inget personuppgiftsbiträde hos tredje part. Produktens formulär för registrering och inloggning använder egenhostad Altcha (MIT-licensierad, HMAC-signerad proof-of-work) som körs i samma process inuti api-monoliten på samma T Cloud Public-kluster; inget widget-JS från tredje part, inget externt underbiträde. Ytterligare kontroller på serversidan (strypning och anropsgränser per IP) gäller över hela ytan. Ingen Web Application Firewall är aktiverad vid edge; se §Edge-skydd nedan.

Edge-skydd – DDoS-skydd, ingen WAF #

Varje yta i fremforge (frem.sh för Forgejo och Git, API:et samt webbplatsen, dokumentationen, statussidan och CLI-sajten) ligger bakom Bunny CDN:s edge, som ger skydd mot volymetriska DDoS-attacker och anropsbegränsning per IP. Ingen Web Application Firewall (WAF) är aktiverad vid edge på någon av fremforges ytor, och ingen har varit det sedan före lanseringen. Beslutet är medvetet. Under testerna före lansering gav OWASP Core Rule Set en hög andel falska positiva på Forgejos typer av anrop (sökvägar i Git-protokollet, diff-vyer för pull requests, hämtning av råa blobbar med hexadecimala identifierare, frågesträngar i signerade URL:er) och på API:ets formulärdata. En överaggressiv WAF som bryter legitima Git-operationer eller flöden i Forgejos gränssnitt hade varit ett sämre utfall för kunderna än den kvarvarande risken i edge-lagret. Skyddet ligger i stället i applikationen: hemlighetsskanning i pre-receive, Altcha proof-of-work vid registrering och inloggning, anropsgränser per IP och per tenant i API:et, autentisering med signerade tokens på varje webhook-mottagare och integritetshashen i granskningskedjan. Hållningen beskrivs i DPA bilaga A.2 och omprövas vid varje kvartalsvis driftgenomgång.

Isolering av hostade runners – engångs-VM i ECS, en per commit #

CI-jobb som du pushar till fremforge körs på T Cloud Public Elastic Cloud Server (ECS): varje commit eller pull request får en egen tillfällig virtuell maskin, som skapas på nytt och förstörs när jobben för den committen är klara. Två oberoende lager av isolering:

• Beräkning / kärna – en dedikerad VM per commit. Jobben för varje commit körs i en virtuell ECS-maskin med en egen Linux-kärna, isolerad av hypervisorn. Två kunder, eller två commits, delar aldrig en kärna eller en maskin, så primitiver för att bryta sig ut ur en container via kärnan (cgroup-utbrytning, utbrytning via bind-mount av /proc, eBPF, exponering av /sys) har ingen gräns mellan tenants att ta sig över: det finns ingen delad kärna att bryta sig ut till. Isoleringsenheten är en hel VM, inte en container – en starkare gräns än den modell med containrar på delad kärna som konventionell Kubernetes (även CCE) använder för runner-poddar. VM:en rensas bort (raderas) när jobben för den committen är klara, så ingenting – byggcache, klonad kod, injicerade secrets – finns kvar till en annan commits jobb eller till någon annan kund.
• Inom en commit kan jobben dela maskin. Efterföljande jobb i samma workflow-körning (till exempel build och sedan deploy på samma commit) kan köras på samma VM, som förstörs när de är klara. Det är avsiktligt: det är samma granskade kod i båda jobben, och en ny maskin per jobb kostar ungefär 40 sekunders extra fördröjning vid start i varje steg i en pipeline. Följden, som är värd att säga rakt ut, är att ett byggsteg som kör kod från tredjepartsberoenden delar maskin med ett senare steg i samma commit. Behandla därför en pipeline som en och samma förtroendedomän, och avgränsa alla autentiseringsuppgifter som ett deploy-steg behöver till den pipelinen. Isoleringen mellan tenants och mellan commits ovan påverkas inte av detta.
• Nätverk – en VPC Security Group per VM. Varje runner-VM ligger bakom en egen VPC Security Group: ingen inkommande åtkomst, trafik mellan VM:ar (inom subnätet) nekas och utgående trafik är begränsad till den SSRF-skyddade utgående runner-proxyn, Forgejo-API:et och DNS. Isoleringen upprätthålls i VPC-/hypervisorlagret, inte i ett NetworkPolicy-lager i klustret som är beroende av att en CNI-agent beter sig korrekt. Tillsammans med den tvingande utgående proxyn och dess SSRF-spärrlista nekas lateral rörelse från en runner-VM till allt utanför kundens eget jobbsammanhang i både VM- och VPC-lagret.

Om T Cloud Publics isoleringsmodell för något av lagren ändras på ett sätt som försvagar det ovanstående (t.ex. om VM:ar per jobb ersätts med containrar på delad kärna, eller om gränsen med en Security Group per VM tas bort) uppdateras den här sidan inom 30 dagar från ändringen, och varje aktiv Kund underrättas enligt DPA §14.

Ärvda certifieringar #

Genom T Cloud Public:

• ISO/IEC 27001 – ledningssystem för informationssäkerhet
• ISO/IEC 27017 – molnspecifika säkerhetskontroller
• ISO/IEC 27018 – skydd av personuppgifter i molnet
• BSI C5 Type 2 – den tyska federala grundnivån för molnsäkerhet
• TISAX – den tyska fordonsindustrins säkerhetsbedömning
• GDPR-förenlig behandling i datacenter inom EU

fremverks egen certifieringsplan #

Per ikraftträdandedatumet har fremverk inga egna certifieringar enligt ISO 27001, SOC 2 eller BSI C5. fremverks säkerhetsarbete vilar på (i) de ärvda certifieringarna hos underbiträdena ovan, (ii) de tekniska och organisatoriska åtgärderna i DPA:ns säkerhetsbilaga och (iii) fremverks program för informationssäkerhet och säkerhetstester som beskrivs i DPA:ns säkerhetsbilaga.

fremverk har åtagit sig att:

• Inleda revision för ISO 27001 Stage 1 inom 18 månader från ikraftträdandedatumet och bli certifierat inom 24 månader.
• Inleda en beredskapsbedömning för SOC 2 Type II inom 24 månader.

Kunder som behöver direkt certifiering före de milstolparna kan teckna avtal under Enterprise-on-Demand med milstolparna för certifieringsberedskap inskrivna i Beställningen. Se DPA §12.1.

Transparens om myndighetsåtkomst #

Per ikraftträdandedatumet har fremverk tagit emot noll begäranden från myndigheter om åtkomst till Kundens personuppgifter. Den fullständiga rapporten – inklusive redovisningen för perioden före lansering – publiceras på frem.sh/trust/transparency/. Därefter omfattar rapporterna hela kalenderår och publiceras under Q1 året efter.

När fremverk tar emot ett bindande rättsligt krav från en myndighet, domstol eller brottsbekämpande organ gör fremverk följande:

• Prövar begärans rättsliga giltighet, jurisdiktion och proportionalitet;
• Bestrider varje begäran som är för omfattande, saknar rättslig grund eller strider mot EU-rätten (inklusive artikel 48 i GDPR för begäranden från länder utanför EU/EES);
• Underrättar den berörda Kunden inom 24 timmar efter mottagandet, om det inte är rättsligt förbjudet;
• Ger Kunden rimlig möjlighet att begära ett skyddsbeslut eller på annat sätt bestrida begäran.

Se DPA §11A.

DSA-transparensrapport (artikel 15) #

fremforge är en värdtjänst i den mening som avses i förordning (EU) 2022/2065 (rättsakten om digitala tjänster). Den årliga rapporten enligt art. 15 om volymer i anmälnings- och åtgärdsmekanismen, förelägganden från medlemsstaternas myndigheter, innehållsmoderering på eget initiativ och utfall av klagomål enligt art. 20 publiceras på frem.sh/trust/dsa/ – skild från rapporten om myndighetsåtkomst ovan. Samma URL innehåller det genomsnittliga antalet aktiva mottagare per månad i EU, som enligt art. 24(2) ska publiceras var sjätte månad.

Schrems II – internationella överföringar #

Ingen internationell överföring av Kundens personuppgifter sker på någon behandlingsväg. All behandling (innehåll i repon, CI-körningar, granskningsloggar, metadata för autentisering, faktureringsunderlag, uppgifter om betalningsmedel, utgående transaktionsmejl och korrespondens till inkommande delade brevlådor) sker inom EU/EES hos aktörer utan amerikanskt moderbolag. Inga skyddsåtgärder enligt artikel 46 i GDPR, inga SCC:er och ingen konsekvensbedömning av överföringar krävs.

Lokalisering av edge-PoP:ar (Bunny CDN) #

Varje pullzone hos Bunny framför frem.sh är konfigurerad att leverera endast från PoP:ar i EU – ingen cachning i USA, Australien eller Asien. Det upprätthålls i OpenTofu på varje pullzone-resurs via routing { zones = ["EU"] }. Konfigurationen av pullzonerna finns i källkodsträdet här:

• Forgejos pullzone: fremforge/forgejo/.infrastructure/main.tf – sök efter zones = ["EU"]
• API:ets pullzone: fremforge/monolith/.infrastructure/bunny.tf – samma rad
• Pullzonerna för de statiska sajterna (www, docs, status, cli) ärver samma routing-block från den delade modulen i fremverk/cloudplatform/modules/static-site/main.tf:103-112.

En tofu plan mot vilken pullzone-stack som helst skriver ut det aktiva värdet för routing.zones, så varje avvikelse från ["EU"] skulle synas som en diff i planen. Granskningsbara bevis blir direkt bläddringsbara när källkodsträdet hostas på den Forgejo-instans som kunderna använder (på https://frem.sh/fremforge/...); tills vidare publiceras dokumentationen av granskningskedjans ankare och integritetsverifieraren på docs.frem.sh/security/audit-chain/.

Om toppdomänen #

frem.sh är en landstoppdomän för Saint Helena (.sh) som administreras av en registeroperatör registrerad i Storbritannien. Det är enbart ett faktum på DNS-nivå. Inga kunduppgifter, inget tillstånd i kontrollplanet och inga backuper lämnar T Cloud Public EU-DE. Suveränitetsgarantierna (personuppgiftsbiträdets identitet, förteckningen över underbiträden, datalokalisering) fastställs i DPA:n och påverkas inte av var DNS hostas.

Ingen exponering för CLOUD Act på någon behandlingsväg. Alla Kundens personuppgifter behandlas inom EU/EES av aktörer utan amerikanskt moderbolag. Se DPA §11.3 för den fullständiga hållningen.

Fotnot om kortnätverk. Mollies PCI-DSS-attesterade kedja för korthantering omfattar Visa Europe Services Inc. (filial i Storbritannien) och Mastercard Europe SA (Belgien) – europeiska driftbolag vars yttersta moderbolag (Visa Inc., Mastercard Inc.) är registrerade i USA. Påståendet om ”inget amerikanskt moderbolag” gäller fremverks egna underbiträden på driftbolagsnivå; kortnätverken är Mollies underbiträden i andra led enligt PCI-DSS nätverksregler. Kunder som vill undvika all exponering mot amerikanska moderbolag på betalningsvägen kan betala med SEPA Direct Debit (inga kortnätverk inblandade). Se underbiträden – Fotnot om kortnätverk.

Verifiera granskningskedjan själv #

Varje administratörsåtgärd som ändrar tillstånd i din organisation registreras i en SHA-256-hashkedja per tenant, och kedjans huvud WORM-förankras varannan minut i T Cloud Public OBS Object Lock-lagring (3 års lagring, fysiskt omöjlig att radera under lagringstiden). Du kan gå igenom hela kedjan utan att behöva lita på fremverks ord.

Med 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

Eller med curl direkt mot samma endpoint som CLI:t anropar:

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

Ett friskt svar innehåller "integrity_status": "ok" och ett worm_anchor-block där agrees_with_db_walk: true bekräftar att kedjan i databasen stämmer med huvudet som förankrats i OBS. Ett brott (hash_mismatch / prev_hash_mismatch) returnerar id för den felaktiga raden och orsaken – utformat för att en revisor ska kunna läsa det. Fullständigt schema, avslutningskoder och hotmodellen finns i docs.frem.sh – granskningskedjans integritet.

Förvaring av operatörens autentiseringsuppgifter #

Administratörsuppgifter för uppstart (den domänavgränsade root-AK/SK:n i T Cloud Public som bara används för att skapa IAM, OBS-buckets och tjänstekopplade agencies första gången) förvaras på operatörens laptop med fullständig diskkryptering via FileVault och filbehörigheten chmod 600, roteras varje kvartal, skickas aldrig via chatt eller skärmdelning och kan återkallas på under 10 minuter via OTC-konsolen. Vanliga driftsättningar använder avgränsade deploy-nycklar per komponent, inte root-uppgiften.

Säkerhetskontakt #

• Rapportera sårbarheter: security@frem.sh
• Policy för rapportering: säkerhet
• PGP-nyckelns fingeravtryck: DBA3 184D 0EFA E4C2 51ED EB46 53FA 57F8 698C 3488 (publik nyckel – RFC 4880 ASCII-armerad, RSA-4096, går ut 2031-05-14). Använd den för krypterade sårbarhetsrapporter till security@frem.sh. Nyckeln publiceras bara från frem.sh/.well-known/; vi laddar inte upp den till publika nyckelservrar (för att undvika en förtroenderot hos tredje part). En spegling finns på /pgp.txt för enkelhetens skull.

Rapportering av sårbarheter #

En maskinläsbar policy för rapportering publiceras på frem.sh/.well-known/security.txt enligt RFC 9116, med skydd för forskning i god tro (safe harbour), omfattning och rapporteringskanal. Rapporter från penetrationstester av tredje part görs, när sådana beställts, tillgängliga för Kunder under sekretessavtal på skriftlig begäran enligt DPA §12.1; avtal under Enterprise-on-Demand kan reglera en viss testfrekvens i Beställningen.

Redovisning av incidenter #

Efterhandsanalyser av varje incident som påverkar kunduppgifter eller tillgänglighet publiceras på den här sidan inom 14 dagar, enligt vår säkerhetspolicy.

Säkerhetsuppdateringar #

fremforge åtar sig följande längsta tid till patch för säkerhetssårbarheter i plattformen, räknat från den rättade versionen uppströms eller publiceringen av säkerhetsmeddelandet, beroende på vad som kommer senast.

Akuta releaser utanför schemat är att räkna med. Det veckovisa underhållsfönstret är ett tak, inte ett golv. Säkerhetspatchar skjuts aldrig upp för att respektera en tenants underhållsfönster; det anges i AUP:n och citeras ordagrant i DPA:ns säkerhetsbilaga.

Utträde och dataportabilitet #

Allt går att exportera – repon, issues, pull requests, Actions-loggar, granskningsspår, SLSA-attestationer – via API:et i standardformat. Det finns ingen inlåsning genom lagring och ingen exportavgift.

Självbetjänad export som avslöjar manipulering. Varje administratör i en tenant kan när som helst starta ett fullständigt paket från administrationsgränssnittet. Paketet levereras som en enda zip-fil med ett SHA-256-manifest som täcker varje fil i arkivet (manifest.json + archive.tar.gz.sha256), så att kunden kan bekräfta att innehållet inte har manipulerats efter nedladdningen. Paketet innehåller git bundle-filer för repona, LFS-manifest, Actions-loggar, utdrag ur granskningsloggen och SLSA-attestationer. Som jämförelse är GitHubs export av en organisation en uppsättning REST-API-anrop, tillgängliga för organisationens ägare, som skapar ett arkiv avsett för import i GitHub Enterprise Server (GitHubs dokumentation, läst 17 oktober 2026). fremforge levererar det i varje plan, till varje kund, varje dag. Manifestet signeras med vår SLSA-byggnyckel (DSSE-kuvert, manifest.json.intoto.jsonl); kunder verifierar med samma förtroenderot på https://www.frem.sh/.well-known/slsa-trust-root.json som publiceras för SLSA-attestationer av byggen. Att verifiera manifestet kräver ingen Sigstore alls – varken den publika instansen eller den egenhostade Fulcio och TSA som vi kör som en andra signatur på byggattestationer. Se docs.frem.sh/data-export för paketets struktur, recept för verifiering och API-endpoints.

Tidsplaner och rutiner för när en tenant avslutas beskrivs i DPA:n.

Cookies och spårning #

fremforge sätter bara strikt nödvändiga cookies på produktens inloggade ytor, och inga cookies alls på webbplatsen, dokumentationen, statussidan och sidor för anonyma besökare. Ingen samtyckesbanner behövs: inte för att vi gömt frågan, utan för att vi inte sätter cookies som skulle kräva samtycke.

Produktens inloggade ytor sätter fyra förstapartscookies, alla strikt nödvändiga enligt artikel 5(3) i ePrivacy-direktivet:

Webbplatsen, dokumentationen och statussidan (www.frem.sh, docs.frem.sh, status.frem.sh) är statiska sajter byggda med Hugo, utan cookies, utan analys, utan inbäddningar och utan någon form av spårning. Det kan du kontrollera i webbläsarens utvecklarverktyg.

Anrop till tredje part från produktens gränssnitt är avstängda som standard: ingen Gravatar, inga federerade avatarer, inga typsnitt eller skript från CDN, ingen analys från tredje part. Avatarer lagras lokalt; typsnitt levereras från samma origin som forgen.

Det här är en medveten hållning i produkten, inte ett minimum för efterlevnad. Den fullständiga förteckningen över cookies och de registrerades rättigheter beskrivs i produktens integritetspolicy.

Ändringar av säkerhetsåtgärderna #

Bilaga A till DPA:n listar de tekniska och organisatoriska åtgärder som fremverk tillämpar och anger att väsentliga ändringar av dem meddelas här. Ändringar från och med 2026-10-04 listas nedan, med den senaste först; tidigare ändringar finns i DPA:ns ändringslogg. En ändring som minskar ett åtagande träder i kraft 30 dagar efter ett besked till varje administratör hos Kunden, med uppsägningsrätten i Villkoren §17; övriga träder i kraft när de publiceras. Varje version länkar till sin text.

Ändringar av den här sidan #

Ändringar versionshanteras i Git och meddelas på säkerhetsutskicket. Datumet överst på sidan anger den senaste innehållsmässigt betydelsefulla ändringen.

Ändringslogg #