What it is
REDGuard is a vulnerability-remediation engine I built to turn raw scanner output into prioritized, plain-language, owner-routed remediation work — with a full audit trail behind every decision. It's in pilot now, and strictly defensive by design: it ranks, explains, drafts tickets, and routes for approval. It never exploits, never scans without authorization, and never takes direct action on a system.
- Ingests scanner findings (Tenable/Qualys-style exports), normalizes them to a common asset/finding/ticket schema, and enriches them with threat intelligence (CISA KEV, EPSS, NVD).
- Prioritizes with deterministic, reproducible scoring rather than a raw severity-sort — so a known-exploited, internet-facing issue on a critical asset outranks an isolated lab "critical."
- Explains itself: every item comes with a plain-language reason for where it ranks, plus an evidence-backed audit trail for every score and drafted action.
- Multi-tenant by design: one shared engine serves many customer environments, each defined entirely by configuration — onboarding a new enterprise is config, not code.
The security boundary
The design keeps a hard line between what reasons and what acts. The AI layer orchestrates, groups, and explains in plain language; the backend enforces what is actually allowed to happen — read-only by default, with any write-back (to Jira, ServiceNow, or the scanner) sitting behind an explicit approval gate. The AI is never the security boundary, and it never does the risk math — that stays deterministic and auditable.
Why it matters
Security teams drown in scanner output and burn time arguing over what to fix first. REDGuard is my answer to that: a reproducible way to rank by real-world risk, explain the ranking to the people who have to act on it, and prove every decision after the fact — without ever handing an autonomous system the keys to change production on its own.