A surge in attacks on tailor-made systems has increased the pressure on organizations to secure not only their infrastructure but also their applications and development processes. Extra time spent on secure development can frustrate development teams, but it often pays off in the long run.
Threat actors are becoming more sophisticated, more active, and more interested in undermining security in the development process.
There were 929 cyber attacks aimed at actively infiltrating open-source software between July 2019 and May 2020, more than four times the number registered in the previous four years, according to data from Sonatype.
The surge in attacks has increased pressure on organizations to secure not only their infrastructure but also their applications and development processes. That costs both time and money, which understandably frustrates developers who want to move fast rather than spend time on strict processes that can inhibit creativity.
Time lies at the root of the problem; attackers have unlimited time to plan and undermine systems. Developers, on the other hand, have a limited amount of time to protect their organization against all eventualities. It’s a common cybersecurity problem; unfortunately, there is no silver bullet. Instead, layers of security-related activities should be introduced at all stages of development that together form a high-quality, reliable security process.
Getting there begins when organizations commit to carrying out a transparent assessment of their strengths and weaknesses. Without a comprehensive awareness of where processes are strong and where they fall short, it’s virtually impossible to know where to focus efforts and direct investment. Honesty is key.
Tools are available that help assess the maturity of teams, including workshops focused on how leaders can interview their teams to better understand how they work. From there, it’s possible to develop metrics to guide where investments are best directed.
These processes aren’t geared toward being perfect, either. Rather, they’re about choosing activities that will generate the most impact within the timeline you have. With that in mind, it’s vital that security steps don’t become hurdles that incentivize developers to bypass the processes in question. The secure way must be the easy way, so there’s no reason to avoid it. Automation has a role to play here, particularly when it comes to repetitive tasks like static code analysis.
Finally, there is a cultural aspect. Organizations that do this well tend to have somebody – officially or otherwise – guiding the team in what’s appropriate. But in the broadest sense, the most effective teams accept that the responsibility for secure development lies with everybody. In the long run, that means secure processes are far more efficient, which retains the pace of development.
Security becomes second nature when entire teams accept that taking shortcuts is too risky, and the sooner that message crystallizes, the better.