Nobody's Blocking Security Tests on Purpose — But They Keep Getting Skipped Anyway

Ask any developer if security testing matters. You'll get an enthusiastic yes every time. Ask that same developer when they last ran a full security test suite before shipping a feature — and you'll get a much more uncomfortable pause.

This isn't a knowledge problem. Most engineers understand, at least conceptually, why security checks belong in the pipeline. The real issue is structural. Security testing has a friction problem so deeply baked into most development workflows that skipping it doesn't feel like negligence — it feels like the only rational choice when a release deadline is breathing down your neck.

Let's actually dig into why that happens, and more importantly, what it costs when it does.

The Approval Maze Nobody Talks About

Here's a scenario that plays out constantly at mid-size software companies across the US: A developer finishes a feature, kicks off the test suite, and hits a security check that requires access to a staging environment configured with production-like credentials. To run that test properly, they need sign-off from the security team, who needs a ticket, who is waiting on the infrastructure team to provision the right access.

That chain takes two days minimum. The release window is tomorrow.

So the developer comments out the security test, ships the feature, and adds a note to come back to it later. That note never gets addressed. The test stays commented out through three more releases. Eventually someone on the team stops noticing it's missing at all.

This isn't a story about a reckless developer. It's a story about a process that made the wrong behavior easier than the right one. And it happens constantly — not because teams are careless, but because security testing was bolted onto the workflow as an afterthought rather than designed into it from the start.

The Cross-Functional Trap

Security checks, more than almost any other category of testing, tend to require things that live outside a developer's immediate control. Specific environment configurations. Credentials that are locked down for good reason. Tools that the security team manages separately from the main CI/CD pipeline. Scans that need to run against live infrastructure rather than mocked services.

That cross-functional dependency creates a kind of permission problem that slows everything down. The developer can't self-serve. They have to wait. And in a culture where shipping speed is the primary metric everyone gets measured on, waiting feels like failing.

The result is predictable: developers find workarounds. They mock out the environments that security tests need. They run a subset of checks and assume the rest would pass. They defer the full scan to "after launch" — a moment that, in practice, rarely arrives.

What This Actually Costs

The business math here is rough. A data breach in the US costs an average of over $9 million, according to IBM's annual Cost of a Data Breach report. That number doesn't include reputational damage, customer churn, or the engineering hours spent on incident response instead of building new features.

But the cost doesn't have to be that dramatic to be real. Consider the smaller-scale version: a vulnerability ships, a customer's data is exposed in a limited way, and your team spends three weeks in remediation mode. Three weeks of engineering time redirected from the roadmap. Three weeks of slowed velocity. A customer trust deficit that takes months to recover from.

All of it traceable back to a security test that got commented out because the approval process was too slow.

Breaking the Cycle Without Breaking the Pipeline

The goal isn't to make security tests harder to skip — it's to make them easier to run. That's a meaningful distinction. Enforcement-first approaches tend to generate resentment and workarounds. Friction-reduction approaches tend to generate adoption.

A few things actually move the needle:

Decouple security scans from blocking gates where possible. Not every security check needs to block a merge. Static analysis, dependency vulnerability scanning, and secrets detection can run in parallel and surface findings as warnings without stopping the pipeline cold. Save the hard blocks for the highest-severity issues, and let lower-priority findings flow into a review queue.

Give developers self-serve access to security test environments. The approval bottleneck often isn't intentional gatekeeping — it's just that nobody set up a path for developers to provision test environments themselves. Investing in infrastructure that lets engineers spin up isolated, security-configured environments on demand eliminates the waiting game entirely.

Shift the conversation from "did security tests pass" to "what did security tests find." When the only acceptable outcome is a clean pass, any finding becomes a blocker. When the expectation is that security tests will surface something and the team will triage accordingly, findings become information rather than emergencies. That reframe reduces the incentive to skip tests to avoid uncomfortable results.

Integrate security tooling into the developer's existing workflow. Asking a developer to log into a separate platform, run a separate scan, and interpret results in a separate dashboard adds cognitive overhead that compounds over time. Tools that surface security findings inside the IDE, inside the PR review, or inside the CI dashboard they're already watching get used. Tools that require context-switching get ignored.

The Culture Piece You Can't Automate

None of the above works without some degree of cultural buy-in. And that buy-in has to come from leadership, not just the security team.

When velocity is the only thing that gets celebrated, security debt accumulates invisibly. Teams ship fast and feel good about it right up until they don't. Building a culture where "we caught a vulnerability before it shipped" is treated as a win — not a delay — requires explicit, repeated reinforcement from people with organizational authority.

That means celebrating the catches. It means treating a sprint where the team ran full security coverage as a success even if it shipped slightly less. It means making sure that the engineers who do the right thing don't get penalized for it in performance reviews.

Start With One Test You've Been Skipping

Here's a practical challenge: identify one security check in your pipeline that's currently commented out, bypassed, or consistently marked as "skipped." Trace back why it got that way. Was it an environment access issue? An approval dependency? A tool that nobody maintained?

Fix that one thing. Get that one test running reliably. Then move to the next one.

Security coverage doesn't have to be an all-or-nothing overhaul. It compounds the same way technical debt does — just in the right direction when you're adding coverage instead of removing it.

The developers on your team aren't skipping security tests because they don't care. They're skipping them because the system made it easier to skip than to run. Change the system, and the behavior follows.