Why security is everyone’s responsibility

Security may not be everyone’s job, but it must be everyone’s responsibility, and that includes product engineering teams. 

This was the big conclusion from a recent webinar on strengthening the relationship between security, product, and engineering teams. Moderated by Lena Reinhard, engineering leadership coach and consultant, the discussion brought together security and product management experts from organizations including Frontegg, SiriusXM, and Smartsheet.

As developers increasingly focus on rapid product iteration and continuous delivery, security is too often seen as a point of friction, slowing things down. “Developers move at the speed of innovation,” said SiriusXM senior principal security architect, Izar Tarandach. “They want to do the new shiny thing as quickly as possible. And security moves at the speed of caution.”

Why dialogue is essential

As Reinhard pointed out, the “ownership” of security can become murky, and incentives become misaligned. As developers focus on pushing features out, the security team is left “to basically pick up the pieces when things fall apart, and you have an incident.”

At the same time, the evolution of security strategies and purchasing decisions over tools and platforms often happens at some remove from the product team. Sometimes it will be a CFO or VP who ultimately has the last word, leaving engineering and security teams feeling left out of the loop.

Product teams can feel that security “lives outside” of the product, said Smartsheet senior product manager Racine Harris. But focusing on closer integration between the teams can make product people more aware of what changes require a check and ensure both sides of the house have the same definition of “done”. It needs to cut both ways too. Security should be more than “the department of no” and starting a dialog by saying “yes, but….”

Legacy products shouldn’t be left out of the conversation either. “If you have a very mature product, maybe now is the time to scan around the market and see if you can migrate some of these painful, homegrown, mature technologies to more modern APIs,” said Frontegg CTO and co-founder, Aviad Mizrachi.

Security must be part of the developer tool box

Questionnaires and checklists are important tools for ensuring compliance, and to help the broader organization assess the amount of risk it is comfortable with. But the people asking the questions need to be able to interpret the answers, and they need to be acted upon, not simply filed away. Otherwise they risk simply becoming “security theater”, as Izar deemed it.

At the same time, security should be a default, practical part of the developer tool box, Tarandach said, and built into the hiring and interviewing process. Having developers taking a more active role in addressing and preventing security issues would mean fewer real world problems and would in turn reduce the need for excessive governance.

Security is everyone’s responsibility

Beyond better collaboration at the individual contributor level, it’s crucial that leadership takes security seriously. While product teams might want to get things out quickly, organizations have to be willing to make room for security.

“If it’s going to slow down development a little bit, so that we’re building the right product with the right integrity, then that’s a trade-off we’re willing to make,” Smartsheet’s Harris said.

If you’re interested in hearing more about how Frontegg can help bring your security and engineering teams closer, book a discovery call with the team today.