Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Improve PoC collection using GitHub archive data

Aberta
  • Algo errado?
#2,429 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
43/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
github, github-actions, python
Domínio
backend

Direção de pesquisa

Nenhum arquivo ou teste específico é indicado na issue. Primeiro, localize o pipeline atual de coleta de PoC que obtém dados de nomi-sec/PoC-in-GitHub e o workflow de CI que o executa. Inspecione como os PoCs são descobertos, armazenados e validados e, em seguida, projete um caminho paralelo de ingestão usando dados de giant-hourly-archive e a camada de confiança proposta. A tarefa estará concluída quando o collector usar a nova fonte de forma reproduzível, com uma saída de validação clara que melhore a confiabilidade dos resultados e possa ser verificada pelas verificações existentes do pipeline.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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:

Linguagem predominante
Python
Estrelas
716
Forks
347
Merge médio
13h 47min
PRs com merge (30d)
8

Preparar o ambiente

  • Inclui um Dockerfile ou arquivo Docker Compose
  • Sem modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de aboutcode-org/vulnerablecode

Todas as issues de aboutcode-org/vulnerablecode

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.