Security teams are constantly striving for mindshare and alignment within the organization. Seasoned security professionals often describe how security must serve the business and how it depends on the business’s acceptance of the importance of security to success. As a result, security teams invest heavily in raising security awareness, educating business users, and explaining why security is critical to the business and cannot succeed without business users.
Without approval from business leaders, security teams can only apply security measures through formal gates, enforced controls, and corporate policies, which without proper communication can often lead to frustration and exacerbate the business approval issue. However, when business teams view security as a business enabler, the conversation completely changes. Employees turn to security for input early 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 security leaders often focus most of their efforts on building relationships with executives to gain executive endorsement. In the best case, this also leads to business units and security teams moving closer together. With this lens, we can see how important and transformative DevSecOps is. Suddenly, development teams can collaborate more easily and sometimes even lead security efforts. The indirect effect of having more people—that is, developers, not just security professionals—think with a security mindset can impact the security team’s ability to make big strides.
A company where many developers understand and push security in their day-to-day work is much more likely to support large security projects like adopting a new identity system or applying Zero Trust, even if they 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 testing as part of CI/CD, although these are also important.
Bring security thinking closer to developers
One possible explanation for the success of DevSecOps is the value of automation. Whether it’s catching syntax errors, identifying an unsafe dependency, or discovering hard-coded secrets, automated security testing helps developers do more in less time. The argument that automation is why developers jump on the security bandwagon seems to imply that developers have always recognized the importance of security but have not had the resources to act on it.
While automation is extremely helpful, I find that the mindset change for some development teams is far greater than just a change in resource discussion. More and more developers see security as part of their responsibility and not the responsibility of others.
There is a bigger shift here than just reducing the cost of adopting security best practices. Security teams began speaking to developers in the language of the developers instead of the language of security. This is a crucial point. Instead of painting a pretty picture of how security should work, DevSecOps shifts the conversation to a much more practical one: how do we take a step forward from where our developers actually stand?
Note that the goal remains the same – to lead development teams to a beautiful picture of how security should work. Crucially, however, we start on the practical side of the discussion, helping to guide each step of the journey rather than describing a future that seems distant or even impractical.
By shifting the security conversation to developers’ language and meeting them where they are, security teams and developers now share a security mindset that aids in both day-to-day operations and the big security steps forward that require developer approval .
While success is important with developers, security is still struggling to win over a much larger segment of the enterprise workforce, namely business users. Can we apply the lessons learned from DevSecOps to bring security closer to business users?
In recent years, lines of business have experienced a tectonic shift through low-code/no-code platforms. By acquiring the skills needed to simplify business processes or build custom applications themselves, business units have drastically reduced their dependency on IT and further accelerated digital transformation. Leading analysts predict that by 2025 most enterprise applications will be developed using low-code/no-code, and surveys show that business users are already using a large proportion – and in some cases the majority – of low-code/no-code . code creator.
The trend of business users becoming developers can be both a challenge and an opportunity for security teams. Leaving this outside of the perceived security accountability will result in significant shadow IT growth. However, it also offers an unprecedented opportunity to cultivate a security mindset among business users. If DevSecOps has made developers more security conscious, a low-code/no-code equivalent could do the same for business users. As with developers, the sea change to bring business users closer to security thinking would mean dramatically increasing security awareness across the enterprise. Low-code/no-code offers a unique security awareness opportunity.
As we seek to capitalize on the security awareness opportunity that low-code/no-code offers, we should apply the lessons we’ve learned from DevSecOps by meeting business users where they are. The low-code/no-code development process differs significantly from pro-code DevOps. Many business users today build their applications and automate their processes with low-code/no-code. Security teams should become familiar with these platforms and their development processes, and learn how to speak in the native language of business development about security for such purpose-built applications.
Low-code/no-code is so dominant among business users that many organizations are already using it for mission-critical applications, even if their security teams are unaware of it. With analysts predicting that 70% of new enterprise applications will be built with low-code/no-code in three years, it’s evident that we have a unique window of opportunity to impact the way these applications are built. But more importantly, this is an opportunity to impact the next generation of developers – namely business users – and the way they think about security and their role in it.