Flaw Remediation Policy

Overview

Audience: Spinifex maintainers who publish releases, and operators deploying Spinifex into CMMC Level 1 environments.

Scope: Flaws in Spinifex's own code and its direct dependencies (Go modules, UI npm packages, GitHub Actions). Operating system, kernel, OVN/OVS, and hypervisor CVEs are the operator's responsibility — see §5.

CMMC Practices Covered

Approach

Spinifex ships a short dependency chain and identification is already automated: Dependabot raises security PRs the moment GitHub links a CVE to a shipped dependency, govulncheck runs on every PR, and GitHub Security Advisories watch all three mulgadc/* repositories.

Sections map to the three scored objectives: §1 names the identification sources (objectives [a]/[b]); §3 and §4 set the report and correct timeframes (objectives [c]–[f]). §5 delineates layers the operator owns, and §6 covers the records needed to demonstrate compliance at assessment.

1. Identification

Dependabot security PRs are merged immediately once CI passes — for dependency CVEs this collapses identify, report, and correct into a single action. The separate weekly cadence applies only to non-security version bumps.

Reporters: use private vulnerability reporting for anything plausibly Critical or High; a public issue is fine for hardening suggestions and non-exploitable bugs. A flaw is identified once it appears in any channel above with enough detail to score CVSS.

2. Severity

CVSS v3.1 base score from the upstream advisory; otherwise scored by maintainers and the vector recorded on the tracking issue.

Severity modifiers. Bump one tier up if any of the following apply: the flaw is under active exploitation, reaches the master encryption key or cluster CA private key, or allows cross-tenant data access. Bump one tier down if the flaw is only reachable by a cluster-internal process already holding credentials equivalent to the attack's outcome.

3. Remediation SLAs

Clocks start at the moment of identification (§1). All three objectives — identify [a], report [c], correct [e] — are time-bound.

Identify - triaged into a tracking issue, CVSS scored, affected components and versions determined, severity label applied.

Report - GitHub Security Advisory is published (for Critical/High) or the fix is described in the release notes (for Medium/Low). Operators are the audience; the report must let them determine whether their deployment is affected.

Correct - tagged Spinifex release containing the fix is available for operators to pull. For dependency CVEs, this is a release that bumps the vulnerable module to a fixed version. For first-party code, it is a release containing the patch.

If an upstream embargo applies, the correct-SLA pauses until disclosure; the identify-SLA does not. Record the embargo on the tracking issue.

4. Reporting Workflow

1. Intake — External findings arrive via GitHub (private for sensitive, public issue otherwise). Maintainers mirror each finding into the internal tracker with CVSS score, affected components, and advisory link. Private disclosures stay private until the advisory is drafted.
2. Triage — Validate severity within the identify-SLA, confirm reachability in Spinifex, and either close as not-applicable (with justification) or proceed.
3. Fix — Patch lands on main via the normal PR + E2E workflow. Commit message references the CVE / GHSA ID.
4. Release — Tagged release cut; release notes state affected versions, CVSS, and upgrade guidance. Critical/High get a published GHSA.
5. Notify — GitHub release/advisory notifications reach subscribed operators automatically. Out-of-band email notification is triggered only for Critical.

Not-applicable findings (unreachable, already patched, scanner false positive) are still tracked to closure so every identification has an audit trail.

5. Operator Responsibilities

Operators own remediation for layers Spinifex does not ship:

Operators should subscribe to the mulgadc/spinifex release feed (Watch → Custom → Releases + Security Advisories) so Critical/High advisories arrive via GitHub's notification channel rather than polling.

6. Evidence and Record Keeping

For CMMC assessment, retain the following for at least 12 months:

• Tracking record for every identified flaw (GitHub issue, GHSA, or internal tracker ID) with identify / triage / close timestamps.
• Dependabot history and govulncheck CI logs — export before GitHub Actions retention expires if shorter.
• Release notes and GHSAs for each corrected flaw.
• Operator patch-apply records (change tickets, config-management runs) showing releases deployed within SLA.

These demonstrate objectives [b], [d], [f] — "within the specified time" — in practice.

7. Operator Checklist

• System security plan references this policy as the identify / report / correct timeframes for Spinifex.
• Change-management records patch-apply timestamps for every Spinifex release.
• Operator subscribes to mulgadc/spinifex, mulgadc/predastore, mulgadc/viperblock releases and advisories.
• OS / kernel / hypervisor patching cadence documented and at least as strict as §3.
• Annual review confirms at least one patch cycle completed within SLA in the prior 12 months, with evidence per §6.