EP 35 — Streamlining and Accelerating Your Product Security with iHerb’s Mike de Libero

In this episode of the Future of Application Security, Harshil speaks with Mike de Libero, Director of Product Security at iHerb, LLC, an online health and wellness shop. They discuss the ways in which automation helps lighten the workload and creates more consistency, when you need to hire someone for security automation, and what to look for when scaling visibility. They also discuss how the role of product security has evolved, the benefits and drawbacks of today’s tools, and how to build more effective remediation.

Topics discussed:

• How to implement automation to lighten the load of product security engineers and to create a more consistent experience for everyone.
• What to look for and what questions to ask in order to scale your visibility.
• How to know if it’s the right time to hire someone for security automation — and why you should borrow someone from the dev team first.
• How product security has changed over the years, including its shift from testing and finding issues to building libraries, controls, and frameworks to help dev teams push code out quicker.
• How to group classes of security issues in order to streamline remediation, and how Mike’s team went from 1900 tickets to 30 with this practice.
• How Mike’s background as a programmer gives him more understanding and empathy in his role as Director of Product Security at iHerb, LLC.
• What Mike learned about product security at different companies in the past, including Salesforce, Microsoft, Uber, and Unity.

Guest Quotes: 

1: “I think people often forget that writing code is very different than actually doing software development. There’s a whole additional chunk of work in that process and knowing that and studying that for a bit really helped me be able to more empathize with the developers and the development teams and be able to translate information a bit better to their perspective.” (1:53)

2: “But we would kick off pretty lightweight scans, things like static analysis, checking for SCA issues, checking for Terraform configs and other cloud config issues, and stuff like that. Nothing super crazy. But the reason we did that was then the product security engineers there didn’t have to do that and didn’t have to spend their time scanning that stuff. … So if we could do the scans for them, then we can take that load off their plate, and then we also have a more consistent experience for everybody as well.” (10:17)

3: “We want to be able to see how painful it is to use secret management, what it’s like to actually deploy our software out to production, how easy is it to get an infrastructure resource. If there’s problems in all those or there’s problem in one or two, you want that feedback so we can improve it. It might not be a direct security win, but often if you go help improve those things, it makes it a lot easier to add those security wins down the road. But oftentimes it is a security win as well.” (19:11)

4: “The role overall has morphed more so from testing and finding issues, then building controls … things to help the devs push out code quicker and help them write secure code more safely. And helping them be better versus kind of pointing out their flaws.” (21:23)

5: “So many of these things that we have to do in security actually more revolves around humans and making those relationships, and working with the teams, and figuring out win scenarios instead of just pushing things on people. Many times I will be more successful talking with the team, figuring out what that problem has, and how I can back that into my problem than anything else.” (29:45)