DEV Community: Jon Rose

What the First 90 Days of Managed CSPM Look Like

Jon Rose — Tue, 09 Jun 2026 13:00:00 +0000

What happens when you engage a managed CSPM service? Here's what the first 90 days typically look like--from initial setup through steady-state operations.

No surprises. No mystery. Just the process.

The value of bringing in an outside team: no politics, no history. We want to understand where things are, where they're headed, and get to the ground truth of what's secure and what needs fixing. Sometimes people get caught up in internal dynamics or the minutia of legacy decisions. An outside perspective cuts through that.

Week 1: Setup and Integration

The technical onboarding is fast, often done asynchronously within the first day or two.

Communication channels: We set up a dedicated Slack channel (or Teams for Microsoft shops). Most cloud and DevOps teams live in chat. Async communication works better than scheduled calls for day-to-day questions.

Scanner integration: Connecting Orca, Wiz, or your existing CSPM to your cloud environment. At the organizational level, new accounts get automatically included. Or we target specific accounts if you're starting focused.

Read-only audit role: We deploy our own audit role with read-only access. This lets our automation validate CSPM findings and extend scanning capabilities beyond what the platform does out of the box.

Initial configuration: SSO setup, MFA enabled, additional users onboarded. Basic housekeeping to ensure secure access.

Total technical setup: typically 15-30 minutes of customer time. The integrations are designed for easy deployment with zero operational impact.

Week 1-2: Scanning and Tuning

Once connected, the scanner needs time to work through your environment. Usually a day or two for a full initial scan.

During this window, we:

Load tuning profiles: Our pre-built configurations for the CSPM platform. Automations that enable or disable specific rules, and custom alerts that roll things up the way we've found works best for remediation focus.

Push custom views: The 25-35 discovery views we've developed for different security domains covering attack surface visibility, IAM posture, and data storage inventory. These become the lenses you use to see your environment.

Configure business units: If you have logical groupings by account, team, or product, we set those up for cleaner reporting.

Apply DSPM policies: Tuned data security scanning that filters the common false positives we see across environments.

Set up integrations: Slack notifications, webhook connections, API setup for our MCP servers and post-processing analysis.

The scanner runs in the background. Agentless side-scanning means no impact on your production systems. No performance hits, no agent deployment headaches.

Week 2-3: Context Gathering

This is where the real work starts.

We walk through your environment together:

Architecture review: How do things connect? What systems serve what purposes? If you have architecture diagrams, great. If not, we build them together.

Business context: What matters most? Which systems are customer-facing? Where does sensitive data live? What's changing? New systems coming online, old ones being retired?

Crown jewel identification: Where's the data you really can't afford to lose? Which systems generate revenue? What keeps you up at night?

Process understanding: How do you patch systems? How does IAM work (SSO integration, access request processes)? Who owns what?

This context gathering transforms generic CSPM alerts into useful intelligence. Without it, we're just showing you what the scanner found. With it, we're telling you what actually matters.

Week 2-3: Initial Findings

As we learn the environment, we start finding things.

When we first log into a CSPM that hasn't been actively managed, we typically see hundreds, sometimes thousands, of critical and high-risk alerts. You can't even make sense of it. That's the starting point.

Critical issues: Anything requiring immediate attention gets flagged right away. Malware, active compromises, severe misconfigurations with real exposure. These don't wait for a monthly report.

Quick wins: Low-effort, low-risk changes with meaningful security improvement. We'll often identify 5-10 of these that can be addressed in a single call. Many customers knock them out immediately.

Abandoned infrastructure: Resources that aren't in use anymore. Dev environments that were "temporary." This discovery frequently saves $5-10K per month. Concrete ROI within the first few weeks.

Junk drawer cleanup: That original cloud account with years of accumulated stuff. We identify what can be decommissioned, what needs migration, what's actually production.

Week 4-8: Systematic Review

Once we understand the environment, we shift to systematic assessment across security domains.

IAM posture: Who are your admins? Are they supposed to be admins? What access keys exist, and are they rotated? Where are privilege escalation paths?

Vulnerability management: What are the actual critical and high issues? How do we prioritize given business context? What's the trend over time?

Data security: Where does sensitive data live? Is it all in expected locations? What needs additional controls?

Attack surface: What's internet-facing? Is that intentional? What services are exposed that shouldn't be?

For each domain, we build a view with current status, top issues, and links to the relevant data in your CSPM. A way to quickly see where you stand and what needs work.

Week 8-12: Establishing Cadence

By month two and three, we're transitioning from initial assessment to steady-state operations.

Daily monitoring: Our team sees new alerts as they appear. Triage happens continuously. Critical issues get immediate escalation; routine findings get batched appropriately.

Monthly reviews: Structured sessions looking at the security posture. Criticals and highs, trend lines, accepted risks, progress on remediation. Credit for what's improving. Honest assessment of what isn't.

Quarterly OKRs: At the start of each quarter, we propose 2-3 high-level objectives with measurable key results. Specific improvement targets that align with your resources and priorities.

Accepted risk tracking: Findings that aren't getting fixed. Why not? What's the compensating control? When do we review again? This gets documented and tracked.

What Steady-State Looks Like

Remember those hundreds or thousands of critical and high alerts from the beginning? After 90 days, the picture looks different.

Critical alerts: Ideally zero. We try to resolve criticals immediately or have clear remediation timelines.
High-risk alerts: Down to 5-40, depending on your environment. Remaining issues are packaged into projects with specific timelines. "Over the next six weeks, we'll figure out a process to patch and relaunch these containers on modern versions."

You should have a solid plan for remediation and an established timeline within 30 days. Even if you can't fix everything immediately, you know what's being addressed and when.

After 90 days, you also have the following.

Fully configured CSPM with custom views, tags, and automation
Daily monitoring and triage by people who know your environment
Clear visibility into your security posture across domains
Quarterly improvement plan with measurable goals
Process for handling new findings (escalation, assignment, tracking)
Running knowledge base of your infrastructure and business context

From there, it's continuous improvement. Quarter over quarter, the posture gets stronger. Issues get resolved or formally accepted. New capabilities get added. The security program matures.

The Timeline Reality

For straightforward environments, 90 days gets you to steady state.

For complex situations with multiple acquisitions, merged infrastructure, or significant technical debt, the roadmap might extend to 6-12 months for comprehensive hardening.

That's fine. We set realistic expectations based on what we find. The goal is consistent progress, not arbitrary timelines.

The Takeaway

The first 90 days aren't mysterious. Methodical work: integrate, scan, tune, learn context, assess systematically, establish cadence.

What makes it work is dedicated attention from people who look at your environment every day, not just when something escalates. Sometimes you just need someone holding you accountable a little bit, encouraging you, being a sounding board for decisions. That sustained focus and outside perspective is what most organizations struggle to provide internally.

By the end of 90 days, you have visibility and a plan. After 90 days, 180 days, one year, your cloud security posture is in a radically better position than when you started. Everyone feels good about the progress. That's the goal.

Jon Rose runs IOmergent, advising engineering-led companies on security strategy and managed cloud security operations.

DIY vs Managed CSPM: An Honest Comparison

Jon Rose — Tue, 02 Jun 2026 13:00:00 +0000

Should you run CSPM tools yourself or bring in a managed service?

There's no universal answer. It depends on your team, your environment, and your honest assessment of what you can sustain.

When DIY Makes Sense

Running CSPM internally works when:

You have dedicated cloud security staff: Someone whose primary job is operating security tooling across your cloud environment. Not "part of their responsibilities."

Your team has deep platform expertise: They know the tools inside out. They've configured custom views, built automation, understand the edge cases. They stay current on updates.

You have engineering capacity for customization: Internal teams that can build additional tooling, integrate data sources, and extend the platform when it doesn't do what you need.

You're willing to invest in continuous improvement: Ongoing tuning, regular reviews, evolving playbooks. Not set-it-and-forget-it.

If all of that is true, DIY can work well. You maintain direct control, build institutional knowledge, and avoid external dependencies.

The DIY Reality Check

But let's be honest about the common pattern.

A brilliant engineer stitches together a handful of tools. Impressive work. They build something genuinely useful for a first pass at the top issues. But it's not their full-time job. Then priorities shift.

What happens next is predictable. The system languishes. No updates, no maintenance, not fully operational. The knowledge gets stuck with one or two people. If they move on, there's not always anyone to pick it up afterward. That's key-man risk applied to infrastructure.

Meanwhile, modern cloud security has gotten genuinely complex. Your CSPM connects to data security posture management, API security, cloud detection and response, CI/CD pipeline scanning. You need to trace code from a developer, through GitHub, through deployment, into running infrastructure. It's an expanding ecosystem, and keeping up requires sustained focus.

Platforms like Orca, Wiz, and Datadog exist because stitching this together yourself is hard. Most companies we work with aren't security businesses. They're providing healthcare, building tech products, running e-commerce. Security isn't their core business.

When Managed Makes Sense

The strongest case for managed CSPM:

You've outgrown DIY but can't justify a dedicated hire: The 50-500 employee range where cloud infrastructure is significant but a full-time cloud security specialist isn't feasible.

Your internal team is stretched: Capable but overloaded. Offloading CSPM operations lets them focus on higher-value work.

You want expertise you can't build quickly: Deep CSPM knowledge takes time to develop. Hiring it is hard. Buying it as a service is faster.

You've tried DIY and it didn't work: The tool is deployed but underutilized. Alert fatigue has set in, and you need a reset.

What Managed CSPM Provides

A CSPM tool isn't cloud security. It's a starting point.

The tool scans your environment and generates findings. What happens next, the interpretation, prioritization, and remediation, is where security actually happens.

When you engage a managed CSPM service, you get:

Tuning and configuration: Custom views, tagging systems, and automation rules that match how your organization thinks about risk. The 25-35 custom discovery views we build for each environment aren't decoration. They're how you actually see what matters.

Daily monitoring: Eyes on the alerts every day. Triage of new findings. Classification of issues as new, persistent, or reoccurring. This ongoing attention is what most internal teams can't sustain.

Monthly reviews: Structured sessions that go beyond individual alerts to look at trends, progress on remediation, and strategic priorities.

Business context integration: Learning your environment over time. Understanding what matters, what data is sensitive, what's changing. This knowledge accumulates and informs every prioritization decision.

Custom tooling when needed: Extending CSPM coverage into gaps, building automation for validation, correlating data sources the platform doesn't connect.

The analogy is fractional CISO services. You could hire a full-time CISO for $350K+ per year. Or bring in someone fractional, spend less on management overhead, and reallocate the savings to products and services that make the program run. Managed CSPM follows the same logic.

The Honest Tradeoffs

Managed CSPM has downsides:

External dependency: You're relying on a third party to understand and monitor your critical infrastructure. Requires trust and good communication.

Business context ramp-up: External teams don't automatically know your business. There's a learning curve.

Cost: Managed services cost money. For some organizations, internal staff works out better. For smaller teams, external services are often more cost-effective than dedicated hires.

Less direct control: You're setting direction and reviewing results rather than doing hands-on configuration yourself.

What You Should Do Internally

Managed CSPM doesn't mean abdicating cloud security. Your team still owns:

Business context: Nobody outside your organization understands your priorities as well as you do. You provide the context; we apply it to technical findings.

Remediation execution: The people who change configurations, patch systems, and fix code are usually internal. Managed CSPM tells you what to fix; your team does the fixing.

Risk decisions: Accepting risk is a business decision. We can advise, but you decide what's acceptable.

The Decision Framework

Ask yourself:

Who is responsible for cloud security today, and what percentage of their time does it actually get?
When was the last time your CSPM configuration was meaningfully updated?
Can you explain what your top 10 cloud security risks are right now?
Do you have playbooks for different security domains?
Is cloud security improving over time, or just being maintained?

If the answers are uncomfortable, that's useful information.

The Takeaway

DIY CSPM works when you have the resources to do it well. Managed CSPM works when you don't, or when you'd rather focus those resources elsewhere.

The worst option is the middle ground: paying for tools but not operating them effectively. That's the most common outcome, and the most expensive, because you get costs without benefits.

Be honest about what you can sustain. Choose accordingly.

Jon Rose runs IOmergent, advising engineering-led companies on security strategy and managed cloud security operations.

The Business Context Problem: Why Vulnerability Severity Scores Lie

Jon Rose — Tue, 26 May 2026 13:00:00 +0000

A critical vulnerability on an Alpine-based reverse proxy sitting behind three layers of network controls isn't actually critical.

A medium-severity finding on the database holding 90% of your customer data might be.

CVSS scores don't know the difference. Your security team needs to.

The Baseline Is Just the Start

Vulnerability prioritization is a hot topic for security teams and vendors. Everyone wants a magic number that tells you what to fix first. The problem is that magic number doesn't exist--at least not without context.

The way we approach it: focus on criticals and highs, generally ignore lows, and treat mediums as a "maybe" that gets reviewed after the urgent stuff is handled. That's a reasonable baseline, but it's just the starting point.

Some things flagged as critical don't matter much in practice. Some highs can be demoted when compensating controls reduce the real risk. And some mediums deserve more attention because of what they protect.

What Actually Drives Risk

When you look at prioritization honestly, it comes down to business impact. The technical severity score is one input, but it's not the whole picture.

Real risk to the business: What happens if this gets exploited? Not in theory. In your specific environment, with your specific data, serving your specific customers.

Commercial and legal exposure: What does a breach mean for contracts? For liability? For regulatory compliance? A vulnerability affecting systems that process healthcare data carries different weight than one on an internal dev server.

Data classification: Is this customer data? Internal data? Partner data? Public data? The sensitivity of what's at risk changes how fast you need to move.

Attack path: How hard is it to get here? A vulnerability on an internet-facing system is different from one buried behind VPNs, firewalls, and authentication layers.

Known exploitability: Is this on the CISA KEV list? Is it being actively exploited in the wild? EPSS scores help predict exploitability. These signals matter more than theoretical CVSS calculations.

Customer and revenue impact: Does this infrastructure serve 90% of your customer base or 1%? What revenue flows through these systems?

You pull all that together and make smart decisions. No algorithm does it for you.

The Stakeholder Experiment

We've experimented with stakeholder-specific vulnerability scoring--the concept is appealing. Different people in an organization weight risk differently. The CFO cares about financial exposure. The CTO cares about operational stability. The CISO cares about compliance and reputation.

We ran vulnerabilities through AI personas representing different stakeholders, then pressure-tested the outputs with actual people. "Our AI bot of you thought this. Do you agree?"

It was a fun thought experiment. Interesting results. But it didn't fundamentally change day-to-day operations. When you have tight alignment with your team on risk tolerance and technical context, you don't need elaborate personas. You need clear communication and shared understanding.

Compensating Controls Matter

One of the most common prioritization adjustments: demoting findings where compensating controls reduce real risk.

That critical vulnerability on a system with no network exposure, running behind a WAF, on a hardened container with no persistent storage? It might still need patching eventually, but it's not the fire you put out first.

The reverse is also true. A vulnerability flagged as medium, on a system with direct internet exposure and access to crown jewel data, deserves escalation.

CSPM tools are getting better at incorporating some of this context. Risk scores that adapt based on internet exposure, sensitive data discovery, and access permissions. But they can't know your business. They don't know which customers matter most, which contracts have the strictest SLAs, which systems represent the core of your revenue.

That context lives in your organization. Someone needs to bridge the gap between technical findings and business reality.

Accepted Risk Is Still Risk

Sometimes the answer is that you're not going to fix this.

Maybe the system is scheduled for decommissioning. Maybe the remediation requires changes that break other things. Maybe the risk is real but acceptable given current priorities.

That's fine, as long as you track it. Accepted risks go in the risk register. They get reviewed periodically. They don't disappear just because you decided not to act on them immediately.

The worst situation is unacknowledged risk. Vulnerabilities ignored without explicit decision-making, sitting in the backlog until someone asks about them at the worst possible moment.

Making Prioritization Work

The triage process we use:

Collect criticals and highs
Sort by actual business context (not just CVSS)
Assign the team to fix the real priorities
Review mediums periodically (some become highs, some become non-issues)
Track anything you're not fixing as accepted risk

The goal isn't zero vulnerabilities. It's focusing limited resources on what matters most, based on real understanding of your environment.

The Takeaway

Vulnerability severity scores are tools, not answers. They give you a starting point for investigation, not a decision.

Real prioritization requires knowing your business. What data is sensitive. What systems are critical. What contracts require specific protections. What customers you can't afford to disappoint.

Technical scores will never capture all of that. But combined with business context, they become genuinely useful.

If your team is spending time debating which "critical" vulnerabilities are actually critical, or worse, treating everything the same because there's no time to think it through, you're not getting the value you should from your tools. Sometimes it helps to have someone come in who's done this prioritization work across many environments, establish a framework, and get the team aligned on what actually matters.

Jon Rose runs IOmergent, advising engineering-led companies on security strategy and managed cloud security operations.

Alert Fatigue Is a Design Choice: Building Views That Actually Help

Jon Rose — Wed, 20 May 2026 15:13:26 +0000

The default dashboard in your CSPM tool is almost certainly wrong for you.

Not wrong as in broken. Wrong as in optimized for someone else's environment, someone else's priorities, someone else's risk tolerance. Out of the box, you get a generic view designed to look impressive in a demo. What you need is a view designed to help you actually fix things.

Here's what we typically see when we first log into a CSPM that hasn't been tuned: hundreds, sometimes thousands of critical and high-risk alerts. You can't even make sense of it. The dashboard is a wall of red and orange that's been that way for months. Alert fatigue is a design choice. You can make different choices.

Building Views That Work

We've built 25 to 35 custom discovery views for every environment we manage. That's not overkill. That's what it takes to see what matters. Some examples:

Publicly exposed cloud services: HTTP/HTTPS listeners across your environment. Simple inventory of web servers.

Non-web services: Anything not on ports 80 or 443. SSH servers, database interfaces, custom APIs. This list is always worth reviewing because non-web services often get less scrutiny.

Internet-facing data storage: S3 buckets, Azure storage accounts, RDS instances with public exposure. These deserve dedicated attention because the blast radius of a misconfiguration is significant.

Untagged PII locations: Assets detected with sensitive data that haven't been confirmed as legitimate. This inverse view (show me what's flagged but not yet validated) drives investigation rather than just alerting.

Each view answers a specific question. Who's exposed? What changed? Where are the gaps in our understanding?

The Tagging System

Views become powerful when combined with consistent tagging. We preload custom tags across every environment:

Known Admin: Tag identity groups, IAM roles, and individual accounts that have legitimate administrative access. Once tagged, these stop generating repetitive alerts. The interesting alert becomes "new admin access that's not on the known list."

Known PII: Tag assets confirmed to contain personal or health information. The database holding customer records should have PII. The development server shouldn't. The interesting alert is untagged PII in unexpected places.

Accepted Risk: Tag findings that represent conscious decisions not to remediate immediately. Maybe the system is being decommissioned. Maybe the fix breaks other things. The risk is acknowledged, tracked, and periodically reviewed.

This flips the default model. Instead of dismissing alerts after you've seen them enough times, you acknowledge them explicitly up front. Your monitoring then surfaces what's genuinely new or unexpected.

IAM: Where Signal-to-Noise Hits Hardest

Identity and Access Management is where the noise problem is most acute. IAM is complex, constantly changing, and critical to get right.

The patterns we see repeatedly:

The "Developers" group with full admin: Someone created an IAM group and attached admin permissions because it was faster than figuring out exactly what developers need. Now every engineer who joins gets dropped into that group. The scanner flags it every day, and everyone ignores the alert.

QA teams with IAM permissions: We've seen outsourced QA teams granted permissions that enable privilege escalation. Not because anyone intended to give them that access, but because someone attached an AWS managed policy without understanding what was in it.

AWS managed policy surprises: You might think AWS managed policies are safe because Amazon made them. But these policies contain permissions like iam:PassRole that enable privilege escalation. Attaching "Lambda Full Access" grants the ability to pass admin roles to functions, potentially escalating from developer to admin. And these policies can change without notice.

CSPM tools flag all of this. But the flags are overwhelming unless you know which access is intentional and which is accidental.

The Long-Lived Credential Problem

IAM access keys deserve special attention because they tend to persist far longer than anyone intended.

We've found API keys that have existed for years. In one case, 15-year-old admin keys. God only knows where they're living at this point. Keys created for a specific integration that's long gone. Keys attached to users who left the company months or years ago.

The solution is layered:

SSO integration: Connect your identity provider with AWS. When someone leaves the company and their account gets deactivated, their cloud access goes away automatically.

Short-lived sessions: AWS SSO CLI tools make it easy to use temporary credentials instead of static keys. You authenticate, get a session that expires, and keep working. If credentials leak, they're useless within hours.

Tag what remains: For the keys you can't eliminate, tag them with owner and business unit. When you're investigating or doing periodic reviews, you can actually trace accountability.

Container Bloat: Another Source of Noise

The noise problem extends to attack surface itself.

A pattern we see everywhere: developers install everything including the kitchen sink into container images because they don't want to troubleshoot missing dependencies. If you're not sure what the application needs to run, easier to include everything than debug what's missing.

The result is bloated images with hundreds of packages, most of which the application never touches. Every package is a potential vulnerability. Your scanner dutifully reports all of them. Now you're triaging CVEs for software you don't even use.

The solutions exist:

Slim base images: Start with minimal distributions instead of full operating systems. If you don't install a package, you don't have to patch it.

Distroless or hardened images: Chain Guard, Google's Distroless, and Docker's hardened images strip out everything except what your application actually needs. Fewer packages, fewer vulnerabilities, less noise.

Same pattern as IAM: reduce the surface area, and the signals that remain are more likely to matter.

The Takeaway

Alert fatigue is a symptom of generic configuration applied to specific environments. The cure is building views that match how you think about risk.

Tag what you know. Build views that surface what's new. Track what you're accepting. Reduce attack surface so there's less noise to begin with.

If your dashboard has been showing hundreds of critical alerts for months and nobody knows which ones actually matter this week, you're not alone. Sometimes you just need someone who's done this across dozens of environments to set things up so the tools actually work for you.

Jon Rose runs IOmergent, advising engineering-led companies on security strategy and managed cloud security operations.