Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Improve PoC collection using GitHub archive data

Abierto
  • ¿Algo no está bien?
#2,429 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
43/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github, github-actions, python
Área
backend

Línea de trabajo

El issue no especifica archivos ni pruebas concretos. Primero, localiza el pipeline actual de recopilación de PoC que obtiene datos de nomi-sec/PoC-in-GitHub y el flujo de trabajo de CI que lo ejecuta. Inspecciona cómo se descubren, almacenan y validan los PoC, y después diseña una ruta de ingestión paralela usando datos de giant-hourly-archive y la capa de confianza propuesta. La tarea estará terminada cuando el collector utilice la nueva fuente de forma reproducible, con una salida de validación clara que mejore la fiabilidad de los resultados y pueda verificarse mediante las comprobaciones existentes del pipeline.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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:

Lenguaje dominante
Python
Estrellas
716
Forks
347
Merge medio
12 h 15 min
PR fusionados (30 d)
9

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de aboutcode-org/vulnerablecode

Todos los issues de aboutcode-org/vulnerablecode

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.