8 big DevSecOps challenges and how to overcome them

Resistance may be futile, but it can sure hold things up. For many people, changing the way they work is hard, particularly if it requires a mindset shift from 'security as an afterthought' to ‘security-first'. You will undoubtedly face reluctance from some, but by installing ‘security champions’ in your teams, you can help dispel the myth that increased security stalls progress and thwarts creativity. 

Be prepared – bring people onboard early to develop new practices that work for everyone. It's all about educating staff across the organisation that code can be delivered rapidly and securely at the same time, encouraging teams to work together towards that united goal.

Research has shown that developers lack the formal security skills they need to carry out some DevSecOps practices. Without that knowledge, your DevSecOps implementation is going to struggle. Formal in-house training can raise awareness and give more experienced staff the opportunity to mentor others. But don't just rely on your own know-how – invest in self-paced online courses and specialist external training organisations to get everyone up to speed.

Many traditional security practices, such as conducting compliance checks, architectural risk analysis, threat modeling and risk management, involve security personnel running tests, reviewing findings, and then circling back to developers to make changes. This lengthy process is at odds with the speed of DevOps, but some of these practices are hard to automate, putting security and DevOps at odds with one another.

To overcome this time-consuming challenge, you’ll need to harness the power of DevSecOps tools to adapt standards, policies, models, and service-level agreements to make them more easily testable. 

For DevOps, speed of release is the number one priority. But security teams are focused on ensuring secure software through time-consuming practices, which aren't conducive for rapid release cycles. Resistance to adopting DevSecOps will come from the perceived incompatibility between security and DevOps. Quick feedback loops are also a vital component of DevSecOps to maintain traceability, find faults, and fix issues. But traditional methods and cultural resistance make these practices tricky to implement. 

By moving security practices earlier in the software development lifecycle (SDLC) – shifting left – developers can identify security issues early on, taking the pressure off security personnel and reducing the cost later in the process. And because you'll be improving your chance of finding vulnerabilities, teams should make use of security patch management to address them as soon as possible. 

While the use of tools is actively encouraged in DevSecOps, problems arise when there are differences in toolsets between security and other teams. With a lack of standards, documentation, and training, developers will find it hard to select from or even use the increasingly complex tools on offer. Not to mention the fact that integrating the tools they do choose into the DevOps pipeline can be hard and time-consuming.

Encourage your teams to develop tool standards and usage guidelines, making selection and usage easier, and to better document which tools are being used. This would help improve configuration management challenges and outline the recommended security settings for tools so everyone is on the same page, speeding up integration.

Security tools used for static application security testing (SAST) don’t support rapid deployment. These tools are important for detecting vulnerabilities early on, but they generate a lot of false positives (which need to be manually assessed) and take a long time to run. As a result, developers avoid using them.

On top of that, tools like containers, which are widely used, are seriously affected by vulnerabilities. This is even more of a threat when they’re containers embedded with third-party elements like code libraries. Developers are torn between using these existing components for speed and risking corrupting their code.

It might be worth considering making more of cloud services to avoid potential issues with standalone SAST tools. Meanwhile, a feature-rich orchestration platform might help to mitigate the problems with containers.

If you have a complex cloud environment, such as a system-of-systems (SoS), you might struggle to produce secure software at the pace DevSecOps demands. And if your infrastructure is a multi-cloud environment with microservices or automated distributed deployment infrastructure, then security assurance and data security will both pose big challenges. You should focus on data security alongside your SDLC, such as a SaaS security lifecycle to overcome these challenges.

If you’re operating in a highly regulated environment, it can be complex for DevSecOps adoption too. Features, such as zero-trust security architectures, restricted communication with stakeholders, and segregated environments all cause challenges when it comes to implementing continuous practices.

Regulations mean you'll have to be systematic and transparent in how you handle vulnerabilities, be design-aware in your risk assessment, and consider vulnerabilities in each software component individually.

When it comes to DevSecOps implementation, it’s clear there are a number of significant barriers your organisation will need to overcome – from people's perceptions to the limitations of the tools they use. Speak to our expert team to find out how we can help your organisation.