Embracing the Next Generation of Business Developers

Security teams constantly strive for mindshare and alignment within the business. Seasoned security leaders often describe how security needs to serve the business and how it depends on business buy-in about the importance of security to succeed. As a result, security teams invest a lot in raising security awareness, educating business users, and explaining why security is crucial to the business and cannot succeed without business users.

Without buy-in from business leaders, security teams can apply security measures only through formal gates, enforced controls, and corporate policies that, without proper communication, can often cause frustration and end up making the business buy-in problem worse. When business teams see security as a business-enabler, however, the conversation changes completely. People reach out to security to get input early on in the process, and security teams can focus on helping teams assess where to invest their security efforts.

This dynamic is so fundamental to organizations that often security leaders focus most of their efforts on building relationships with business leaders to get that executive buy-in. In the best cases, that also translates to bringing business units and security teams closer together. With this lens, we can see just how important and transformational DevSecOps is. Suddenly, development teams more easily collaborate and even sometimes lead the effort for better security. The indirect effect of having more people — that is, developers, not just security professionals — thinking with a security mindset can be transformational to the ability of the security team to make big strides forward.

An organization where lots of developers understand and push for security in their day-to-day work is far more likely to go along with large security projects like rolling out a new identity system or applying zero trust, even though those might require some patience from users during implementation. This indirect effect could end up being much more important than the fact that we now have automated security tests as part of the CI/CD, even though those are important as well.

Bringing Developers Closer to the Security Mindset

One possible explanation for the success of DevSecOps is the value of automation. Whether it's through catching syntax errors, identifying an insecure dependency, or detecting hard-coded secrets, automated security testing helps developers achieve more in less time. The argument that automation is the reason why developers are jumping on the security bandwagon seems to imply that developers always saw the importance of security but lacked the resources to act on it.

While automation is extremely helpful, I find that the change in mindset for some development teams is far greater than just a change in the resources discussion. More and more developers are seeing security as part of their responsibility, rather than the responsibility of someone else.

There is a bigger shift here than just a reduction in the cost of applying good security practices. Security teams started talking to developers in the language of developers, rather than the language of security. This is a crucial point. Instead of painting a beautiful picture of how security should work, DevSecOps shifts the conversation to a much more practical one: How do we make one step forward to where our developers actually are?

Note that the goal remains the same — guiding developer teams toward a beautiful picture of how security should work. However, crucially, we start off at the practical side of the discussion and help guide every step of the journey rather than describe a future that seems far away or even impractical.

By shifting the security conversation to the language of developers and meeting them where they are, security teams and developers now share a security mindset, which helps with both day-to-day operations and the large security strides forward that require developer buy-in.

While the success with developers is important, security still struggles with getting mindshare for a much larger portion of corporate employees, namely business users. Can we apply lessons learned from DevSecOps to bringing business users closer to security?

The Times They Are A-Changin'

In recent years, business units have been experiencing a tectonic shift brought forth by low-code/no-code platforms. By gaining the skills required to facilitate business processes or create custom applications on their own, business units have drastically reduced their reliance on IT and continue to accelerate digital transformation. Leading analyst firms predict that most enterprise applications will be developed using low-code/no-code by 2025, and surveys reveal that business users are already a large part of — and in some cases, the majority of — low-code/no-code builders.

The trend of business users becoming builders can be both a challenge and an opportunity for security teams. If left outside of security's perceived scope of responsibility, it will lead to a significant growth in shadow IT. However, it also presents an unprecedented opportunity to cultivate a security mindset with business users. If DevSecOps made developers more security-aware, an equivalent for low-code/no-code could do the same for business users. As with developers, the fundamental change of bringing business users closer to the security mindset would mean drastically increasing security mindshare across the organization. Low-code/no-code presents a unique security awareness opportunity.

When trying to capture the security awareness opportunity that low-code/no-code presents, we should apply the lessons we learned from DevSecOps by meeting business users where they are. The low-code/no-code development process significantly differs from pro-code DevOps. Many business users nowadays are building their applications and automating their processes with low-code/no-code. Security teams should familiarize themselves with those platforms and their development processes, and learn how to talk about security for such purpose-built applications in the native language of business development.

Low-code/no-code is so dominant with business users that it is already being used for business-critical applications within many organizations even if their security teams don't know about it. With analysts predicting that 70% of new enterprise applications will be built with low-code/no-code in three years, it is apparent that we have a unique window of opportunity to affect the way that these applications will get built. But even more importantly, this is an opportunity to influence the next generation of developers — namely business users — and the way they will think about security and their roles in it.