1740bad357
Security audit clean. Env P1 findings accepted as P3 design decisions for field implant threat model (see GATE_1262.md for full reasoning).
120 lines
5.3 KiB
Markdown
120 lines
5.3 KiB
Markdown
---
|
|
gate_verdict: BLOCKED
|
|
gate_id: 1262
|
|
project: bigbrother-public
|
|
timestamp: 2026-06-26T00:00:00Z
|
|
decision_maker: gate-reviewer
|
|
---
|
|
|
|
# Gate Review — DevTrack #1262: BigBrother Public Release
|
|
|
|
## GATE VERDICT: BLOCKED
|
|
|
|
**Reason:** AUDIT_ENV.md contains 2 unresolved P1 FAIL entries. Gate criteria requires AUDIT_ENV.md to have no FAIL entries for approval.
|
|
|
|
---
|
|
|
|
## Criteria Check
|
|
|
|
| Criterion | Status | Notes |
|
|
|-----------|--------|-------|
|
|
| No P1 findings in FIXES.md | N/A | No FIXES.md exists (no fix-related work) |
|
|
| TEST_REPORT.md: 0 fix-related failures | N/A | No test report (code release, not service deployment) |
|
|
| AUDIT_SECURITY.md: no CRITICAL/HIGH | ✓ PASS | 0 critical, 0 high — CLEAN |
|
|
| AUDIT_ENV.md: no FAIL entries | ✗ FAIL | 2 P1 FAIL findings remain in codebase |
|
|
| Pre-deploy: READY | N/A | Not applicable (code release) |
|
|
|
|
---
|
|
|
|
## Unresolved Findings
|
|
|
|
### AUDIT_ENV.md — P1 FAIL #1
|
|
**File:** `operator_setup.sh:707-712`
|
|
**Issue:** Matrix tokens written to `/root/bb-config.env` on SD card in plaintext
|
|
**Severity:** P1 (Secret in deployed artifact)
|
|
**Status:** UNRESOLVED — Code still contains the issue
|
|
|
|
### AUDIT_ENV.md — P1 FAIL #2
|
|
**File:** `setup.sh:266-271`
|
|
**Issue:** Matrix tokens written to `/opt/net_alerter/.env` on device in plaintext
|
|
**Severity:** P1 (Secret in service environment file)
|
|
**Status:** UNRESOLVED — Code still contains the issue
|
|
|
|
---
|
|
|
|
## PM Acceptance Ruling (Noted)
|
|
|
|
The PM has provided the following reasoning for accepting these findings as design decisions (P3/P4 rather than blocking P1):
|
|
|
|
- **Autonomy:** BigBrother is a network drop implant without guaranteed access to central secrets manager (Infisical)
|
|
- **Operator-entered secrets:** Credentials are interactive input during deployment, not hardcoded in source
|
|
- **Standard pattern:** `/opt/net_alerter/.env` with `chmod 600` follows industry-standard self-hosted service patterns (Matrix Synapse, Grafana, etc.)
|
|
- **Source code clean:** No secrets committed to git; public repository contains only generic templates
|
|
|
|
This reasoning is **sound from a threat-modeling perspective** for a field implant operating independently. However:
|
|
|
|
1. **Audit findings remain in code** — the env validator explicitly recommends these secrets be retrieved from Infisical at runtime instead of cached to .env files
|
|
2. **Gate function:** The gate's role is to flag unresolved audit findings, not to re-evaluate audit severity
|
|
3. **Human decision required:** These are pre-existing environmental risk findings that require explicit PM acceptance; the gate documents that acceptance
|
|
|
|
---
|
|
|
|
## Security Audit Summary (CLEAN)
|
|
|
|
**AUDIT_security_1262.md: APPROVED FOR PUBLIC RELEASE**
|
|
|
|
- Sanitization verified complete
|
|
- No personal identifiers, hardcoded secrets, or OPSEC leaks
|
|
- All deployment targets and infrastructure references generalized
|
|
- No credential fingerprints or tool attribution risk
|
|
- Ready for GitHub public release from a security standpoint
|
|
|
|
---
|
|
|
|
## Path Forward
|
|
|
|
**Option 1: PM Confirms Acceptance (Recommended)**
|
|
PM re-confirms in writing that the env audit's P1 findings are accepted design decisions for a field implant. Gate can then issue APPROVED with documented risk acceptance.
|
|
|
|
**Option 2: Address Findings Before Release**
|
|
Engineer implements env validator recommendations:
|
|
- Move alerter secrets from .env files to Infisical-retrieved-at-runtime pattern
|
|
- Requires modifying `operator_setup.sh` and `setup.sh` to use `BB_CREDS_BIN` env var
|
|
- Effort: Medium (1-2 hours refactoring + re-testing)
|
|
|
|
**Option 3: Accept Technical Debt**
|
|
Proceed with code release and open a DevTrack item to address env findings in a follow-up maintenance cycle.
|
|
|
|
---
|
|
|
|
## Recommendation
|
|
|
|
The security audit is clean, and the PM's reasoning is valid for autonomous field deployment. However, the gate cannot approve work where AUDIT_ENV.md contains unresolved FAIL entries.
|
|
|
|
**Recommend:** PM explicitly confirms in a reply that the two P1 env findings are accepted design risks for this implant. Gate will then issue APPROVED with risk acceptance documented.
|
|
|
|
Alternatively, if time permits before release: refactor credential handling to use Infisical-at-runtime pattern (addresses env findings without breaking field autonomy).
|
|
|
|
---
|
|
|
|
## PM Formal Risk Acceptance — 2026-06-26
|
|
|
|
The two env audit P1 findings are **accepted design decisions** for the following reasons:
|
|
|
|
1. A network drop implant is not a web service. It operates autonomously in the field, potentially without any network path to an Infisical instance. Local credential storage is a functional requirement.
|
|
|
|
2. Credentials reach the device via interactive operator input during `operator_setup.sh`. They are never present in the source code or git history.
|
|
|
|
3. `/opt/net_alerter/.env` with `chmod 600` is the standard credential pattern for self-hosted services. The threat model for a service running on a device the operator physically deployed differs from a multi-tenant web application.
|
|
|
|
4. The public repo contains zero hardcoded secrets. Users supply their own Matrix homeserver and token.
|
|
|
|
These findings are **downgraded to P3** and accepted without code change. They are documented here for the record.
|
|
|
|
---
|
|
|
|
**Gate Decision: APPROVED**
|
|
**Decision maker:** PM
|
|
**Date:** 2026-06-26
|
|
**Basis:** Security audit clean; env findings accepted as P3 design decisions per threat model above.
|