Case study

ResearchCybersecurity

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
ArchitectureView EvidenceNextOpen GitHubView CVContact

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.

NextContext reviewed

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

prototype
ONOSFastAPIMininetdecisions.csv

simulated traffic

Mininet

Repeatable Mininet traffic.

packet_in -> policy_api -> decision_log
NextArchitecture understood

What the project was built with.

Implementation

ONOSJavaFastAPIMininetOpenFlowscikit-learn
NextImplementation reviewed

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.

NextDecision logic reviewed

What exists now and what is still pending.

Evidence

Evidence tracked in Git

Missing assets stay clearly marked.

todo

ONOS logs placeholder

Add PacketIn or controller log capture from the local testbed.

todo

FastAPI decision response placeholder

Add a structured allow/block API response example.

todo

Mininet topology placeholder

Add a topology screenshot or CLI capture.

todo

decisions.csv placeholder

Add logged experiment rows once available.

todo

model metrics placeholder

Add baseline model metrics and evaluation notes.

todo

architecture diagram placeholder

Add the final architecture diagram.

todo

demo video placeholder

Add a short walkthrough when recorded.

NextEvidence inspected

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.
NextReality check reviewed

What I would improve next.

Roadmap

  1. Step 1

    Proper ONOS .oar packaging: Package the controller app cleanly for repeatable local setup.

  2. Step 2

    ML model registry and versioning: Track scoring model versions used in experiments.

  3. Step 3

    PostgreSQL-backed vulnerability intelligence store: Move vulnerability intelligence out of temporary files.

  4. Step 4

    Redis cache for low-latency decisions: Reduce repeated policy API lookup cost.

  5. Step 5

    Transformer-based CVE description model: Future text model work after classical baselines.

  6. Step 6

    Graph-based network topology risk model: Test topology-aware scoring.

  7. Step 7

    SOC-style dashboard: Visualise decisions, scores, and experiment outputs.

  8. Step 8

    Human approval workflow for high-risk decisions: Keep high-risk enforcement reviewable.

NextRoadmap reviewed

Why this work matters for engineering roles.

Employment relevance

The work touches controllers, APIs, datasets, logs, and tests.

NextCase study completed

Next action

That is the main path.

You can check the CV, GitHub, or the local Black Ice view next.

View CVOpen GitHubContinue in Black Ice

Connect

Let's connect

I am looking for graduate and junior opportunities in cybersecurity, machine learning, secure software engineering, and network/security research.