Revisjonslogg
Revisjonsloggen fanger opp hver administrativ handling mot organisasjonen din: hvem gjorde hva, når, fra hvilken IP og mot hvilken ressurs. Oppbevaringen har to nivåer: et søkbart varmt nivå med full hendelsesnyttelast (actor, action, fields_json) i 90 / 180 / 365 / 730 dager – som standard 90 (standardplan) eller 365 (enterprise-planer), og konfigurerbart per kunde under Authentication policy → Audit log retention; og et kryptografisk kjedearkiv i 3 år i T Cloud Public OBS WORM som tar vare på ankerobjektene i hashkjeden etter at nyttelasten i det varme nivået er sladdet. Samsvarseksporter dekker det søkbare vinduet.
For den kryptografiske sporbarhetskjeden (ankerkjede, Merkle-forpliktelser lagret i OBS), se Integriteten til revisjonskjeden.
Hva som registreres
| Hendelsesklasse | Eksempler |
|---|---|
| Identitet | Innlogging, ny SSO-autentisering, nullstilling av MFA, SCIM-provisjonering, rolleendring |
| Repository | Repository opprettet, overført, arkivert, slettet; branchbeskyttelse endret |
| Secrets | Secret opprettet, rotert, slettet (bare navnet, aldri verdien) |
| Webhooker | Mål lagt til, rotert, fjernet; levering spilt av på nytt |
| Policy | Regel for push-beskyttelse lagt til eller overstyring brukt; overstyring av skadevareskanning; avvisning av SAST-funn |
| Fakturering | Planendring, oppdatering av betalingsmetode, endring av tak |
| Dataeksport | Eksport satt i kø, lastet ned, utløpt |
Det som bevisst mangler: vanlige lesinger (klone, vise, åpne fil). Revisjonsloggen er en logg over administrative handlinger, ikke en tilgangslogg. Unntaket er revisorer med lesetilgang, hvis lesinger av innstillingene dine registreres (se Revisoraktivitet). Tilgang til pakke- og containerregisteret (hver nedlasting, opplasting og sletting, med aktør og klient-IP) står i den separate tilgangsloggen for registeret, som du kan lese gjennom API-et, videresende til SIEM-en din og få med i dataeksporten. Git clone og fetch logges ikke per forespørsel ennå.
Pakke- og utgivelseshendelser
Publisering, tagging, sletting og avvisning av interne artefakter står i revisjonsloggen, hashkjedet som alle andre hendelser og i SIEM-strømmen din. To visninger skriver dem:
- Versjonsvisningen, fra selve registeret: en versjon dukket opp eller forsvant.
- Forespørselsvisningen, fra opplastingsproxyen foran hver skriving til registeret: én hendelse per godtatt eller avvist skriving, med jobben bak et jobbtoken og, for tagger, hva taggen pekte på før.
| Handling | Når |
|---|---|
package.published | En pakkeversjon dukket opp (den første filen kom inn). |
package.deleted | En pakkeversjon og filene dens er borte. |
package.upload.accepted | En skriving til registeret lyktes: en fil, en npm publish, en ny fil i en eksisterende versjon, et containermanifest pushet med digest. |
package.upload.refused | fremforge avviste en skriving: skadevare, skanneren utilgjengelig, for stor til å skannes, en sperre for containerlag. |
package.delete.accepted | En sletting lyktes (en fil, en versjon, et containermanifest med digest). |
package.delete.refused | En sletting ble avvist (bortsett fra en registerrobots, se nedenfor). |
package.tag.created | En containertag eller npm dist-tag som ikke fantes, peker nå på en digest. |
package.tag.moved | En containertag peker nå på en annen digest. previous_digest er den den pekte på før. |
package.tag.set | En tag ble skrevet og fremforge kunne ikke se hva den pekte på før, eller den pekte på samme digest (unchanged: true). npm dist-tags er alltid set. |
package.tag.deleted | En tag ble slettet; digest er det den pekte på. |
package.immutable.refused | En overskriving av en publisert versjon ble avvist (uforanderlige utgivelser); begge sha256-verdiene. |
registry_robot.delete_refused | En registerrobot prøvde å slette; roboter publiserer, men sletter aldri. |
package.files.recorded, package.files.removed | Filene i en versjon med sha256 (pakkepolicyer, organisasjoner). |
forgejo.release.*, forgejo.ref.create, forgejo.ref.delete | En utgivelse publisert, redigert eller slettet (med id, mål, flagg for utkast og forhåndsutgivelse og ressurser); en git-tag eller branch opprettet (med commiten) eller slettet. |
Hver pakkehendelse har:
| Felt | Betydning |
|---|---|
org, package_type, package_name, package_version, file | Hva som ble skrevet. En forespørsel navngir det stien navngir; versjonsvisningen navngir versjonen. |
digest | sha256:<hex>: digesten til et containermanifest, eller sha256 av en rå opplastings-body (filens egen sha256 for alle typer unntatt npm og Cargo, der opplastings-bodyen pakker inn filen). |
actor_kind | human, robot (en registerrobot), job (et jobbtoken fra Forgejo Actions), bot (en fremforge-systembot), system eller anonymous. |
actor_login, actor_id | Hvem registeret autentiserte. |
job_repo, job_run_id, job_run_number, job_id | For et jobbtoken: repositoryet og kjøringen (/<owner>/<repo>/actions/runs/<job_run_number>). |
decision, reason | Ved en avvisning, eller en skriving som en sperre i observasjonsmodus slapp gjennom. |
access_event_id | Den tilsvarende raden i tilgangsloggen for registeret, som også har klient-IP-en. |
Hendelser fra forespørselsvisningen finnes fra 2026-10-08. Forfremmelse mellom repositoryer er ikke et registerbegrep i fremforge, så det finnes ingen forfremmelseshendelse.
Pakketilgang
Tilgang per pakke og beskyttede navn skriver:
| Handling | Når |
|---|---|
package_access.settings.updated | Organisasjonens standard endret seg (default_mode fra og til). |
package_access.package.updated | En pakkes tilgangsinnstilling ble opprettet eller endret (mode, inherit_repo, changed). |
package_access.package.removed | En pakkes innstilling og tildelinger ble fjernet (grants_removed). |
package_access.grant.set | En tildeling til et team eller Actions ble lagt til eller endret (grantee_kind, grantee_name, permission, previous_permission). |
package_access.grant.removed | En tildeling ble fjernet. |
package_protection.rule.created, .updated, .deleted | En regel for beskyttede navn endret seg (package_type, name_pattern, push, delete). |
package_access.denied | En forespørsel ble avvist av tilgang per pakke eller et beskyttet navn (access, needed, permission, reason og aktørfeltene ovenfor). Høyst én gang i timen for samme aktør, pakke og tilgang. |
package_access.would_deny | Det samme, mens fremforge kjørte sjekken i observasjonsmodus og leverte forespørselen. |
Modellskanning
Modellskanning skriver:
| Handling | Når |
|---|---|
security_policy.model_scan.updated | Organisasjonens modellpolicy endret seg (changed, og diff med from og to for hver innstilling). |
security_policy.model_scan.dismissed | Et funn ble avvist for én fil, eller avvisningen ble fornyet (sha256, verdict, reason, expires_at, replaced). |
security_policy.model_scan.dismissal_revoked | En avvisning ble tilbakekalt (sha256). |
En pull som modellpolicyen avviser, er en registry.pull.blocked-hendelse med gate: model, se nedenfor.
Sperrer for container-pull
Registerets image-sperrer skriver beslutningene sine til revisjonsloggen, så de når SIEM-en din som alle andre hendelser:
| Handling | Når |
|---|---|
registry.pull.blocked | En container-pull ble avvist |
registry.pull.would_block | En pull ble levert som en sperre ville avvist: blokkeringshandlingen din for image-skanning er warn, eller sperren kjører i observasjonsmodus |
Aktøren er system:registry-pull-gate. fields er:
| Felt | Betydning |
|---|---|
gate | image_scan (sårbarhetsfunn på eller over blokkeringsterskelen din), image_malware (ondsinnede pakker), registry_scan (et lag i imaget som ClamAV fant infisert eller ikke kunne skanne), registry_blob (det samme, for et lag hentet direkte med digest), signature (image-signaturer: reason er unsigned, untrusted eller invalid) eller model (modellskanning: reason er model-malicious, model-suspicious eller model-unscannable) |
image, ref, digest | Imaget, taggen eller digesten det ble bedt om, og digesten som ble levert |
reason | Hva sperren fant, for eksempel layer-infected eller image-malware |
mode | enforce, warn (blokkeringshandlingen din) eller shadow (observasjonsmodus) |
block_severity, finding_count | Bare image_scan: terskelen og antallet åpne funn på eller over den |
window_start | Timen denne hendelsen står for |
previous_window_start, previous_window_count | Den siste tidligere timen med en hendelse for samme nøkkel, og hvor mange beslutninger den hadde totalt; null for den første |
Én hendelse per time. En CI-jobb som puller et blokkert image i en løkke, ville ellers fylt loggen. Derfor kommer det én hendelse per image-digest, sperre og beslutning per UTC-time, skrevet ved timens første beslutning. Senere beslutninger i den timen telles, og antallet rapporteres på neste hendelse for samme nøkkel som previous_window_count. Antallet for en time når derfor SIEM-en din med neste hendelse for den digesten, ikke ved slutten av timen; antallet for den siste timen med pulls sendes ikke. En blocked og en would_block for samme digest, eller to sperrer, er separate nøkler.
En registry.pull.blocked-hendelse utløser også varselwebhooken din for security.pull.blocked, hvis du har abonnert på en. Hver pull, tillatt eller ikke, står i tilgangsloggen for registeret.
Revisoraktivitet
Medlemmer av organisasjonens Auditors-team kan lese organisasjonsinnstillingene uten å endre dem. Lesingene deres registreres, så du kan se hva en revisor har sett på:
| Handling | Når |
|---|---|
tenant.auditor.read | En revisor åpnet en administrasjonsside eller kalte et leseendepunkt i API-et. Høyst én hendelse per revisor og rute hvert 10. minutt |
tenant.auditor.write_refused | En revisor sendte en forespørsel som ville endret noe, og den ble avvist. Hvert forsøk |
tenant.auditor.read_refused | En revisor ba om en side eller et endepunkt som er stengt for revisorer, som dataeksporten, og det ble avvist. Hvert forsøk |
compliance.evidence.fetched | Hvem som helst, revisor eller ikke, hentet den signerte bevispakken for samsvar gjennom API-et. Hver henting |
På de tre tenant.auditor.*-hendelsene er aktøren revisorens brukernavn, og fields har route (rutemønsteret, som /:slug/_admin/members, aldri spørrestrengen), method, status på tenant.auditor.read, via (portal, oauth eller token) og, for et API-token, token_id.
Lese loggen
Organisasjonsadministrasjon → Rapporter → Revisjonslogg. Filtrer på aktør (<username>, eller en agent som mcp-client:<client id>; filteret matcher også personen en agent handlet for), handling (secret.created, role.changed, …), tidsrom eller berørt ressurs. Standardvisningen er de siste 7 dagene.
Klikk på en rad for å utvide JSON-nyttelasten. Sensitive felt (secret-verdier, OIDC-tokener, vedlegg med personopplysninger) sladdes ved skrivegrensen, så en utvidet rad viser aldri en verdi du ikke ville latt en kundes revisor lese.
CSV-eksport
Klikk Eksporter CSV på en hvilken som helst filtrert visning for å få et øyeblikksbilde. CSV-filen inneholder radene som er filtrert akkurat nå, med en grense på 50 000 rader per eksport. For større vinduer setter du en full dataeksport i kø fra Rapporter → Dataeksport.
Via REST-API
Revisjonsloggen er tilgjengelig på den offentlige API-flaten. Bruk dette når du strømmer hendelser inn i din egen analysekjede, bygger et samsvarsdashbord eller kjører revisjonsspørringer fra et skript.
- Spør mot loggen
GET /_app/api/v1/orgs/:slug/audit(filtrer med?actor_kind=og?since=) - Verifiser kjedeintegriteten
GET /_app/api/v1/orgs/:slug/audit/integrity - Endre oppbevaringsvinduet
PATCH /_app/api/v1/orgs/:slug/auth-policybody:{ "audit_full_payload_retention_days": 365 }
Krever et personlig tilgangstoken (PAT) med scopet audit:read (eller policy:write for å endre oppbevaringsvinduet):
curl -H "Authorization: Bearer ${FREMFORGE_PAT}" \
"https://frem.sh/_app/api/v1/orgs/acme/audit?actor_kind=human&since=2026-01-01T00:00:00Z"Se referansen for det offentlige REST-API-et for hele OpenAPI-spesifikasjonen.
SIEM-videresending
Hver revisjonshendelse sendes også til et HTTPS-mottak per kunde hvis du konfigurerer SIEM-videresending. Mottaket får hendelsene i sanntid (innen sekunder etter handlingen) i en kompakt JSON-form; formatet er stabilt og versjonert.
Oppbevaring
Revisjonsposter tas vare på i to nivåer:
- Søkbart nyttelastnivå – aktørnavnet og
fields_json-nyttelasten for hver hendelse kan søkes i administrasjonsgrensesnittet / CSV-eksporten / SIEM-strømmen i oppbevaringsvinduet nedenfor. - Manipulasjonsavslørende kjedenivå – hver hendelses kryptografiske hash og kjedeledd blir værende i 3 år (WORM-forankret til OBS object lock). Det er dette som gjør kjeden beviselig urørt for revisjonsberedskap; den forblir intakt selv etter at sladdingen i nyttelastnivået har stemplet en rad.
Oppbevaring av søkbar nyttelast
| Plan | Standard | Forhåndsvalg kunden kan justere |
|---|---|---|
| fremforge / starter | 90 dager | 90 / 180 / 365 / 730 |
| enterprise / enterprise_trial | 365 dager | 90 / 180 / 365 / 730 |
Taket på 730 dager (≈2 år) holder den levende tabellen audit_events avgrenset. Alt utover det er WORM-nivåets oppgave; trenger du søkbar historikk utover 730 dager, setter du en dataeksport i kø hvert kvartal og arkiverer den i SIEM-en din.
Grensen gjelder kolonnene for aktør og fields_json: rader eldre enn vinduet beholder hash, tidsstempel og handlingsnavn (så SOC 2- / DORA-rapportering fortsatt virker), men aktøren pseudonymiseres til redacted, og nyttelasten erstattes med {}. Den kryptografiske kjeden brytes ikke av dette; sladdingen er en pseudonymisering på stedet, ikke en sletting.
Det søkbare vinduet er klassen audit_payload i oppbevaring av bevis, der de andre bevisklassene også settes. En rettslig tilbakeholdelse (legal hold) setter sladdingen på vent.
Endre det søkbare vinduet
Organisasjonsadministrasjon → Sikkerhet → Autentiseringspolicy → kortet Oppbevaring av revisjonsloggen. Velg 90 / 180 / 365 / 730 dager. Merknader om virkemåten:
- Forlenge vinduet (f.eks. 90 → 365): nyskrevne rader forblir søkbare lenger. Rader som allerede er sladdet under det forrige vinduet, forblir sladdet – fremforge opphever ikke sladding.
- Forkorte vinduet (f.eks. 365 → 90): neste daglige sladderunde sladder hver rad eldre enn det nye vinduet. Sladding kan ikke angres når den er gjort; WORM-kjeden påvirkes ikke.
Revisjonshandling som registreres for denne innstillingen: tenant.auth_policy.audit_retention.updated (med antall dager i previous og next).
Samsvarsforpliktelser
Databehandleravtalens vedlegg A.7 forplikter til grunnnivået på 90 dager + 3 år WORM. Enterprise-SLA-en forplikter til 365 dager søkbart + 3 år WORM. Å gå under planens standard er tillatt i grensesnittet, men vil bryte databehandleravtalen – fremforge håndhever ikke gulvet i kolonnen, det gjør kontrakten. En feil i selve den daglige sladderunden (atskilt fra at en kunde endrer oppbevaringen) overvåkes og varsles kontinuerlig.