Shannon 3.0 is here #439
Pinned
keygraphVarun
announced in
Announcements
Shannon 3.0 is here
#439
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Shannon 3.0 is here
Today we're launching Shannon 3.0.
When we first released Shannon, the thesis was to give an AI agent an application's source code and running environment, then let it autonomously try to break it.
Since then, Shannon has grown to more than 47K GitHub stars, built an incredible open-source community, and started autonomously pentesting internal applications at Fortune 500 companies.
With 3.0, we’re bringing:
Try Shannon 3.0
Shannon performs real exploitation. Only run it against applications and environments you own or have explicit authorization to test.
Advanced security code analysis is now open source
In 3.0, we're augmenting Shannon's code analysis with a new multi-stage agentic security code-analysis pipeline, adapted from the open-source Mantis security-review skills and substantially modified for Shannon's Pi-based agent architecture.
It runs alongside the recon and vulnerability-analysis agents that already read source and trace attacker-controlled data to sensitive sinks, adding a deeper, code-first review before exploitation.
In parallel with the classic recon-to-vulnerability flow, it builds its own security-relevant model of the application: components, interfaces, dependencies, data flows, trust boundaries, and high-risk assets.
From there, agents inspect relevant source, follow attacker-controlled data across call sites and component boundaries, and produce structured candidate vulnerabilities with the supporting code paths.
Those candidates pass through several filters. They are deduplicated, challenged by an independent review agent, evaluated for production viability, statically confirmed against their source-to-sink paths, and risk-calibrated.
flowchart TD S["Source code"] --> EXISTING["Recon + vulnerability analysis"] S --> SAST["Agentic security code analysis"] EXISTING -- "Pentest candidates" --> REC["Finding reconciliation<br/>(merge + deduplicate)"] SAST -- "SAST candidates" --> REC REC -- "Reconciled exploitation queue" --> EXP["Exploitation agents"] APP["Running application"] --> EXP EXP -- "Exploit demonstrated" --> REPORT["Reporting<br/>PDF · Markdown · SARIF"] EXP -- "No exploit demonstrated" --> DROP["Discard"] REPORT --> CICD["CI/CD gate"]These candidates feed into the same exploitation stage Shannon has always used. A code-analysis hypothesis never becomes a finding on its own; an agent still has to demonstrate it against the running application:
The open-source implementation provides deeper code understanding while staying practical to run locally and in CI/CD. The Keygraph platform builds on it with a heavier AppSec stack, including parsed-code analysis, data-flow graphs, source-to-sink analysis, SCA with reachability, secrets, IaC, containers, and broader enterprise application context.
Benchmark Results
Doyensec recently published a benchmark of two AI application-security testing platforms, Aikido and XBOW, across a set of vulnerable open-source apps. We ran Shannon 3.0 against Photoview, one of their targets, on the same commit, using three models at different price points (DeepSeek v4 Flash, Grok 4.6, and Opus 5). The report covers how each scan was run and a finding-by-finding comparison against Aikido's and XBOW's results. Across the three models, Shannon's scans produced quality results, at costs between roughly $6 and $115, versus the $4,000 per scan for each commercial platform.
Full benchmark: [BENCHMARK LINK]
A rebuilt CLI and resumable pentests
In previous Shannon releases, understanding what was happening could mean digging through Temporal or reading the complete workflow log.
The rebuilt CLI exposes that workflow directly:
You can see which phases and agents are running, what has completed, and where something failed. Combined workflow logs and individual agent logs make it easier to follow or debug a specific part of an assessment without opening Temporal.
Shannon 3.0 also uses workspaces to make pentests resumable:
Agent progress is checkpointed, so interrupted runs can resume from the same workspace without unnecessarily repeating completed work. This matters when providers rate-limit, networks fail, machines restart, or Docker containers stop halfway through a scan.
CI/CD integrations
Shannon 3.0 is designed to make pentesting continuous rather than an exercise teams schedule once or twice a year.
We've published an official GitHub Action, available through the GitHub Marketplace, and an official reusable GitLab CI/CD component.
Both integrations support automated staging pentests, scheduled and release scans, CI artifacts, reports, logs, and severity-based pipeline gating.
Gating follows the same rule as reporting:
only an exploitable vulnerability will be able to block a build.
Teams can choose the severity threshold that fails a job, making it possible to run Shannon after a staging deployment, before production, or as part of a scheduled security assessment.
Reports and native SARIF
Shannon 3.0 generates PDF and Markdown assessment reports alongside machine-readable SARIF 2.1.0 output.
For each validated vulnerability, reports can include severity, exploitation evidence, reproduction information, affected source context, and remediation guidance.
The same findings can flow into GitHub code scanning, GitLab security workflows, vulnerability-management platforms, dashboards, and other SARIF-compatible tooling. Where Shannon can associate a vulnerability with a source location, that context travels with the result.
Finally, the exploit agents now reason through CVSS before they assign a severity, so the reported category should match what the CVSS factors support. We also rewrote the prompting for titles and descriptions to push the agents toward realistic, clear descriptions of each finding. The severity section below shows how far that got us.
Deduplication
With two pipelines producing finding candidates, v3 deduplicates in two passes. When vulnerability analysis and the Code Analysis pipeline finish, one agent per vulnerability category merges that category's Code Analysis findings with its exploit queue. Then the reporting agent runs a final pass across categories, so a finding that two category pipelines both reported appears once in the report.
A Miscellaneous Exploit Agent
Some Code Analysis CWEs don't map cleanly onto Shannon's five vulnerability categories. v3 adds a sixth exploit agent for those miscellaneous findings, which widens the range of exploit types Shannon attempts. Its findings carry the MISC prefix in the new reports
Links
Thanks
A lot of Shannon 3.0 came directly from what people in this community asked for.
Thank you to everyone who tested Shannon, opened issues, shared bug reports, benchmarked it, deployed it internally, or pushed the project further than we expected when we first open-sourced it.
Shannon also builds on great open-source work. Special thanks to Pi, Playwright CLI, and Mantis.
If you try 3.0, we'd love to hear what Shannon finds, what it misses, where the agents get stuck, and how it behaves inside your CI/CD workflows.
Bug reports are welcome in GitHub Issues, and everything else in the comments below.
All reactions