Mountain climbing and software development: with some precautions, both can be safe. Image source

Security work can often be divided into two parts: people and computers. The relatively new role of security partner is ideal for those who like both, as it involves working to meet the company’s needs for a secure system and needs of engineers to have a reasonable technical solution to execute and maintain. Does it sound complicated? It is! But that’s what makes it satisfying and why the security partner role has become more common across tech companies.

Gusto’s Security Partners team sits within Product Security, and we’re far from the only company that’s recognized the need for this role. Meta, Atlassian, Netflix, and Microsoft, among others, have formed teams dedicated to helping colleagues write more secure code, understand security concerns for new features, and identify and reduce risk.

I took this job because it combines so many different skills, equally weighing technical acumen and those that enable useful collaboration with different audiences. And the collaboration skills are key, because it’s at the center of this work. I can’t usefully write a document, complete a feature review, or offer risk mitigation without a good working relationship with the teams I partner with. If they wanted a generic assessment of the risk of cross-site scripting, they could Google; they come to my team when they want to know how to weigh the risk implicit in features with respect to how Gusto specifically operates.

But what does security mean at Gusto? Who owns risk here?

Hint: it’s not our security teams. Our CSO Fredrick Lee expands on this approach in his BSides SF 2020 talk; the tl;dr version, as it applies here, is that at Gusto, engineering teams own the risk of the code they write and the features they maintain. That means that my job—and this is something I say to every new PM, team, and engineer I work with—is to keep them from being awakened at 3 am by the PagerDuty summons no one ever wants to get. We’re here to educate, not dominate, and I work to make sure that engineering teams avoid all the surprises they reasonably can. This also means that it’s our job to share security knowledge and responsibility across Gusto.

A week in the life

Let’s talk about what that means from day to day. It’s rare for two days in this job to be substantially the same, so I’ll give you a sample calendar of what a week in this job can contain:

Monday

  • Hold a monthly conversation with an engineering team PM
  • Set up a feature review
  • Scan Slack to find unanswered questions
  • Investigate a Bugcrowd submission

Tuesday

  • One-on-ones with teammates and manager
  • Review notes from recent feature review meetings
  • Draft a new feature review
  • Update existing documentation based on a risk surfaced in that feature review

Wednesday

  • Lead monthly Secure Code Training
  • Review a fellow security partner’s draft feature review
  • Talk to an engineer who located a missing part of our documentation
  • Initial work on writing that missing document

Thursday

  • Code review for critical PR
  • Answer questions about new feature design
  • Incorporate feedback on initial draft of missing documentation
  • Another PM meeting

Friday

  • Deliver feature risk analysis to team and setting up meeting to discuss
  • Answer engineer questions via DM
  • Research specifics about S3 storage and access
  • Review next week’s meetings to ensure I’m talking to everyone I need to be

You may have noticed a lot of meetings in this sample schedule, which is where that relationship-building work comes in. My job doesn’t work if I don’t know what’s going on, which means talking with people regularly and ensuring those conversations are interesting, maybe even fun. It’s important that I really like talking to engineers, and I think it would be difficult to do this job well if I didn’t.

Of course, not all connections can be made on a one-to-one basis. Teams and staffing shift, and we don’t have partners assigned to every engineering team in Gusto. To let engineering at large know what support is available, we do relationship building at scale by holding trainings open to the whole company, being part of every engineer’s onboarding, presenting in all-hands meetings, and regularly being the friendly faces of Gusto Security. This helps ensure people know how to reach us and that we really, truly want to hear from them.

Being in the right conversation at the right time requires some luck, but we try to make it as strategic and deliberate as we can, because this work doesn't go without knowing what’s happening across Gusto and offering security’s help when it’s needed.

What experience does a security partner need?

The perpetual question: how do I get that security job? And the perpetual security answer: it depends.

I came to security the long way via years in editorial, followed by a switch to full-stack engineering, and then moving into site reliability engineering and then enterprise security work. Understanding tech is imperative to being effective in this job, but the skills I use the most from day to day are my ability to ask questions, talk to colleagues until I get the answers I need, and change the way I deliver a message based on the recipient. I highlight different elements of an issue depending on if I’m talking to my team, my PE (Gusto speak for manager), all of security, our chief security officer, a product manager, or various Gusto engineering teams. My vocabulary changes again if I need to discuss security practices with coworkers outside of engineering.

My teammates have more traditional backgrounds than I do (read: computer science degrees, vs. my own BFA in writing and publishing), but we share an interest in working with other people. Our experience makes it easier for us to get into different dev mindsets, which is important for effectively communicating security concerns, but it doesn’t work without empathy and knowing how others learn and understand.

If you’re considering this work, development and security experience are critical, arguably more than other security roles. You can learn security fundamentals on the fly while you’re building tools, but it’s harder to do that in conversation (though the ability to say “I don’t know, but I’ll research and get back to you” is critical too).

The more out-there parts of my experience that contribute to my ability to do this job are my background in consulting, knowing how to work with different kinds of people, and my public speaking work. Doing conference talks is generally professionally helpful in this field, but my talks in particular usually focus on relating specialized information to a wider audience, and I think said talks offered an accurate preview of what I’d do in this role.

Why would you want to do this work, though? If any of the following are true, security partners work might be for you:

  • It makes you happy when your work varies a lot and is done with lots of different teams and people
  • You like to learn constantly because you don’t work from start to finish on a single feature
  • Your preferred colleagues are a wide range of engineers and security professionals
  • You enjoy writing documentation and teaching
  • A combination of working with people and handling technical needs makes you happy
  • Enabling other teams to succeed gives you professional satisfaction

Perhaps just as importantly, why wouldn’t someone like this job?

  • You measure your success in code contributions
  • You prefer to stay with a single project until it’s done
  • Explaining the same thing more than once sounds exhausting
  • You’d rather execute than plan and optimize

It’s a very different sort of engineering work, but that’s what I was looking for. I like talking security with people; it’s a conversation that usually elevates everyone involved. I also wanted to work at a company small enough that I could take ownership of problems and large enough to have a robust team of smart people to learn from.

All customer data at any company should be handled with the greatest care, but the specific challenge of data around payroll and benefits is an important one to me. I come from a family of small business owners, and I’ve seen firsthand how this kind of administration gets really complicated. I want small business owners to have one less hurdle between them and their dreams, and I want them to know that their critical data is in good hands. It makes me happy to be able to contribute to that for even a single employer.If any of that sings to you, maybe you’re security partner material too. Check out Gusto’s careers page to see what roles are open, and maybe you’ll get to work with our team too!