CVE‑2025‑6543 is a zero‑day vulnerability in Citrix NetScaler ADC and Gateway appliances. Rapid7 confirmed exploitation prior to the public patch release on June 26, 2025.

• CVSS v3.1: Not yet available (zero‑day)

• Exploit Status: Demonstrated in the wild

• Affected Systems: NetScaler ADC/Gateway versions with default configs

Why It Matters

NetScaler is widely deployed in enterprise router and access gateway roles. This zero‑day allows attackers to execute code remotely with elevated privileges — often without authentication.

Recommended Actions

1. Apply Citrix’s emergency patch immediately.

2. Review appliance configurations, especially access rules and VPN settings.

3. Watch for anomalous admin logs or configuration changes post‑exploit.

Key Takeaway

Network appliance zero‑days are especially dangerous — they’re exposed and trusted. Rapid patch deployment and continuous monitoring are non‑negotiable.

CVE‑2025‑6554 is a critical zero‑day vulnerability in Chrome’s V8 JavaScript/WebAssembly engine. Google patched it on July 1, 2025, after confirming active exploitation in the wild by unknown threat actors :contentReference[oaicite:1]{index=1}.

• CVSS v3.1: Not yet scored (zero‑day)

• Exploit Status: Confirmed active exploitation

• Affected Software: Google Chrome (all platforms)

Why It Matters

This is Chrome’s fourth zero‑day this year — and another active exploit targeting a core browser component. Threat actors can bypass sandboxing and run arbitrary code, posing severe risks to endpoint security :contentReference[oaicite:2]{index=2}.

Recommended Actions

1. Update Chrome immediately to the latest stable version.

2. Monitor browser processes for unusual behavior or crash indicators.

3. Enforce automated patching, especially in managed environments.

Key Takeaway

Zero‑days in browser engines remain high‑impact and are now routine. Active exploitation heightens risk — patch without delay.

CVE‑2025‑2783 is a recently patched zero-day in Google Chrome, actively exploited by the threat group TaxOff to deliver the “Trinper” backdoor.

• CVSS v3.1: 8.3 (High)

• The exploit targets a sandbox escape, enabling unauthorized access via browser visit :contentReference[oaicite:2]{index=2}.

Why It Matters

• This is an in-the-wild exploit affecting unpatched Chrome installations.

• Browser sandbox escapes are rare and high-impact events.

• The identified threat actor (“TaxOff”) is maintaining a stealthy malware campaign.

Recommended Actions

1. Update Chrome Immediately to the latest stable release.

2. Check for Indicators of Compromise related to “Trinper” in browser activity logs.

3. Enforce automated Chrome updates across your environment.

Key Takeaway

Browser zero-days still pose significant risk. Active exploitation combined with sandbox bypass means urgent patching is essential—no exceptions.

CVE‑2025‑49144 is a newly disclosed privilege escalation vulnerability affecting Notepad++ v8.8.1. Despite being a local attack, it poses a serious risk due to ease of exploitation and availability of proof-of-concept code in the wild.

Why It Matters

• The vulnerability allows a local user or compromised account to gain full system control—high impact for desktops and developer workstations.

• Notepad++ is widely used by sysadmins and developers, making it a common target.

• The released PoC lowers the barrier for exploitation, increasing urgency.

Recommended Actions

1. Update Immediately to the latest patched version of Notepad++.

2. Restrict write-permissions to Notepad++ directories on shared systems.

3. Monitor privileged process launches originating from Notepad++ (EDR or SIEM).

Key Takeaway

Local privileges can be just as dangerous as remote exploits—particularly for trusted applications. Treat released PoCs as an urgent indicator and act accordingly.

CVE‑2016‑3351: A Low‑Scoring Vulnerability with Real‑World Exploits

Why It’s on the CISA KEV List

CVE‑2016‑3351 is an older Internet Explorer vulnerability with a relatively low CVSS score. Despite that, it has been actively used in real-world attacks — particularly as part of exploit kits tied to ransomware delivery.

This shows why CVSS alone can be misleading. A low score does not mean a low risk.

Key Points:

• Theoretical vs. Practical Risk
  CVSS scoring reflects potential impact under assumed conditions, not whether attackers actually use it.

• Used in Ransomware Delivery
  This vulnerability was exploited by multiple malware families, including CryptoWall and Bad Rabbit, through exploit kits in the wild.

• CISA KEV Inclusion Criteria
  CISA adds CVEs to the Known Exploited Vulnerabilities (KEV) catalog based on confirmed exploitation, not just score. This vulnerability met the criteria:

  • It has a CVE identifier

  • It has been actively exploited

  • There is a known fix or mitigation path

Implications for Vulnerability Management

• Do not rely on CVSS alone. This vulnerability is a case study in why that’s dangerous.

• Exploitability must factor into prioritization. CISA KEV entries should trigger urgent review regardless of severity score.

• Legacy systems remain a real risk. Even if a CVE is years old, if it’s exploitable and present, it’s still a live threat.

Recommended Actions

1. Verify asset exposure. Are any legacy Internet Explorer versions still in use or accessible?

2. Apply mitigations or compensating controls. Remove legacy browsers where possible, or isolate and monitor them.

3. Ensure KEV CVEs are treated as priority. Use a threat-aware prioritization policy that boosts exploited items.

Summary

CVE‑2016‑3351 may not stand out by CVSS score alone, but it has a clear record of real-world abuse. The fact that it remains on CISA’s KEV list underscores the importance of prioritizing based on exploitation activity — not just severity metrics.

If your prioritization policy doesn’t currently factor in KEV or known exploited vulnerabilities, this is a strong reason to update it.

This post is part of the “Briefings” series — fast, focused takes on topics that matter in vulnerability management.

The CISA Known Exploited Vulnerabilities (KEV) list is one of the most actionable threat intelligence feeds available — and it’s completely free.

But most organizations either underuse it, or apply it in shallow ways that don’t translate into actual risk reduction.

What KEV Actually Tells You

• A vulnerability is being exploited in the wild

• CISA believes it's serious enough to require patching for federal agencies

• It’s not speculative. It’s not theoretical. It’s real-world threat activity

What KEV Doesn’t Tell You

• If the CVE applies to your version or your configuration

• Whether controls already mitigate the risk (e.g., segmentation, EDR)

• How long it has been exploited — the KEV list can lag behind real-world use

How to Use KEV Effectively

• As a risk signal in prioritization (e.g., KEV = auto Critical regardless of CVSS)

• As a patching override (bump timelines from 30 days to 7)

• As a remediation conversation driver with service owners and teams

• As a compliance signal — especially for regulated US orgs or contractors

Suggested Controls

✅ KEV is Integrated into VM Tools
Your vulnerability platform highlights or tags KEV vulnerabilities clearly.

✅ KEV-Listed CVEs Trigger SLA Overrides
Internal policy states that KEV = Critical, with fast-track remediation (e.g., 7-day SLA).

✅ KEV Coverage is Audited Regularly
You maintain a report showing open KEV vulnerabilities across your estate, reviewed weekly.

➡️ Want to connect or ask a question? Find me on LinkedIn

This post is part of the “Briefings” series — fast, focused takes on topics that matter in vulnerability management.

Microsoft’s Patch Tuesday is a relic of early 2000s enterprise IT — yet it continues to shape patch cycles, threat landscapes, and exploit timelines. Why?

Because coordinated disclosure windows and structured risk communication still have real-world value.

What Patch Tuesday Actually Means

• It’s a predictable drop of Microsoft patches on the second Tuesday of every month

• Often includes Adobe, SAP, and other vendors who align their releases

• Typically features:

  • Remote Code Execution (RCE) vulnerabilities

  • Privilege escalation bugs

  • Zero-day disclosures

  • Occasionally KEV additions

Why You Should Still Care

Even if you’ve automated most patching and CI/CD is humming:

• PoC code emerges fast
  Public exploits and weaponized metasploit modules often follow within hours

• Zero-day reveals are common
  Microsoft often discloses actively exploited bugs on Patch Tuesday

• It creates a planning rhythm
  Many orgs structure their remediation cadence around these monthly drops

Real-World Tip

Use Patch Tuesday as a "Threat Review Window" — not just a patch drop.

Treat it as a recurring moment to:

• Review which CVEs actually apply to your environment

• Escalate certain fixes beyond standard SLAs

• Update KEV, vendor exploit feeds, and threat intelligence links

Suggested Controls

✅ Patch Tuesday Monitoring is Part of VM Workflow
Monthly updates are reviewed for severity, exploitability, and exposure to your estate.

✅ Zero-Day Disclosures are Flagged Immediately
Any disclosed in-the-wild exploited bugs are automatically pushed to critical review.

✅ Patch Windows are Pre-Agreed and Repeatable
IT Ops and Infrastructure teams align patch windows around Microsoft’s cycle to reduce friction.

➡️ Want to connect or ask a question? Find me on LinkedIn

A real-world vulnerability management process doesn’t always need expensive tools. Whether you’re just getting started or want to augment existing platforms, here’s a curated list of free or open-source tools that support every stage of the VM lifecycle.

These tools aren’t “nice to haves” — many are used by professionals in live production environments.

Asset Discovery & Inventory

Nmap
A classic network discovery and port scanning tool.
→ https://nmap.org/

Lansweeper Free Edition
Agentless network scanning for asset inventory and device classification.
→ https://www.lansweeper.com/

Rumble (now runZero) – Free Tier
Cloud-based asset discovery for hybrid environments. Free for small-scale use.
→ https://www.runzero.com/

IP Fabric Community Edition
Network topology and device visibility. Helps validate network-level asset inventory.
→ https://ipfabric.io/

Vulnerability Scanning

OpenVAS / Greenbone Community Edition
An open-source vulnerability scanner, regularly updated with community feed.
→ https://www.greenbone.net/en/community-edition/

Nessus Essentials
Free version of the commercial Nessus scanner, limited to 16 IPs.
→ https://www.tenable.com/products/nessus/nessus-essentials

Nikto
A lightweight web server scanner for common misconfigurations and issues.
→ https://cirt.net/Nikto2

Trivy
A fast, open-source scanner for container images, filesystems, and Git repos.
→ https://github.com/aquasecurity/trivy

Prioritization & Threat Intel

CISA KEV Catalog (API or CSV)
Regularly updated list of known exploited vulnerabilities (KEV).
→ https://www.cisa.gov/known-exploited-vulnerabilities-catalog

VulnCheck KEV (Open Data Tools)
Expanded datasets and enrichment around exploited vulnerabilities.
→ https://vulncheck.com/

Exploit Prediction Scoring System (EPSS)
Free scoring system to estimate likelihood of exploitation in the wild.
→ https://www.first.org/epss/

Shodan Free
Search engine for internet-connected devices. Useful for checking external exposure.
→ https://www.shodan.io/

Reporting & Analysis

Elastic Stack (Elasticsearch, Logstash, Kibana)
Open-source stack for building custom dashboards, reports, and visualizations.
→ https://www.elastic.co/what-is/elk-stack

Grafana
Open-source visualisation and dashboarding platform. Integrates with many scanners.
→ https://grafana.com/

GVM Dashboards
Community dashboards built on top of Greenbone/OpenVAS.
→ https://github.com/greenbone/gvmd

Final Thoughts

Free tools can fill critical gaps in visibility, detection, and communication — but they work best with a clear process behind them.

Have a tool you rely on that’s not listed here?
Let me know and I’ll consider including it in the next update.

Want to connect or ask a question? Find me on LinkedIn

This post brings together the full “Building a Real-World Vulnerability Management Process” series — a six-part practical guide based on field-tested experience, not theory.

Why This Series Exists

Vulnerability Management isn’t just a scan and a report. It’s a process — one that spans multiple teams, tools, and decisions.

Most resources focus on tools. This series focuses on real-world operations: who does what, how risk is prioritized, and how to turn scan data into meaningful action.

The Six Stages of a Practical VM Program

Each phase of the process builds on the last — and all are required if you want a VM program that’s complete, defensible, and effective.

Part 1: Asset Discovery and Scanning

Laying the foundation for visibility and coverage

How do you know what to scan? How do you ensure new assets are automatically included? This post explores discovery sources, scan types, and common blind spots.

Part 2: Vulnerability Assessment

From scan results to smart decisions

Not all vulnerabilities matter equally. This post dives into prioritization, exploitability, external exposure, and how to create your own Prioritization Framework.

Part 3: Vulnerability Reporting

Turning scan data into decisions and accountability

Reporting isn’t just dashboards — it’s how you communicate risk, show progress, and create accountability across teams. This post looks at reporting formats, metrics, and stakeholder alignment.

Part 4: Remediation

Driving risk reduction through collaboration, not control

This is the heart of vulnerability management. Learn how to coordinate action across teams, track blockers, verify fixes, and define what mitigation really means.

Part 5: Verification

How to confirm fixes, validate controls, and prove risk reduction

How do you know remediation actually worked? This post covers rescanning, validating mitigations, SLA follow-up, and post-patch assurance.

Part 6: Continuous Improvement

How to keep your VM program relevant, responsive, and resilient

The most mature programs review their process regularly. This post explores how to embed learning loops, tool reviews, KPIs, and stakeholder feedback.

What's Next?

• Want to turn this into a checklist?

• Want a downloadable PDF version?

• Want to go deeper with a VM Policy or Prioritization Framework template?

Let me know what you'd find useful — this series was built to help real teams do real work more effectively.

Want to connect or ask a question? Find me on LinkedIn

This post is part of the “Building a Real-World Vulnerability Management Process” series — a practical guide to documenting what actually works in the field.

The Most Overlooked Stage

Most vulnerability management programs stop at verification. But if you want a sustainable, resilient, and auditable process — you need to build in continuous improvement.

The threat landscape evolves. Your environment changes. Teams change. Tools change.

Without regular reflection and refinement, your VM process risks becoming outdated, ignored, or ineffective.

What Continuous Improvement Looks Like

Continuous improvement is a mindset and a cadence — a habit of reviewing what’s working, what’s not, and what needs to change.

It includes:

• Regular process reviews

• Tool and platform tuning

• Lessons learned from incidents or failures

• Training and upskilling

• Stakeholder feedback loops

• Tracking process metrics over time

When to Improve

You don’t need to overhaul the process weekly. But you do need a deliberate rhythm:

• Quarterly VM process reviews
  Walk through each stage of the process: what’s working, what’s lagging, what’s changed?

• Post-incident retrospectives
  If an incident relates to a missed vulnerability, dig into where the process failed: Discovery? Assessment? Prioritization? Fix?

• New asset types or environments
  Bring the VM process to new platforms (e.g., cloud-native, OT, containers) as the org grows.

• Tooling upgrades
  Ensure new platform features are reviewed and, if helpful, adopted.

Examples of Improvement

• Switch from unauthenticated to authenticated scans after audit feedback

• Create new tagging strategy to improve asset classification

• Tune SLA tiers based on actual remediation times

• Document false positive review process

• Build dashboards that show business units their own exposure

Suggested Controls

• ✅ Quarterly Process Review
  VM team holds a regular improvement session covering performance, pain points, and pipeline gaps.

• ✅ Tooling Feature Review
  VM platforms are reviewed at least annually for unused or new features that may improve process flow.

• ✅ Post-Incident Improvement Tracking
  Lessons from missed vulnerabilities or audit findings are used to update the process or documentation.

• ✅ Training & Skill Development
  VM staff are given time and budget for platform training, vulnerability research, and threat awareness.

• ✅ Stakeholder Feedback Loop
  Patching teams, risk owners, and IT leads are asked regularly for feedback on data quality and process friction.

• ✅ Process KPIs
  Time to patch, time to verify, false positive rate, and SLA compliance are tracked over time to identify trends.

Why This Phase Matters

Continuous improvement is what turns your VM process from a reactive scanner into a strategic capability.

It’s how you adapt to new threats, respond to audit findings, and keep your teams engaged.

In a world where everything changes, a process that stands still quickly becomes irrelevant. But one that evolves stays valuable.

➡️ Want to connect or ask a question? Find me on LinkedIn

This post is part of the “Building a Real-World Vulnerability Management Process” series — a practical guide to documenting what actually works in the field.

Why Verification Matters

Patching is not the end — verifying that a fix was applied correctly is how you close the loop.

Real-world VM programs are full of false positives:

• Patches that silently fail

• Fixes applied to the wrong environment

• Reboots not performed

• Mitigations that drift over time

Without a feedback loop, you’re trusting that “Resolved” in the ticketing system = “Remediated” in reality. Often, it doesn’t.

What Verification Means in Practice

Verification isn’t just rescanning. It’s about confirming that the original risk has been eliminated or mitigated. That includes:

• Confirming CVE is no longer detected by scanner

• Confirming compensating control (e.g., WAF, config) is still active

• Validating that the correct asset was fixed (and not just tagged)

• Ensuring that waivers have end dates and follow-up reviews

This phase helps turn vulnerability management from a ticket-closing exercise into a risk reduction function.

How Long After Patching Should You Rescan?

Best practice: within 24–72 hours of patch window, depending on your platform’s scan cycle.

• Agent-based scanning: Should auto-confirm within a few hours

• Network-based scanning: Schedule rescans post-maintenance

• Cloud-native assets: Consider webhook-triggered or pipeline-driven scans

Tip: Log patch job completion timestamps so you can correlate when fixes were applied vs. when they're confirmed.

How to Verify Mitigations

Patching isn't always possible — especially for legacy or fragile systems.

In those cases, verification must include a control validation step, such as:

• Confirming WAF or firewall rule is applied and active

• Checking that vulnerable service is disabled or blocked

• Running test exploit scripts to simulate impact

• Reviewing change logs or configuration management output

Risk acceptance doesn’t end the conversation — it requires re-evaluation at a future date.

Common Challenges

• Scan lag: Scanner runs days after patch applied = false positive

• Agent gaps: Agents may be offline or deinstalled

• Delta-only scans: Some platforms don’t pick up every change unless full scan is triggered

• No post-fix tracking: Teams assume “applied” = “done” with no validation workflow

• Unverified waivers: No process for checking mitigations after acceptance

Suggested Controls

• ✅ Automated Rescan After Patch Windows
  Scheduled or triggered scans occur within 24–72 hours of planned remediation windows.

• ✅ Agent Check-In Monitoring
  Systems with agents are monitored for scan freshness; alerts sent for offline hosts.

• ✅ Mitigation Verification Steps
  Where patches are not possible, compensating controls are manually or automatically validated.

• ✅ Waiver Review Schedule
  All accepted risks are re-reviewed quarterly or semi-annually.

• ✅ Patch Job Correlation
  VM and patching teams align to log when updates are deployed and confirmed by scanner.

• ✅ Post-Patch Reporting Dashboards
  Dashboards show fix rate, false positives, and overdue verifications.

Why This Phase Matters

Verification is where your VM program proves it’s doing more than tracking vulnerabilities — it’s confirming results.

If you don’t verify, you’re only assuming risk has gone down. If you do verify, you can prove it.

It also improves credibility with audit, executives, and security leadership: not just “we said we fixed it,” but “we know we did.”

➡️ Want to connect or ask a question? Find me on LinkedIn

This post is part of the “Building a Real-World Vulnerability Management Process” series — a practical guide to documenting what actually works in the field.

Why Remediation Is Everything

Vulnerability Management is only successful if vulnerabilities are actually fixed.

This is the most important phase — all others exist to support it.

You can have the best scanning tools, the most accurate risk scoring, and gorgeous dashboards — but if remediation isn’t happening, nothing changes.

The True Role of a Vulnerability Manager

The VM team typically doesn’t patch systems or deploy config changes. Instead, your role is to drive remediation through:

• Presenting accurate, prioritized risk

• Highlighting external exposure and real-world threats

• Coordinating with owners, platform teams, and app leads

• Following up and tracking status

• Flagging blockers and escalating as needed

Your job is to make it easy for others to do the right thing — and hard to ignore the real risk.

Remediation Approaches

There are three primary paths to remediation:

1. Patching – Apply a vendor-provided fix or upgrade

2. Configuration Change – Disable vulnerable features, block ports, or restrict access

3. Mitigation – Implement a compensating control (if patching isn’t feasible)

What Counts as Mitigation?

Mitigation is not ignoring a vuln. It’s applying an interim or alternative control that reduces the risk to an acceptable level — ideally until a permanent fix is possible.

Examples of Effective Mitigation

• WAF rules that block exploit signatures

• ACLs to restrict access to vulnerable services

• Registry or config changes to disable affected functionality

• EDR prevention of specific attack techniques

• Isolation via firewall, VLAN, or segmentation

• Scheduled upgrades or infrastructure migrations with agreed deadlines

Mitigations should be documented, reviewed, and — if necessary — accompanied by a risk acceptance waiver.

Common Remediation Pitfalls

• No asset owner identified: Vulnerabilities linger when no one takes responsibility

• Lack of urgency: Without clear prioritization, critical vulns are lumped in with noise

• Missed dependencies: Patch fails due to OS/app compatibility, restarts, or downtime risks

• Technical blockers: Upgrades may require newer kernel versions, config files, or staging/testing cycles

• Business blockers: Fear of downtime, change freezes, or conflicting priorities

As a VM professional, you won’t solve all these issues — but you can raise visibility, coordinate conversation, and track progress.

Effective Remediation Practices

Here’s what works in real organizations:

• Weekly remediation meetings with all service owners

• Pre-filtered lists focused on external, critical, or KEV vulnerabilities

• Grouping issues by team/application, not random CVEs

• Dashboard + CSV + human-readable summaries

• Escalation route for overdue vulns or blocker approvals

• Waiver process for exceptions — with review cycle

Suggested Controls

• ✅ Clear Ownership Mapping
  Each asset group or application is linked to a team responsible for patching or mitigating vulnerabilities.

• ✅ Remediation Meeting Cadence
  Weekly or biweekly meetings are held to review outstanding issues, actions, and blockers.

• ✅ Documented Waiver Process
  Risk acceptance or mitigation is formalized with justification, duration, and re-review dates.

• ✅ Escalation Routes for Overdue Items
  A defined path exists for escalating overdue critical vulns to management or risk owners.

• ✅ Remediation SLAs
  SLAs are tracked, and overdue items are flagged and discussed regularly.

• ✅ Standard Mitigation Guidance
  Platform teams have pre-agreed mitigation options for common tech stacks (e.g., WAF rules for Apache, config flags for Windows).

• ✅ Patch Failure Handling
  Failed patches are logged, reviewed, and retested — not ignored or dropped.

Why This Phase Matters

Fixing vulnerabilities is the only outcome that matters. Everything else — the scanning, the assessment, the reporting — is preparation.

Remediation is how you reduce risk, meet compliance, avoid headlines, and build trust.

The best vulnerability managers understand that their role is about influence, persistence, communication, and prioritization — not just tools and tickets.

➡️ Want to connect or ask a question? Find me on LinkedIn

This post is part of the “Building a Real-World Vulnerability Management Process” series — a practical guide to documenting what actually works in the field.

Scan results and assessment are only useful if the right people know about them. Reporting is how vulnerability management becomes visible, measurable, and actionable.

It’s how the business understands progress, how patching teams are held accountable, and how executives stay informed without drowning in detail.

What Is Vulnerability Reporting?

Reporting is the act of translating scan and assessment data into usable formats for different audiences. It gives shape to the backlog, highlights the trends, and drives decision-making.

Good reporting isn’t just about charts — it should answer key questions:

• Where is the risk?

• What’s improving?

• What’s not?

• Who owns the problem?

• What needs to happen next?

Know Your Audiences

Vulnerability data means different things to different people. Tailor reports accordingly:

• Infrastructure and App Teams → Focus on specific hosts, patchable vulns, and deadlines

• VM / SecOps Teams → Overview of trends, backlog, compliance vs. SLA

• Executives → Risk posture snapshots, exceptions, and movement on top priorities

• Audit and Risk → Proof of process, controls, risk decisions, waivers, and SLA adherence

Common Reporting Formats

Use a mix of real-time tools and structured reports. Most mature programs adopt a multi-format model:

• Dashboards – Visual, always-on view into posture and trends

• CSV Exports – Used for deep dives, filters, or combining with asset inventories

• PDF Packs – Lightweight and readable summaries for monthly/quarterly distribution

• Meeting Minutes – Capture blockers, owners, decisions, and next steps during weekly review calls

Common Reporting Pitfalls

• No ownership mapping: Reports that don’t clearly show who’s responsible lose accountability

• Too much data: Dumping every CVE into a spreadsheet is overwhelming

• Stale metrics: Old scan data = unreliable risk picture

• Lack of trend view: Snapshot reports are fine, but trend reporting shows progress

• Executive overload: Execs need summaries, not scan detail

Suggested Controls

• ✅ Defined Reporting Schedule
  Weekly team reports, monthly management summaries, and quarterly board/audit updates are clearly documented.

• ✅ Ownership Mapping
  All vulnerabilities are linked to business units or teams responsible for remediation.

• ✅ Trend Reporting
  Reports track open/closed volumes, time-to-fix, SLA compliance, and backlog movement over time.

• ✅ Meeting-Based Reporting
  Regular VM review meetings are held with notes, assigned actions, and blockers captured.

• ✅ Exec & Audit Packs
  Lightweight summary reports are created to support leadership briefings and control reviews.

• ✅ Tool-Generated Reports
  Dashboards and exports from your VM platform are standardized and regularly reviewed.

Why This Phase Matters

Reporting is what keeps the wheels turning. Without it, no one knows what’s getting fixed — or not. It’s what drives action, supports evidence for audits, and helps organizations stay in control of risk.

It also shifts the perception of vulnerability management from “tech scanning” to risk governance.

➡️ Want to connect or ask a question? Find me on LinkedIn

This post is part of the “Building a Real-World Vulnerability Management Process” series — a practical guide to documenting what actually works in the field.

A vulnerability scan leaves you with one thing: a pile of vulnerabilities.

Assessment is where this noise becomes signal — where the goal isn’t to “patch everything,” but to fix the right things, at the right time, for the right reasons.

This step is critical in transforming scan outputs into an actionable, prioritized remediation plan.

What Is Vulnerability Assessment?

Assessment is the process of evaluating, scoring, filtering, and prioritizing vulnerabilities based on context. This includes:

• Technical severity (CVSS or vendor severity)

• Exploitability and threat intelligence

• Asset importance and exposure

• Business risk and sensitivity

A mature VM program recognizes that not all vulnerabilities matter equally — and the job of assessment is to triage risk intelligently.

Key Prioritization Dimensions

To assess effectively, you need to weigh vulnerabilities across several dimensions:

1. Exploitability

• Is there a known public exploit?

• Is the vulnerability being actively exploited in the wild?

• Is it listed in CISA KEV, vendor threat feeds, or internal threat intel?

2. Asset Exposure

• Is the asset externally facing or Internet-accessible?

• Is the vulnerability discoverable without credentials?

• Could it be exploited via phishing or supply chain channels?

3. Business Impact

• Does the asset support revenue-generating services?

• Does it hold customer data, payment information, or sensitive operational data?

• Is it part of critical infrastructure (e.g., OT/ICS systems, finance gateways)?

4. Technical Severity

• What is the CVSSv3 score? (Be cautious of over-reliance)

• Is there a vendor-specific risk rating?

• Are there known exploitation chains (e.g., pre-auth + RCE)?

5. Compensating Controls

• Is the vulnerability mitigated by network segmentation, firewall rules, or EDR?

• Is it behind a VPN or internal-only?

• Has a virtual patch been applied?

Define “Critical” in Your Context

The term “critical” is often misunderstood — especially when used interchangeably between CVSS scores, vendor ratings, and internal language.

A real-world program needs to be deliberate about how it defines criticality. For example:

• A CVSS 10 on a test system may pose no real risk

• A CVSS 7.5 with public exploit code on a customer-facing app might be high priority

In short, context matters, and your program should have a consistent internal definition of what gets treated as “critical” from a business and risk perspective.

Build a Prioritization Framework

In a real-world VM program, ambiguity is the enemy. Without a clear, documented policy on how vulnerabilities are prioritized, teams rely on gut feel, vendor defaults, or inconsistent logic.

A Prioritization Framework or Vulnerability Prioritization Policy helps clarify what your organization considers “critical” — and how different risk factors are combined into a decision.

It becomes the reference point for risk owners, patching teams, and audit.

What Should This Document Include?

• Critical Asset Categories: Revenue-generating, customer-facing, OT, or regulated systems

• Vulnerability Triggers: KEV inclusion, active exploitation, public PoC, unauthenticated access

• Exposure-Based Boosting: Internet-facing or unauthenticated findings get automatically prioritized

• SLAs by Risk Tier: Clearly defined timeframes for Critical, High, and Medium vulnerabilities

• Escalation & Risk Acceptance Guidance: When, how, and who can defer or waive remediation

This doesn’t need to be a long document — but it should be clear, agreed, versioned, and referenced often.

Suggested Controls

• ✅ Documented Prioritization Framework
  There is a policy that defines how vulnerabilities are assessed and prioritized across key dimensions.

• ✅ Exploitability Data Integration
  Your platform ingests CISA KEV, vendor exploit feeds, or internal threat intel into the assessment workflow.

• ✅ Asset Classification Tags
  Assets are tagged by business importance — e.g., customer-facing, revenue-critical, regulated, OT.

• ✅ External Exposure Flagging
  Scanning or asset inventory systems identify externally exposed systems and prioritize accordingly.

• ✅ SLA by Priority Tier
  Each vulnerability priority (e.g., Critical, High, Medium) is mapped to a time-based remediation SLA.

• ✅ Stakeholder Review Process
  There is a weekly or bi-weekly review of top vulnerabilities involving VM, infrastructure, and application teams.

• ✅ Risk Acceptance Workflow
  Low-priority or unpatchable vulnerabilities have a documented waiver/risk acceptance process.

Why This Phase Matters

Assessment is where your vulnerability management program moves from theory to practicality. It's what ensures:

• Remediation teams aren’t overwhelmed by volume

• Executives can see progress on what matters

• Audit teams can validate that risk-based decisions are being made

Ultimately, assessment is the prioritization engine that keeps your entire process grounded in real-world risk.

➡️ Want to connect or ask a question? Find me on LinkedIn

This post is part of the “Building a Real-World Vulnerability Management Process” series — a practical guide to documenting what actually works in the field.

A vulnerability management process starts with a single truth: you can’t secure what you don’t know exists. Discovery and scanning form the foundation for every other step in the vulnerability lifecycle. If your asset inventory is incomplete — or your scanning coverage is unreliable — all downstream efforts will be inconsistent at best, and misleading at worst.

This post outlines how to build the Discovery and Scanning section of your vulnerability management process documentation — with actionable controls that can be reviewed, validated, and audited.

Step 1: Define Asset Scope

Your first task is to clearly define what’s in scope for vulnerability management.

Asset Types to Include:

• On-prem servers and workstations

• Cloud instances (e.g. AWS EC2, Azure VMs)

• Containers and ephemeral compute

• Network devices (firewalls, load balancers, routers)

• Endpoints (laptops, desktops)

• External-facing assets (e.g. public IPs, exposed services)

• Third-party hosted infrastructure (where applicable)

Common Oversights:

• Shadow IT (untracked cloud assets, dev instances)

• Short-lived containers or test environments

• Dormant IP ranges with legacy systems

• Remote endpoints or unmanaged devices

A formal inventory should be sourced from:

• CMDB (e.g. ServiceNow)

• Cloud APIs and infrastructure-as-code

• Endpoint management platforms (e.g. Intune, JAMF, SCCM)

• Discovery tools (e.g. network probes, EASM platforms)

Step 2: Asset Discovery Mechanisms

Discovery mechanisms should run continuously or on a regular cadence to identify:

• Newly provisioned assets

• IPs in use but untracked

• Unexpected changes to asset states (e.g. previously offline servers)

Sources of Truth May Include:

• DHCP leases, DNS logs

• Cloud control planes (Terraform, AWS Config)

• Active Directory or Entra ID device joins

• External IP monitoring

Use asset tags or naming conventions to track:

• Business owner

• Location or region

• Platform (Windows, Linux, cloud type)

• Criticality (CBS/IBS classification)

Step 3: Scan Configuration

Once assets are discovered, define how they will be scanned.

Key Parameters:

• Authenticated or agent-based scanning (recommended for depth)

• Unauthenticated scans for attacker-simulated perspective

• Internal vs external scans based on exposure

• Scan frequency aligned to asset criticality and risk appetite

Typical Frequency:

• Critical external systems: Daily or continuous

• Internal infrastructure: Weekly

• Endpoints: Daily (via agents) or weekly

• Cloud assets: Integrated via API or infrastructure automation

• Ad hoc scans: Before go-live, post-patch, or security incidents

Scan Tuning:

• Limit scan windows to avoid business disruption

• Include DNS/NetBIOS resolution to identify assets from IP

• Schedule re-authentication record checks for credentialed scans

Step 4: Coverage Validation

The final — and most often missed — part of scanning is validation.

How Do You Know You’re Scanning Everything?

• Compare scan targets against CMDB, cloud asset lists, and endpoint platforms

• Look for IPs not seen in the last 30 days

• Track scan success/failure rates by asset

• Identify blind spots (e.g. legacy systems, segmented networks)

Suggested Controls

• ✅ All in-scope assets are defined, including infrastructure, endpoints, cloud workloads, and external services.

• ✅ A centralised inventory is maintained using data from CMDB, cloud APIs, and endpoint management platforms.

• ✅ New assets are added to scanning within 24 hours of provisioning or onboarding.

• ✅ Scan coverage includes all internal and external IP ranges, with defined frequency per asset type.

• ✅ Authenticated or agent-based scanning is used for internal systems; unauthenticated scans cover external-facing assets.

• ✅ Scan failures are tracked and remediated, with owners and due dates clearly assigned.

• ✅ Monthly reconciliation is performed between the asset inventory and active scan coverage.

• ✅ Asset tags (e.g. owner, environment, criticality) are applied consistently during onboarding or discovery.

Summary

Discovery and scanning are the foundation of any vulnerability management program. Get this part wrong, and everything that follows will be incomplete or misleading.

As you document your process, focus on:

• What assets are in scope

• How they’re discovered and added to scanning

• The method and frequency of scans

• How coverage is verified and monitored

In the next post, we’ll move into Assessment and Prioritisation — where raw scan data becomes actionable risk intelligence.

➡️ Want to connect, ask a question, or suggest a topic? Find me on LinkedIn.

Every organisation with a digital footprint has vulnerabilities — but not every organisation manages them well. Vulnerability management is the structured process of identifying, assessing, prioritising, remediating, and verifying vulnerabilities in systems, networks, and applications. When done correctly, it reduces risk, improves visibility, and strengthens your overall security posture.

It’s more than scanning. It’s about having a process in place — one that is consistent, measurable, and built to scale.

The Vulnerability Management Lifecycle

A mature vulnerability management function doesn’t rely on reactive, ad hoc fixes. It follows a defined, repeatable cycle. The typical stages are:

• Discovery and Scanning

• Assessment

• Reporting

• Remediation

• Verification

• Continuous Improvement

Each phase plays a critical role in ensuring vulnerabilities are not just found, but acted on.

1. Discovery and Scanning

You can’t secure what you don’t know exists.

Asset Discovery

Start with identifying your full asset inventory:

• Servers, desktops, laptops

• Cloud infrastructure (IaaS, SaaS, hybrid)

• Containers and virtual machines

• Network appliances, firewalls, load balancers

• Third-party hosted services

A mature program integrates with:

• CMDB (Configuration Management Databases)

• Cloud APIs (Azure, AWS, GCP)

• Endpoint agents and asset management platforms

Scanning

Once assets are known, they must be scanned regularly for vulnerabilities using tools such as:

• Agent-based or authenticated scans for deeper insight

• Unauthenticated scans for attacker-like visibility

• External scans for internet-facing risk

• Continuous monitoring for dynamic environments

Scan frequency should reflect asset criticality. For example:

• Internal servers: weekly or monthly

• Critical external services: daily or continuous

• New assets: immediately upon provisioning

2. Assessment

Scanning reveals vulnerabilities — assessment determines their relevance.

Prioritisation Criteria

Not all vulnerabilities are equally dangerous. Effective assessment considers:

• Severity: CVSS score (e.g. 9.8 is more critical than 4.3)

• Exploitability: Known exploits, proof-of-concept availability

• Threat Intelligence: Inclusion on KEV (CISA Known Exploited Vulnerabilities) list

• Asset Criticality: Does the asset support a critical business service?

• Exposure: Is it accessible externally? On an internet-facing port?

This is where risk-based vulnerability management (RBVM) stands apart from legacy, volume-based approaches. It focuses remediation efforts on what matters most, not just what scores highest.

Common Pitfalls

• Failing to contextualise severity

• Treating all vulnerabilities the same

• Relying only on CVSS without threat context

3. Reporting

Assessment means little if results don’t reach the right teams.

Stakeholder-Specific Reporting

Effective reporting breaks down by audience:

• Remediation Teams (Ops, Platform, App Support)

  • Actionable lists by asset group

  • Assigned deadlines or SLAs

  • Ticketing or change request integration

• Vulnerability Management Teams

  • Trends (e.g., backlog growth/shrink)

  • Coverage gaps

  • Scan success/failure

• Executives and Risk Owners

  • Risk exposure summaries

  • KPIs (e.g., time-to-remediate)

  • Compliance posture (ISO, NIST, PCI)

Metrics That Matter

• % of critical vulns remediated within SLA

• Mean time to remediation (MTTR)

• Assets with overdue vulnerabilities

• Coverage vs known asset inventory

4. Remediation

This is where the process delivers impact — and where many programs fall short.

Responsibilities

The vulnerability management function typically does not apply patches. Its role is to:

• Surface findings

• Prioritise based on risk

• Support teams with remediation options

Patching, configuration changes, or system replacement fall to:

• Infrastructure teams

• Application support teams

• Cloud or DevOps teams

Strategies

• Patch — ideal where vendor fixes exist

• Mitigate — firewall rules, disabling services, etc.

• Decommission — removing EOL or unused systems

• Risk Accept — for low impact or unresolvable issues (requires proper governance)

Challenges

• Downtime windows or change control

• Legacy systems that can’t be patched

• Teams not owning remediation

• Resource constraints

Successful remediation programs rely on:

• Regular coordination meetings

• Clear ownership

• Escalation paths for blockers

5. Verification

Patching doesn’t equal resolution unless you confirm the outcome.

What Verification Involves

• Re-scanning the asset post-remediation

• Validating that the CVE is no longer detected

• Confirming that mitigation (if used) is still in place

• Capturing the outcome in dashboards or reports

Why It Matters

Verification ensures:

• Work done is measurable

• No false sense of security

• Compliance requirements are met

6. Continuous Improvement

Vulnerability management isn’t static — it’s iterative.

Each cycle is an opportunity to improve:

• Coverage: Are all new assets scanned promptly?

• Responsiveness: Are SLAs being met?

• Prioritisation logic: Is the business risk model accurate?

• Automation: Can steps be streamlined with better tools?

Inputs to Continuous Improvement

• Internal audits

• Post-incident reviews

• Lessons learned from major vulnerabilities (e.g. Log4Shell, ProxyShell)

• Feedback from remediation teams

Mature teams operate in agile cycles, iterating process improvements with every sprint or quarter.

Why It Matters

A repeatable, risk-based vulnerability management process helps organisations:

• Reduce real-world attack surface

• Respond quickly to emerging threats

• Align with security frameworks like NIST CSF, ISO 27001, and CIS Controls

• Support business continuity by preventing avoidable incidents

It’s not enough to scan. Security posture is improved by acting on what’s found — consistently, collaboratively, and with clear ownership.

Microsoft’s June 2025 Patch Tuesday addressed 49 vulnerabilities across a range of products, including Windows, Office, SharePoint, and Microsoft Dynamics.

Out of the 49, 4 are rated Critical, and 2 are currently under active exploitation.

Key Vulnerabilities to Note

1. CVE-2025-2197 – Windows RDP Gateway RCE

• Remote Code Execution via RDP Gateway

• Network exploitable; no user interaction required

• Patched across multiple supported Windows Server builds

• Critical due to prevalence of exposed RDP in enterprise environments

2. CVE-2025-2203 – Windows Kernel Elevation of Privilege

• Exploited in the wild at time of release

• Impacts Windows 10, 11, and Server 2022

• Allows attackers with local access to gain SYSTEM privileges

• Considered high risk for lateral movement and ransomware campaigns

3. CVE-2025-2230 – Microsoft Office Remote Code Execution

• Exploitable through crafted files or email content

• May be triggered via user interaction

• Impacts Office 2019 and Office 365 Desktop apps

Products with Multiple Vulnerabilities

• Microsoft SharePoint Server

  • 5 vulnerabilities addressed

  • Includes privilege escalation and remote code execution

  • Likely targets for attackers looking to move laterally in corporate networks

• Windows DNS Server

  • Multiple denial-of-service and spoofing vulnerabilities

  • Relevant in on-prem environments

What You Should Prioritise

Patch Immediately:

• CVE-2025-2197 (RDP Gateway)

• CVE-2025-2203 (Windows Kernel – active exploitation)

Prioritise if SharePoint or Office is in use:

• CVE-2025-2230 (Office RCE)

• SharePoint Server rollups

Strategic Notes

If your organisation separates backlog from BAU remediation, this month’s Patch Tuesday items should be handled as new, time-sensitive vulnerabilities — especially those on your Critical Vulnerabilities List.

No references to specific vulnerability scanners are needed. Prioritisation should be driven by:

• Exploitability status

• Exposure in your environment

• Business criticality of affected services

Additional Updates

Adobe also released updates for:

• Acrobat Reader

• ColdFusion

• Creative Cloud products

These are not widely exploited at time of writing, but still warrant attention in enterprise environments with creative or document-heavy workloads.

Final Thought

Microsoft’s June 2025 release is notable for the presence of two zero-days and critical vulnerabilities affecting widely deployed components. Ensure these are addressed in line with your normal triage practices for actively exploited threats.

CISA recently added CVE-2024-6382 to the Known Exploited Vulnerabilities (KEV) catalog, marking it as actively exploited in the wild.

Why This Matters

This vulnerability affects Apache Struts, a Java web application framework still present in many legacy systems.

• Exploitation allows remote code execution (RCE)

• No user interaction is required

• Exploits are already circulating publicly

Affected Versions

• Apache Struts 2.5.0 to 2.5.31

• Patched in 2.5.32 (released June 2024)

What You Should Do

1. Upgrade to Struts 2.5.32 or later

2. Review any internal or vendor-hosted applications using Apache Struts

3. Add CVE-2024-6382 to your Critical Vulnerabilities List

4. Confirm visibility via:

   • Vulnerability scanners (e.g., Qualys QID: TBD)

   • External ASM or attack surface tools

Risk Context

• Added to KEV: June 10, 2024

• CVSS Score: 9.8 (Critical)

• Exploitability: Public POCs confirmed

• Campaigns: Targeting sectors with exposed web applications

Strategic Relevance

This CVE checks all the major boxes for prioritisation:

• Appears in the CISA KEV catalog

• Exploitable with real-world consequences

• Often found in legacy or hard-to-reach systems

This is not a candidate for backlog. It should be addressed immediately as part of your active Critical Vulnerabilities List response.

Most vulnerability backlogs aren’t fixed because they’re too big, too scattered, and too low-priority to get executive attention.

The solution? Run focused, time-boxed remediation sprints — targeting backlog clusters by platform, owner, or business risk. This Playbook outlines a repeatable 4-week model to chip away at vulnerability debt while keeping BAU intact.

Why This Matters

Backlogs don’t disappear by adding more dashboards.

You need structure, buy-in, and a realistic time frame. The 4-week sprint model gives teams just enough urgency to focus, without disrupting critical operations.

It also gives leadership the progress trendline they want — even if it’s incremental.

The 4-Week Burndown Sprint Model

Each sprint focuses on a backlog segment — for example:

• All backlog vulnerabilities on Windows servers owned by Platform X

• All EOL software or kernel-level issues on Linux

• All open medium-severity CVEs on externally facing hosts

This prevents the “boil the ocean” problem.

Week 0: Prep

• Define the sprint scope (by platform, team, region, or vuln type)

• Pull a list of in-scope vulnerabilities (>30 days old)

• Get agreement on start/end dates, team contacts, and blockers

• Freeze scope: no new findings are added during the sprint

Week 1: Kickoff

• 30-minute call to review the scope and expectations

• Confirm working contacts for each team

• Assign remediation tasks or risk acceptance actions

• Escalate anything clearly out of scope or unfixable

Week 2–3: Remediate

• Weekly check-ins (15–30 min) to:

  • Review progress

  • Triage unpatched items

  • Raise blockers (e.g. maintenance windows, change freeze)

• Optional: send mid-sprint scorecards to leadership

Week 4: Wrap-Up

• Finalise metrics: total fixed, waived, or postponed

• Update tracking sheet or dashboard

• Share summary with stakeholders

• Celebrate wins — even partial cleanup counts

What Success Looks Like

• 80–100% of scoped vulnerabilities resolved or risk accepted

• No major blockers escalated beyond agreed timeline

• Trendline showing backlog reduction sprint over sprint

• Team confidence in a repeatable process

Tips for First-Time Sprints

• Keep scope small for sprint #1 — platform-specific and achievable

• Use existing change windows to avoid friction

• Track progress in a simple checklist or spreadsheet

• Don’t aim for perfection — just consistent movement

Pitfalls to Avoid

• Sprinting across too many platforms or teams at once

• Letting the scope creep mid-sprint

• No defined sprint lead or coordinator

• Reporting only patch counts, not total impact

Backlog Burndown Sprint – Checklist

• Define the sprint scope (platform, owner, vulnerability type)

• Extract list of backlog vulnerabilities older than 30 days

• Identify team leads or asset owners for in-scope items

• Confirm sprint dates and create a communication plan

• Schedule and run kickoff meeting (Week 1)

• Assign remediation or risk acceptance tasks

• Hold weekly check-in meetings (Week 2–3)

• Escalate or document blockers and issues

• Complete final review and sprint closure (Week 4)

• Capture metrics: resolved, risk accepted, postponed

• Share summary report with stakeholders

• Capture lessons learned and prepare for next sprint

For questions or feedback, connect with me on LinkedIn.

Most organisations have two distinct vulnerability challenges:

1. A stream of new vulnerabilities that need quick triage and action

2. A backlog of old, often low-priority vulnerabilities that never seem to move

Treating them the same way — with one workflow, one SLA, one dashboard — leads to confusion, burnout, and missed risk. This Playbook outlines how to separate them operationally and build tailored processes for both.

Why This Matters

A “vulnerability backlog” isn’t just technical debt — it’s operational risk that’s been deprioritised, ignored, or lost in translation.

At the same time, new vulnerabilities (especially KEV-listed or zero-day ones) demand rapid action with clear ownership.

Without separation, two things happen:

• New vulnerabilities drown in noise

• Old vulnerabilities never get fixed

Organisations need two lanes:

• One for new vulnerabilities, triaged and actioned in real time

• One for backlog burndown, handled in cycles or sprints

Define the Two Tracks

1. New Vulnerabilities (Day 0–30)

These are vulnerabilities discovered:

• In the last 30 days

• Through regular scanning or new CVE feeds

• Often include KEVs, vendor criticals, or internal intel priorities

Primary goal: Fix or risk-accept before they age out

Process focus:

• Triage fast: is it real, relevant, and exploitable?

• Prioritise using business impact and exposure

• Assign and track within SLA

• Report status weekly

This is your real-time operations lane.

2. Backlog (Vulnerability Debt)

These are vulnerabilities:

• Older than 30 days

• Often low/medium severity or historically “too hard to fix”

• Accumulated over months or years

Primary goal: Reduce the overall volume and risk — without disrupting BAU

Process focus:

• Group by common root causes (e.g., old OS versions, missing configs)

• Target based on business service, platform, or team

• Run structured remediation sprints (e.g., 4-week cycles)

• Track reduction trends, not just absolute counts

This is your programmatic cleanup lane.

What Good Looks Like

Common Pitfalls

• Lumping everything into one SLA report – makes teams look like they’re always failing

• Expecting urgent response to old vulnerabilities – sets up unrealistic pressure

• No defined backlog owner – leads to passive accumulation

Your Next Actions

1. Audit your current vulnerability list: Split into “New” and “Backlog” based on age

2. Define separate workflows and reporting views for each

3. Launch a time-boxed backlog sprint (e.g., 4 weeks per platform)

4. Make backlog targets achievable and report on trendlines, not just volume

Coming Soon

Future Playbooks will go deeper into:

• Triage models for new vulnerabilities

• Structuring a 4-week backlog burndown sprint

• Setting up realistic reporting and KPIs

If this helped, subscribe for future Playbooks or connect with me on LinkedIn.