Tilgangslogg for registeret

Revisjonsloggen registrerer administrative handlinger. Tilgangsloggen for registeret registrerer noe annet: hver forespørsel en klient gjør mot pakke- og containerregisteret til organisasjonen din. Det omfatter hver nedlasting, hver lesing av metadata (en npm-packument, en enkel PyPI-indeks, en Maven-maven-metadata.xml), hver opplasting og hver sletting, og det tar med forespørsler som en policy blokkerte. Ingenting tas med som stikkprøver, med to unntak for rutinemessig CI-trafikk gjennom avhengighetsproxyen. Begge gjelder bare en forespørsel som en Forgejo Actions-jobb gjorde, og som proxyen tillot og besvarte uten feil:

• CI-lesinger av metadata registreres ikke (siden 2026-10-12). En pakkeindeks eller versjonsliste (en npm-packument, en enkel PyPI-indeks, en Maven-maven-metadata.xml) som en jobb leser, lagres ikke. Én pakkeinstallasjon gjør hundrevis av slike lesinger, og de forteller ingenting som nedlastingen etter dem ikke forteller.
• CI-nedlastinger som serveres fra proxybufferen, telles i stedet for å logges én for én (siden 2026-10-13). Når en jobb laster ned en pakkefil som proxyen allerede har, legges nedlastingen til i pull-tellingen i stedet for å lagres som en hendelse: én telling per UTC-døgn, pakkeversjon og repository, med ID-ene til Actions-kjøringene som hentet den. Du kan altså fortsatt se hvilken versjon av hvilken pakke som kom inn i hvilket bygg, per kjøring, fra tellingen.

Alt annet er fortsatt én hendelse, også CI:

• hver nedlasting som proxyen hentet fra upstream-registeret (bom i bufferen), og hver nedlasting fra ditt eget register
• hver forespørsel som en policy avviste, blokkerte eller ville ha blokkert
• hver forespørsel som feilet (status 400 eller høyere)
• hver forespørsel fra en person, en bot, en registerrobot eller anonymt, inkludert lesinger av metadata og treff i bufferen

En CI-nedlasting som telles i pull-tellingen, beholder pakke, versjon, dag, repository og kjøring, og antall hentinger. Den beholder ikke det en hendelse har utover dette: filnavnet, størrelsen, det nøyaktige tidspunktet for hver henting (tellingen har den første og den siste i døgnet), klientadressen, user agent og forespørsels-ID-en. Den leveres ikke til et SIEM-endepunkt og står ikke i access-log.ndjson; den finnes i API-et for pull-tellingen og i metadata/pulled-versions.ndjson i dataeksporten. Hendelser som ble lagret før disse datoene, beholdes i sin vanlige oppbevaringstid.

Hva en hendelse inneholder

Registreres aldri: et tilgangstoken, en Authorization-header, en informasjonskapsel eller en spørrestreng. En forhåndssignert lagrings-URL vises for eksempel aldri i en hendelse.

Lese den

Med et token som har audit:read:

curl -sS -H "Authorization: Bearer $FFP_TOKEN" \
  "https://frem.sh/_app/api/v1/orgs/acme/access-log?action=download&type=npm&since=2026-10-01"

Resultatene kommer med de nyeste først. Send next-verdien fra en side som cursor for å få neste side, og stopp når next er null. Markøren er nøkkelbasert, så hendelser som kommer mens du blar, forskyver eller gjentar aldri en rad. Filtre: since, until, origin, action, decision, type, name, version, actor (et brukernavn, eller anonymous) og ip. En side har opptil 500 hendelser. Se API-referansen for hele formatet.

Hvilke sårbare versjoner som hentes

Pull-tellingen teller de vellykkede nedlastingene i denne loggen per pakkeversjon og forbruker, sammen med CI-treffene i bufferen som telles der i stedet for å logges, og kobler dem mot sårbarhetsvarslene som pakkepolicyen din bruker. Den svarer på «hvilke sårbare versjoner ble hentet de siste 30 dagene, og av hvem» uten at du må bla gjennom de rå hendelsene, og run_id svarer på «hvilke versjoner hentet dette bygget».

Sende den videre til SIEM-en din

Tilgangshendelser kan leveres til et SIEM-endepunkt i den samme signerte konvolutten som revisjonshendelser. Handlingen er registry.access.<action> (for eksempel registry.access.download), og hash_chain er null fordi tilgangshendelser ikke er en del av hashkjeden i revisjonsloggen. Levering er av som standard, fordi nedlastingstrafikken er langt større enn revisjonstrafikken. Slå den på per endepunkt med include_access_log:

curl -sS -X PATCH -H "Authorization: Bearer $FFP_TOKEN" -H 'Content-Type: application/json' \
  -d '{"include_access_log": true}' \
  https://frem.sh/_app/api/v1/orgs/acme/siem/endpoints/$ENDPOINT_ID

Handlingsprefiksene til et endepunkt gjelder også for tilgangshendelser. For eksempel sender registry.access.upload bare opplastinger videre. CI-trafikken som ikke lagres som hendelser (se over), leveres heller ikke.

I dataeksporten

En dataeksport inneholder access-log.ndjson med hver tilgangshendelse som fremforge fortsatt har for organisasjonen, ett JSON-objekt per linje i det samme formatet som API-et returnerer, og metadata/pulled-versions.ndjson med pull-tellingen, der CI-treff i bufferen telles. Begge filene er dekket av eksportens signerte manifest.

Hvor lenge den oppbevares

Tilgangshendelser oppbevares i henhold til organisasjonens access_log-innstilling for oppbevaring av bevis: 30 til 730 dager. Hvis den ikke er satt, følger den oppbevaringstiden for revisjonsloggen (90, 180, 365 eller 730 dager, satt under Authentication policy → Audit log retention; standard 90). Eldre hendelser slettes én gang i døgnet. Så lenge en rettslig tilbakeholdelse (legal hold) gjelder, slettes ingenting.

Hvem som kan se adressene

Tilgangsloggen inneholder personopplysninger: brukernavnene og IP-adressene til brukerne dine. API-et, SIEM-leveransen og eksporten viser begge slik de ble registrert, fordi dette er organisasjonens egen logg. Verktøyene til fremforge-ansatte ser begge bare som nøkkelbaserte pseudonymer. Logglinjer som plattformen skriver for sin egen drift, inneholder ingen av dem.

Begrensninger

• Git clone og fetch, og lesinger gjennom REST-API-et (/api/v1), er ikke registerforespørsler og står ikke i denne loggen ennå.
• Sletting av en pakkeversjon gjennom REST-API-et (DELETE /api/v1/packages/...) eller nettgrensesnittet registreres ikke her. Slettinger som en registerklient gjør under /api/packages, blir registrert.
• En forespørsel som plattformen avviste før registeret svarte, for eksempel en opplasting som skadevareskanneren avviste, har ingen autentisert aktør og vises som anonymous.
• Leveransen fra registeret til loggen skjer i satser hvert 2. sekund eller for hver 500. hendelse. Hvis plattformen startes på nytt midt i en sats, kan hendelsene fra de siste sekundene gå tapt. Bevisste forkastinger logges og utløser alarm hos oss.