Opgehaalde packageversies

Een bevinding in een afhankelijkheid zegt dat een versie ergens is gedeclareerd. De pull-telling zegt iets anders: welke packageversies daadwerkelijk zijn gedownload, door welke afnemer en hoe recent. Ze wordt geteld uit de toegangslog van de registry, en omvat dus je eigen packages in de fremforge-registry en de packages die je organisatie via de dependency proxy ophaalt, inclusief pulls vanuit CI buiten fremforge die een registryrobot gebruiken.

Sinds 2026-10-13 wordt een download die een Forgejo Actions-job via de dependency proxy doet, en die de proxy uit zijn cache serveert, hier direct geteld en niet als gebeurtenis in de toegangslog opgeslagen (zie toegangslog van de registry). De pull-telling is daarom het overzicht van die pulls: per UTC-dag, packageversie en repository, met de runs die ze ophaalden.

Wat telt als een pull

Een pull is een geslaagde download die een versie noemt: een npm-tarball, een PyPI-bestand, een Maven-artefact, een NuGet-package, een Go-module-zip, een generiek of ander registrybestand, of een containerimage die op tag is opgehaald. Niet geteld worden:

• metadata-leesacties, zoals een npm-packument of een PyPI simple index;
• geweigerde verzoeken;
• downloads van containerlagen, die alleen een digest noemen.

Een download die een beleid in schaduwmodus zou hebben geweigerd, maar heeft doorgelaten, telt wel als pull.

Afnemers

Elke pull wordt toegeschreven aan de afnemer die de toegangslog vastlegde:

Welke advisories worden gekoppeld

• Versies die via de dependency proxy zijn opgehaald (npm, PyPI, Maven, NuGet en Go) worden vergeleken met de OSV-advisory-index die het packagebeleid van de proxy evalueert. Versiebereiken worden geëvalueerd, niet alleen exacte versies. source is advisory_index.
• Versies van je eigen registrypackages dragen de openstaande bevindingen van dat packagebestand, dezelfde bevindingen die het packagebeleid leest. Genegeerde en opgeloste bevindingen worden weggelaten. source is package_findings.
• Containerimages worden geteld, maar deze lijst toont er geen advisories voor. Bevindingen in images staan op de pagina’s voor imagescanning.

In de console

Open in het organisatiebeheer Beveiliging › Componenten › Opgehaalde versies. De pagina toont dezelfde versies als de API, met dezelfde volgorde en filters: packagenaam, periode (vandaag, of de laatste 7, 30, 90 of 365 dagen), minimale ernst, ecosysteem, bron (je eigen registry of de dependency proxy), soort afnemer en afnemer. Vink Versies zonder bekend advies meenemen aan om elke opgehaalde versie te zien, niet alleen de kwetsbare. Elke rij toont de hoogste ernst, tot drie advisories met een gefixte versie, het aantal pulls per soort afnemer, de belangrijkste afnemers en wanneer de versie het laatst en het eerst werd opgehaald. De regel boven de tabel zegt tot wanneer toegangsgebeurtenissen zijn geteld. Volgende pagina en Eerste pagina bladeren door de lijst; CSV exporteren downloadt elke overeenkomende versie met de huidige filters, in dezelfde kolommen als de CSV van de API.

Uitlezen met de API

Met een API-token dat components:read of findings:read heeft:

curl -sS -H "Authorization: Bearer $FFP_TOKEN" \
  "https://frem.sh/_app/api/v1/orgs/acme/components/pulled?days=30&min_severity=high"

Standaard bevat de lijst alleen kwetsbare versies, de ernstigste eerst en daarna de meest recent opgehaalde. Elk item heeft de versie en haar purl, de hoogste severity, de advisories met hun gefixte versies, het totaal aantal pulls, de pulls per soort afnemer, first_seen_at en last_seen_at, en tot tien consumers met hun eigen aantallen en tijden. Een afnemer van het type job heeft ook run_ids: tot 20 Actions-run-id’s (GITHUB_RUN_ID) die de versie in de periode ophaalden, de nieuwste eerst.

Om te zien wat één build ophaalde, geef je de run-id mee met vulnerable=false:

curl -sS -H "Authorization: Bearer $FFP_TOKEN" \
  "https://frem.sh/_app/api/v1/orgs/acme/components/pulled?run_id=123456&vulnerable=false&days=7"

Geef de next_cursor van een pagina mee als cursor om de volgende pagina op te halen, met dezelfde filters, en stop als die null is. Een pagina bevat tot 500 versies (limit). Voeg format=csv toe voor elke overeenkomende versie als CSV. Een query die meer dan 50.000 versies oplevert, antwoordt met 413 too-many-rows; maak hem dan smaller. Zie de API-referentie voor de volledige structuur.

Hoe actueel het is en hoe lang het wordt bewaard

De pull-telling wordt elk uur uit de toegangslog samengevat. window.rolled_up_to in het antwoord zegt tot wanneer toegangsgebeurtenissen zijn geteld. CI-downloads die uit de cache van de dependency proxy worden geserveerd, worden toegevoegd zodra ze binnenkomen, zonder op de uurlijkse samenvatting te wachten.

De pull-telling volgt de bewaartermijn voor bewijs van de toegangslog en wordt door dezelfde dagelijkse job verwijderd: de aantallen van een dag verdwijnen zodra de nieuwste download die ze tellen buiten de bewaartermijn access_log valt, of buiten de bewaartermijn access_log_ci voor CI-pulls via de dependency proxy. Zolang er een legal hold geldt, wordt niets verwijderd.

In de data-export

Elke data-export bevat de pull-telling als metadata/pulled-versions.ndjson, één regel per UTC-dag, packageversie en afnemer: de rijen die deze pagina optelt. Zie Export schema. De advisories staan niet in het bestand: die worden gekoppeld wanneer je de lijst leest, uit advisorygegevens die in de loop van de tijd veranderen.

Beperkingen

• Een pull is geen deployment. Een versie kan door een build worden opgehaald en nooit worden uitgeleverd, of één keer worden opgehaald en maandenlang in een cache staan.
• Pulls uit caches buiten fremforge worden niet gezien. Alleen verzoeken die de fremforge-registry of de dependency proxy bereiken, worden geteld.
• Teams worden niet vastgelegd. De pull van een gebruiker wordt aan die gebruiker toegeschreven.
• Run-id’s worden bewaard vanaf 2026-10-13. Per UTC-dag, packageversie en repository worden de 100 nieuwste runs bewaard; een repository die op een dag meer dan 100 builds draait die dezelfde versie ophalen, houdt het aantal van elke pull, maar alleen de id’s van de 100 nieuwste runs.
• De pull-telling legt niet vast welke job van een run een versie ophaalde, en ook niet het exacte tijdstip van elke pull, alleen de eerste en de laatste van de dag.