Sangamesh.Dandin
Résumé
All projects

Case 07 / 09Vulnerability managementCompleted

PREDICTIVE PATCH SCHEDULER.

Patch scheduling from rule-based and ML risk scores.

A FastAPI app that turns vulnerability records (entered by hand, uploaded as CSV or JSON, or generated as sample data) into a patch schedule. A deterministic rule scores risk from CVSS, exploit availability and system criticality. An optional ML path (Random Forest for risk, Gradient Boosting for priority) is trained on synthetic data labelled by the same rule, so it approximates the rule rather than replacing it. Priority sets the patch window, from 24 hours for critical to 14 days for low, and a dashboard shows Plotly analytics with WebSocket alerts.

Problem
Patch prioritisation
Built with
FastAPI, scikit-learn
Result
Priority-based schedule
  • Python
  • FastAPI
  • scikit-learn
  • SQLite
  • Plotly
  • WebSockets

▶Demo

See it work.

An animated walkthrough of the interface, not a screen recording. The systems, CVEs and scores shown are example values. The video uses the app's own name, PatchGuard.

01Architecture

How it's built.

Drawn from the project's source code, not its README: what each part actually does and how a request moves through it.

Predictive Patch Scheduler risk-to-schedule map A vulnerability record from manual entry, CSV or a sample generator is scored two ways in parallel: a deterministic rule computes a risk score and priority from CVSS, exploit availability and system criticality, and a Random Forest plus Gradient Boosting model predicts a risk score and priority from seven features; the models are trained on synthetic data whose labels come from the same rule formula, so the two paths largely agree. Both feed a priority-only schedule-time function, results are stored in SQLite with status always pending, and analytics, real-time alerts and the pending-patch view read from the database. No patch is ever applied. RULE PATH · DETERMINISTIC ML PATH · LEARNS THE RULE CONVERGENCE + STORAGE INPUTS RECORD RISK + PRIORITY 7 FEAT VERDICT TRAIN ×1000 TRAINING TARGETS = RULE FORMULA + NOISE WRITE QUERY Vulnerability record 9 fields, operator-supplied cvss_score · exploit_available system_criticality · usage cve_id · patch_id · system_id description · last_seen sources manual JSON · CSV / JSON file sample generator (fake data) no auth · CORS * no real CVE / NVD feed CVSS is an input, not a confirmed-exploit signal RULE risk_calculator.py risk = cvss (+2 if exploit) × 1.3 / 1.0 / 0.7 by crit · cap 10 priority: cvss≥8 or exploit → critical; ≥6 high; ≥4 med; else low FEATURES L1 prepare_features 7 features: cvss, exploit, days_since_seen, 2 encoded categoricals, 2 interactions (cvss×exploit, crit×cvss) SCIKIT-LEARN ML models RandomForestRegressor → ml_risk_score GradientBoostingClassifier → ml_priority + confidence SYNTHETIC Training data 1,000 random rows · labels from the rule formula + noise SHARED calculate_scheduled_time one input only: the priority criticalnow + 24 h high+3 d · 02:00 medium+7 d · 02:00 low+14 d · 02:00 usage pattern & dependencies are stored but never used here STORE L2 SQLite · patches.db vulnerabilities (9 cols) scheduled_patches: risk_score, scheduled_time, status status is always “pending” READ Read side · FastAPI + static-JS frontend · reads stored rule risk_score Analytics 6 Plotly charts: risk, timeline, heatmap, CVSS… Real-time WebSocket threshold alerts (advisory text) Pending patches table view · no patch is ever applied The model is trained on the rule’s own output, so ML risk ≈ rule risk — it learns, it doesn’t add signal. VERIFIED LIMITS · FOUND IN CODE, NOT STATED IN THE README L1 At inference, LabelEncoder orders categories alphabetically (high, low, medium), but training coded them high, medium, low — so “medium” and “low” are swapped. L2 No patch is ever applied. status stays “pending”; nothing is deployed, updated or marked complete. Auth libs (jose, passlib, bcrypt) are listed but never imported. LEGEND Input source Code component ML / shared schedule Store / synthetic data Input (HTTP) Data flow ML targets come from the rule L1 Verified limit

Read from the code at commit 2be5d9e · Open full size ↗

02Under the hood

How it works.

  1. 01

    Input

    Records from a form, a CSV or JSON upload, or sample data

  2. 02

    Rule score

    CVSS, exploit availability and system criticality

  3. 03

    ML score

    Random Forest for risk, Gradient Boosting for priority

  4. 04

    Schedule

    Critical in 24 h, high in 3 days, medium in 7, low in 14

→Up next · 08 / 09

Next project.

VulnXploit Scanner — A small web front end for nmap service scans.

Back to all projects