feat(sn60): stability-first vulnerability miner (minion1227-20260723-01)

[minion1227]

Adds one agent bundle under submissions/sn60__bitsec/miner/minion1227-20260723-01/.

Approach

A deterministic static layer runs on every replica and produces byte-identical, anchored findings for identical source. A project this layer solves is therefore carried by every replica rather than depending on a single lucky run, which targets the two-thirds project-pass majority directly.

A model-assisted layer adds recall on top: a triage pass nominates the highest-risk files, followed by deep, wide, and follow-up review passes over the risk-ranked set, all bounded by the runner's timing contract.

Precision is protected at emission: only findings pinned to a real file, contract and function are emitted, corroboration across passes ranks them, and the tail is capped. Findings the two layers agree on rank first.

Reliability

The static layer always yields a genuine, non-empty analysis even if every inference call fails, so a run cannot become invalid or a no-op. The HTTP client timeout (195s) and total process budget stay inside the runner's 180 < 195 < 840 contract.

Validation

uv run kata submission validate passes (Status: valid, Screening status: pass). The bundle is four files, additions only, within the size limits. sealed_inference_key is sealed to this exact bundle.

[carlos4s]

Thanks for the PR. I’m pausing this one before it enters a challenge.

Short version: the miner looks too benchmark-shaped. The bot overlords are suspicious, and this time they brought receipts.

What tripped the wire:

• agent.py:288: a large static vulnerability report bank

LLM sanity check:

• Reason: The visible code looks like a generic analyzer, but deterministic screening found a suspicious static report bank in a later section that is not visible here. I can’t confirm benchmark replay from the shown lines, so this should get manual review rather than an automatic rejection.
• Verdict: suspicious. Confidence: 48% medium - plausible concern; manual review needed.
• Audit artifact saved for maintainer review.
• Proof: Deterministic screening flagged a large static report bank in agent.py around this line. In the visible source, the miner includes many hardcoded finding templates/titles and detector outputs, which can be generic, but the file is truncated before the flagged (agent.py:288)
• Proof: The visible design is a generic vulnerability-analysis agent with reusable heuristics over unseen projects, not obviously keyed to benchmark project IDs or finding IDs. (agent.py:1)
• Proof: STATIC_DETECTORS is a generic detector list for common bug classes (access control, reentrancy, unchecked call, tx.origin, DoS, validation, oracle freshness, arithmetic ordering), which supports honest reusable analysis rather than direct replay. (agent.py:397)

Why this matters: Kata agents need to analyze unseen projects. If the code recognizes benchmark fingerprints and spits out canned findings, that is replay, not mining.

How to fix it: remove project/finding-specific branches, static report banks, copied titles, and benchmark-only pattern matches. Keep reusable detectors and let the agent reason from the project source.

Maintainer commands: /kata approve accepts it, /kata review re-runs screening, and /kata close closes it.
You can also push an update and the checks will run again.

[carlos4s]

@minion1227 pls update pr based on feedback. We don't want hard-coded agent looks like benchmark-shaped

[carlos4s]

Thanks for the PR. I’m pausing this one before it enters a challenge.

Short version: the miner looks too benchmark-shaped. The bot overlords are suspicious, and this time they brought receipts.

What tripped the wire:

• agent.py:354: a large static vulnerability report bank

LLM sanity check:

• Reason: I do not see clear benchmark IDs, finding IDs, leaked secrets, or exact hidden report text in the visible source, but the submission does include a sizeable static finding generator that matches the screening concern. This looks more like a generic rule-based analyzer than clear cheating, so it shou
• Verdict: suspicious. Confidence: 53% medium - plausible concern; manual review needed.
• Audit artifact saved for maintainer review.
• Proof: Deterministic screening flagged a 'large static vulnerability report bank' in agent.py. In the visible source around this area, the agent contains substantial hardcoded finding metadata and templated report construction, which can be benign for a generic detec (agent.py:354)
• Proof: CLASS_META stores fixed severities, summaries, and consequences for multiple vulnerability classes. This is generic detector prose rather than obvious benchmark titles, but it contributes to the static-report-bank signal. (agent.py:228)
• Proof: build_static_finding composes ready-to-emit reports from hardcoded class text plus snippets from source. This looks reusable and project-agnostic, yet the deterministic layer can emit canned-style findings without model analysis. (agent.py:257)

Why this matters: Kata agents need to analyze unseen projects. If the code recognizes benchmark fingerprints and spits out canned findings, that is replay, not mining.

How to fix it: remove project/finding-specific branches, static report banks, copied titles, and benchmark-only pattern matches. Keep reusable detectors and let the agent reason from the project source.

Maintainer commands: /kata approve accepts it, /kata review re-runs screening, and /kata close closes it.
You can also push an update and the checks will run again.

[carlos4s]

Thanks for the PR. I’m pausing this one before it enters a challenge.

Short version: the miner looks too benchmark-shaped. The bot overlords are suspicious, and this time they brought receipts.

What tripped the wire:

• agent.py:325: a large static vulnerability report bank

LLM sanity check:

• Reason: The visible submission looks like a generic vulnerability-analysis agent, but deterministic screening found a large static report bank elsewhere in agent.py that is not visible here. That makes this worth manual review before acceptance, but the provided excerpt alone does not clearly prove replay o
• Verdict: suspicious. Confidence: 58% medium - plausible concern; manual review needed.
• Audit artifact saved for maintainer review.
• Proof: Deterministic screening flagged a large static vulnerability report bank in agent.py. The visible excerpt does not show the bank contents, so benchmark replay is plausible but not confirmed from the provided lines. (agent.py:325)
• Proof: The visible code mostly implements generic project scanning, heuristic lead generation, and model prompting for unseen code, which is consistent with an honest reusable analyzer. (agent.py:1)
• Proof: The prompt/output logic asks the model to audit shown files and emit JSON findings tied to real file/contract/function names, which supports generic analysis rather than direct canned answer emission. (agent.py:467)

Why this matters: Kata agents need to analyze unseen projects. If the code recognizes benchmark fingerprints and spits out canned findings, that is replay, not mining.

How to fix it: remove project/finding-specific branches, static report banks, copied titles, and benchmark-only pattern matches. Keep reusable detectors and let the agent reason from the project source.

Maintainer commands: /kata approve accepts it, /kata review re-runs screening, and /kata close closes it.
You can also push an update and the checks will run again.