Streamlining Security in a Product Shop

Creating a strong security program in a product shop is tough. In a setting where quick movement and fast production is the key driver of revenue, security can feel like a drag on innovation.

But there are ways to align security strategies in a smoother and more efficient way.

The traditional approach is to use code scanning software, but that identifies potential problems after a product is finished and ready to deploy. Developers don’t want to hear about possible issues when they think their work is done. So, while scanning is valuable and should be done, it shouldn’t be the core of your strategy.

To me, a better approach is to integrate with development teams early on. Befriend the chief product officer or chief technology officer to ensure you’re part of the conversation from the beginning of the development chain instead of at the end. If you integrate security in the design phase of an application or software package, you can ask questions that will lead to better security outcomes at the development phase. You’re more likely to get a good deal of buy-in from the developers to ensure the product is secure, and at the same time, decrease your security cycle on the backend.

Organizational alignment can also streamline processes. Working with product teams to build reusable code will save a lot of time in software shops. That’s extremely important in the product development world, where speed of execution has a major impact on revenue generation. If you can agree on modules that are reusable, then you’re likely to get very strong alignment from the product team.

You’re also likely to get a lot less pushback when something has to be delivered before there’s time to do thorough testing. In those situations, the best thing you can do is continuous product testing post-release.

You’ll want buy-in on a bug bounty team that will be able to quickly respond to vulnerabilities after the product has gone to production. Because they’re based on financial incentives, bug bounty programs also encourage the company and the product team to do a better job of releasing bug-free software.

You can do bug bounty programs internally, or with an external partner. External programs cost more, but they require a lot less in terms of management. Internal programs might be slightly more effective because they’re closer to your development teams and a lot less anecdotal. But you’ll need a designated person who interfaces on a regular basis with the people who discover the bugs, and that can be a full-time job.

Early integration with development teams, organizational alignment and bug bounty programs offer a strong, programmatic approach to preventing security issues that can cost your business hundreds of millions of dollars.

I think most modern developers would welcome the idea of having security more integrated. Developers are under just as much pressure as security practitioners to ensure their products are hyper stable and production ready.

But it’s not going to be their idea. It’s going to be on CISOs to take that programmatic approach, instead of security being a box that gets ticked at the end so the development team can deploy a product. 

Article originally appeared on Security Current.

###