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.


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.


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!”)




Starting Up Security

Guides for the growing security team

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

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