Microsoft Defender for Cloud Natively Integrates with Endor Labs
Integrate Microsoft Defender for Cloud with Endor Labs for reachability analysis and attack path visibility — available natively within the Defender for Cloud console. Prioritize what to fix without switching tools.
Integrate Microsoft Defender for Cloud with Endor Labs for reachability analysis and attack path visibility — available natively within the Defender for Cloud console. Prioritize what to fix without switching tools.
Integrate Microsoft Defender for Cloud with Endor Labs for reachability analysis and attack path visibility — available natively within the Defender for Cloud console. Prioritize what to fix without switching tools.
Integrate Microsoft Defender for Cloud with Endor Labs for reachability analysis and attack path visibility — available natively within the Defender for Cloud console. Prioritize what to fix without switching tools.
Integrate Microsoft Defender for Cloud with Endor Labs for reachability analysis and attack path visibility — available natively within the Defender for Cloud console. Prioritize what to fix without switching tools.
.png)
Effective vulnerability management requires a unified approach that breaks down the silos between application security (AppSec) and cloud security (CloudSec) teams. By combining their expertise and tooling, these teams can gain a complete picture of application risk, enabling them to proactively address vulnerabilities and strengthen their organization's security posture. A holistic view of application risk, encompassing both code and its runtime environment, is crucial for prioritizing remediation efforts and strengthening security posture.
To achieve this, Endor Labs and Microsoft are joining forces. Today we announced Microsoft Defender for Cloud developed a native integration with Endor Labs, providing customers a reachability-based SCA experience and code-to-runtime reachability. This best-of-breed integration fosters a unified approach to vulnerability management, enabling AppSec and CloudSec teams to work together seamlessly to identify, prioritize, and remediate vulnerabilities across the entire software development lifecycle (SDLC).
“Our collaboration with Endor Labs makes Defender for Cloud the first CNAPP to provide true code-to-runtime reachability,”
-Vlad Korsunsky, Corporate Vice President, Cloud & Enterprise Security at Microsoft
How the AppSec/CloudSec divide hurts efficiency
The divide between AppSec and CloudSec stems from their distinct focuses and skillsets. AppSec teams concentrate on securing the code and applications within the development lifecycle, emphasizing secure coding practices, vulnerability assessments, and dependency management. CloudSec teams, on the other hand, focus on securing the cloud infrastructure and runtime environment, prioritizing configuration management, access control, threat detection and response. Despite these different focuses, their responsibilities overlap significantly when it comes to vulnerability management. Both teams are involved in identifying and prioritizing vulnerabilities, determining remediation strategies, and responding to security incidents. But in most organizations, these functions are owned by different people, and often completely different teams. There are three common barriers to effective vulnerability management across the teams.
Barrier 1: Communication and collaboration
Effective vulnerability management requires a unified front, but often, application security (AppSec) and cloud security (CloudSec) practitioners operate in silos, hindered by communication gaps and conflicting priorities. This lack of collaboration creates the first barrier to efficient vulnerability management. Teams may struggle to agree on the severity of vulnerabilities, ownership for remediation, and the appropriate balance between rapid development and security hardening. This is further complicated when AppSec and CloudSec have separate budgets, leading to arguments over who should pay for shared tools and resources. Neither team is incentivized to invest in solutions that primarily benefit the other, even if it improves overall security. This disconnect can lead to delays in patching critical vulnerabilities and an overall weaker security posture.
Barrier 2: Tools and processes
The second barrier arises from the use of disparate tools and processes. AppSec teams typically rely on code scanning tools (like SCA), which flags open source vulnerabilities in code repositories. Later, CloudSec teams utilize their own cloud-specific security solutions (like CNAPP) that might flag the same vulnerabilities again, but this time in a running container. Because these tools aren't talking to each other, and with teams potentially unaware of each other's findings, everyone wastes time: developers get multiple alerts for the same issue, different teams scramble to triage the same vulnerability at different points in the SDLC, and remediation efforts get duplicated. This fragmented approach, exacerbated by separate budgets and a lack of incentive to adopt tools that help the "other" team, creates inconsistencies, extra work, and potential blind spots. Without a unified platform and shared visibility into vulnerabilities, organizations are left with a patchwork security approach that is less effective than a cohesive strategy.
Barrier 3: Poor visibility
Organizations need a comprehensive view of security that spans the entire software development lifecycle and extends into the runtime cloud environment. However, this "attack path" visibility is often elusive. Why? Because it requires connecting the dots between disparate sources of information: vulnerability scanners, code repositories, cloud configurations, network traffic, and more. These data points are often siloed across different teams and tools, making it difficult to assemble a complete picture of how a vulnerability could be exploited in a running application. For example, a vulnerability flagged as low priority by AppSec during development could become a critical security hole if the affected component is publicly exposed due to a cloud misconfiguration. Without this integrated perspective, it's difficult to prioritize remediation efforts, decide where to deploy mitigating controls, and allocate resources effectively. This lack of a unified understanding of application risk hinders both AppSec and CloudSec teams from achieving their shared goal of robust security.
Endor Labs with Defender for Cloud
Integrating Endor Labs with Defender for Cloud empowers AppSec and CloudSec to efficiently address vulnerabilities. AppSec gains deeper context for prioritizing remediation, developing targeted fixes, and collaborating with CloudSec on shared ownership of application security. CloudSec benefits from increased visibility into attack paths, enabling proactive implementation of security controls and more effective threat response. This collaboration breaks down silos, strengthens security monitoring, and reduces organizational risk.
A special shoutout goes to the brilliant team representing both companies who are the backbone of this announcement. To Lara Goldstein, Mona Thaker, Tzach Kaufmann, Andrew Davidson, Pawan Shankar and Tom Gleason: Your relentless dedication and expertise have made this effort a reality. Thank you for your hard work and commitment!
Step 1: Prioritize findings by exploitability based on function-level reachability
This integration brings function-level reachability analysis directly into the Defender for Cloud console, allowing teams to finally answer the crucial question: "Which vulnerabilities pose an actual threat in our environment?" Although research shows that only 9.5% of vulnerabilities are exploitable within a given application context, many teams lack the means to pinpoint these critical flaws. This forces them to choose between time-consuming manual research and a "fix everything" approach, neither of which is sustainable or efficient. With vulnerability findings often numbering in the hundreds or thousands, this integration provides a crucial capability.
Step 2: Prioritize remediation based on code-to-runtime exploitability
Let's say Endor Labs found an exploitable vulnerability in one of your OSS libraries. Depending on how that library interacts with your code, you might be able to simply upgrade and move on. But sometimes upgrades are complex, taking months or even years. Your team will want to know about the exploitable path so they can determine urgency and whether mitigating controls should be implemented. But how do you figure out the attack path?
Well, like so many things in tech, it depends...
—Without a CNAPP—
Welcome to your nightmare of chasing down owning teams and asking them to go find instances. You're probably better off pushing through the upgrade as fast as possible or crossing your fingers.
—With a CNAPP—
This still isn't ideal, but it's better! You'll work with the CloudSec team to find lists of deployed environments. What this looks like varies because it depends how they use/work with the CNAPP. So, easier said than done.
—With Endor Labs and Defender for Cloud—
Welcome to the future! With reachability analysis embedded in Defender, you can automatically generate an attack path connecting reachable findings generated by Endor Labs to corresponding container images, containers, Kubernetes pods, and more. If the affected library is actively running in the cloud, CloudSec can implement a mitigation to prevent a worst case scenario while you work with engineering to get the library upgraded.
The AppSec and CloudSec owners at an enterprise customer told us:
“Endor Labs’s reachability analysis helps reduce cognitive load for developers because they trust we’re only asking them to remediate exploitable vulnerabilities. With the addition of Defender for Cloud’s attack paths, we can demonstrate how the vulnerability can actually be exploited in our environment. Together, these capabilities build our credibility, and most importantly, help the organization reduce risk.”
Continuous monitoring without CI scans: Agentless SCA for Azure Repos
Azure Repos users can achieve even faster time to value through the Endor Labs Azure Repos app, which automatically identifies security vulnerabilities in your repositories without having to extensively engage development teams. Setup only requires a personal access token (PAT) for quick configuration.
Our customers using Azure can now achieve reachability analysis within Azure Repos with an agentless approach, helping organizations scan effortlessly without per-pipeline configuration. Automated daily scans keep you aware of risks, and developers are automatically alerted to new security risks that violate policy as they introduce changes, so you can avoid preventable risk in production.
This experience is also available to GitHub shops.
Get started
The integration of Defender for Cloud and Endor Labs marks a significant step forward in application and cloud security, ushering in a new era of unified vulnerability management. Today, the integration is in Public Preview. We will continue to add new use cases as the integration matures — let us know what’s important to you!
To get started with Endor Labs and Defender for Cloud, visit our documentation for step-by-step details. If you’re already a customer of both products, this process takes just minutes!
Book a 20-minute demo to learn how Endor Labs can help you manage security risks more effectively or start a free, full featured 30-day trial that includes test projects and the ability to scan your own projects.
