Learning outcomes
- Triage a report by affected artifact, exposure, preconditions, exploit path, impact, and active use.
- Coordinate containment, root-cause remediation, regression testing, release, and deployment verification.
- Communicate affected versions and mitigations without confusing severity with actual deployment risk.
- Feed recurring weakness and process failures back into design, frameworks, tests, and defaults.
Operating objective
The vulnerability process must reduce real user risk while preserving evidence, release quality, and clear ownership. It begins before the first report. Publish a monitored reporting channel and policy. Assign product, security, release, infrastructure, support, and communication roles. Maintain an inventory that connects source, dependencies, builds, deployments, owners, and supported versions.
For every report, create one controlled record with:
- Reporter and communication status.
- Affected component, version, configuration, and deployment class.
- Weakness and suspected root cause.
- Entry point, actor, preconditions, exploit path, and required authority.
- Security property and affected assets.
- Reproduction status and evidence.
- Known exploitation and exposure.
- Temporary containment and its limits.
- Remediation owner, release, deployment, and verification state.
- Disclosure and customer-action decision.
Protect reporter information and exploit details according to need. Preserve original evidence. Do not run an untrusted proof of concept on a production system or developer workstation with sensitive credentials.
Signals and evidence
Triage uses several independent facts. Confirm whether the affected code or dependency is present in the released artifact, enabled, reachable, exposed to the expected actor, and running with useful authority. Reproduce the behavior in a controlled environment. Determine whether the report describes the root cause or only one manifestation.
Use severity as one input. Add deployment reachability, identity requirements, network position, data and control-plane impact, exploit reliability, active exploitation, available containment, recovery cost, and user exposure. A high generic score can have no reachable path in one deployment. A lower-scored authorization or business-logic defect can expose critical data in another.
Collect evidence for each phase:
- Reproduction of the original result.
- Root-cause analysis across related code and components.
- Search for the same weakness class elsewhere.
- Tests for exploit variants, alternate routes, and adjacent state.
- Artifact provenance for the fixed release.
- Deployment inventory and adoption.
- Runtime signals for attempted exploitation and containment health.
- Final verification on the deployed version and configuration.
Response and recovery
Contain only when the containment has a clear security effect. Disable the affected feature, close reachability, revoke a credential, restrict a route, isolate a worker, or block a narrow known exploit path. Do not present a web filter as a permanent fix for unsafe command or query construction. Give temporary controls owners and expiry.
Fix the root cause and the surrounding weakness class. Use a safe API, remove an unnecessary interpreter, narrow authority, correct object authorization, improve state handling, or replace an unsafe component. Add a regression test that observes the protected result. Review the patch for new bypass, compatibility, and rollback risk.
Build through the controlled release path. Identify all affected and fixed versions. Deploy according to consequence and test the exact artifact. Verify that the running state contains the fix and that temporary containment can be removed safely. Rotate credentials or rebuild systems when compromise could have exposed them.
Communicate what users need to act: affected products and versions, required conditions, impact, fixed version, supported mitigation, detection guidance, and update path. State uncertainty directly. Coordinate with the reporter and relevant dependency maintainers.
After closure, change the development system. Improve the secure default, framework, library, code pattern, review rule, static check, fuzz target, integration test, inventory, or deployment control that allowed the weakness to recur.
Design tradeoffs and residual risk
Immediate disclosure can help defenders and can expose unpatched users. Delayed disclosure gives repair time and can leave users unaware of active risk. A broad emergency block can reduce exploitability and harm availability. A fast patch can create regression or incomplete remediation. A complete rebuild and credential rotation can be costly and necessary when integrity is uncertain.
Make decisions from user protection, active threat, fix readiness, containment strength, deployment control, and coordination needs. Record who accepted the remaining risk and when the decision must be reviewed.
Pomerium boundary
Pomerium can reduce reachability to a vulnerable application route, narrow temporary access, revoke route sessions through surrounding identity controls, and provide access evidence. It cannot repair the upstream weakness or prove that no direct path exists.
For a Pomerium vulnerability, follow the project's supported reporting and release process. For an upstream vulnerability, the application owner still owns remediation, deployment inventory, and final verification. Do not claim that placing a vulnerable service behind Pomerium removes the need to patch it.
Exercise
Run a tabletop with this report: an authenticated user can change the object identifier in an export request and receive another tenant's report. The direct origin is reachable from one internal network. The export worker stores results under public object URLs for one hour.
Produce:
- An exploit-path and impact statement.
- Affected asset, version, deployment, and owner inventory.
- Immediate containment with explicit limits.
- Root-cause fix and search for the weakness class.
- Regression tests for route, object, tenant, worker, and storage paths.
- Release, deployment, rollback, and verification plan.
- User communication with affected versions and action.
- Development-system changes that prevent recurrence.
Measure how long it takes to identify every deployment and confirm the fixed artifact.
Evaluation checklist
- Is the reporting channel monitored and connected to named response roles?
- Can the team identify affected source, dependencies, artifacts, deployments, versions, configurations, and owners?
- Does triage model the complete exploit path and deployment exposure rather than rely on one score?
- Does containment break the path without being mistaken for the root-cause fix?
- Do tests cover the weakness class, variants, alternate routes, and final protected result?
- Is the fixed artifact deployed and verified everywhere it is needed?
- Did the response improve a framework, default, test, review, inventory, or release control?
Next learning unit
Vulnerability and Exploit
Distinguish a software weakness, exploitable vulnerability, exploit path, exposure, and resulting security impact.
