Responsible disclosure¶

Crucible can prepare evidence. It never sends a report, chooses a severity, or decides publication timing. Those are human decisions made against the affected project's current policy.

Before contacting anyone¶

Do not report from a fuzzer artifact or generated markdown alone. The minimum record is:

• crafted input reproduces under a named harness and target build;
• clean control does not reproduce;
• source at the attributed site and its callers has been read;
• primitive is stated precisely: read/write, bounds, attacker control, and consequence;
• target checkout commit and dirty state are recorded;
• harness binary, PoC, control, environment, and raw output are hash-bound;
• current upstream HEAD has been tested;
• existing issues, advisories, and CVEs have been searched;
• affected versions are supported by target-specific evidence;
• severity and any CVSS vector are operator-ratified;
• every quoted frame, line, and trace came from the cited build.

An Exact or Stable identity helps organize evidence; neither is a source-level root-cause decision.

Separate observation, primitive, and impact¶

Use three explicit statements:

1. Observation: what the process and sanitizer did.
2. Primitive: what source analysis and the witness establish.
3. Impact: what a real deployment boundary allows.

Example:

Observation: ASan reports a 32-byte heap out-of-bounds read in the model loader.
Primitive: file-controlled dimensions make the consumer read beyond a 32-byte allocation.
Impact: loading a crafted model terminates the tested service process. No code execution,
cross-tenant disclosure, or privilege gain was demonstrated.

Do not turn heap-buffer-overflow into “RCE,” a pointer disclosure into “ASLR defeated” on every build, or a process abort into “remote” without establishing the network path.

Severity and CVSS¶

Crucible deliberately does not assign an automatic score. A CVSS vector requires facts that a crash class cannot provide:

• attack vector and reachable trust boundary;
• attack complexity and environmental preconditions;
• privileges and user interaction;
• scope;
• demonstrated confidentiality, integrity, and availability impact.

Record the full vector and the source of each metric. Keep submitted, coordinator, maintainer, and assigner values in separate provenance fields; disagreement is information, not a value to overwrite.

Choose the current channel¶

1. Read the target's SECURITY.md and security policy at the commit/date you are using.
2. Prefer the vendor's private channel when it exists and is responsive.
3. GitHub private vulnerability reporting works only when the repository has enabled it; check the repository rather than assuming a draft advisory reaches maintainers. See GitHub's private-reporting documentation.
4. When vendor coordination breaks down or multiple vendors are affected, consider CERT/CC VINCE. CERT/CC recommends attempting vendor contact first and prioritizes only some reports.
5. Use a CNA or coordinator only after checking its current scope and requirements. Program scope, availability, and response expectations change; do not preserve old timelines in this guide.

Keep a receipt: channel, artifact/content identifier, exact text sent, attachments and hashes, timestamp, tracking ID, and later corrections. A URL in an internal ledger is not proof that the associated content was this finding's direct filing.

Write a self-contained report¶

# <precise primitive> in <component> via <input/path>

## Tested configuration
- target commit and dirty state
- platform, compiler, sanitizer/runtime
- harness/public entry point
- binary, control, and PoC SHA-256

## Observation
- process exit/signal and raw sanitizer excerpt
- exact source frames from this build

## Root cause
- attacker-controlled field
- missing/incorrect invariant
- source data flow to the fault

## Reproduction
- exact build and run commands
- expected control result
- expected crafted result

## Impact
- demonstrated consequence
- explicitly unestablished stronger consequences

## Suggested invariant
- what must be checked or derived
- sibling sites examined

Generated Crucible reports are internal substrates for this work. They are not submission templates and intentionally contain no automatic CVSS or affected-version answer.

Provide a fix only when it is verified¶

A patch makes a stronger claim than a finding: it says the invariant now holds without breaking valid behavior.

flowchart LR
    F[Reproduced finding] --> G[Define the invariant]
    G --> P[Apply and compile patch]
    P --> C[Crafted input rejected safely]
    C --> R[Real artifacts still work]
    R --> L[Patched lines proved live]
    L --> S[Sibling sites reviewed]
    S --> O[Patch evidence bundle]

Verify:

• vulnerable build reproduces the expected primitive;
• patched build rejects or handles the same bytes safely;
• genuine production artifacts still load or execute;
• test coverage reaches the new check;
• a different retained positive remains visible;
• duplicated loaders and sibling call sites are covered;
• the patch was built into the binary actually tested.

Do not call a fix complete because the motivating PoC stopped crashing. A broad rejection, dead code, or blinded harness can produce the same observation.

Corrections¶

When a published detail is unsupported or wrong:

1. preserve the original sent/published artifact;
2. state the exact claim being corrected;
3. provide the evidence that supports the replacement;
4. distinguish attribution/detail correction from validity of the underlying vulnerability;
5. post through the same public or coordinated channel when possible;
6. retain both records and their hashes in the disclosure ledger.

Do not silently edit history or broaden the correction beyond what the audit established.

Coordination and publication¶

There is no universal deadline that overrides the target's policy, coordinator plan, user risk, or active remediation. Agree on milestones where possible: receipt, reproduction, patch review, release, advisory/CVE state, and publication date.

If the vendor is unresponsive, document contact attempts and use an appropriate coordinator. Public issue or PR text can itself disclose the vulnerable condition, so treat a “fix-only” diff as a disclosure decision.

Before publication, re-run the integrity audit against the artifact as actually sent or published:

• CVSS vector and source;
• submitted and assigner CWE separately;
• affected-version evidence;
• tested build and dirty state;
• frame/function/file/line provenance;
• whether any classifier output substituted for replay and source inspection;
• corrections already present in the thread.

Ethics and authorization¶

Use Crucible on software and infrastructure you own or are authorized to assess.