




















Security findings are often siloed: SAST for code, CNAPP for infrastructure and workloads. Teams spend extra effort piecing those signals together before they can act on what matters most. We use “AI-powered echolocation” to describe how static vulnerabilities can be projected into their real-world cloud context, where findings echo against live assets, exposure, and behavior. Just as a whale pieces together echoes to map its surroundings, security teams can connect signals from Snyk and Sysdig to shift from long vulnerability lists to prioritized, real risks and threats.
Artificial Intelligence (AI) and Model Context Protocol (MCP) make it possible. Modern LLMs can quickly handle semantic problems with complex data that humans used to spend hours on, cutting down tedious work so analysts can focus on what matters. MCP servers connect these LLMs to APIs and data sources, enabling them to process information across different domains and uncover correlations that previously were difficult to reveal.

The defender’s dilemma is inescapable: security teams must protect everything continuously, while attackers only need to exploit a single weakness to succeed. This asymmetry forces defenders to stay several steps ahead of any attacker.
Static scanners do a fine job of listing every vulnerability in code or dependencies. However, they still require teams to invest time debating theoretical risks instead of focusing on what’s critical, live, and exposed.
Cloud Workload Protection Platforms take a different approach, capturing context from workload configurations and real-time behavior. This approach tracks the ever-changing puzzle of ephemeral services and environments, such as containers that can live for less than a minute, sensitive storage buckets, or microservices exposed to the internet.
Both approaches can become overwhelming at scale.
If a security team has to protect a building, grabbing the building’s blueprints on a table and pinpointing the weaknesses is a great way to start realizing what they need to resolve. But, a blueprint only tells part of the story—and it’s static. In this scenario, the team tasked with protecting a building also needs to know what’s happening in real time. The same concept applies to cybersecurity teams, and the purpose of our proposal is to bring them more tools: a lidar, electronic sensors, and security cameras on every single floor, room, and stairs. Now they have broader and deeper coverage, offering new perspectives that can change everything.
The proposal is equal parts simple and powerful. In addition to our classic vulnerability management approach, let’s use a modern LLM to read the static vulnerabilities found in the source code (building’s blueprint), analyze them with pictures of the actual infrastructure configuration (LIDAR), considering both historical behavior logs and real-time views of what is happening right now (sensors, security cameras).
The MCP protocol is an open standard, so it can be used with almost any Large Language Model. In our example, we will be using Anthropic’s Claude Sonnet 4.5. Before getting started, ensure that both the Snyk and Sysdig MCP servers are properly configured.

For this particular use case, we will disable Sysdig’s MCP built-in vulnerability and image scanning features. Instead, Sysdig will focus on providing runtime risks and security events, while Snyk will remain the single source of truth for developer-owned code and vulnerabilities.
Note that each MCP server operates at a different scope. The Snyk MCP server interacts with local project data, while the Sysdig MCP server interfaces with the Sysdig backend to provide information that is continuously gathered from live environments.
Let’s step into the shoes of a security engineer who wants to proactively perform threat modeling using prompts. Setting a clear context for what we want to achieve is always a good starting point.
Please keep in mind that these prompts are meant to inspire your thinking, the real value lies in asking your own questions. The examples below are simply starting points and not fully optimized.
You are a cloud security specialist conducting a multi-step investigation.Record only verified data and exact values, no assumptions.Do not create or guess container names or other identifiers.Save all findings for the final report, provide no explanations or conclusions during analysis.Maintain precision, consistency, and factual accuracy throughout.
Ask Claude to use Snyk SAST scanner to identify the most relevant vulnerabilities. Also ask it to use the Snyk IaC tool to find out the name of the container that this code generates (it will be useful to correlate objects with Sysdig with no margin for error).
Use the Snyk SAST MCP tool to analyze the project "/Users/manuel.boira/Sysdig/snyk/security-playground/security-playground/" and determine if there are critical vulnerabilities with risk of exploitation, save SAST results as 'snyk-vulnerability-list'.Use the Snyk IaC MCP tool to scan the project, additionally obtain the resulting container name from the path, and save the value as container-name.
Now ask Claude to use some Sysdig tools to take the X-Ray shot:
Use the Sysdig SySQL MCP tool to check if any running kubernetes workload matches the container-name and save the result as 'sysdig-container-context'.Retrieve the risk factors of the kubernetes workload using Sysdig SySQL: Workload exposed, failing high-severity controls. Save the results as 'sysdig-risk'.Retrieve runtime events from the last 15 days filtered by the workload name equal to container-name and limiting results to 500, perform only one search, and save the result as 'sysdig-runtime-events'.

Let Claude do the job: overlay vulnerabilities with deployment risks, exposure, and runtime behavior. At this stage, our prompts are designed to interpret the semantics of the vulnerability description and attack vector.
Correlate the 'snyk-vulnerability-list' with 'sysdig-container-context' and 'sysdig-risk' to proactively explore how the vulnerabilities and their attack paths reported from Snyk could be exploited in the actual configuration and risks pointed by Sysdig. The key is to combine both to model threats in detail, going ahead of any future attacker. Highlight how Sysdig findings increase or decrease the likelihood of exploitation for each vulnerability, and provide clear reasoning. Also determine if any of these vulnerabilities show signs of actual exploitation by contrasting sysdig-runtime-events with the snyk-vulnerability-list.
Generate clear and understandable reports that help security teams prioritize, mitigate, and remediate risks and threats effectively. And, given that we are working with MCP servers, let’s use a Jira MCP server to create a beautiful and actionable ticket, ready to start with the resolution stage.
Deliver a one-page, concise, visual, and actionable PDF with three clearly labeled sections: Projected Threat Modeling, Exploitation Evidence, and Remediation.Deliver a graphical representation of attack paths possible considering Snyk and Sysdig findings.Create two Jira tickets: Ticket 1 (security-playground-tag): Describe what must be fixed to reduce the identified risks. Ticket 2 (security-playground): Request response, mitigation, fixes, and redeployment
Here are some sample reports generated with a sandbox environment.





Why stop here? The security specialist or incident responder can use the LLM too, pulling insights from Sysdig in real time, mitigating the risks or resolving them permanently.
Load the Jira ticket PRO-1234. Use Sysdig to check the actual status of these cloud assets as well as the latest security events.
Snyk Agent Fix can fix code vulnerabilities through automatic flows.
We have shown that static and dynamic information work best when combined. Let’s pause for a moment to take stock of what we have gained:
With the latest LLMs and MCP servers, it’s now possible to tackle new use cases directly and unlock value that was previously out of reach or required complex integrations. Static scans, runtime signals, and modern AI no longer compete with each other; they work best together. When these pieces are combined, security teams can move beyond chasing endless vulnerability lists and instead focus on what truly matters: understanding, prioritizing, and mitigating real risks in context.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。