5 mistakes to avoid when building DevSecOps

Mistake #1: Forgetting that DevSecOps is a work culture

Let’s start with the big one: DevSecOps is, first and foremost, about changing your company culture to incorporate security into development. While having the right tools and frameworks is critical for success, the overriding aim (and requirement) is to make security an inherent part of software quality. Moving to DevSecOps means major changes to the way everyone works and collaborates, and companies that aren’t making these changes are likely to fail in their efforts.

“DevSecOps is a culture where everybody in the company is responsible for a high-quality product,” says Suha Akyuz, Senior Application Security Manager at Invicti. “Some companies see DevSecOps as a burden, as it means adding lots of technologies, tools, and frameworks with no universal standards or best practices to follow. In reality, the best practice for building DevSecOps will be different and unique for each organization. That’s why it needs to be part of a wider culture where Dev, Sec, Ops, and even other departments all work together to achieve the highest possible software quality in every respect, including security.”

Mistake #2: Trying to centralize DevSecOps

If an organization fails to recognize the need for a cultural shift as a prerequisite, it may attempt to implement DevSecOps through structural changes alone. Invicti’s Distinguished Architect Dan Murphy explains: “It is not uncommon to try to ‘solve’ DevSecOps by assigning a team or department to the role. However, the most successful implementations of DevSecOps recognize that it is more of a culture and a mindset. Development, security, and operations are melded together into single a cohesive role, ideally integrated at the team level.”

Attempts to implement DevSecOps through a top-down mandate without deep changes within teams are ultimately doomed to failure or superficial results at best. One example of this, says Murphy, is the failure to create a security champion program to train and empower a person on each development team to review sensitive code and implement security best practices. “All too often, DevSecOps is given lip service, but developers continue to write code as though deployment, maintenance, and security are someone else’s problem.”

Mistake #3: Building DevSecOps without accurate automation

Even with the right culture and talent in place, adding security testing and remediation to a highly automated DevOps pipeline will only work if you can match that level of automation. “If you try to shoehorn security into the process without investing in automation, a team may manually run security scans before a release,” Murphy explains. “This inevitably creates the tension between fixing or shipping, leading companies to knowingly release vulnerable code to hit externally communicated deadlines.”

Apart from compromising security in the short term, inadequate automation and integration also have a knock-on effect on the entire development process. Without the right tools to make testing and remediation an integral part of application development, issues will accumulate with no clear way to reduce the backlog. This is especially dangerous when trying to automate low-quality results that need time-consuming manual verification. “Failure to automate accurate security scanning as part of the CI/CD pipeline builds up security debt that tends to accrue over time,” warns Murphy.

Mistake #4: Failure to establish a continuous DevSecOps process

Application security should always be a continuous improvement process, both in terms of building more secure software and improving security testing and remediation itself. This is especially true when trying to build security into the pipeline. Suha Akyuz puts it bluntly: “If companies are scanning every three months, they are not doing DevSecOps. They need to monitor results constantly and improve their pipeline daily so that, in time, they will improve their  DevSecOps implementation.”

Even with a continuous security testing process in place, vulnerability management often falls by the wayside, again leading issues to pile up. “It is crucial to not only find security defects but also to handle them properly. Tooling alone is not enough to do this, so it is still important to have a security engineering team coordinate how tests are run and vulnerabilities are addressed all across the DevSecOps process. Having a continuous feedback loop is critical for preventing bottlenecks,” stresses Akyuz.

Mistake #5: Treating DevSecOps as a direct driver of revenue

Done right, DevSecOps allows organizations to finally catch up with their security backlog, treat security as part of software quality, and move towards improving that quality. In the face of revenue-driven decisions, it is all too easy to overlook this and treat the cost efficiencies of a DevSecOps program primarily as a way to improve the bottom line. Certainly, when compared with disjointed AppSec efforts that require disproportionate amounts of time, work, and money for any security improvement, the savings can be substantial – but these are a consequence of improving efficiency and quality, not the primary goal of the exercise.

Of course, that’s not to say that implementing DevSecOps brings no broader financial benefits. “DevSecOps itself does not provide a direct financial advantage. However, it does enable you to build more secure and better quality software faster with the same resources by changing your work culture,” Suha Akyuz points out. “In time, you may see financial benefits because you are saving so much time, but the direct benefit and purpose of DevSecOps is improved software security as part of better software quality overall.”

DevSecOps by any other name

There is no question that ensuring application security is now a non-negotiable requirement for any organization that builds its own software. With data breaches and malware infections skyrocketing, running vulnerable software can get extremely costly. DevSecOps is one way to bake security into the web development pipeline, and whatever acronym and process you choose, the important thing is to make it work continuously for your specific organization.

“DevSecOps is still a very young approach that needs time to mature. No company can say they know the one right way to do DevSecOps. We can talk about a general framework, but that does not mean everyone will use it in the same way,” sums up Suha Akyuz. “The overriding goal is to make security a process of continuous improvements to software quality.”

At Invicti, we believe that a mature platform for dynamic application security testing (DAST) is an essential component of any DevSecOps transformation. Read our white paper on application security best practices using a DAST-based approach that works in the real world.