Introduction: Did Adding “Sec” to DevOps Actually Work?
“Let’s integrate security into DevOps and call it DevSecOps.”
“Let’s shift security left and start checking earlier in development.”
These ideas sound simple in theory. But in reality, what often happens inside organizations looks more like a cold war between development and security teams.
- Developers: “Security checks slow down our releases. And half the findings are false positives.”
- Security teams: “Developers underestimate risks. Shipping software with vulnerabilities is unacceptable.”
In my career, I’ve supported many organizations transitioning to DevSecOps as a delivery engineer at a global security vendor.
I’ve worked with teams across a wide range of environments—from web services to embedded systems.
One pattern I’ve consistently seen is this:
Teams adopt the tools and build the pipeline structure, but the culture needed to make DevSecOps work never catches up.
In this article, instead of explaining tool configurations, I’d like to share a practical, field-level perspective on what actually makes DevSecOps succeed, based on real-world experience.
1. Dev, Ops, and Sec: Different Goals, Same Pipeline
DevSecOps is supposed to integrate traditionally separate roles.
But in practice, each team often still optimizes for completely different KPIs.
Dev (Development)
Wants to build features, change things, and release quickly.
KPI: Release frequency, lead timeOps (Operations)
Wants stability and predictability. Ideally nothing breaks at 2 AM.
KPI: Uptime, MTTRSec (Security)
Wants to eliminate risk and verify everything before release.
KPI: Vulnerability counts, compliance
Security teams historically acted as gatekeepers, often blocking releases right before deployment.
When security becomes part of the development pipeline, it’s easy for them to be perceived as “the brake pedal.”
If you introduce CI/CD tools while this tension still exists, automation doesn’t solve the conflict—it simply accelerates it.
Successful teams do something different first.
Before tools, they establish a shared language:
Where should we balance speed of delivery and acceptable risk for our product?
Without that agreement, DevSecOps pipelines tend to become battlegrounds rather than collaboration systems.
2. Abandon the “One-Size-Fits-All” DevSecOps Model
Many teams assume there’s a standard DevSecOps template they should follow.
In reality, security priorities depend heavily on the nature of the product.
Web / Cloud-Native Applications
In web services, a large portion of the codebase often comes from open-source dependencies.
Because of this, SCA (Software Composition Analysis) tools are extremely valuable for detecting vulnerabilities in third-party libraries.
Another important factor is that web services can usually be patched and redeployed quickly.
This makes a culture of “detect early and fix fast” more practical than “block everything until it’s perfect.”
SAST tools are still useful for catching issues like XSS or injection vulnerabilities, but many of these problems are also caught through code reviews.
Embedded Systems and IoT (C/C++)
In contrast, the manufacturing environments I’ve worked with operate under very different constraints.
Firmware written in C or C++ is much harder to update after release.
Even when OTA updates exist, they carry significant operational risks.
Just think about automotive recalls.
In these environments, building security into the product before release becomes critical.
Here, priorities often shift toward:
- SAST (Static Analysis)
- Memory safety
- Preventing low-level vulnerabilities early in development
Speed matters less than engineering quality into the product upfront.
Instead of copying the practices of companies like Google or Netflix, teams need to ask:
What level of risk is acceptable for our product?
That said, creating completely custom internal rules can also be dangerous.
A good starting point is usually to adopt vendor or industry best practices first, and then adapt them to your environment.
3. The Missing Piece: The “Translator”
Sometimes organizations already have:
- Expensive security tools
- Skilled engineers
- Automated pipelines
And yet DevSecOps still doesn’t work.
One common reason is the absence of a translator between security and development.
Someone needs to translate:
- Security reports filled with technical terminology → into actionable development tasks
And also translate:
- Development’s release pressure and deadlines → into realistic security triage and prioritization
This role requires engineers who can move beyond narrow specialization.
When teams operate in silos—
- “I’m in security, I don’t know how to fix the code.”
- “I’m a developer, security isn’t my responsibility.”
—the DevSecOps pipeline eventually stalls.
In recent years, developers are increasingly expected to understand security principles.
At the same time, security engineers are being asked to understand code and development workflows more deeply.
What modern engineering teams need isn’t just deep specialization.
They also need people willing to step into adjacent domains and help bridge the gaps.
Sometimes the most valuable skill is simply being curious—and a little bit nosy—about problems outside your official role.
4. The Real Meaning of “Shift Left”
“Shift Left” is often misunderstood.
It does not mean pushing security work onto developers.
A better interpretation is this:
Make security issues naturally visible earlier in the development process, when fixing them is still cheap.
For example:
- Seeing a potential buffer overflow while writing code in the IDE
- Discovering a license issue in a dependency the moment a pull request is opened
If shift-left doesn’t happen, especially in manufacturing environments, the consequences can be severe.
Production schedules are fixed.
Parts have already been procured.
Release dates are announced.
Security evaluation then happens at the last minute.
If vulnerabilities are discovered, there’s often no time left to fix and retest.
In those situations, it’s easy to imagine security being quietly deprioritized.
Developers don’t need to become security experts.
The real goal of DevSecOps is to create an environment where:
Security quality emerges naturally as part of the development workflow.
Closing Thoughts
DevSecOps isn’t something you simply install.
It’s something you cultivate.
Adopting new tools is valuable, but the more important step is having conversations inside your team:
- Why is this security check necessary?
- Is it creating unnecessary friction for developers?
- What level of risk are we willing to accept?
DevSecOps starts not with pipelines, but with shared understanding.
Top comments (0)