Sikkerhedsfunktioner i overblik
Alt, hvad fremforge leverer, i én tabel, der er let at skimme. Hver række linker til den side, der beskriver konfiguration, tilsidesættelse og dokumentationen for det underliggende værktøj.
fremforge er bevidst åben om de open source-værktøjer, der ligger under hver kontrol: kunder, der revideres efter BSI C5, ISO 27001, BaFin eller ENISA-regulering, har brug for revisionssporet ned på værktøjsniveau, og vi vil hellere have, at du kan søge i vores kildekode, end at du skal reverse-engineere en sort boks. Det, der adskiller os, er integrationen (hooks, RBAC, revisionskæde, data i EU, ingen Microsoft, ingen AWS), ikke scanneren.
Kontroller ved push af kode
| Kontrol | Hvad den gør | Værktøj | Kan konfigureres pr. tenant |
|---|---|---|---|
| Push-beskyttelse | Scanning efter secrets ved pre-receive; afviser commits med legitimationsoplysninger, før de kommer ind i git-historikken | Gitleaks v8 (120+ mønstre) | Tilsidesættelsesregler + omgåelse pr. mønster |
| Branch-beskyttelse | Regler pr. branch: påkrævede reviewere, statustjek, krav om signerede commits, blokering af force-push | Forgejo native | Ja (pr. branch) |
| Tofaktorgodkendelse | TOTP for alle brugerkonti; håndhævelse af WebAuthn kan slås til på organisationsniveau (brugerens egen tilmelding af WebAuthn sker på sikkerhedssiden i Forgejos brugerindstillinger). Kan håndhæves pr. organisation | Forgejo native + egne hooks til håndhævelse | Ja (håndhævelse for hele organisationen, tilvalg pr. bruger) |
| Verifikation af MFA via OIDC | Verificér kryptografisk ved hvert login, at din IdP har bekræftet MFA, via OIDC-claimet amr (RFC 8176). Erstatter det gamle afkrydsningsfelt “trust IdP MFA”, som operatøren attesterede: tokenet siger ["pwd","mfa"], ellers er det ikke MFA | Egen middleware til tjek af claims | Politik for påkrævet amr pr. tenant |
| SSO-nødadgang | Når din IdP er utilgængelig eller fejlkonfigureret, eller SSO-forbindelsen er brudt, kan navngivne ejere af organisationen genvinde adgangen via en separat administreret nødadgang med legitimationsoplysninger. Registreres i revisionsloggen | Eget (skrevet af fremforge) | Navngivne ejere pr. tenant |
| Nøglefri signering af commits (sigstore / gitsign) | OIDC-bundet signering: din IdP-identitet (Entra, Okta, Google Workspace, Authentik) signerer commit’et via et Fulcio-certifikat, der gælder i 10 minutter. Forgejo viser Verified by sigstore: <email> via <IdP>. Rod-CA i T Cloud Public DEW KMS (FIPS 140-2 Level 3 HSM, Tyskland). Fulcio på sign.frem.sh, TSA på tsa.frem.sh. Bevidst ingen Rekor / transparenslog: kun tidsstempling forankret i TSA, så signaturer holdes ude af enhver tredjeparts log | Selvhostet Fulcio v1.8.5 + TSA på T Cloud Public eu-de, gitsign hos kunden | Administration → tilladte OIDC-udstedere + strenghedsniveau |
| Signering af commits: SSH-nøgle | Signér commits med den samme SSH-nøgle, som Forgejo bruger til push. Mærket “Verified” vises direkte i webgrænsefladen. Kan bruges sammen med nøglefri signering; organisationsadministratoren sætter strengheden | OpenSSH + Forgejos allowedSignersFile | Slås til pr. bruger |
| Signering af commits: GPG | Det almindelige forløb med git commit.gpgsign. Upload den offentlige nøgle i brugerindstillingerne; Forgejo verificerer og viser mærket “Verified” | GnuPG + Forgejo native | Slås til pr. bruger |
Kodekvalitet + sårbarhedsscanning
Disse scannere kører centralt på fremforges egne scannere på hver pull request og på standardbranchen. Der er ingen workflow-fil, der skal installeres i dine repositorier. Resultaterne vises under Sikkerhed › Fund.
| Kontrol | Hvad den gør | Værktøj | Kan konfigureres |
|---|---|---|---|
| SAST | Statisk analyse på hver PR og på standardbranchen, kørt centralt på fremforges egne scannere; der er ingen workflow-fil i dit repo, der skal installeres eller vedligeholdes. Finder injection, 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 til C/C++ og fremforges egne regler | Blokerende alvorlighed; dine egne OpenGrep-regler, som hver især tjekkes på deres eget eksempel, før de kører |
| Hemmelighedsscanning | gitleaks på hver pull request (tjekket fremforge/secret-scan) og en ugentlig gennemgang af den fulde historik i hvert repository; push-beskyttelse blokerer secrets ved push | Gitleaks | Tjek på pull requests til eller fra |
| IaC-scanning | Tjek for fejlkonfiguration med trivy config (Dockerfile, Compose, Kubernetes, Helm, Terraform m.fl.) på hver PR, som tjekket fremforge/iac-scan med sin egen fane med fund, plus din organisations egne Rego-tjek; blokerer kun for det, en PR tilføjer; fund grupperet efter CIS-benchmark og NIS2-område i compliance-rapporten | Trivy | Tilstand og grænse under Sikkerhed › Politikker › Scannere |
| Afhængighedsscanning (OSV) | Scanning af afhængigheder for CVE/GHSA på hver PR, kørt centralt på fremforges egne scannere. Viser CVE’er, der kan rettes, med den foreslåede opgradering | osv-scanner | Grænse for alvorlighed |
| Nåbarhed | Markerer hvert fund i afhængigheder og images som nåbar, ikke nåbar eller ukendt, med belæg (fil og linje eller den berørte funktion), og sorterer lister, anbefalinger og sammendraget efter det. Go: govulncheck på binærerne i dine images. JavaScript og TypeScript: Jelly, på importniveau, medmindre advarslen nævner funktioner. Python, Java og Kotlin: importniveau, også gennem andre pakker, aldrig unreachable. Intet skjules eller afvises; det, der blokerer en merge, er uændret, medmindre du vælger det til | govulncheck, Jelly, fremforges importlæsere | Valgfri SLA-multiplikator (1-4) for ikke-nåbare fund; valgfrit “bloker ikke pull requests på ikke-nåbare fund” |
| Kendt udnyttet | Markerer fund, hvis CVE står som udnyttet i ENISA’s EU Vulnerability Database eller CISA’s KEV-katalog: et mærke og et filter, sorteres før EPSS, får aldrig forlænget SLA, AutoFix først. Begge lister opdateres dagligt | Spejle af ENISA EUVD + CISA KEV | - |
| Sikkerhedsrettelser | Ét klik åbner én pull request, der løfter en sårbar afhængighed til den laveste version, der retter alle åbne advarsler (økosystemerne under Understøttede økosystemer), eller løfter et images FROM-base; Ret alle pr. repository. Merges aldrig automatisk. Valgfrie AI-rettelser for en kort liste af SAST-regler bruger kun din egen modeludbyder og er slået fra som standard | Hostet Renovate; din egen AI-udbyder til SAST-rettelser | Grænser pr. repo og pr. organisation; AI-rettelser slået fra som standard |
| Regelbaserede rettelser | Åbn rettelses-PR på et fund af en secret flytter legitimationsoplysningen over i en miljøvariabel (Go, Python, JavaScript, TypeScript); på seks IaC-tjek sætter den egenskaben til sin sikre værdi. En fast regel, ingen AI: intet forlader fremforge. Syntakstjekkes og scannes igen først, merges aldrig automatisk | gitleaks og Trivy, de scannere, der rejste fundet | Grænser pr. repo og pr. organisation |
| Scanning af container-images | fremforges centrale scanner kører Trivy (intet installationstrin): trivy fs og trivy config på hver PR, trivy image på hvert image i dit registry og hvert image hentet gennem afhængighedsproxyen. Fund vises under Sikkerhed › Fund › Container-images, knyttet til image og commit. En blokeringshandling for images (none, warn, block_pull) gælder fund på eller over grænsen for images, som standard high | Trivy | Blokeringshandling, grænse og ignore-filer |
| Licensscanning | Trivys licensgenkendelse på hver PR, kørt centralt på fremforges egne scannere. Klassificerer hver afhængigheds licens i en SPDX-politik med 7 alvorlighedstrin (permissive → reciprocal → restricted → forbidden); blokerer merge ved fund på eller over den konfigurerede grænse. Vises under Sikkerhed › Fund › Licenser | Trivy | Blokerende alvorlighed + SPDX-tilladelsesliste + afvisning pr. fund |
| OpenSSF Scorecard | Ugentlig score for god praksis pr. repo. Ikke et workflow pr. repo: kører ugentligt på isoleret platforminfrastruktur med en bot pr. tenant, der kun har læseadgang til repoerne; uændrede repoer springes over, og kun scorens JSON gemmes. Viser mangler (branch-beskyttelse, håndhævelse af MFA, fastlåste afhængigheder, dækning af code review) som en kolonne på siden med repoer | scorecard | Ugentlig kadence + spring over ved uændret HEAD |
| Ondsindede pakker | OSV-advarsler af typen MAL-* sammenholdt med SBOM’en for hvert repositorys standardbranch og sprogpakkerne i hvert offentliggjort container-image, efter hvert push og dagligt. Altid critical; hentning af images med et åbent fund afvises | osv-scanner + Trivy | Afvis med begrundelse og slutdato |
| Pakkepolitikker | Én politik pr. organisation afgør, hvilke pakker fra registryet der må hentes: grænser for sårbarheder (alvorlighed, CVSS, EPSS, rettelse tilgængelig), SPDX-licenslister, tilladelses- og afvisningslister med versionsintervaller og en minimumsalder. Undtagelser skal godkendes af en anden person. Enforce afviser med 403, Shadow (standard) registrerer; en fil, der indeholder kendt malware, afvises i alle tilstande. Container-images: kun shadow | Syft + osv-scanner | Tilstand, regler, tilsidesættelser pr. type, undtagelser |
| Malwarescanning af uploads | ClamAV over Git-LFS-objekter, vedhæftninger på web og upload af pakker. Afhængighedsproxyen scanner hentede pakker og image-lag med ClamAV, når din organisation slår det til (fra som standard) | ClamAV med signaturer fra SaneSecurity, YARA-Forge Core og Linux Malware Detect | Tilsidesættelse for signaturer med kendte falske positiver |
| Sikkerhedsgate for workflows | Et pre-receive-tjek parser hver ændret workflow-YAML og afviser push, der introducerer: docker://-referencer til registries, der ikke er på tilladelseslisten, farlige mønstre med pull_request_target + script-injection, ufastlåste uses:-referencer til organisationer, der ikke spejles | Egne regler (skrevet af fremforge) | Tilsidesættelse af tilladelseslisten for docker-URI’er pr. tenant |
| IP-tilladelsesliste | Én liste pr. organisation over tilladte CIDR-intervaller for hver HTTPS-flade: webadministration, fremforge-API’et, repositoriernes webgrænseflade, Forgejos REST API, Git over HTTPS, LFS og pakke-registries. Git over SSH er ikke omfattet. Forhåndsvisning, der kun registrerer, og 24 timers nødadgang for ejere | Egne regler (skrevet af fremforge) | CIDR-liste pr. tenant + til/fra for runners |
Proveniens i forsyningskæden
| Kontrol | Hvad den gør | Værktøj | Kan konfigureres |
|---|---|---|---|
| SBOM’er | SBOM’er i CycloneDX 1.6 og SPDX 2.3 genereret centralt på hver PR (begge formater accepteres ved indlæsning). Når en release offentliggøres, bindes den SBOM, der allerede findes for det commit, til releasen i stedet for at scanne igen, så en releases SBOM ikke kræver et build og vises med det samme. Kan forespørges under Sikkerhed › Komponenter › SBOM’er | Syft | Opbevaringsvindue + release-refs |
| Signeret attestation af offentliggørelse | En in-toto / SLSA-proveniens-DSSE-konvolut genereret på serversiden af fremforge ved Forgejos webhooks release.published / package, uden workflow-fil i dine repoer. fremforge hasher hvert asset og signerer med en Ed25519-nøgle, som platformen har (keyid fremforge-slsa-builder-v1, builder https://frem.sh/runner-controller/v1), uploadet ved siden af assettet som <asset>.intoto.jsonl, plus en anden, nøglefri signatur mod fremforges selvhostede Fulcio + RFC3161 TSA som <asset>.sigstore.json. Ingen offentlig Sigstore, ingen Rekor, ingen transparenslog. Verificér lokalt med den offentliggjorte tillidsrod; se SLSA-proveniens. Bevidst ikke beskrevet som et SLSA-niveau: den attesterer, hvad der blev OFFENTLIGGJORT, ikke hvordan det blev bygget; udledningen og det, der mangler, står i SLSA-proveniens | Egen signer på serversiden (Node stdlib crypto, Ed25519 DSSE) + selvhostet Sigstore | — |
| Signering og verifikation af images med cosign | Det centrale pull request-tjek fremforge/cosign-verify verificerer signaturerne på images fastlåst med digest, enten fra din organisations egne workflows gennem fremforges Sigstore eller fra den offentlige Sigstore, og siger til, når det ikke kunne tjekke. Det er informativt. Politikken for image-signaturer kan også kræve signerede images ved hentning, med dine betroede identiteter. Kundens CI signerer med sin egen OIDC-identitet, uden langlivede signeringsnøgler | cosign + selvhostet Fulcio | Signaturpolitik (shadow eller enforce) |
| Fastlåsning af workflows | En daglig scanning lister hver uses: i .forgejo/workflows/, .gitea/workflows/ og .github/workflows/, der peger på et tag eller en branch i stedet for en commit-SHA på 40 tegn, og hvert docker://-trin-image, der refereres med tag i stedet for digest; ét klik åbner en pull request, der fastlåser actions | Eget (skrevet af fremforge) | — |
| Spejl af actions | uses: actions/checkout@v4 slås op som frem.sh/actions/checkout, et native Forgejo pull-spejl af opstrøms med synkronisering hver 8. time. Ingen hentning fra github.com ved build på kundens kritiske vej. Spejlede organisationer omfatter actions, docker, pnpm, aws-actions, azure, google-github-actions, peter-evans, softprops, sonarsource, step-security, dorny | Forgejo native pull-spejl (opslag af actions kun i EU) | (Administreres af operatøren; gennemsigtigt for kunder) |
| Kompatibilitet med Marketplace | De 20 mest brugte GitHub Marketplace-actions er verificeret til at virke uændret på fremforge: GITHUB_TOKEN, GITHUB_SHA, GITHUB_REF, GITHUB_API_URL osv. udfyldes alle på samme måde | Forgejo Actions-runtime | — |
| Afhængighedsopdateringer | Versionsopdateringer med Renovate for hver tilmeldt organisation, hver nat, plus Kør nu. Finder forældede afhængigheder, action-versioner og base-images til containere. Repositorier kan fravælge det | Renovate + egen orkestrering | Fravalg pr. repo |
Isolation ved kørsel (hostede CI-runners)
| Kontrol | Hvad den gør | Værktøj | Kan konfigureres |
|---|---|---|---|
| Sandkasse for hostede runners | Ét commit = én dedikeret VM = én kerne. Platformen starter en ny, kortlivet ECS-VM pr. commit, registrerer forgejo-runner --ephemeral, så hver registrering bruges af én opgave, og destruerer VM’en, når commit’ets jobs er færdige. To kunder, og to commits, deler aldrig en kerne; jobs fra samme commit kan dele VM’en, så behandl en pipeline som ét tillidsdomæne. Hver VM har sit eget ENI + Security Group (netværksisolation) og ingen IAM-agency tilknyttet (ingen adgang til platformens API’er indefra). En reaper uden for selve forløbet fungerer som sidste værn og dræber forældreløse VM’er, hvis runner aldrig registrerede sig eller aldrig blev færdig. Samme model som GitHub-hostede og GitLab-hostede runners | T Cloud Public ECS + ENI pr. VM + forgejo-runner (act_runner) | VM-flavor (loft for CPU/RAM), loft for samtidighed pr. tenant |
| Loft for samtidige jobs pr. tenant | 2 samtidige jobs pr. bruger garanteret (mindst 10, højst 60), og op til 60, når der er ledig kapacitet (GitHub-hostet: Free 20, Pro 40, Team 60). Mere efter aftale | Håndhævelse på platformniveau | Tilsidesættelse pr. tenant |
| Pulje af runner-minutter | seat_cap × 1000 min/month. Tenants i prøveperiode har en fast pulje på 500 min; se Fakturering. Tenants med merforbrug slået til kører videre; andre får afvist udsendelse af jobs | Tjek før udsendelse mod målt forbrug | Tilsidesættelse af loftet pr. tenant |
| Egress-proxy | Kundeworkflows når det offentlige internet gennem runnernes egress-proxy (afviser kun SSRF, tillader CGNAT; svarer til GitHub-hostede runners) | Egen proxy (skrevet af fremforge, baseret på Hono) | — |
| Vægurstid pr. job | 60 min pr. job som standard, hårdt loft på 360 min. En separat oprydder sletter forældreløse VM’er, med en absolut grænse på 6 t 10 min | Oprydder uden for selve forløbet | timeout-minutes på trinniveau |
Secrets + adgangskontrol
| Kontrol | Hvad den gør | Værktøj | Kan konfigureres |
|---|---|---|---|
| Udrulnings-secrets | Krypterede secrets pr. miljø. AES-256-GCM i hvile med en MASTER_ENCRYPTION_KEY, der ligger i DEW KMS. Dekrypteres kun inde i den runner-VM, der har brug for dem. Nøglerotation understøtter et vindue med to nøgler (nuværende + forrige) til rotation på stedet | Eget (Node crypto) + afgrænsning pr. miljø + DEW KMS | Pr. miljø / pr. repo / pr. organisation |
| RBAC + afgrænsning pr. tenant | Forgejos native RBAC + fremforges lag for afgrænsning pr. tenant; alle platformens API-endpoints håndhæver tenant_id fra JWT’en, ingen datalæk på tværs af tenants. Administration → Medlemmer | Forgejo + middleware i fremforges api | Granularitet pr. team |
| Single sign-on med OIDC | Den foretrukne vej til IdP. Forbind Okta, Entra, ADFS, Google Workspace, Authentik, Keycloak, Auth0, enhver OpenID Connect-udbyder, til indgående føderation. Domæneverifikation, oprettelse af brugere just-in-time, mapning af grupper → teams. Konfigureres under Administration → SSO → Autentificeringskilder | Forgejos native OIDC-autentificeringskilde | IdP-konfiguration pr. tenant |
| SAML 2.0 single sign-on | Ikke tilgængelig endnu. Forbind Entra ID eller ADFS over OIDC i stedet | — | — |
| SCIM 2.0-brugeroprettelse | Send brugere fra din IdP ind i din fremforge-organisation via SCIM 2.0. Bearer-token-godkendelse pr. tenant, rotationsvindue med to tokens, idempotent CRUD på Forgejo-brugere. Virker med enhver SCIM-kompatibel IdP | Egne api-endpoints under /<slug>/scim/v2/* | SCIM-token pr. tenant |
| SSH-CA | SSH-adgang til git bruger et CA-signeret certifikat, ikke rå nøglefingeraftryk. Certifikat pr. bruger med TTL; kan tilbagekaldes i organisationsadministrationen | OpenSSH-CA + udstedelse af certifikater administreret af fremforge | TTL + tilbagekaldelse pr. bruger |
| Godkendelsespolitik | Et samlet sæt af håndhævelsesindstillinger pr. organisation: hardwarebaserede nøgler (kun WebAuthn, ingen TOTP), maksimal levetid for PAT (loft under platformens standard på 90 dage), krav om signerede commits (bloker usignerede push), SSH slået fra (kun HTTPS), krav om 2FA, login kun via SSO (bloker lokalt Forgejo-brugernavn og -adgangskode). Svarer til GHEC’s politikflade for enterprise. Hver indstilling registreres i revisionsloggen, når den ændres | Patches, som Forgejo bærer + fremforges håndhævelses-hooks | Politiksæt pr. tenant |
| Tilladelsesliste for e-maildomæner | Tilladelsesliste pr. organisation med mønstre for e-mail-værtsnavne. Når den er slået til, kan medlemmer kun tilføje adresser som @acme.com, der matcher de konfigurerede mønstre. Lukker vejen til at “tilskrive commits til attacker@arbitrary-domain.com” under en retsteknisk gennemgang. Eksisterende e-mails fjernes ikke automatisk; login via OIDC er undtaget (IdP’en attesterer). Mønstre understøtter eksakte værdier + *.subdomain | Egne regler + Bunny-intercept ved kanten på /user/settings/account/email | Mønstre pr. tenant + håndhævelsesflag |
| Workflow-secrets | Actions-secrets på organisations- og repo-niveau sendes ind i hvert CI-job som miljøvariabler. Forgejo gemmer dem krypteret i hvile; fremforges administration formidler CRUD med revisionshændelser (værdien gemmes aldrig i fremforges database eller revisionslog). At overskrive en secret med samme formular er rotationsforløbet | Forgejos native secrets + fremforges administrationsproxy | Pr. organisation / pr. repo / pr. miljø |
| Workflow-OIDC til cloud-godkendelse | Runner-VM’er får en ny OIDC-JWT med aud=fremforge pr. job. Kundernes tillidspolitikker i deres cloud bruger den til at udveksle kortlivede legitimationsoplysninger (ingen langlivede AWS-nøgler, JSON-filer til GCP-servicekonti eller Azure-klient-secrets i workflow-secrets) | Egen OIDC-udsteder signeret med fremforges runner-OIDC-nøgle (roteres hver 180. dag; manuel rotation, automatisk rotation er endnu ikke leveret) | — |
| Godkendelse for agenter | Tre mønstre på IdP-siden for kaldere, der ikke er mennesker: (1) Direkte JWT-bearer fra kundens IdP: præsentér en JWT fra Entra workload identity / Okta-servicekonto / Google-servicekonto direkte som Authorization: Bearer på ethvert /api/v1/*-endpoint; (2) RFC 8693 token exchange + OBO: POST /_app/api/v1/auth/token-exchange accepterer subject_token og eventuelt actor_token; personen er actor i revisionsloggen og agenten en detalje i rækken (fields.agent), uden sin egen agentidentitet; (3) RFC 6749 client_credentials: POST /_app/api/v1/oauth/token til apps uden IdP. Binding af audience pr. tenant (https://frem.sh/<slug>), påstande om claims pr. kilde (tid/hd), UNIQUE på databaseniveau forhindrer to tenants i at gøre krav på samme udsteder til direkte bearer | Eget (auth_sources + oauth_clients + pipeline til token exchange med jose) | Tilvalg pr. kilde; loft over scope pr. klient |
DevOps-observerbarhed
| Kontrol | Hvad den gør | Værktøj | Kan konfigureres |
|---|---|---|---|
| DORA-dashboard | De fire klassiske DORA-målinger, Deployment frequency, Lead time for changes, Change-failure rate, MTTR, beregnet over et rullende vindue på 30 dage ud fra de udrulningshændelser, der er registreret for din tenant. Data kommer ind via Forgejos release-webhook plus et manuelt POST /_app/api/v1/dora/deployments til workflows, der ikke tagger releases. Vises under Administration → DORA | Eget (skrevet af fremforge, mod tenantens database) | Rullende vindue + manuel indlæsning |
| Sikkerhedsoverblik | Sikkerhed › Overblik: åbne fund pr. scanner med links til hver fane og tjeklisten til opsætning | Egen aggregering | — |
| Panel for runner-forbrug | Antal runner-minutter pr. måned + tabel med varighed pr. job under Administration → Byg og udrul → CI-forbrug. Driver fakturalinjerne via tabellen metering_events | Eget (aggregering af runner_jobs) | — |
AI-holdning
| Kontrol | Hvad den gør | Værktøj | Kan konfigureres |
|---|---|---|---|
| Egen AI: adgang for agenter | fremforge er AI-agnostisk. Kundens Claude Code / Cursor / Windsurf / Codex CLI / Aider arbejder mod den samme Git- og REST-flade som mennesker (maskinlæsbar OpenAPI-specifikation). Sammen med godkendelse for agenter (direkte IdP-JWT-bearer, RFC 8693 token exchange + OBO, RFC 6749 client_credentials) godkendes agenter som fuldgyldige principals, uden at låne et menneskes PAT. Intet AI-produkt låst til forgen, ingen agentfunktioner, der kræver en bestemt leverandør | Standardkompatibel Git + REST | Styres af kunden |
| AI-integrationer (BYOK) | Administration → AI-integrationer: registrér din egen nøgle til en AI-leverandør (Anthropic, OpenAI, Mistral m.fl.). Slår til: AI-review af PR’er (udkast til review-kommentarer på diffen), Renovate-forklaringer med AI (resuméer af changelogs i almindeligt sprog på PR’er, der løfter afhængigheder) og gatewayen /_app/api/v1/orgs/<slug>/ai/complete til LLM-kald fra workflows | Egen gateway (skrevet af fremforge) | Leverandør + nøgle pr. organisation |
Compliance + revision
| Kontrol | Hvad den gør | Værktøj | Kan konfigureres |
|---|---|---|---|
| Revisionslog | Hver tilstandsændrende handling (push, rolleændring, oprettelse af secret, tilsidesættelse for runner, ændring af fakturering) logges med aktør + tidsstempel + før/efter. Opbevaring i to lag: et varmt lag, der kan forespørges (90 / 180 / 365 / 730 dage, kan konfigureres pr. tenant) + et arkiv med kryptografisk kæde i 3 år i T Cloud Public OBS WORM | Eget, kun tilføjelse (tabellen audit_events) | Opbevaringsvindue pr. tenant |
| Revisionskæde | Hash-kædet revisionslog + lineær hashkæde forankret hvert 2. minut i T Cloud Public OBS WORM. Et verifikationscron tjekker kædens integritet hver time + fuld gennemgang hvert 30. minut. Kunder kan verificere, at “ingen hændelse er slettet eller ændret bagefter” | Eget (skrevet af fremforge, tilpasset BSI C5) | — |
| SIEM-streaming | Strøm i realtid af revisionshændelser til et endpoint, kunden stiller til rådighed (Splunk HEC, Sentinel, ELK, OpenSearch, generisk HTTPS-webhook). Relæ i EU, ingen data forlader regionen eu-de. Endpointets helbred pr. tenant er synligt for operatøren + tenantens administrator | Egen videresender + tabellen siem_endpoints | Endpoint-konfiguration pr. kunde |
| Dataeksport (GDPR-dataportabilitet) | Selvbetjent eksport af tenantens data: repoer (som git-bundles), issues, pull requests og releases (NDJSON), pakkeoversigt, scanningsfund, tilstand for pakkepolitikker, signerede attestationer, SBOM’er for repositorier og container-images, revisionshændelser (NDJSON), med et DSSE-signeret manifest. Hentes fra en signeret OBS-URL, der gælder i 7 dage. Påkrævet for dataportabilitet efter GDPR art. 20 + offboarding | Egen eksportør | Kan startes når som helst |
| Livscykluspolitikker | Automatisering af opbevaring + sletning pr. tenant: arkivering af forældede repoer, adfærd ved loftet for runner-minutter, opbevaringsvindue for revisionsloggen, frist ved suspension af tenant, SLA for sletning af data ved kontraktens ophør | Eget (tabellen tenant_lifecycle) | Politik pr. tenant |
| Spejling af repoer (indgående migreringer) | Pull-spejl kundens repoer fra GitHub, GitLab, Bitbucket eller en anden Git-vært ind i fremforge med godkendelse via legitimationsoplysninger + periodisk synkronisering. Bruges under migreringer i faser; spejlet kan fjernes, når overgangen er gennemført | Forgejo native pull-spejl + fremforges administrationsproxy | Kilde + interval pr. repo |
| Notifikationsindstillinger | Routing af hændelser for hele organisationen: hvilke revisionshændelser der sendes som mail/webhook/SIEM, hvilke roller der tilkaldes ved Critical-fund, kontakter til eskalering af faktureringshændelser | Eget (tabellen notification_preferences) | Routing pr. tenant |
| Rapportering af sårbarheder | security.txt offentliggjort, SLA på 24 t for kvittering på security@frem.sh, offentlig takkeside, politik om ingen retssager mod forskning i god tro | — | — |
| Rettefrist (SLA) | SLA-mærke pr. organisation ved siden af hvert åbent fund. Standardfrister (Critical 7 d / High 30 d / Medium 90 d / Low ingen), kan strammes pr. tenant. Forankret i NIST SP 800-40r4 | Eget (skrevet af fremforge) | Stramning pr. tenant |
Hvad vi bevidst ikke gør
| Det gør vi ikke | Hvorfor |
|---|---|
| Intet Microsoft-fodaftryk (ingen GitHub, ingen Azure AD, ingen Office 365, ingen Defender, ingen GHAS CodeQL) | Suverænitet i EU + Schrems II; se trust |
| Ingen amerikansk hostet Sigstore / Fulcio / Rekor i verifikationsvejen | Samme grund. fremforge kører sin egen Fulcio + TSA på T Cloud Public eu-de med rod-CA’en i DEW KMS (FIPS 140-2 Level 3 HSM, Tyskland). Ingen offentlig Sigstore, ingen Rekor / transparenslog: kun TSA-tidsstempling, bevidst |
| Ingen afhængighed af AWS, GCP eller nogen cloud kontrolleret fra USA på platformens kritiske vej | Samme grund |
| Ingen skrifttyper indlæst fra tredjeparts-CDN (Google Fonts osv.) | Selvhostet på www.frem.sh/fonts/ via Bunnys EU-kant |
| Ingen proprietære tredjepartsscannere: hver scanner er open source eller fremforges egen, og hvert regelsæt, hver advarselsdatabase og hver kilde til malwaresignaturer bag dem er navngivet med sin licens i styklisten | Kundens revisionsspor kræver åbenhed med navngivne værktøjer |
| Ingen langlivede legitimationsoplysninger til servicekonti i kundeworkflows | Kun OIDC til cloud-godkendelse; langlivede nøgler er en forældet vej, der skal vælges til |
Åbenhed om værktøjer: den fulde stykliste
Har du brug for dette til et udbud, en BSI C5-revision eller en intern sikkerhedsgennemgang, ligger den autoritative liste, med versioner, kilder og platformskomponenterne, på docs.frem.sh/security/bill-of-materials/. Tabellen nedenfor er et udsnit til hurtigt opslag.
| Lag | Værktøj | Hvor det bruges | Licens |
|---|---|---|---|
| Kerne for kildekontrol | Forgejo v15 | Hosting af repoer, code review, protokol for Actions-runners | GPLv3 |
| Binær til CI-runner | forgejo-runner (act_runner) v13.2.0 | Kortlivet ECS-VM pr. job | MIT |
| Hemmelighedsscanning | Gitleaks v8 | Pre-receive-hook | MIT |
| SAST | OpenGrep v1.21 | Analyse ved PR | LGPLv2.1 |
| CVE-scanning af containere | Trivy | Kundens CI + bagt ind i runner-imaget | Apache 2.0 |
| Afhængighedsscanning | osv-scanner | Analyse ved PR | Apache 2.0 |
| Generering af SBOM | Syft | Workflow ved release-tag | Apache 2.0 |
| Signering + verifikation af images | cosign | Tjek ved hentning og det informative pull request-tjek fremforge/cosign-verify | Apache 2.0 |
| Nøglefri 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øglefri kodesignering: TSA | Sigstore TSA (tidsstempelmyndighed) | Selvhostet på T Cloud Public eu-de på tsa.frem.sh | Apache 2.0 |
| gitsign hos kunden | gitsign | Kundens git-klient; OIDC-bundet signering af commits | Apache 2.0 |
| Opdatering af afhængigheder | Renovate | Hostet bot, cron hvert 15. minut, fravalg pr. repo | AGPLv3 |
| Image-build (rootless) | kaniko | Container-build i kundeworkflows | Apache 2.0 |
| Malwarescanning | ClamAV | Scanning ved pre-receive + LFS-upload | GPLv2 |
| OpenSSF-score for god praksis | scorecard | Ugentligt pr. repo | Apache 2.0 |
| Platformens CDN + WAF | Bunny CDN | Kant i EU, ingen Cloudflare/Fastly | (Leverandør i EU, ingen amerikansk underdatabehandler) |
| Cloudplatform | T Cloud Public (Deutsche Telekom) | Beregning, lager, netværk, database | (Leverandør, udelukkende regionen eu-de) |
| E-mail (transaktionel) | Lettermint (NL) | Godkendelsesmails, fakturaer, alarmer | (Leverandør i EU) |
| Postkasse | mailbox.org | Driftspostkasse | (Leverandør i EU) |
| Betalinger | Mollie (NL) | Fakturering | (Leverandør i EU) |
| Bogføring | Dinero (DK) | Udstedelse af fakturaer | (Leverandør i EU) |
Hver leverandør på denne liste er kontraktligt forpligtet til at have data i EU uden amerikansk underdatabehandler i datavejen. Se trust-siden for den fulde databehandleraftale og kæden af underdatabehandlere.
Køreplan (styret af efterspørgsel)
| Funktion | Status | Udløser |
|---|---|---|
Egen KMS til MASTER_ENCRYPTION_KEY (kundeleveret DEW CMK i kundens egen T Cloud Public-konto) | Designet | Første kunde forpligter sig |
| SLSA-build-proveniens (opsamling af output-digest under build, så den signerede erklæring henviser til en faktisk build-kørsel; forudsætningen for at kunne påstå et SLSA-niveau; begge Build L3-krav er allerede opfyldt) | Afgrænset | Efterspørgsel fra kunder |
| MCP-signering + verifikation for AI-agenters forsyningskæde | Designet | Branchestandarden bliver færdig |