HiveGrid-Wireframes/hivegrid-cloud/docs/improvement-plan/06-plugin-system/security-findings

Phase 06 — Security Findings

This directory holds per-finding remediation detail documents produced after the internal self-audit (docs/security/plugin-internal-findings.md) and after the external pen-test (Cure53 / SySS / secfault / etc., per docs/security/plugin-audit-rfp.md).

Folder structure

security-findings/
├── README.md                                 # this file
├── F-001-capability-consent.md               # one file per Critical/High finding
├── F-002-per-instruction-fuel.md
├── F-003-audit-hash-chain.md
├── ...
└── external/
    └── 2026-MM-DD-<firm>-F-<id>.md           # external-audit findings

When to create a file here

Create a per-finding file for every Critical and High finding from either source. Medium / Low findings can be tracked as one-line entries in the parent inventory (docs/security/plugin-internal-findings.md or the external sanitised report) until they are scheduled for remediation, at which point they get promoted to a file here.

A finding file must contain:

1. ID + severity — F-NNN (internal) or <firm>-<NNN> (external). Severity = Critical/High/Medium/Low + CVSS or DREAD if the auditor provided.
2. Asset — link to the matching A-NN in docs/security/plugin-threat-model.md.
3. Description — what's wrong, what an attacker can do, business impact.
4. Reproduction — minimal repro steps the auditor / engineer can follow.
5. Remediation plan — design + concrete file/line targets.
6. Status — open, in-progress, remediated, accepted-residual (with operator sign-off), or wont-fix (with explicit justification + acceptance).
7. Remediation commits — list of SHAs once landed.
8. Re-test result — auditor's re-test verdict for external findings, or the responsible engineer's signed-off internal review for internal findings.

Template

# F-NNN: <short title>

**Severity:** Critical | High | Medium | Low
**Asset:** [A-NN](../../../security/plugin-threat-model.md#1-asset-catalogue)
**Source:** internal self-audit (2026-MM-DD) | <firm> <date>
**Status:** open | in-progress | remediated | accepted-residual | wont-fix

## Description

…

## Reproduction

…

## Remediation plan

…

## Remediation commits

| SHA | Summary |
|-----|---------|

## Re-test result

…

Lifecycle

1. Open. Finding is recorded here as a stub with description + reproduction.
2. In-progress. A PR or commit chain is targeting it; the file lists the WIP branch / commits.
3. Remediated. All commits landed on main; re-test scheduled.
4. Re-tested. Auditor (external) or self-audit (internal) confirms the gap is closed. Status updated to remediated.
5. Sign-off (Critical/High only). The operator and lead auditor co-sign docs/security/plugin-runtime-signoff.md — only after all Critical and High items reach remediated (or accepted-residual with co-signature).

Cross-references

• docs/security/plugin-threat-model.md — the threat-model asset catalogue (A-NN).
• docs/security/plugin-attack-surface.md — the inventory of host bindings / DB tables / routes.
• docs/security/plugin-internal-findings.md — the running list of internal-self-audit findings.
• docs/security/plugin-audit-rfp.md — the external-audit scope of work.
• docs/security/plugin-runtime-signoff.md — the joint sign-off the production rollout gate.
• docs/improvement-plan/BLOCKERS.md § B-006 — the operator-procurement blocker for the external audit.