7 DevSecOps myths and how to overcome them

DevOps and security teams have long been at odds with each other over the software delivery pipeline. DevOps teams have historically viewed security teams as the “release prevention department” with overly conservative approaches to risk mitigation. Meanwhile, security teams think accelerated software releases pose too great a risk to governance, security and regulatory controls. To reconcile the two, many organizations have tried to shift security and compliance left by implementing measures earlier in the development process.

While this limited DevSecOps approach does improve the quality and delivery of the software, it doesn’t solve the whole problem. Forward-thinking enterprises have realized that it’s not enough to shift security and compliance left; they need to shift them everywhere.

By including security and compliance processes in end-to-end automation, businesses can secure software throughout the whole software supply chain, significantly improve the developer experience, and accelerate safer delivery. To achieve this, enterprises need to overcome these seven common DevSecOps myths that are preventing them from making the shift.

7 DevSecOps myths

Myth 1: Security and compliance are a single point in the software delivery process.
Reality: Security and compliance are most effective when they are continuous throughout the entire pipeline. Companies who treat security and compliance as events, often have to pull entire development teams away from value-creating activities for periods throughout the year to manage audit requirements. This approach significantly increases a company’s “compliance tax.” If security isn’t baked in from the beginning, security teams spend more time going back and fixing issues – time that adds no productive value to the organization.

Myth 2: Adding more tools will help solve security and compliance challenges.
Reality: While tools can certainly help with security and compliance, single solutions generally won’t solve the big-picture problem. More people are typically needed to operate the tools and analyze the results. Development managers then must consume the results and prioritize actions for developers. While more tools can help, more tools can also just mean increased complexity. Finding a single, comprehensive solution, rather than a set of tools, will be more effective and create fewer potential points of failure by giving a holistic view of a company’s security and risk posture.

Myth 3: Training developers to be security and compliance experts will prevent noncompliance.
Reality: Your developers probably want to innovate, not run tests or decode regulatory frameworks. Developers should absolutely be concerned about security – we’re here saying security is everyone’s problem – but expecting development teams to handle security in addition to their job description is a good way to stifle innovation and breed resentment.

Myth 4: Embedding security experts in DevOps teams will address the challenge.
Reality: Having a dedicated security expert inside the development silo can be helpful in freeing developers to innovate. However, this approach can still cause interruptions to developers and deepen the rift between the two teams.

Myth 5: My company is too small or obscure to be the target of a cyber-attack.
Reality: The average cost of a data breach to a company is in the millions and rising rapidly. No business should feel comfortable gambling with that kind of profit. Every business – all sizes and industries – is at risk and needs to take security seriously.

Myth 6: If I automate, I am secure and compliant.
Reality: Automation is key to security and compliance – but many automation tools are point-in-process solutions, rather than end-to-end automation. If you deploy tools to automate single points of your pipeline, those parts will be more secure. But if you deploy tools to automate your entire pipeline, your entire pipeline will be more secure.

Myth 7: Embracing DevSecOps is enough.
Reality: It takes more than just overhauling your software delivery pipeline to resolve the silos between development and security teams. The culture throughout your organization needs to be overhauled, too. Yes, security needs to be everyone’s concern; but innovation and productivity need to be a priority across all teams, too.

End-to-end security

Shifting security everywhere through an end-to-end software delivery solution allows you to bake in security from the beginning, and throughout the entire pipeline. Gone will be the days of month-long security audits that halt development and productivity. Advanced DevSecOps enables automated security and compliance testing while enforcing the use of approved components.

End-to-end automation limits the introduction of security flaws due to human error, and if something does break it’s easier to find and fix the problem before compromised code is delivered. Access controls are automated to manage who can make changes and when – ensuring no one accidentally changes critical components without being noticed.

Eliminate silos through shared pipeline

With a shared pipeline platform that spans development, QA, and operations, organizations have advanced control and visibility over the entire system’s development process. Security, development and operations teams gain a shared holistic understanding of the entire digital estate, enabling them to innovate with an informed perspective.

A shared pipeline helps catch problem code pre-release. Rather than fixing vulnerabilities post-delivery, incremental fixes can be deployed to address issues as they arise. More visibility means a better understanding of the pipeline for everyone, which in turn improves communication and helps eliminate blame.

Enable progressive delivery

An end-to-end software delivery solution allows progressive delivery of your software to accelerate safe and secure releases. Progressive delivery introduces new code on a rolling basis, rather than via “big bang” releases. This approach mitigates risk by testing code on a small scale with the ability to rapidly roll back any problem code that arises (feature management). Progressive delivery turns a software release into a gradual low-risk process with trusted governance and provides an “enterprise kill switch” should something serious happen in production.

Progressive delivery also gives developers more freedom to innovate. In the low-risk software release environment, they can experiment more with less risk, and on a more flexible timeline. Dev teams need the space to create; InfoSec needs security and governance. An end-to-end software pipeline satisfies both – which manifests by getting products to market faster.