Patch Management Framework
Audience: DevOps / Platform engineers, Security architects
Time: ~25 min
Prerequisites:
- Control Plane running (see Quick-Start)
- Administrator role
- Optional: SPIRE enabled for SPIFFE-authenticated patch downloads
- Feature flag
flags.patchManagement.enterprise_v2(default off) for Manifest 2.0 nomenclature enforcement
Control Core delivers signed patch packs for the Control Plane and Bouncers (PEPs) through Settings → Patch Management. Patches are discovered from a signed Manifest, verified with SHA-256 + cryptographic signatures, and rolled out in rings with health gates and rollback.
TL;DR
- Open Settings → Patch Management
- Confirm entitlement and discovery repository URL
- Check for updates → review KEV / SLA badges → Precheck → Install
- For air-gapped sites: import a signed offline ZIP (no network / SPIFFE required)
- Monitor Patch compliance posture per environment
Troubleshooting: If the Settings card is missing, confirm you are Admin. If discovery fails, verify the GitHub token / patch repo URL and that
manifest.jsonassets exist on releases. Full admin help: Admin troubleshooting.
1. Patch nomenclature
| Type | Pattern | Example |
|---|---|---|
| Monthly pack | cc-<<month>>-<<year>> | cc-07-2026 |
| One-off / hotfix | cc-<<jira-task-id>> | cc-SCRUM-1234 |
| Major release | cc-<semver> | cc-3.0.0 |
Monthly packs accumulate fixes (12/year) and roll into majors each January. Hotfixes can ship any day and are later absorbed into a monthly pack. Artifacts are immutable once published.
2. Trust & transport
- Integrity: SHA-256 checksum of every artifact
- Authenticity: Detached Ed25519 or ECDSA P-256 signature over the checksum (verified against
PATCH_SIGNING_PUBLIC_KEY) - SBOM: Manifest may include
sbom_ref(CycloneDX/SPDX) - SPIFFE (optional): When SPIRE is enabled, Control Plane downloads may use SVID client certificates (
SPIFFE_SVID_CERT_FILE/SPIFFE_SVID_KEY_FILE/SPIFFE_TRUST_BUNDLE_FILE) - Air-gap: Offline ZIP with
manifest.json+ artifact; Control Plane validates signature before catalog registration
Troubleshooting: Signature failures usually mean wrong public key, tampered artifact, or DEMO_MODE/legacy accept disabled. Never share private signing keys with customer Control Planes — only the public key.
3. Staged rollout (rings)
| Ring | Purpose |
|---|---|
| 0 | Canary (1 target) |
| 1 | Pilot (~10%) |
| 2 | Broad rollout |
Auto-pause triggers when a ring’s failure rate is ≥ 5%. Every patch should declare rollback_version. Post-install attestation compares the running binary hash to the catalog checksum.
4. Risk-based SLAs (guidance)
| Tier | Target |
|---|---|
| KEV / critical RCE | 24–72 hours after internal validation |
| High | 7–14 days |
| Medium / monthly | within the monthly cycle |
| Low | next major or deferred with documented exception |
5. Compliance evidence
Admins can export a JSON compliance report (GET /patches/compliance-report) covering posture scores, catalog summary, and deployment log for SOC 2 CC7.1 / CC8.1 and PCI-oriented patch evidence. Reports exclude secrets and PII.