Who Fixes That Bug?

Part Two: Us!

Ryan McGeehan
Aug 14, 2015 · 4 min read

In part one, we discussed how a security team can’t be depended on for the entire burden of fixing application vulnerabilities within an organization.

Here we will discuss the characteristics of a “security engineering” and how it can vary greatly from company to company. They differ on the amount of vulnerability research, software development, bug triage and awareness they take part in.

Non-Dependence on Security

To avoid having the same engineers hit with bugs over and over again, on call bug rotations can push a sharing of responsibility among engineers. Facebook employs this well. This avoids long tenured engineers from racking up tons of bug debt. Rotating a large bugs on-call for each product area is a great way to avoid slamming the entire burden of security on a single team, and is just good organization for bugs in general. Not to mention the benefits of onboarding new hires into them, or pollinating engineers with other products or technical areas.

Any dedicated security frameworks and infrastructure will still need to be owned and built, though.

Builders

All “breaking” will be in the form of formal consultant audits and disclosure programs, or internal bug finding automation.

This approach may end up shouldering the entire burden of security if expectations aren’t set. The goal with this mindset is to focus talented engineers on long-game mitigations that other developers can use.

Breakers

This approach carries high risk of exclusion from product road maps. Especially if all they do is complain about the flaws in launched products and slow down progress.

Split Responsibility

The best security engineers I know on the “builder” side express disdain for becoming “owners” of largely unowned code simply because they understand it from preparing multiple fixes. Years into a role, they’ll find themselves maintaining a static amount of debt from others. I rarely see this solved well, but might be solved by having clear expectations on who reviews and maintains a fix and strong rotations as mentioned previously.

Having this more nuanced approach avoids needing the security team to be a subject matter expert in everything, forever, as their role requires them to bounce around to every part of a code base at some point. However, being vague, can cause conflict in a territorial culture.

Agents and Advocates

This approach requires care and feeding. It’s mostly beneficial to reign in a complex organization that deals with inherited technology from M&A or global presence. In non-engineering contexts, this is useful for awareness endeavors too (“Hey Finance! Use strong passwords!”)

Conclusion


@magoo

@libber

Starting Up Security

Guides for the growing security team

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store