Vulnerability Management Automation
Vulnerability Management · Exposure Management · Security Operations · Automation
Turning Security Findings Into an Operational Remediation Program
Finding vulnerabilities is only the first step.
The harder problem is turning findings into something engineering teams can understand, prioritize, remediate, and verify without creating a flood of low-context security tickets.
I worked on improving the vulnerability-management lifecycle by connecting cloud and security findings with engineering workflows, adding validation, defining remediation expectations, and improving ownership across teams.
The goal was to move from:
Finding → Ticket
to a more complete lifecycle:
Finding → Validation → Prioritization → Ownership → Remediation → Verification → Closure
The Problem
Modern security platforms can generate a large number of findings across:
Cloud resources
Containers
Vulnerable packages
Public exposure
Identity permissions
Misconfigurations
Secrets
Attack paths
Endpoint security
Application dependencies
The challenge is that severity alone does not always explain risk.
A vulnerability that looks moderate in isolation can become critical when combined with:
Internet exposure
Excessive permissions
Sensitive data
Reachable credentials
Weak network segmentation
Privileged service accounts
Additional exploitable weaknesses
Likewise, a finding marked critical may require validation before engineering invests time in remediation.
The security program therefore needed a workflow that preserved automation without turning security into noise.
My Approach
I focused on building a vulnerability-management process around four principles:
Automation
Validation
Ownership
Accountability
Automation should move information quickly.
Validation should improve signal quality.
Ownership should make remediation clear.
Accountability should ensure findings do not disappear after assignment.
Integrating Security Findings With Engineering Workflows
One of the major improvements was connecting security findings from Wiz into Jira.
This allowed security issues to enter the same operational workflow engineering teams were already using.
Instead of relying on:
Email
Slack reminders
Spreadsheets
Manual follow-ups
findings could be routed into a structured ticketing process.
The integration made it easier to track:
Assigned team
Finding severity
Affected resource
Remediation status
Age
SLA expectations
Exceptions
Closure state
Why Automation Alone Wasn't Enough
A fully automated finding-to-ticket workflow can create a new problem:
ticket overload
If every finding is sent directly to engineering with minimal context, security teams can lose credibility quickly.
Engineers may begin to treat security tickets as background noise.
That means the vulnerability-management process needs a balance between scale and judgment.
I worked on improving how findings were validated and contextualized before or during assignment.
Understanding Risk Beyond CVSS
Traditional vulnerability management often centers heavily on CVSS.
CVSS is useful, but it does not capture the full environmental context.
For example, two systems with the same vulnerability can represent very different risk.
System A
Internal only
No sensitive data
Strong identity controls
Limited permissions
No known attack path
System B
Internet exposed
Privileged workload identity
Sensitive data
Reachable secrets
Connected to production systems
The vulnerability may be identical.
The risk is not.
Modern exposure-management tools can help combine these signals.
Attack Paths and Toxic Combinations
One concept I emphasized when working with engineers was that security severity may represent a combination of weaknesses, not just one CVE.
For example:
Internet Exposure
Known Vulnerability
Excessive IAM Permissions
Sensitive Resource Access
can create a much more serious risk than any individual finding by itself.
This helps explain why some cloud-security findings may initially appear “overrated” when viewed only through the vulnerability itself.
The surrounding context matters.
Triage and Validation
Before escalating material findings, I looked for context such as:
Is the resource actually exposed?
Is the vulnerable software reachable?
Does the workload run in production?
What permissions does the resource have?
Is sensitive data accessible?
Does the finding participate in an attack path?
Are compensating controls present?
Is there evidence that the vulnerability has already been mitigated?
Is the affected resource still active?
Is the issue duplicated elsewhere?
The goal was not to manually investigate every low-risk issue.
The goal was to apply human judgment where it materially improved prioritization.
Remediation SLAs
The vulnerability-management program used severity-based remediation expectations.
A typical structure included:
Critical — 7 days
High — 30 days
Medium — 90 days
Low / Informational — 180 days
These timelines created a common expectation for both security and engineering teams.
SLAs also made it possible to measure whether vulnerability management was actually improving over time.
Exceptions and Compensating Controls
Not every vulnerability can be remediated immediately.
There may be legitimate reasons such as:
Vendor dependencies
Production stability concerns
No available patch
Technical incompatibility
Business-critical legacy systems
False positives
Planned system retirement
Rather than allowing these findings to remain indefinitely open without explanation, exceptions should document:
Why remediation cannot occur
Who accepted the risk
What compensating controls exist
When the exception should be reviewed
Whether the resource is expected to be replaced
This converts “we can't fix it” into a documented risk decision.
Closure Validation
Another important lesson was that closing a Jira ticket does not necessarily mean the vulnerability is gone.
Whenever practical, remediation should be validated using the source security platform.
For example:
Jira says fixed
does not necessarily equal:
Wiz confirms the exposure no longer exists
A mature vulnerability-management lifecycle should verify the actual security state before considering the issue complete.
Jira and Security Platform Synchronization
Workflow integration can become complicated when multiple systems maintain state.
If the integration is primarily one-way, a finding can be:
Closed in Jira
Still open in the security platform
or:
Automatically remediated
Still represented by an outdated ticket
This makes synchronization strategy important.
I worked on improving workflows around:
Automated ticket creation
Assignment
Security validation
Potential auto-closure
Source-of-truth decisions
Status reconciliation
The objective was to reduce unnecessary manual administration without sacrificing validation.
Ownership
Vulnerability management works better when resource ownership is clear.
A strong ticket should answer:
What is affected?
Why does it matter?
Who owns it?
What action is expected?
When is it due?
When ownership is unclear, security findings frequently stall.
This made asset ownership and routing an important part of the workflow design.
Practical Tips & Tricks
1. Don't send engineers raw scanner output
Raw findings often contain too much information and too little context.
Summarize what matters:
Affected resource
Actual risk
Exploitability
Business context
Recommended action
Deadline
The full scanner detail can remain available through a link.
2. Validate the highest-severity findings first
You usually do not have enough time to manually review everything.
Start with:
Critical
then:
High
especially where there is:
Internet exposure
Privilege
Sensitive data
Active exploitation
Credential access
3. Prioritize attack paths over isolated findings
A single vulnerability may not be your biggest risk.
Look for combinations that create a viable path to:
Privilege escalation
Data access
Lateral movement
Production compromise
4. Verify ownership before assignment
Sending a ticket to the wrong team adds delay and frustration.
Asset metadata, tags, repositories, infrastructure ownership, and service catalogs can all help determine the correct owner.
5. Use severity as a starting point, not the entire decision
Scanner severity should inform triage.
It should not replace judgment.
Consider:
Severity + exposure + exploitability + privilege + data sensitivity + business context
6. Give engineers remediation context
A good security ticket should explain why the issue matters.
Bad:
Critical vulnerability detected. Fix immediately.
Better:
This internet-facing workload contains a known exploitable vulnerability and has access to a privileged service role. Remediation is prioritized because compromise could provide access beyond the affected container.
Context increases cooperation.
7. Track age, not just count
A vulnerability dashboard showing 1,000 findings does not tell you much.
Age can be more useful.
Track:
Critical past SLA
High past SLA
Median remediation time
Oldest unresolved findings
New vs. closed findings
8. Don't close findings based only on a comment
Where possible, validate through the security platform that the condition has actually changed.
This reduces false closure.
9. Automate repetitive routing
Humans should spend time evaluating risk, not copying findings into tickets.
Automate:
Ticket creation
Metadata
Severity
Ownership
Links
SLA dates
Then reserve human review for judgment.
10. Tune for trust
Vulnerability management depends heavily on engineering trust.
If engineers repeatedly receive low-quality findings, they will eventually ignore even good ones.
Signal quality is a security control.
Metrics That Matter
Useful vulnerability-management metrics can include:
Open Critical findings
Open High findings
Findings beyond SLA
Mean time to remediation
Median time to remediation
Percentage remediated within SLA
Finding recurrence
Findings by owning team
Findings by environment
Findings by exposure type
Accepted-risk count
Exception age
The goal is not to produce dashboards for their own sake.
Metrics should answer:
Are we actually reducing meaningful exposure?
The Security and Engineering Relationship
A vulnerability-management program succeeds when Security and Engineering operate as partners.
Security brings:
Threat context
Exposure analysis
Prioritization
Validation
Engineering brings:
System context
Implementation knowledge
Remediation
Operational impact awareness
The best outcomes happen when neither group treats the other as a ticket queue.
Outcome
The improved workflow created a more structured vulnerability-management lifecycle.
It provided:
Faster routing
Better ownership
Clearer remediation expectations
Improved finding context
Defined SLAs
Better visibility into overdue risk
Stronger validation before closure
Less dependence on manual ticket administration
Most importantly, it shifted vulnerability management from a scanner-driven process toward a risk-driven operating model.
Technologies
Wiz · Jira · AWS Security Hub · Amazon Inspector · CrowdStrike · AWS · Kubernetes · Cloud Security · Exposure Management · Vulnerability Management
What This Demonstrates
This project demonstrates experience in:
Vulnerability management
Exposure management
Security operations
Risk prioritization
Cloud security
Workflow automation
Jira integration
Remediation SLAs
Security metrics
Engineering partnership
Control validation
Security-program maturity
Key Takeaway
The goal of vulnerability management is not to close the most tickets. It is to identify and reduce the exposures most likely to create meaningful risk.