Vulnerability to remediation¶
Trigger¶
A vulnerability is reported, discovered by scanning, or published by a vendor.
Intended outcome¶
The exposure removed or consciously accepted, with evidence either way.
Workflow steps and gates¶
| Step | Accountable role | Activity | Handover | Gate |
|---|---|---|---|---|
| 1 | Vulnerability Management Analyst | establishes exposure and prioritises by exploitability | prioritised findings with owners and targets | Prioritised on exploitability and exposure, not severity score alone |
| 2 | Threat Intelligence Analyst | supplies exploitation context and actor interest | exploitability and targeting assessment | Source reliability and analytic confidence stated |
| 3 | Application Security Engineer | or Security Engineer triages the technical remediation route | remediation guidance per finding | Scanner noise tuned rather than forwarded |
| 4 | Container Platform Engineer | rebuilds affected images from patched bases where the finding is inherited | rebuilt signed images | Base image owner and cadence identified |
| 5 | Software Engineer | or Linux Systems Administrator applies the fix | patched system or dependency | Fix verified, not assumed from a version number |
| 6 | Change Manager | authorises the remediation window | change authorisation | Risk of patching weighed against risk of waiting, explicitly |
| 7 | Penetration Tester (Network and Infrastructure) | retests on request to confirm closure | retest verification | Only within a current signed authorisation |
| 8 | IT Risk Manager | records acceptance where remediation will not happen | time-bound risk acceptance with a compensating control | Accepted by the owner carrying the risk |
Running this workflow: operator and implementer boundary¶
In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.
For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.
How to use this workflow¶
A practical prompt pattern is:
Apply the
vulnerability-to-remediationworkflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.
Operational interpretation¶
The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.