SecDevOps vs DevSecOps: The Path to Transformation

What Is SecDevOps?

SecDevOps vs DevSecOps. It might sound like semantics, but the order of words carries all the weight. How do we culturally shift the way we address security? We start by treating it with the gravity it deserves and start building it in, at the very beginning.

There’s no doubt that DevOps and security are top-of-mind for software and business IT organizations, and the result of integrating security into DevOps has been the introduction of the terms SecDevOps and DevSecOps. The result of integrating security into DevOps has been coined as SecDevOps and DevSecOps.

Although used interchangeably, SecDevOps vs DevSecOps is comparing two radically different things. Why? Because the order of the words is important. In most cases, security is still being “tacked on” at the end of the deployment process.

In this post, I’ll discuss why the distinction between DevSecOps vs SecDevOps is crucial for the security of your applications. I will also touch on how delivering secure software is easier to achieve when security is an integral part of development, from the start of the software development process rather than as a gate at the end of the delivery pipeline.

What Security Looks Like in DevSecOps

Despite the increased focus on security, it’s challenging for software teams to build security into a process and pipeline. The pressure to complete projects on time and within budgets often overrules other considerations. As a result, security integration tends to be seen as the last gating step for a release candidate, as illustrated below:

As security knowledge is typically scarce, and limited to a few individuals in an organization, these individuals are often grouped into a centralized security team. The security team is tasked to test the product using their “magic box of tricks” to find vulnerabilities in the release candidate before deployment. When the team, inevitability, finds a vulnerability, they pass the “bad news” back to the development team. However, because the development team doesn’t have the security training or knowledge about how to use the tools that the security team is using, the security team is often seen as “bad guys” because they are now holding up the release because of “some security vulnerabilities.” So what’s the typical reaction of the team?

The traditional approach leads to delayed release and/or security vulnerabilities in production.

Let’s face it, it’s tough to get important security fixes, controls, and coding standards into a project that’s “done and dusted” as far as the development team is concerned. So what happens? The product goes out the door with known, and unknown, security vulnerabilities with possibly some promise to “fix or change them in the next release.” This is what you get when you put security after development – “Dev” then “Sec” then “Ops.” While this isn’t the intention, this is the reality in many organizations. Consider a better approach described below.

What Security Looks Like With SecDevOps

Security controls, guidelines, coding standards, and best practices must be integrated completely into the software development process. This is done by including security from the beginning: “Sec” then “Dev” then “Ops.” The security team (or perhaps an architecture or senior developer specialized in security) defines the necessary policies upfront for the team.

These policies might consist of secure coding standards, rules for avoiding insecure APIs and poor encryption, instructions for using static and dynamic analysis, and testing guidelines. The goal is to have the developers working towards more secure software as part of their daily routine and automation helps make this a reality.

With automation, you can shift left your approach to security for a SecDevOps strategy that looks something like this:

As security is now baked in at the start of development, the team will naturally become more proficient in security and fewer security vulnerabilities will be found at the end of the pipeline.

The vulnerabilities that do make it through can then be investigated and the results of root cause analysis used to improve on the security policies and guidelines – essentially improving the outcome as each cycle progresses.

Driving iterative improvements to the policy results in less disruptive late-cycle escalations, and looks like this:

When you compare SecDevOps vs DevSecOps, the incremental and integrated approach of the former works much better than trying to tack on a security audit at the end of the project.

How to Transform DevSecOps to SecDevOps?

There’s no way around the fact that security adds an additional requirement for developers, but how you manage the impact of this work is what makes the difference between an on-time, secure product, and a late, insecure one. A critical requirement is to integrate security into the existing development process, which you can do by integrating Parasoft’s suite of CWE-compatible testing tools to make security a part of quality and the overall operations workflow.

Make Security Part of Quality With a Security-Focused Workflow

The workflow starts with the secure coding policy. The Architect or Lead creates a configuration (possibly based on coding guidelines such as CERT, CWE, OWASP, UL-2900, or PCI DSS) for the rest of the team to leverage directly within their IDE. This gives the developer the ability to check the code locally on their machine before committing to source control – catching and fixing security violations where and when it’s cheaper and easier to do so.

The same configuration is then leveraged by analysis executed as part of the build process. This comprehensive analysis goes beyond the scope of the developer’s locally modified code and provides a safety net to gate the delivery pipeline to ensure that insecure code does not get promoted to later stages.

Lastly, the results of the analysis are sent back to the developer’s IDE via the centralized reporting and analytics dashboard, where progress can be tracked, course corrections made, and audit reports generated in real time.

The full SecDevOps workflow looks like this:

Managers and security leads can now assess projects based on security standards such as CWE, in the central dashboard as shown below:

These dashboards enable comprehensive monitoring, and can show trending information to help answer questions, such as, “Is the project improving or getting worse?” or “Which areas of the code are causing the most issues?”

Being able to answer these and other questions, and take action, transforms the development team from DevSecOps to SecDevOps.

DevSecOps vs SecDevOps: Prioritizing Security in Development

Despite the interchangeable use of DevSecOps and SecDevOps, the order of the words is just as important as the implications of the tools, techniques, and processes the word implies. Security is often left as an add-on or a gating process before releasing a product, but it’s difficult to fix security issues when a product is halfway out the door.

Shifting security to the left, as in SecDevOps, is the key to success. Security must be part of each developer’s day-to-day workflow and integrated into the software pipeline. Parasoft’s automated security controls and policies build security into the pipeline while reducing the impact and risk of either SecDevOps or DevSecOps.