Security automation should accelerate judgment, not remove it.
When a scanner produces a high-severity finding, immediately creating a ticket may look efficient. But if the asset, exposure, evidence, or owner is wrong, that automation transfers investigation work to another team and weakens trust in the security program.
My preferred workflow is:
Discover → validate → prioritize → assign → remediate → verify → close
Each step should produce evidence.
First, confirm what the tool actually found
I begin with four questions:
Does the affected resource still exist?
Does the detected condition still exist?
Is the asset or software actually in the vulnerable path?
How current is the evidence?
A valid software-version match can still overstate organizational risk if the component is unreachable or unused. Conversely, a finding should not be dismissed merely because the vulnerable value appears encoded, wrapped in JSON, or stored in an unexpected format.
Encoding is not encryption. Encryption is not necessarily sufficient protection. The relevant question is whether an unauthorized party could obtain or use the underlying value.
Separate exposure from compromise
I document findings using three different statements:
Potential exposure: The vulnerable condition exists and could be reached under defined circumstances.
Observed behavior: Testing or telemetry shows that the condition can be exercised.
Confirmed compromise: Evidence shows unauthorized use or impact.
Those are not interchangeable.
A scanner confirming that a credential remains usable is strong evidence that remediation is required. It does not, by itself, prove that an attacker used the credential.
Clear language prevents unnecessary escalation while preserving the seriousness of the finding.
Prioritize with more than severity
CVSS describes vulnerability severity. It is not a complete statement of business risk. NIST’s vulnerability-metrics guidance identifies CVSS as a qualitative measure of severity. NVD
I would enrich severity with:
Internet or network exposure.
Asset criticality and data sensitivity.
Required privileges and reachable attack path.
Compensating controls.
Known exploitation evidence.
Exploitation probability.
Business impact.
Evidence confidence.
CISA recommends using its Known Exploited Vulnerabilities Catalog as an input to vulnerability prioritization—not as the entire prioritization method. cisa.gov
FIRST’s EPSS estimates the probability that a published CVE will be exploited in the next 30 days. It can help focus limited remediation capacity, but it should be combined with severity and environmental context. first.org
Make the ticket useful
A validated ticket should tell the owner:
What was detected.
Which resource and component are affected.
When the evidence was last checked.
Why the finding matters in this environment.
What remediation or mitigation is expected.
How Security will verify the result.
What remains uncertain.
I also include the evidence source rather than copying only the scanner’s title.
That makes ownership clearer and reduces the familiar cycle of reassignment, clarification, and premature closure.
Treat false positive as a conclusion
“False positive” should describe a completed validation outcome.
Useful evidence might show that:
The scanner identified the wrong component or version.
The resource no longer exists and inventory lag explains the result.
The vulnerable execution path is absent.
The detected value cannot provide the claimed access.
A vendor confirms the condition does not apply.
A compensating control is different. It may reduce risk without making the finding false.
An accepted risk is different again. The condition remains, but an authorized owner accepts it for a documented period.
Keeping these outcomes separate improves reporting and exception management.
Verify remediation in the source of truth
A Jira ticket marked Done proves that someone changed the ticket status. It does not prove that the security condition disappeared.
Before closure, I look for current evidence such as:
A rescan no longer detects the condition.
A credential was revoked and can no longer authenticate.
A vulnerable package is absent from the deployed artifact.
The exposed path is no longer reachable.
The required control is present and operating.
Where rescanning is delayed, I may record remediation as implemented but awaiting validation. I avoid presenting it as verified closure.
Apply Zero Trust to the process
Zero Trust means verifying the state instead of trusting labels such as Critical, Fixed, or False Positive.
Defense in depth means combining scanner evidence, asset context, threat information, configuration review, and remediation validation.
Least privilege matters too: analysts need enough access to validate findings, but they do not necessarily need unrestricted production administration.
The purpose of vulnerability management is not to move findings through a ticket queue. It is to reduce verified risk while preserving an evidence trail that others can trust.
Explore my related Security Engineering Case Studies.