5 Warning Signs Your DevSecOps Implementation Is Failing You

Simon Saugier and Ben Mead

5 Warning Signs Your DevSecOps Implementation Is Failing You

Labored breathing. High blood pressure. Alternating feelings of rage and despair. Experiencing these symptoms when working through security reviews can be a sign that you may have implemented DevSecOps incorrectly.

DevSecOps is a collection of disciplines that seeks to incorporate security as a first-class concept throughout the DevOps lifecycle and thereby integrate it seamlessly and effectively into the other DevOps disciplines. However, implementing these processes incorrectly or incompletely can lead to frustration and negative outcomes, which can usually be tied back to a few different root causes.

Do any of these other symptoms listed below seem familiar?

Common Symptoms of Failing DevSecOps - Credera

Common Symptoms of DevSecOps Failure

Common symptoms of broken or missing DevSecOps include:

Blame and avoidance: The security team is blamed for slowing down projects, and project teams frequently "side-step" security.
Slow and ineffective security reviews: Security reviews of new applications take weeks and produce little actionable information.
Bad user experience: The user experience for authentication and authorization are awkward and inconsistent.
Unmanageable complexity: Your vulnerability list is overwhelmingly large, complex, and is growing rapidly.
Gaps in risk profile: Large parts of your technology portfolio have undiscovered security vulnerabilities.

DevSecOps Gap Diagnosis

These symptoms are indicators of gaps in your DevSecOps process. Such gaps often include:

Security involved too late: If your security team is reviewing an application for the first time right before the production launch, the most relevant architecture and implementation decisions have already been made. Any recommendations from the security team will appear to be "roadblocks," and the security team will be seen as "unhelpful." On top of that, with such a short time to review a net-new application under the pressure of an impending go-live date, the security team cannot possibly assess all aspects of every application, leading to unidentified security gaps and vulnerabilities.
No automation: Many DevSecOps security processes and scans are assisted by analytical tools. When these tools are not present or must be set up and run manually for the first time right before an application goes live, they are unlikely to yield many actionable results. Furthermore, the output from these tools is often overwhelming, and may never make it to the right person who can actually take action.
Reinventing the security wheel: Security solutions can be complex and have significant impacts on application architecture. When development teams must implement security patterns on their own, the solutions are often incomplete, disjointed, and require a large amount of developer time and energy without adding any perceived functional value. To make matters worse, when these solutions are implemented in a hurry right before go-live, they often have a negative impact on the user experience.
Misaligned teams: Dev teams are under pressure from stakeholders to deliver applications according to a project schedule, so they get permission from their stakeholders to file a security exception instead of implementing proper security controls.

Remediation Steps for DevSecOps Success

The following DevSecOps best practices address these issues and move your organization toward a healthy state where security is everyone's responsibility:

Embed security in dev teams: Reorganize dev teams to have a dedicated (although perhaps fractional) security team member/architect available to help with feature and system design decisions. Align team members on stakeholder objectives, and make security a first-class requirement for every application and every feature.
Automate security scans: Automating the execution and analysis of security scans allows them to be executed frequently, making incremental progress to reduce the list of known vulnerabilities. When scans are regularly run against multiple applications in the organization, patterns and best practices developed by one team can be applied to the same vulnerabilities that exist in other applications.
Create security standards and accelerators: Equip developers with reference implementations, approved product lists, approved architecture patterns, and recommended configurations for common security scenarios. This will help them quickly adopt security best practices at design time, ensure a consistent user experience, and create a uniform security posture which will greatly reduce the complexity of your security landscape.
Third-party opinion: It's often a good idea to get an outside perspective to help validate and refine your self-diagnosis and remediation plans. A third party may help you identify opportunities to tie into various compliance protocols (such as SOX, SOC, and FedRAMP), which can open your company up to new business and customers, while deepening trust with existing customers

A Healthy DevSecOps Operating Model

A healthy DevSecOps operating model embeds security team members into dev teams to help implement security scans and to include security considerations early in the design process. Security team members also serve as subject matter experts to help identify the correct patterns and reference implementations to fit each scenario and help ensure they are implemented correctly and efficiently.

Diagnose Your Own DevSecOps Symptoms

Are you experiencing any of these DevSecOps issues? Our security leaders have experience troubleshooting and transforming DevSecOps operating models. Reach out to start a conversation at security@credera.com.