Every week, Sprocket Security's CEO Casey Cammilleri interviews an expert leading the charge on empowering security experts and practitioners with the knowledge and insights needed to excel in the future of cybersecurity.

He recently spoke with Eyal Paz, VP of Research at OX Security,. Here are the top takeaways from the interview.

#1: Run Penetration Tests on Staging Environments

“We're always going to have a room, like the human in the loop. Also I think after people will be out of jobs with all of the AI or taking over. I think the last people on earth with jobs are going to be penetration testers. So definitely not the kind of population that I want to make angry with me. However, some of the use cases that I've got to discuss with some of our customers when basically, I'm working on this shift left technology. So what we find out is that sometimes our customers actually ship or start the penetration test process before they are shipping new services to production.

“Actually, this is the way that this should be, for new services to run the pentest on top of staging and not on top of production. And so we had this use case where they came to the developer, the development team, and told them, ‘Hey, the penetration test found this and these vulnerabilities within your product.’ And they say ‘Oh, don't worry, we already got it covered,’ because they also in parallel so that our scan detected this kind of vulnerability. So they already remediated it before the product was shipped to production. So basically this is the classical way where penetration test and shift left approach actually mingle well, very, very well together.”

Actionable Takeaway: Integrate penetration testing with shift-left security for maximum effectiveness. By testing in staging environments before production deployment, your security team can identify vulnerabilities while developers simultaneously remediate issues caught by automated scans. This collaborative approach ensures vulnerabilities are addressed before reaching production, creating a seamless security workflow rather than conflicting processes.

#2: Leverage Recent Security Incidents to Build Developer Buy-In

“I suggest starting with the pain point. The thing that people like developers would be most cooperative with is something that they recognize as bad. Meaning that if for example in some organization there was a recent crisis because of this XSS on their production application, then they should be really, really sensitive about XSS. And the way to find XSS for example is integrating a code security tool, like a SAS tool into the pipeline. And that's it. XSS are really, really easy for SAS tool to locate with very, very high precision. So low risk of noise from that end.

“And I think this would be a very, very good use case with very high success rates. Same example, is if for some organization, maybe a DevOps organization by mistake put a terraform code, which put some S3 bucket exposed out to the Internet with some sensitive data. It doesn't matter if it was found by penetration test or by a customer or by some random actor. Basically now all DevOps knows this is very bad and the way to solve this is by infrastructure as code scan integrated into their pipeline.

“So I think something that will also maximize the chance of success in this case is actually putting into play shift left scanning, which is relevant to something really bad which recently happened. Now, again, this is one kind of approach. If you didn't add any incident regarding application security in the past two years, of course you can still integrate it. But what I'm saying is that security guys should really, really take advantage of bad things which happen to the organization as excuses to actually move forward with the shift left.

“I think that this will have developers and DevOps more cooperative into putting these technologies and also making them more patient for stuff like okay, maybe this scan takes like put more time into their pipeline or maybe that's false positive, but they will still be cool about it because they will know that this will solve the specific use case of this kind of leakage or vulnerability or any kind of embarrassing stuff going on in production.”

Actionable Takeaway: Start your DevSecOps journey with tools addressing recent security incidents in your organization. When developers have felt the pain of an XSS attack or exposed S3 bucket, they're more receptive to pipeline security tools that specifically prevent those issues. Their willingness to tolerate extra scan time or occasional false positives increases dramatically when security measures target problems they personally recognize as harmful.

#3: Consider Long-Term Costs When Choosing Security Tools

“Obviously there is a lot of very, very high-quality, well-maintained, open source software out now — and this is very, very easy to implement by the way — defining GitHub Action or GitLab CI job, which fail if, let's say you run an open source scanning tool like Ripe or Trivy, and if it detects anything in the dependency scanning then you then the tool return like a non-zero exit code and then you can block the pipeline very easily. If the pipeline ends with a non-zero exit code. This is trivial to implement.

“Now, the problem starts when it does find stuff, and now what do you do when things go wrong? Now I think that it's open source usage. It's very, very good practice either when you simply don't have a budget and you need to have something working. It's very good for experiments, for running experiments, like to assess what is as a preparation toward larger deployments. Because again it's free and it's very, very simple to implement.

“But it's not manageable in larger organizations, and outside of simple experiments. And I've also encountered a really, really large organization with a really very, very large security team. And I found it blew my mind when I understood the amount of time and the amount of effort that they took and they built this amazing. It's an entire product. They built an entire product all based on open source software and it works.

“But thinking about the amount of time it took them to actually to build this infrastructure and the size of the team, this is absurd because they could have made much better use of their time and just getting a security product which is implementing basically the same kind of capabilities, it just does it a little better and obviously faster.”

Actionable Takeaway: Although open-source security tools offer quick implementation through simple CI/CD integrations, evaluate their total cost of ownership for enterprise deployment. Free tools excel for experiments and small implementations but often become unmanageable at scale. Many organizations underestimate the substantial time investment required to build comprehensive workflows around these tools, making commercial solutions more cost-effective despite the upfront expense.