Notifications
Clear all
Topic starter
02/08/2026 12:08 pm
TL;DR: DevSecOps adoption still breaks down around tool sprawl, automation friction, alert overload, third-party code risk, and weak governance, according to Veracode. The hard part is not adding more checks but making security feedback actionable, measurable, and embedded in SDLC workflows before debt and compliance gaps accumulate.
NHIMG editorial — based on content published by Veracode: Top 10 Challenges in DevSecOps Adoption
Questions worth separating out
Q: What breaks when security is added too late in a DevSecOps pipeline?
A: When security is added after development work is mostly complete, teams usually find secrets exposure, privilege issues, and configuration errors only at release time.
Q: Why do third-party dependencies complicate DevSecOps adoption?
A: Third-party code expands trust beyond what the engineering team directly builds, so security must account for packages, updates, and transitive risk that arrive outside normal release ownership.
Q: How do you know if DevSecOps automation is actually helping?
A: Automation is working when it reduces manual triage, shortens remediation time, and produces consistent results without forcing developers to bypass controls.
Practitioner guidance
- Implement a single remediation workflow Map findings from code scanning, dependency analysis, and compliance checks into one triage process so teams do not resolve the same issue in multiple tools.
- Harden pipeline identity and permissions Review CI/CD service accounts, tokens, and deployment credentials for least privilege, short-lived scope, and clear ownership.
- Tune security automation for developer workflows Validate that scans run within acceptable build times, produce consistent results across environments, and suppress duplicate or low-value findings.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- The article expands the full list of 10 DevSecOps adoption barriers and how they show up in day-to-day programmes.
- It outlines the specific operational issues behind tool sprawl, automation bottlenecks, and developer alert fatigue.
- It describes how governance, compliance reporting, and executive buy-in influence DevSecOps adoption.
- It closes with the article's recommended adoption approach and ebook offer for practitioners who want a broader playbook.
👉 Read Veracode's guide to the top 10 DevSecOps adoption challenges →
DevSecOps adoption: what practitioners need to fix first?
Explore further
02/08/2026 1:12 pm
DevSecOps adoption is really a control-integration problem, not a tooling problem. The article’s challenge list shows that organisations usually have some security capability already, but it is fragmented across development, operations, and compliance workflows. That fragmentation weakens enforcement, slows remediation, and creates inconsistent decisions across environments. For practitioners, the issue is whether controls can survive the pace of delivery.
A question worth separating out:
Q: Who is accountable when compliance checks are embedded into the SDLC?
A: Accountability should sit with the teams that own the pipeline stage and the underlying control, not with a separate security function that only reviews outputs. Governance works best when engineering, security, and compliance share evidence, but ownership remains tied to the process that can actually change the result.
👉 Read our full editorial: DevSecOps adoption falters when tools, feedback, and governance drift
