What actually stops a live attack inside a cloud workload: a scanner that flags a misconfiguration, or a sensor watching a process spawn at 3 a.m.? That question shapes the cloud detection and response (CDR) market, where Sweet Security, Upwind, and Lacework now compete for the same security budget. Each promises to catch attackers in the act. Each also has a boundary it cannot cross. Understanding where those boundaries sit matters more in 2027 than any feature list, because buying the wrong shape of protection leaves a gap nobody notices until an incident review. (Cloud identity security tools actually protects access 2026)
Why CDR Became the Center of the Cloud Security Debate
For years, cloud security meant posture management: scan configurations, flag public buckets, rank misconfigurations by severity. That model assumes the attacker is lazy and the environment is static. Neither holds. Runtime attacks move through identity, containers, and APIs in minutes, and a misconfiguration report delivered the next morning is a history lesson, not a defense.
CDR flips the emphasis toward live telemetry. Instead of asking “is this bucket public,” it asks “what is this process doing right now, and does it match what we expect.” The shift is genuine, but it also created a labeling problem. CDR is not a formal standard. No standards body publishes a definition that vendors must meet, so each company draws its own boundary around the term. That is why three products in the same category can protect very different things.
The Three Contenders at a Glance
The table below reflects how each product positioned itself as of early 2025. Treat every cell as subject to change; roadmaps in this market move fast.
| Product | Core approach | Primary protection focus | Typical blind spot |
|---|---|---|---|
| Sweet Security | eBPF-based runtime sensing | Live workload behavior in Kubernetes, containers, VMs | Posture, identity, and Windows-heavy estates |
| Upwind | Runtime-powered CNAPP | Runtime detection combined with posture and vulnerability context | Depth of any single module versus specialists |
| Lacework | Behavioral analytics (Polygraph lineage) | Cloud workload and account behavior anomaly detection | Roadmap certainty after the Fortinet acquisition |
The pattern is clear. Sweet Security is the narrowest and sharpest. Upwind is the broadest. Lacework carries the most history and the most uncertainty.
What Sweet Security Actually Protects
Sweet Security built its name on runtime. Its sensors use eBPF to observe what workloads do, then flag behavior that looks like an attack: a shell spawned inside a container that should never run one, a crypto miner’s CPU pattern, lateral movement between pods. The product is designed for teams that already accept cloud posture tools and want the missing half, the part that sees the attack rather than the weakness. (NIST SP 800-190: Application Container Security Guide)
What it protects well is the Linux workload layer. What it does not try to be is a full platform. If a security leader needs configuration scanning, identity posture, or a single console for compliance evidence, Sweet Security is one piece of that puzzle, not the whole board.
Where Sweet Security’s Limits Begin
The first limit is coverage. eBPF is a Linux kernel technology, which means visibility depends on the kernel being there and the sensor being deployed. Windows nodes, some managed serverless abstractions, and PaaS layers where you cannot install a sensor fall outside the view. The second limit is organizational: runtime-only products often land as a second purchase, which means budget approval depends on someone else’s tool already being in place.
What Upwind Actually Protects
Upwind took the opposite bet: build a runtime-first CNAPP that wraps posture, vulnerability management, and detection into one platform. The pitch is consolidation. A team gets cloud security posture management, runtime sensing, and an attack-path view without stitching three vendors together.
In practice, this protects a broader surface. A misconfigured role and the suspicious API call that exploits it can appear in the same investigation. That context is genuinely valuable, because most real incidents are chains, not single events.
Where Upwind’s Limits Begin
Breadth has a cost. When one platform covers posture, vulnerability, and runtime, each module competes for engineering attention against specialists who do nothing else. Buyers should ask a blunt question: is the runtime detection as deep as a dedicated tool, or deep enough to check a box? The honest answer varies by module and by quarter, which is exactly why proof-of-concept testing beats slide decks.
The second limit is the same kernel dependency that affects every eBPF-based product. Runtime-first does not mean runtime-everywhere. An estate heavy on Windows or managed platform services needs a coverage map before signing, not after.
What Lacework Actually Protects
Lacework earned its reputation on behavioral analytics. Its Polygraph engine learned what normal looked like across workloads and accounts, then flagged deviations. That approach protects against the attacker who uses valid credentials and quiet commands, the kind of intrusion signature-based tools miss entirely.
The complication is ownership. In June 2024, Fortinet announced an agreement to acquire Lacework, and the deal closed later that year. For existing customers, the technology still works. For anyone planning 2027, the question is integration: how much of Lacework’s detection logic ends up inside a broader platform, and what happens to standalone positioning. That is uncertainty, not failure, but security leaders should plan for it explicitly rather than assume continuity.
Where Lacework’s Limits Begin
Beyond roadmap risk, the classic behavioral-model limits apply. Anomaly detection needs a learning period, which means a newly onboarded environment is least protected exactly when it is newest and least understood. Behavior models also generate tuning work; a noisy baseline produces alert fatigue, and alert fatigue produces ignored alerts.
The Shared Blind Spot Nobody Markets
All three products lean on runtime telemetry, and all three therefore inherit the same structural gap: the control plane and the identity layer. An attacker who never touches a workload, who instead manipulates cloud APIs, assumes roles, or abuses federation, may generate little runtime signal at all. This is where the boundaries of the category itself begin, and it connects directly to the cloud identity security challenges that drive a large share of modern breaches. Runtime sensing watches the house; identity abuse walks in through the front door with a key.
Supply chain risk compounds the problem. A compromised dependency executes inside a workload the sensor trusts, and the first signal may be legitimate-looking behavior. Teams that treat CDR as complete coverage tend to underinvest in the upstream controls that prevent the payload from arriving, which is why supply chain security deserves its own budget line rather than a footnote in the runtime project.
How to Test These Products Before You Buy
Vendors publish comparisons, and those comparisons are marketing, not evidence. The practical approach is a structured proof of concept with pass or fail criteria agreed in advance:
- Map every workload type in your estate, including Windows, serverless, and managed services, and mark which ones a sensor can actually reach.
- Deploy each candidate in the same namespace and run the same three simulated attacks: a reverse shell, a crypto miner, and credential access from a compromised pod.
- Measure time to detection, quality of context, and how many clicks it takes to isolate the workload.
- Count false positives over a full week of normal traffic, not a demo hour.
- Ask each vendor to walk through what happens when the sensor cannot be installed, and write the answer down.
That fifth step is where most evaluations quietly fail. Coverage gaps are rarely announced; they are discovered during an incident.
Where the Category’s Limits Really Begin in 2027
The honest 2027 picture is that CDR tools are excellent at one thing and mediocre at everything adjacent. They see runtime behavior in Linux workloads with real depth. They struggle at the edges: the identity layer, the control plane, the platforms you do not own, and the supply chain feeding all of it.
This is not a reason to skip CDR. It is a reason to scope it correctly. A runtime tool that covers 70 percent of your estate is valuable if you know which 70 percent, and dangerous if you assume it covers everything. The same logic applies to adjacent controls. Network segmentation limitations show up precisely where teams assume east-west traffic is contained, and DNS-layer protection only pays off in specific scenarios rather than universally.
Consolidation adds a second-order risk. As platforms absorb point tools, the surviving products get broader and the integration gets deeper, but the roadmap belongs to the acquirer. Buyers should ask what happens to their detection content if a product line is folded into a larger suite, and get an answer that covers data portability as well as feature continuity.
A Practical Buying Framework
Match the tool to the gap rather than to the category label:
- If runtime blind spots are the problem and posture is already covered, a focused runtime product is the cleanest fit.
- If the estate is fragmented across too many consoles and the team is small, a consolidated runtime-powered platform reduces operational load.
- If behavioral anomaly detection on cloud accounts is the priority, evaluate the incumbent carefully and price in roadmap uncertainty.
For every option, verify three things in writing: sensor coverage by workload type, detection content ownership and portability, and the specific response actions available without human approval. Those three answers separate a real CDR deployment from a dashboard.
Conclusion
Sweet Security, Upwind, and Lacework all protect something real, and none of them protects everything. Sweet Security sees runtime behavior in Linux workloads with focus. Upwind wraps runtime inside a broader platform and trades some depth for context. Lacework brings behavioral analytics and a genuine question mark about its post-acquisition future. The limits begin at the same place for all three: the identity layer, the control plane, the platforms without sensors, and the supply chain feeding the workload. In 2027, the winning move is not picking the vendor with the longest feature list. It is mapping your estate honestly, testing coverage rather than assuming it, and buying the shape of protection that matches the gap you actually have.
Frequently Asked Questions
What is cloud detection and response in simple terms?
Cloud detection and response is a category of security tooling that watches live activity inside cloud environments, such as processes, network connections, and API calls, and flags or blocks behavior that looks like an attack. Unlike posture scanning, which reviews configuration, CDR focuses on what is happening right now.
Is CDR a formal industry standard?
No. There is no standards-body definition that vendors must meet, so each company defines the scope differently. Some limit CDR to workload runtime behavior, others include cloud control-plane activity and identity signals. Buyers should ask each vendor exactly what telemetry feeds its detections.
Which of the three is best for Kubernetes environments?
All three can monitor Kubernetes, but Sweet Security and Upwind both build on eBPF-based runtime sensing, which suits containerized Linux workloads. The right choice depends on whether you need runtime only or runtime plus posture and vulnerability context in one console.
What happens to Lacework customers after the Fortinet acquisition?
The technology continues to operate, and Fortinet has publicly framed the acquisition as a strengthening of its cloud security portfolio. What remains genuinely uncertain is how much standalone positioning Lacework retains by 2027. Customers should ask about data portability and detection content continuity rather than assume the roadmap stays fixed.
Do these tools cover Windows workloads and serverless functions?
Coverage varies and is often partial. eBPF sensing depends on the Linux kernel, so Windows nodes and some managed serverless and PaaS layers may not support a sensor at all. Always confirm coverage per workload type during a proof of concept rather than relying on general claims.
How long should a proof of concept run?
At least two weeks. Anomaly-based detection needs time to learn a normal baseline, and false positive rates measured over a demo hour are meaningless. Run real traffic, simulate three or four attacks, and document what the tool could not see as carefully as what it caught.
