An interview with Paul Costall: The trends and future of DevSecOps
We sat down with the head of engineering at bp, Paul Costall, to discuss the emerging trends, challenges, and future of DevSecOps – from navigating the ever-shifting digital landscape to increasing flexibility and addressing digital compliance. Read more about his critical insights below.
In your time at bp, how have you seen the landscape of DevSecOps evolve?
The evolution has been significant. The initial focus was to seed the agile delivery methodology into the organisation, and start to incubate DevOps capability. It was quickly identified that to do DevOps at Enterprise scale repeatably, securely implementing DevSecOps enabled CI/CD pipelines was needed to provide service owners with the guide rails to deliver.
That evolution has resulted in close collaboration between Digital Security and our Engineering teams, a partnership accelerating our ability to build maturity. By implementing the security tooling into the pipelines, we capture issues long before they ever get close to production. Our focus now is taking the telemetry from the tooling that makes up the pipeline to derive insights into code quality, security, and velocity of delivery.
Can you tell us some of the emerging trends of DevSecOps?
DevSecOps is evolving to keep pace with the broader tools and techniques needed for modern organisations to succeed. I think we’ll continue to see an acceleration of applications being decomposed to Microservices for teams and businesses looking to release small incremental change safely into production daily.
We’ll continue to see organisations moving to the cloud, and are looking to leverage containers and serverless solutions to provide the elasticity and flexibility that these solutions offer. We’re seeing a rapid evolution in artificial intelligence and machine learning, which is shaping our approach to software development. If you play this forward to its natural conclusion, AI/ML will lead us to a world of NoOps.
We hear a lot about DevOps. But increasingly Enterprises need to focus on building their Site Reliability Engineering capabilities. DevOps teams need reliable, scalable, and robust platforms and SRE provides the focus to build these capabilities. The more infrastructure can be automated and self-healed the better for those looking to benefit from higher orders of maturity.
What do you feel are the key challenges and limitations currently facing the DevSecOps landscape?
The number of CI/CD and Security tools is bewildering. Creating flexibility and optionality whilst addressing digital security and compliance needs is the key to cracking DevSecOps. Being able to run different tools within the pipeline to address specific needs will help win hearts and minds. Teams will already be familiar and like certain tools. If you can create approved pipelines utilising these tools you will help encourage adoption.
Tooling is an emotive subject and being flexible and able to “hot swap” tools will help grow adoption. Equally, the tools we are using today may not be the tools we’ll want to use in 12- or 18-months’ time. DevSecOps is evolving at an incredible pace, so being able to change tooling in the future with the minimum of reengineering effort should be a primary consideration for anyone looking to build a DevSecOps pipeline.
How do you and your team counter these challenges and limitations?
It’s important to be flexible and embrace the breadth of the challenge. Start small and identify where you can maximize any investment to reduce risk and increase efficiencies. Make sure you build in optionality from day one as you will need to customize platforms to the specifics of the application and platforms involved. Understand that the DevSecOps pipelines will evolve and change over time, if they don’t, you’re doing something wrong. Reduce opportunities for technical debt and allow for tools to be hot-swappable as things evolve in the future.
Flexibility is key but you’ll need to agree on a common code repository and a small number of tools to operate the better. Opportunities to consolidate vendor engagements and maximize efficiencies of scale needs to be considered. It’s a balancing act driven by the specifics of your organisation.
Build on your successes by engaging with teams that are keen to partner and focused on building DevOps maturity. Celebrate your joint success and that will help attract critical mass to your DevSecOps pipelines.
What are your main considerations when implementing DevSecOps at bp?
Performing penetration testing just before releasing code into production is such an outdated and inefficient approach. In a world where we now have the technology to shift-left and identify vulnerabilities and defects at every stage of the development lifecycle, DevSecOps is an obvious step for an organisation that wants to embrace agile delivery and build DevOps maturity.
I see lots of enterprises struggling with how to perform DevOps safely at an enterprise scale. Bringing your digital security and engineering teams together to focus on DevSecOps provides an incredible opportunity to massively increase efficiencies and change the risk profile.
What have been your key takeaways from working in DevSecOps?
DevSecOps is the missing link for enterprises that want to do DevOps. It’s relatively easy to perform DevOps in a start-up, but once you layer on top the size and scale of your average Enterprise, along with regulation, compliance, and security considerations. DevSecOps is your guide to build maturity. The secret is to build pipelines that can accommodate and benefit teams at different maturity levels.
The other big takeaway I have found is in seeing the benefits of our digital security teams partnering with engineers. This is a community that has for too long been perceived as living in an ivory tower. Their knowledge and involvement in building out the automation are directly contributing to business success. Long may that partnership and involvement continue.
In your opinion, what is the future of DevSecOps?
In the short term, we need to see a standardisation of alerting across security tools. Today, issues highlighted in one tool may be categorized or reported differently compared to another. Once a team has addressed high criticality issues, it’s often difficult to see the wood for the trees. Teams become swamped with alerts and it’s possible to be overwhelmed with false positives. Security tooling needs to evolve and not assume that everyone is a security expert. Security should be everyone’s responsibility, but tools need to get better at helping users understand by using everyday language.
Data science is increasingly being applied to security and this will have an implication for DevSecOps in the coming years. I predict that in the next 5 years, Artificial Intelligence and Machine Learning (AI/ML) will be so aware of software and infrastructure components that it will have a huge impact. Security tooling will increasingly be more tightly integrated into the Developer experience, and we’ll see increasing applications of self-healing and auto-fix capabilities.
Is there anything else you would like to say about the DevSecOps landscape which you feel hasn’t been covered?
Every company will be a data company soon. Look around you and see how the world has accelerated to digital under the pandemic. For companies to survive and succeed in a world that’s changing so rapidly, they will need to embrace digital. As a result, we must focus on how we deliver code efficiently and safely. Organisations need to consider DevSecOps contributions to their digital transformations as a priority.