SEC595: Applied Data Science and AI/Machine Learning for Cybersecurity Professionals


Experience SANS training through course previews.
Learn MoreLet us help.
Contact usBecome a member for instant access to our free resources.
Sign UpWe're here to help.
Contact Us
I’ve spent 27 years in the cybersecurity industry. I’ve worked with organizations of every size and taught security practitioners from every corner of the world, and I have never once met a team that looked me in the eye and said, “Vulnerability management? We’ve got that completely handled.” Not once. And if you’re honest with yourself, you know why.
At SANS Secure Your Fortress 2026, I made the case that we are at an inflection point. The traditional model of scanning everything, sorting by CVSS score, and patching what you can before the next scan cycle is not going to hold. The math doesn’t work anymore. But AI gives us a real path out, if we’re willing to use it.
Here’s the landscape we’re working in: CVE publications have grown by 263% between 2020 and 2025, and that growth is continuing to accelerate. That comes to around thirty thousand CVEs a year.
NIST also recently announced that they can no longer enrich most CVE publications. Not because they don’t want to, but because they don’t have the time or budget. Going forward, they’re focusing enrichment resources almost entirely on the KEV database, the Known Exploited Vulnerabilities list. That’s good for the most critical stuff, but it means the onus is on us to figure out the rest.
We’re all now in the position of having to independently analyze thousands of vulnerability findings, sometimes millions, and not all of them are going to be exploited. So where do you focus? How do you get more time actually fixing things instead of spending all of your time triaging? This question got me thinking seriously about how to implement AI in this space.
Too much noise, remediation that's too slow, and a translation gap between security teams and developers. These aren't new problems. I've been watching organizations struggle with the same patterns for 27 years.
I describe vulnerability management as a treadmill of pain. You can't get off it. You just run and run and the belt keeps on moving. I don't think we'll ever fully step off it. But AI can change the speed at which we move.
The model we're moving toward is exposure management. Not just "is this vulnerable?" but "what can an attacker do from here if they exploit this?"
Adam Shostack, the godfather of threat modeling, taught me a framework I keep coming back to: who can get to what from where? That simple question, applied to every vulnerability in your environment, is how you get to real prioritization. Is this asset internet-facing? Who can reach it? What does the attacker gain if they own it?
AI is exceptionally good at reasoning over that kind of contextual data at scale. That's where it starts to matter for this problem.
This is the one anyone can start doing today, with no new budget and no new tools. The prompt matters more than most people realize. Don't just paste in a list of CVEs and ask what's bad. Give it context: ask it to identify the top five risks to prioritize for remediation, and tell it to factor in exploitability, whether the asset is internet-facing, whether sensitive data is involved, and whether there's active exploitation in the wild. Then ask it to explain its reasoning. That last part is important. You want to see the logic, not just the answer.
I demonstrated this live during my talk with a deliberately mixed set of 20 CVEs: Log4Shell, Citrix Bleed, MOVEit, exposed RDP, open S3 buckets with PII, publicly accessible Kubernetes dashboards, and more. In about 15 seconds, ChatGPT came back with a ranked prioritization. Log4Shell on an internet-facing Java server at the top — correct. But what impressed me more were the runners-up. It flagged an SMB signing issue not because of its standalone score, but because of what it enables in combination with other findings: SMB relay attacks, lateral movement, and credential poisoning. That kind of compound reasoning is exactly what static CVSS scoring misses, and it's exactly what takes your senior analysts the longest to work through manually.
Twenty vulnerabilities, your team can probably handle on their own. But what about a thousand? What about the organizations I work with that are staring down tens of thousands of findings with no clear signal on where to start? That's where AI assistance starts to multiply your capacity in ways that matter.
That said, treat the output as a starting point, not a verdict. I’ve seen AI confidently prioritize something that didn’t hold up once we factored in context it didn’t have, like which asset was actually Internet-facing, or which finding was already mitigated. The reasoning it shows you is as important as the ranking. Read it. Challenge it. That’s the gut check.
I’ve put together a copy-paste prompt kit for all four use cases covered in this post. Download it here.
I give board presentations regularly. I also spend a lot of time with developers, and I can tell you from experience: neither group wants nerd speak. The board wants to know what the risk is and what you're doing about it. Developers want to know exactly what to fix and how. Security teams are often not good at either translation, not because they lack knowledge, but because it takes time they don't have.
Here's the approach I used in my talk: take a specific CVE and ask AI to explain it in plain English with actionable remediation steps for a particular audience. I used CVE-2025-1974, a critical Kubernetes vulnerability, and asked it to break it down for a DevOps team running Kubernetes workloads. In under 10 seconds it produced a plain-English explanation of the risk, why it matters for containers and namespaces, what to treat as urgent, and a step-by-step remediation guide including patching, cluster config checks, image scanning with tools like Trivy or Wiz, and pod security lockdown guidance.
That output is something you can hand directly to a dev team. No translation required on your end. You're not replacing your security engineering judgment. You're eliminating the hours it used to take to make that judgment useful to someone else.
The most useful thing AI can do with a vulnerability scan isn't to tell you what's bad. It's to tell you what's bad in combination with everything else, and where an attacker goes from there.
I ran a Nessus scan against a Linux test system we use in the SEC501 lab environment and uploaded the report directly into ChatGPT. I asked it two things: how exploitable are these vulnerabilities, and if an attacker compromises this internet-facing web server, what are the potential attack paths? The response called out a stack-based buffer overflow with remote code execution potential as a one-shot compromise, weaponized in exploit kits, old version, high urgency. But then it did something more interesting. It flagged the SMB signing issue as moderate on its own, but noted that in combination with other findings, it's an open door to SMB relay attacks and lateral movement. That's not an initial entry point, it said, but you should know where it leads.
That kind of contextual reasoning is what your senior analysts do when they're at their best, and it's what gets skipped when they're buried. AI doesn't replace that judgment. It gives you a gut check so you can spend your time validating and acting rather than starting from scratch.
One important note: be deliberate about what you upload. Sensitive scan reports with real asset information belong in an enterprise or isolated version of these tools, not in a public-facing interface.
Here's the scenario I keep running into with cloud teams: a critical patch drops, there are hundreds or thousands of workloads potentially affected, and everyone looks at each other trying to figure out where to start. Patching at cloud scale isn't "apply and reboot." There's dependency mapping, rollback strategy, patching wave sequencing, decisions about immutable infrastructure versus traditional VMs, EC2 Image Builder, CI/CD pipeline integration — it's a real engineering problem, not just an ops task.
I asked ChatGPT to produce a remediation playbook for exactly this scenario: multiple critical patches in a cloud-scale AWS environment. What came back in about 10 seconds included patching wave strategy, a decision matrix for immutable versus traditional workloads, pre-patching prep steps, backup and rollback readiness guidance, and execution options across apt, yum, and EC2 Image Builder. Tools mentioned included Jenkins, Terraform, and EDR platforms.
Is it a finished runbook? No. But it's a credible starting point that you can take into a one-hour session with your cloud engineering team and actually make decisions from. What it changes is the dynamic of that conversation. Instead of starting from a blank whiteboard, you're reacting, refining, and pressure testing something concrete. That's a fundamentally different and more productive place to begin.
What AI is going to do is enrich your analysis, help you prioritize better, surface attack path reasoning you might miss under time pressure, and generate automation guidance that would otherwise take hours. Think of it as a second opinion at machine speed.
But here's the thing, and this is important: the AI doesn't know your environment. It doesn't know which systems are truly critical to your operations, which misconfigurations are accepted risks, which teams have the capacity to act on what. That context lives in your head and in your team's heads. The better you can formalize and feed that context to AI, the more accurately it can help you.
The hallucination and accuracy problems of earlier AI systems are improving, but they're not gone. Validate before you act. Don't let AI make final decisions on your behalf. Speed is only valuable if you're moving in the right direction.
Attackers are already using AI to find vulnerabilities and develop exploits faster. That timeline from disclosure to active exploitation in the wild is going to keep shrinking. We have to match that speed, and AI-assisted triage and prioritization is one of the clearest ways to do it.
Here's where things actually stand right now. Some of what I've covered in this post is ready to use today, with no new tools and no new budget. Other pieces are still taking shape, and I think it's worth being clear about the difference so you know where to put your energy.
AI-assisted triage, CVE translation, scan report analysis, and remediation playbook generation are all ready to use today with tools you already have.
A lot of organizations are just starting to explore where autonomous prioritization engines fit. I think we'll get to a point where AI-driven systems can flag the top priorities without anyone's opinion biasing the output. Not mine, not yours, and not the CISO's. That autonomous prioritization, not autonomous fixing, is where we're headed. And integration into CI/CD pipelines for continuous vulnerability detection is going to become standard.
The future of vulnerability management isn't about finding more vulnerabilities, it's about the fixes. That's the whole job, and AI is a tool that finally gives us a real shot at getting there.
These are concrete actions you can take this week. For the first three, I’ve put together a copy-paste prompt kit with ready-to-use templates for each use case. Download the AI Prompt Kit here.
None of this requires a new budget line or a new vendor evaluation: You can start with the tools you already have.
I co-author and teach SEC501: Advanced Security Essentials — Enterprise Defender. It’s built around the philosophy that we’re all working with limited information: how do you make the best decisions as fast as possible without making things worse? Vulnerability management is a core part of what we cover, including how to bring AI into that workflow effectively.
Watch the full presentation here from SANS Secure Your Fortress 2026.


Dave Shackleford, founder of Voodoo Security, has advanced cybersecurity through his leadership roles, including serving as CTO for the Center for Internet Security, where he coordinated the first published virtualization security benchmarks.
Read more about Dave Shackleford