Case study
VulnGuard SDN
ONOS and FastAPI prototype for risk-aware network decisions.
VulnGuard SDN connects controller events to a policy API in a controlled SDN lab.
At a glance
VulnGuard SDN
ONOS and FastAPI prototype for risk-aware network decisions.
- Why it matters
- It connects controller signals to a network decision path.
- My role
- Research prototype developer
- Stack / tools
- ONOS, Java, FastAPI, Mininet, OpenFlow, scikit-learn
- Status
- Research
- Estimated read
- 6-8 minutes
Role
Research prototype developer
Stack
ONOS, FastAPI, Mininet, scikit-learn
Status
Controlled lab prototype
Evidence
logs, API output, CSV rows
What problem this project tries to solve and where the evidence starts.
Context
Controlled SDN lab
The project keeps scoring outside the controller and records the result.
Logs, API output, Mininet tests.
How PacketIn metadata becomes a policy decision.
Architecture
Mininet to decision logs
ONOS handles the controller path. FastAPI handles the policy decision.
01 · testbed: mininet traffic generated
Traffic enters Mininet/OVS
Repeatable lab traffic enters the SDN path.
02 · packet_in: tcp metadata observed
ONOS receives PacketIn events
ONOS reads PacketIn metadata from the lab.
03 · vulnguard: metadata forwarded
VulnGuard prepares metadata
The controller app builds a policy request.
04 · policy_api: request accepted
FastAPI evaluates the request
The policy API returns a structured decision.
05 · scorer: risk compared with threshold
Scorer checks risk logic
Rules and ML baselines support risk scoring.
06 · decision: allow/block returned
Decision is returned
The result returns through the controller path.
07 · log: decisions.csv updated
Output is logged
Outputs are stored as logs and CSV rows.
vulnguard / system-map
simulated traffic
Mininet
Repeatable Mininet traffic.
Add PacketIn or controller log capture from the local testbed.
todologFastAPI decision response placeholderAdd a structured allow/block API response example.
todoscreenshotMininet topology placeholderAdd a topology screenshot or CLI capture.
todoWhat the project was built with.
Implementation
Machine learning layer
What metrics exist and what is still missing.
Decision output
pending
Add measured decision counts after experiments are logged.
Model metrics
pending
Add baseline evaluation results when available.
What exists now and what is still pending.
Evidence
Evidence tracked in Git
Missing assets stay clearly marked.
ONOS logs placeholder
Add PacketIn or controller log capture from the local testbed.
FastAPI decision response placeholder
Add a structured allow/block API response example.
Mininet topology placeholder
Add a topology screenshot or CLI capture.
decisions.csv placeholder
Add logged experiment rows once available.
model metrics placeholder
Add baseline model metrics and evaluation notes.
architecture diagram placeholder
Add the final architecture diagram.
demo video placeholder
Add a short walkthrough when recorded.
What works now and what still needs work.
Reality check
What works now
- ONOS connects to Mininet/OVS in a controlled lab.
- FastAPI policy service returns structured decisions.
- Decision logging records experiment output.
- Classical ML scoring layer is planned or partially integrated depending on the current repo state.
What is simulated
- Traffic is from a local Mininet testbed.
- Vulnerability/service mapping is controlled.
- Enforcement is evaluated under research conditions.
What still needs improvement
- Production-grade ONOS packaging.
- Model registry and versioning.
- Caching for low-latency policy decisions.
- Larger experiment set.
- Dashboard and human approval workflow.
What I would improve next.
Roadmap
- Step 1
Proper ONOS .oar packaging: Package the controller app cleanly for repeatable local setup.
- Step 2
ML model registry and versioning: Track scoring model versions used in experiments.
- Step 3
PostgreSQL-backed vulnerability intelligence store: Move vulnerability intelligence out of temporary files.
- Step 4
Redis cache for low-latency decisions: Reduce repeated policy API lookup cost.
- Step 5
Transformer-based CVE description model: Future text model work after classical baselines.
- Step 6
Graph-based network topology risk model: Test topology-aware scoring.
- Step 7
SOC-style dashboard: Visualise decisions, scores, and experiment outputs.
- Step 8
Human approval workflow for high-risk decisions: Keep high-risk enforcement reviewable.
Why this work matters for engineering roles.
Employment relevance
The work touches controllers, APIs, datasets, logs, and tests.
Next action
That is the main path.
You can check the CV, GitHub, or the local Black Ice view next.
Connect
Let's connect
I am looking for graduate and junior opportunities in cybersecurity, machine learning, secure software engineering, and network/security research.