cschanhniem · Jul 9, 2026 · Jul 9, 2026
diff --git a/Makefile b/Makefile
@@ -1,4 +1,4 @@
-.PHONY: help demo test lint ci clean bench-leakage bench-multi-negatives bench-baseline bench-hidden-active bench-cluster-split bench-expert-ablation bench-expert-ablation-500 bench-selectivity bench-feature-decomp bench-gate bench-easy-baseline bench-charge-matched bench-order-dependent bench-precision-at-k bench-per-family bench-simulation-ablation bench-simulation-ablation-within-amp simulation-gate bench-strategy-compare regenerate-all generate phase3 pilot validate-scoring validate-scoring-phase3 validate-scoring-strict external-pilot pilot-confident presynth-qc gold-standard diversity synthesis-order novelty-broad external-consensus questionnaire gate-check ip-report benchmark-card wave0-5-gate-check wave0-5-novelty-audit wave0-5-novelty-audit-v2 wave0-5-panel wave0-5-evidence wave0-5-fill-external wave0-5b-generate wave0-5b-filter recalibration-engine recalibration-engine-dry-run validate-policy-version generate-synthetic-lab-results bump-policy-version generate-review-packet failed-candidate-report safe-publication-filter classify-negative-informativeness validate-rejection-events negative-result-dashboard calibration-audit calibration-audit-example calibration-overfit-check result-quality-filter synthetic-result-policy-check calibration-decision-checklist calibration-rollback-plan simulation-registry validate-simulation-result-schema simulation-baseline-check adapter-gate-check simulation-provenance simulation-ensemble-check simulation-ci-report simulation-deprecation-check simulation-scope-check simulation-evidence-packet artifact-version candidate-manifest artifact-changelog integration-check adapter-author-check license-check artifact-compat-check contribution-check adoption-scorecard release-gate-check decision-log release-request-check coi-check rotation-plan-check rotation-plan-check
+.PHONY: help demo test lint ci clean bench-leakage bench-multi-negatives bench-baseline bench-hidden-active bench-cluster-split bench-expert-ablation bench-expert-ablation-500 bench-selectivity bench-feature-decomp bench-gate bench-easy-baseline bench-charge-matched bench-order-dependent bench-precision-at-k bench-per-family bench-simulation-ablation bench-simulation-ablation-within-amp simulation-gate bench-strategy-compare regenerate-all generate phase3 pilot validate-scoring validate-scoring-phase3 validate-scoring-strict external-pilot pilot-confident presynth-qc gold-standard diversity synthesis-order novelty-broad external-consensus questionnaire gate-check ip-report benchmark-card wave0-5-gate-check wave0-5-novelty-audit wave0-5-novelty-audit-v2 wave0-5-panel wave0-5-evidence wave0-5-fill-external wave0-5b-generate wave0-5b-filter recalibration-engine recalibration-engine-dry-run validate-policy-version generate-synthetic-lab-results bump-policy-version generate-review-packet failed-candidate-report safe-publication-filter classify-negative-informativeness validate-rejection-events negative-result-dashboard calibration-audit calibration-audit-example calibration-overfit-check result-quality-filter synthetic-result-policy-check calibration-decision-checklist calibration-rollback-plan simulation-registry validate-simulation-result-schema simulation-baseline-check adapter-gate-check simulation-provenance simulation-ensemble-check simulation-ci-report simulation-deprecation-check simulation-scope-check simulation-evidence-packet artifact-version candidate-manifest artifact-changelog integration-check adapter-author-check license-check artifact-compat-check contribution-check adoption-scorecard release-gate-check decision-log release-request-check coi-check rotation-plan-check security-report-check
 
 PYTHON := $(shell [ -f .venv/bin/python ] && echo .venv/bin/python || echo python3)
 PYTEST  := $(shell [ -f .venv/bin/pytest ] && echo .venv/bin/pytest || echo pytest)
@@ -860,3 +860,8 @@ rotation-plan-check:
 	.venv/bin/openamp-foundry rotation-plan-check \
 		--plan-json '{"entries":[{"github_handle":"maintainer","role":"primary_maintainer","backup_handle":"backup-maintainer","responsibilities":["releases","safety-policy","final-approvals"],"status":"active"},{"github_handle":"backup-maintainer","role":"secondary_maintainer","backup_handle":"maintainer","responsibilities":["day-to-day-reviews","issue-triage"],"status":"active"}]}'
 	@echo "Rotation plan check complete."
+
+security-report-check:
+	.venv/bin/openamp-foundry security-report-check \
+		--report-json '{"report_id":"SEC-2026-001","severity":"medium","category":"dependency_vulnerability","description":"CVE-2026-1234 in requests library","affected_version":"v0.7.3","reporter_handle":"anonymous","report_date":"2026-07-09","status":"acknowledged"}'
+	@echo "Security report check complete."
diff --git a/docs/evidence/METRICS_CURRENT.md b/docs/evidence/METRICS_CURRENT.md
@@ -5,7 +5,8 @@ Machine-readable snapshot: `outputs/metrics_snapshot.json` regenerated with `mak
 > **Purpose:** One authoritative table of current pipeline metrics. If any doc disagrees
 > with this file, this file wins. Updated whenever benchmark/benchmark config changes.
 >
-> **Last updated:** 2026-07-09 (Phase J J5 — maintainer rotation plan — v0.7.3)
+> **Last updated:** 2026-07-09 (Phase J J6 — security policy — v0.7.4)
+> **New in v0.7.4:** Security policy (J6 — Loop 114) — `docs/governance/SECURITY_POLICY.md` with private vulnerability reporting process, response timeline (48h acknowledgment, 30d patch), severity classification (critical/high/medium/low), 5 vulnerability categories (code_vulnerability, secret_leakage, dependency_vulnerability, safety_guardrail_bypass, dual_use_risk), out-of-scope items, disclosure process. `src/openamp_foundry/governance/security_policy.py` with `VulnerabilityReport` dataclass (9 fields: report_id, severity, category, description, affected_version, reporter_handle, report_date, status, dry_lab_only), `SecurityReportValidationResult` dataclass (6 fields, dry_lab_only=True), `VALID_SEVERITY_LEVELS` (4: critical, high, medium, low), `VALID_VULNERABILITY_CATEGORIES` (5: code_vulnerability, secret_leakage, dependency_vulnerability, safety_guardrail_bypass, dual_use_risk), `VALID_REPORT_STATUSES` (6: received, acknowledged, under_review, patched, disclosed, not_applicable), `validate_vulnerability_report()` (9 checks: report_id SEC- prefix, valid severity, valid category, non-empty description, non-empty affected_version, non-empty reporter_handle, YYYY-MM-DD date, valid status, dry_lab_only must be True; critical+received warning, safety_guardrail_bypass warning), `validate_report_dict()` (dict input with 8 required fields guard). CLI (`openamp-foundry security-report-check`) with `--report-json`, `--format text|json`. `make security-report-check` target. 18 tests. Dry-lab only. Private vulnerability reporting now has a validated structure and documented process.
 > **New in v0.7.3:** Maintainer rotation plan (J5 — Loop 113) — `docs/governance/MAINTAINER_ROTATION_PLAN.md` with purpose, current maintainers table (3 entries covering primary, secondary, external_advisor), role definitions (4 roles: primary_maintainer, secondary_maintainer, external_advisor, contributor), bus-factor assessment (target >=2 for every critical function, CI maintenance and domain expertise currently at 1), rotation schedule (every 6 months), onboarding and offboarding checklists, linked policies. `src/openamp_foundry/governance/maintainer_rotation.py` with `MaintainerEntry` dataclass (6 fields: github_handle, role, backup_handle, responsibilities, status, dry_lab_only), `RotationPlanValidationResult` dataclass (7 fields: passed, errors, warnings, maintainer_count, critical_role_coverage, bus_factor_sufficient, dry_lab_only), `VALID_ROLES` (4: primary_maintainer, secondary_maintainer, external_advisor, contributor), `CRITICAL_ROLES` (2: primary_maintainer, secondary_maintainer), `VALID_STATUSES` (4: active, on_leave, emeritus, departing), `validate_maintainer_entry()` (6 checks), `validate_rotation_plan()` (aggregates entry validation + bus-factor coverage: missing critical role is error, single coverage is warning), `validate_rotation_plan_dict()` (dict input with missing-entries-fields guard). CLI (`openamp-foundry rotation-plan-check`) with `--plan-json`, `--format text|json`. `make rotation-plan-check` target. 21 tests. Dry-lab only. Project durability is now machine-validated.
 > **New in v0.7.2:** COI disclosure template (J4 — Loop 112) — `docs/governance/COI_DISCLOSURE_TEMPLATE.md` with structured COI disclosure template (purpose, fill-in-the-blank template with 10 fields: Disclosure ID, disclosure type (reviewer|contributor|maintainer|external_advisor), subject, related artifact, relationship type (financial|institutional|competitive|personal|none), description (conditional), date, recusal required, reviewer, review status (pending|acknowledged|resolved); when to disclose section covering financial/institutional/competitive/personal relationships; process with machine validation and escalation; linked policies). `src/openamp_foundry/governance/coi_disclosure.py` with `COIDisclosure` dataclass (10 fields), `COIValidationResult` dataclass (6 fields, dry_lab_only=True), `VALID_DISCLOSURE_TYPES` (4: contributor, external_advisor, maintainer, reviewer), `VALID_RELATIONSHIP_TYPES` (5: competitive, financial, institutional, none, personal), `VALID_REVIEW_STATUSES` (3: acknowledged, pending, resolved), `validate_coi_disclosure()` (10 checks including disclosure_id COI- prefix, valid disclosure_type, non-empty subject/related_artifact, valid relationship_type, description required unless none, YYYY-MM-DD date, non-empty reviewer, valid review_status, dry_lab_only must be True; financial without recusal warning), `validate_coi_dict()` (dict input with 10 required fields guard, missing fields returns passed=False early). CLI (`openamp-foundry coi-check`) with `--disclosure-json`, `--format text|json`. `make coi-check` target. 20 tests. Dry-lab only. COI disclosures now have a validated structure that builds institutional trust.
 > **New in v0.7.1:** Release request template (J3 — Loop 111) — `docs/governance/RELEASE_REQUEST_TEMPLATE.md` with structured release request template (purpose, fill-in-the-blank template with 17 fields: Release ID, release type, artifact ID/version, requestor name/institution, request date, evidence level 1-6, dry_lab_only, safety_review_status, benchmark_summary, known_limitations, intended_use, data_license, human_reviewer, review_class, approval_status; review criteria with 8 checks; process with classes A-D timelines and escalation path). `src/openamp_foundry/governance/release_request.py` with `ReleaseRequest` dataclass (17 fields), `ReleaseRequestValidationResult` dataclass (6 fields, dry_lab_only=True), `VALID_RELEASE_TYPES` (5), `VALID_SAFETY_STATUSES` (3), `VALID_INTENDED_USES` (4), `VALID_APPROVAL_STATUSES` (4), `VALID_REVIEW_CLASSES` (4), `validate_release_request()` (17 checks including dry_lab_only+evidence_level>4 error, public+safety_pending error, model+review_class warning), `validate_request_dict()` (dict input with missing-fields guard). CLI (`openamp-foundry release-request-check`) with `--request-json`, `--format text|json`. `make release-request-check` target. 25 tests. **3516 total.** Formal release requests now have a validated structure before entering human review.
@@ -101,7 +102,7 @@ Machine-readable snapshot: `outputs/metrics_snapshot.json` regenerated with `mak
 > **New in v0.5.31:** Added dipeptide-order features for sequence-order awareness. `dipeptide_order_score` achieves AUROC 0.7861 on AMP-vs-scrambled discrimination — the strongest order-dependent feature in the pipeline. Only 7/31 features survive scrambling (amphipathicity/helix-wheel + dipeptide). All composition features are purely position-independent (exactly 0.5000 AUROC on scrambled test).
 > **New in v0.5.30:** Easy baseline benchmark added — charge density alone (AUROC 0.8166) outperforms the full pipeline ensemble (0.7792) on AMP-vs-Swiss-Prot-decoy discrimination. Honest finding documented: expected because pipeline optimizes for safety, not raw discrimination.
 > **New in v0.5.29:** Expanded benchmark to 500 AMPs + 500 composition-matched decoys (n=1000). AUROC 0.7792 (CI₉₅: 0.7505–0.8065) confirms signal generalizes. Cluster-aware CI: 0.746–0.8102. Representative AUROC: 0.778. Standard benchmark (n=191) retained for backward comparison.
-> **Pipeline version:** v0.7.3 (J5 — maintainer rotation plan)
+> **Pipeline version:** v0.7.4 (J6 — security policy)
 > **Branch:** main
 
 ---

diff --git a/docs/governance/SECURITY_POLICY.md b/docs/governance/SECURITY_POLICY.md
@@ -0,0 +1,93 @@
+# Security Policy
+
+## Purpose
+
+This document describes how to report security vulnerabilities in the OpenAMP Foundry project privately, what the project maintains as its security boundary, and how reports are handled.
+
+**Scope:** Computational code, Python library, CLI, schemas, documentation. This project is dry-lab only — there are no wet-lab protocols, clinical systems, or patient data.
+
+---
+
+## Reporting a Vulnerability
+
+**Do NOT file a public GitHub issue for security vulnerabilities.**
+
+Instead, report privately via one of these channels (in priority order):
+
+1. **GitHub Private Vulnerability Reporting** — use the "Report a vulnerability" button on the GitHub Security tab.
+2. **Maintainer email** — send to the primary maintainer (see MAINTAINER_ROTATION_PLAN.md for the current handle; find their contact via their GitHub profile).
+
+Include in your report:
+- Description of the vulnerability
+- Steps to reproduce (minimal example preferred)
+- Affected version(s) or commit hash
+- Potential impact assessment
+- Whether you have a proposed fix
+
+---
+
+## What Counts as a Security Issue
+
+| Category | In scope | Examples |
+|---|---|---|
+| Code vulnerabilities | Yes | Command injection via CLI args, path traversal, insecure deserialization |
+| Secret leakage | Yes | API keys, tokens, or credentials committed to the repo |
+| Dependency vulnerabilities | Yes | Known CVEs in pinned dependencies that affect users |
+| Overclaiming / false biological claims | Yes | Code that removes dry-lab-only guardrails or inflates evidence level |
+| Dual-use safety safeguards | Yes | Weakening toxicity, hemolysis, or novelty checks without review |
+| Missing features / performance | No | Feature requests and performance issues belong in public issues |
+| Documentation inaccuracies | No | Minor doc fixes belong in public PRs |
+
+---
+
+## Response Timeline
+
+| Step | Target |
+|---|---|
+| Acknowledgment | Within 48 hours of receipt |
+| Initial assessment | Within 5 business days |
+| Patch or mitigation | Within 30 days for confirmed high/critical issues |
+| Public disclosure | After patch is available and reporter is notified |
+
+If we cannot meet these timelines, we will communicate proactively.
+
+---
+
+## Severity Classification
+
+| Severity | Description |
+|---|---|
+| Critical | Remote code execution, secret exposure, dry-lab boundary bypass |
+| High | Privilege escalation, path traversal, dependency with known CVE |
+| Medium | Denial of service (local CLI only), insecure default config |
+| Low | Minor info disclosure, defense-in-depth improvements |
+
+---
+
+## Out of Scope
+
+- Theoretical vulnerabilities without a reproducible proof of concept
+- Issues that require physical access to the researcher's machine
+- Social engineering attacks on maintainers
+- Issues in dependencies where no fix is available upstream
+
+---
+
+## Process
+
+1. Reporter files private report.
+2. Maintainer acknowledges within 48 hours.
+3. Maintainer assesses severity and determines whether fix is needed.
+4. If confirmed: patch is developed on a private branch, reviewed, and merged.
+5. A new release is cut with the fix.
+6. Reporter is notified and given 7 days to review the fix before public disclosure.
+7. Public disclosure is made via GitHub Security Advisory.
+
+---
+
+## Linked Policies
+
+- [GOVERNANCE.md](../../GOVERNANCE.md)
+- [SAFETY.md](../../SAFETY.md)
+- [RESPONSIBLE_USE.md](../../RESPONSIBLE_USE.md)
+- [MAINTAINER_ROTATION_PLAN.md](MAINTAINER_ROTATION_PLAN.md)