Topic starter
25/06/2026 10:39 pm
TL;DR: 49% of enterprises were already integrating security into existing DevOps practices, according to DigiCert’s 2017 survey, while the report argues that security and development both improve when security is built into delivery workflows. The governance issue is not tooling alone but whether security is embedded early enough to shape change, ownership, and process design.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “New Report Gives Recommendations for Integrating Security into DevOps”.
Key questions
Q: How should security teams implement SecDevOps without slowing delivery?
A: Start with advisory controls, not blocking gates.
Q: Why do DevSecOps programmes fail when teams keep security knowledge siloed?
A: DevSecOps fails when security is treated as a specialist function instead of a shared practice.
Q: What are the signs that security is being treated as an afterthought in DevOps?
A: Common signs include security teams arriving only near deployment, repeated delays caused by late findings, hardcoded credentials slipping into code, and infrastructure changes shipping without policy checks.
Practitioner guidance
- Appoint a delivery security owner Assign one accountable leader for how security requirements enter DevOps workflow design, exception handling and release standards.
- Embed security leads in pipeline design Require security representation in every material DevOps initiative so identity, approval and control requirements are set before rollout.
- Standardise identity and release controls Use the same approach for secrets handling, approvals and change promotion across teams so controls are repeatable and auditable.
Bottom line: The article’s central point is that DevOps security succeeds or fails as a governance design choice, not a tooling purchase.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
25/06/2026 11:16 pm
Security-in-DevOps is a governance design problem before it is a tooling problem: the article is really about where control ownership lives in the delivery model. If security decisions are made after pipeline design, they arrive too late to shape release behaviour. The practitioner conclusion is that identity and security governance must be embedded in the process architecture, not appended to it.
A question worth separating out:
Q: Who is accountable for security in a DevSecOps model?
A: Accountability should be shared, but not vague. Engineering owns implementation, security owns policy and assurance, and operations owns runtime consistency. The important part is that responsibilities are explicit for each control, because shared ownership fails when no one is responsible for fixing the finding.
👉 Read our full editorial: Integrating security into DevOps remains a governance problem
This post was modified 4 days ago by NHI Mgmt Group