As someone who's been immersed in the security business for 20 years and IT for over 30, I’ve seen countless security products come and go. I’ve also had the unique opportunity to build out critical security programs from the ground up at Five9, including our software supply chain security and secrets detection initiatives. When it comes to selecting vendors, my strategy often leans towards early-stage startups.

Why? They’re hungry for my business and that translates into a significant willingness to listen to their customers. Often they’re more responsive than established platforms, building out features that meet our needs and committing to a true partnership. There’s also an inherent energy in startups; they are constantly innovating. I believe startups are often better positioned to handle technology shifts (AI!) due to their agility and cutting-edge technical teams.

But being an early adopter comes with risk. What if they’re smoke and mirrors? Will I get fired over a bad pick? But I’ve found that the risks can be mitigated with an approach that in many ways looks a lot like creating a new job description and conducting thorough interviews for the role. This strategy has resulted in solid technology matches and kept me safe when sticking my professional neck out for a junior organization.

Creating a “job description”: Understand the problem and technology

Any hiring manager can attest to this truth: You’re setting yourself up for failure if you don’t clearly understand the job to be done. Selecting a vendor begins with a very clear understanding of the problem I'm trying to solve. For example, when I was looking to replace the SCA tool at Five9, I established that we had to 1) improve the pace of remediation without sending noise to developers and 2) keep upgrades to just the necessary ones because any threat to uptime is a problem.

Next, I do my research on the technology and approaches. In the SCA example, I needed something that helped us prioritize remediation. There are different ways to do that, with different degrees of effectiveness. On one end of the spectrum are tools that apply generic filters of CVSS and whether something has been exploited. On the other end, there’s function-level reachability which is application-specific. Fortunately my personal experience working at IBM made me very familiar with tracing call paths, so I already knew a tool that could deliver on function-level reachability would be a winner.

After my research is done, I’m ready to assemble my list of requirements or an RFP. But because I’m often looking at immature companies, I’m realistic about which requirements are must-haves from the start vs. those that can come with time.

Conducting the “job interview”: Vet the vendors

Once I understand the problem and the technology, the next step is vetting the vendor. I approach this much like a job interview, looking for both technical prowess and a strong cultural fit.

The technical interview

My vendor assessments center around a fundamental principle: verifiability of findings. My background in application penetration testing and source code reviews taught me that any finding delivered must be justifiable and verifiable. I need to be able to explain precisely why a finding exists and why it's classified a certain way to technical teams. This core idea guides my entire selection process.

This is why I expect deep technical conversations. I need vendors to be transparent and willing to discuss how their technology operates. Given these conversations happen under NDA, vendors should be comfortable sharing some proprietary details about the product. If I encounter double talk or a reluctance to explain the underlying mechanics, it's a red flag for me. And naturally, the POV experience has to align with what I’ve been told. Going back to my SCA example, I had extensive discussions with the CTO of Endor Labs (Dimitri Stiliadis) about their call graph analysis and the intricacies of their function reachability. He spared no detail and gave me confidence that they could deliver on their technical promises.

The culture fit

Because I’m looking for a vendor that will listen and act on my input, I also thoroughly vet non-technical elements to judge if they’ll be a good partner. Think about this a bit as the “soft skills” part of the interview. I can get a feel for whether it’s going to be a good fit by looking at:

• Do they take my questions seriously, or blow me off?
• How quickly do they respond to questions and issues?
• (This one’s not quite a joke) Would I want to get a beer with them?

Ultimately, I’m looking for someone I can work with. A colleague, if you will. This approach has resulted in solid relationships and even some friends!

About the author

Greg Pettengill is a Principal Product Security Engineer at Five9, where he’s responsible for managing their software supply chain security and secrets detection programs. His extensive career includes stints at Labcorp and IBM, and Greg also gives back to the community by teaching secure coding classes.