mirror of
https://github.com/KeygraphHQ/shannon.git
synced 2026-09-29 21:11:55 +02:00
Arjun Malleswaranandezl-keygraph
9767ebe633
* feat(worker): add agentic static analysis Add the ten-stage Agentic SAST pipeline, confined repository tools, model runtime, prompt templates, and SARIF export. Make retries, repair sessions, reduced coverage, usage accounting, and model-output drift durable across Temporal replay and resume. Keep retry diagnostics in their actionable closed vocabulary. Package the Mantis-derived license material with the prompts that require it. * feat(worker): deduplicate static and runtime findings before exploitation Parse Agentic SAST SARIF into typed observations, enrich and route those observations, and reconcile them with pentest findings before exploitation. Publish deterministic exploitation queues with stable lineage, exact-path Git commits, retry-safe manifests, named drop reasons, and confined task formation. Reject duplicate producer IDs before commit and adopt either legal provenance shape after a lost acknowledgement. * feat(config)!: replace vuln_classes with agentic_sast Wire Agentic SAST and reconciliation into the main pipeline, persist their durable state, and add the Miscellaneous finding and exploitation lane. Make scan completion, cancellation, partial outcomes, resume identity, and report recovery use the integrated final workflow contract. Introduce the atomic finalization, ordering, renumbering, compaction, and output services that workflow calls. Keep completed Miscellaneous work and report drafts idempotent across resume, preserve public main's default-on exploit SARIF behavior, and describe stage-fallback candidates without claiming they were exported. BREAKING CHANGE: `vuln_classes` has been removed. Configs containing it now fail validation, and all five core pentest classes run on every scan. Workspaces created by Shannon 2.x cannot be resumed. Finish or discard in-flight scans before upgrading, then start a new workspace name. * perf: overlap static analysis and the Miscellaneous lane with the pentest Run Agentic SAST alongside vulnerability analysis and run Miscellaneous exploitation alongside the specialist exploitation lanes. Keep reconciliation dependent on the completed static-analysis result while preserving parallel work everywhere that has no data dependency. * feat(cli)!: default the scan target and add a JSON error contract List local scans, resolve the active or most recent workspace automatically, and make logs, status, and stop use one canonical scan identity. Add stable machine-readable failures, richer status output, explicit help errors, and seven-day Temporal retention. Treat absent Temporal pending-activity failures as absent whether the decoder represents them as `null` or missing. BREAKING CHANGE: `status --json` now returns a fixed `failureMessage`. Read `partialReasons`, `agenticSast`, and `workflow.log` for diagnostic detail. * feat(logging): trace tool calls and write a log per agent Record complete tool-call arguments in the workflow log and project each agent's events into its own durable log. Add agent listing and agent-specific log tailing while preserving byte-exact output and draining log handles before activities return. * feat(worker): standardize severity and reporting guidance in exploit prompts Give every exploit agent the same status, confidence, severity-reasoning, report-writing, credential-handling, and scope contract. Apply the same task-formation and SAST-enrichment procedure to the Miscellaneous lane. * feat(worker): disclose scan coverage and make reporting auditable Build on the retry-safe finalization foundation to preserve correct identities, source locations, scan dates, partial-coverage limitations, and consistent report JSON, Markdown, SARIF, and PDF output. Report Agentic SAST, reconciliation wall-clock time, stage usage, retry spend, and background work without duplicate or hardcoded totals. Keep report findings canonical, drop cross-class restatements, name enrichment losses, and render the executive-summary narrative in the PDF. * chore(license): attribute Mantis and Pi and refresh the docs Add the final Mantis and Pi notices, license copies, acknowledgements, and residual copyright updates. Update the README, maintained documentation, contributor guidance, and hand-maintained mirrors to describe Agentic SAST, reconciliation, the Miscellaneous lane, current CLI behavior, and the final release contract. Correct stale workspace and container guidance and annotate long-standing internals for maintainers. * fix(logging): treat a slash as a word separator in agent labels * feat(cli)!: rebuild scan status around model work - show Capella stages beneath the concurrent Agentic SAST phase - attach reconciliation time to the class row it feeds - hide completed bookkeeping and the duplicate miscellaneous wrapper - carry validated child-workflow progress into durable parent state - derive the terminal tree and status JSON from the same phase shape BREAKING CHANGE: `status --json` replaces phase `parallel` with `children` and `meta`, adds phase summaries and notes plus agent attachment fields, and removes the `analysis-engines` and `operational-work` phases. * fix(report): drop the empty Critical Findings section from the PDF summary * fix(sast): align Capella export with the submit-time code-path contract The export gate required every code_paths entry to be file:line, but submit only requires the primary sink to be file:line and accepts bare trace steps. A single malformed trace step therefore dropped an otherwise-valid finding at export. - add isValidPrimaryCodePath as the one shared primary-sink contract - validate only the primary at export; buildResult already drops unusable steps - route the submit-time validator through the same helper so the two cannot drift * feat(sast): tolerate hygiene-only Capella reductions instead of going partial A reduction only makes a run partial when it loses real coverage or a whole finding. Malformed model output, salvaged turn-limit work, and rejected duplicate verdicts are recorded as evidence but no longer flip the run to partial. - add reductionIsTolerable: partial only when genuine-loss counts are nonzero - drive runCapella's partial reasons and display coverage off non-tolerable ones - keep every reduction in agenticSast.reductions so nothing is lost as evidence * feat(logging): record the provider reason for a failed agent turn A failed provider turn collapsed to AGENT_EXECUTION_FAILED/unknown with the underlying reason discarded, so a model-side rejection or safeguard was indistinguishable from a transport fault in the error log. - add safeProviderTurnDetails: write bounded, non-sensitive fields (provider, model, responseId, stop reason, tool-in-flight, category, retryable) to error.log - gate a sanitized errorMessage snippet behind SHANNON_DEBUG_PROVIDER_ERRORS, off by default - forward SHANNON_DEBUG_PROVIDER_ERRORS from the CLI into the worker container * fix(cli): keep shannon logs tailing through a Temporal blip - End the interactive tail on the log's own terminal marker or Ctrl-C, so a transient Temporal outage no longer aborts the command with exit 1. - Rebuild the memoized Temporal client after a failed poll: a wedged gRPC channel was cached forever, so "retrying…" could never reconnect. - Keep start --follow (CI) bounded — a genuinely dead Temporal still fails the run instead of hanging. * fix(worker): correct PDF finding reporting - Render OWASP category, authentication state, and remediation - Omit the redundant per-finding exploited status - Preserve canonical category and field ordering across report modes - Continue Proof of Impact numbering across embedded code blocks - Wrap long PDF code lines without changing canonical report content * fix: attribute a reconciliation failure to exploitation only - Stop marking a class's vulnerability-analysis agent failed when that agent succeeded and only reconciliation failed; the status tree now renders the analysis row completed and the exploitation row failed - Consume the worker's failedReconciliations signal in the CLI, which the mirrored PipelineState already declared but never read - Correct the class_reconciliation_failed message, which claimed the class's analysis results were still in the report when the class is excluded from it * fix(pi): give each task sub-session its own resource loader to prevent stale extension ctx * fix(prompts): scope exploit agents to in-band proof, mark OOB-only findings blocked * fix(cli): reject a shell credential that shadows a gateway config.toml key * fix(cli): make scan shutdown verifiable - preselect and persist workflow identity before worker launch - cancel first, then verify bounded Temporal termination - reconcile Docker workers with Temporal open workflows - fail closed on stale images and unavailable lifecycle state - mark cancellation only after confirmed shutdown * feat(cli): prompt for setup on a bare npx invocation with no credentials * fix(cli): don't blame anthropic when no credentials are configured at all * chore(release): bump beta base version to 3.0.0 * feat(cli): show a 'start your first scan' box in help on a TTY * docs: refresh README and platform overview for Shannon 3.0 - lead with the 3.0 launch note and rewrite key capabilities around security code analysis, the rebuilt terminal experience, native CI/CD, and PDF/SARIF - recast the editions table as Shannon Open Source against the Keygraph Enterprise Platform, stating open source is not a trial edition - rewrite the platform overview around exhaustive agentic SAST, canonical findings, automated remediation, targeted verification, and governance - add five product screenshots under assets/keygraph-platform/, referenced relative to docs/ * docs: add the Shannon naming section and swap in the 3.0 demo GIF - explain the Claude Shannon information-theory origin under "What is Shannon?" - point "Shannon in Action" at the 3.0 recording in assets/Shannon3GIF.gif Both taken from the README half of #438. * docs: document CI/CD integrations and the reconciled analysis pipeline - add a CI/CD Integrations section covering the official GitHub Action and GitLab component, pipeline artifacts, and exploit-only severity gates - redraw the architecture section as a Mermaid flow: agentic code analysis and recon feed finding reconciliation, then exploitation and reporting - describe open-source code analysis as a multi-stage agentic workflow and reserve parsed-code CPGs and exhaustive verification for Enterprise - sharpen the privacy wording: results stay local, but model requests carry source context to whichever endpoint you configure - drop the "not recommended" framing on local models and add a section on why Shannon complements rather than replaces human pentesters - regenerate llms-full.txt from the updated README and docs * docs: add the Photoview benchmark across three models - Add a "Shannon in Action" table for Photoview 2.4.0 runs on DeepSeek v4 Flash, Grok 4.6, and Claude Opus 5, each linking its PDF report and SARIF output - Store the per-model reports under benchmark/ - Link the (forthcoming) benchmark writeup from the section intro * docs: add the Shannon vs XBOW/Aikido Photoview benchmark writeup - Add docs/shannon-xbow-aikido-benchmark.md with methodology, per-model cost/coverage tables, and links to each model's report and SARIF - Link the writeup from the README "Shannon in Action" section * docs: link the benchmark announcement discussion from the README * fix(readme): restore theme-aware banner, badge, and buttons * feat!: trigger the Shannon 3.0 major release --------- Co-authored-by: ezl-keygraph <ezhil@keygraph.io>
50 lines
5.5 KiB
Plaintext
50 lines
5.5 KiB
Plaintext
<verdict_vocabulary>
|
|
Three separate things decide how a finding is recorded. Keep them distinct — they are different fields with different values.
|
|
|
|
- **`status`** — a field on the delivery tool with exactly two values. `"exploited"` means your own testing settled the question. `"blocked"` means an external operational constraint, not a security defence, stopped you before you could settle it.
|
|
- **`severity`** — a separate field, set only when `status` is `"exploited"`. Four values: `critical`, `high`, `medium`, `low`.
|
|
- **False positive** — not a value on either field. Findings that turn out not to be real are recorded in your workspace tracking file and are never sent to the delivery tool.
|
|
</verdict_vocabulary>
|
|
|
|
<severity_reasoning>
|
|
Severity is a judgement about consequence. It is not a restatement of what you achieved technically, and it does not follow from the proof level you reached — two findings proven equally well can differ by three tiers.
|
|
|
|
Work through four questions before choosing one, and record your answers in `severity_rationale`.
|
|
|
|
**1. What does the attacker end up holding?**
|
|
|
|
Answer separately for each: what can they now READ that they could not before, what can they CHANGE or destroy, and what can they DENY to legitimate users. Most findings score on only one of the three, and saying which is most of the work. Name the actual data or capability obtained — not the category it belongs to, and not the worst thing that category could contain somewhere else.
|
|
|
|
**2. What did it take?**
|
|
|
|
Every precondition lowers severity. Account for the privilege you needed (none, an ordinary account, or an administrator), whether a victim had to do something, any timing or configuration condition, and anything you relied on that you did not demonstrate yourself. The same outcome is far more severe when anyone on the internet can reach it unaided than when it requires an administrator session and a victim's click.
|
|
|
|
**3. How far does it reach?**
|
|
|
|
Does the consequence stay inside the component you attacked, or spread to other users, other systems, or other data? Propagation counts only if you demonstrated it. "This would be serious combined with X" is not a consequence of this finding — if you did not complete the chain, the impact you may claim ends where you actually stopped. Impact that originates in a different finding belongs to that finding.
|
|
|
|
**4. What is it worth here?**
|
|
|
|
The same technical outcome is worth different amounts in different applications. Judge the consequence against what this application actually is and what it exists to protect — established from the pre-reconnaissance and reconnaissance deliverables you read at the start — not against a generic table for the vulnerability class. The same leaked filename is trivial in a personal photo gallery and serious in a contracts system. Decide which this is, and say so.
|
|
|
|
**The floor: not every finding has a tier.**
|
|
|
|
Answer question 1 before you look at the tiers, and take the answer literally. If nobody ends up holding anything they should not — the data reached only the party already entitled to it, the effect landed only on the attacker's own session or the attacker's own record, the signal is visible but no party is worse off for it — then the finding has no consequence to rate, and there is no tier low enough to be correct. Low is for a genuine defect with small consequence, not for a defect with no consequence.
|
|
|
|
Two checks catch the cases that reach the tiers dishonestly:
|
|
|
|
- **Your own rationale must not refute your finding.** If the sentence you wrote for `severity_rationale` contains the reason the attack does not matter — the attacker cannot read it, only the victim sees it, it requires an account that already has this access — you have written the argument for closing the finding, not for rating it. Stop and close it.
|
|
- **The criterion you met must be the one you were given.** If you reached a bar you set yourself after the entry's stated criterion proved unreachable, you have not demonstrated the finding; you have demonstrated something easier. Substituting a weaker criterion mid-run does not support any tier.
|
|
|
|
A finding that hits the floor is not sent to the delivery tool. Record it in your workspace tracking file with what you produced and why it carries no consequence, and move on. Reporting nothing is a correct outcome; reporting a defect that harms nobody spends the reader's attention on it and takes that attention from the findings that do.
|
|
|
|
**Choosing the tier**
|
|
|
|
- **Critical** — severe, immediate and broad harm to the business running this application. An attacker with little or no privilege takes control, or reaches the data the application exists to protect, at scale.
|
|
- **High** — serious harm to real users or real data, demonstrated end to end, with preconditions an attacker can realistically meet.
|
|
- **Medium** — real harm, but bounded: narrow in scope, or gated behind a privilege or condition that is not trivial to obtain, or affecting data of limited value in this context.
|
|
- **Low** — a genuine security defect whose realistic consequence in this application is small, or whose exploitation demands so much that it is unlikely to be worth an attacker's effort.
|
|
|
|
**The burden of proof rises with the tier.** Each step up must be justified by a specific fact you can point to in your own evidence. If you cannot name that fact, the finding belongs one tier lower. Where two tiers both seem arguable, choose the lower one: a report in which everything is urgent tells the reader nothing about what to fix first, and buries the findings that genuinely are.
|
|
</severity_reasoning>
|