Status: Portfolio Project | Risk-Based Vulnerability Management | Security Automation
This project demonstrates how I would operate a risk-based vulnerability management workflow that moves beyond scanner severity alone.
The Vulnerability Operations Center converts sanitized scanner findings into an explainable remediation queue by combining CVSS, EPSS, VPR, CISA Known Exploited Vulnerabilities, exploit availability, internet exposure, and asset criticality. It also tracks remediation decisions, preserves an audit trail, and generates reporting for technical and executive audiences.
The demonstration uses 40 sanitized synthetic findings. It contains no employer data, credentials, or live scanner output.
Vulnerability teams often face more findings than they can remediate at once. Scanner severity does not always explain:
- Which vulnerability should be addressed first
- Whether exploitation is active or likely
- Whether the affected asset is internet-facing or business-critical
- Who owns the remediation
- What decision was made and why
- Whether leadership and auditors can verify the workflow later
This project models a structured process for turning vulnerability data into defensible remediation decisions.
The portfolio demonstration includes:
- Risk-based prioritization using CVSS, EPSS, VPR, CISA KEV, exploit availability, exposure, and asset criticality
- A searchable vulnerability inventory with filters, ownership, due dates, and remediation guidance
- Finding-level evidence showing why each vulnerability received its priority score
- A remediation queue with draft, approved, rejected, and reset states
- Reviewer notes and persistent workflow decisions
- An evidence-constrained AI analyst grounded in the current synthetic findings
- Executive and technical PDF reporting
- Complete finding, remediation, and audit CSV exports
- A workflow audit log that preserves approval and rejection events
- Vulnerability and asset findings are normalized into a consistent data model.
- A deterministic scoring policy evaluates technical severity, exploitation likelihood, active exploitation, exposure, and asset context.
- Findings are ranked into a prioritized remediation queue with defined SLA targets.
- An analyst reviews the evidence and records an approval, rejection, or reset decision.
- The workflow preserves reviewer notes, timestamps, and audit events.
- Reporting packages provide both leadership summaries and technical evidence.
The overview provides exposure metrics, severity distribution, risk trends, prioritization evidence, and the highest-priority remediation items.
The vulnerability inventory supports search, filters, sorting, ownership context, remediation due dates, and finding-level evidence. The selected example shows how the score is supported by CVSS, EPSS, CISA KEV, internet exposure, and asset criticality.
The remediation queue tracks draft and completed decisions. Analysts can document context, approve or reject a remediation draft, reset the decision, and preserve the result for later review.
The AI analyst is grounded in the sanitized findings loaded into the demonstration. It provides remediation guidance based on the available evidence rather than inventing unsupported environment details.
The reporting workflow creates one synchronized evidence package containing:
- Executive Risk Report PDF
- Technical Evidence Report PDF
- Full Finding Inventory CSV
- Remediation Queue CSV
- Workflow Audit Log CSV
The audit log preserves remediation decisions, reviewer notes, timestamps, and workflow events so the prioritization and remediation process can be reviewed later.
- Vulnerability Management
- Risk-Based Vulnerability Management
- Vulnerability Prioritization and Remediation
- Exposure Management
- CVE, CVSS, EPSS, VPR, and CISA KEV
- Tenable-style vulnerability data
- Security Automation
- Python and FastAPI
- Next.js and TypeScript
- SQLite workflow persistence
- Audit Logging
- Executive and Technical Reporting
- LLM input controls and evidence grounding
This is a portfolio implementation of a vulnerability management operating workflow. It is not presented as an enterprise production deployment or a replacement for commercial scanners, ticketing platforms, identity systems, or distributed data infrastructure.
- All included findings and assets are synthetic
- No credentials or employer information are included
- External Jira and ServiceNow ticket creation is disabled
- Demonstration decisions are stored locally
- AI responses in demo mode are deterministic and credential-free
How would you balance technical severity, exploitation likelihood, asset criticality, and operational constraints when deciding what to remediate first?