We're fans of cloud security tools. Prowler, Wiz, Orca, Scout. There are dozens of options, with new ones appearing regularly. They automate the heavy lifting of querying cloud environments and correlate findings across services.
But every scanner has limitations. And sometimes you need to build your own.
How CSPM Tools Work (And Where They Stop)
Cloud providers like AWS and Azure have well-documented, standard APIs. What you test in one tool you could test in another, or run yourself via the AWS CLI. The major CSPM platforms do this at scale--connecting to control planes, pulling configuration data, scanning data stores, and correlating findings.
What they can't do is make every decision perfectly for your environment.
Every vulnerability scanner and CSPM tool involves design decisions:
- When to report a finding
- How much detail to provide
- How to handle edge cases
- What counts as "critical" vs. "high" vs. "medium"
These decisions involve tradeoffs. The scanner team optimizes for the common case, the typical user, the expected configuration. That's reasonable engineering. But it means some findings that matter to you won't surface, and some that don't matter will.
Recognizing the Limits
When you run these tools daily across many environments, you start to see the nuances. You find yourself asking: Why didn't this show up? Why did that get flagged? You dig into the alert logic and start to reverse-engineer the decisions made by the original signature designers.
Sometimes you don't agree with those decisions.
At that point, you have two options:
File a bug report: Explain your perspective to the vendor. Maybe they agree and update the scanner. Maybe they don't, or maybe it's low priority for them.
Build your own tooling: Augment the scanner with scripts, automation, and additional checks that fill the gaps.
We usually try both. But often, building your own tools is faster than waiting for vendor changes.
What Custom Tooling Looks Like
This isn't about replacing your CSPM. It's about extending it.
Read-only audit roles: We always set up a dedicated security audit role in cloud environments. A read-only account that our automation can use to double-check CSPM findings, validate alerts, and go deeper than the scanner goes.
Validation scripts: Small scripts that verify scanner findings. Did the CSPM flag this correctly? Is the context accurate? Especially useful for edge cases where scanner logic is uncertain.
Gap filling: New AWS services or features that aren't covered yet. Edge cases that the scanner handles partially. Specific configurations that matter to your environment but aren't general enough for the vendor to prioritize.
Custom correlation: Pulling data from multiple sources and correlating it in ways the CSPM doesn't. Combining scanner output with access logs, business metadata, or findings from other tools.
The goal is a consolidated view that brings together CSPM findings, custom checks, and business context into something actionable.
Where Gaps Commonly Appear
Some areas where we consistently see CSPM tools fall short:
Identity and Access Management: IAM is complex and constantly evolving. Most tools flag obvious issues like stale keys, overly broad policies, and known privilege escalation paths. But the nuances of who should have access to what in your specific organization require custom analysis.
Data Security Posture: DSPM scanners find sensitive data, but the false positive rate can be high. Third-party dependencies with contributor emails get flagged, and build artifacts with test data trigger alerts. Custom policies help filter the noise.
Attack Surface Reachability: Understanding what's truly reachable from the internet vs. what just looks exposed requires combining multiple data sources. Scanner enrichments don't always get it right.
Vulnerability Prioritization: Beyond CVSS scores, true prioritization needs business context that scanners can't know: customer impact, revenue implications, contractual obligations.
Patch Management: Identifying what needs patching is one thing. Understanding the blast radius of patching it, the dependencies involved, and the operational impact requires additional analysis.
Infrastructure-as-Code Root Causes: A client had a security group flagged as overly permissive, with 65,000 IP addresses allowed in. The scanner caught it. But understanding why required tracing it back through their Terraform code. Turns out the CIDR range had a typo, off by one digit, and it was actually copied from an example in Terraform's documentation. Those 65,000 addresses belonged to AT&T customers in Florida. The scanner found the symptom; custom analysis found the root cause.
Secrets in Build Artifacts: Another client did everything right with secrets management. They used GitHub Secrets, never committed credentials to code, and GitHub Advanced Security showed clean. But their build process injected an AWS access key into client-facing JavaScript during compilation, and that artifact got pushed to S3. GitHub's scanning doesn't see post-build artifacts. That's not what it's designed for. The fix was adding detect-secrets as a post-build GitHub Action to scan what was actually being deployed. Nobody expected secrets to appear after the build. That's the gap custom tooling fills.
These are areas where small, focused vendors often emerge to fill specific gaps. We partner with some of them. We build alternatives when we can't find good options.
The Resource Reality
Most security teams can't do this.
If you're running a CSPM as part of your job, one of twelve priorities on your daily list, you probably don't have time to:
- Deep-dive into scanner limitations
- Enumerate edge cases and form opinions about them
- Build custom tooling to extend coverage
- Maintain that tooling as cloud services evolve
Before you know it, you've got a Frankenstein platform held together with scripts and scheduled jobs. Maintained as a side project. Increasingly fragile.
This is where dedicated focus matters. If cloud security is your full-time job and not one of many responsibilities, you have the bandwidth to go deep, stay current, and maintain the additional tooling that turns generic coverage into comprehensive visibility.
The Ecosystem Response
The gaps in CSPM tools aren't secrets. The market responds by creating small vendors that target specific pain points. Data security specialists. IAM analyzers. Attack surface mappers.
These tools can be valuable, but integrating them adds complexity. Another dashboard. Another data source. Another thing to maintain.
The alternative is building in-house, if you have the engineering capacity and sustained focus. The advantage of custom tooling is that it does exactly what you need. The disadvantage is that you're now responsible for maintaining it.
Questions to Ask
When you're building a comprehensive view of cloud security, consider:
- How deep do you want to go? Generic coverage or nuanced analysis?
- How much coverage do you actually need? What risks matter most?
- What's your opinion on scanner decisions? Do you agree with how your CSPM handles edge cases?
- Do you have capacity to maintain custom tooling? Or will scripts accumulate and rot?
There's no universal answer. The right approach depends on your environment, your risk tolerance, and your resources.
The Takeaway
CSPM tools are essential. They do the heavy lifting that would be impossible manually. But they're not complete.
Every scanner makes decisions you might disagree with. Every platform has edge cases it handles imperfectly. If you want truly comprehensive cloud security, you need to either accept those limitations or extend beyond them.
The question is whether you have the time and expertise to build and maintain that extended coverage.
If you've noticed gaps in your CSPM but don't have bandwidth to build custom tooling, or you've tried and ended up with a fragile collection of scripts that nobody wants to maintain, you're facing a common problem. Sometimes it makes sense to bring in a team that's already built this infrastructure across many environments, rather than reinventing it yourself.
Jon Rose runs IOmergent, advising engineering-led companies on security strategy and managed cloud security operations.
