# VulnWatchdog: An Automated CVE Monitor That Sends GPT-Generated Reports to Feishu

> VulnWatchdog watches GitHub for CVE-related repositories, pulls PoC code, and uses a GPT model to produce Markdown reports with risk and poisoning scores. It is aimed at teams that want a hands-off pipeline but are willing to trade control for automation.

**arschlochnop/VulnWatchdog** — VulnWatchdog is an automated vulnerability monitoring and analysis tool. It monitors CVE-related repositories on GitHub, collects vulnerability info and PoC code, and uses GPT for intelligent analysis to generate detailed reports.

- Repository: https://github.com/arschlochnop/VulnWatchdog
- Stars: 116 · Forks: 29
- Language: Python
- License: not declared
- Published: 2026-08-26 · Updated: 2026-08-26 · Language: en
- Canonical page: https://hysenlabs.com/projects/arschlochnop-vulnwatchdog

## What VulnWatchdog Actually Automates

VulnWatchdog solves a narrow but real problem: keeping up with newly published CVE proof-of-concept code on GitHub without refreshing a search page every hour. The README describes a tool that monitors GitHub repositories related to CVEs, fetches vulnerability details and PoC code, then runs a GPT model over that material to produce a structured analysis. The output is a Markdown file per CVE, stored under data/markdown/{cve_id}-{repo_name}.md, plus an index that gets regenerated on each run. The intended user is a security engineer or a small team that already uses Feishu for notifications and wants a first-pass triage of new PoCs. It is not a vulnerability scanner. It does not test your own systems. It watches what others publish and summarizes it for you.

## The Data Flow: From GitHub to Markdown Report

The pipeline has a clear sequence visible in the repository layout. main.py is the entry point. It coordinates a few libraries: libs/utils.py for helpers, libs/webhook.py for notifications, libs/search_engines.py for multi-engine searching, and models/models.py for CVE and repository data structures. The README states that the tool monitors GitHub CVE-related repositories hourly. For each new or updated item, it fetches CVE details, pulls the PoC code, and sends that combined input to a GPT model via a configurable server URL. The model returns fields such as name, type, app, risk, version, condition, poc_available, poison, and markdown. The poison field is a percentage estimate of whether the PoC is malicious, which is a distinctive feature. The final report is written to disk, and the index tool, tools/generate_indexes.py, regenerates the README index. Notifications go out through the webhook module, which currently supports only Feishu. The whole thing can run in GitHub Actions on a schedule or manually.

## Deployment Paths: GitHub Actions or Local Python

The README offers two ways to run VulnWatchdog. The recommended route is GitHub Actions. You fork the repository, add secrets under Settings, and let the workflow run every hour. The cron expression in .github/workflows/monitor.yml controls the frequency, with a default of '0 * * * *'. Required secrets are WEBHOOK_URL for Feishu, GPT_SERVER_URL, and GPT_API_KEY. GPT_MODEL is optional and defaults to gemini-2.0-flash. GH_TOKEN is optional but recommended, since the README claims it raises the GitHub API rate limit from 60 requests per hour to 5000 per hour. The local route is straightforward: git clone, pip install -r requirements.txt, copy .env.example to .env, fill in the variables, and run python main.py. The .env file mirrors the secrets: WEBHOOK_URL, GPT_SERVER_URL, GPT_API_KEY, GPT_MODEL, SEARXNG_URLS (comma-separated), and GH_TOKEN. Feature toggles live in config.py, including ENABLE_NOTIFY, ENABLE_GPT, ENABLE_SEARCH, ENABLE_EXTENDED, and ENABLE_UPDATE_CHECK.

## The Search Engine Layer: Multiple SearXNG Instances

VulnWatchdog does not rely solely on GitHub search. It also queries SearXNG instances to find vulnerability information beyond the repository metadata. The README mentions that it supports multiple SearXNG instances concurrently and performs automatic failover. You configure the instances via SEARXNG_URLS in the .env file, separating URLs with commas. The default configuration lives in libs/default_search_engines.json. This design is a practical hedge: if one SearXNG instance is down or rate-limited, the tool moves to the next. The ENABLE_SEARCH and ENABLE_EXTENDED flags let you turn this off entirely or run a broader search. What is not clear from the material is how the search results are merged with the GitHub data before being sent to the GPT model. The README does not specify the exact prompt or the input format. That is a gap worth checking before you rely on the output.

## The Poisoning Score: A Useful Idea with Unclear Grounding

The most interesting output field is poison, described as a poisoning risk assessment with an example value of 90%. The idea is to flag PoCs that might be malicious, not just proof-of-concept exploits. This matters because public PoC repositories are a known vector for malware. The README says the GPT model evaluates this risk, but it does not explain the criteria. There is no rubric, no threshold, and no confidence interval. The score is a single percentage produced by an LLM, which means it is probabilistic and may vary between runs. For a security tool, that is a genuine limitation. You cannot treat the number as a hard metric. It is more like a heuristic that should prompt a human review. The README also notes that unit tests are on the development plan but not yet added, so the code that computes this score has no automated verification.

## Rate Limits and Token Handling: The Three-Tier GitHub Access

The README spends significant space on GitHub API rate limits, which is honest because they are the main operational constraint. It lists three configurations: no token (60 requests per hour), GITHUB_TOKEN (1000 per hour, automatically provided by Actions), and GH_TOKEN (5000 per hour, recommended). The recommended setup is to generate a classic personal access token with only the public_repo scope and store it as GH_TOKEN. The README explicitly says this is for reading public repositories. That is a sensible security boundary. However, the project also has a three-level priority system for tokens, which implies the code tries multiple token sources. If you run locally, you must supply GH_TOKEN yourself. The rate limit matters because the tool scans GitHub hourly, and if the limit is hit, the workflow will fail or skip items. The README does not say what happens on failure, so you should assume the run may be incomplete.

## Alternatives and the Trade-off in Approach

The README credits Poc-Monitor as the source of the project's inspiration. Poc-Monitor is a different tool: it tracks PoC repositories on GitHub and sends notifications, but it does not use an LLM for analysis. That is the core difference. VulnWatchdog adds a GPT layer to interpret the data, while Poc-Monitor stays closer to raw aggregation. If you want a deterministic pipeline that just tells you 'new PoC for CVE-X', Poc-Monitor is simpler and has fewer moving parts. If you want a summarized assessment with risk and poisoning estimates, VulnWatchdog offers that, but you accept the variability of LLM output. Another alternative is to write your own script using the GitHub API and a webhook, which gives you full control but requires more maintenance. The choice depends on whether you trust an LLM to triage security data for you.

## Maintenance, Licensing, and What to Verify First

The repository states an MIT License, which is permissive, but the README also lists the license as MIT while the repository metadata says unknown. That inconsistency is worth noting. The project is not archived and has a default branch of main, but there are no recent releases retrieved, and the last push date is unknown. The development plan shows completed items like config management and multi-engine search, but unit tests are still pending. That means the code may change quickly, and you should pin the commit or fork if you rely on it. Before adoption, check the .env.example file for any variables not mentioned in the README, and test the GPT server URL with a real CVE to see the report quality. Also verify that the Feishu webhook format matches what the code sends, because the README points to NOTIFY.md for details that are not included in the material I have.

## Conclusion

Adopt VulnWatchdog if you want a scheduled, low-effort CVE alerting pipeline that runs in GitHub Actions and pushes GPT-generated Markdown reports to Feishu. Do not adopt it if you need deterministic analysis, strict accuracy guarantees, or support for notification channels beyond Feishu. Before using it, verify the GPT endpoint you plan to use, confirm the model's output quality on sample CVEs, and check that the GitHub token you supply has only the read-only public_repo scope. The project has no unit tests yet, so audit the code paths that handle PoC content before trusting the poisoning score.

## FAQ

### What does the arschlochnop VulnWatchdog tool do?

It monitors GitHub repositories related to CVEs once an hour, fetches the vulnerability information and any proof-of-concept code, sends them to a model for analysis, and writes a structured Markdown report per finding. It can also push results to a webhook and score each finding for risk and for repository poisoning.

### How do I run VulnWatchdog on GitHub Actions?

Fork the repository, add the secrets the features need, and the scheduled workflow runs itself every hour. The cadence is a cron expression in the monitoring workflow file with a documented default of '0 * * * *', and a run can also be triggered by hand from the Actions page.

### Why does VulnWatchdog need a GitHub token?

Because it polls the API hourly. With no token the limit is 60 requests per hour, the token Actions supplies automatically raises it to 1000, and a token you add yourself as a secret raises it to 5000 per hour, which is the recommended setup and needs only permission to read public repositories.

### Which dependencies does VulnWatchdog need, and how does it call the model?

Four packages: an HTTP client, a dotenv loader, an ORM and a command line library, with no vendor SDK for the model. The model endpoint is a plain address, with the example pointing at an OpenAI-compatible chat completions path, and the default model is a small Flash model even though the configuration variables are named for GPT.

### Where does VulnWatchdog store its reports?

One Markdown file per finding, at a path built from the CVE identifier and the repository name under the data directory, with a date-organised index generated alongside. Both are updated and committed on every run, and results can be pushed to a webhook as well.

## Sources

- [Official README](https://github.com/arschlochnop/VulnWatchdog#readme)
- [Project repository](https://github.com/arschlochnop/VulnWatchdog)
- [README](https://github.com/arschlochnop/VulnWatchdog/blob/main/README.md)
- [Releases](https://github.com/arschlochnop/VulnWatchdog/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/arschlochnop-vulnwatchdog