If you spend enough time on LinkedIn, you'll encounter these posts by security directors, VPs or CISOs. Mocking cold calls. Taking a jab at conference booths. Gaslighting SDRs that do bad cold outreach. You know the vibe: "Stop selling me shit!"
And I get it, most business devs suck at their job. They have a 'takers' mentality: they have their battlecards and go through their motion and you see right through them. But that's not a reason to dismiss the industry.
At first, I thought it was a form of humblebrag. Confession time: I joined LinkedIn precisely because my colleagues were bitching about having so many recruiters "annoying" them and thought I deserved a piece of the action. All this to say: what you see as an annoyance can be someone else's desire, so be careful throwing them down.
But this gets deeper. I think the aversion to the industry is deeply rooted in our discipline... and I think it's a problem.
The Hacker Myth
There’s a prevailing mindset in this field that "real" teams build their own tools. This mentality comes from our hacker roots. A hacker tinkers, customizes and cleverly tweaks. For many of us, building is part of our identity. It’s what we’ve done for years. It’s what made us fall in love with the technology in the first place.
I admire that hacker mindset. The curiosity. The initiative. The sense of being able to outsmart the system. But inside an enterprise environment, that instinct often requires a shift toward what might seem like the "boring" choice: corporate bowties and croissants conferences.
Build vs Buy is one of my biggest ongoing debates with my colleagues, and I'd argue, in the GRC industry as a whole. I'm part of the latter group: let's rely on this company who lives and breathes a single problem to solve our identical problem. Developers cost hugely and they hate doing maintenance. A McKinsey study found that developers spend up to 50% of their time on maintenance rather than innovation.
The counter-argument I keep hearing is about how these security tools cannot meet our needs. I counteract with: How unique are you, really? And should you be that unique?
In most cases, the extra 10% of customization we’re craving comes with a hidden cost. Think time spent on maintenance, troubleshooting, documentation, and support. WHICH EVERYBODY HATES TO DO. Internal tools lack the external support you get from vendors. You lose the ability to escalate when things go wrong, and you’re left managing a tool that can easily become a liability if the original builder leaves or moves on. In fact, Forrester points out that 70% of orgs struggle with knowledge loss when technical staff leave teams that maintain custom tools.
At a certain scale, building becomes a trade-off that limits our ability to focus on the real, high-value problems that only we can solve.
What about GRC?
Now, as a GRC professional, it’s easier for me to advocate for buying instead of building. My job is to make strategic decisions, not to write code. But that’s not just a fallback option. I believe my bias is based on the reality of operational efficiency. Buying a tool doesn’t mean you’re less technical or that you’re not capable of building. It means you’re choosing to focus your time and energy on doing something else than debugging software (a.k.a not bringing security value). It’s a decision to invest in scalability and sustainability rather than novelty. A vendor’s tool is already tested, supported, and maintained. Let them update those hosts and containers.
The relationship with a vendor also gives you leverage. You can push them for improvements, tie renewals to their roadmap, and hold them accountable. That’s harder to do with in-house tools, where you’re locked into whatever you've built, often with no clear escalation path when things go wrong. Worse, from what I've seen, sentiment gets in the way. It kind of get difficult to tell Larry that his software sucks if you ride in the same bus every day.
The Cost of Humans
Hiring people to build things can be a great solution too, but that takes more discipline. It’s not about pushing a few buttons or making a quick change. It’s about coaching, upskilling, and managing. You’re not just paying for a tool, you’re investing in people who will need your guidance, mentorship, and time to grow. That takes a lot of effort, especially when they are managing tools that don’t have external support.
None of this is to say that building tools is inherently bad or unnecessary. Sometimes it’s exactly the right decision. But too often, the drive to build is fueled by an identity, a culture of hackerism that places more value on being different than on being effective. The truth is, most enterprises don’t need to reinvent the wheel.
In a high-functioning enterprise, the real work often looks like buying the “boring” tool even if it makes you feel like a corporate stooge or a sellout. But boring gets things done. And let’s not forget the CFO. Predictable OpEx beats mystery Dev time. Buying lets you forecast, track ROI, and tie spend to value. And in security, that’s the kind of work that really matters.
I wrote a similar article in reaction to my visit at the "North Sec" a passion-driven conference:
Pierre-Paul Ferland
Member discussion: