It can sometimes feel like development and security teams are working toward two separate goals. Both developers and security professionals are supposed to be working toward timely, secure releases, but in reality, developers tend to prioritize speed and function, and security professionals prioritize security measures. How can you unify the teams and focus them on shared goals? A little history can help.
Several decades ago, software deployment followed a waterfall approach with releases every six months. But as the world became increasingly digital, biannual releases were no longer fast enough. Organizations moved to an agile approach, releasing weekly or monthly. And today, with continuous integration (CI) and continuous delivery (CD) processes, releases are daily, hourly, or even by the minute.
With the increase in release frequency comes an increase in security threats. To combat these threats, security regulators instituted more stringent compliance requirements and penalties. These requirements have placed added stress on security professionals – who are already facing staffing shortages and pressure associated with multiple releases a day.
To aid the security shortage, many companies moved the responsibility of securing code to developers. Developers agreed to take on the additional responsibility and, initially, security improved. But as DevOps continues to mature, and the speed of releases continues to increase, developers have placed security on the backburner in favor of speed.
Why are they prioritizing speed? There are several reasons. First, at most organizations, the developer’s performance is directly tied to the speed of releases. Second, the majority of developers don’t have the necessary tools or training to write secure code or to remediate flaws.
So how can you encourage developers to not just prioritize speed, but to also prioritize security? The key to success is making sure that security measures are fast and easy to implement. How can you achieve this? Build security measures into the developers’ existing processes so that scans don’t slow them down. You also need to enable developers with tools and resources to write secure code in order to reduce the number of issues from the start. And you need to scale your program, building and maintaining the AppSec infrastructure and cost model to meet ever-increasing demand. Lastly, you need to set the precedent with developers that security is an expected outcome, not just speed.
By following these steps, security will start concentrating on ways to speed up their processes and developers will have an easier time implementing security.
To learn more about the evolution of software deployments and the effect on developers and security professionals, check out our interactive infographic, Is Application Security an Expected Outcome for You ... Or Does it Take a Backseat to Application Innovation?