panic-attack

panic-attack is a multi-language security analysis and stress-testing system.

It combines static analysis, logic reasoning, attack simulation, and distributed execution to identify weaknesses across codebases and systems.

---

Table of Contents

• What it is
• Why it exists
• Core capabilities
• Operating modes
  • Special Cases
• Relationship to PanLL
• Relationship to NAFA
• Design philosophy
• CLI & Automation
  • Global options
  • Automation readiness
• Integration & Groove
• Status
• One line summary

What it is

panic-attack is a security and resilience tool.

It is designed to:

• analyse codebases across many languages

• identify weak points and vulnerabilities

• simulate failure conditions and stress scenarios

• generate verifiable reports and system-level insights

It operates across:

• static analysis

• dynamic attack execution

• logical inference (miniKanren)

• distributed batch scanning

---

Why it exists

Modern systems are:

• large

• heterogeneous

• distributed

• difficult to reason about globally

Security tools often:

• operate per-language

• miss cross-system interactions

• generate high false-positive rates

• lack temporal or system-level context

panic-attack exists to address this by combining:

• multi-language analysis

• logic-based reasoning

• system-wide scanning

• temporal and spatial modelling

---

Core capabilities

panic-attack provides:

• 49-language static analysis across multiple families

• Weak point detection (25 categories)

• Attack simulation (6 axes): CPU, memory, disk, network, concurrency, time

• miniKanren logic engine for taint analysis and cross-language reasoning

• Signature detection (use-after-free, deadlock, etc.)

• Batch scanning (assemblyline) with parallel execution

• Temporal analysis via snapshots and diffing

• System imaging (fNIRS-style risk visualisation)

• Cryptographic attestation (intent → evidence → seal)

---

Operating modes

panic-attack supports multiple deployment patterns:

• Standalone: local analysis and reporting

• panicbot: integrated automated diagnostics

• mass-panic: large-scale multi-repo / multi-system scanning

Special Cases

For browser extensions (Firefox/Chrome):

• Use panic-attack assail (static analysis only)

• Skip dynamic attack phase (extensions cannot be executed as standalone programs)

• Focus on:

  • eval() usage

  • DOM manipulation

  • Hardcoded secrets

  • Supply chain risks

Future: Add browser-specific attack simulation via headless browsers.

---

Relationship to PanLL

panic-attack integrates with PanLL as a diagnostic and analysis layer.

• panic-attack generates structured outputs

• PanLL visualises and interacts with those outputs

• PanLL panels (imaging, temporal, event-chain) provide exploratory views

Examples:

• event-chain export → DAW-style timeline

• system-image → spatial risk maps

• temporal-diff → change over time

---

Relationship to NAFA

panic-attack represents a non-ambient layer.

It is intentionally:

• explicit

• analytical

• visible

Where NAFA aims for:

• calm

• low cognitive load

• minimal surface noise

panic-attack operates when:

• systems must be inspected

• risks must be surfaced

• problems must be made visible

---

Design philosophy

panic-attack prioritises:

• correctness over convenience

• visibility over abstraction

• verifiability over guesswork

It is not designed to be silent.

It is designed to be trustworthy.

---

CLI & Automation

panic-attack is a Clap-powered CLI. Each subcommand inherits a shared set of knobs so the UX is consistent whether developers run assail, attack, assault, assay, aggregate, temporal, panll, groove, or another entry point.

Global options

Globally applied flags let automation pipelines control verbosity, output format, storage location, and presentation. Current defaults are:

Flag	Default	Description
--report-view	Accordion	Controls the presentation mode (Accordion, Summary, Timeline) that the CLI writes and that PanLL mirrors.
--expand-sections	false	Expands extra detail blocks in the formatted report.
--output-format	json	Chooses how the artifact is serialized (json, markdown, or text); the CLI reuses this when it writes PanLL exports or temporal diffs.
--pivot	false	Rotates the narrative axis for boards that expect events-first storytelling.
--store	unset	Directory where generated reports, exports, and artifacts should land.
--quiet	false	Suppresses informational log lines for automation.
--parallel	false	Enables threaded execution when commands support it (assault, image, mass-panic).

Consult man/panic-attack.1 or panic-attack help for every command, and use panic-attack completions --shell <fish|zsh|bash|powershell|nushell> to bootstrap automation-friendly helpers.

Automation readiness

panic-attack diagnostics validates AI manifests, VeriSimDB caches, Hypatia and gitbot-fleet watchers, and the docs PanLL expects (docs/ambush-timeline.md, docs/panll-export.md). docs/patch-bridge-design.md details how the patch-bridge subcommands plug into BoJ cartridges, CVE workflows, and the PanLL panel.

just test-elixir runs the Elixir harnesses that cover the CLI surface so documentation, help text, and automation flags stay aligned.

Integration & Groove

panic-attack can emit PanLL-friendly exports (event chains, system images, temporal diffs) per docs/panll-export.md, and it also advertises its static-analysis capability via the Gossamer groove protocol. Start the discovery endpoint with panic-attack groove --port 7600 and check the JSON manifest by curling http://localhost:7600/.well-known/groove (the health endpoint sits at /health).

The manifest follows the Idris-aligned semantics that live in boj-server/src/interface/abi/Groove.idr and the gossamer schema references. As a result, any groove-aware consumer—PanLL event-chain panels, the Burble voice platform, Hypatia, or other automation fabrics—sees the same capability vocabulary and can attach its own UI (Groove + Burble PanLL) confidently.

VeriSimDB remains the foundation dependency for these exports, so every snapshot recorded for PanLL, Gossamer, or Burble can be replayed, inspected, and audited even after the CLI process exits.

---

Status

Current state: v2.5.0

• 32,000+ lines of Rust + Chapel

• 897 passing tests (per cargo test --release, 4 ignored; 901 runnable per cargo test — --list) across unit / property / e2e / aspect / integration tiers

• v2.5.5 cohort landed 2026-06-02: context-aware FP suppression via test_context / comment_marker / ffi_kind / jit_context modules — // panic-attack: accepted inline markers, automatic PanicPath suppression in test-only code, build.zig/build.rs auto-accept, Cranelift/LLVM/Wasm/JS JIT detection. See PROOF-PROGRAMME.md for the formal soundness landscape

• 0 warnings

• 38 CLI subcommands

• 49 supported languages (25 canonical weak-point categories PA001–PA025; PA001b SARIF subvariant collapses two allocation flavors under the same canonical rule)

See ROADMAP.adoc for full capability breakdown and milestones.

---

One line summary

---

panic-attack makes system risk visible, measurable, and testable.

---