[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-77952":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":9,"rankLanguage":9,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":9,"pushedAt":9,"updatedAt":26,"readmeContent":27,"aiSummary":28,"trendingCount":15,"starSnapshotCount":15,"syncStatus":29,"lastSyncTime":30,"discoverSource":31},77952,"OpenHack","hadriansecurity\u002FOpenHack","hadriansecurity","Lightweight, file-based workspace for source-guided whitebox security review.",null,"Python",653,94,6,1,0,5,19,614,18,9.93,"MIT License",false,"main",true,[],"2026-06-12 02:03:45","\u003Cp align=\"center\">\n  \u003Cimg src=\"public\u002Fhadrian.png\" alt=\"Hadrian\" width=\"320\">\n\u003C\u002Fp>\n\n\u003Ch1 align=\"center\">Hadrian OpenHack\u003C\u002Fh1>\n\n\u003Cp align=\"center\">\u003Cem>A lightweight, file-based workspace for source-guided whitebox security review.\u003C\u002Fem>\u003C\u002Fp>\n\n[![License: MIT](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Flicense-MIT-blue.svg)](LICENSE)\n[![Python 3.9+](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fpython-3.9%2B-blue.svg)](https:\u002F\u002Fwww.python.org\u002F)\n\n`openhack` is a set of agents and tools that mimics how the\nHadrian research team performs automated vulnerability research. The methodology\nhas been adjusted so it can run inside a common model harness — Claude Code,\nCodex, Cursor, or a custom runner — while keeping durable state in plain files:\ncloned source, recon items, scenario prompts, scenario results, finding\ncandidates, triage decisions, findings, and logs. The harness provides model\nexecution, terminal access, repository access, and human-in-the-loop approval;\nthis tool provides the durable workflow and review artifacts.\n\n**The core idea:** checkpointed, scenario-first review. Recon discovers surfaces,\na router agent turns them into scoped scenarios, expert agents prove or reject\neach scenario, and an independent triage agent decides which verified candidates\nbecome final findings. The human approves every phase transition.\n\n---\n\n\u003Cp align=\"center\">\n  \u003Cimg src=\".\u002Fpublic\u002Flazy.jpeg\">\n\u003C\u002Fp>\n\n## Quick Start\n\nThe easiest way to get started is to open this repository in a coding harness\nsuch as Codex, Claude Code, or Cursor and ask it:\n\n```text\nInitiate a whitebox pentest on https:\u002F\u002Fgithub.com\u002Fexample\u002Fapp.git\n```\n\nThe harness should follow `AGENTS.md`: initialize a run, summarize each\ncheckpoint, and ask before moving to the next phase.\n\n**Manual CLI flow:** install the CLI from the repository root:\n\n```bash\npython3 -m pip install -e .\n```\n\nThis project is currently distributed as a workspace-first repository. The\nroot-level `agents\u002F`, `config\u002F`, `templates\u002F`, and writable `runs\u002F` directories\nare runtime data, so the supported install model is a cloned checkout with an\neditable install. If you invoke `openhack` from outside the checkout, set\n`OPENHACK_ROOT` to the repository root.\n\n**2. Walk through a run.** Execute one command at a time. Each command prints a\ncheckpoint summary and the next command to run — review the output and approve\nbefore continuing.\n\n```bash\n# Create a run from a fresh git checkout\nopenhack init-run demo https:\u002F\u002Fgithub.com\u002Fexample\u002Fapp.git --run-id demo-001\n\n# Choose expert scope, then run reconnaissance\nopenhack run-recon demo demo-001 --all-agents\n\n# Or scope the run to selected experts\nopenhack run-recon demo demo-001 \\\n  --expert injection \\\n  --expert broken-access-control\n\n# Optional: enrich recon with bundled Semgrep rules\nopenhack run-recon demo demo-001 --all-agents --semgrep\n\n# Generate the scenario backlog from routing units in one approved routing phase\nopenhack create-scenarios demo demo-001\n\n# After the router answers the prompt, record the selected backlog\nopenhack record-scenario-backlog demo demo-001 router-result.json\n\n# Render a scenario prompt for an expert agent\nopenhack render-scenario-prompt demo demo-001 S001\n\n# Record an expert's verified result (materializes finding-candidates\u002F)\nopenhack record-scenario-result demo demo-001 S001 result.json\n\n# Render and record independent triage before final findings are created\nopenhack render-finding-triage-prompt demo demo-001 S001-F001\nopenhack record-finding-triage demo demo-001 S001-F001 triage-result.json\n\n# Resume or hand off: prints current counts + next checkpoint\nopenhack summarize-run demo demo-001\n```\n\n> **Resuming a run?** Run `openhack summarize-run \u003Ctarget> \u003Crun-id>` to see counts\n> and the next checkpoint command without executing anything.\n\nSet `OPENHACK_ROOT` to this workspace path if you invoke the CLI from\noutside the repo root. See [`docs\u002FQUICKSTART.md`](docs\u002FQUICKSTART.md) for more\ndetail.\n\n---\n\n## How It Works\n\nHadrian is a state machine around files. A command advances the run to the next\ndurable state, an agent answers the exact prompt for that state, and the next\nrecorder command validates the answer before materializing new work. Humans\napprove phase transitions; the long-running parts are still item-by-item loops,\nnot bulk analysis.\n\nThe durable chain stays narrow on purpose:\n\n```text\nrecon item  →  routing unit  →  scenario  →  scenario result  →  finding candidate  →  triage decision  →  finding\n```\n\nThe workflow widens only where evidence requires it: one routing unit may fan\nout to several experts, one scenario may emit several finding candidates, and\neach candidate then gets its own independent triage decision.\n\n```mermaid\n%%{init: {\n  'theme': 'base',\n  'themeVariables': {\n    'background': '#0a0a0a',\n    'fontFamily': '\"Inter\", \"IBM Plex Sans\", system-ui',\n    'primaryColor': '#1a1a1a',\n    'primaryBorderColor': '#2e2e2e',\n    'primaryTextColor': '#e8e8e8',\n    'lineColor': '#4a4a4a',\n    'edgeLabelBackground': 'transparent',\n    'clusterBkg': '#0a0a0a',\n    'clusterBorder': '#2e2e2e',\n    'tertiaryColor': '#0a0a0a'\n  },\n  'flowchart': {\n    'htmlLabels': true,\n    'nodeSpacing': 50,\n    'rankSpacing': 70,\n    'curve': 'basis'\n  },\n  'themeCSS': 'svg { background: #0a0a0a !important; } .flowchart { background: #0a0a0a !important; } .node rect, .node polygon { rx: 6px; ry: 6px; } .nodeLabel { font-family: \"Inter\", \"IBM Plex Sans\", system-ui !important; line-height: 1.2; } .node-title { color: #e8e8e8; font-size: 14px; font-weight: 500; } .node-subtitle { color: #a0a0a0; font-size: 12px; font-weight: 400; } .gate .node-title, .gate .node-subtitle, .agent .node-title, .agent .node-subtitle { color: #ffffff; } .flowchart-link { stroke: #4a4a4a !important; stroke-width: 1px !important; } marker path { fill: #4a4a4a !important; stroke: #4a4a4a !important; transform: scale(.72); transform-origin: center; } .edgeLabel, .edgeLabel p, .edgeLabel span, .edgeLabel div { background: transparent !important; color: #888888 !important; fill: #888888 !important; font-family: \"Inter\", \"IBM Plex Sans\", system-ui !important; font-size: 11px !important; font-style: italic !important; font-weight: 400 !important; } .edgeLabel rect, .labelBkg { opacity: 0 !important; fill: transparent !important; background: transparent !important; }'\n}}%%\nflowchart TD\n  classDef gate fill:#FF003D,stroke:#FF003D,stroke-width:1.5px,color:#ffffff;\n  classDef command fill:#1a1a1a,stroke:#2e2e2e,stroke-width:1px,color:#e8e8e8;\n  classDef agent fill:#161616,stroke:#FF003D,stroke-width:1.5px,color:#ffffff;\n  classDef artifact fill:#1a1a1a,stroke:#2e2e2e,stroke-width:1px,color:#e8e8e8;\n  classDef loop fill:#1a1a1a,stroke:#2e2e2e,stroke-width:1px,color:#e8e8e8;\n  classDef final fill:#1a1a1a,stroke:#2e2e2e,stroke-width:1px,color:#e8e8e8;\n\n  start[\"\u003Cspan class='node-title'>Operator request\u003C\u002Fspan>\"]:::gate\n  init[\"\u003Cspan class='node-title'>init-run\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>snapshot target and run metadata\u003C\u002Fspan>\"]:::command\n  scope[\"\u003Cspan class='node-title'>Expert scope approved\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>all agents or selected experts\u003C\u002Fspan>\"]:::gate\n  recon[\"\u003Cspan class='node-title'>run-recon\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>routes, inputs, sinks, boundaries, exposures\u003C\u002Fspan>\"]:::agent\n  enrich[\"\u003Cspan class='node-title'>Optional Semgrep enrichment\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>source-pattern hints\u003C\u002Fspan>\"]:::command\n  units[\"\u003Cspan class='node-title'>routing-units.jsonl\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>clustered review surfaces\u003C\u002Fspan>\"]:::artifact\n  routerPrompt[\"\u003Cspan class='node-title'>create-scenarios\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>router prompt, no extra gate\u003C\u002Fspan>\"]:::command\n  router[\"\u003Cspan class='node-title'>Scenario-router answer\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>scenarios + coverage decisions\u003C\u002Fspan>\"]:::agent\n  backlog[\"\u003Cspan class='node-title'>record-scenario-backlog\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>validated scenario queue\u003C\u002Fspan>\"]:::artifact\n  scenarioLoop[\"\u003Cspan class='node-title'>Scenario loop\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>render S### prompt → expert subagent → record result\u003C\u002Fspan>\"]:::agent\n  candidates[\"\u003Cspan class='node-title'>finding-candidates\u002F\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>pending_triage\u003C\u002Fspan>\"]:::artifact\n  triageLoop[\"\u003Cspan class='node-title'>Finding triage loop\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>render S###-F### prompt → triage subagent → record decision\u003C\u002Fspan>\"]:::agent\n  findings[\"\u003Cspan class='node-title'>findings\u002F*.md\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>accepted or downgraded only\u003C\u002Fspan>\"]:::final\n  validate[\"\u003Cspan class='node-title'>validate-run\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>schema, coverage, and integrity checks\u003C\u002Fspan>\"]:::command\n  resume[\"\u003Cspan class='node-title'>summarize-run\u003C\u002Fspan>\u003Cbr\u002F>\u003Cspan class='node-subtitle'>counts + next checkpoint\u003C\u002Fspan>\"]:::command\n\n  start --> init --> scope --> recon --> units --> routerPrompt --> router --> backlog\n  recon -. rerun with Semgrep .-> enrich\n  enrich -. normalized into recon output .-> units\n  backlog --> scenarioLoop\n  scenarioLoop -->|verified with findings| candidates\n  scenarioLoop -->|rejected, candidate, or needs_context| resume\n  candidates --> triageLoop\n  triageLoop -->|accepted or downgraded| findings --> validate\n  triageLoop -->|duplicate, rejected, or needs_context| validate\n  validate -->|handoff or fix-forward| resume\n  linkStyle default stroke:#4a4a4a,stroke-width:1px;\n```\n\n### Output States\n\n| State | Primary outputs | What it means |\n|---|---|---|\n| **Initialized** | `run-config.yaml`, `sourcecode\u002F`, `run-state.jsonl` | The target is pinned to a source checkout, commit, branch, and run id. |\n| **Recon complete** | `recon-output\u002Frecon-items.jsonl`, inventories, `routing-units.jsonl` | The workspace has mapped review surfaces, but no vulnerability has been proven. |\n| **Router prompt ready** | `scenarios\u002Fscenario-router-prompt.md` | A scenario-router agent has a compact, evidence-based prompt; it has not created durable scenarios yet. |\n| **Backlog recorded** | `scenarios\u002Findex.jsonl`, `scenarios\u002Fbacklog\u002FS###.json`, `S###.md`, `coverage-decisions.json` | The router output passed coverage validation and became the review queue. |\n| **Scenario loop in progress** | `scenarios\u002Ffinished\u002FS###.json` | Each finished scenario has its own prompt hash, subagent id, reviewed files, status, and evidence. |\n| **Candidate triage pending** | `finding-candidates\u002FS###-F###.json` | A scenario expert proposed a verified issue; it is still not a final finding. |\n| **Triage loop in progress** | `finding-triage\u002Fprompts\u002F`, `finding-triage\u002Fdecisions\u002F` | Each candidate receives an independent reportability, dedupe, confidence, and severity review. |\n| **Findings materialized** | `findings\u002F*.md` | Only accepted or downgraded triage decisions write final finding reports. |\n| **Validated** | command output from `validate-run` | Schemas, prompt hashes, coverage gates, candidate\u002Ftriage consistency, and final finding materialization have been checked. |\n\n### Loops and Gates\n\n**Human gates are phase gates.** The operator approves expert scope before recon,\nscenario routing after recon, the scenario backlog after the router answer, and\nthe finding-triage backlog after candidate creation. Approving a backlog means\n\"process every unfinished item,\" not \"summarize the batch.\"\n\n**Scenario review is a queue.** Every `S###` is rendered as a standalone prompt,\nassigned to exactly one expert subagent, reviewed against source, and recorded\nwith `review_mode: \"per-scenario-subagent\"`. Status can be `verified`,\n`candidate`, `rejected`, or `needs_context`; only `verified` results may emit\nfinding candidates.\n\n**Finding triage is a second queue.** Every `S###-F###` candidate gets a\nstandalone triage prompt and a separate triage subagent. Decisions can be\n`accepted`, `downgraded`, `duplicate`, `rejected`, or `needs_context`; only\n`accepted` and `downgraded` materialize Markdown findings.\n\n**Resume is always derived from files.** `summarize-run` reads the run directory\nand reports counts plus the next missing durable phase, so interrupted work can\ncontinue without reconstructing model context.\n\nAll workflow commands append audit records to `logs\u002Fevents.jsonl` and\n`trace.jsonl`. Those logs record what happened, the artifacts involved, and the\nhandoff status; final findings still come only through the recorded scenario and\ntriage chain above.\n\n---\n\n## Core Concepts\n\n| Artifact | What it is |\n|---|---|\n| **Recon item** | A discovered place worth review — a route, sink, auth boundary, manifest, upload handler, or parser entrypoint. |\n| **Routing unit** | A deterministic cluster around an endpoint, handler, parameter, upload\u002Fdownload path, SQL\u002FHTML\u002Fredirect sink, parser, auth flow, static exposure, or dependency surface. |\n| **Scenario** | One routing unit + one expert + one proof question. The same unit or file may appear in multiple scenarios when multiple root-cause experts are relevant. |\n| **Scenario result** | A recorded expert answer for one scenario: verified, rejected, or needs more context. |\n| **Finding candidate** | A scenario expert's proposed verified vulnerability, pending independent triage. |\n| **Triage decision** | An independent one-candidate admission decision that checks reportability, scope, confidence, and severity. |\n| **Finding** | A triage-accepted vulnerability. One scenario can produce multiple candidates when separate parameters, sinks, or trust boundaries are independently vulnerable. |\n\n**Expert scope** is chosen before recon. Use `all agents` for broad coverage, or\nselect one or more expert IDs to focus routing. The chosen scope is written to\n`run-config.yaml`, and later coverage, router prompts, and backlog recording are\nconstrained to that same set of experts. After recon, one approval covers\ncreating the router prompt, getting the router answer, and recording the\nscenario backlog; the prompt render is not a separate checkpoint.\n\n**Findings are accepted only when recorded through `scenarios\u002Ffinished\u002F`,\n`finding-candidates\u002F`, `finding-triage\u002Fdecisions\u002F`, and `findings\u002F`.** Do not\nstart a pentest with a broad LLM source sweep — the contract is command-first\nand artifact-first.\n\nLogs are audit artifacts, not private reasoning transcripts: what was done, what\nevidence was used, what decision was made, status, and handoffs.\n\n---\n\n## Command Reference\n\nRun commands from the repository root (or set `OPENHACK_ROOT`).\n\n| Command | Purpose |\n|---|---|\n| `openhack init-run \u003Ctarget> \u003Cgit-url> [--run-id \u003Cid>] [--branch \u003Cbranch>]` | Clone the target into a fresh run workspace. |\n| `openhack run-recon \u003Ctarget> \u003Crun-id> --all-agents [--semgrep]` | Source reconnaissance with every configured security expert; `--semgrep` adds bundled rule hints. |\n| `openhack run-recon \u003Ctarget> \u003Crun-id> --expert \u003Cid> [--expert \u003Cid> ...] [--semgrep]` | Source reconnaissance scoped to selected expert IDs. |\n| `openhack create-scenarios \u003Ctarget> \u003Crun-id>` | Build the scenario-router agent prompt from routing units and compact recon output. |\n| `openhack record-scenario-backlog \u003Ctarget> \u003Crun-id> \u003Crouter-result.json>` | Materialize the router's selected backlog into `scenarios\u002Fbacklog\u002F`. |\n| `openhack render-scenario-prompt \u003Ctarget> \u003Crun-id> \u003CS###>` | Render a scenario prompt for an expert agent. |\n| `openhack record-scenario-result \u003Ctarget> \u003Crun-id> \u003CS###> \u003Cresult.json>` | Record an expert result and materialize any finding candidates. |\n| `openhack record-scenario-result \u003Ctarget> \u003Crun-id> \u003Cbundle.json>` | Record a multi-scenario bundle (top-level `results` array). |\n| `openhack render-finding-triage-prompt \u003Ctarget> \u003Crun-id> \u003CS###-F###>` | Render a prompt for the independent finding-triage agent. |\n| `openhack record-finding-triage \u003Ctarget> \u003Crun-id> \u003CS###-F###> \u003Ctriage-result.json>` | Record reportability, dedupe, confidence, and severity due diligence; accepted\u002Fdowngraded decisions materialize final findings. |\n| `openhack summarize-run \u003Ctarget> \u003Crun-id>` | Print current counts and the next checkpoint command. |\n| `openhack log-event \u003Ctarget> \u003Crun-id> \u003Cactor> \u003Cstatus> \u003Csummary>` | Append an operational log event. |\n| `openhack validate-run [\u003Ctarget> \u003Crun-id>]` | Validate the whole repo or a specific run. |\n\n### What recon produces\n\n`run-recon` writes `recon-items.jsonl` plus lightweight `routes.jsonl`,\n`inputs.jsonl`, `sinks.jsonl`, `exposures.jsonl`, `request-boundaries.jsonl`,\n`coverage-gaps.json`, and `routing-units.jsonl`. Routing units cluster noisy\nline hits into review surfaces before the LLM router sees them. With\n`--semgrep`, raw `semgrep-results.json` is also written and normalized into the\nsame recon items, routing units, and routing requirements.\n**Semgrep hits are hints, not verified vulnerabilities.** Recon also records\nexpert scope in `run-config.yaml`; rerun with `--all-agents` or repeated\n`--expert` options to change scope before scenario routing.\n\n### What the router does\n\n`create-scenarios` does not create final scenarios itself. It writes\n`runs\u002F\u003Ctarget>\u002F\u003Crun-id>\u002Fscenarios\u002Fscenario-router-prompt.md`, which the\nscenario-router agent answers with JSON containing top-level `scenarios` and\n`coverage_decisions` arrays. The prompt prioritizes `routing-units.jsonl` and\nuses compact inventory and Semgrep summaries instead of the full raw\ninventory dump. `record-scenario-backlog` validates that every mandatory\n`routing_unit_id + expert`, recon path, and path\u002Fexpert requirement is either\nrepresented by a scenario or explicitly explained by a coverage decision before\nmaterializing the backlog.\nThe router prompt is an intermediate artifact inside the approved routing phase;\npause for human review after the backlog is materialized, not between prompt\ncreation and router answer.\nThe prompt and validator only use experts selected before recon, so a focused\nrun does not create backlog work for unselected experts.\n\n### What finding triage does\n\nScenario experts write proposed vulnerabilities into the scenario result's\n`findings` array, but `record-scenario-result` stores them as\n`finding-candidates\u002FS###-F###.json`. A candidate is not a final report.\n\nFor each candidate, render a dedicated prompt for the `finding-triage` agent.\nThat agent independently checks evidence quality, reportability, duplicate or\nmerge scope, confidence, and severity due diligence. `record-finding-triage`\nrecords the decision under `finding-triage\u002Fdecisions\u002F`; only `accepted` and\n`downgraded` decisions create Markdown reports under `findings\u002F`.\n\n---\n\n## Run Layout\n\nEvery run lives under `runs\u002F\u003Ctarget>\u002F\u003Crun-id>\u002F`:\n\n```text\nruns\u002F\u003Ctarget>\u002F\u003Crun-id>\u002F\n  sourcecode\u002F           Fresh git checkout for this run.\n  recon-output\u002F         Recon items, inventories, routing units, coverage gaps.\n  scenarios\u002F\n    backlog\u002F            Scenario JSON and rendered expert prompts.\n    finished\u002F           Recorded scenario results.\n  finding-candidates\u002F   Proposed findings emitted by scenario experts.\n  finding-triage\u002F\n    prompts\u002F            Rendered one-candidate triage prompts.\n    decisions\u002F          Recorded triage decisions.\n  findings\u002F             Triage-accepted findings for this run.\n  logs\u002F                 Structured event log.\n  run-config.yaml       Target URL, commit, branch, expert scope, workflow metadata.\n  run-state.jsonl       Run lifecycle events.\n  trace.jsonl           Structured agent and command trace.\n```\n\n`runs\u002F**`, `sourcecode\u002F`, nested `sourcecode\u002F`, and `targets\u002F` are gitignored so\ntarget code and review artifacts never get committed.\n\n---\n\n## Repository Structure\n\n```text\nconfig\u002F                            Registry, defaults, and schema contracts.\nagents\u002F\n  orchestration\u002F                   Run lifecycle, scenario routing, finding triage.\n  reconnaissance\u002F                  Source recon agents that emit recon items.\n  experts\u002F                         OWASP\u002FMITRE-aligned root-cause family experts.\n  shared\u002F                          Protocol all agents follow.\nsrc\u002Fopenhack\u002F     Shared implementation and editable-install CLI.\ntemplates\u002F                         Scenario, result, finding, and triage templates.\ndocs\u002F                              Operating model and quickstart notes.\nruns\u002F                              Generated run workspaces (gitignored).\n```\n\n---\n\n## Agent Model\n\nAgents are Markdown manifests — intentionally compact, but each expert must be\noperational. It states when it should receive a scenario, what evidence proves or\nrejects the root-cause family, common false positives, and where to handoff\ncross-family leads.\n\nThe workflow roles:\n\n- **Orchestration agents** own run lifecycle, scenario routing, and finding triage.\n- **Reconnaissance agents** find surfaces — routes, files, sinks, auth boundaries,\n  upload paths, parser entrypoints, manifests, and debug\u002Fadmin areas.\n- **Expert agents** own OWASP\u002FMITRE-aligned root-cause families. The current\n  registry defines **12 expert families** as Markdown manifests in\n  `agents\u002Fexperts\u002F`; each file's YAML frontmatter declares the expert id,\n  category, ownership, standards, and routing signals.\n\nThe expert families are:\n\n| Expert ID | Standard-aligned title |\n|---|---|\n| `broken-access-control` | A01:2025 - Broken Access Control |\n| `security-misconfiguration` | A02:2025 - Security Misconfiguration |\n| `software-supply-chain-failures` | A03:2025 - Software Supply Chain Failures |\n| `cryptographic-failures` | A04:2025 - Cryptographic Failures |\n| `injection` | A05:2025 - Injection |\n| `memory-buffer-boundary-errors` | CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer |\n| `insecure-design` | A06:2025 - Insecure Design |\n| `authentication-failures` | A07:2025 - Authentication Failures |\n| `software-data-integrity-failures` | A08:2025 - Software or Data Integrity Failures |\n| `sensitive-information-exposure` | CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor |\n| `path-traversal-unrestricted-upload` | CWE-22 \u002F CWE-434 - Path Traversal and Unrestricted Upload |\n| `unrestricted-resource-consumption` | API4:2023 \u002F CWE-770 - Unrestricted Resource Consumption |\n\n> **Surfaces are not expert ownership labels.** API, GraphQL, upload, parser,\n> admin, and native boundaries are recon signals that fan out to multiple\n> experts. Impacts like RCE or account takeover are finding impacts. A verified\n> finding must name one primary root-cause owner.\n>\n> SSRF is covered inside `broken-access-control` because OWASP Top 10:2025 maps\n> CWE-918 to A01:2025; the dedicated outbound-client checklist is preserved in\n> that expert rather than kept as a separate family.\n\n---\n\n## Development\n\nValidate the workspace or a specific run:\n\n```bash\nopenhack validate-run\nopenhack validate-run \u003Ctarget> \u003Crun-id>\n```\n\nSee [`AGENTS.md`](AGENTS.md), [`CONTRIBUTING.md`](CONTRIBUTING.md), and\n[`docs\u002FOPERATING_MODEL.md`](docs\u002FOPERATING_MODEL.md) for deeper documentation.\n\n---\n\n## Disclaimer\n\nA note before you use this: this project is an experimental research prototype, provided as-is and without warranty of any kind. It is not a security product, has not been independently audited, and is not intended to be relied upon for any decision involving the security, safety, or correctness of software. It will miss real vulnerabilities and may report issues that do not exist. It is not a substitute for a professional security audit, manual code review, or established static analysis tools, and should never be used as a sole or primary means of assessing risk. By using it, you accept full responsibility for any outcomes, and the authors disclaim all liability for any damages, losses, or consequences arising from its use.\n\n## License\n\nMIT. See [`LICENSE`](LICENSE).\n","Hadrian OpenHack 是一个轻量级的基于文件的工作空间，用于源代码引导的白盒安全审查。它通过一系列代理和工具模仿了Hadrian研究团队进行自动化漏洞研究的方法，能够在常见的模型框架（如Claude Code, Codex, Cursor或自定义运行器）中运行，并将持久状态保存在普通文件中，包括克隆源码、侦察项、场景提示等。该项目支持Python 3.9+版本，采用MIT许可证开放源代码。其核心理念是基于检查点的场景优先审查，通过发现表面、路由代理生成范围场景、专家代理验证或拒绝每个场景以及独立的分类代理决定最终结果来完成整个流程。每一步都需要人工批准，确保准确性与安全性。适用于需要对软件项目进行深度安全审计的场景，尤其是当团队希望以结构化方式记录和管理审查过程时。",2,"2026-06-11 03:56:17","CREATED_QUERY"]