Security is Sales & Marketing

When I first started in security I thought security was a technical job. We got paid to know how to find vulnerabilities, recommend remediation, design standards, and find flaws. We built incredible tools that found esoteric edge cases and celebrated when we found an issue that was beyond the imagination of our peers.

Fast forward a few years, after having the same conversation about the same vulnerability with the same company that I realized finding the issue wasn’t enough. I had to tell a story about what could happen and understand their goals in order to make the impact I wanted to make.

Security is mostly selling. We just don’t like to admit it.

The job is convincing people

Almost everything a security team does depends on someone else doing something. A developer adopting a new pattern. A team prioritizing a fix over a feature. A VP signing off on a process that slows down the thing they’re measured on. A sales rep filling out yet another security questionnaire. None of those people work for us. Most of them have leadership breathing down their necks and a backlog groaning under the weight of someone else’s priorities.

When I ask a team to adopt a secure-by-default library or to spend a sprint on a vulnerability they don’t think is that bad, I’m selling. I’m asking them to trade something they already value for something I claim is worth more. If I can’t make that case, the work doesn’t happen. It doesn’t matter how right I am on the technical merits or how many data breach reports I’ve shared with the team.

Influence without authority

Most security leaders don’t directly manage the people building the platform. We have to influence, not dictate. For anyone outside our reporting line, that means earning trust one person at a time. That means earning trust with individuals.

The Trusted Advisor has shaped how I think about this more than almost any security book I’ve read. The core idea is simple: trust is built when people believe you’re competent, reliable, and that you have their interests at heart, not just your own. If a developer thinks the security team is showing up to score points, protect itself, or is undermining the goals of the business, heels will dig in. We never want to “win” an argument. We want to find the best possible solution for the business. If we do that all parties will leave the discussion in agreement.

We do want the same thing. Nobody on my team wakes up hoping the business slows down. Nobody on the engineering team wakes up hoping for a breach. We both want to ship great software to customers safely and quickly.

Marketing the work

Selling individual decisions is half of it. The other half is marketing, the steady, consistent, and trustworthy work of making sure people know what you do, why it matters, and how it helps them.

Security teams are notoriously bad at this. We do hard, valuable work and then file it under “obvious” and move on. I’ve seen many brilliant engineers minimize their own incredible security research because after they spent months working on the problem the solution is so obvious to them that they think it’s obvious to everyone. If we don’t spend the time celebrating and documenting our wins with stories and metrics it’s hard to articulate our value. If we can’t articulate our value we run the risk of slashed budgets and weakened programs.

A few things I’ve found that help:

• Tell the story of outcomes, not activities or tools. “We shipped a secrets scanner” is an activity. “We blocked 47 credentials from being pushed to git, three that would’ve been a Sev-1” is an outcome.

• Take credit for unblocking the business. If security review let a deal close, that’s a win worth talking about. If a compliance posture opened up a market, say so. If you’ve honestly improved the lives of a cohort of developers through your tool, library, or secure defaults, sing it from the mountaintops.

• Make the easy path the secure path, then market the easy path. Adoption is your best PR.

The skill we don’t train for

We hire security people for their technical chops, and that is the floor. The gap between a good security engineer and a great security leader is almost entirely in the selling and communication. Reading the room. Building trust over time. Framing a hard ask in terms the other side cares about. Knowing when to push and when to wait. Marketing the wins so the next ask is easier or even better, so engineering reaches out to the security team because they value our opinion.

Security is sales. The best security engineers are quietly excellent at it, they’d just never call it that.