odin-security-advanced

Use when building or running native code under AddressSanitizer, or when interpreting an existing ASan report. Instruments C/C++ or Rust unsafe/FFI targets, sets ASAN_OPTIONS for fuzzer integration, and classifies each reported error with its faulting and allocation sites. Not for remote, credential, publish, deploy, or irreversible changes.

Use when the user needs to set up and run an AFL++ fuzzing campaign for a C/C++ target. Compiles with LTO, LLVM, or GCC instrumentation, runs single or multi-core campaigns, triages crashes, and minimizes the corpus. Requests explicit approval before system-level changes. Not for libFuzzer harness campaigns — use libfuzzer.

Use when a user needs coverage-guided fuzzing for Python code or a Python native extension using Atheris. Sets up an instrumented harness, configures sanitizer flags for native extensions, and reproduces saved crash artifacts. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a multi-language program graph is needed for call paths, entrypoints, blast radius, coarse taint reachability, privilege boundaries, or declared cross-system links. Builds the full graph, runs preanalysis, and gates every version-specific query behind a capability probe with bounded security claims. Not for a quick overview; use trailmark-summary. Not for a fixed snapshot payload; use trailmark-structural.

Use when a human invokes the Burp search command with a required .burp project file and optional parser operation. Runs the Burp Suite project parser wrapper and returns JSON search results. Not for source or remote-system changes.

Use when asked to search or analyze a Burp Suite .burp project to extract audit items, inspect request or response metadata, or search captured traffic. Reads through Burp Suite Professional headless JAR, preflights result size, and returns size-checked JSON with truncated body fields. Findings are indicators requiring validation.

Use when initializing, running, measuring coverage, or triaging a cargo-fuzz target in a Rust crate. Installs the nightly toolchain, writes the fuzz_target! harness, runs under the chosen sanitizer, and reproduces crash artifacts. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a supported Algorand, Cairo, Cosmos SDK, Solana, Substrate, or TON codebase needs chain-specific vulnerability scanning. Returns reachability-backed findings routed to the matching ecosystem reference. Not for generic non-chain security review — route that to security-review.

Use when reviewing cryptographic code for timing side-channels (C, C++, Go, Rust, Swift, Java, Kotlin, C#, PHP, JS, TS, Python, Ruby). Statically inspects assembly or VM bytecode for secret-dependent variable-time ops across an explicit configuration matrix. Not for runtime timing tests — use constant-time-testing.

Use when a cryptographic implementation must be checked at runtime for timing side-channel leakage. Runs dudect statistical testing and Timecop dynamic tracing, applies a Welch t-test threshold, and reports leakage or a bounded inconclusive result. Not for static assembly inspection — use constant-time-analysis.

Use when asked for a sequence diagram of cryptographic protocol semantics from code, prose, RFCs, papers, ProVerif, or Tamarin. Also handles code/spec divergence when both are supplied. Not for general architecture diagrams — use embed-diagram.

Use when given a PR, commit, diff, or baseline and asked for security regressions, blast radius, test gaps, or adversarial review. Risk-classifies changes and writes an evidence-backed report. Not for whole-codebase audit — use security-review. No remote or irreversible changes.

Use when a user needs to create or improve a deterministic, engine-agnostic fuzz harness for raw or structured target inputs. Identifies the API entry point, defines an adapter for structured input, writes a deterministic harness, populates a boundary corpus, and confirms API reachability with preserved crashes. Not for coverage measurement — use fuzzing-coverage-analysis.

Use when a user needs to measure fuzz corpus coverage, explain a coverage plateau, or turn uncovered regions into campaign work. Builds an instrumented binary, runs it over a post-campaign corpus, and produces a reproducible coverage report excluding harness noise. Not for harness creation — use fuzz-harness-writing.

Use when a parser, protocol, or file format fuzzer stalls at fixed-token validation gates. Extracts tokens from target source, headers, or binary, writes a fuzzer-parseable dictionary, and confirms tokens correspond to target parsing gates. Not for patching the SUT — use fuzzing-obstacles.

Use when asked to identify and bypass checksums, nondeterminism, or validation barriers that block fuzzing coverage. Patches the SUT behind an explicit fuzzing build flag with false-positive risk assessed. Not for dictionary creation — use fuzzing-dictionary. Local writes only.

Use when two refs or source snapshots need security-relevant structural comparison a line diff may miss; returns a GRAPH_EVOLUTION report classifying node, edge, entrypoint, and subgraph changes. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a custom LibAFL fuzzer needs an executor, observer, feedback, mutator, scheduler, or objective composed around a target. Produces a coverage-guided engine with persisted findings. Don't use for remote, credential, publish, deploy, or irreversible changes.

Use when asked to build, run, and triage Clang libFuzzer campaigns: harness structure, sanitizer-compiled binary, corpus-driven execution, and crash reproduction. Don't use for remote, credential, publish, deploy, or irreversible changes.

Use when a cryptographic Mermaid sequenceDiagram is supplied and the user requests a ProVerif model with secrecy, authentication, replay, or forward secrecy verification. Parses the diagram, defines Dolev-Yao cryptographic primitives, maps messages to ProVerif processes, and runs verification queries. Not for remote, credential, publish, deploy, or irreversible changes.

Use when asked to implement, debug, or validate an OAuth 2.0/2.1 flow (authorization code+PKCE, client credentials, device flow, refresh rotation) or to explain a token exchange failure against RFC 6749/6750/7636/8252/8628. Not for remote, credential, publish, deploy, or irreversible changes.

Use when asked to enroll a project in OSS-Fuzz or run its helper workflow locally. Builds the project image and fuzzers, runs the named harness, and checks enrollment metadata. Not for remote, credential, publish, deploy, or irreversible changes.

Use when an existing static-analysis rule must be ported to another language or analyzer, producing an independently validated rule with vulnerable, safe, and edge-case parity tests. Use this for cross-language rule porting, not for authoring a new rule from a vulnerability description (use semgrep-rule-authoring) or for running scans (use semgrep-security-scan).

Use when SARIF results, reviewer annotations, or a third-party finding export must be projected onto an existing program graph and cross-referenced with precomputed reachability or blast-radius evidence, with every finding left at its source status. Not for building the graph; use build-program-graph. Not for triaging one finding; use triage-security-finding.

Use when asked to set up and run coverage-guided fuzzing of Ruby code or C extensions with Ruzzy, producing crash reports or clean campaign summaries. Not for C/C++ fuzzing — use fuzzing.

Use when a named security allegation needs a true-positive or false-positive verdict backed by data-flow and exploitability evidence. Not for discovering bugs — use security-review. Not for adding controls — use security-hardening.

Use when a vulnerability or code pattern and a target language need a new custom static-analysis detection rule. Produces one validated, tested rule with a graded vulnerable/safe/edge/nested test matrix. Not for porting an existing rule to another language — use port-static-analysis-rule. Not for running scans with existing rules — use semgrep-security-scan.

Use when a smart-contract project must become review-ready before an audit. Produces a handoff package with frozen commit, build checks, and readiness checklist. Not for workflow — use smart-contract-secure-workflow; not for guidelines — use smart-contract-guidelines-advisor.

Use when a smart-contract team invokes this before check-in or deployment to run a five-stage security workflow producing a consolidated pass or unresolved-risk report. Not for audit prep — use smart-contract-audit-prep; not for guidelines — use smart-contract-guidelines-advisor.

Use when a token implementation or integration needs standards, privilege, nonstandard-behavior, and defensive-integration analysis. Returns a prioritized remediation report. Not for tasks that require source or remote-system changes.

Use when a target needs a detailed single-snapshot structural analysis for hotspots, entrypoints, coarse taint, blast radius, privilege boundaries, proxies, subgraphs, and type references. Not for a quick overview — use trailmark-summary. Does not diff between branches or snapshots.

Use when exactly one concrete security finding with a bindable source anchor (a SARIF result, reviewer annotation, suspicious function, or report excerpt) needs a Promote, Needs manual review, Deprioritize, or Blocked verdict before PoC work. Not for projecting batches of findings onto a graph; use project-findings-onto-graph.

Use when a confirmed root cause must be searched across a codebase or turned into a search rule. Returns triaged variants, false positives, and a CI-ready regression rule. Not for graph-neighborhood seeding — use variant-neighborhood-seeding.

Use when a confirmed or plausible issue maps to a graph node and the user needs a ranked handoff packet of graph-neighborhood review targets to seed variant analysis. Produces a local markdown file with ranked candidates, exclusion rationale, and search guidance. Not for searching codebase manifestations of a root cause — use variant-hunt.

Use when existing cryptographic implementations and a vector-consuming harness need mutation-driven, cross-implementation test vector expansion. Produces targeted test vectors isolating escaped-mutant defects and a measured before/after kill-rate delta. Not for validating against the established Wycheproof corpus — use wycheproof. Not for coverage-guided fuzzing — use fuzz-harness-writing.

Use when an incoming vulnerability report, CVE, bug-bounty submission, or automated finding needs resource-allocation triage before deep verification. Evaluates through seven brocards and returns ACCEPT, DISMISS, or NEEDS-MORE-INFO. Don't use for tasks that require source or remote-system changes.

Use when validating a cryptographic implementation against Project Wycheproof vectors to prove it accepts/rejects them correctly, or when explaining why an implementation disagrees with a vector. Produces parameterized valid, invalid, and acceptable cases with stable tcId identifiers and a per-category pass/fail/warn summary. Not for mutation-driven vector creation — use vector-forge. Not for zeroization auditing — use zeroize-audit.

Use when writing, reviewing, optimizing, validating, or migrating YARA or YARA-X malware-detection rules, including CRX or DEX rules. Produces a validated rule with family-specific indicators and separated validation results. Not for network IDS or memory-forensics rules.

Use when auditing C, C++, or Rust secret-handling code to verify zeroization survives compiler optimization (dead-store elimination, register spills). Produces findings JSON and a Markdown report correlating source lines with optimization-level evidence. Not for test vectors — use wycheproof.