Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Add standard "known vulnerabilities" metadata field, sourced from OSV

Geschlossen
  • Stimmt etwas nicht?
#1,360 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
45/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
api, backend, security

Rechercherichtung

Start with PythonRepositoryVersionViewSet and the existing VulnerabilityReport.vulns data, then compare the response-shape precedent in #1282 for PackageYank. The work is done when Simple API and JSON API responses expose the standard vulnerabilities field from OSV results, with the issue's open question about automatic scanning resolved.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Is your feature request related to a problem? Please describe.

pulp_python already has vulnerability-scanning capability: a scan action on PythonRepositoryVersionViewSet (added in #1013/#1012) queries OSV.dev and stores results in pulpcore's VulnerabilityReport model. However, that data is not exposed through the standard PyPI "known vulnerabilities" metadata field described in the PyPI JSON API spec — the existing scan output lives in its own report resource, not in the Simple API / JSON API response shape that standard PyPI tooling expects, and today's scan is manual/on-demand only. Tooling that relies on the standard field for vulnerability visibility (e.g. Red Hat Trusted Libraries / the pulp-trustify effort) has no way to consume it from pulp_python today.

Describe the solution you'd like

Surface the existing VulnerabilityReport.vulns data (see above) through the Simple API / JSON API responses as the standard vulnerabilities field, following a comparable per-(name, version) marker pattern to native PackageYank support (#1282) for the API-shape/serializer side. OSV remains the data source underneath — no new scanning backend needed. Open design question to resolve here: scanning today is manual/on-demand only — deciding whether it should also trigger automatically (e.g. on sync/upload) is in scope for this issue.

This is agreed phase-1 scope for the Pulp-Trustify integration effort — complex/custom scanning and Trustify-specific data-source integration are intentionally deferred to a later phase (see context below).

Describe alternatives you've considered

  • Implementing this in pulp-service instead — ruled out; pulp-service (the hosted Pulp team) is an external stakeholder for this effort, not a place for this logic to live.
  • Full Trustify-backed scanning/library integration now — deferred; this issue is scoped narrowly to the standard OSV-sourced vulnerabilities field, decoupled from the broader pulp-trustify core-library work happening in parallel in pulp/pulp_trustify.
  • Building a new scanning mechanism from scratch — ruled out; #1013/#1012 already added an OSV.dev-backed scan pipeline (VulnerabilityReport model, scan action) that this issue should extend rather than duplicate.

Additional context

  • Part of the broader Trustify integration program (Red Hat Trusted Libraries / Calunga); tracked upstream at pulp/pulp_trustify.
  • Related PRs: #1013/#1012 (existing OSV.dev-backed scan pipeline — VulnerabilityReport model, scan action — the mechanism this issue extends), #1282 (native PackageYank content model — API-shape precedent for surfacing a per-package marker).
  • Filed on behalf of Otávio Fernandes; Gerrod Ubben to be notified separately once this is actually filed — he may pick it up next sprint, or review a contribution from Otávio.
Vorherrschende Sprache
Python
Sterne
49
Forks
88
Ø Merge
2 T. 4 Std.
Gemergte PRs (30 T.)
31

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus pulp/pulp_python

Alle Issues in pulp/pulp_python

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.