Laura Bell Main, author of Agile Application Security and founder of SafeStack, recently presented a webinar titled Decoding Dev Culture 2024, in which she provided a "from the ground view" of security in 2024. Drawing from her experience, and a 12-month SafeStack survey, Bell discussed the need for DevSecOps practioners to move away from an overfocus on SAST and other tooling. She advocated for a better understanding of the developer experience associated with security processes and tooling. Bell explained that effective security ownership can be encouraged through improved communication, and positively impacting engineer productivity.
Praising DevSecOps for its aim to unite development, security, and operations into "fullstack-capable" teams with a "shared sense of purpose," Bell also highlighted a concerning trend. She noted a shift toward siloing of DevSecOps capabilities. According to Bell, in practice, DevSecOps is often segregated into dedicated or SRE teams, detached from the delivery teams. This segregation, she explained, stems from cultural and operational challenges, such as security initiatives that are tightly coupled to CI/CD tooling, rather than the development teams running those pipelines.
Nikki Robinson, author of Effective Vulnerability Management, gave a talk at DevOps Summit Canada last November, titled Where Platform Engineering and Security Meet. Robinson discussed the discipline of "platform security engineering," as the practice of supporting developers in securing complex systems by treating the engineering teams as customers. She discussed the importance of taking a developer experience targeted approach to not just tooling, but also processes and collaboration models. Robinson said:
If teams don't... bring ideas to each other and talk to each other about what's really going on, it's really difficult for platform engineering to succeed, because we need to understand what the developer experience is… It's the same with that transition from DevOps to DevSecOps, or integrating security somewhere in the pipeline, so that it's at the end, right before the system is getting ready to go to production. The idea is that security can be integrated as a team member, or a function of the platform engineering team, to help build a really great experience for developers.
Similarly, Bell explained that contrary to the DevSecOps goal of "combining development, security and operations together," she was now seeing a repeat of historic patterns when security was "adopted into operations." Explaining the tensions which lead to this situation, she elaborated:
We have cultural and operational challenges that are causing this repeat in the cycle. So for a start things like our security initiatives are being very tightly coupled to our CI/CD pipelines… this means that the people who manage those pipelines, who configure them, but not necessarily run them, are often the people who are the only ones touching the security tools. So if you've got this case, then you start to isolate your security initiatives away from your active development teams.
Bell observed that instead of focusing solely on DevSecOps, development teams are now prioritising their own engineering productivity. To ensure security remains a priority, she suggested strategies like reducing developer cognitive load through early visibility of upcoming security initiatives, improving tooling to reduce toil, controlling false alarms, and minimising factors which constrain autonomy, such as approval bottlenecks. SafeStack’s ongoing application security survey showed that most companies have 1 application security professional for every 50 to 100 developers, highlighting the risk of such bottlenecks.
SafeStack survey on the ratio of dev to security professionals. (Source: SafeStack: Decoding Dev Culture 2024 - A Security Leadership Perspective)
Furthermore, Bell stressed the importance of security specialists being mindful of any additional friction they may introduce to engineering teams. Instead of exacerbating existing challenges, she advocated for approaches that facilitate adoption of improvements and accelerate development processes. She said:
… our developers are hurting and we need to support them more than ever. They have a lot to do. They have less people and less budget than they ever had. The solution is not to buy more tools, but to look at what we've already asked them to do, the friction that it's causing, and the impact on their world. If you are able to make improvements to reduce developer toil and improve productivity, then you're going to make a lot of friends and make a cultural change that no tool can do on its own.
Robinson also encouraged platform security engineering teams to invest in building relations and communicating with team members. She emphasised the importance of understanding the friction and challenges of security practices in order to better optimise for tools and processes supportive of individual and team context. She said:
I think that the people aspect, the relationship building aspect, the unconscious bias aspect of all of those pieces are just as important as building the technical infrastructure in a specific way. So understand how the developers are using the environment. How can security best integrate with them? What timelines work for people?
By prioritising the reduction of developer toil and fostering a culture of continuous improvement, organisations can drive meaningful change and ensure the holistic security of their software infrastructure. Bell, who recently hosted the Securing Modern Software track at QCon London and guides thousands of organisations on their security journeys, closed her webinar by urging security leaders to support development teams in not just managing new systems, but also ensuring the security of legacy applications. She said:
… know the following: legacy and foundation systems run the Internet. It's not just our new stuff. Our development teams know this, and they worry about those old systems but they're only given time and resources to work on the new stuff. As security leaders it's our job to make sure software development teams are given the time and support to look after all of the software we build and maintain, not just the new stuff.