The traditional framing of security versus velocity is wrong. It assumes security is inherently friction-generating. Twenty years of running QIT Solutions has taught me the opposite. The teams I see ship the most code per quarter are usually also the teams with the cleanest security posture. Not in spite of security, because of how they implement it.

The teams that ship slow are not slow because they take security seriously. They are slow because they treat security as gatekeeping. Those are different things, and conflating them is how organizations end up with both worse security and worse velocity at the same time.

The friction fallacy

Most security friction comes from bolted-on processes, not from security itself. Manual code reviews that take three days. Change advisory boards that meet weekly and reject deploys for missing fields on a form nobody reads. Quarterly access reviews where 200 people get an email asking if Jane still needs prod access, and 199 of them click "yes" without reading.

None of that is security. It is process debt masquerading as security. The clearest tell is when you ask the people enforcing the process why a particular control exists. If the answer is "compliance" or "we have always done it this way" or "the auditor wants it," you are looking at friction without the security benefit.

Real security controls do work. They prevent specific failure modes that the team understands. The friction-generating ones almost always exist to make someone feel safer rather than to actually be safer. Telling these apart is the first move of any security-first culture.

What security-first actually looks like

Three things distinguish the engineering organizations that get this right from the ones that talk about getting this right. None of them are tools.

1. Automated guardrails, not human gates

Security checks run in the CI/CD pipeline, not in a meeting. Static analysis on every commit. Dependency scanning on every PR. Secrets scanning before code lands. IaC policy checks before infrastructure deploys. Container image scanning before anything reaches production.

The guardrail principle is that security finds the problem at the moment of introduction, when the cost of fixing it is near zero. By the time a security review finds the same vulnerability two weeks later in a CAB meeting, fixing it costs the engineer's full context-recovery time plus a re-deploy plus possibly customer-facing comms about the delay. Push detection left enough and a lot of "security incidents" become "the build failed and we fixed it before lunch."

Worth distinguishing this from the trendier "shift left" or "DevSecOps" framing. Both are useful labels, but the actual pattern is more specific: replace human-judgment gates with deterministic checks where you can, keep the human-judgment ones small enough that they do not block flow.

2. Paved roads with secure defaults

The single highest-leverage thing a security-mature organization does is make the secure choice the easy choice. A platform team builds a paved road for how services get deployed: the standard template comes pre-configured with TLS, secret management, IAM least-privilege, structured logging, and the rest of the basics. Choosing the secure path requires zero extra work. Choosing an insecure path requires deliberately stepping off the road.

Compare this to the alternative, which is what most organizations actually run: every team rolls its own deployment pipeline, every team makes its own IAM policy choices, every team rediscovers how to handle secrets. The aggregate engineering hours wasted on solving the same problem 30 times exceed the cost of the platform team that would have built the paved road.

The economics get clearer at scale. A company with 200 engineers and no paved roads has 200 different security postures, which means 200 different attack surfaces and 200 different incident-response playbooks. A company with 200 engineers and a paved road has one well-tested security posture and 200 engineers focused on the actual product. That is not a small productivity difference.

3. Shared ownership, not a security team

The security-mature organizations I see do not have a "security team" that owns security. They have a security platform team that builds the guardrails, and every product engineer owns the security implications of their own code. When someone introduces a SQL injection vulnerability, the fix is owned by the team that wrote the bad query. When someone misconfigures an S3 bucket, the fix is owned by the team that deployed it.

This is harder than it sounds because most engineering managers want to make security "someone else's problem". That is the default human response to a hard topic. The shared-ownership model requires real investment. Every engineer goes through threat-modeling training, every team includes security as a first-class concern in design reviews, every postmortem treats security incidents as engineering incidents (not as an indictment of one team).

The payoff is that security stops being a phase. It becomes the way the engineering organization operates by default.

How to tell if you are actually security-first

Most organizations think they have a security culture. Few actually do. Here are the diagnostics I run when I evaluate a client's security posture:

How long does it take a new engineer to make their first secure deployment to production? If the answer is more than two weeks, your paved road is not paved. If the answer is "they cannot, only senior engineers deploy to prod," you have a process problem, not a security one.

What percentage of security findings are caught before code review? Mature orgs catch 70%+ of issues in CI before any human looks at the diff. If your security team is finding bugs at code review or in production, your guardrails are insufficient.

When was the last security incident, and who was in the postmortem? If the security team led it and product engineers attended as audience, you do not have shared ownership. If the engineering team that wrote the vulnerable code led the postmortem and the security team consulted, you do.

Can engineers explain why each security control exists? Pick three random controls and ask three random engineers. If they cannot articulate the failure mode each control prevents, the controls are theater. Theater controls drift toward dropped, ignored, or worked-around over time.

What happens when a security tool blocks a deploy? The healthy answer: the engineer fixes the issue and re-deploys, usually within an hour. The unhealthy answer: the engineer files a ticket to bypass the tool because the deploy is blocking a release. If you see the unhealthy pattern, your tools are tuned wrong (false positive rate too high) or your culture rewards shipping over security.

The leadership actions that actually matter

Most "build a security culture" advice is generic. Write a security policy, run training, hire a CISO. That is mostly downstream of one decision: are you willing to make security a real budget line on the engineering platform team, or are you going to outsource it to a separate security org with no engineering authority?

The organizations that get this right invest in security platform capability the same way they invest in CI/CD platform capability. Real engineering hours, real ownership, real authority to set defaults. Not a compliance team running scans from outside.

The other leadership decision that matters: the org chart. If your security team reports to the CIO and engineering reports to the CTO, you have created two organizations that compete for engineering hours. They will lose. The orgs I see succeed have security platform reporting into engineering. The head of security is one of the engineering directors, not a separate VP. That structure makes the trade-offs explicit and forces them to be made by one person rather than negotiated between two.

For the broader executive context, the patterns in the executive framework for responsible AI adoption apply equally to security. Both topics suffer from the same anti-pattern: the function gets walled off into a side org and then fails to influence the core engineering decisions.

Where this breaks down

Security-first cultures are real, and they work, but the model has limits. It works best in product engineering organizations where you have control over the development pipeline and can mandate the paved road. It works less well in:

None of these are fatal. They just mean security-first culture is one piece of an overall security posture, not the whole thing.

The honest version

Building a security-first culture without slowing down engineering is harder than the conference-talk version makes it sound. It requires real platform investment, a willingness to delete process that does not earn its keep, and an org structure that does not pit security against engineering.

But the alternative (security as gatekeeping) is worse on both axes. Worse security because the gates are easy to game and bypass. Worse engineering because the gates create friction without proportional benefit. The choice is not between security and velocity. It is between two ways of organizing security: one that compounds with engineering velocity, and one that fights it.

The teams that pick the first one ship more code, get fewer incidents, and have happier engineers. They are also rarer than they should be, because the first version of any organization tends to grow security as an afterthought and then add gates as the costs of that decision become visible. Refactoring a gatekeeping security culture into a guardrail one is hard work, but it is one of the highest-leverage things a CTO can do.

Frequently asked questions

What is shift-left security?

Shift-left security means moving security checks earlier in the development lifecycle, ideally to the point where code is written or committed. Catching a vulnerability in CI before code review is dramatically cheaper than catching it in QA, which is dramatically cheaper than catching it in production. Shift-left is one tactic of a broader security-first culture, not the whole thing.

What is the difference between DevSecOps and a security-first culture?

DevSecOps is a practice that integrates security into the DevOps lifecycle through automation. A security-first culture is the organizational and cultural conditions under which DevSecOps actually works: shared ownership, paved roads, automated guardrails, and leadership investment in security as engineering work. You can do DevSecOps without a security-first culture, but it tends to fall apart because the culture does not reinforce the practice.

How do I measure security without slowing down engineering?

Two metrics matter. First, percentage of security issues caught in CI vs in production. Higher is better, target above 70%. Second, mean time to remediation when an issue is found. Lower is better, target hours not weeks. If both are improving over quarters, your security culture is healthy. If you have to add manual review steps to push numbers, you are gaming the metric, not improving security.

Who should own security in an engineering org?

The platform team owns security tooling and paved roads. Each product team owns the security of their own code. The security platform leadership reports into engineering, not as a separate org. This matches the model that works for site reliability and observability. Same pattern, different domain.

Can small teams build a security-first culture?

Yes, and arguably easier than large teams. With 5-10 engineers, every engineer is part of the platform team by default, and the paved road is mostly a documented set of conventions. The challenge at small scale is resisting the temptation to skip security work because the surface area feels small. The teams I see hit security walls hardest are the ones that grow from 10 to 50 engineers without ever investing in platform capability.

About the author

Jess Coburn runs QIT Solutions, a managed services firm that has handled IT operations, security, and infrastructure for hundreds of small and mid-sized businesses since 2002. He writes about practical IT operations, security trade-offs that compound, and where engineering culture actually meets the threat model. More posts on engineering and security strategy live on the blog, and you can find him on LinkedIn.