Why Your Code isn’t as Secure as You Think (and What You Can Do About It)
Erik Dietrich asks how well you really know you code, the dangers of not knowing, and promotes the value of making code reviews part of your process - which can help secure your code.
Join the DZone community and get the full member experience.Join For Free
How well do you know your code?
It sounds like a strange question, but please indulge me.
Maybe you’re a manager or business analyst. If this is the case, you ‘know’ the code through a translation layer in which the developers in your organization explain what it does. Sometimes you can see what it does by interacting with it as a user or by reading incident reports.
But to really know and understand what it would do — to have a grasp on how it will behave in an arbitrary situation — you need one or more developers to give you an explanation.
Maybe You’re a Developer
In this case, you don’t need a translator. If you’ve written the code, then, presumably (hopefully), you can explain how it works in arbitrary situations. If someone else on your team, in your group, or from your department has written the code, you might not know it quite as well. But, with a bug report, an afternoon, and your IDE, you could figure it out. That’s assuming, of course, that you have access to the code and some reason to look at it.
Depending on the size and scope of the codebase or codebases that the company has in production, any given developer may be utterly and permanently clueless about some corner of the application. For any given piece of code, someone knows something about it, assuming the author has not departed the company, but the knowledge coverage may not be especially deep.
For any given bit of code or a corresponding bit of functionality, how many people really know what’s going on? Could it be fewer than you think? Maybe just one person? Maybe even… no one, in the event that the original author has long since departed?
The Danger of Shallowness of Knowledge
Cisco recently announced the launch of an internal code review. This was done in response to Juniper performing a similar sort of internal audit and discovering code that would allow secret, remote access to its firewall products. The linked article makes allusions to the NSA and some pretty cloak and dagger stuff, with it not being known at the time of writing how this code found its way into production.
I can tell you from my own experience that such a thing would be appallingly easy, in some situations. I’ve personally been in situations, particularly at smaller companies, where I was the gatekeeper between the codebase and production deployments. I could literally have sneaked a condition into the codebase that appended “|| password == ‘Erik’” that would have given me carte blanche access to a production system for as long as I worked there and quite possibly long after I’d left.
Of course, I’ve never done any such thing. And frankly, I doubt too many developers have either. If a developer were going to do something like this with any sort of ill intent, I suspect that he’d be a lot more clever about it. The resultant code would almost certainly be more subtle and come along with plausible deniability. “Oh my,” he would later say if confronted, “I can see now how that BUG would allow someone admin access – I had no idea!”
I have never done such a thing, nor have I ever been tempted.
But the fact that it would have been possible for me to do it easily is a huge process smell. It indicates that there is a perilous shallowness to the knowledge of the code. You typically see this in small, understaffed shops where the development team is spread quite thin. But no one is really immune – it just takes that one module that no one but Alice really knows too much about.
This situation is so dangerous precisely because there are all manner of ways that Alice as the only link in the chain can break. Maybe she inadvertently opens a security hole. Maybe someone socially engineers her somehow to inadvertently open a security hole. Maybe she’s paranoid about being fired and builds in an ‘insurance policy.’ The list goes on. But if Alice is the only one with eyes on what Alice is doing, weird, unpredictable, and problematic things could be brewing.
In short, and to return to my earlier question, you don’t really know what your code is doing if you have to take a single person’s word for it.
Code Review to the Rescue
It should surprise no one that the solution to this problem is an all-hands-on-deck audit.
There is no faster way to increase the organizational knowledge depth of the code than to bring in an army of people to read, review, understand, and question existing it. To appropriate Eric S Raymond’s famous quote, “with enough eyes, all backdoors are visible.”
But this sort of Herculean effort is extremely costly and evokes the phrase, “closing the barn door after the horse has escaped.”
Throwing a lot of people at a massive code audit is expensive both in opportunity cost and in wage cost because at least some of them will presumably need knowledge of the codebase. It’s also probably the case that your reputation has suffered a hit and that you’re scrambling to cover yourself. This is not only wholly suboptimal but easily preventable.
All that’s necessary is a culture of regular code review. On the surface, code review seems like a costly exercise that’s often a luxury. After all, each hour spent reading someone else’s code is an hour that the engineer could be writing new code. This argument, however, tends to fall apart quickly on deeper inspection.
Code review is one of the most effective ways to reduce defect counts, and that alone probably recoups the return on investment. But a more subtle, more germane benefit is that code review promotes a culture of collective code ownership.
Collective code ownership is the idea that there isn’t “Alice’s module” and “Bob’s module.” Members of the team do not silo and do not own code. They work on one section of the code or one feature, and then move on to a different one. They collaborate heavily on all code being written, through pair programming and/or code review. This creates a culture in which the team owns the code. And when the team owns the code, the possibility that any one developer will take out an ‘insurance policy’ becomes orders of magnitude smaller.
Anyone with a stake in production software worries about their code. Does it do what it’s supposed to? Does it perform well? Does it look good? How safe is it? There are few easy answers when it comes to questions like this.
But when it comes to the safety of your code, you have the good fortune of a no-brainer at your disposal: create and nurture a culture of code review.
Surprised at How Effective Code Review Can be at Securing Your Code?
There are other benefits to code review that may surprise you. Check out our newest eBook, 10 Things Developers Wished Their Boss Understood About Code Review, to learn more.
Published at DZone with permission of Erik Dietrich, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.