The Gap Between Security and Adoption

Let’s be honest: security tools have often felt like they’re playing catch-up, especially when compared to the sleek, intuitive tools developers use every day. Developers today are already juggling speed, innovation, and the growing expectation to “build secure.” And most weren’t even trained for that last part.

When security tools introduce friction, generate noise, or simply aren't available when and where they matter, adoption suffers. Developers get frustrated. Alerts get ignored.

Compare that to GitHub Copilot. It’s seen incredible adoption, over 15 million monthly active users in 2025, a 4x year-over-year increase since its launch. That kind of effortless, flow-enhancing experience is what security tools should aspire to. It proves what’s possible when a tool helps rather than hinders a developer’s day-to-day.

This article isn’t just about pointing out what’s broken. It’s the start of a four-part series on how we’re rethinking security through the lens of developer experience. In this first post, we’ll lay out our vision and core principles. The next three posts will break down how Wiz brings that vision to life, step by step, across the developer journey: in the IDE, in pull requests and pipelines, and in the Wiz portal.

Why Legacy Security Was Never Built for Devs

AppSec tools are still stuck in the past

The traditional AppSec ecosystem, especially tools like SAST, wasn’t designed for how modern teams build software. These tools operate in isolation, analyzing code without understanding how that code behaves once deployed. They lack runtime validation. They lack context.

This creates blind spots across the SDLC. Security and cloud teams often end up working in parallel silos, duplicating efforts or overlooking critical relationships between code, infrastructure, and runtime behavior.

The result? A wave of false positives and noise that overwhelms developers. Take a classic example: a SAST scanner flagging an SQL injection vulnerability, but in reality, the input is sanitized further up the stack. From a code-only perspective, the finding seems valid, but from a runtime perspective, it’s not exploitable. Developers dismiss these as false positives. But what happens when that sanitization logic changes later? Without a cross-SDLC context, a theoretical risk becomes a real one, and no one sees it coming.

Context switching is expensive

Now think about the number of tools a developer has to touch just to push a change, say adding a semicolon to line 11 in app.js, to production. They’re reviewing pull requests, checking CI pipelines, verifying runtime impact, and toggling between platforms to resolve any issues. Each of those hops carries a mental cost.

The ideal number of context switches to verify a secure change? Zero.

In practice, most developers are navigating tool sprawl and siloed feedback loops that break their flow. And the more complicated that process becomes, the more likely security guidance gets skipped or sidelined.

Cloud-native and AI have raised the bar

Today’s developers expect automation by default. Platform engineering tools abstract away complexity. GitHub Copilot and similar AI assistants write boilerplate code, flag errors, and even suggest tests in real time. They fit into the developer experience; every ‘tab’ stroked gets them moving forward with more code, and that’s why they get adopted.

Security, by contrast, hasn’t kept up. The same AI that speeds up development is also accelerating the risk surface. When devs can generate hundreds of lines of code in minutes, new misconfigurations, secret leaks, or vulnerable packages increase at a proportional rate. Without security that’s equally fast, equally integrated, and equally intuitive, the gap between written code and secured code will keep growing.

Principles for Modern Developer Security– Security That Emulates a Dev Tool

At Wiz, we believe security should be a native part of the developer experience, baked in from the first line of code to production deployment. That means rethinking how tools show up in developer workflows and what “usable security” really looks like. Here are five principles we follow.

1. “Start Secure” with Secure Defaults and Easy Buttons

The best security issue is the one you never have to fix. Developers shouldn’t be left holding the bag for risks they didn’t introduce, like insecure base images, weak pipeline settings, or unencrypted secrets.

“Starting secure” means giving developers a hardened foundation by default. That’s why WizOS, our hardened, FIPS-compatible, zero-CVE image, exists. Developers shouldn’t need to opt into security; they should start from a place where secure is the default, not the exception.

Easy buttons matter too. Whether it’s a prebuilt policy, a one-click fix suggestion, or a pre-commit hook that flags a leaked secret before it hits GitHub, security should feel like a helping hand, not an extra hurdle.

2. Guardrails Instead of Gates

Security that blocks progress is security that gets bypassed. Developers don’t respond well to rigid policies that fail builds for low-priority issues, especially when those issues have no real exploit path.

We give teams full control over how they want to enforce security, whether that’s blocking builds on critical CVEs or providing soft guidance for medium-risk issues. Our unified policy engine allows orgs to define risk thresholds, apply them consistently across IDEs, pull requests, and CI/CD, and remember which issues were triaged, fixed, or ignored, so developers don’t get stuck in loops.

By guiding instead of blocking, security becomes a collaborator, not a bottleneck.

3. “Less Is More” for Developers

A great developer experience doesn’t overload you with information. It tells you what matters, when it matters, and gets out of the way.

That’s why we focus on clear, minimal security feedback, like a one-line pull request comment explaining a vulnerability and how it affects your app, plus a link to autofix. No dump of raw CVE data. Just enough to understand the impact and take action.

Behind the scenes, Wiz Code auto-discovers the full SDLC: VCS repositories, CI pipelines, Infrastructure as Code, container registries, and cloud deployments. Developers don’t have to manually configure anything or hunt for context; we connect the dots for them, from the first commit to production.

4. Speak the Same Language: The Security Graph

Security and developers often use different tools, view different metrics, and model applications in entirely different ways. That disconnect leads to confusion, misalignment, and missed risks.

The Wiz Security Graph changes that. It models the full application, from code artifacts to workloads, secrets, IAM roles, databases, and public endpoints, and maps the relationships between them. It becomes a shared language for security and engineering to understand how the application behaves, what it’s connected to, and what’s at risk.

Developers can trace a misconfiguration back to the Terraform file that deployed it. Security teams can see whether a code vulnerability (e.g., both CVEs and CWEs) is reachable from the internet or already mitigated upstream. Everyone works from the same model, and that’s what breaks down silos.

5. Zero Context Switching

The most powerful way to reduce friction is to meet developers where they already are.

That’s why Wiz Code integrates into the IDE for real-time scanning, VCS workflows like pull requests, and the GitHub and GitLab Security tabs. No need to jump into separate dashboards or learn new interfaces. Just actionable, timely security feedback in familiar tools.

We also automate as much as possible, generate pull requests to fix dependency issues, automatically track scan coverage, and send auto-notifications when new risks emerge. Developers only need to intervene when it matters.

How We’re Bringing This Experience to Life at Wiz

This isn’t a distant vision. We’re already bringing this developer-first approach to life across every layer of the SDLC with Wiz Code, and it’s evolving fast. This is the foundation for the next three blog posts in this series, where we’ll dive deeper into each part of the developer journey:

What follows here is a small preview of how this experience plays out across the SDLC.

Part 2. In the IDE

Security should feel as immediate and integrated as ‘autocomple’, which is why Wiz Code delivers real-time, in-editor security that helps developers fix risks before code ever leaves their machine.

We’ll explore real-time scanning and AI-powered fix suggestions directly in VS Code and JetBrains (now in preview) and pre-commit hooks to catch secrets before code even reaches version control. We’ll also review how Wiz streamlines onboarding and setup, with no API tokens or complex provisioning.

Part 3. In the Version Control System (VCS) and CI/CD pipelines

By embedding guardrails directly into code reviews and build workflows, Wiz Code ensures security happens in the natural flow of development, without slowing releases down.

We’ll see how findings are displayed in PR comments and the GitHub or GitLab Security tabs and reports, with one-click fix flows and support for defining or ignoring issues inline or via .wiz config files.

Wiz Code enforces security policies across local and pipeline environments using a unified Wiz CLI. Teams can customize risk thresholds per project or repo, fail builds only when it matters, and ensure consistency without introducing new complexity.

Part 4. In the Wiz Portal

With dedicated developer views and progress tracking, we’ll see how Wiz turns security from a background task into a shared, visible achievement across individuals and teams.

Developers can explore personalized dashboards showing the repos they own, the risks that affect them, and their progress over time. The new Developer Role lets them work independently within Wiz, while the “Champion Center” celebrates milestones like “Zero secrets in repo” or “Zero critical CVEs with a fix.” Adoption is visible, measurable, and motivating.

Together, these experiences reflect our core belief: security tools should reduce effort, not add to it. They should help developers build securely by default, not require them to become security experts.

Conclusion

Security tools shouldn’t just scan. They should guide. They should help fix. They should accelerate development, not slow it down.

At Wiz, we’re rebuilding Application Security Posture Management (ASPM) from the ground up, with developer experience at the center. Because if your developers won’t use a security tool, it doesn’t matter how powerful it is.

We’re just getting started. Keep an eye on the Wiz blog for the next installments.