Mythal
real poc plan
CSX Proof of Concept · prepared by Next-Era LLC

From simulated to real software.

CSX has seen the simulated loop. The next cut is the real one: real Linux hosts running real platform software with real, exportable vulnerabilities — scanned by a real scanner, patched by real Ansible, and re-scanned to prove the fix. No CSX systems touched. Everything stands up in our environment, resets in seconds, and runs end-to-end through the same twelve agents.

Real targets
4
Tomcat · Liberty · Log4j · OS
Real scanner
Yes
Trivy / OpenVAS
Real patcher
Ansible
their exact tool
CSX systems touched
0
our environment
Reset time
<30s
repeatable demo
Target delivery
Early next wk
per the call
The call · verbatim

What CSX asked for on today's call

The pivot

"Real software, not a simulation"

"Instead of, like earlier, we demonstrated actual simulation — instead, we have real software, and in real time how it's scanning, get the scanner, and how the patching is done, everything end-to-end."

"The exact same thing what you are doing on the OS level — we wanted to perform that on the platform level."

Four explicit constraints
ENV

In your environment, not ours

"A clean environment outside" — avoids CSX security approvals and access questions.

HOST

Linux platform software

"Any Linux platform, any version… default installation for some of our products" — Liberty, Tomcat, open-source middleware.

TOOL

Ansible for patching

"Right now, we use Ansible." Some products patch via vendor scripts.

FLOW

Scanner → assess → approve → patch → rescan

"Qualys or some scanner reports vulnerabilities… the approval process… how the patching is done, end-to-end."

The shift

Three things become real

Before → After

The findings

Was: a scenario engine minted synthetic MCR-SIM-* findings on a timer.

Now: a real scanner fingerprints real running software and reports real CVEs with real CVSS, EPSS, and KEV status.

Before → After

The patch

Was: the Executor wrote a fake play_recap after a time.sleep().

Now: the Executor runs a real ansible-playbook over SSH that actually upgrades the software on the target host.

Before → After

The proof

Was: the loop "closed" because the FSM said so.

Now: the Verifier triggers a real re-scan; the CVE is gone because the version is genuinely patched. Truth, not assertion.

The platform does not change — its inputs and outputs do The twelve agents, the signed message bus, the reasoning-trace ledger, the policy gate, the approval workflow, and the console stay exactly as they are. We swap the simulated edges (feed in, executor out) for real connectors. That is the whole POC.
The POC lab

What we stand up — all in containers, all ours

Targets · vulnerable on purpose

Real platform software

  • target-tomcat — Apache Tomcat 9.0.30 on Debian
  • target-liberty — Open Liberty (WebSphere family), older pin
  • target-log4shell — Java app bundling log4j-core 2.14
  • target-linux — stale OS packages (openssl, etc.)
  • Each: SSH-enabled, a managed node for Ansible
Scanner · the real thing

Reports real CVEs

  • scanner — Trivy engine (default): reads versions, emits FixedVersion
  • Option: Greenbone / OpenVAS — authentic network scan, Qualys-analog
  • Production path at CSX: Qualys VMDR connector
  • Output normalized to canonical VulnerabilityFinding
Mythal · unchanged core

The control plane + remediator

  • api + console — twelve agents, policy gate, console
  • ansible-control — ansible-core, playbooks, SSH keys
  • Stretch: AWX — real job-template UI & API
  • postgres · redis — already in the stack
Real vulnerable platform software Real scanner reporting real CVEs Mythal core + real Ansible — unchanged agents

One docker-compose.poc.yml overlay extends the existing stack. Targets sit on an isolated bridge network; no host other than ours is reachable. Ports chosen outside the in-use block (targets internal-only; OpenVAS UI :9392, AWX :8095 if enabled).

Choosing the vulnerabilities

Four targets, picked because the fix is real and provable

TargetPinned versionHeadline CVESevReal remediation (Ansible)Verify
Apache Tomcat
target-tomcat
9.0.30 CVE-2020-1938 "Ghostcat" — AJP file read / inclusion 9.8 Upgrade distribution to 9.0.x (fixed ≥ 9.0.31); reload service Re-scan: version now ≥ fix → finding clears
Open Liberty
target-liberty
older pin* Liberty runtime advisory (SSRF / info-disclosure class) High Bump Liberty runtime to fixed release; restart server Re-scan: runtime build ≥ fix → clears
Log4Shell app
target-log4shell
log4j-core 2.14 CVE-2021-44228 "Log4Shell" — JNDI RCE 10.0 Replace jar with 2.17.1; restart app Re-scan: jar hash/version → clears (drama: KEV + ransomware-linked)
Linux base
target-linux
stale openssl CVE-2022-0778 — BN_mod_sqrt() infinite loop (DoS) High ansible apt/dnf upgrade openssl Re-scan: package version ≥ fix → clears

*Exact Open Liberty pin and its reported CVE set are fixed at lab-build time against the live scanner output, so we present only what the scanner genuinely reports — no claimed CVE we can't show on screen.

"Qualys or some scanner"

The real scanner — and why Trivy carries the demo

Demo engine · default

Trivy

Fingerprints the running middleware and OS packages, maps to CVEs with CVSS/severity, and — critically — emits a FixedVersion per finding.

Deterministic, fast, repeatable. The same scan returns the same findings every demo. That reliability is what wins the room.

Hero shot · optional

Greenbone / OpenVAS

A true authenticated network vulnerability scanner — the closest open-source analog to Qualys. Same shape of output, more "scanner theater," heavier and slower.

We wire it as a second connector for buyers who want to watch a network scan run.

Production · at CSX

Qualys VMDR

In a real deployment Mythal reads CSX's existing Qualys. The connector is the same shape — trigger / poll / normalize — so the POC connector and the production connector are interchangeable.

The detail that makes the whole loop real Trivy's FixedVersion field feeds two agents at once: the Patch Hunter reports the fix without guessing, and the Executor's Ansible playbook gets its exact target version from the same field. The fix the scanner names is the fix Ansible installs — closed, grounded, no hand-waving.
"Right now, we use Ansible"

Real patching — the Executor runs real playbooks

How it works

The Executor agent stops simulating. On an approved plan it invokes a real ansible-playbook from the ansible-control container against the target over SSH. The play's real play_recap (ok/changed/failed) lands in the executions row and streams to the console plan-detail page exactly as today.

One playbook per software class — Tomcat upgrade, Liberty bump, jar swap, OS package update — parameterized by the FixedVersion the scanner reported.

Same Execution rows · same streaming UI · real stdout
# remediate_tomcat.yml — driven by scanner's FixedVersion - hosts: target-tomcat become: true vars: fixed_version: "{{ scanner_fixed_version }}" tasks: - name: Snapshot current build # rollback point shell: cp -a /opt/tomcat /opt/tomcat.bak - name: Fetch + unpack fixed Tomcat unarchive: src: "…/apache-tomcat-{{ fixed_version }}.tar.gz" remote_src: true dest: /opt/ - name: Swap symlink + restart shell: ln -sfn /opt/apache-tomcat-{{ fixed_version }} /opt/tomcat notify: restart tomcat handlers: - name: restart tomcat service: { name: tomcat, state: restarted }

Stretch: route through AWX (open-source Ansible Automation Platform) so the Integrations screen shows a real job-template launch and the Executor calls the AWX REST API — the same pattern CSX would use with Ansible Automation Platform in production.

End to end

The real closed loop, agent by agent

01
Scan
Trivy scans targets → real CVEs
02
Ingest
Scanner Liaison normalizes findings
03
Enrich
Threat Intel: live NVD + CISA KEV + EPSS
04
Fix
Patch Hunter reads FixedVersion
05
Plan
Impact · Change Risk · Planner build runbook
06
Approve
Policy gate → human approval
07
Patch
Executor runs real ansible-playbook
08
Verify
Verifier re-scans → CVE gone → CLOSED
What CSX watches

On the console, every step above appears in real time on the Agent Activity timeline and the plan Kanban — the same audit theatre as today, now backed by real scanner JSON and real Ansible recaps.

The honest moment

Between step 07 and 08 the version on the box genuinely changes. The re-scan is not staged — it queries the same Trivy engine and the finding is simply no longer there.

Reset

make poc-reset tears the targets back to their vulnerable pin and clears Mythal state in under 30 seconds. Run the whole loop again, live, on demand.

What we build

Real connectors replace four simulated edges

EdgeToday (simulated)POC (real)Where
Scanner inscenario engine mints MCR-SIM-*ScannerConnector: trigger Trivy/OpenVAS, parse JSON, call ingest_finding() with real CVEspackages/connectors/scanner/ + routes/scan.py
Patch lookupstatic fix stringsPatch Hunter consumes scanner FixedVersion; OS feeds for distro packagesagents/patch_hunter/
Executor outtime.sleep() + fake recapAnsibleExecutor: real ansible-playbook (or AWX API), real recap into executionsagents/executor/ + connectors/ansible/
Integrations healthhardcoded _INTEGRATIONS listlive probes: scanner reachable, Ansible reachable, NVD/KEV reachable, targets uproutes/integrations.py
Threat Intel goes live too Enrichment already references NVD / CISA KEV. For the POC we confirm those calls hit the real public feeds so EPSS, KEV membership, and ransomware-actor association on screen are genuine for the real CVEs (Log4Shell and Ghostcat are both KEV-listed — that lands well).
"Admin screen integrations should be real"

The Integrations screen stops lying

Today

The Integrations page renders a fixed list of twenty-two connectors with "status":"healthy" baked in. Impressive breadth, but none of it is probed.

For an investor flyover that's fine. For a CISO POC, a fabricated health light is a credibility risk the moment someone asks "is that real?"

POC

Each connector in scope reports actual health from a real probe:

  • Scanner — last scan job id, timestamp, finding count
  • Ansible / AWX — control node reachable, last job status
  • NVD & CISA KEV — last successful fetch + HTTP status
  • Targets — SSH reachability per managed node

Connectors we haven't wired stay clearly marked not_configured — honest beats impressive.

!
Label discipline carries over Simulated breadth (Claroty, Nozomi, Dragos, Panorama, the rail OT estate) stays in the product story but is tagged SIMULATED in the UI, exactly as the build tenets require. The POC makes the IT/platform path real without pretending the entire fabric is wired.
In the room

Three real scenarios to walk CSX through

Scenario 1 · the headline

Ghostcat on Tomcat

Run the scan live. CVE-2020-1938 lands on target-tomcat, KEV-listed, CVSS 9.8. Agents enrich, plan, you approve, Ansible upgrades Tomcat, re-scan clears it. ~3–4 min, fully real.

Scenario 2 · the drama

Log4Shell fast-track

CVE-2021-44228, CVSS 10.0, ransomware-linked in KEV. Show the platform reprioritize, fast-track approval, swap the jar, and verify. The CVE everyone in the room already fears.

Scenario 3 · the platform

Liberty + OS package

The WebSphere-family story CSX named. Liberty runtime bump and an openssl OS update via Ansible — two more real loops, proving it's a pattern, not a one-off trick.

One control surface Each scenario is launchable from the console and resets in seconds — so CSX can ask "run Ghostcat again" and watch the entire real loop a second time without a reset script in a terminal.
Build plan

Five days to a real end-to-end loop

DAY 1

Lab targets up

Author docker-compose.poc.yml: four vulnerable target containers (Tomcat 9.0.30, Open Liberty, Log4Shell app, stale-OS Linux), SSH-enabled, isolated bridge network. Confirm each boots and is reachable.

DAY 2

Real scanner wired

Stand up Trivy as a scan service; build ScannerConnector + /api/scan/run; parse JSON into real VulnerabilityFinding events. Findings appear on the console for real software. (OpenVAS as time permits.)

DAY 3

Real Ansible patching

ansible-control container + four playbooks parameterized by FixedVersion. Rewire the Executor to run real plays. Confirm a patch actually upgrades a target.

DAY 4

Close the loop + live integrations

Verifier triggers real re-scan; finding clears; FSM reaches CLOSED on truth. Replace Integrations health with live probes. Wire the three scenarios + make poc-reset.

DAY 5

Rehearse + harden

Dry-run all three scenarios end-to-end, tune timings, confirm sub-30s reset, write the demo runbook addendum. Ship to CSX.

AWX and OpenVAS are stretch items layered after the core loop is green — they raise production fidelity but are not on the critical path to "real end-to-end."

Holding the quality bar

Real software, still safe and repeatable

Isolation

Air-gapped lab

Targets live on a private bridge network. Nothing routes to CSX. Vulnerable containers expose no ports to the host beyond what the demo needs.

Repeatability

Deterministic

Pinned image digests + Trivy's stable DB snapshot mean the same findings every run. No flaky live-internet dependency in the hot path.

Reversibility

Snapshot + reset

Every playbook snapshots before it changes anything. make poc-reset restores the vulnerable baseline in seconds.

Trust

Injection defense on

Scanner output and advisory text stay untrusted input — wrapped and classified, never executed as instructions. The existing prompt-injection harness still applies.

!
Honest framing for the room This is a lab POC, not a CSX production integration. We say so plainly. The value it proves: the loop is real, the scanner is real, the patch is real, the verification is real — and the exact same connectors point at CSX's Qualys and Ansible Automation Platform when they're ready to pilot inside their estate.
Next decisions

What we'd confirm before Day 1

Decision 1

Scanner emphasis

Lead with Trivy for reliability, or invest the extra day in OpenVAS for the authentic "watch a network scan" moment? Recommended: Trivy core, OpenVAS as stretch.

Decision 2

Ansible surface

Bare ansible-core (fast, real) or AWX (production-grade UI/API, +1 day)? Recommended: ansible-core for the loop, AWX if CSX wants to see the platform.

Decision 3

Fourth target

Keep Log4Shell as the drama scenario, or swap for another CSX-named product if one is available open-source? Recommended: keep Log4Shell — it's KEV, it's CVSS 10, it lands.

The commitment on the call was "early next week, end-to-end." This plan delivers exactly that: a real scanner finding real vulnerabilities in real platform software, remediated by real Ansible, and proven by a real re-scan — all in our environment, all repeatable, all on the same Mythal console CSX already saw.