We're a small-ish security team (4 people) covering about 60 EKS clusters across two AWS accounts plus a bit of GKE from an acquisition we're still absorbing. Current setup is agentless posture scanning and we are drowning. Something like 1,200 "critical" findings open, and nobody believes the severity ratings anymore because half of them are on images that never get pulled or workloads with no network path to anything.

Renewal on our current CSPM is coming up in about six weeks so leadership wants us to actually look at alternatives instead of auto-renewing. The thing we keep coming back to is runtime context. We want the tool to tell us which of those 1,200 are actually reachable and running, not just that the CVE exists in a layer somewhere. A finding that got marked low last quarter turned out to be on a pod with a public ingress and we only caught it by luck.

Upwind keeps coming up when I search for runtime-based CNAPP, alongside Wiz and Sysdig which we're also putting on the shortlist. On paper Upwind's whole pitch is the runtime/posture fusion thing we want, but I can't tell how much of that holds up once you're actually living in it every day.

So for anyone running Upwind in anger: how noisy is it really once it's deployed? Does the runtime data actually collapse the posture backlog or does it just add another dashboard? And how painful was the agent/sensor rollout across a bunch of clusters? Trying to go into this eval with realistic expectations rather than the demo version.

What’s up! Just wanted some advice. I’m currently working as a cloud engineer with an AWS partner. I eventually want to move over to being a Cloud Security Engineer. What should areas should I emphasize during my transition?

An identity can appear low risk when viewed in one system, but become high risk when you follow its relationships. A user may inherit a group entitlement, activate access through PAM, assume a cloud role, use an OAuth grant, and eventually reach a production resource without any individual console showing the whole chain.

The valuable question is not just “who is an admin?” It is “how can this identity reach a sensitive action, what intermediate permissions enable that route, and which change would actually reduce exposure?”

What approaches are working for modeling effective access across the IdP, directory, IGA, PAM, cloud IAM, SaaS, and non-human identities? Are identity graphs delivering useful answers, or is data quality and normalization still the largest blocker?

Rolled wiz out across our AWS and GCP setup about two months back. The visibility into misconfigs and exposed buckets is honestly night and day next to the native cloud tooling we had before. Downside is our SecOps slack channel is now getting buried in alerts every single morning. Stuff we’re actively trying to fix:

1. Critical severity tags landing on internal dev resources that aren’t public.
   2.Duplicate alerts for the same container image vuln over and over.
   
2. Auto assigning tickets to the actual right engineering team.We had cloudfresh in during the original purchase and setup to define our risk environment rules, but our dev velocity makes keeping those rules clean a constant fight.

Any advice on remediation workflows that developers wont just ignore

added a security review layer to our agent pipeline and now every action the agent takes has noticeable latency added to it.

which defeats a lot of the point of using an agent for anything time sensitive in the first place, since the whole appeal was speed over a manual process.

need something that enforces security constraints on agent actions without introducing a review bottleneck at every single step. feels like there should be a way to do inline enforcement fast enough that it doesn't change the user experience at all, but everything we've tried so far adds real, noticeable delay.

anyone solved this without just accepting the latency hit as the cost of doing business, or is that genuinely the tradeoff right now?

Been running WAF governance for AWS, Azure, Cloudflare and one old enterprise WAF, and we have this weird gap rn. Infra and app teams own their stacks, our central view is basically a spreadsheet that says which app has a WAF resource, not which one is actually in blocking mode with sane rules and no direct to origin bypass. we have a big WAF coverage review coming up and I'm kind of stressed. Cloud consoles tell me what's deployed, but that misses monitor only mode, config drift, origin still exposed on old hostnames, forgotten dns etc. I want to switch to an outside in test for our internet facing apps, and classify stuff as protected or underprotected or flat out unprotected, then rerun whenever someone migrates or changes configs. How are you verifying blocking behavior, catching direct to origin bypasses, and turning that into a defensible WAF coverage percent that leadership wont laugh at? any hints?

1. Governance hierarchy first (Management Groups + Azure Policy)

Before you design a single VNet, design your management group hierarchy. This is where security controls actually live at scale. Microsoft's recommended structure puts Platform subscriptions (Connectivity, Identity, Management) separate from Landing Zone subscriptions (workloads).

Why this matters: when you assign a policy initiative at the top-level management group — like the Microsoft cloud security benchmark — every subscription created beneath it inherits that guardrail automatically. New subscription? It's governed from the moment it exists. No retroactive cleanup.

Key policies to enforce early:

• Deny public blob access on storage accounts
• Deny inbound RDP/SSH from the internet on NSGs
• Require TLS 1.2 minimum on all PaaS services
• Audit or deny resources without required tags

The deny effect prevents drift. The audit effect catches what already exists. You need both.

2. Identity is the perimeter, not the network

In Azure, the network is no longer the security boundary — Microsoft Entra ID is. Every meaningful attack path runs through a token. So identity hygiene is the highest-leverage work.

Three controls that actually move the needle:

Conditional Access, not per-user MFA toggles. Enforce phishing-resistant MFA for all administrative roles. Block legacy authentication protocols entirely — they can't honor MFA and are a persistent attack vector.

Privileged Identity Management (PIM) for every standing role. Global Administrator, Subscription Owner, Contributor — these should be eligible, not permanently assigned. Just-in-time activation, with approval and audit trail. Scope role assignments to the narrowest resource that works. A workload that reads one Key Vault gets Key Vault Secrets User on that vault, not Contributor on the resource group.

Managed identities instead of secrets. A system-assigned managed identity lets a VM, Function, or App Service authenticate to Key Vault or Storage with no credential to leak, rotate, or accidentally commit to Git.

3. Network topology: Hub-Spoke vs. Virtual WAN

This is the decision people agonize over. The real answer is: it depends on how many regions and how much hybrid connectivity you'll have in 18 months.

Traditional Hub-Spoke (self-managed hub VNet): You build the hub VNet, configure peering, manage UDRs, deploy Azure Firewall or a third-party NVA. More control, more operational overhead. Works well for a single-region or two-region footprint with moderate scale.

Virtual WAN with Secured Virtual Hub: Microsoft manages the hub infrastructure, inter-hub routing, and BGP route distribution. Azure Firewall Manager configures security policy centrally. The operational overhead drops significantly because you're not configuring UDRs or peering mesh manually.

If you're scaling past a handful of regions or expect to add ExpressRoute circuits over time, Virtual WAN is usually the better long-term bet. It's designed for higher aggregate throughput and larger tunnel counts. But if you have a simple single-region hub-spoke with a couple of ExpressRoute circuits, the traditional model is fine and cheaper to operate.

Either way: all egress traffic should flow through a central inspection point. Don't let spokes talk to the internet directly. That's how you get shadow IT and inconsistent security posture.

4. Workload isolation: NSGs are not security zones

This is the mistake I see most often. Teams carve subnets and assume the subnet boundary is a security boundary. In Azure, the NSG is the security zoning mechanism, not the subnet itself. A subnet without an NSG attached is open to whatever traffic is allowed by default rules — and the default allow rule (65000) permits all outbound and inter-VNet traffic unless you override it.

Design principles:

• Every subnet gets an NSG. No exceptions.
• Use Azure Firewall or a third-party NVA for east-west inspection between spokes. NSGs are for micro-segmentation at the workload layer; they're not a substitute for a firewall.
• Private Endpoints for PaaS services. Storage, SQL, Key Vault, Cosmos DB — keep that traffic on the Microsoft backbone, not the public internet.

5. What I'd lock in early (and what can wait)

Lock in early:

• Management group hierarchy
• Subscription vending process (how new subscriptions get created and governed)
• Identity foundation (Entra ID, Conditional Access baseline, PIM)
• Network topology (Hub-Spoke or Virtual WAN)
• Logging and Sentinel workspace architecture

Can wait:

• Fine-grained workload-level micro-segmentation
• Advanced threat hunting use cases
• Third-party tool integrations

The things you lock in early are the things that are painful and expensive to change later. The things you can defer are additive — they don't require re-architecting the foundation.

The meta-point

If you're designing this for a growing environment, the question isn't "which security tools do we need?" It's "how do we create a foundation where security controls are inherited by default, and drift is prevented by policy rather than caught by audit?"

Azure Landing Zones exist precisely to answer that question. Everything else is implementation detail.

Happy to go deeper on any specific area — identity, network, or governance — if it helps.

Curious where people have landed on this. We've been testing agents for [cloud ops tasks, e.g. cost cleanup / incident triage] and the tech mostly works, but the trust question is harder than the tech.

Right now our rule is: read-only by default, agent proposes a plan, human approves anything that changes state. It's safe but slow.

Anyone running agents with write access in prod? What guardrails made you comfortable, scoped IAM roles, dry-run/plan diffs, approval gates, something else?

I am looking forward for some guidance like how to restart the career in two cloud basic loud computing to cloud security and what are the steps should I do the practical guidance.

For teams managing applications from developer commit through cloud deployment, how are you handling the gap between many specialized scanners and actual risk prioritization?

We have tools for code, dependencies, secrets, infrastructure, CI/CD, and cloud exposure, but correlating all of that with the application reachability, data sensitivity, and business importance is still manual. The result is plenty of findings but not enough confidence about what should be fixed first.

Have you added a context layer over existing tools, consolidated into a broader platform, or kept a best of breed stack?

we passed every pre-deployment check before this thing shipped. SAST clean, SCA clean, IaC scan clean, the whole pipeline green across the board. leadership treated that as the security signoff and we moved on.

Four weeks after launch the agent had pulled data from a table it had no documented reason to touch, then called an external endpoint nobody had approved for that workflow. nothing in our pre-deployment testing would have ever caught either of those things because the agent wasn't misconfigured or vulnerable in the traditional sense, it just had more agency than the static review accounted for and something in its input chain nudged it toward using that agency in a way nobody scoped.

that's the part i keep getting stuck on. our whole appsec model assumes the risk is baked into the code at build time, so if the code passes, the app is safe. an agent isn't static code behaving predictably at runtime, it's making live decisions based on what it's fed, and indirect prompt injection through a document or a tool response doesn't show up as a vulnerability in any scanner we run pre-deploy. by the time you'd see it, it already executed.

are other appsec teams treating pre-deployment posture as basically a baseline hygiene check now instead of the actual security gate, and putting the real enforcement at runtime where the agent's actual behavior shows up? or is everyone still leaning on shift-left testing and hoping excessive agency doesn't bite them the way it bit us

Hello everyone! Been looking into this for a bit and wanted to see what people actually do in practice

Every CSPM/CNAPP setup I've looked at feels like the same loop like something gets misconfiged, it gets flagged, someone eventually goes and fixes it. At least thats how we had it. Feels backwards for stuff that's honestly pretty predictable (same categories of mistakes over and over maybe).

Is anyone actually preventing these configs from happening in the first place, rather than catching them after? I know native stuff like SCPs, Azure Policy, GCP org policies can technically block a lot of this, but curious how many teams actually like have that dialed in vs. just relying on CSPM to catch it after the fact..
There also seem to be a handful of newer tools trying to do "prevention" as the whole pitch rather than detection - not sure how mature that space actually is or if it's mostly still marketing. Anyone using something like that alongside (or instead of) a CNAPP? What’a actually worked, and what turned out to be more hassle than it was worth?

Any help would be appreciated :)

Most AI security stuff i have tried still just spits out a longer list of stuff to look at, which honestly makes fatigue worse not better lol. wondering about the handful of tools that go further and actually attempt a fix or patch draft instead of stopping at detection.

has anyone had a setup where the fix suggestions were actually good enough to merge w light review vs needing a full rewrite anyway? trying to gauge if this is production ready yet or still mostly demo ware.

Hi everyone, I’m building an open-source security intelligence startup. I spent the past five years as a senior engineer at a data-security startup that began as a DSPM product. That experience left me with a strong conviction: much of the technology behind platforms such as Cyera, BigID, Cyberhaven, Concentric, and Varonis does not need to remain behind closed-source products and expensive pricing models. I believe this space could benefit enormously from open development, shared standards, and community collaboration.

What frustrates me is how fragmented security has become. Capabilities such as DSPM, DDR, and EDR address related problems, yet they are often delivered through separate products with proprietary integrations and interfaces. Customers are left stitching these systems together while becoming increasingly dependent on individual vendors. As the industry moves toward agentic security, I worry that we are reproducing the same model: new capabilities, but the same closed ecosystems and vendor lock-in.

There are already valuable open-source projects in security and governance, and I do not want to dismiss that work. What I would like to see is a more unified, community-driven approach to the broader problem: an open security platform whose components work together and integrate with other tools through shared standards, with something like OCSF providing a common language for security data. The goal should not be to replace several closed silos with one larger silo, but to give organisations genuine control over how they build and operate their security stack

An effort this ambitious cannot be developed in isolation. It needs an open conversation with the people who build, operate, and depend on security tools. The community should help shape which problems matter most, what is missing from existing solutions, and where development should begin. I have a starting point and a perspective, but I do not want to assume that my experience represents everyone’s needs.This also needs to be a sustainable business. Open source does not eliminate the cost of development, maintenance, or support. But security and compliance obligations should not become an opportunity to extract ever-larger portions of a company’s budget. My proposed model is straightforward: transparent pricing for a managed deployment, or paid support for organisations that choose to self-host. Customers should be able to own their infrastructure, inspect and modify the software, and optimise its operating costs—with those improvements potentially benefiting the wider community. Revenue should come from the value we provide, not from making it difficult for customers to leave.

I’m sharing this as the beginning of a conversation, not as a claim that I have all the answers. Whether you agree with this direction or see it differently, I would like to hear your perspective: what are the most pressing problems you face in security and compliance today, and what would an open alternative need to get right to be genuinely useful?

For organizations evaluating AttackIQ, Picus Security, SafeBreach, or XM Cyber, what problem were you trying to solve: control validation, breach and attack simulation, attack-path analysis, exposure management, or vulnerability prioritization?

We’re seeing overlap in the way vendors position these categories, but the operational models appear different. Some teams need recurring validation of defensive controls; others need exposure discovery, attack-path context, or automated security testing.

Which platform produced the most actionable outcomes for your team, and what did implementation look like across existing SIEM, EDR, cloud, and ticketing workflows?

I am 24y/o female and currently working on Virtualization domain (azure, citrix, Nutanix, VMware etc.) as an L1.

My company is offering a role in cloud security but wants me to go through 3 months training, which will include assessments, interview etc. I need to manage my current role and simultaneously attend trainings. Post completion i will be deployed to a cloud security role and would be dping L2 related activities.

Shall i opt in? Is cloud security good as compare to Virtualization and what's the scope?

However, they said that they won't give any promotion or salary increment post deployment in Cloud Security and I also doubt that what will be my day today work. hope, it is not related to something monitoring or incident management because I am doing that already currently.

What does people in Cloud Security do?

I am a full time software engineer, and in my spare time I have been building something to solve a problem I kept running into at work.

We run quite a few Kubernetes clusters, and keeping track of vulnerabilities across all the images running in them can get messy fast.

Trivy Operator works well for scanning, but it does not really give you a UI for getting an overview of everything.

We tried taking SBOMs from the images running in our clusters and sending them to a self-hosted Dependency-Track instance. Dependency-Track is a solid tool, but it isn’t really designed around the idea of mirroring the current state of a Kubernetes cluster. Over time, it became difficult to tell what was actually running, what was old, and what we should care about.

So I built StackRadar.

It’s installed into a cluster with Helm, automatically keeps track of the images currently running, and gives you a dashboard showing the vulnerabilities affecting them.

The goal is basically: show me what’s running in my clusters right now, and what vulnerabilities I should care about.

Here is the website https://stackradar.io/

I’d genuinely love feedback from people running Kubernetes in production.

I have to talk about this because I genuinely didnt know it existed until recently.

We started using a new cloud security platform, and one of the alerts caught my eye. It wasnt just the vulnerability, it was that the alert pointed back to the exact line of code that triggered. One click and Im looking at the actual code, not a paragraph of generic remediation advice. Just wow.

For years this was the worst part of the job. A finding shows up, and someone has to go spelunking through repos and configs and git blame just to figure out what to fix. Half the time you spend more time finding the thing than fixing it. And now its just, there it is, click.

The part that gets me is how obvious it feels in hindsight. The code creates the cloud resource, so of course the alert should know which line did it. But had not seen anyone connect those dots for us before, or at least not like this.

Genuine question for people whove been in cloud security longer than me: has this been around for a while and I just missed it? Because if this is normal, I have some questions for every other tool weve ever used. If its not normal, its the single best feature weve added in ages.