Closing the security gap

Who should keep software development safe and secure? It’s the engineering organization

Kevin Bocek
© Shutterstock / Ico Maker

The truth is that every business is now a software developer – whether a retailer, bank, transportation, insurer – they are all operating as software companies. If attackers are setting their sights on software as a promising venue for their exploits, then organizations have to close this security gap.

In the war against cyberattackers, we may be putting the wrong type of soldier on the front lines. Security teams traditionally focus on protecting infrastructure – the servers, endpoints and other building blocks of corporate networks – instead of 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 the security teams, aren’t trained to thwart the right threats. Nor does the engineering culture, where speed and feature development are highly valued, currently lend itself to security.

The result: Software products are developed between two worlds – security and engineering – that have hardened their practices over the past few decades since security teams became fixtures in companies. These two worlds don’t play well together, and in fact, don’t even like each other very much: Engineers think that security professionals will slow down the lucrative work of product development, and security pros think engineers are basically anarchists.

The truth is that every business is now a software developer – whether a retailer, bank, transportation, insurer – they are all operating as software companies. If attackers are setting their sights on software as a promising venue for their exploits, then organizations have to close this security gap. There are many ideas on the table, like creating the position of Chief Product Security Officer, or the infamous idea of DevSecOps that would find traditional security teams paired into modern application development. I think the best model, which may also pose the most disruption to business, is to hand responsibility to the engineers who actually create software solutions.

SEE ALSO: “The impact of poor machine identity management can be devastating”

The pandemic hastens software security

The path to developing secure software products isn’t all that clear. A new Venafi survey of infosec and developer professionals found that there’s no consensus as to which functional team within organizations is responsible for ensuring that the software supply chain is secure. Nearly half of the respondents (48%) believe the responsibility rests on security teams, while another 48% say that DevOps teams are responsible. The lack of consensus on software security responsibility creates gaps in the build and code management environments that leave organizations and their customers vulnerable to attacks.

The disconnect has been around a long time, but the differences between security and engineering weren’t as pronounced before the pandemic. Certainly the transition to the cloud has changed perceptions of security, now that businesses no longer live behind firewalls. But the pandemic and remote work hit businesses like an asteroid. We experienced a decade’s worth of digital transformation in just months.

Security teams were ill-equipped for the explosion in software development at every company. Most of them are not engineers who know how to build software. Today, every business is in the software business, and the power and security of your software is your competitive advantage.

One idea: a Chief Product Security Officer

So what’s the solution for keeping software development secure? This is a hot topic among security professionals. Chris Wysopal, the CTO of Veracode, advocates for the creation of a Chief Product Security Officer (CPSO).

“This would be a role that works with the development leader to make sure security is built into the development process,” Chris explains. “They should have a software engineering background and focus solely on the products companies ship to customers or deploy to the cloud. The engineering team needs to do the automated testing and fixing of flaws, but the CPSO can put in additional people and processes to augment what developers can do themselves.”

Chris sees the CPSO as reporting to a member of a business’s executive team, just like a CISO does at most companies. If small companies don’t want to add a CPSO, they should consider creating a Director of Product Security position that’s part of the engineering organization.

I think Chris is on to something here: We can’t change the culture around development and security without getting buy-in from the top. The C-suite needs to make it clear that finger-pointing between security and engineering isn’t acceptable, and that both departments are accountable for the safety and security of software products.

SEE ALSO: “Proactive security scanning of code is a must”

Fast and secure, without compromises

My answer to the security problem starts with a Formula 1 racing analogy. The sport needs extreme performance, but with a certainty of safety. Designers and race engineers can’t compromise on either goal. Software development needs to be fast for competitive reasons, but we can no longer compromise on security. Meeting both goals has to come from the engineering culture: the people that know how to make products. And it can’t be speed and then we’ll try to secure it; it must be fast and secure all at the same time. Like our engineering teams at Venafi, security architects who know how to code should be involved in every software product.

If engineering is going to build security into products, as they should, security teams don’t need to be as large as they’ve been getting. We don’t need more firewalls; we need more people who can code but have a head for creating safer software.

As engineering builds out a new security function, security teams can scale back to what they know best. They’re the experts on threats, and can guide the business on governance and compliance relating to security.

No matter which precise solution an organization chooses to keep security safe, the accountability will rest on the development organization. If we expect to keep software products safe for customers to use – and if we don’t want our businesses to end up in the headlines because of an undetected security fault – engineering organizations need to become better-trained “soldiers” on the frontlines of cybersecurity.


Kevin Bocek

Kevin is responsible for security strategy and threat intelligence at Venafi. He brings more than 16 years of experience in IT security with leading security and privacy leaders, including RSA Security, Thales, PGP Corporation, IronKey, CipherCloud, NCipher, and Xcert. Most recently, Mr. Bocek led the investigation that identified Secretary Hillary Clinton’s email server did not use digital certificates and encryption for the first 3 months of term. In 2013, Mr. Bocek led Venafi’s investigation into how Edward Snowden used cryptographic keys and digital certificates to breach the NSA.

Kevin has a B.S. in chemistry from the College of William and Mary and an MBA from Wake Forest University.

Inline Feedbacks
View all comments