In the war against cyber attackers, we may be putting the wrong kind of soldier on the front line. Security teams have traditionally focused on protecting infrastructure — the servers, endpoints, and other building blocks of enterprise networks — rather than code, repositories, or build pipelines. But in the wake of software supply chain attacks like SolarWinds and Kaseya, it’s clear that the “soldiers,” or security teams, aren’t trained to thwart the right threats. The engineering culture, where speed and feature development are highly valued, also currently does not lend itself to security.
Result: software products are developed between two worlds – security and engineering – which have hardened their practices over the last decades since security teams have become essential in companies. These two worlds don’t work well together and, in fact, don’t even like each other very much: engineers think security professionals will slow down lucrative product development work, and security professionals think engineers are fundamentally anarchists.
The truth is that every business is now a software developer – whether retailer, bank, carrier, insurer – they all operate as software companies. If attackers are targeting software as a promising location for their exploits, companies need to close this security hole. Many ideas are on the table, such as the creation of the position of director of product security, or the infamous idea of DevSecOps which would find traditional security teams paired with modern application development. I think the best model, which can also be the most business disruptive, is to put the responsibility on the engineers who actually create the software solutions.
SEE ALSO: “The impact of poor machine identity management can be devastating”
The pandemic is accelerating software security
The path to developing secure software products is not so clear. A new Venafi survey of infosec professionals and developers found that there was no consensus on which functional team within organizations is responsible for ensuring software supply chain security. Nearly half of respondents (48%) believe the responsibility lies with security teams, while 48% say DevOps teams are responsible. The lack of consensus on responsibility for software security creates gaps in build and code management environments that leave organizations and their customers vulnerable to attack.
The disconnect has been around for a long time, but the differences between security and engineering weren’t as pronounced before the pandemic. Certainly, the move to the cloud has changed perceptions of security, now that businesses no longer live behind firewalls. But the pandemic and remote work are hitting businesses like an asteroid. We’ve experienced a decade of digital transformation in just a few months.
Security teams were ill-equipped for the explosion of software development across all enterprises. Most of them are not engineers who know how to create software. Every business in the software industry today, and the power and security of your software is your competitive advantage.
An idea: a Chief Product Security Officer
So what is the solution to secure software development? This is a hot topic among security professionals. Chris Wysopal, the CTO of Veracode, pleads for the creation of a Chief Product Security Officer (CPSO).
“This would be a role that would work with the development lead to ensure security is built into the development process,” Chris explains. “They need to have a background in software engineering and focus only on products that companies ship to customers or deploy in the cloud. The engineering team should perform the automated tests and fix the flaws, but the CPSO can put in place additional people and processes to augment what the developers can do themselves.
Chris considers the CPSO to report to a member of a company’s management team, just like a CISO does in most companies. If small businesses do not want to add a CPSO, they should consider creating a product safety manager position that is part of the engineering organization.
I think Chris is onto something here: we can’t change the culture around development and security without getting buy-in from the top. The C suite should make it clear that finger pointing between security and engineering is not acceptable and that both departments are responsible for the safety and security of software products.
SEE ALSO: “Proactive code security analysis is essential”
Fast and secure, without compromise
My answer to the safety issue begins with an analogy to Formula 1. Sport needs extreme performance, but with certainty of safety. Race designers and engineers cannot compromise on any of these goals. Software development has to be fast for competitive reasons, but we can no longer compromise on security. Achieving these two goals must come from the culture of engineering: people who know how to make products. And it can’t be the speed and then we’ll try to secure it; it must be fast and secure at the same time. Like our engineering teams at Venafi, security architects who know how to code must be involved in every software product.
If engineering is to embed security into products, as it should be, security teams need not be as large as they have become. We don’t need more firewalls; we need more people who know how to code but who have the head to create more secure software.
As engineering develops a new security feature, security teams can go back to what they know best. They are the threat experts and can guide the business in security governance and compliance.
Whatever precise solution an organization chooses to provide security, the responsibility will rest with the development organization. If we want to ensure the security of software products for customers, and if we don’t want our companies to be in the headlines because of an undetected security breach, engineering organizations must become better “soldiers”. trained on the front line. cyber security.