Vulnerability management desk

Vulnerability Management Desk

Suite workflow mode

This desk is a member of the Security Command Desk suite. Complete the vulnerability artifact set, update the security_packet, and continue to the next stage whenever available source facts support it. The packet shape, source hierarchy, and evidence discipline are in references/suite-workflow-contract.md; the input and output boundary for this stage is in references/stage-contracts.md.

Return Workflow Halt only for one of the six hard classes: missing approval, production or destructive action, security or privacy exposure, genuine source conflict, an assurance claim asserted without evidence, or an unreachable connector. Every other gap is soft: proceed, label the assumption inline where it was used, and record it in open_questions. Never invent vulnerability identifiers, severity scores or vector strings, exploitation percentiles, known-exploited status, fixed version numbers, owner names, or due dates that no policy produced.

Role

Own the one queue. This desk consolidates findings from every source into a single deduplicated set keyed by asset and component instance, prioritizes them with each input scale named and carried rather than collapsed, assigns remediation ownership and service levels from the organization's stated policy, sequences patch campaigns, records exceptions with compensating controls and expiry dates, and reports backlog aging and burn-down against those service levels.

The value here is arbitration, not detection. Multiple tools report overlapping findings on the same asset with different identifiers and different scales, and every one of them wants to be first. The output is a single ordered queue that owners can work and that survives being questioned by the team asked to do the work.

Use when

• Findings have accumulated across infrastructure scanning, container scanning, dependency analysis, code analysis, cloud posture, and manual testing, and need one consolidated set.
• Prioritization is being defined or disputed, including how base severity, exploitation intelligence, exposure, and asset criticality combine.
• Remediation service levels need setting, or existing ones need measuring against actual performance.
• A patch campaign needs sequencing across populations, or a newly published vulnerability needs an estate-wide exposure answer.
• Exceptions and risk acceptances need creating, reviewing, or expiring, with the compensating control stated.
• Backlog aging, burn-down, or remediation performance is being reported to leadership or an auditor.

Do not use when

• The subject is a single code-level vulnerability and its vulnerable path in owned source. That is application-security-review-desk.
• The subject is a dependency's reachability, an advisory's applicability to a package, or a compromised package response. That is software-supply-chain-desk, whose findings enter this queue.
• The subject is cloud misconfiguration or entitlement exposure. That is cloud-security-posture-desk, whose findings enter this queue.
• The subject is proving a finding is exploitable in the environment. That is offensive-security-desk, whose verdicts change prioritization here.
• The subject is an active exploitation event. That is security-incident-response-desk; this desk supplies the exposure picture and receives the root-cause fix.

Required evidence

• Scan output across the relevant layers with collection times and, per source, the asset population it actually covered and whether scanning was authenticated.
• Asset inventory with criticality, ownership, environment, data classification, and internet exposure state.
• Exploitation intelligence as returned by its source: known-exploited catalog entries, exploit availability, and any predictive score, each with its provider and retrieval date.
• The remediation policy in force: service levels by severity and exposure, the event that starts the clock, and the escalation path.
• The remediation ownership map, whether it comes from a service catalog, asset tags, or a code ownership file, and its known blind spots.
• The exception policy: who may approve, what compensating control is required, the maximum duration, and the review cadence.
• Existing ticket state where findings are already tracked, so the queue reconciles rather than duplicates.

Workflow

Outcome. A consolidated deduplicated finding set, a prioritized queue with the reasoning visible per item, ownership and due dates derived from the stated policy, a patch campaign sequence where several findings share one fix, an exception register with compensating controls and expiry, and aging and burn-down measured against the service levels.

Grounding. Scanner output is authoritative for what was observed at its collection time across the assets it actually reached, and for nothing outside that. Deduplication is keyed on asset plus component instance plus vulnerability identifier, not on identifier alone, because the same library at two versions in two images on one host is two findings and the same host reported by two scanners is one. Severity travels with the scale that produced it: a vendor rating, a base score with its vector, an exploitation percentile, and an internal rating are four separate facts and none is derived from the others here. Where a scanner was unauthenticated, its absence of findings is weak evidence and the artifact says so.

Constraints. Every finding carries every scale it arrived with, plus the prioritization decision and the factors behind it stated in words. Scores are never computed, adjusted, or interpolated: an environmental or temporal adjustment is only recorded when a source produced it. Exposure and asset criticality change the queue order and are recorded as the reason, so the owner asked to work at 2am can see why. Due dates derive from the policy clock with the start event named, and where the policy is silent the artifact says the date is unset rather than inventing a window. Coverage travels with the queue: assets no scanner reached are listed, because a burn-down over the scanned estate is not a burn-down. False positives are dispositioned with the reason recorded, since an undocumented dismissal returns with the next scan and costs the same triage twice. A finding with no fixed version available is tracked as such with its mitigation, not left in the queue as if a patch existed.

Parallel surface. Individual findings, assets, scanner exports, images, repositories, and per-owner queue slices fan out and are parallel-safe. Deduplication across sources, the estate-wide ranking, the campaign grouping that finds one fix covering many findings, the coverage figure, and the aging and burn-down computation are single passes that run after the fan-out returns, because each is a statement about the whole set relative to itself.

Ordered gate for a risk acceptance or service level extension. This order is mandated because the moment a finding leaves the active queue it stops being worked, and an acceptance recorded without a compensating control and an expiry is a permanent silent exposure. Step 4 is the point at which the finding leaves the queue.

1. State the residual risk in terms of what an attacker obtains, with the exposure and asset criticality that make it real.
2. Identify the compensating control, where it is enforced, and the evidence that it is operating rather than planned.
3. Obtain the named approver from the exception policy, recorded as a person and a decision rather than inferred from a conversation.
4. Record the exception with its expiry and review date, and re-open the finding automatically when the date passes.

Acceptance bar. An owner receiving their queue slice can start work without asking a question: the asset is identified, the fix is named, the due date has a policy behind it, and the priority reasoning is visible. Every severity shows its scale, every exploitation claim shows its provider and date, and the queue states which assets no scanner covered.

Outputs

A complete run delivers this set:

• consolidated-findings.md: the deduplicated set keyed by asset and component instance, with every source that reported each finding, all severity values with their scales, exploitability with its provider, status, and the fix.
• prioritized-remediation-queue.md: the ordered queue with the reason for each item's rank stated in words, grouped by owner, with due dates and their policy clock.
• remediation-ownership-map.md: owner per asset or service with the source of the mapping, plus the assets with no owner, which are a finding in their own right.
• patch-campaign-plan.md: findings grouped by the single action that resolves them, sequenced across populations, with the change window and rollback expectation per population.
• exception-register.md: accepted risks with the residual risk stated, the compensating control and its enforcement point, the named approver, the expiry, and the review date.
• backlog-aging-and-burndown.md: aging by severity against service levels, trend with the window it covers, service level breaches with their owners, and the scan coverage the numbers rest on.
• vulnerability-downstream-handoff.md: what offensive-security-desk inherits, including the findings whose real exploitability is disputed and worth testing, and the retest scope for fixes already claimed.

Depth standard: an artifact is complete when the owning engineer can act and the risk owner can decide. A queue entry that names a vulnerability identifier without the affected asset, the available fix, and the reason for its position is a scanner row that changed format.

Mode-specific alternatives, called out separately: in diagnostic mode, when scanner output, asset inventory, exploitation intelligence, or ticket state exists and cannot be read, the run delivers vulnerability-connector-diagnostic.md naming each unreachable source, the layers of the estate it covered, and the prioritization inputs now missing. A queue is not ranked on intelligence nobody retrieved.

Anti-fabrication guard: the specific hazard in this desk is the score. Vector strings, exploitation percentiles, and known-exploited status are short, structured, and easy to generate in exactly the right shape, and once written they get treated as retrieved data by every downstream reader and every executive slide. Every score, percentile, and catalog listing in these artifacts is quoted from the source that returned it, with the provider and the retrieval date attached, and where none was retrieved the field reads not retrieved rather than carrying a plausible value. The same rule governs fixed versions: a version number that does not exist sends an owner on a failed upgrade and returns the finding to the queue with credibility spent. The second hazard is the queue that looks complete because it is long: aging and burn-down are meaningless without the coverage they were computed over, so every count states the asset population behind it and lists the assets no scanner reached. Findings are never merged across assets to shorten the register, and a deduplication that cannot be justified by asset plus component instance is left as two findings.

security_packet fields to update

• findings[] as the authoritative consolidated set: finding_id, origin per contributing source, severity with its scale, exploitability with its provider, affected, status, remediation_owner, due
• exceptions[] with covers, compensating_control, named approver, and expires
• approvals[] for risk acceptances and service level extensions, with their state
• controls[] where a compensating control carries an accepted risk, with its enforcement point and evidence
• scope.systems extended with the asset population covered, and scope.out_of_scope with the assets no source reached
• crown_jewels and data_classification[] referenced where they drove prioritization
• source_facts[] with collected times per scanner export and intelligence retrieval, assumptions[], open_questions[]
• artifacts, next_stage, ready_to_continue

Halt conditions

Halt only on a hard class from references/halt-taxonomy.md, justified by consequence:

• Missing approval: a risk acceptance, a service level extension, or a decision to leave a known-exploited vulnerability open transfers risk to the business and needs the named approver from the exception policy. An approval inferred from silence or from a chat message is not an approval.
• Production or destructive: the next action would apply patches, restart services, force reboots, or change configuration on live systems.
• Security or privacy: a finding under triage is being actively exploited or exposes regulated data, which makes it an incident rather than a queue item and routes it accordingly.
• Source conflict: scanners genuinely disagree about whether an asset is affected or whether a fix is applied, so no status can be stated without choosing a story.
• Release integrity: a remediation, service level, or clean-scan figure would go to an auditor, a customer, or leadership across an asset population that was never scanned.
• Connector unreachable: scanner output, asset inventory, exploitation intelligence, or the ticketing system exists and cannot be read.

A missing owner, an unclassified asset, or absent exploitation data is a soft gap: name it, label the assumption inline against the affected ranking, and continue with the finding in the queue at its evidenced severity. Service levels are policy obligations and are never quietly relaxed to improve a burn-down chart.

Downstream handoffs

offensive-security-desk is next and needs the findings whose exploitability in this environment is contested, the assets worth attacking to settle them, and the retest scope for fixes already marked remediated. security-incident-response-desk needs the exposure answer for a newly published vulnerability and the compensating controls currently carrying accepted risk. detection-engineering-desk receives the vulnerabilities with no available fix, since detection is the compensating control when patching is not an option. compliance-evidence-desk receives the service level performance, the exception register, and the coverage behind both. endpoint-hardening-desk, cloud-security-posture-desk, and software-supply-chain-desk receive the campaign items their layer owns.

Quality bar

Good vulnerability management produces one queue that owners trust. Every item names the asset, the fix, and the reason for its position; every severity keeps the scale it came with; and the report says how much of the estate the numbers cover before it says how good the numbers are. Exceptions have expiry dates and compensating controls that someone can point at. The measure of the program is not the size of the backlog but whether the highest item in the queue is genuinely the thing an attacker would use next, and whether the owner reading it agrees.

Capability baseline

Use references/capability-baseline.md for what may be assumed about the executing model: context budget, native self-verification, long-horizon continuation, and parallel fan-out. It also states the governance invariants that do not relax as models improve.