Improve PoC collection using GitHub archive data
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 43/100
研究方向
Issue 中沒有指定具體的檔案或測試。首先，找出目前從 nomi-sec/PoC-in-GitHub 取得資料的 PoC 收集管線，以及執行該管線的 CI 工作流程。檢查 PoC 如何被發現、儲存及驗證，然後使用 giant-hourly-archive 資料和提議的 confidence layer 設計一條平行的擷取路徑。完成的標準是 collector 能以可重現的方式使用新來源，並提供清楚的驗證輸出，以提升結果可靠性，且可由現有的管線檢查加以驗證。
由索引模型根據 Issue 內容生成。
描述
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:
- https://github.com/giant-hourly-archive/giant-hourly-archive-2011
- ...
- https://github.com/giant-hourly-archive/giant-hourly-archive-2026
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:
- 主要語言
- Python
- 星號
- 716
- 分支
- 347
- 平均合併
- 13 小時 47 分鐘
- 30 天內合併 PR
- 8
環境準備
- 提供 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 沒有貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
aboutcode-org/vulnerablecode 的其他 Issue
-
OSV parser drops all crates.io affected entries because the ecosystem mapping uses cargo可能已有人在做 @Ashutosh-Panda2004 於 5 天前認領。 未關閉
難度 2/5 1-3 小時 新手友好度 76/100
aboutcode-org/vulnerablecode#2485 · 1 則留言 ·
維護者通常 1 天內回覆
-
Docker Compose setup fails on wait-for-it host web:8000 and missing runtime .env可能已有人在做 @Anurag-S1ngh 於 9 天前認領。 未關閉
難度 2/5 半天 新手友好度 77/100
aboutcode-org/vulnerablecode#2477 · 1 則留言 ·
維護者通常 1 天內回覆
-
OVAL parser corrupts version bounds when the epoch is 10, 20 or the version contains "0:"可能已有人在做 @Ashutosh-Panda2004 於 7 天前認領。 未關閉
難度 2/5 1-3 小時 新手友好度 76/100
aboutcode-org/vulnerablecode#2474 · 1 則留言 ·
維護者通常 1 天內回覆
-
Docker build fails on Apple Silicon (arm64) — only x86_64 wheels pinned for extractcode-7z, extractcode-libarchive, typecode-libmagic可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 2/5 1-3 小時 新手友好度 86/100
aboutcode-org/vulnerablecode#2426 ·
維護者通常 1 天內回覆
-
Get NuGet package versions from federated PURL version data in https://github.com/aboutcode-data/可能重新可做 @Anshi321 於 28 天前認領，目前沒有進行中的 PR。 未關閉bug data-quality
難度 2/5 1-3 小時 新手友好度 72/100
aboutcode-org/vulnerablecode#2418 · 4 則留言 ·
維護者通常 1 天內回覆
查看 aboutcode-org/vulnerablecode 的全部 Issue
相似的 Issue
-
URLValidator ignores an explicit empty scheme allowlist可能已有人在做 @IlyaKhalafi 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 85/100
tortoise/tortoise-orm#2393 ·
維護者通常 2 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 62/100
frappe/frappe_docker#2046 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 62/100
-
complete_box_iou_loss / complete_box_iou: NaN gradients for zero-height boxes, NaN for point boxes未關閉
難度 2/5 1-3 小時 新手友好度 62/100
維護者通常 1 天內回覆
-
AXI SMU SPEC
難度 2/5 1-3 小時 新手友好度 62/100
tenstorrent/tt-oca-harness#3556 ·
維護者通常 1 天內回覆