Sikkerhetsfunksjoner i korte trekk
Alt fremforge leverer, i én tabell det er lett å skumlese. Hver rad lenker til den egne siden med konfigurasjon, hvordan du overstyrer, og dokumentasjonen for det underliggende verktøyet.
fremforge er bevisst åpen om OSS-verktøyene under hver kontroll: kunder som gjennomgås etter BSI C5, ISO 27001, BaFin eller ENISA-regulering, trenger revisjonssporet helt ned på verktøynivå, og vi vil heller at du kan greppe i kildekoden vår enn reversere en svart boks. Det som skiller oss ut, er integrasjonen (hooks, RBAC, revisjonskjede, data i EU, ingen Microsoft, ingen AWS) – ikke skanneren.
Kontroller ved push av kode
| Kontroll | Hva den gjør | Verktøy | Kan konfigureres per tenant |
|---|---|---|---|
| Push-beskyttelse | Skanning etter secrets før mottak; avviser commits som inneholder legitimasjon før de havner i Git-historikken | Gitleaks v8 (over 120 mønstre) | Overstyringsregler og omgåelse per mønster |
| Branchbeskyttelse | Regler per branch: påkrevde godkjennere, statussjekker, krav om signerte commits, blokkering av force-push | Innebygd i Forgejo | Ja (per branch) |
| Tofaktorautentisering | TOTP for alle brukerkontoer; håndheving av WebAuthn er tilgjengelig på organisasjonsnivå (brukerne registrerer WebAuthn på sikkerhetssiden i Forgejos brukerinnstillinger). Kan håndheves per organisasjon | Innebygd i Forgejo + egne hooks for håndheving | Ja (håndheving for hele organisasjonen, tilvalg per bruker) |
| Bekreftelse av OIDC-MFA | Bekreft kryptografisk at identitetsleverandøren din bekreftet MFA ved hver innlogging, via OIDC-claimen amr (RFC 8176). Erstatter den gamle avkrysningsboksen «stol på IdP-MFA» som operatøren bekreftet – tokenet sier ["pwd","mfa"], ellers er det ikke MFA | Egen mellomvare som sjekker claims | Policy for påkrevd amr per tenant |
| SSO break-glass | Når identitetsleverandøren er utilgjengelig, feilkonfigurert eller SSO-tilkoblingen er brutt, kan navngitte eiere av organisasjonen gjenopprette tilgangen via en separat administrert nødtilgang (break-glass). Logges i revisjonsloggen | Eget (skrevet av fremforge) | Navngitte eiere per tenant |
| Nøkkelfri commit-signering (sigstore / gitsign) | Signering bundet til OIDC – identiteten din hos identitetsleverandøren (Entra, Okta, Google Workspace, Authentik) signerer commiten via et Fulcio-sertifikat som gjelder i 10 minutter. Forgejo viser Verified by sigstore: <email> via <IdP>. Rot-CA i T Cloud Public DEW KMS (FIPS 140-2 nivå 3 HSM, Tyskland). Fulcio på sign.frem.sh, TSA på tsa.frem.sh. Bevisst ingen Rekor / transparenslogg – bare tidsstempling forankret i TSA, slik at signaturer holdes unna alle tredjepartslogger | Selvhostet Fulcio v1.8.5 + TSA på T Cloud Public eu-de, gitsign hos kunden | Organisasjonsadministrasjon → Tillatte URL-er for OIDC-utstedere + strenghetsnivå |
| Commit-signering – SSH-nøkkel | Signer commits med den samme SSH-nøkkelen som Forgejo bruker for push. Merket «Verified» vises direkte i nettgrensesnittet. Kan brukes sammen med nøkkelfri signering; organisasjonsadministratoren setter strenghetsnivået | OpenSSH + Forgejos allowedSignersFile | Slås på per bruker |
| Commit-signering – GPG | Den vanlige flyten med git commit.gpgsign. Last opp den offentlige nøkkelen i brukerinnstillingene, så bekrefter Forgejo og viser merket «Verified» | GnuPG + innebygd i Forgejo | Slås på per bruker |
Kodekvalitet og sårbarhetsskanning
Disse skannerne kjører sentralt på fremforges egne skannere for hver pull request og på standardbranchen. Det er ingen workflow-fil å installere i repositoryene dine. Resultatene vises under Sikkerhet › Funn.
| Kontroll | Hva den gjør | Verktøy | Kan konfigureres |
|---|---|---|---|
| SAST | Statisk analyse for hver PR og på standardbranchen, kjørt sentralt på fremforges egne skannere – det finnes ingen workflow-fil i repoet ditt å installere eller vedlikeholde. Finner injeksjon, XSS, hardkodede secrets og farlige API-er i C, C++, C#, Go, Java, JavaScript og TypeScript, Kotlin, PHP, Python, Ruby, Rust, Scala, Swift og Bash | OpenGrep med GitLab sast-rules, 0xdea-regler for C/C++ og fremforges egne regler | Alvorlighetsgrad som blokkerer; dine egne OpenGrep-regler, hver av dem sjekket mot sitt eget eksempel før den kjører |
| Skanning etter secrets | gitleaks for hver pull request (sjekken fremforge/secret-scan) og en ukentlig gjennomgang av hele historikken i hvert repository; push-beskyttelse blokkerer secrets ved push | Gitleaks | Sjekken for pull requests av eller på |
| IaC-skanning | Sjekker for feilkonfigurasjon med trivy config (Dockerfile, Compose, Kubernetes, Helm, Terraform med mer) for hver PR, som sjekken fremforge/iac-scan med en egen fane for funn, pluss organisasjonens egne Rego-sjekker; blokkerer bare på det en PR legger til; funn gruppert etter CIS-benchmark og NIS2-område i samsvarsrapporten | Trivy | Modus og terskel under Sikkerhet › Policyer › Skannere |
| Avhengighetsskanning (OSV) | Skanning av avhengigheter for CVE/GHSA for hver PR, kjørt sentralt på fremforges egne skannere. Viser CVE-er som kan rettes, med foreslått oppgradering | osv-scanner | Terskel for alvorlighetsgrad |
| Nåbarhet | Merker hvert funn i avhengigheter og imager som nåbart, ikke nåbart eller ukjent, med bevis (fil og linje, eller den berørte funksjonen), og rangerer lister, anbefalinger og oppsummeringen etter det. Go: govulncheck på binærfilene i imagene dine. JavaScript og TypeScript: Jelly, på importnivå med mindre varselet navngir funksjoner. Python, Java og Kotlin: importnivå, også gjennom andre pakker, aldri unreachable. Ingenting skjules eller avvises; hva som blokkerer en merge, er uendret med mindre du slår det på | govulncheck, Jelly, fremforges importlesere | Tilvalg: SLA-multiplikator (1–4) for funn som ikke er nåbare; tilvalg: «ikke blokker pull requests på funn som ikke er nåbare» |
| Kjent utnyttet | Markerer funn der CVE-en er oppført som utnyttet i ENISAs EU Vulnerability Database eller CISAs KEV-katalog: et merke og et filter, rangert foran EPSS, får aldri en forlenget SLA, AutoFix først. Begge listene oppdateres daglig | Speil av ENISA EUVD og CISA KEV | - |
| Sikkerhetsrettelser | Ett klikk åpner én pull request som løfter en sårbar avhengighet til den laveste versjonen som retter alle åpne sårbarhetsvarsler (økosystemene under Støttede økosystemer), eller som løfter FROM-basen i et image; Fix all per repository. Merges aldri automatisk. Valgfrie AI-rettelser for en kort liste SAST-regler bruker bare din egen modelleverandør og er av som standard | Hostet Renovate; din egen AI-leverandør for SAST-rettelser | Grenser per repo og per organisasjon; AI-rettelser av som standard |
| Regelbaserte rettelser | Åpne PR med rettelse på et funn av en secret flytter legitimasjonen til en miljøvariabel (Go, Python, JavaScript, TypeScript); på seks IaC-sjekker setter den egenskapen til den sikre verdien. En fast regel, ingen AI: ingenting forlater fremforge. Syntakssjekket og skannet på nytt først, merges aldri automatisk | gitleaks og Trivy, skannerne som fant funnet | Grenser per repo og per organisasjon |
| Skanning av containerimager | fremforges sentrale skanner kjører Trivy (ingen installasjon): trivy fs og trivy config for hver PR, trivy image på hvert image i registeret ditt og hvert image som pulles gjennom avhengighetsproxyen. Funn vises under Sikkerhet › Funn › Containerimager, knyttet til imaget og commiten. En blokkeringshandling for imager (none, warn, block_pull) gjelder funn på eller over terskelen for imager, høy som standard | Trivy | Blokkeringshandling, terskel og ignore-filer |
| Lisensskanning | Lisensgjenkjenning med Trivy for hver PR, kjørt sentralt på fremforges egne skannere. Klassifiserer lisensen til hver avhengighet i en alvorlighetsgrad for SPDX-policy med 7 kategorier (permissive → reciprocal → restricted → forbidden); blokkerer merge på funn på eller over den konfigurerte terskelen. Vises under Sikkerhet › Funn › Lisenser | Trivy | Alvorlighetsgrad som blokkerer + SPDX-tillatelsesliste + avvisning per funn |
| OpenSSF Scorecard | Ukentlig poengsum for beste praksis per repo. Ikke en workflow per repo – kjører ukentlig på isolert plattforminfrastruktur med en skrivebeskyttet bot per tenant som bare har lesetilgang til repoene; uendrede repoer hoppes over, og bare JSON-filen med poengsummen beholdes. Viser mangler (branchbeskyttelse, håndheving av MFA, festede avhengigheter, dekning av kodegjennomgang) som en kolonne på Repos-siden | scorecard | Ukentlig frekvens + hopper over uendret HEAD |
| Ondsinnede pakker | OSV-varsler av typen MAL-* matchet mot SBOM-en for hvert repositorys standardbranch og språkpakkene i hvert publiserte containerimage, etter hver push og daglig. Alltid kritiske; pull av imager med et åpent funn avvises | osv-scanner + Trivy | Avvis med begrunnelse og sluttdato |
| Pakkepolicyer | Én policy per organisasjon avgjør hvilke registerpakker som kan lastes ned: terskler for sårbarheter (alvorlighetsgrad, CVSS, EPSS, retting tilgjengelig), SPDX-lisenslister, tillatelses- og sperrelister med versjonsområder, og en minstealder. Unntak må godkjennes av en annen person. Enforce avviser med 403, Shadow (standard) registrerer; en fil som inneholder kjent skadevare, avvises i alle moduser. Containerimager: bare shadow | Syft + osv-scanner | Modus, regler, overstyringer per type, unntak |
| Skadevareskanning av opplastinger | ClamAV over Git-LFS-objekter, vedlegg på nett og pakkeopplastinger. Avhengighetsproxyen skanner hentede pakker og imagelag med ClamAV når organisasjonen din slår det på (av som standard) | ClamAV med signaturer fra SaneSecurity, YARA-Forge Core og Linux Malware Detect | Overstyring på signaturer med kjente falske positiver |
| Sikkerhetssperre for workflower | En sjekk før mottak tolker hver endret workflow-YAML og avviser pusher som innfører: docker://-referanser til registre som ikke er på tillatelseslisten, farlige injeksjonsmønstre med pull_request_target + script, ufestede uses:-referanser til organisasjoner som ikke er speilet | Egne regler (skrevet av fremforge) | Overstyring av tillatelseslisten for docker-URI-er per tenant |
| IP-tillatelsesliste | Én liste per organisasjon over tillatte CIDR-områder for alle HTTPS-flater: webadministrasjon, fremforge-API-et, nettgrensesnittet for repositoryer, Forgejos REST-API, Git over HTTPS, LFS og pakkeregistre. Git over SSH er ikke dekket. Forhåndsvisning i ren revisjonsmodus og 24 timers break-glass for eiere | Egne regler (skrevet av fremforge) | CIDR-liste per tenant + bryter for runnere |
Proveniens i forsyningskjeden
| Kontroll | Hva den gjør | Verktøy | Kan konfigureres |
|---|---|---|---|
| SBOM-er | SBOM-er i CycloneDX 1.6 og SPDX 2.3 genereres sentralt for hver PR (begge formatene godtas ved innlesing). Når en utgivelse publiseres, bindes SBOM-en som allerede finnes for den commiten, til utgivelsen i stedet for at den skannes på nytt, så en SBOM for en utgivelse trenger ikke noe bygg og vises med en gang. Kan søkes i under Sikkerhet › Komponenter › SBOM-er | Syft | Oppbevaringsvindu + utgivelsesreferanser |
| Signert attestasjon av publisering | En in-toto-/SLSA-provenance-DSSE-konvolutt generert på serversiden av fremforge ved Forgejo-webhooks for release.published / package – ingen workflow-fil i repoene dine. fremforge hasher hver ressurs og signerer med en Ed25519-nøkkel som plattformen holder (keyid fremforge-slsa-builder-v1, builder https://frem.sh/runner-controller/v1), lastet opp ved siden av ressursen som <asset>.intoto.jsonl, pluss en andre nøkkelfri signatur mot fremforges selvhostede Fulcio + RFC3161-TSA som <asset>.sigstore.json. Ingen offentlig Sigstore, ingen Rekor, ingen transparenslogg. Bekreft lokalt med den publiserte tillitsroten – se SLSA provenance. Bevisst ikke beskrevet som et SLSA-nivå: den attesterer hva som ble PUBLISERT, ikke hvordan det ble bygget; utledningen og hva som mangler, står i SLSA provenance | Egen signerer på serversiden (Nodes standardbibliotek crypto, Ed25519-DSSE) + selvhostet Sigstore | – |
| Signering og bekreftelse av imager med cosign | Den sentrale pull request-sjekken fremforge/cosign-verify bekrefter signaturene til imager festet med digest, enten fra organisasjonens egne workflower gjennom fremforges Sigstore eller fra den offentlige Sigstore, og sier fra når den ikke kunne sjekke. Den er informativ. Policyen for imagesignaturer kan også kreve signerte imager ved pull, med identitetene du stoler på. Kundens CI signerer med sin egen OIDC-identitet – ingen langlivede signeringsnøkler | cosign + selvhostet Fulcio | Signaturpolicy (shadow eller enforce) |
| Festing av workflower | En daglig skanning lister hver uses: i .forgejo/workflows/, .gitea/workflows/ og .github/workflows/ som peker på en tagg eller branch i stedet for en commit-SHA på 40 tegn, og hvert docker://-steg-image som refereres med tagg i stedet for digest; ett klikk åpner en pull request som fester actionene | Eget (skrevet av fremforge) | – |
| Action-speil | uses: actions/checkout@v4 løses til frem.sh/actions/checkout – Forgejos innebygde pull-speil av upstream, synkronisert hver 8. time. Ingen henting fra github.com under bygging på kundens kritiske vei. Speilede organisasjoner inkluderer actions, docker, pnpm, aws-actions, azure, google-github-actions, peter-evans, softprops, sonarsource, step-security, dorny | Forgejos innebygde pull-speil (oppløsning av actions bare i EU) | (Administreres av operatøren; usynlig for kundene) |
| Kompatibilitet med Marketplace | De 20 mest brukte GitHub Marketplace-actionene er bekreftet å virke uendret på fremforge – GITHUB_TOKEN, GITHUB_SHA, GITHUB_REF, GITHUB_API_URL osv. fylles ut på samme måte | Forgejo Actions-kjøretiden | – |
| Avhengighetsoppdateringer | Versjonsoppdateringer med Renovate for hver påmeldte organisasjon, hver natt, pluss Kjør nå. Finner utdaterte avhengigheter, action-versjoner og basisimager for containere. Repositoryer kan melde seg av | Renovate + egen orkestrering | Avmelding per repo |
Isolasjon under kjøring (hostede CI-runnere)
| Kontroll | Hva den gjør | Verktøy | Kan konfigureres |
|---|---|---|---|
| Sandkasse for hostede runnere | Én commit = én dedikert VM = én kjerne. Plattformen starter en ny, flyktig ECS-VM per commit, registrerer forgejo-runner --ephemeral slik at hver registrering brukes opp av én oppgave, og sletter VM-en når jobbene for commiten er ferdige. To kunder, eller to commits, deler aldri en kjerne – jobber fra den samme commiten kan dele VM-en, så behandle en pipeline som ett tillitsdomene. Hver VM har sitt eget ENI + Security Group (nettverksisolasjon) og ingen IAM-agency knyttet til seg (ingen tilgang til plattformens API innenfra). En reserveopprydder utenfor hovedflyten dreper foreldreløse VM-er der runneren aldri registrerte seg eller aldri ble ferdig. Samme modell som GitHub-hostede og GitLab-hostede runnere | T Cloud Public ECS + ENI per VM + forgejo-runner (act_runner) | VM-flavor (tak for CPU/RAM), tak for samtidighet per tenant |
| Tak for samtidighet per tenant | 2 samtidige jobber per bruker garantert (minst 10, høyst 60), og opptil 60 når det er ledig kapasitet (GitHub-hostet: Free 20, Pro 40, Team 60). Høyere ved forespørsel | Håndheving på plattformnivå | Overstyring per tenant |
| Pott med runner-minutter | seat_cap × 1000 min/måned. Tenanter i prøveperiode har en fast pott på 500 min – se Fakturering. Tenanter med overforbruk slått på fortsetter å kjøre; andre får utsendelsen avvist | Sjekk før utsendelse mot målt forbruk | Overstyring av taket per tenant |
| Utgående proxy | Kundeworkflower når det offentlige internett gjennom runnernes utgående proxy (avviser bare SSRF, tillater CGNAT – samme oppførsel som GitHub-hostet) | Egen proxy (skrevet av fremforge, basert på Hono) | – |
| Veggklokketid per jobb | 60 min per jobb som standard, absolutt tak på 360 min. En separat opprydder sletter foreldreløse VM-er, med en absolutt grense på 6 t 10 min | Opprydder utenfor hovedflyten | timeout-minutes på stegnivå |
Secrets og tilgangskontroll
| Kontroll | Hva den gjør | Verktøy | Kan konfigureres |
|---|---|---|---|
| Secrets for utrulling | Krypterte secrets per miljø. AES-256-GCM ved lagring med en MASTER_ENCRYPTION_KEY som holdes i DEW KMS. Dekrypteres bare inne i runner-VM-en som trenger dem. Nøkkelrotasjon støtter et vindu med to nøkler (gjeldende + forrige) for rotasjon på stedet | Eget (Node crypto) + avgrensning per miljø + DEW KMS | Per miljø / per repo / per organisasjon |
| RBAC + avgrensning per tenant | Forgejos innebygde RBAC + fremforges lag for avgrensning per tenant; alle plattformens API-endepunkter håndhever tenant_id fra JWT-en, ingen datalekkasje mellom tenanter. Organisasjonsadministrasjon → Medlemmer | Forgejo + mellomvare i fremforge-API-et | Granularitet per team |
| OIDC single sign-on | Den foretrukne veien for identitetsleverandører. Koble til Okta, Entra, ADFS, Google Workspace, Authentik, Keycloak, Auth0 – hvilken som helst OpenID Connect-leverandør – for innkommende føderasjon. Domenebekreftelse, brukerklargjøring akkurat i tide (JIT), tilordning gruppe → team. Konfigureres under Organisasjonsadministrasjon → SSO → Autentiseringskilder | Forgejos innebygde OIDC-autentiseringskilde | Konfigurasjon av identitetsleverandør per tenant |
| SAML 2.0 single sign-on | Ikke tilgjengelig ennå. Koble til Entra ID eller ADFS over OIDC i stedet | – | – |
| SCIM 2.0-klargjøring av brukere | Push brukere fra identitetsleverandøren din inn i fremforge-organisasjonen via SCIM 2.0. Autentisering med bearer-token per tenant, rotasjonsvindu med to tokener, idempotent CRUD på Forgejo-brukere. Virker med alle SCIM-kompatible identitetsleverandører | Egne API-endepunkter under /<slug>/scim/v2/* | SCIM-token per tenant |
| SSH-CA | SSH-tilgang til Git bruker et sertifikat signert av en CA, ikke rå nøkkelfingeravtrykk. Sertifikat per bruker med TTL; kan tilbakekalles i organisasjonsadministrasjonen | OpenSSH-CA + sertifikatutstedelse administrert av fremforge | TTL + tilbakekalling per bruker |
| Autentiseringspolicy | En samling håndhevingsbrytere per organisasjon: maskinvarebaserte nøkler (bare WebAuthn, ingen TOTP), maksimal levetid for PAT (tak under plattformens standard på 90 dager), signerte commits påkrevd (blokker usignerte pusher), SSH slått av (bare HTTPS), 2FA påkrevd, bare SSO-innlogging (blokker lokalt brukernavn/passord i Forgejo). Speiler GHECs flate for virksomhetspolicyer. Hver bryter skriver en revisjonshendelse ved endring | Patcher vi har på Forgejo + fremforges hooks for håndheving | Policysamling per tenant |
| Tillatelsesliste for e-postdomener | Tillatelsesliste per organisasjon over mønstre for e-postvertsnavn. Når den er slått på, kan medlemmer bare legge til adresser av typen @acme.com som samsvarer med de konfigurerte mønstrene. Stenger veien «utgi commits for å være fra attacker@arbitrary-domain.com» under en kriminalteknisk gjennomgang. Eksisterende e-postadresser fjernes ikke automatisk; OIDC-innlogging er unntatt (identitetsleverandøren bekrefter). Mønstre støtter eksakte former og *.subdomain | Egne regler + avskjæring i Bunny-kanten på /user/settings/account/email | Mønstre per tenant + håndhevingsflagg |
| Workflow-secrets | Actions-secrets på organisasjons- og reponivå settes inn i hver CI-jobb som miljøvariabler. Forgejo lagrer dem kryptert; fremforge-administrasjonen formidler CRUD med revisjonshendelser (verdien lagres aldri i fremforges database eller revisjonslogg). Å overskrive en secret i det samme skjemaet er rotasjonsflyten | Forgejos innebygde secrets + fremforges administrasjonsproxy | Per organisasjon / per repo / per miljø |
| Workflow-OIDC for autentisering mot skyen | Runner-VM-er får en ny OIDC-JWT med aud=fremforge per jobb. Kundens tillitspolicyer i skyen bruker den til å bytte til kortlivede legitimasjoner (ingen langlivede AWS-nøkler, JSON-filer for GCP-tjenestekontoer eller Azure-klient-secrets i workflow-secrets) | Egen OIDC-utsteder signert med fremforges runner-OIDC-nøkkel (rotert hver 180. dag; manuell rotasjon, automatisk rotasjon er ikke levert ennå) | – |
| Autentisering for agenter | Tre mønstre på identitetsleverandørsiden for ikke-menneskelige klienter: (1) Direkte JWT-bearer fra kundens identitetsleverandør – presenter en JWT fra en Entra-arbeidslastidentitet / Okta-tjenestekonto / Google-tjenestekonto direkte som Authorization: Bearer på et hvilket som helst /api/v1/*-endepunkt; (2) RFC 8693-tokenbytte + OBO – POST /_app/api/v1/auth/token-exchange godtar subject_token og valgfritt actor_token; personen er actor i revisjonsloggen og agenten en detalj i raden (fields.agent), uten egen agentidentitet; (3) RFC 6749 client_credentials – POST /_app/api/v1/oauth/token for apper uten identitetsleverandør. Binding av audience per tenant (https://frem.sh/<slug>), påstander om claims per kilde (tid/hd), UNIQUE på databasenivå som hindrer at to tenanter gjør krav på den samme utstederen for direkte bearer | Eget (auth_sources + oauth_clients + tokenbyttekjede som bruker jose) | Tilvalg per kilde; tak for scope per klient |
DevOps-observerbarhet
| Kontroll | Hva den gjør | Verktøy | Kan konfigureres |
|---|---|---|---|
| DORA-dashbord | De fire kanoniske DORA-målene – utrullingsfrekvens, ledetid for endringer, feilrate for endringer, MTTR – beregnet over et rullerende vindu på 30 dager fra utrullingshendelser registrert for tenanten din. Data kommer inn via Forgejos release-webhook pluss en manuell POST /_app/api/v1/dora/deployments for workflower som ikke tagger utgivelser. Synlig under Organisasjonsadministrasjon → DORA | Eget (skrevet av fremforge, mot tenantdatabasen) | Rullerende vindu + manuell innlesing |
| Sikkerhetsoversikt | Sikkerhet › Oversikt: åpne funn per skanner, med lenker til hver fane, og sjekklisten for oppsett | Egen aggregator | – |
| Panel for runner-forbruk | Antall runner-minutter per måned + tabell over varighet per jobb under Organisasjonsadministrasjon → Bygg og utrulling → CI-forbruk. Styrer fakturalinjene via tabellen metering_events | Eget (aggregering av runner_jobs) | – |
AI-holdning
| Kontroll | Hva den gjør | Verktøy | Kan konfigureres |
|---|---|---|---|
| Egen AI – tilgang for agenter | fremforge er AI-agnostisk. Kundens Claude Code / Cursor / Windsurf / Codex CLI / Aider jobber mot den samme Git- og REST-flaten som mennesker (maskinlesbar OpenAPI-spesifikasjon). Sammen med autentisering for agenter (direkte JWT-bearer fra identitetsleverandøren, RFC 8693-tokenbytte + OBO, RFC 6749 client_credentials) autentiserer agenter seg som fullverdige identiteter – ingen lån av menneskers PAT. Ingen AI-produkt som er låst til forgen, ingen agentfunksjoner som krever en bestemt leverandør | Standardkompatibel Git + REST | Kundestyrt |
| AI-integrasjoner (BYOK) | Organisasjonsadministrasjon → AI-integrasjoner: registrer din egen nøkkel hos en AI-leverandør (Anthropic, OpenAI, Mistral og andre). Gir: AI-gjennomgang av PR-er (utkast til gjennomgangskommentarer på diffen), AI-forklaringer i Renovate (endringslogger oppsummert på vanlig språk i PR-er som løfter avhengigheter) og gatewayen /_app/api/v1/orgs/<slug>/ai/complete for LLM-kall fra workflower | Egen gateway (skrevet av fremforge) | Leverandør og nøkkel per organisasjon |
Samsvar og revisjon
| Kontroll | Hva den gjør | Verktøy | Kan konfigureres |
|---|---|---|---|
| Revisjonslogg | Hver operasjon som endrer tilstand (push, rolleendring, opprettelse av secret, overstyring for runner, faktureringsendring) logges med aktør + tidsstempel + før/etter. Oppbevaring i to nivåer: et varmt nivå det kan søkes i (90 / 180 / 365 / 730 dager, kan konfigureres per tenant) + et arkiv med kryptografisk kjede i 3 år i T Cloud Public OBS WORM | Eget, bare tillegg (tabellen audit_events) | Oppbevaringsvindu per tenant |
| Revisjonskjede | Hash-kjedet revisjonslogg + lineær hash-kjede forankret hvert 2. minutt i T Cloud Public OBS WORM. En bekreftelsesjobb sjekker kjedens integritet hver time + full gjennomgang hvert 30. minutt. Kunder kan bekrefte at «ingen hendelse ble slettet eller endret i ettertid» | Eget (skrevet av fremforge, i tråd med BSI C5) | – |
| SIEM-strømming | Sanntidsstrøm av revisjonshendelser til et endepunkt kunden oppgir (Splunk HEC, Sentinel, ELK, OpenSearch, generisk HTTPS-webhook). Relé i EU, ingen data forlater regionen eu-de. Helsetilstanden til endepunktet per tenant er synlig for operatøren og tenantadministratoren | Egen videresender + tabellen siem_endpoints | Endepunktkonfigurasjon per kunde |
| Dataeksport (GDPR-portabilitet) | Eksport av tenantdata som selvbetjening: repoer (som git-bundler), issues, pull requests og utgivelser (NDJSON), pakkeoversikt, skannefunn, tilstanden til pakkepolicyer, signerte attestasjoner, SBOM-er for repositoryer og containerimager, revisjonshendelser (NDJSON), med et DSSE-signert manifest. Lastes ned fra en signert OBS-URL som gjelder i 7 dager. Påkrevd for portabilitet etter GDPR art. 20 og ved avslutning av kundeforholdet | Egen eksportør | Kan startes når som helst |
| Livssykluspolicyer | Automatisering av oppbevaring og sletting per tenant: arkivering av inaktive repoer, oppførsel ved tak for runner-minutter, oppbevaringsvindu for revisjonsloggen, frist ved suspensjon av tenant, SLA for sletting av data ved kontraktsslutt | Eget (tabellen tenant_lifecycle) | Policy per tenant |
| Repospeiling (innkommende migreringer) | Pull-speil av kundens repoer fra GitHub, GitLab, Bitbucket eller en hvilken som helst annen Git-vert inn i fremforge, med legitimasjonsbasert autentisering + periodisk synkronisering. Brukes under trinnvise migreringer; speilet kan fjernes når overgangen er fullført | Forgejos innebygde pull-speil + fremforges administrasjonsproxy | Kilde + intervall per repo |
| Varslingsinnstillinger | Ruting av hendelser for hele organisasjonen: hvilke revisjonshendelser som sender e-post/webhook/SIEM, hvilke roller som varsles ved kritiske funn, kontakter for eskalering av faktureringshendelser | Eget (tabellen notification_preferences) | Ruting per tenant |
| Sårbarhetsrapportering | security.txt publisert, SLA for kvittering fra security@frem.sh innen 24 t, offentlig takkeside, policy om ingen søksmål mot forskning i god tro | – | – |
| SLA for utbedring | SLA-merke per organisasjon ved siden av hvert åpent funn. Standardfrister (Critical 7 d / High 30 d / Medium 90 d / Low ingen) – kan strammes inn per tenant. Forankret i NIST SP 800-40r4 | Eget (skrevet av fremforge) | Innstramming per tenant |
Hva vi bevisst ikke gjør
| Det vi ikke gjør | Hvorfor |
|---|---|
| Ingen Microsoft-avtrykk (ingen GitHub, ingen Azure AD, ingen Office 365, ingen Defender, ingen GHAS CodeQL) | Suverenitet i EU + Schrems II – se trust |
| Ingen USA-hostet Sigstore / Fulcio / Rekor i bekreftelsesveien | Samme grunn. fremforge kjører sin egen Fulcio + TSA på T Cloud Public eu-de med rot-CA-en i DEW KMS (FIPS 140-2 nivå 3 HSM, Tyskland). Ingen offentlig Sigstore, ingen Rekor / transparenslogg – bare TSA-tidsstempling, med vilje |
| Ingen AWS, GCP eller annen avhengighet kontrollert av en amerikansk sky på plattformens kritiske vei | Samme grunn |
| Ingen fonter lastet fra tredjeparts-CDN (Google Fonts osv.) | Selvhostet på www.frem.sh/fonts/ via Bunnys EU-kant |
| Ingen proprietære skannere fra tredjeparter: hver skanner er åpen kildekode eller fremforges egen, og hvert regelsett, hver varseldatabase og hver kilde til skadevaresignaturer bak dem er navngitt, med lisens, i materiallisten | Kundens revisjonsspor krever åpenhet med navngitte verktøy |
| Ingen langlivede legitimasjoner for tjenestekontoer i kundeworkflower | Bare OIDC for autentisering mot skyen; langlivede nøkler er en utfaset vei som må slås på |
Åpenhet om verktøy – full materialliste
Hvis du trenger dette til et anbud, en BSI C5-revisjon eller en intern sikkerhetsgjennomgang, finner du den kanoniske listen – med versjoner, hentekilder og plattformkomponentene – på docs.frem.sh/security/bill-of-materials/. Tabellen nedenfor er et utdrag for raskt oppslag.
| Lag | Verktøy | Hvor det brukes | Lisens |
|---|---|---|---|
| Kjerne for kildekontroll | Forgejo v15 | Repohosting, kodegjennomgang, protokollen for Actions-runnere | GPLv3 |
| Runner-binær for CI | forgejo-runner (act_runner) v13.2.0 | Flyktig ECS-VM per jobb | MIT |
| Skanning etter secrets | Gitleaks v8 | Hook før mottak | MIT |
| SAST | OpenGrep v1.21 | Analyse ved PR | LGPLv2.1 |
| CVE-skanning av containere | Trivy | Kundens CI + bakt inn i runner-imaget | Apache 2.0 |
| Avhengighetsskanning | osv-scanner | Analyse ved PR | Apache 2.0 |
| Generering av SBOM | Syft | Workflow ved utgivelsestagg | Apache 2.0 |
| Signering og bekreftelse av imager | cosign | Sjekk ved pull, og den informative pull request-sjekken fremforge/cosign-verify | Apache 2.0 |
| Nøkkelfri kodesignering – CA | Fulcio v1.8.5 (Helm-chart 2.9.0) | Selvhostet på T Cloud Public eu-de på sign.frem.sh | Apache 2.0 |
| Nøkkelfri kodesignering – TSA | Sigstore TSA (tidsstempelautoritet) | Selvhostet på T Cloud Public eu-de på tsa.frem.sh | Apache 2.0 |
| gitsign hos kunden | gitsign | Kundens Git-klient; commit-signering bundet til OIDC | Apache 2.0 |
| Avhengighetsoppdatering | Renovate | Hostet bot, cron hvert 15. minutt, avmelding per repo | AGPLv3 |
| Imagebygg (uten root) | kaniko | Containerbygg i kundeworkflower | Apache 2.0 |
| Skadevareskanning | ClamAV | Skanning før mottak + LFS-opplasting | GPLv2 |
| Poengsum for beste praksis fra OpenSSF | scorecard | Ukentlig per repo | Apache 2.0 |
| Plattformens CDN + WAF | Bunny CDN | Kant i EU, ingen Cloudflare/Fastly | (Leverandør – EU-basert, ingen amerikansk underdatabehandler) |
| Skyplattform | T Cloud Public (Deutsche Telekom) | Beregning, lagring, nettverk, database | (Leverandør – utelukkende regionen eu-de) |
| E-post (transaksjonell) | Lettermint (NL) | Autentiserings-e-post, fakturaer, varsler | (Leverandør – EU) |
| Postkasse | mailbox.org | Driftspostkasse | (Leverandør – EU) |
| Betalinger | Mollie (NL) | Fakturering | (Leverandør – EU) |
| Regnskap | Dinero (DK) | Utstedelse av fakturaer | (Leverandør – EU) |
Alle leverandørene på denne listen er kontraktsmessig plassert i EU, uten amerikanske underdatabehandlere i dataveien. Se trust-siden for hele kjeden med databehandleravtale og underdatabehandlere.
Veikart (styrt av etterspørsel)
| Funksjon | Status | Utløser |
|---|---|---|
Egen KMS for MASTER_ENCRYPTION_KEY (DEW-CMK fra kunden i kundens egen T Cloud Public-konto) | Designet | Første kunde forplikter seg |
| SLSA-byggeproveniens (registrering av output-digest under bygging, slik at den signerte erklæringen viser til en faktisk byggekjøring – forutsetningen for å kunne hevde et SLSA-nivå; begge Build L3-kravene er allerede oppfylt) | Avgrenset | Etterspørsel fra kunder |
| MCP-signering + bekreftelse for forsyningskjeden til AI-agenter | Designet | Bransjestandarden ferdigstilles |