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

Improve PoC collection using GitHub archive data

Offen
  • Stimmt etwas nicht?
#2,429 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
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
43/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
github, github-actions, python
Bereich
backend

Rechercherichtung

Im Issue werden keine spezifischen Dateien oder Tests genannt. Finde zunächst die aktuelle PoC-Sammelpipeline, die Daten aus nomi-sec/PoC-in-GitHub bezieht, sowie den CI-Workflow, der sie ausführt. Untersuche, wie PoCs entdeckt, gespeichert und validiert werden, und entwirf dann einen parallelen Ingest-Pfad mit giant-hourly-archive-Daten und der vorgeschlagenen Confidence-Schicht. Als abgeschlossen gilt die Aufgabe, wenn der Collector die neue Quelle reproduzierbar verwendet und eine klare Validierungsausgabe liefert, die die Zuverlässigkeit der Ergebnisse verbessert und durch bestehende Pipeline-Prüfungen verifiziert werden kann.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

We are currently collecting PoCs primarily from this repository:

From my understanding, this repository is generated by an automated bot.

There is another project doing something very similar:

The general approach seems to be running a CI job that uses the GitHub API to search for repositories containing CVE IDs and then collecting the results.

However, I think we could use a cleaner and potentially more reliable approach for collecting PoCs.

Instead of repeatedly querying the GitHub API for every CVE ID, we could use the GitHub hourly archive data:

The idea would be to process the archive data locally and search for CVE IDs across newly indexed GitHub content. This could significantly reduce the number of GitHub API requests and give us a more reproducible dataset.

We could then add an extra validation layer to determine whether a discovered repository is actually a valid PoC/Exploit repository. For example, this could involve:

  • Manual review by contributors for higher-confidence results.
  • An LLM-based validation step that reads the repository metadata/content and determines whether it actually contains a PoC or exploit related to the identified CVE.
  • Potentially combining both approaches to assign a confidence level to each result.

As a proof of concept, I’ve tested this approach with:

Vorherrschende Sprache
Python
Sterne
716
Forks
347
Ø Merge
12 Std. 15 Min.
Gemergte PRs (30 T.)
9

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Keine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

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 aboutcode-org/vulnerablecode

Alle Issues in aboutcode-org/vulnerablecode

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

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