During my 20+ years of writing software, I admit to succumbing to my programmer’s code mocking reflex more than once. “I could have done that much more elegantly/simpler/better” is a common thought for a programmer while reading through other programmers’ code. A sentiment that is probably inherent to programming, since software code represents its author’s way of thinking, of structuring and solving problems: a highly individual streak, unique to every person. Immersion into the thought structure of another programmer often has literally a very uncomfortable feel to me, comparable to wearing my right-hand glove on my left hand. And there’s a great way to avoid this uncomfortable feeling: Just ditch the other person’s code, and start from scratch, my way. This is known as the not-invented-here syndrome, of course. Objectively, whether starting from scratch or using the existing, “foreign” code is more suitable depends on the situation. There is no right or wrong per se.

Make or buy?

As some programmers turn into managers, and some managers eventually into CIOs, the not-invented-here syndrome sticks with them: Many companies develop their own software when there are products on the market that would, at least at first glance, fulfill their requirements at least as well, if not better. Again, there is no right or wrong. Make or buy decisions typically take into account many factors, and people will probably always disagree while judging the available options. But when discussing those decisions, I often get the impression that especially former programmers try hard rationalizing a decision that is mainly rooted in that feeling so similar to wearing a wrong glove. Knowing where this is coming from, I tend to sympathize with them, and often favor specific, to the point in-house implementations over generic off-the-shelve standard products. But there is an exception: Security software.

Security software is different

This is an area where my internal judgment scale is highly loaded on the “buy” side. Why, you may ask, what’s so special about security software that makes me nearly always recommend buying over making? A few weeks ago, while having a program concept assessed by us, the customer asked exactly this. The question gave us a welcome opportunity to discuss the topic amongst ourselves, it helped us challenge and re-confirm our own perceptions. In the end we still agreed that in general, security software is better bought than made, for the following reasons:
  1. Bugs: All new software comes with bugs. While this can be a nuisance in most areas, in security it can pretty much defy the whole purpose of introducing the software in the first place. Using something that has been around for a while reduces the risks of falling prey to a crucial bug.
  2. Developers: “Security” is not just another requirement that can be jotted down on a card and put up on the Scrum or Kanban board. Like “Usability”, it permeates every aspect of programming, and requires a specific focus and sufficient experience to work around the many pitfalls of data insecurity. Programmers with this focus and experience tend to work in the security industry. Chances are there won’t be enough of them on your development staff.
  3. Testing: Collective knowledge about good testing is ever increasing, with more and more teams adopting techniques like test-driven development, continuous testing, hallway testing, etc. But testing of security products adds a whole other dimension to testing. Typically, development teams for security software have put rigorous processes in place to ensure that what they release fulfills its purpose: is secure.
  4. Penetration testing: You benefit from other users’ testing efforts: Not only does the manufacturer test very thoroughly. Many customers also perform penetration tests on their environment, some even regularly, up to several times a year. Information about detected vulnerabilities goes back to the manufacturer, who can solve the problem to the benefit of all the other users.
  5. Vulnerability monitoring: Even the most ardent advocate of “do it yourself” development will rely on external libraries and components for some parts of his system. And these components and libraries may have security flaws themselves. Every day numerous vulnerability reports are being published by various organizations. Monitoring these reports, detecting the relevant ones and reacting appropriately is something a security software manufacturer dedicates considerable resources for. Our “do it yourself” advocate may easily miss some crucial hint that all his efforts of building a secure system are in vain due to a big gaping hole in a part he didn’t code himself. And most importantly, this is something that never stops, for the whole lifetime of the software.
  6. Core business: From a business perspective, it’s most likely better if a company puts its software development efforts into developing core business solutions which help differentiate itself from its competition, rather than working on something that is certainly required, but will not help with generating business in the first place.
Of course this is all only true if the security software vendor in question can provide convincing proof that he is covering all these points.
So next time, when you find yourself having to decide whether that entry gateway or that authentication server should be bought or made, also consider to which extent you’ll be able to supply the project with adequately trained and experienced developers, sufficient testing resources, ongoing vulnerability monitoring for the whole lifetime, and to what extent you can live with newly found bugs in your system, and the absence of other users doing some of the testing and vulnerability finding work for you. And finally, decide whether security is part of your company’s core business, or just an auxiliary function.