Architecture

driftmux is built as a small pipeline.

The main stages are:

1. service discovery;

2. parsing and normalization;

3. passive enrichment;

4. scan planning;

5. active checks;

6. reporting.

Pipeline overview

Host
 |
 v
NmapScanner
 |
 v
NmapXmlParser
 |
 v
HostScanResult
 |
 +--> NVD enrichment
 |
 +--> ScanPlan
        |
        +--> Nuclei targets
        +--> WordPress targets
 |
 v
Final report

Models

The central model is HostScanResult. It contains:

• discovered services;

• findings;

• tool errors;

• metadata.

Open ports are represented as normalized service objects. They can include:

• port;

• protocol;

• state;

• service name;

• product;

• version;

• extra information;

• tunnel;

• CPEs;

• classifications.

Planner

The planner decides which tools should run against which services.

It receives:

• the host;

• discovered services;

• passive findings;

• selected scheme;

• scan profile.

It returns a ScanPlan containing:

• Nuclei targets;

• WordPress targets;

• passive-only status.

Nuclei integration

Nuclei execution is target-based.

Instead of launching the whole template catalog against every service, driftmux groups targets by tags and runs focused template categories.

This keeps scans easier to reason about and reduces unnecessary noise.

NVD enrichment

NVD enrichment works best when Nmap provides product, version or CPE evidence.

When Nmap only returns tcpwrapped or unknown services, driftmux may still report the exposed service, but there may be no reliable vulnerability match.

This is expected:

80/tcp open tcpwrapped

is not enough to infer a specific vulnerable product such as Apache, Nginx, Tomcat or OpenSSH.