Image source PeopleImages via Getty Images Signature
By Stephen M Dick, VP Cloud Engineering
I couldn’t believe it!
I was standing in line to pick up some soggy food served in plastic at SRECon in San Jose, pretending not to listen to a conversation happening directly behind me. The VPs of Engineering and Application Security from a small software company met in person for the first time, and the engineering leader seemed elated as he spoke about how they’ve enabled each other teams to excel. It’s a story I’ve heard across the industry: it’s not new tools helping companies unlock better security posture; it’s a new level of collaboration across teams, where security is becoming a shared responsibility.
From DevOps to DevSecOps: A Natural Evolution?
At the core of DevOps is better collaboration between teams. When teams share system-level outcomes, particularly improvements to software delivery, better business results follow. A natural extension of this model is to integrate security into the software development process, also known as DevSecOps.
In today’s fast-paced software development landscape, security has become an increasingly critical factor that cannot be ignored. News of the latest data leaks are now ubiquitous in our news feeds, and software security is now a matter of national security. DevSecOps has solved this challenge, integrating security into the software development process. However, despite the demand for DevSecOps, adoption in the industry lags, and companies of all sizes and maturities struggle with its implementation.
The Top Challenge in DevSecOps Implementation
Progress, a leading CI/CD provider, released an eye-opening report. Based on 606 in-depth interviews with software companies across the globe, they concluded that many DevSecOps projects have stalled while other projects are being ‘explored’ (read: we’re thinking about it).
Source: Progress Research Study: Simplifying Complexity in a Changing World
In recent months, almost all companies I’ve talked to share frustrations with what gets labeled as ‘company culture’, a generic, catch-all phrase used to describe team anti-patterns like silos, friction and a lack of cross-team collaboration that slows down DevSecOps adoption.
Interestingly, this observation fits the Progress research study, where 71% of the global firms surveyed see culture as the most significant barrier to DevSecOps progress.
We’re Encountering Problems Software Tools Alone Cannot Fix
With the DevSecOps market valued at around $23 billion, it’s no wonder we’re seeing increasing numbers of tooling vendors move to create solutions for this growing market. Spurred on by the White House’s memorandum to enhance the security of the software supply chain, we will likely see this market continue to grow over the next few years. Yet, the 2022 State of DevOps Report indicates the biggest predictor of successful security practices is not technical; it’s cultural – specifically having a high-trust culture.
The Cultural Impact of ‘Zero Trust’
Among the many security paradigms to emerge over the years, ‘Zero Trust’ has likely been one of the most influential. Defined by Gartner as “a security paradigm that explicitly identifies users and devices and grants them just the right amount of access so the business can operate with minimal friction while risks are reduced”. Put another way, Zero Trust policies assume all people and all systems pose risks, therefore system access and information sharing should be kept to the minimum.
But what happens when ‘Zero Trust’ policies bleed into organizational culture? A Zero Trust culture can grind work to a halt with additional security checks, change approval boards, added layers of approval, mistrust between teams, stymied communication and siloed teams. These things block flow, slow down business delivery and hamper the efforts of the best-intentioned engineer.
It’s a paradox. The threats can come from any system and any person. Yet, when we treat our people as potential threats, rather than enlist them as allies, we alienate those that can help prevent the security problems we want to prevent in the first place.
Zero Trust Policies, Enabled by High Trust Culture
How do we ensure Zero Trust policies and high trust culture can co-exist? Here are some ideas leaders in the software field can focus on to find the right balance:
- True shared outcomes
An old lesson we’ve learned in the DevOps movement is that teams need to share commonly held goals to ensure alignment. Too often, senior leaders can focus on their slice of the pie and fail to see their peers’ goals as equally important to the direction of the business. Like our friends standing in line at SRECon, until security leaders care as much about shipping good quality software as they do about security alignment will struggle, and outcomes will lag.
- Collaborative Leadership
DORA research (now centralized on dora.dev) shows that a high-trust, generative culture predicts software delivery outcomes. It’s been almost 20 years since Dr. Westrum’s released his findings on organizational culture outcomes; therefore it seems these lessons stand the test of time.
Collaborative leadership emphasizes cooperation, teamwork, and communication, where everyone is encouraged to contribute to the organization’s success. In a collaborative environment, leaders facilitate work between team members and encourage everyone to progress toward common goals.
Yet, in many organizations, software development, security, and operations teams work in isolation, leading to communication breakdowns and a lack of understanding of each other’s goals and priorities. Collaborative leadership helps to break down these silos by encouraging cross-functional work and ensuring all team members have a shared understanding of the project goals and priorities.
The Democratization of Security
We may be at an inflection point in the industry. Security risks have become too complex, and attacks too widespread and frequent. The current incarnation of DevSecOps at many companies needs to evolve beyond the traditional boundaries of siloed software engineers and centralized security teams that rely on new tools to ensure a strong security posture. An organizational-wide model is needed, where everyone is responsible for data and software security.
This move towards democratization, where new ‘engagement vectors’ for education and involvement are unlocked for everyone in the company, will need to be paved with a new, highly cross-functional approach. DevSecOps tools and new features can not wallpaper over a lack of alignment or teams that work at odds with one another. Employees from all business units must be engaged and empowered to amplify a company’s security posture.
We know from Conway’s law that “we ship the org chart” meaning, our software (and security posture) reflect how our teams are designed and collaborate. Only when we have enlisted the efforts of all, in the eternal battle against the bad actor and external threat, should we consider new tooling that can help amplify that collective effort. First culture, then tooling.