Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Improve PoC collection using GitHub archive data

Ouverte
  • Quelque chose ne va pas ?
#2,429 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
43/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
github, github-actions, python
Domaine
backend

Piste de recherche

Aucun fichier ni test spécifique n’est indiqué dans l’issue. Commencez par localiser le pipeline actuel de collecte de PoC qui s’alimente de nomi-sec/PoC-in-GitHub, ainsi que le workflow CI qui l’exécute. Examinez comment les PoC sont découverts, stockés et validés, puis concevez un chemin d’ingestion parallèle utilisant les données de giant-hourly-archive et la couche de confiance proposée. La tâche sera terminée lorsque le collector utilisera la nouvelle source de manière reproductible, avec une sortie de validation claire qui améliore la fiabilité des résultats et peut être vérifiée par les contrôles existants du pipeline.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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:

Langage dominant
Python
Étoiles
716
Forks
347
Merge moyen
12 h 15 min
PR mergées (30 j)
9

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de aboutcode-org/vulnerablecode

Toutes les issues de aboutcode-org/vulnerablecode

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.