Learning outcomes
- Prioritize vulnerabilities from reachable paths, authority, exploit evidence, and impact.
- Validate patched artifacts, configuration, compatibility, and security behavior.
- Deploy in bounded stages with detection and rollback.
- Remove obsolete vulnerable paths and prove the effective version.
Operating objective
Every component on the access path has an owner, version, exposure, authority, dependency record, update path, validation, and rollback. Remediation priority reflects reachable attack path, current exploitation, privileges, data, blast radius, and available compensating controls, not severity score alone.
Signals and evidence
Join asset and runtime inventory, vendor advisory, affected-version logic, exploit evidence, exposure, identity and network path, privileges, artifact provenance, deployment state, and observed behavior. Record decision, owner, deadline, exception, compensating control, patch artifact, tests, rollout, and effective version.
Response and recovery
- Confirm affected components and reachable paths.
- Contain active exploitation or exposed authority.
- Obtain a trusted patch or build and verify provenance and digest.
- Test configuration migration, authentication, authorization, protocols, negative access, load, and rollback.
- Deploy to a bounded population and watch control and application signals.
- Promote the exact artifact or roll back to a still-safe known version.
- Remove old instances, images, credentials, routes, and emergency controls.
- Prove runtime versions and repeat negative tests.
Design tradeoffs and residual risk
Fast patching reduces exposure and can cause an access outage. Slow staged rollout preserves service and leaves vulnerable replicas. Rollback restores availability and can restore the vulnerability. Compensating controls buy time and can hide indefinite exceptions.
Residual risk includes unknown assets, incorrect affected-version data, compromised update channels, configuration incompatibility, and exploitation before detection.
Pomerium boundary
Pomerium publishes supported upgrade guidance. Operators own inventory, advisory intake, artifact verification, environment testing, deployment, monitoring, rollback, and all upstream or dependency patches. A running Pomerium version does not prove every access-path component is patched.
Exercise
Use a staged component with a known fixed version. Build the affected inventory, priority decision, test plan, verified artifact, deployment stages, signals, rollback trigger, and removal proof. Simulate one compatibility failure and one active-exploitation signal.
Evaluation checklist
- Does priority combine exploitation, exposure, authority, impact, and compensating controls?
- Is the patch artifact authenticated and tied to exact affected assets?
- Do tests cover positive service and negative security behavior?
- Can rollout stop and recover without restoring compromised authority?
- Are old runtime instances, artifacts, credentials, and exceptions removed?
Next learning unit
Security Assurance and Evidence
Distinguish a control claim, verification, validation, assurance argument, and the evidence that supports each conclusion.
