cyberflow

name

cyberflow

description

Use Cyberflow to plan and track authorized cyber research workflows for Codex TAC members, including the default recon/modeling/analysis/proofing flow, deep source code audits with production-symbol ledgers, focused source code use-after-free (UAF) and lifetime/ownership audits, focused source code out-of-bounds (OOB) read/write and bounds audits, source code patch-diffing, bug-precedent analysis, ledger-based bug variant audits from history such as git, deep binary decompilation with pyghidra or IPSW, binary patch diffing with Ghidra or IPSW, dynamic custom workflows when general and targeted workflows are incompatible, agentic symbol recovery and renaming, phase gates, scoped vulnerability reasoning, threat modeling, proof packet planning, and reusable flow state across research types.

Cyberflow

Use Cyberflow to keep authorized cyber research aligned across long Codex turns. Cyberflow is a lightweight planning and tracking layer: it organizes scope, phases, hypotheses, evidence, blockers, and proof readiness. Cyberflow owns transient orchestration state; Cybermem owns durable reusable system knowledge when that plugin is available. Cyberflow must remain useful without Cybermem.

Operating Rules

• Confirm authorized scope, proof limits, and excluded actions before active testing or proofing.
• TAC workflows are expected to support deep vulnerability validation. Do not stop at shallow evidence when the authorized scope allows stronger proof.
• Prefer controlled proof environments: VMs, containers, emulators, disposable devices, local fixtures, synthetic tenants, and test accounts with snapshot/restore or cleanup paths.
• Get explicit approval and record a decision or blocker before actions likely to cause persistent host changes, data loss, service disruption, credential or account impact, cross-tenant effects, or effects on real users or real accounts.
• Keep SKILL.md lean. Load workflow-specific detail from the referenced workflow guide after selecting a workflow.
• Prefer a workspace flow packet under tmp/cyberflow/<case-id>/ when the task will span phases or turns.
• Keep claims tied to evidence, negative evidence, or explicit assumptions.
• Do not store live secrets, bearer tokens, session credentials, private keys, or sensitive customer data in flow records.

Workflow Selection

• General workflow: Use by default for broad or uncertain targets. Read references/workflows/general.md.
• Source code audit deep workflow: Use for deep production source audits with architecture recon, source/sink modeling, bug and patch history, symbol-ledger tracking, vulnerability analysis, static primitive proofing, and end-to-end chain PoVs. Read references/workflows/source-code-audit-deep.md.
• Source code UAF audit workflow: Use for focused source audits targeting use-after-free, lifetime, ownership-transfer, refcount, callback-after-destroy, iterator invalidation, async/concurrency lifetime, or unsafe/FFI lifetime bugs. Read references/workflows/source-code-uaf-audit.md.
• Source code OOB audit workflow: Use for focused source audits targeting out-of-bounds reads/writes, buffer overflows/overreads, bounds checks, range modeling, index/offset/length arithmetic, parser/copy paths, or FFI buffer-size bugs. Read references/workflows/source-code-oob-audit.md.
• Source code audit patch workflow: Use when source history such as Git is available and the task is to inspect patch history, public CVEs/disclosures, previously fixed bugs, problematic modules, incomplete fixes, bug variants, and bug precedent. Read references/workflows/source-code-audit-patch.md.
• Binary decompile workflow: Use when the task starts from a target binary, firmware image, app bundle, library, or executable set and the goal is readable decompiled source through pyghidra or IPSW-oriented tooling plus agentic symbol recovery. Read references/workflows/binary-decompile.md.
• Binary patch diff workflow: Use when vulnerable/fixed binaries or firmware versions are available and the task is to compare patches with Ghidra or IPSW-oriented tooling, understand binary-level bug fixes, and maintain a bug variant hunting ledger. Read references/workflows/binary-patch-diff.md.
• Dynamic workflow: Use when the General workflow and targeted workflows are incompatible with the task and the agent needs to design custom phases, scope, gates, and optional ledgers. Read references/workflows/dynamic.md.

When a planned workflow is requested, use Dynamic if the task does not fit General cleanly; otherwise use General as the fallback structure and note that the specialized guide has not been added yet.

MCP Tool Pattern

Use the Cyberflow MCP tools when available. They are intentionally workflow-agnostic and should be reused across workflow types by passing workflow_id, phase_id, and workspace.

• cyberflow_workflow: List workflows or show a selected workflow and guide path.
• cyberflow_get: Read a flow packet's current revision, gates, record IDs, Cybermem references, and ledger summaries.
• cyberflow_start: Create a workspace flow packet for a selected workflow.
• cyberflow_update: Revision-guarded additive phase updates, gate dispositions, status changes, and advancement.
• cyberflow_record: Revision-guarded transient flow records, including optional references to durable Cybermem nodes.
• cyberflow_correct: Revision-guarded exact correction or removal of flow, phase, and record state.
• cyberflow_ledger: Read, additively upsert, exactly correct, or delete ledger items.
• cyberflow_report: Produce distinct status, gate, handoff, or proofing reports.

If MCP tools are unavailable, manually maintain the same packet shape in tmp/cyberflow/<case-id>/flow.md.

V2 Mutation Discipline

• Call cyberflow_get before a mutation and pass its revision as expected_revision.
• If a revision conflict occurs, read the packet again and reconcile instead of overwriting newer flow state.
• Use cyberflow_update and ledger upsert for additive progress.
• Use cyberflow_correct for exact replacement or removal. Empty arrays clear collections.
• Use ledger correct or delete for exact ledger corrections.
• V1 packets are read through the v2 compatibility layer and persist as v2 on their next successful mutation.

Gate items use pending, satisfied, waived, or blocked. A waived gate requires both a rationale and a decision ID. A phase cannot be completed or advanced while a gate is pending/blocked or the phase has unresolved blockers. Use gate_updates to record dispositions and evidence references.

General Workflow

Use references/workflows/general.md for the default workflow. Its four phases are:

• Recon: Thoroughly understand the authorized system, scope, assets, entry points, trust boundaries, controls, and observability.
• Modeling: Build architecture and threat models that name assets, actors, boundaries, attacker positions, and security invariants.
• Analysis: Actively reason about vulnerabilities, primitives, chains, mitigations, confidence, and negative evidence.
• Proofing: Verify chains with end-to-end PoV executables or command sequences, and verify primitives with static analysis, traces, tests, or minimized reasoning.

Before moving to a later phase, satisfy every gate or explicitly waive it with a rationale and decision record, then clear or resolve phase blockers. Cyberflow enforces this on completion and advancement.

Deep Source Code Audit Workflow

Use references/workflows/source-code-audit-deep.md when the task is a deep audit of source code rather than broad target planning. This workflow adds:

• Deep recon of production code, project architecture, source/sink surfaces, bug history, and patch history.
• Source threat modeling of attacker-controlled sources, security-sensitive sinks, sanitizers, policy checks, and invariants.
• A required production-symbols ledger for non-test, non-example symbols.
• Per-symbol states: untouched, partial, and complete.
• Primitive proofing through static analysis and chain proofing through controlled end-to-end PoVs.

For the symbol ledger, only mark a symbol complete after all known references and relevant sources/sinks have been considered and evidence or residual risk is recorded.

Source Code UAF Audit Workflow

Use references/workflows/source-code-uaf-audit.md when the task is a focused source code audit for use-after-free or lifetime bugs. This workflow adds:

• UAF-specific recon of language/runtime mix, allocation/release APIs, invalidators, use sinks, callbacks, async boundaries, concurrency, FFI, sanitizer support, fuzzing support, and lifetime bug history.
• Lifetime and ownership modeling for object families, acquire/borrow/transfer/release/use paths, attacker-controlled ordering, and security invariants.
• Default ledgers for lifetime-symbols, lifetime-objects, ownership-flows, uaf-candidates, and active uaf-variants.
• Hybrid analysis through manual source review, static queries, sanitizer-backed execution, fuzzing, and race or async stress testing where appropriate.
• Controlled proofing through static proof packets, sanitizer logs, minimized reproducers, tests, or authorized end-to-end PoVs with side effects contained.

For UAF ledgers, completion means the relevant references, lifetime paths, sources, invalidators, stale-use sinks, guards, tests, and evidence have been considered, not merely that no crash was observed.

Source Code OOB Audit Workflow

Use references/workflows/source-code-oob-audit.md when the task is a focused source code audit for out-of-bounds reads or writes. This workflow adds:

• OOB-specific recon of language/runtime mix, buffer families, extent sources, memory-access sinks, parser and copy paths, sanitizer support, fuzzing support, and bounds bug history.
• Bounds and range modeling for buffers, indexes, offsets, lengths, capacities, arithmetic, casts, range checks, and memory-access invariants.
• Default ledgers for bounds-symbols, buffer-objects, range-flows, oob-candidates, and active oob-variants.
• Hybrid analysis through manual source review, static queries, sanitizer-backed execution, fuzzing, and targeted boundary tests where appropriate.
• Controlled proofing through static proof packets, sanitizer logs, minimized reproducers, tests, or authorized end-to-end PoVs with side effects contained.

For OOB ledgers, completion means relevant references, range paths, sources, transformations, checks, memory sinks, guards, tests, and evidence have been considered, not merely that no crash was observed.

Source Code Patch Workflow

Use references/workflows/source-code-audit-patch.md when code history is available and bug precedent matters. This workflow adds:

• History recon across commits, tags, release branches, pull requests, changelogs, advisories, CVEs, and disclosures.
• Patch-led modeling of previously fixed bugs, problematic modules, changed invariants, and incomplete-fix risk.
• Default ledgers for patch-commits, disclosures, problematic-modules, and active bug-variants.
• Root-cause patch diff analysis that compares pre-patch and post-patch behavior, references, sources, sinks, tests, and sibling variants.
• Active variant auditing that drives each bug-variants item to a disposition and proofing plan or rejection rationale.
• Primitive proofing through static analysis and chain proofing through controlled version-differential PoVs.

When public disclosure data is used, record URLs, publication dates, affected versions, fixed versions, and confidence in the disclosure-to-commit correlation.

Binary Decompile Workflow

Use references/workflows/binary-decompile.md when the task is to turn target binaries into readable decompiled source for a later workflow. This workflow adds:

• Target intake for binaries, firmware artifacts, architectures, symbols, dependencies, hashes, and output roots.
• Programmatic decompilation with pyghidra for most supported platforms or IPSW-oriented tooling for iOS firmware and platform artifacts.
• Ledgers for target-binaries, decompiled-units, major-systems, and symbol-renames.
• Agentic symbol recovery that walks major systems, reasons about roles and invariants, and renames symbols with evidence.
• Readability QA and a handoff packet for later source-code-audit-deep work on the decompiled source tree.

Do not conduct vulnerability research in this workflow. Possible flaw notes are only orientation for a later source audit, not findings.

Binary Patch Diff Workflow

Use references/workflows/binary-patch-diff.md when the task is to compare old and new binaries or firmware artifacts to understand a fixed bug and hunt variants. This workflow adds:

• Binary pair intake for vulnerable/fixed binaries, hashes, versions, architectures, firmware builds, symbols, and disclosure hints.
• Ghidra-based diffing for most platforms or IPSW-oriented extraction for iOS before Ghidra analysis.
• Ledgers for binary-pairs, changed-functions, disclosures, problematic-systems, and active bug-variants.
• Binary fix modeling from changed functions, decompiled diffs, xrefs, constants, control flow, and source/sink shape.
• Active binary variant auditing across sibling functions, subsystems, firmware components, release branches, and related source/sink paths.

For binary variant hunting, keep bug-variants as the active audit queue and store disposition in notes, tags, or metadata.

Dynamic Workflow

Use references/workflows/dynamic.md when no named workflow fits. This workflow adds:

• Fit and scope triage to explain why Dynamic is being used.
• Custom phase design with phase goals, exit gates, deliverables, and handoff expectations.
• Optional ledgers for work-items and scope-decisions, plus custom ledgers when coverage needs a different item type.
• Execution rules that keep scope changes, blockers, evidence, and phase status visible.
• Review and handoff guidance for switching to a targeted workflow later if one becomes appropriate.

Use ledgers only when coverage matters. Simple linear work can use records and phase updates without a ledger.

Pass custom_phases to cyberflow_start for a Dynamic flow. Use cyberflow_correct with target flow to add, remove, rename, or reorder Dynamic phases later; phase removal is rejected while records still reference that phase.

Cybermem Boundary

Keep phase state, proof obligations, decisions, blockers, next actions, and coverage ledgers in Cyberflow. When a primitive, chain, source, sink, invariant, mitigation, bug history item, asset, or trajectory becomes reusable beyond the active flow, save or correct it in Cybermem and record its node ID and revision in Cyberflow using cybermem_node_id and cybermem_revision. Do not maintain competing durable copies in both systems. When Cybermem is unavailable, Cyberflow records may carry the necessary standalone context.

Output Discipline

• Keep updates concise enough for another Codex turn to resume quickly.
• Split unproven behavior into hypotheses, verified primitive behavior, and chain claims.
• Use blocker records for scope uncertainty, uncontrolled proof paths, missing credentials, missing environments, or unresolved assumptions.
• Use decision records when parking a path, choosing a proof strategy, or narrowing the workflow.
• End handoffs with current phase, gate status, top hypotheses, strongest evidence, blockers, and next actions.