Tillit

Gjelder fra: 2026-05-19 – Versjon: 1.13

Sist oppdatert: 2026-10-07

Sammendrag #

fremforge er EU-suveren Git-hosting bygget på Forgejo fra upstream og drevet av fremverk ApS (Danmark). Hver flate kjører i Den europeiske union. Ingen kundeopplysninger forlater EUs jurisdiksjon.

Hver behandlingsflate (repositoryer, CI, revisjon, fakturering, autentisering, utgående e-post, korrespondanse til innkommende delte postbokser) kjører hos aktører uten amerikansk morselskap. Ingen underleverandører med amerikansk morselskap på noen vei. Se produktets DPA §11.3 for den fullstendige posisjonen.

Denne siden er den offisielle referansen for hvor opplysningene dine ligger, hvem som behandler dem, hvilke sertifiseringer som gjelder, og hvordan du når oss.

Behandlingsansvarlig #

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

Hosting og regioner #

Underleverandører #

Den gjeldende oversikten over underleverandører føres her. Hver endring varsles 30 dager i forveien på sikkerhetsutsendelsen og på denne siden.

Beskyttelsen mot boter involverer ingen databehandler hos tredjepart. Produktets skjemaer for registrering og innlogging bruker selvhostet Altcha (MIT-lisensiert, HMAC-signert proof-of-work) som kjører i samme prosess inne i api-monolitten på samme T Cloud Public-klynge; ikke noe widget-JS fra tredjepart, ingen ekstern underleverandør. Ytterligere kontroller på serversiden (struping og frekvensgrenser per IP) gjelder over hele flaten. Ingen Web Application Firewall er aktivert ved edge; se §Edge-beskyttelse nedenfor.

Edge-beskyttelse – DDoS-beskyttelse, ingen WAF #

Hver flate i fremforge (frem.sh for Forgejo og Git, API-et samt nettstedet, dokumentasjonen, statussiden og CLI-siden) ligger bak edge-laget til Bunny CDN, som gir beskyttelse mot volumetriske DDoS-angrep og frekvensbegrensning per IP. Ingen Web Application Firewall (WAF) er aktivert ved edge på noen av fremforges flater, og ingen har vært det siden før lanseringen. Beslutningen er bevisst. Under testene før lansering ga OWASP Core Rule Set en høy andel falske positiver på Forgejos typer forespørsler (stier i Git-protokollen, diff-visninger for pull requests, henting av rå blober med heksadesimale identifikatorer, spørrestrenger i signerte URL-er) og på API-ets skjemadata. En overaggressiv WAF som ødelegger legitime Git-operasjoner eller flyter i Forgejo-grensesnittet, ville vært et dårligere utfall for kundene enn den gjenværende risikoen i edge-laget. Beskyttelsen ligger i stedet i applikasjonen: skanning etter secrets i pre-receive, Altcha proof-of-work ved registrering og innlogging, frekvensgrenser per IP og per organisasjon i API-et, autentisering med signerte tokener på hver webhook-mottaker og integritetshashen i revisjonskjeden. Posisjonen er beskrevet i DPA vedlegg A.2 og vurderes på nytt ved hver kvartalsvise driftsgjennomgang.

Isolasjon av hostede runnere – engangs-VM i ECS, én per commit #

CI-jobber du pusher til fremforge, kjører på T Cloud Public Elastic Cloud Server (ECS): hver commit eller pull request får sin egen midlertidige virtuelle maskin, som opprettes på nytt og slettes når jobbene for den commiten er ferdige. To uavhengige lag med isolasjon:

• Databehandling / kjerne – én dedikert VM per commit. Jobbene for hver commit kjører i en virtuell ECS-maskin med egen Linux-kjerne, isolert av hypervisoren. To kunder, eller to commits, deler aldri en kjerne eller en maskin, så primitiver for å bryte ut av en container via kjernen (cgroup-utbrudd, utbrudd via bind-mount av /proc, eBPF, eksponering av /sys) har ingen grense mellom kunder å krysse: det finnes ingen delt kjerne å bryte ut til. Isolasjonsenheten er en hel VM, ikke en container – en sterkere grense enn modellen med containere på delt kjerne som konvensjonell Kubernetes (også CCE) bruker for runner-poder. VM-en ryddes bort (slettes) når jobbene for den commiten er ferdige, så ingenting – byggebuffer, klonet kode, injiserte secrets – blir værende til en annen commits jobb eller til noen annen kunde.
• Innenfor én commit kan jobbene dele maskin. Påfølgende jobber i samme workflow-kjøring (for eksempel build og deretter deploy på samme commit) kan kjøre på samme VM, som slettes når de er ferdige. Det er med vilje: det er den samme gjennomgåtte koden i begge jobbene, og en ny maskin per jobb koster omtrent 40 sekunder ekstra forsinkelse ved oppstart i hvert steg i en pipeline. Konsekvensen, som er verdt å si rett ut, er at et byggesteg som kjører kode fra tredjepartsavhengigheter, deler maskin med et senere steg i samme commit. Behandle derfor en pipeline som ett og samme tillitsdomene, og avgrens all legitimasjon et utrullingssteg trenger, til den pipelinen. Isolasjonen mellom kunder og mellom commits ovenfor påvirkes ikke av dette.
• Nettverk – én VPC Security Group per VM. Hver runner-VM ligger bak sin egen VPC Security Group: ingen innkommende tilgang, trafikk mellom VM-er (innenfor subnettet) avvises, og utgående trafikk er begrenset til den SSRF-beskyttede utgående runner-proxyen, Forgejo-API-et og DNS. Isolasjonen håndheves i VPC-/hypervisorlaget, ikke i et NetworkPolicy-lag i klyngen som er avhengig av at en CNI-agent oppfører seg riktig. Sammen med den påtvungne utgående proxyen og SSRF-sperrelisten dens avvises sideveis bevegelse fra en runner-VM til alt utenfor kundens egen jobbkontekst i både VM- og VPC-laget.

Hvis T Cloud Publics isolasjonsmodell for noen av lagene endres på en måte som svekker det ovenstående (f.eks. hvis VM-er per jobb erstattes med containere på delt kjerne, eller hvis grensen med én Security Group per VM fjernes), oppdateres denne siden innen 30 dager etter endringen, og hver aktive Kunde varsles etter DPA §14.

Arvede sertifiseringer #

Gjennom T Cloud Public:

• ISO/IEC 27001 – styringssystem for informasjonssikkerhet
• ISO/IEC 27017 – skyspesifikke sikkerhetskontroller
• ISO/IEC 27018 – beskyttelse av personopplysninger i skyen
• BSI C5 Type 2 – det tyske føderale grunnnivået for skysikkerhet
• TISAX – den tyske bilindustriens sikkerhetsvurdering
• GDPR-forenlig behandling i datasentre i EU

fremverks egen sertifiseringsplan #

Per ikrafttredelsesdatoen har fremverk ingen egne sertifiseringer etter ISO 27001, SOC 2 eller BSI C5. fremverks sikkerhetsarbeid hviler på (i) de arvede sertifiseringene hos underleverandørene ovenfor, (ii) de tekniske og organisatoriske tiltakene i DPA-ens sikkerhetsvedlegg og (iii) fremverks program for informasjonssikkerhet og sikkerhetstester som er beskrevet i DPA-ens sikkerhetsvedlegg.

fremverk har forpliktet seg til å:

• Starte revisjon for ISO 27001 Stage 1 innen 18 måneder fra ikrafttredelsesdatoen og bli sertifisert innen 24 måneder.
• Starte en beredskapsvurdering for SOC 2 Type II innen 24 måneder.

Kunder som trenger direkte sertifisering før disse milepælene, kan inngå avtale under Enterprise-on-Demand med milepælene for sertifiseringsberedskap skrevet inn i Bestillingen. Se DPA §12.1.

Åpenhet om myndighetstilgang #

Per ikrafttredelsesdatoen har fremverk mottatt null anmodninger fra myndigheter om tilgang til Kundens personopplysninger. Den fullstendige rapporten – inkludert redegjørelsen for perioden før lansering – publiseres på frem.sh/trust/transparency/. Deretter omfatter rapportene hele kalenderår og publiseres i 1. kvartal året etter.

Når fremverk mottar et bindende rettslig pålegg fra en myndighet, domstol eller politimyndighet, gjør fremverk følgende:

• Vurderer anmodningens rettslige gyldighet, jurisdiksjon og forholdsmessighet;
• Bestrider hver anmodning som er for omfattende, mangler rettslig grunnlag eller strider mot EU-retten (inkludert artikkel 48 i GDPR for anmodninger fra land utenfor EU/EØS);
• Varsler den berørte Kunden innen 24 timer etter mottak, med mindre det er rettslig forbudt;
• Gir Kunden rimelig mulighet til å be om en beskyttelsesavgjørelse eller på annen måte bestride anmodningen.

Se DPA §11A.

DSA-transparensrapport (artikkel 15) #

fremforge er en vertstjeneste i den betydningen som brukes i forordning (EU) 2022/2065 (forordningen om digitale tjenester). Den årlige rapporten etter art. 15 om volumer i varslings- og tiltaksmekanismen, pålegg fra myndigheter i medlemsstatene, innholdsmoderering på eget initiativ og utfall av klager etter art. 20 publiseres på frem.sh/trust/dsa/ – atskilt fra rapporten om myndighetstilgang ovenfor. Den samme URL-en inneholder det gjennomsnittlige antallet aktive mottakere per måned i EU, som etter art. 24(2) skal publiseres hver sjette måned.

Schrems II – internasjonale overføringer #

Ingen internasjonal overføring av Kundens personopplysninger skjer på noen behandlingsvei. All behandling (innhold i repositoryer, CI-kjøringer, revisjonslogger, metadata for autentisering, faktureringsgrunnlag, opplysninger om betalingsmidler, utgående transaksjonell e-post og korrespondanse til innkommende delte postbokser) skjer i EU/EØS hos aktører uten amerikansk morselskap. Ingen garantier etter artikkel 46 i GDPR, ingen SCC-er og ingen vurdering av overføringer er nødvendig.

Lokalisering av edge-PoP-er (Bunny CDN) #

Hver pullzone hos Bunny foran frem.sh er konfigurert til å levere bare fra PoP-er i EU – ingen bufring i USA, Australia eller Asia. Det håndheves i OpenTofu på hver pullzone-ressurs gjennom routing { zones = ["EU"] }. Det gjelder alle pullzoner: Forgejo, API-et og de statiske nettstedene (www, docs, status, cli).

En tofu plan mot hvilken som helst pullzone-stakk skriver ut den aktive verdien for routing.zones, så ethvert avvik fra ["EU"] ville vist seg som en diff i planen. Dokumentasjonen av revisjonskjedens anker og integritetsverifikatoren er publisert på docs.frem.sh/nb/security/audit-chain/.

Om toppdomenet #

frem.sh er et landstoppdomene for Saint Helena (.sh) som administreres av en registeroperatør registrert i Storbritannia. Det er bare et faktum på DNS-nivå. Ingen kundeopplysninger, ingen tilstand i kontrollplanet og ingen backuper forlater T Cloud Public EU-DE. Suverenitetsgarantiene (databehandlerens identitet, oversikten over underleverandører, datalokalisering) er fastsatt i DPA-en og påvirkes ikke av hvor DNS hostes.

Ingen eksponering for CLOUD Act på noen behandlingsvei. Alle Kundens personopplysninger behandles i EU/EØS av aktører uten amerikansk morselskap. Se DPA §11.3 for den fullstendige posisjonen.

Fotnote om kortnettverk. Mollies PCI-DSS-attesterte kjede for korthåndtering omfatter Visa Europe Services Inc. (filial i Storbritannia) og Mastercard Europe SA (Belgia) – europeiske driftsselskaper der de øverste morselskapene (Visa Inc., Mastercard Inc.) er registrert i USA. Påstanden om «ikke noe amerikansk morselskap» gjelder fremverks egne underleverandører på driftsselskapsnivå; kortnettverkene er Mollies underleverandører i annet ledd etter PCI-DSS-nettverksreglene. Kunder som vil unngå all eksponering mot amerikanske morselskaper på betalingsveien, kan betale med SEPA Direct Debit (ingen kortnettverk involvert). Se underleverandører – Fotnote om kortnettverk.

Verifiser revisjonskjeden selv #

Hver administratorhandling som endrer tilstand i organisasjonen din, registreres i en SHA-256-hashkjede per organisasjon, og hodet på kjeden WORM-forankres hvert annet minutt i T Cloud Public OBS Object Lock-lagring (3 års oppbevaring, fysisk umulig å slette i oppbevaringstiden). Du kan gå gjennom hele kjeden uten å måtte stole 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 direkte mot det samme endepunktet som CLI-et kaller:

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 friskt svar inneholder "integrity_status": "ok" og en worm_anchor-blokk der agrees_with_db_walk: true bekrefter at kjeden i databasen stemmer med hodet som er forankret i OBS. Et brudd (hash_mismatch / prev_hash_mismatch) returnerer ID-en til den feilaktige raden og årsaken – utformet for at en revisor skal kunne lese det. Fullstendig skjema, avslutningskoder og trusselmodellen finnes i docs.frem.sh – revisjonskjedens integritet.

Oppbevaring av operatørens legitimasjon #

Administratorlegitimasjon for oppstart (den domeneavgrensede root-AK/SK-en i T Cloud Public som bare brukes til å opprette IAM, OBS-bøtter og tjenestetilknyttede agencies første gang) oppbevares på operatørens laptop med full diskkryptering via FileVault og filtillatelsen chmod 600, roteres hvert kvartal, sendes aldri via chat eller skjermdeling og kan tilbakekalles på under 10 minutter via OTC-konsollen. Vanlige utrullinger bruker avgrensede deploy-nøkler per komponent, ikke root-legitimasjonen.

Sikkerhetskontakt #

• Rapporter sårbarheter: security@frem.sh
• Policy for rapportering: sikkerhet
• Fingeravtrykket til PGP-nøkkelen: DBA3 184D 0EFA E4C2 51ED EB46 53FA 57F8 698C 3488 (offentlig nøkkel – RFC 4880 ASCII-armert, RSA-4096, utløper 2031-05-14). Bruk den for krypterte sårbarhetsrapporter til security@frem.sh. Nøkkelen publiseres bare fra frem.sh/.well-known/; vi laster den ikke opp til offentlige nøkkelservere (for å unngå en tillitsrot hos tredjepart). Et speil finnes på /pgp.txt for enkelhets skyld.

Rapportering av sårbarheter #

En maskinlesbar policy for rapportering publiseres på frem.sh/.well-known/security.txt i henhold til RFC 9116, med beskyttelse for forskning i god tro (safe harbour), omfang og rapporteringskanal. Rapporter fra penetrasjonstester utført av tredjepart gjøres, når slike er bestilt, tilgjengelige for Kunder under taushetsavtale på skriftlig forespørsel etter DPA §12.1; avtaler under Enterprise-on-Demand kan regulere en bestemt testfrekvens i Bestillingen.

Redegjørelse for hendelser #

Etteranalyser av hver hendelse som påvirker kundeopplysninger eller tilgjengelighet, publiseres på denne siden innen 14 dager, etter sikkerhetspolicyen vår.

Sikkerhetsoppdateringer #

fremforge forplikter seg til følgende lengste tid til patch for sikkerhetssårbarheter i plattformen, regnet fra den rettede versjonen hos upstream eller publiseringen av sikkerhetsvarselet, avhengig av hva som kommer sist.

Akutte utgivelser utenfor tidsplanen må påregnes. Det ukentlige vedlikeholdsvinduet er et tak, ikke et gulv. Sikkerhetspatcher utsettes aldri for å respektere en organisasjons vedlikeholdsvindu; det står i AUP-en og siteres ordrett i DPA-ens sikkerhetsvedlegg.

Avslutning og dataportabilitet #

Alt kan eksporteres – repositoryer, issues, pull requests, Actions-logger, revisjonsspor, SLSA-attesteringer – gjennom API-et i standardformater. Det finnes ingen innlåsing gjennom lagring og ingen eksportavgift.

Manipulasjonsavslørende eksport med selvbetjening. Hver administrator i en organisasjon kan når som helst starte en fullstendig pakke fra administrasjonsgrensesnittet. Pakken leveres som én zip-fil med et SHA-256-manifest som dekker hver fil i arkivet (manifest.json + archive.tar.gz.sha256), slik at kunden kan bekrefte at innholdet ikke er manipulert etter nedlastingen. Pakken inneholder git bundle-filer for repositoryene, LFS-manifester, Actions-logger, utdrag av revisjonsloggen og SLSA-attesteringer. Til sammenligning er GitHubs eksport av en organisasjon et sett REST-API-kall, tilgjengelige for organisasjonens eiere, som lager et arkiv beregnet på import i GitHub Enterprise Server (GitHubs dokumentasjon, lest 17. oktober 2026). fremforge leverer det i hver plan, til hver kunde, hver dag. Manifestet signeres med SLSA-byggenøkkelen vår (DSSE-konvolutt, manifest.json.intoto.jsonl); kunder verifiserer med den samme tillitsroten på https://www.frem.sh/.well-known/slsa-trust-root.json som publiseres for SLSA-attesteringer av bygg. Å verifisere manifestet krever ingen Sigstore i det hele tatt – verken den offentlige instansen eller den selvhostede Fulcio og TSA som vi kjører som en andre signatur på byggeattesteringer. Se docs.frem.sh/data-export for pakkens struktur, oppskrifter for verifisering og API-endepunkter.

Tidsplaner og rutiner for når en organisasjon avsluttes, er beskrevet i DPA-en.

Informasjonskapsler og sporing #

fremforge setter bare strengt nødvendige informasjonskapsler på produktets innloggede flater, og ingen informasjonskapsler i det hele tatt på nettstedet, dokumentasjonen, statussiden og sider for anonyme besøkende. Det trengs ingen samtykkebanner: ikke fordi vi har gjemt spørsmålet, men fordi vi ikke setter informasjonskapsler som ville kreve samtykke.

Produktets innloggede flater setter fire førsteparts informasjonskapsler, alle strengt nødvendige etter artikkel 5(3) i ePrivacy-direktivet:

Nettstedet, dokumentasjonen og statussiden (www.frem.sh, docs.frem.sh, status.frem.sh) er statiske nettsteder bygget med Hugo, uten informasjonskapsler, uten analyse, uten innebygginger og uten noen form for sporing. Det kan du kontrollere i nettleserens utviklerverktøy.

Kall til tredjeparter fra produktets grensesnitt er slått av som standard: ingen Gravatar, ingen fødererte avatarer, ingen skrifttyper eller skript fra CDN, ingen analyse fra tredjepart. Avatarer lagres lokalt; skrifttyper leveres fra samme origin som forgen.

Dette er en bevisst posisjon i produktet, ikke et minimum for etterlevelse. Den fullstendige oversikten over informasjonskapsler og de registrertes rettigheter er beskrevet i produktets personvernerklæring.

Endringer i sikkerhetstiltakene #

Vedlegg A til DPA-en lister opp de tekniske og organisatoriske tiltakene fremverk bruker, og sier at vesentlige endringer i dem varsles her. Endringer fra og med 2026-10-04 er listet opp nedenfor, med den nyeste først; tidligere endringer står i DPA-ens endringslogg. En endring som reduserer en forpliktelse, trer i kraft 30 dager etter et varsel til hver administrator hos Kunden, med oppsigelsesretten i Vilkårene §17; andre trer i kraft når de publiseres. Hver versjon lenker til sin tekst.

Endringer på denne siden #

Endringer versjonsstyres i Git og varsles på sikkerhetsutsendelsen. Datoen øverst på siden viser den siste innholdsmessig betydningsfulle endringen.

Endringslogg #