ErSilh0x/VULNaware

What it is

Vulnaware (ErSilh0x/VULNaware) is a self-hosted prioritisation engine for scanner exports. It runs as three Docker containers (postgres 17, an app serving the dashboard over TLS on 443 bound to loopback, and an APScheduler worker). The stack is Python 3.13, Flask, SQLAlchemy 2 and Alembic. The page does not state a licence, a version number or a release date.

How it works

Each scanner is scoped by a criterion set on the scanner side:

Empty scopes are configuration errors, never "export everything". Greenbone needs two credential pairs: SSH to the socat bridge, and GMP login.

Scoring is deterministic. Findings below prioritization.eligible_severities (default critical and high) are dropped. KEV, trending and exploit tags are added on top, and CISA KEV outranks the other KEV sources. Prioritised findings trigger notification and ticketing. Nothing is event-driven: imports, feeds and dispatch run on scheduler ticks (5 minutes by default for scanner import).

Findings with no CVE are handled differently. CVE-less rows are kept only at critical. Nessus drops them, and MaxPatrol rows carrying an FSTEC BDU id go to a manual_review table.

Trending data comes only from the MaxPatrol CSV trend column, so other scanners never get that signal.

Preconditions / Affected

• Only one ITSM platform may be enabled at a time. Enabling more than one is refused with a health alert.
• osTicket tickets are never updated after creation. Jira updates one ticket per host as new CVEs appear.
• VulnCheck feeds need a token (VulnCheck 402/403 or no token skips the feed). CISA KEV and FSTEC BDU need none.
• The dashboard is loopback-bound, so remote access needs an SSH tunnel (docs/ssh_tunnel.md).
• The container mounts config.yaml read-only and never sees the host .env, so save in run_config.py must run on the host.

What to do

Smoke test with the shipped MaxPatrol example. It is the only one that reaches Telegram and Jira, because its row carries the trending flag that the notify/ticket gate needs.

cp vulnaware/vuln_scanners/MaxpatrolVM/example_csv.csv \
   vulnaware/vuln_scanners/MaxpatrolVM/vuln_import/
docker compose --profile full restart worker
docker compose logs -f worker | grep -iE "import|jira|telegram"

Expect 1 stored finding from 6 rows (CVE-2025-43859, high, CVSS 9.1). That is correct behaviour: four rows fall under the severity filter and one high row has no CVE. Use cp, not mv, because scanner.delete_after_import is true by default.

Setup order: run run_config.py on the host, generate the TLS cert with openssl, start postgres, run db init and add_user admin, then docker compose --profile full up -d. Restart the worker afterwards, since every job fires once at start before the schema exists and fails. The restart also force-retries feeds.

Set hide_assets: true in vulnaware/config.yaml to keep hostnames and IPs out of Telegram. Set mode there to choose auto dispatch or analyst-reviewed manual dispatch. Scoring is the same in both.

Caveats

• Feed states: error triggers a HOLD on dispatch; degraded (empty upstream catalog) and skipped do not, and neither gets the 30-minute fast retry because VulnCheck retries re-download archives of hundreds of MB. Degraded feeds raise a feed_degraded ops alert.
• run_config.py save rewrites config.yaml through yaml.dump and drops hand-written comments.
• Air-gapped use is possible by setting the VulnCheck download flags to false and reading local files.
• The page gives no information on scale, performance or the exact scoring formula.