How do I install Cerno?

Copy the stdio config for Cursor, Claude Desktop, Claude Code, or VS Code on this page. It uses the publisher's install, not a PlugMCP proxy.

Does Cerno need an API key?

No required environment variable is listed on this record.

When was Cerno last checked?

Last checked 2026-10-28. TUI for triaging Nessus findings: import .nessus into SQLite, launch nmap/NetExec against affected hosts, track review progress across scans, and drive it all from an MCP client.

Cerno MCP sunucusu

Cerno

A TUI tool for reviewing Nessus scan findings and orchestrating security tools (nmap, NetExec, custom commands). Import .nessus files into a SQLite database for organized, persistent vulnerability verification and exploitation.

Key capabilities:

🔍 Interactive TUI for browsing/reviewing vulnerability findings — triage hundreds of findings fast
💾 SQLite-backed persistence — never lose review progress; track risk across scans
⚡ One-command tool launches (nmap NSE scripts, NetExec, custom workflows) — no retyping targets
📊 CVE extraction, Metasploit module search, host comparison — go from finding to exploit path
🔗 NetExec database integration — see where your credentials already work
🤖 Claude Assistant — on-demand AI second opinion without leaving the TUI
🔀 Proxychains4 integration — route every tool through your pivot with one toggle
🔌 MCP server — drive an engagement from any MCP client (Claude CLI, etc.)

📺 Watch the demo:

Quick Start
How It Works
Installation
Configuration
Features
Commands
MCP Server (BETA)
Keyboard Shortcuts
Custom Workflows
Troubleshooting
Documentation
Releases
Contributing
About the Name
License

Quick Start

# Install with pipx (recommended)
pipx install git+https://github.com/ridgebackinfosec/cerno.git

# Import a Nessus scan
cerno import nessus scan.nessus

# Review findings interactively
cerno review

That's it! See Commands for more.

No Nessus file handy? Use the synthetic demo scan included in this repo:

cerno demo
cerno review

The demo fixture uses documentation-only IP ranges and `.example` hostnames. See docs/demo for details.

How It Works

Cerno turns a raw Nessus export into a tracked, actionable verification workflow:

Import — parse one or more .nessus files into a local SQLite database (~/.cerno/cerno.db).
Review — browse findings in an interactive TUI: filter by severity, host, and exploitability; inspect plugin detail, CVEs, and affected host:ports.
Act — launch nmap / NetExec / Metasploit / custom commands against the exact hosts and ports of a finding, with execution and artifacts logged automatically.
Track — review state, sessions, and tool history persist in the database, so progress survives restarts and you can compare a host's risk across scans.

The same database and tooling are also exposed over the Model Context Protocol, so an MCP client (e.g. Claude CLI) can query findings and generate commands programmatically.

Installation

Requirements:

Python 3.11+ on Linux, macOS, or Windows (Linux recommended)
Optional tools (only if you use them): nmap, nxc/netexec, msfconsole, claude
Clipboard support on Linux: xclip, xsel, or wl-copy

Recommended (pipx):

pipx install git+https://github.com/ridgebackinfosec/cerno.git
cerno --help

Alternative (pip):

pip install git+https://github.com/ridgebackinfosec/cerno.git

Development:

git clone https://github.com/ridgebackinfosec/cerno.git
cd cerno
pip install -e ".[dev]"

Shell completion:

cerno --install-completion  # Enable tab completion for your shell

Configuration

Configuration file (~/.cerno/config.yaml):

Auto-created with defaults on first run. All settings managed via config file.

cerno config show                    # View all settings with current values
cerno config get <key>               # Get a single config value
cerno config set <key> <value>       # Change a setting
cerno config reset <key>             # Reset one setting to its default
cerno config reset                   # Reset to defaults (creates backup)

Terminal colors: colors are tuned for a light (white) terminal background by default. On a dark terminal, switch to the classic palette:

cerno config set color_scheme dark    # light (default) | dark

Proxychains4 proxy settings:

cerno config set proxychains_enabled true        # Route tools through proxychains4 (default: false)
cerno config set proxychains_host 127.0.0.1      # proxychains4 SOCKS5 proxy host
cerno config set proxychains_port 9000           # proxychains4 SOCKS5 proxy port (matches ssh -D default)

All settings (cerno config show prints the same list with current values):

Key	Default	Purpose
General / UI
`results_root`	`~/.cerno/artifacts`	Where tool output and artifacts are written
`log_path`	`~/.cerno/cerno.log`	Log file location
`debug_logging`	`false`	Log at DEBUG level
`default_page_size`	auto (terminal height)	Rows per page in lists (min 8); also the MCP default `limit`
`top_ports_count`	`5`	Top ports shown in the scan overview (capped at 100)
`color_scheme`	`light`	Terminal background the colors are tuned for: `light` or `dark`
`no_color`	`false`	Disable ANSI colors
`term_override`	unset	Force a terminal type (`dumb` disables colors)
Tools & workflows
`default_tool`	unset	Pre-select a tool in the Run Tool menu (`nmap`, `netexec`, `metasploit`, `custom`)
`default_netexec_protocol`	unset (`smb`)	Default NetExec protocol
`nmap_default_profile`	unset	Default NSE profile name
`custom_workflows_path`	unset	Custom workflows YAML merged over the bundled ones (TUI default and MCP)
NetExec
`nxc_workspace_path`	`~/.nxc/workspaces/default`	NetExec workspace to read (`""` disables)
`nxc_enrichment_enabled`

List keys take CSV: `cerno config set mcp_exec_allowlist "nmap,nxc"`.

Features

🔍 Interactive TUI for browsing/reviewing vulnerability findings

Triage hundreds of findings fast — see what matters without scrolling through raw Nessus exports.

Rich tables with paged views, keyboard-driven navigation, and real-time filtering. Key capabilities:

Browse by severity, preview plugin details, clipboard copy
Grouped view (host:port,port) or raw file view
Multi-select operations, reversible review states

📊 Intelligence & Research

Go from a finding to an exploitation path without context-switching — CVEs, Metasploit modules, and host overlap in one place.

Extract CVEs, search Metasploit modules, and compare findings across hosts. Features:

CVE extraction - CVEs imported from .nessus file (press [E])
Metasploit search - Find relevant modules by CVE/description
Workflow mappings - Plugin-specific verification/exploitation steps (press [W])
Host comparison - Compare findings across hosts to find identical combinations and superset relationships

🤖 Claude Assistant

Get a second opinion on exploitability without leaving your review or copying scan data elsewhere.

Ask Claude questions about findings without leaving the TUI. Powered by the claude CLI (claude -p) — no API key required, no data sent to external services beyond what claude itself handles.

Three scopes:

Finding level — press [A] inside a finding detail view to discuss that specific plugin: CVEs, CVSS context, exploitability, verification steps
Severity menu — press [A] at the severity selection screen to discuss all findings across the selected scan(s)
Findings list — press [A] in the findings list footer to discuss the current set of findings (respects any active severity, name, or group filter)

Conversation persistence: History is saved per-scope in SQLite and resumed automatically on re-entry. Inside the chat, Enter adds a new line, Alt+Enter (or Ctrl+J) sends, /clear clears history for the current scope, and Ctrl+C goes back.

Setup:

# Install Claude Code CLI (required)
npm install -g @anthropic-ai/claude-code   # or follow https://claude.ai/code

# Opt in (off by default). You can also just press [A] in review and confirm the prompt.
cerno config set claude_assistant_enabled true

Opt-in (default off): the assistant sends finding names, plugin metadata, affected hosts, ports, CVEs, workflow steps, and Nessus plugin output to the local claude CLI. Because that is sensitive engagement data, it is disabled by default. The first time you press [A] with claude installed, Cerno shows a data-path disclosure and, on confirmation, enables and remembers the choice. Enable it only if your engagement rules allow that data path.

Tool availability: [A] is hidden only when claude is not on PATH. When installed but not yet enabled, [A] is shown and triggers the one-time opt-in prompt.

Note: Responses may be inaccurate — always verify before acting on suggestions.

🔗 NetExec Database Integration

Instantly see where your credentials already work, so you prioritize provable risk over theoretical findings.

Automatically enrich finding displays with data from your NetExec databases—see which credentials work on affected hosts, share access, and security misconfigurations.

Features:

Credential correlation - Shows which NetExec-discovered credentials have access to affected hosts
Share access - Displays SMB share read/write permissions across hosts
Security flags - Highlights SMB signing disabled, Zerologon, PetitPotam vulnerabilities
Per-host breakdown - Press [N] in finding view for detailed per-host NetExec context

Configuration:

# NetExec workspace auto-detected at ~/.nxc/workspaces/default/
cerno config set nxc_workspace_path ~/.nxc/workspaces/client_a  # Custom workspace
cerno config set nxc_enrichment_enabled false                    # Disable feature

Supported protocols: SMB, SSH, LDAP, MSSQL, RDP, WinRM, FTP, NFS, VNC, WMI

Note: NetExec databases are read in read-only mode; Cerno never modifies them.

⚡ One-command tool launches

Skip retyping targets — launch the right tool against the exact hosts and ports of a finding.

Launch nmap NSE scripts, NetExec, Metasploit, or custom commands with placeholder substitution. Features:

Launch nmap (NSE profiles, UDP), NetExec, or custom commands
Placeholder substitution for flexible templating
Execution logging & artifact tracking

✅ Verification results & verdicts

Record what you actually proved, not just what Nessus claimed.

Tool runs from the TUI and the MCP server are logged and attributed to their finding.
Any logged nmap run (open ports, NSE vuln verdicts) or NetExec run, including TUI runs, can be ingested into structured results with the MCP ingest_results tool. MCP runs are ingested automatically when mutations are enabled.
Verdicts (confirmed / false_positive / unable) are recorded with evidence, separately from review status.
cerno creds list shows NetExec credential refs without secrets; cerno creds reveal <ref> prints one cleartext secret (audited).

Verdicts, ingestion and batch runs are driven through the MCP server.

💾 SQLite-backed persistence

Never lose review progress, and see how a host's risk profile changes over time.

Session Management:

Auto-save/resume interrupted reviews
Finding status: Unreviewed → In Progress → Done, moved with [M]; the Done list's [M] moves findings back to Unreviewed
Session statistics (duration, per-severity breakdown)

Database: SQLite-backed persistence at ~/.cerno/cerno.db tracks scans, findings, sessions, tool executions, and artifacts. Cross-scan tracking enables host history queries. See docs/DATABASE.md for schema details.

🔀 Proxychains4 Integration

Run every tool through your pivot with a single toggle — no per-command proxy fiddling.

Route all tool executions (nmap, NetExec, Metasploit, custom commands) through a SOCKS5 proxy via proxychains4 (proxychains-ng). Designed for use with an SSH -D tunnel. Cerno always invokes the proxychains4 binary; the proxychains_* config key names are kept for compatibility and configure proxychains4.

Enable in config (persists across sessions):

cerno config set proxychains_enabled true        # Route tools through proxychains4
cerno config set proxychains_host 127.0.0.1      # proxychains4 SOCKS5 proxy host
cerno config set proxychains_port 9000           # Matches: ssh -D 9000 user@host

Or override per session:

cerno review --proxy      # Force-enable proxychains4 routing for this session
cerno review --no-proxy   # Force-disable proxychains4 routing for this session

Behavior when active:

[PROXY] badge (magenta) shown in the review session status line
proxychains4 row appears in the startup tool availability table with the detected proxychains-ng version (e.g. v4.17 · SOCKS5 127.0.0.1:9000 (active))
Tools run as proxychains4 -q (quiet) so per-connection chatter doesn't clutter the terminal; a magenta [PROXY] proxychains4 → SOCKS5 host:port line and a Running via proxychains4 spinner confirm routing
Set cerno config set debug_logging true to see full proxychains4 output when troubleshooting a tunnel
nmap automatically adds -Pn and drops sudo when proxied (ICMP and raw sockets don't traverse SOCKS)
Cerno manages its own ~/.cerno/proxychains4.conf — system config is not touched

Requires: proxychains4 installed and available on PATH.

Remote scan mode (pivot SYN scans): SOCKS can't carry raw-socket scans. In the nmap tool menu, [R] toggles remote mode: Cerno serves the target list over HTTPS on pivot_interface:pivot_http_port and gives you a curl … | nmap one-liner to run on the pivot host, plus an scp line to copy the results back into results_root.

🔌 MCP server (BETA)

Drive an engagement from an AI client — query findings, build target lists, and generate commands programmatically.

cerno mcp exposes the same scan database and tooling over the Model Context Protocol, so any MCP client (Claude CLI, Claude Desktop, etc.) can work with your findings. Read-only by default; execution and mutation are opt-in. See MCP Server (BETA) below for setup and the full capability reference.

Commands

# Import and review
cerno import nessus <scan.nessus>              # Import a single .nessus file
cerno import nessus <directory>                # Recursively import all .nessus files in a directory
cerno demo [--overwrite] [--no-nxc]            # Import the bundled demo scans + NetExec workspace
cerno review [--custom-workflows PATH]         # Start interactive review (custom workflows merged over bundled)
cerno review --custom-workflows-only PATH      # Use only this workflow YAML
cerno review --no-tools                        # Review only, no tool prompts
cerno review -q                                # Skip the banner
cerno review --proxy                           # Force-enable proxychains4 routing for this session
cerno review --no-proxy                        # Force-disable proxychains4 routing for this session
cerno review --check                           # Check tool availability and exit

# Manage scans
cerno scan list                                # Compact summary (use --wide for all severities, --json for scripting)
cerno scan delete <scan_name>
cerno scan compare <scan1> <scan2>             # Compare findings between two scans
cerno scan history <host_ip>                   # View vulnerability timeline for a host

# View workflows
cerno workflow list [--custom-workflows PATH]

# NetExec credentials (local only)
cerno creds list                               # Credential refs, usernames, domains (never secrets)
cerno creds reveal <ref>                       # Print one cleartext secret (SENSITIVE; audited)

# Configuration
cerno config show                              # Display all settings with current values
cerno config get <key>                         # Get a single config value
cerno config set <key> <value>                 # Set a config value
cerno config reset <key>                       # Reset one setting to its default
cerno config reset                             # Reset to defaults (creates backup)

# MCP server (BETA)
cerno mcp                                      # Serve scan data/tooling over MCP (stdio)

# Maintenance
cerno reset                                    # Purge ~/.cerno and return to fresh state
cerno --version                                # Show version

MCP Server (BETA)

cerno mcp exposes your scan database and tooling over the Model Context Protocol, so any MCP client (Claude CLI, Claude Desktop, etc.) can query findings, build target lists, generate tool commands, and — when explicitly enabled — execute tools and update review state. It speaks over stdio, so it is launched by the client rather than run directly in a terminal.

Add it to Claude CLI:

# pipx install (cerno is on PATH)
claude mcp add cerno -- cerno mcp

# development / editable install (point at your checkout's venv binary)
claude mcp add cerno -- /abs/path/to/cerno/.venv/bin/cerno mcp

Then claude mcp list to verify, or /mcp inside a session to see the tools, resources, and prompts.

The server is read-only by default — execution and mutation tools stay hidden until you enable them:

cerno config set mcp_allow_execution true        # execute_command + background jobs
cerno config set mcp_allow_mutations true        # review state, notes, verdicts, ingest, import
cerno config set mcp_allow_batch true            # execute_batch over a query (also needs execution)
cerno config set mcp_allow_cred_injection true   # resolve @cred:<ref>@ placeholders at run time
cerno config set mcp_allow_cred_reveal true      # reveal_credential (cleartext; audited)
cerno config set mcp_exec_allowlist "nmap,nxc"   # restrict which binaries execute_command may run ("*" = any)
cerno config set mcp_exec_denylist "rm,dd,sh"    # binaries execute_command may never run (always wins)

Gating flags are read once at startup; reconnect (remove + re-add, or restart the client) to apply a change.

Even with execution enabled, execute_command only runs binaries matching mcp_exec_allowlist (default: nmap, nxc, netexec, msfconsole plus low-impact recon utilities such as curl, wget, dig, whois, ssh-audit, sslscan and snmpwalk; an empty list denies everything) and never runs binaries matching mcp_exec_denylist (default: destructive commands such as rm, dd, mkfs*, shred, shutdown). Common wrapper prefixes (sudo, env, timeout, nice, nohup, …) are unwrapped so the real target is checked. The denylist is a guardrail, not a security boundary: with "*", shells and interpreters can still run denied programs unless you deny them too.

See docs/MCP.md for the full tool/resource/prompt reference, scopes, and management commands.

Keyboard Shortcuts

In the findings list view:

Enter - Open the first finding on the page; type a row number to open that finding
[S] - Cycle sort modes (severity, plugin ID, name, host count)
[F] - Filter findings by text (plugin name, description, etc.)
[I] - Toggle In Progress only / all statuses
[C] - Clear active text and status filters
[V] - View all unique hosts across the filtered findings
[H] - Compare: group findings by identical host:port combinations (when a group has more than 8 findings, answer D at the prompt to page through every group)
[O] - Overlapping: find findings whose affected hosts are a superset of another's
[X] - Clear group filter (when a comparison/overlap group is active)
[E] - Extract CVEs for all findings matching current filter
[M] - Move to next status: every filtered finding moves one step (Unreviewed → In Progress, In Progress → Done)
[D] - Done list; inside it, [M] moves selected findings back to Unreviewed
Status column: ○ Unreviewed, ◐ In Progress
[A] - Ask Claude — chat about the current filtered findings set
[N] / [P] - Next / previous page
[B] - Back to severity menu
[?] - Show help menu with all available actions

In the finding detail view:

[I] - Finding Info (plugin metadata, CVSS, CVEs)
[D] - Finding Details (host list, port distribution, plugin output)
[V] - View host(s) (grouped host:port or raw list; copy to clipboard)
[E] - CVE info for this finding
[N] - NetExec Data (per-host credential and access breakdown)
[T] - Run Tool (launch nmap, NetExec, Metasploit, or custom workflow)
[A] - Ask Claude — chat about this specific finding
[W] - View workflow verification steps (when one is mapped)
[M] - Move to In Progress / Move to Done (label follows the finding's status)
[B] - Back to findings list

Custom Workflows

Add plugin-specific verification workflows with --custom-workflows (merged over the defaults; custom wins on conflict) or --custom-workflows-only (replaces defaults):

cerno review --custom-workflows my_workflows.yaml

Example workflow YAML:

version: "1.0"
workflows:
  - plugin_id: "57608"
    workflow_name: "SMB Signing Not Required"
    steps:
      - title: "Verify SMB signing"
        commands: ["netexec smb <TARGET> -u <USERNAME> -p <PASSWORD>"]

Workflow placeholders: <TARGET>, <PORT>, <USERNAME>, <PASSWORD>, <DOMAIN>, <INTERFACE>. Workflows are shown as reference steps in the TUI ([W]); the MCP prepare_workflow tool fills them in from the finding's hosts, ports and a chosen credential.

Custom command placeholders (the "Custom command" option in Run Tool, not workflows): {TCP_IPS}, {UDP_IPS}, {TCP_HOST_PORTS}, {PORTS}, {WORKDIR}, {RESULTS_DIR}, {OABASE}

Set custom_workflows_path in config to load your workflows by default (the MCP server uses it too).

For comprehensive documentation, see Custom Workflows Guide covering:

Complete YAML schema reference
Multi-plugin workflows
Placeholder system details
Configuration integration
Best practices and troubleshooting

Troubleshooting

Database issues:

# Reset database (re-import required)
rm ~/.cerno/cerno.db
cerno import nessus scan.nessus

Config file issues:

# Reset a single setting to its default
cerno config reset <key>

# Reset config to defaults (creates backup)
cerno config reset

Full environment reset:

# Purge ~/.cerno entirely and return to a fresh installation state
cerno reset   # Prompts for typed confirmation before deleting

Import failures:

Ensure the .nessus file is valid XML (not corrupted or truncated)
Check file permissions and path
Turn on cerno config set debug_logging true and check ~/.cerno/cerno.log for the parse error

Tool execution issues:

Verify tools (nmap, netexec) are installed and on PATH
Check ~/.cerno/cerno.log for detailed error messages

Documentation

Releases

Cerno uses automated releases triggered by version changes in pyproject.toml.

How it works:

When pyproject.toml version is updated and merged to main, GitHub Actions automatically:
- Creates a git tag (e.g., v1.0.1)
- Generates a GitHub Release marked as "latest"
- Extracts release notes from CHANGELOG.md
- Attaches built wheel and source distribution

View releases: github.com/ridgebackinfosec/cerno/releases

For contributors: To create a new release, update the version in pyproject.toml and add an entry to CHANGELOG.md following Keep a Changelog format. The release workflow runs automatically when changes are merged to main.

Contributing

Found a bug or have a feature request? Please open an issue at: github.com/ridgebackinfosec/cerno/issues

Pull requests are welcome. For major changes, please open an issue first to discuss.

Target the develop branch — all contributor PRs should be opened against develop, not main. Releases flow from develop to main.

See CONTRIBUTING.md for dev setup, the test workflow, and the TUI ↔ MCP shared-core contract that keeps both interfaces working.

About the Name

Cerno comes from the Latin verb cernō, meaning:

To discern, distinguish, perceive
To separate, sift through
To decide, determine, resolve

The name reflects this tool's core purpose: to help security professionals discern what matters in large vulnerability scans. Just as cernō means to sift through and distinguish the important from the noise, Cerno helps you:

Discern which findings require immediate action vs. can be deferred
Separate findings by severity, host, and exploitability
Perceive patterns across hosts and identify verification paths
Determine the most efficient approach to vulnerability validation
Resolve findings through organized, tracked remediation workflows

In penetration testing and vulnerability management, clarity through careful examination is essential—that's Cerno.

Pronunciation: In Classical Latin, cerno is pronounced KEHR-noh (IPA: [ˈkɛr.noː])—the 'c' as a hard 'k' sound, the 'e' as in 'bed', and the 'o' as in 'no' (long). Audio sample

License

This tool orchestrates local utilities and includes Nessus XML parsing functionality adapted from DefensiveOrigins/NessusPluginHosts. Respect all dependencies' licenses and your organization's policies.

Cerno

Bu sunucuyu ekle

Host a copy with our keys and logs.

Server facts

Tools

Questions

How do I install Cerno?

Does Cerno need an API key?

What transport does Cerno use?

When was Cerno last checked?

Documentation

Cerno

Table of Contents

Quick Start

The demo fixture uses documentation-only IP ranges and `.example` hostnames. See docs/demo for details.

How It Works

Installation

Configuration

List keys take CSV: `cerno config set mcp_exec_allowlist "nmap,nxc"`.

Features

🔍 Interactive TUI for browsing/reviewing vulnerability findings

📊 Intelligence & Research

🤖 Claude Assistant

🔗 NetExec Database Integration

⚡ One-command tool launches

✅ Verification results & verdicts

💾 SQLite-backed persistence

🔀 Proxychains4 Integration

🔌 MCP server (BETA)

Commands

MCP Server (BETA)

Keyboard Shortcuts

Custom Workflows

Troubleshooting

Documentation

Releases

Contributing

About the Name

License

Bu sunucuyu ekle

Host a copy with our keys and logs.

Server facts

Tools

Questions

How do I install Cerno?

Does Cerno need an API key?

What transport does Cerno use?

When was Cerno last checked?

Documentation

Cerno

Table of Contents

Quick Start

The demo fixture uses documentation-only IP ranges and .example hostnames. See docs/demo for details.

How It Works

Installation

Configuration

List keys take CSV: cerno config set mcp_exec_allowlist "nmap,nxc".

Features

🔍 Interactive TUI for browsing/reviewing vulnerability findings

📊 Intelligence & Research

🤖 Claude Assistant

🔗 NetExec Database Integration

⚡ One-command tool launches

✅ Verification results & verdicts

💾 SQLite-backed persistence

🔀 Proxychains4 Integration

🔌 MCP server (BETA)

Commands

MCP Server (BETA)

Keyboard Shortcuts

Custom Workflows

Troubleshooting

Documentation

Releases

Contributing

About the Name

License

The demo fixture uses documentation-only IP ranges and `.example` hostnames. See docs/demo for details.

List keys take CSV: `cerno config set mcp_exec_allowlist "nmap,nxc"`.