25/09 edition: the patch finished, but was exposure actually closed?

What the ticket must be able to prove

This edition addresses the maintainer, security team and service owner accepting a change. The question is narrower than 'are we secure?': did remediation remove the bounded exposure across this asset set? There is no invented CVE or exploit, and no patch this editorial team applied on 25 September.

NIST SP 800-40 Rev. 4's public abstract defines patch management as including identification, prioritisation, acquisition, installation and verification of installation. The abstract and final publication record were read, not the full PDF. The detailed protocol below is an original Velqory proposal, not a sequence attributed to NIST.

Write the target before making the change

Our proposal starts by retaining the affected condition from the applicable primary advisory, the instance set and authorised routes to check. Do not publish sensitive environment details. Define what observation distinguishes fixed from merely installed, and what dependency might require restart or instance replacement.

NCSC recommends knowing assets, owners and versions. Our editorial adaptation selects persistent service identifiers and links each observation to the right instance. An address alone can correspond to multiple nodes over time; the dossier should explain what was observed, when and from where.

Three forms of evidence that cannot replace each other

Velqory proposal: retain the installation record, confirmation of the actual running state and an authorised observation of the relevant route. Do not use one 'success' screenshot for all three. The confirmation method must follow product documentation and be approved in advance by the owner.

NCSC recommends verifying that vulnerabilities addressed by reconfiguration or mitigation are no longer present, while monitoring temporary workarounds. This supports verification, not the result of any environment. If a test excludes an instance, state the gap rather than extrapolating.

Criteria for accepting closure

This is an untested proposal. The service owner accepts the change; where resources allow, somebody other than the implementer reviews whether evidence matches the target. If a row fails, record partial progress, containment and the next check, not 'resolved'.

An old node remained behind routing

Hypothetical scenario: an update reaches two nodes, but a third still serves requests through another route. The exercise need not execute an exploit. Ask the team to connect each node to the change record and explain the coverage of the observation after rollout.

If the verifier only saw the router and cannot establish destination coverage, closure fails our proposed criterion. An alternative is temporarily reducing exposure of the unverified node through an authorised decision and completing validation. Do not declare isolation solved every risk without evidence of scope.

Do not confuse closure with absence of an incident

Proposed closure asserts only that a condition was checked within the described scope. It does not prove that exploitation never occurred before the change or that other vulnerabilities are absent. Indications of compromise require a separate investigation with evidence preservation and its own authority.

Also record reopening signals: rollback, an added node, restart restoring old configuration or a new access route. Velqory recommends making the ticket a reproducible conclusion, not a celebration of the installer. Whoever receives the service should know exactly what was accepted and which unknowns remain open.