IT Employment

10 security challenges facing closed source software

David A. Wheeler described three necessities for developing secure software. Read about them, and ten challenges that face developers of closed source software when they try to satisfy those necessities.

According to David A. Wheeler's Secure Programming for Linux and Unix HOWTO, the three core requirements for developing secure software are as follows:

  • First, people have to actually review the code.
  • Second, at least some of the people developing and reviewing the code must know how to write secure programs.
  • Third, once found, problems need to be fixed quickly and their fixes distributed.

Wheeler's howto is one of the best online resources for people who want to start learning the technical side of writing secure software, and these three principles are non-negotiable necessities for widely distributed, truly secure software design.

While these principles are presented as part of Wheeler's explanation for how open source software has more potential for software security than its closed source counterparts, they apply to closed source software just as much as to open source software, and there's no reason these three principles cannot be properly employed to ensure secure software development in a closed source shop too.

There are some challenges, though:

  1. Independent code review tends to be extremely expensive when you require nondisclosure agreements.
  2. Free code review tends to be scarce with "source available" licensing, because people typically feel they're giving you something for nothing, whereas open source software is in many ways its own reward.
  3. The more code review, the better -- and even if you get some reasonable amount of review for closed source or "source available" code, you are unlikely to get as much as you could for open source code.
  4. Most of the best secure code writers understand that open code is the best way to get secure code (see Kerckhoffs' principle), which might make it difficult to hire them if you plan to keep your code closed.
  5. Hiring and retention decisions in corporate development shops tend to ultimately rest in the hands of people who wouldn't know secure code if it bit them on their noses.
  6. Corporate responsibility lies with shareholder profits -- not the actual quality of software. This means that any time the ability to generate revenue or reduce costs conflicts with secure coding goals, the secure coding goals are likely to suffer. Considering the value of good programmers who know how to write secure code, that means that severely limiting the money the human resources department is authorized to offer for new hire salaries is normal behavior, which in turn limits the ability to hire the best programmers.
  7. Comprehensive software management systems, such as those found in open source Unix-like OSes like APT for Debian GNU/Linux and the ports system for FreeBSD don't carry closed source software anywhere near as often as open source software, and the software management systems for closed source OSes like MS Windows usually don't handle any third-party software at all anyway. This means that rapid fix distribution for closed source software usually relies on end users hunting down news of fixes, then acquiring and installing patched versions of software, themselves.
  8. Corporate responsibility is an important factor for patch distribution too; it is usually in a corporate vendor's best short term financial interest to downplay security vulnerabilities, which often involves deferring development of security patches (sometimes indefinitely) and even hindering the ability of users to find reliable information about vulnerabilities and fixes.
  9. Identification, development, and testing of security fixes depends on the availability of developers and testers. Releasing software under the terms of an open source license tends to increase the number of available developers and testers significantly.
  10. As David Wheeler pointed out in the Secure Programming for Linux and Unix HOWTO, you cannot very easily make changes to closed source software on the spot the way you can with open source software, given the necessary in-house expertise.

None of these disadvantages for closed source software are inflexible or absolute. There's no reason closed source software developed by a corporate vendor can't be as secure as an open source equivalent. It should be pretty obvious that, all else being equal, the trend is for circumstances to favor the security of open source software -- at least as far as these principles of software security are concerned.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

10 comments
CodeSeeker
CodeSeeker

Great! The best analysis I have ever read on this topic! Irrefutable demonstration ...

Tony Hopkinson
Tony Hopkinson

mention, and it's more of a corrolary. Is that closed source development has a tendency due to other factors you mentioned to drift to monolithic designs. That of course exacerbates just about all the other issues leading to a vicious circle of poor choices and worse implementation.

brooksgr
brooksgr

I work for a corporate IT department that mostly uses Open Source software running on SUSE Linux. Stuff like Tomcat, Hibernate, Apache, etc. Where is all this software management and automated patches? Nowhere. Not only that, automated patches could easily break our code. Most of the issues raised in this article are bogus. First, it is well known that Open Source programmers lose interest in one project and migrate to something else frequently. So much for support, patches and security. Security is hard work that few people will volunteer for. Open Source advocates are living in a dream world, but in our organization we are paying the price. We get less performance, higher cost and less security, and we use main line OS products. Less performance - because we use a very deep open source software stack to get what we need, and it is typically very slow. Higher cost - because most of these projects are just starting points, and we have to do a lot of programming to get what we need. Less security - because the foundational components we use have hundreds of unpatched security issues, and the code we write around them is itself probably not scrutinized sufficiently. Dream on, open source people. There is a real world.

apotheon
apotheon

Several of the ten listed challenges are just consequences of an underlying problem for secure software development in a corporate environment: the fact that the only security a corporation's representatives ultimately care about is the security of a revenue stream. Are there any other security challenges facing closed source software development that you would like to add to the list?

shardeth-15902278
shardeth-15902278

But in your first paragraph, you appear to complain about the lack of automated patching, and then point out why automated patching is a bad thing anyway. What did I miss? As for management solutions, I believe Novell has corporate grade solutions available. I don't think they give them away for free, but then MS isn't passing SMS out for free either, right? OSS programmers losing interest and moving on, I'd be curious to see a real statistic on that, vs closed source programmer longevity. My guess is they are pretty even. And with closed source, regardless of the size of the company behind it, if they lose interest and decide to Shelve it, well, that is pretty much that. Whereas w/ open source, you can pick it up and keep it going, or if you aren't a programmer yourself but can afford it, you can hire a programmer to keep it going. If anything, you have demonstrated another security challenge of closed source software - a denial of service issue of sorts...

Tony Hopkinson
Tony Hopkinson

If you can see the issues, join in and fix them, at least raise them with the requisite groups. Open source people do not move on when they lose interest, they move on when you show none! They think they've failed! You aren't giving them anything, not even a complaint! ffs.

seanferd
seanferd

Selling separately things that should be a core part of the software, integrating things that should be separable.

dragon
dragon

9 times out 10 no-one does anything... open source = FUBAR far to much of the time!

Neon Samurai
Neon Samurai

.. and where they to the original project since you took the time to post them? Either way, it's still better than deny by default responses from closed source. "it's not our bug, it's theres.. go talk to them" and when you do "nope, it's the third parties bug not ours, talk to them".