Säkerhetsfunktionerna i korthet
Allt som fremforge levererar, i en tabell som är lätt att skumma. Varje rad länkar till den sida som beskriver konfiguration, flödet för åsidosättning och dokumentationen för det underliggande verktyget.
fremforge är avsiktligt transparent med vilka verktyg med öppen källkod som ligger under varje kontroll: kunder som granskas enligt BSI C5, ISO 27001, BaFin eller ENISA-regler behöver spårbarhet ned på verktygsnivå, och vi vill hellre att du kan greppa i vår källkod än att du ska behöva bakåtkompilera en svart låda. Det som skiljer oss åt är integrationen (hooks, RBAC, granskningskedja, data i EU, ingen Microsoft, ingen AWS), inte skannern.
Kontroller vid push av kod
| Kontroll | Vad den gör | Verktyg | Konfigurerbar per tenant |
|---|---|---|---|
| Push-skydd | Skanning efter hemligheter före mottagning; avvisar commits som innehåller inloggningsuppgifter innan de hamnar i git-historiken | Gitleaks v8 (120+ mönster) | Regler för åsidosättning + förbikoppling per mönster |
| Branch-skydd | Regler per branch: obligatoriska granskare, statuskontroller, krav på signerade commits, blockering av force-push | Inbyggt i Forgejo | Ja (per branch) |
| Tvåfaktorsautentisering | TOTP för varje användarkonto; tvingande WebAuthn finns på organisationsnivå (användarna registrerar WebAuthn på säkerhetssidan i Forgejos användarinställningar). Kan göras obligatorisk per organisation | Inbyggt i Forgejo + egna hooks för att tvinga | Ja (tvingande för hela organisationen, frivilligt per användare) |
| Verifiering av MFA via OIDC | Verifiera kryptografiskt att din IdP intygade MFA vid varje inloggning, via OIDC-claimet amr (RFC 8176). Ersätter den äldre kryssrutan “lita på IdP:ns MFA” som operatören intygade: antingen säger token ["pwd","mfa"], eller så är det inte MFA | Egen middleware som kontrollerar claimet | Policy per tenant för obligatoriskt amr |
| SSO break-glass | När din IdP inte är tillgänglig, är felkonfigurerad eller SSO-kopplingen är trasig kan namngivna ägare av organisationen återfå åtkomst via en separat hanterad break-glass-väg för inloggningsuppgifter. Granskningsloggas | Egen (skriven av fremforge) | Namngivna ägare per tenant |
| Nyckellös signering av commits (sigstore / gitsign) | Signering knuten till OIDC: din IdP-identitet (Entra, Okta, Google Workspace, Authentik) signerar commiten via ett Fulcio-certifikat som gäller i 10 minuter. Forgejo visar 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. Avsiktligt ingen Rekor / transparenslogg: bara tidsstämpling förankrad i TSA, så att signaturerna inte hamnar i någon tredje parts logg | Självhostad Fulcio v1.8.5 + TSA i T Cloud Public eu-de, gitsign hos kunden | Organisationens administration → Tillåtna OIDC-utfärdare + striktnivå |
| Signering av commits med SSH-nyckel | Signera commits med samma SSH-nyckel som Forgejo använder vid push. Märket “Verified” visas direkt i webbgränssnittet. Samexisterar med nyckellös signering; organisationens administratör anger striktnivå | OpenSSH + Forgejos allowedSignersFile | Slås på per användare |
| Signering av commits med GPG | Det vanliga flödet med git commit.gpgsign. Ladda upp den publika nyckeln i användarinställningarna, så verifierar Forgejo och visar märket “Verified” | GnuPG + inbyggt i Forgejo | Slås på per användare |
Skanning av kodkvalitet och sårbarheter
De här skannrarna körs centralt på fremforges egna skannrar för varje pull request och på standardbranchen. Det finns ingen arbetsflödesfil att installera i dina repon. Resultaten listas under Säkerhet › Fynd.
| Kontroll | Vad den gör | Verktyg | Konfigurerbar |
|---|---|---|---|
| SAST | Statisk analys för varje PR och på standardbranchen, körs centralt på fremforges egna skannrar: det finns ingen arbetsflödesfil i ditt repo att installera eller underhålla. Hittar injektion, XSS, hårdkodade hemligheter och farliga API:er i C, C++, C#, Go, Java, JavaScript och TypeScript, Kotlin, PHP, Python, Ruby, Rust, Scala, Swift och Bash | OpenGrep med GitLabs sast-rules, 0xdeas C/C++-regler och fremforges egna regler | Blockeringsnivå; dina egna OpenGrep-regler, var och en kontrollerad mot sitt eget exempel innan den körs |
| Skanning efter hemligheter | gitleaks för varje pull request (kontrollen fremforge/secret-scan) och en veckovis genomgång av hela historiken i varje repo; push-skyddet blockerar hemligheter vid push | Gitleaks | Kontrollen för pull requests av eller på |
| IaC-skanning | trivy config letar efter felkonfigurationer (Dockerfile, Compose, Kubernetes, Helm, Terraform med mera) för varje PR, som kontrollen fremforge/iac-scan med en egen flik för fynd, plus din organisations egna Rego-kontroller; blockerar bara på det som en PR lägger till; fynden grupperas efter CIS-benchmark och NIS2-område i efterlevnadsrapporten | Trivy | Läge och tröskel under Säkerhet › Policyer › Skannrar |
| Beroendeskanning (OSV) | Skanning av beroenden efter CVE/GHSA för varje PR, körs centralt på fremforges egna skannrar. Visar åtgärdbara CVE:er med föreslagen uppgradering | osv-scanner | Allvarlighetströskel |
| Nåbarhet | Markerar varje fynd för beroenden och images som nåbart, inte nåbart eller okänt, med belägg (fil och rad, eller den berörda funktionen), och sorterar listor, Rekommendationer och sammandraget efter det. Go: govulncheck på binärerna i dina images. JavaScript och TypeScript: Jelly, på importnivå om inte rådgivningen namnger funktioner. Python, Java och Kotlin: importnivå, även via andra paket, aldrig unreachable. Ingenting döljs eller avfärdas; vad som blockerar en merge är oförändrat om du inte själv väljer det | govulncheck, Jelly, fremforges importläsare | Valfri SLA-multiplikator (1-4) för fynd som inte är nåbara; valfritt “blockera inte pull requests på fynd som inte är nåbara” |
| Känt utnyttjade | Flaggar fynd vars CVE står som utnyttjad i ENISA:s EU Vulnerability Database eller CISA:s KEV-katalog: ett märke och ett filter, sorteras före EPSS, får aldrig förlängd SLA, AutoFix först. Båda listorna uppdateras dagligen | Speglar av ENISA EUVD + CISA KEV | - |
| Säkerhetsrättningar | Ett klick öppnar en pull request som höjer ett sårbart beroende till den lägsta version som åtgärdar alla öppna rådgivningar (ekosystemen på Stödda ekosystem) eller höjer en images FROM-bas; Åtgärda alla per repo. Mergeas aldrig automatiskt. Valfria AI-rättningar för en kort lista SAST-regler använder bara din egen modelleverantör och är avstängda som standard | Hostad Renovate; din egen AI-leverantör för SAST-rättningar | Gränser per repo och per organisation; AI-rättningar avstängda som standard |
| Regelbaserade rättningar | Öppna fix-PR på ett fynd av en hemlighet flyttar inloggningsuppgiften till en miljövariabel (Go, Python, JavaScript, TypeScript); för sex IaC-kontroller sätter den egenskapen till sitt säkra värde. En fast regel, ingen AI: ingenting lämnar fremforge. Syntaxkontrolleras och skannas om först, mergeas aldrig automatiskt | gitleaks och Trivy, skannrarna som tog fram fyndet | Gränser per repo och per organisation |
| Skanning av container-images | fremforges centrala skanner kör Trivy (inget installationssteg): trivy fs och trivy config för varje PR, trivy image för varje image i ditt registry och varje image som hämtas via beroendeproxyn. Fynden listas under Säkerhet › Fynd › Container-images, kopplade till imagen och commiten. En blockeringsåtgärd för images (none, warn, block_pull) gäller fynd på eller över tröskeln för images, high som standard | Trivy | Blockeringsåtgärd, tröskel och ignore-filer |
| Licensskanning | Trivys licensidentifiering för varje PR, körs centralt på fremforges egna skannrar. Klassar varje beroendes licens i en SPDX-policynivå med 7 steg (tillåtande → ömsesidig → begränsad → förbjuden); blockerar merge vid fynd på eller över den konfigurerade tröskeln. Visas under Säkerhet › Fynd › Licenser | Trivy | Blockeringsnivå + SPDX-lista över tillåtna + avfärda per fynd |
| OpenSSF Scorecard | Veckovis poäng för god praxis per repo. Inte ett arbetsflöde per repo: körs varje vecka på isolerad plattformsinfrastruktur med en bot per tenant som bara har läsåtkomst till repona; oförändrade repon hoppas över och bara poängens JSON sparas. Visar brister (branch-skydd, tvingande MFA, fästa beroenden, täckning av kodgranskning) som en kolumn på sidan Repos | scorecard | Veckovis takt + överhoppning när HEAD är oförändrad |
| Skadliga paket | OSV-rådgivningar av typen MAL-* matchas mot SBOM:en för varje repos standardbranch och mot språkpaketen i varje publicerad container-image, efter varje push och dagligen. Alltid kritiska; hämtningar av images med ett öppet fynd nekas | osv-scanner + Trivy | Avfärda med motivering och slutdatum |
| Paketpolicyer | En policy per organisation avgör vilka paket i registryt som får laddas ned: sårbarhetströsklar (allvarlighetsgrad, CVSS, EPSS, rättning finns), SPDX-licenslistor, listor över tillåtna och nekade paket med versionsintervall samt en minsta ålder. Undantag kräver att en andra person godkänner dem. Tvinga nekar med 403, Skugga (standard) registrerar; en fil som innehåller känd skadlig kod nekas i alla lägen. Container-images: endast skuggläge | Syft + osv-scanner | Läge, regler, åsidosättningar per typ, undantag |
| Skanning av uppladdningar efter skadlig kod | ClamAV över Git-LFS-objekt, bilagor på webben och paketuppladdningar. Beroendeproxyn skannar hämtade paket och image-lager med ClamAV när din organisation slår på det (avstängt som standard) | ClamAV med signaturer från SaneSecurity, YARA-Forge Core och Linux Malware Detect | Åsidosättning för signaturer med kända falsklarm |
| Säkerhetsspärr för arbetsflöden | En kontroll före mottagning tolkar varje ändrad YAML-fil för arbetsflöden och avvisar push som inför: docker://-referenser till registryn som inte är tillåtna, farliga injektionsmönster med pull_request_target + script, ofästa uses:-referenser till organisationer som inte speglas | Egna regler (skrivna av fremforge) | Åsidosättning per tenant av listan över tillåtna docker-URI:er |
| Lista över tillåtna IP-adresser | En lista per organisation med tillåtna CIDR-intervall för varje HTTPS-yta: webbadministrationen, fremforges API, repots webbgränssnitt, Forgejos REST-API, Git över HTTPS, LFS och paketregistryn. Git över SSH omfattas inte. Förhandsvisning med enbart granskning och 24 timmars break-glass för ägare | Egna regler (skrivna av fremforge) | CIDR-lista per tenant + reglage för runners |
Ursprung i leveranskedjan
| Kontroll | Vad den gör | Verktyg | Konfigurerbar |
|---|---|---|---|
| SBOM:er | SBOM:er i CycloneDX 1.6 och SPDX 2.3 genereras centralt för varje PR (båda formaten accepteras vid inläsning). När en release publiceras knyts den SBOM som redan finns för den commiten till releasen i stället för att skannas om, så en release-SBOM kräver ingen build och syns direkt. Sökbara under Säkerhet › Komponenter › SBOM:er | Syft | Lagringsperiod + release-referenser |
| Signerad intygan om publicering | Ett DSSE-kuvert med in-toto / SLSA-ursprung som genereras på serversidan av fremforge vid Forgejos webhooks release.published / package: ingen arbetsflödesfil i dina repon. fremforge hashar varje tillgång och signerar med en Ed25519-nyckel som plattformen håller (keyid fremforge-slsa-builder-v1, builder https://frem.sh/runner-controller/v1), uppladdad bredvid tillgången som <asset>.intoto.jsonl, plus en andra nyckellös signatur mot fremforges självhostade Fulcio + RFC3161-TSA som <asset>.sigstore.json. Ingen publik Sigstore, ingen Rekor, ingen transparenslogg. Verifiera lokalt med den publicerade förtroenderoten, se SLSA-ursprung. Beskrivs avsiktligt inte som en SLSA-nivå: den intygar vad som PUBLICERADES, inte hur det byggdes; härledningen och vad som saknas finns i SLSA-ursprung | Egen signerare på serversidan (Nodes stdlib crypto, Ed25519 DSSE) + självhostad Sigstore | — |
| Signering och verifiering av images med cosign | Den centrala pull request-kontrollen fremforge/cosign-verify verifierar signaturerna för images som är fästa med digest, antingen från din organisations egna arbetsflöden via fremforges Sigstore eller från den publika Sigstore, och säger till när den inte kunde kontrollera. Den är informativ. Signaturpolicyn för images kan också kräva signerade images vid hämtning, med dina betrodda identiteter. Kundens CI signerar med sin egen OIDC-identitet: inga långlivade signeringsnycklar | cosign + självhostad Fulcio | Signaturpolicy (skugga eller tvinga) |
| Fästa arbetsflöden | En daglig skanning listar varje uses: i .forgejo/workflows/, .gitea/workflows/ och .github/workflows/ som pekar på en tagg eller branch i stället för en commit-SHA med 40 tecken, och varje docker://-steg vars image refereras med tagg i stället för digest; ett klick öppnar en pull request som fäster actions | Egen (skriven av fremforge) | — |
| Spegel för actions | uses: actions/checkout@v4 löses upp till frem.sh/actions/checkout: Forgejos inbyggda pull-spegel av upstream med synk var 8:e timme. Ingen hämtning från github.com vid build på kundens kritiska väg. Speglade organisationer omfattar actions, docker, pnpm, aws-actions, azure, google-github-actions, peter-evans, softprops, sonarsource, step-security, dorny | Forgejos inbyggda pull-spegel (upplösning av actions enbart i EU) | (Hanteras av operatören; transparent för kunderna) |
| Kompatibilitet med Marketplace | De 20 mest använda actions från GitHub Marketplace är verifierade att fungera oförändrade på fremforge: GITHUB_TOKEN, GITHUB_SHA, GITHUB_REF, GITHUB_API_URL med flera fylls i på identiskt sätt | Forgejo Actions-körtid | — |
| Beroendeuppdateringar | Versionsuppdateringar med Renovate för varje anmäld organisation, varje natt, plus Kör nu. Hittar inaktuella beroenden, versioner av actions och basimages för containrar. Repon kan välja bort det | Renovate + egen orkestrering | Bortval per repo |
Isolering vid körning (hostade CI-runners)
| Kontroll | Vad den gör | Verktyg | Konfigurerbar |
|---|---|---|---|
| Sandlåda för hostade runners | En commit = en dedikerad VM = en kärna. Plattformen startar en ny, kortlivad ECS-VM per commit, registrerar forgejo-runner --ephemeral så att varje registrering förbrukas av en uppgift, och förstör sedan VM:en när commitens jobb är klara. Två kunder, och två commits, delar aldrig kärna; jobb från samma commit kan dela VM, så behandla en pipeline som en enda förtroendedomän. Varje VM har eget ENI + Security Group (nätverksisolering) och ingen IAM-agency kopplad (ingen åtkomst till plattformens API:er inifrån). En reaper utanför det ordinarie flödet dödar föräldralösa VM:ar vars runner aldrig registrerades eller aldrig blev klar. Samma modell som GitHubs och GitLabs hostade runners | T Cloud Public ECS + ENI per VM + forgejo-runner (act_runner) | VM-flavor (tak för CPU/RAM), tak för samtidighet per tenant |
| Tak för samtidiga jobb per tenant | 2 samtidiga jobb per användare garanterat (minst 10, högst 60), och upp till 60 när kapaciteten är ledig (GitHubs hostade runners: Free 20, Pro 40, Team 60). Högre på begäran | Upprätthålls på plattformsnivå | Åsidosättning per tenant |
| Pool med runner-minuter | seat_cap × 1000 min/month. Testtenants har en fast pool på 500 minuter, se Fakturering. Tenants med överförbrukning påslagen fortsätter att köra; andra får inga fler jobb utskickade | Kontroll före utskick mot uppmätt förbrukning | Åsidosättning av taket per tenant |
| Egress-proxy | Kunders arbetsflöden når det publika internet via runnerns egress-proxy (nekar bara SSRF, tillåter CGNAT: samma beteende som GitHubs hostade runners) | Egen proxy (skriven av fremforge, byggd på Hono) | — |
| Väggklocktid per jobb | 60 minuter per jobb som standard, hårt tak på 360 minuter. En separat städare tar bort övergivna VM:ar, med en absolut gräns på 6 h 10 min | Städare utanför det ordinarie flödet | timeout-minutes på stegnivå |
Hemligheter och åtkomstkontroll
| Kontroll | Vad den gör | Verktyg | Konfigurerbar |
|---|---|---|---|
| Hemligheter för deploy | Krypterade hemligheter per miljö. AES-256-GCM i vila med en MASTER_ENCRYPTION_KEY som förvaras i DEW KMS. Dekrypteras bara inne i den runner-VM som behöver dem. Nyckelrotation stöder ett fönster med två nycklar (aktuell + föregående) för rotation på plats | Egen (Nodes crypto) + avgränsning per miljö + DEW KMS | Per miljö / per repo / per organisation |
| RBAC + avgränsning per tenant | Forgejos inbyggda RBAC + fremforges lager för avgränsning per tenant; alla plattformens API-endpoints upprätthåller tenant_id från JWT:n, inga dataläckor mellan tenants. Organisationens administration → Medlemmar | Forgejo + middleware i fremforges api | Granularitet per team |
| OIDC-baserad single sign-on | Den föredragna IdP-vägen. Anslut Okta, Entra, ADFS, Google Workspace, Authentik, Keycloak, Auth0 (vilken OpenID Connect-leverantör som helst) för inkommande federation. Domänverifiering, användare som skapas just-in-time, mappning grupp → team. Konfigureras under Organisationens administration → SSO → Autentiseringskällor | Forgejos inbyggda OIDC-autentiseringskälla | IdP-konfiguration per tenant |
| Single sign-on med SAML 2.0 | Finns inte ännu. Anslut Entra ID eller ADFS via OIDC i stället | — | — |
| Användarprovisionering med SCIM 2.0 | Skicka användare från din IdP till din fremforge-organisation via SCIM 2.0. Autentisering med bearer-token per tenant, rotationsfönster med två token, idempotent CRUD på Forgejo-användare. Fungerar med alla IdP:er som följer SCIM | Egna api-endpoints under /<slug>/scim/v2/* | SCIM-token per tenant |
| SSH-CA | SSH-åtkomst till git använder ett certifikat signerat av en CA, inte råa nyckelfingeravtryck. Certifikat per användare med TTL; kan återkallas i organisationens administrationsgränssnitt | OpenSSH-CA + certifikatutfärdande som hanteras av fremforge | TTL + återkallande per användare |
| Autentiseringspolicy | En uppsättning reglage per organisation för tvingande regler: hårdvarubaserade nycklar (bara WebAuthn, ingen TOTP), maximal livslängd för PAT (tak under plattformens standard på 90 dagar), krav på signerade commits (blockerar osignerade push), SSH avstängt (bara HTTPS), krav på 2FA, inloggning endast via SSO (blockerar lokalt Forgejo-användarnamn/lösenord). Motsvarar GHEC:s policyer för företag. Varje reglage skriver en granskningshändelse när det ändras | Patchar som bärs i Forgejo + fremforges hooks för att tvinga | Policyuppsättning per tenant |
| Lista över tillåtna e-postdomäner | Lista per organisation med tillåtna mönster för e-postdomäner. När den är påslagen kan medlemmar bara lägga till adresser av typen @acme.com som matchar de konfigurerade mönstren. Stänger vägen “ta åt sig commits som attacker@arbitrary-domain.com” vid en forensisk granskning. Befintliga adresser tas inte bort automatiskt; OIDC-inloggning är undantagen (IdP:n intygar). Mönstren stöder exakta namn och formen *.subdomain | Egna regler + avlyssning i Bunnys edge på /user/settings/account/email | Mönster per tenant + flagga för att tvinga |
| Hemligheter för arbetsflöden | Actions-hemligheter på organisations- och reponivå som injiceras i varje CI-jobb som miljövariabler. Forgejo lagrar dem krypterade i vila; fremforges administration skickar vidare CRUD med granskningshändelser (värdet sparas aldrig i fremforges databas eller granskningslogg). Att skriva över en hemlighet i samma formulär är rotationsflödet | Forgejos inbyggda hemligheter + fremforges administrationsproxy | Per organisation / per repo / per miljö |
| OIDC i arbetsflöden för autentisering mot molnet | Runner-VM:ar får en ny OIDC-JWT med aud=fremforge per jobb. Kunders förtroendepolicyer i molnet utgår från den för att byta till kortlivade inloggningsuppgifter (inga långlivade AWS-nycklar, JSON-filer för GCP-tjänstekonton eller klienthemligheter för Azure bland arbetsflödets hemligheter) | Egen OIDC-utfärdare som signeras med fremforges OIDC-nyckel för runners (roteras var 180:e dag; manuell rotation, automatisk rotation har inte levererats ännu) | — |
| Autentisering för agenter | Tre IdP-baserade mönster för anropare som inte är människor: (1) JWT direkt från kundens IdP som bearer: presentera en JWT för en Entra workload identity / ett Okta-tjänstekonto / ett Google-tjänstekonto direkt som Authorization: Bearer mot valfri /api/v1/*-endpoint; (2) tokenbyte enligt RFC 8693 + OBO: POST /_app/api/v1/auth/token-exchange tar emot subject_token och valfri actor_token; personen är actor i granskningen och agenten en detalj i raden (fields.agent), utan någon egen agentidentitet; (3) RFC 6749 client_credentials: POST /_app/api/v1/oauth/token för appar utan IdP. Audience-bindning per tenant (https://frem.sh/<slug>), claim-krav per källa (tid/hd), UNIQUE på databasnivå som hindrar två tenants från att göra anspråk på samma utfärdare för direkt bearer | Egen (auth_sources + oauth_clients + pipeline för tokenbyte med jose) | Frivilligt per källa; tak för scope per klient |
Observerbarhet för DevOps
| Kontroll | Vad den gör | Verktyg | Konfigurerbar |
|---|---|---|---|
| DORA-instrumentpanel | De fyra klassiska DORA-måtten (driftsättningsfrekvens, ledtid för ändringar, andel misslyckade ändringar, MTTR) beräknade över ett rullande fönster på 30 dagar från de driftsättningshändelser som registrerats för din tenant. Händelserna kommer från Forgejos webhook release plus ett manuellt POST /_app/api/v1/dora/deployments för arbetsflöden som inte taggar releaser. Syns under Organisationens administration → DORA | Egen (skriven av fremforge, mot tenantens databas) | Rullande fönster + manuell inläsning |
| Säkerhetsöversikt | Säkerhet › Översikt: öppna fynd per skanner, med länkar till varje flik, och checklistan för att komma igång | Egen aggregering | — |
| Panel för runner-förbrukning | Antal runner-minuter per månad + tabell med varaktighet per jobb under Organisationens administration → CI-användning. Styr fakturaraderna via tabellen metering_events | Egen (aggregering av runner_jobs) | — |
AI-hållning
| Kontroll | Vad den gör | Verktyg | Konfigurerbar |
|---|---|---|---|
| Egen AI: åtkomst för agenter | fremforge är AI-agnostiskt. Kundens Claude Code / Cursor / Windsurf / Codex CLI / Aider arbetar mot samma Git- och REST-yta som människor (maskinläsbar OpenAPI-specifikation). Tillsammans med autentisering för agenter (direkt IdP-JWT som bearer, tokenbyte enligt RFC 8693 + OBO, RFC 6749 client_credentials) autentiserar sig agenter som fullvärdiga principaler: inget lån av människors PAT. Ingen AI-produkt som låser in dig i forgen, inga agentfunktioner som kräver en viss leverantör | Git + REST enligt standarder | Kunden styr |
| AI-integrationer (BYOK) | Organisationens administration → AI-integrationer: registrera din egen nyckel från en AI-leverantör (Anthropic, OpenAI, Mistral med flera). Möjliggör: AI-granskning av PR:er (skriver utkast till granskningskommentarer på diffen), AI-förklaringar i Renovate (sammanfattningar av ändringsloggar på vanlig engelska i PR:er som höjer beroenden) och gatewayen /_app/api/v1/orgs/<slug>/ai/complete för LLM-anrop från arbetsflöden | Egen gateway (skriven av fremforge) | Leverantör + nyckel per organisation |
Efterlevnad och granskning
| Kontroll | Vad den gör | Verktyg | Konfigurerbar |
|---|---|---|---|
| Granskningslogg | Varje operation som ändrar tillstånd (push, rolländring, skapad hemlighet, åsidosättning för runner, ändring i faktureringen) loggas med aktör + tidsstämpel + före/efter. Lagring i två nivåer: en sökbar varm nivå (90 / 180 / 365 / 730 dagar, konfigurerbart per tenant) + ett arkiv med kryptografisk kedja i 3 år i T Cloud Public OBS WORM | Egen, endast tillägg (tabellen audit_events) | Lagringsperiod per tenant |
| Granskningskedja | Hashkedjad granskningslogg + linjär hashkedja som förankras varannan minut i T Cloud Public OBS WORM. Ett verifieringsjobb kontrollerar kedjans integritet varje timme + fullständig genomgång var 30:e minut. Kunder kan verifiera att “ingen händelse har tagits bort eller ändrats i efterhand” | Egen (skriven av fremforge, anpassad till BSI C5) | — |
| SIEM-strömning | Strömning i realtid av granskningshändelser till en endpoint som kunden tillhandahåller (Splunk HEC, Sentinel, ELK, OpenSearch, generisk HTTPS-webhook). Relä i EU, inga data lämnar regionen eu-de. Hälsan för endpointen per tenant syns för operatören och tenantens administratör | Egen vidarebefordrare + tabellen siem_endpoints | Endpoint-konfiguration per kund |
| Dataexport (dataportabilitet enligt GDPR) | Självbetjänad export av tenantens data: repon (som git-bundles), issues, pull requests och releaser (NDJSON), paketinventarie, skanningsfynd, paketpolicyns tillstånd, signerade intyg, SBOM:er för repon och container-images, granskningshändelser (NDJSON), med ett DSSE-signerat manifest. Laddas ned från en signerad OBS-URL som gäller i 7 dagar. Krävs för portabilitet enligt GDPR art. 20 + avslut | Egen exportör | Kan startas när som helst |
| Livscykelpolicyer | Automatisering av lagring och radering per tenant: arkivering av inaktiva repon, beteende vid taket för runner-minuter, granskningsloggens lagringsperiod, frist vid avstängning av tenant, SLA för radering av data vid avtalets slut | Egen (tabellen tenant_lifecycle) | Policy per tenant |
| Spegling av repon (inkommande migreringar) | Pull-spegla kunders repon från GitHub, GitLab, Bitbucket eller valfri annan Git-värd till fremforge med autentisering via inloggningsuppgifter + periodisk synk. Används vid stegvisa migreringar; spegeln kan tas bort när övergången är klar | Forgejos inbyggda pull-spegel + fremforges administrationsproxy | Källa + intervall per repo |
| Aviseringsinställningar | Routning av händelser för hela organisationen: vilka granskningshändelser som skickar e-post/webhook/SIEM, vilka roller som larmas vid kritiska fynd, eskaleringskontakter för faktureringshändelser | Egen (tabellen notification_preferences) | Routning per tenant |
| Rapportering av sårbarheter | security.txt publicerad, SLA på 24 h för kvittens till security@frem.sh, publik tackvägg, policy om att inte processa mot forskning i god tro | — | — |
| SLA för åtgärd | En SLA-markering per organisation bredvid varje öppet fynd. Standardtidsfrister (Critical 7 d / High 30 d / Medium 90 d / Low ingen), kan skärpas per tenant. Förankrad i NIST SP 800-40r4 | Egen (skriven av fremforge) | Skärpning per tenant |
Det här gör vi uttryckligen inte
| Antifunktion | Varför |
|---|---|
| Inget Microsoft-fotavtryck (ingen GitHub, ingen Azure AD, inget Office 365, ingen Defender, ingen GHAS CodeQL) | Suveränitet i EU + Schrems II, se trust |
| Ingen Sigstore / Fulcio / Rekor som hostas i USA i verifieringsvägen | Samma skäl. fremforge kör egen Fulcio + TSA i T Cloud Public eu-de med rot-CA:n i DEW KMS (FIPS 140-2 nivå 3 HSM, Tyskland). Ingen publik Sigstore, ingen Rekor / transparenslogg: bara tidsstämpling via TSA, avsiktligt |
| Inget beroende till AWS, GCP eller något moln som kontrolleras från USA på plattformens kritiska väg | Samma skäl |
| Inga typsnitt som laddas från tredje parts CDN (Google Fonts osv.) | Självhostade på www.frem.sh/fonts/ via Bunnys edge i EU |
| Inga proprietära skannrar från tredje part: varje skanner har öppen källkod eller är fremforges egen, och varje regeluppsättning, rådgivningsdatabas och källa till signaturer för skadlig kod bakom dem namnges, med licens, i materialförteckningen | Kundens granskningsspår kräver transparens ned till namngivna verktyg |
| Inga långlivade inloggningsuppgifter för tjänstekonton i kundernas arbetsflöden | Bara OIDC för autentisering mot molnet; långlivade nycklar är en frivillig, utfasad väg |
Transparens om verktygen: fullständig materialförteckning
Om du behöver detta för en upphandling, en BSI C5-revision eller en intern säkerhetsgranskning finns den kanoniska listan, med versioner, hämtningskällor och plattformskomponenterna, på docs.frem.sh/security/bill-of-materials/. Tabellen nedan är ett urval som snabbreferens.
| Lager | Verktyg | Var det används | Licens |
|---|---|---|---|
| Kärna för versionshantering | Forgejo v15 | Hosting av repon, kodgranskning, runner-protokollet för Actions | GPLv3 |
| Binär för CI-runner | forgejo-runner (act_runner) v13.2.0 | Kortlivad ECS-VM per jobb | MIT |
| Skanning efter hemligheter | Gitleaks v8 | Hook före mottagning | MIT |
| SAST | OpenGrep v1.21 | Analys vid PR | LGPLv2.1 |
| Skanning av containrar efter CVE:er | Trivy | Kundens CI + inbyggd i runner-imagen | Apache 2.0 |
| Beroendeskanning | osv-scanner | Analys vid PR | Apache 2.0 |
| Generering av SBOM | Syft | Arbetsflöde för release-taggar | Apache 2.0 |
| Signering + verifiering av images | cosign | Kontroll vid hämtning, och den informativa pull request-kontrollen fremforge/cosign-verify | Apache 2.0 |
| Nyckellös kodsignering: CA | Fulcio v1.8.5 (Helm-chart 2.9.0) | Självhostad i T Cloud Public eu-de på sign.frem.sh | Apache 2.0 |
| Nyckellös kodsignering: TSA | Sigstore TSA (tidsstämplingstjänst) | Självhostad i T Cloud Public eu-de på tsa.frem.sh | Apache 2.0 |
| gitsign hos kunden | gitsign | Kundens git-klient; commit-signering knuten till OIDC | Apache 2.0 |
| Uppdatering av beroenden | Renovate | Hostad bot, cron var 15:e minut, bortval per repo | AGPLv3 |
| Build av images (rootless) | kaniko | Container-build i kunders arbetsflöden | Apache 2.0 |
| Skanning efter skadlig kod | ClamAV | Skanning före mottagning + LFS-uppladdning | GPLv2 |
| Poäng för god praxis enligt OpenSSF | scorecard | Veckovis per repo | Apache 2.0 |
| Plattformens CDN + WAF | Bunny CDN | Edge i EU, ingen Cloudflare/Fastly | (Leverantör, EU-baserad, inget underbiträde i USA) |
| Molnplattform | T Cloud Public (Deutsche Telekom) | Beräkning, lagring, nätverk, databas | (Leverantör, enbart regionen eu-de) |
| E-post (transaktionell) | Lettermint (NL) | E-post för autentisering, fakturor, larm | (Leverantör, EU) |
| Brevlåda | mailbox.org | Brevlåda för driften | (Leverantör, EU) |
| Betalningar | Mollie (NL) | Fakturering | (Leverantör, EU) |
| Bokföring | Dinero (DK) | Utfärdande av fakturor | (Leverantör, EU) |
Varje leverantör på listan finns enligt avtal i EU, utan underbiträde i USA i dataflödet. Se trust-sidan för hela kedjan av personuppgiftsbiträdesavtal och underbiträden.
Färdplan (styrs av efterfrågan)
| Funktion | Status | Utlösare |
|---|---|---|
Egen KMS för MASTER_ENCRYPTION_KEY (DEW CMK som kunden tillhandahåller i sitt eget T Cloud Public-konto) | Designad | Första kunden förbinder sig |
| SLSA-ursprung för builds (digest för build-resultatet fångas vid build, så att det signerade uttalandet avser en faktisk build-körning: förutsättningen för att göra anspråk på någon SLSA-nivå; båda klausulerna för Build L3 är redan uppfyllda) | Avgränsad | Efterfrågan från kunder |
| MCP-signering + verifierare för AI-agenters leveranskedja | Designad | Branschstandarden färdigställs |