Throughout 2021, thousands of cybersecurity incidents were recorded, many of them significant and some of them devastating. Information belonging to over 550 million Facebook users was published online, Coinbase sent out a letter to 6,000 users after detecting a third-party malicious campaign to move customer funds off the platform and Robinhood disclosed a data breach impacting roughly five million users on the trading app. These attacks show no signs of slowing. Just last month, the Log4j vulnerability made headlines and, at time of writing, is still being actively exploited in the wild.
The costs of these incidents are substantial, and the number of incidents happening year over year continues to grow. According to a 2021 report from IBM and the Ponemon Institute, the average cost of a data breach among companies surveyed reached $4.24 million per incident in 2021—the highest in 17 years.
Traditionally, the perception has been that security and compliance are executive-level decisions, given the high stakes that come with security breaches. When things go wrong, it’s usually executives who have to answer, like when Target’s CEO stepped down last year after a major security breach. This leads to top-down enforcement rather than bottom-up adoption, where CISOs are responsible for buying, implementing and enforcing security tooling and processes throughout the organization.
While this siloed approach may seem like the logical—or even the only option—it seldom produces the desired results. The rise of DevOps culture, technologies and design patterns have enabled a new breed of speed and agility, elevating software developers to be key stakeholders when it comes to security—whether organizations acknowledge it or not. This has given rise to shift-left security, which emphasizes the importance of developers having skin in the game to write secure code, ensure third-party delivery pipelines are securely configured and flag misconfigurations and vulnerabilities before code is ever pushed to production.
Despite the purported benefits, it can seem daunting for security teams and executives to relinquish control when the stakes are this high. But the costs of keeping security siloed from development are much higher. Modern organizations that are embracing DevSecOps are moving not only with higher velocity but with more proactive security that’s baked into the software development lifecycle before code is even deployed.
With these considerations in mind, here are a few ways that organizations can encourage bottom-up adoption of security:
Open source tools don’t require budget approval and can quickly provide visibility into the posture of one’s own code. These tools provide free feedback to begin the proactive journey of securing code based on the findings before it makes it to a company-sanctioned security code review. The right open source tools will speak the developer language and provide outputs in a comprehensive and in-context format so developers can begin tackling security issues themselves.
The right developer security tooling will be embedded in developer’s existing tools, such as their IDE and VCS. The best feedback includes fixing suggestions or guidelines with code. This is a big improvement from the long CSV of issues without context and is the easiest shortcut to getting developers to actually make a fix. If they receive the security feedback in the tools they are using with minimal effort to find a fix, they may even like the security tool.
The most successful DevSecOps movements include more than just enforcement and requirements. Developers should be given the tools and space to educate themselves on application and infrastructure security. Nowadays, there’s an appetite from developers to write secure code; there just isn’t always the explicit permission to reprioritize work to make that happen. If you dedicate 10% of your time (or whatever works for your team) to security education and provide the educational resources, you will see how developers will naturally flock to learning new concepts that benefit their work. And it’s not a one-way street. Ideally, your security team should also invest time learning about shift-left security, infrastructure as code (IaC) and supply chain security.
Andy Jassy famously said that, at AWS, security is job zero. Creating a culture that embraces proactive security requires buy-in from everyone, because if developers are acting totally independently, then they may end up using a different tool suite than security, and if security isn’t considering the needs of developers, their tooling mandates will often be ignored. But getting everyone on the same page will lead to a significant drop in the number of security issues.
Following this pattern, I’ve seen developers begin to gain visibility into security issues and start to secure their own code with a new sense of ownership. With enough adoption and positive outcomes (more secure code), the security processes and tools begin to spread to other teams until it becomes a company standard. Over time, this creates a culture of security-minded development that is far more scalable than any top-down mandate, and the result is a double win of more secure code and happier developers.
This post originally appeared as a Forbes Technology Council post.
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement. Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.