Method names alone are not evidence of malicious activity on the part of a developer.

(I should write more on this subject, but for now that’s the entire post)

Consider a scenario similar to the previous post, where there’s some big security issue in a project that wants to ship soon. Instead of stopping the project in its tracks, you decide to let it go. Why is that?

Reasons to let it ship

• Investigate further and discover whether the security issue is really exploitable. As a side benefit, maybe this will give mitigation ideas. (More on this later)
• We’re here to build useful products and make money, not to build a perfect work of art. Maybe after stepping back and thinking about it some more you can convince yourself (and others) that it’s actually a reasonably secure design despite the issue you’ve found.
• You don’t want to damage the relationship with the product team because it will hurt the overall mission.
• The number of people on earth that have the skillset or access necessary to exploit the issue is in the single digits, and none of them are going to be motivated to do so.

Mitigations

Rather than just letting the project ship unmodified, maybe you can work out some kind of mitigating controls. Examples:

Shipping projects at a big tech company is very challenging work. Much can be written on the subject (such as Sean Goedecke’s post on how to ship), but it’s not my area of expertise. Instead, I work to make sure that projects don’t ship. Or rather, that projects that shouldn’t be shipping don’t ship. I do this for the same reason doctors sometimes measure success in terms of “nobody died who shouldn’t have”. Projects should be built to meet the security needs of the business without introducing risks that are likely to make the project cost more than the revenue it brings in. I want to ensure that we aren’t shipping projects with unnecessary risks when we know how to mitigate those risks.