90% of ‘your’ software is not written by your people

Alarming? Maybe, but that number is probably even higher for most.

Software development in the modern age is fortunate to build upon the foundations of the past. As a result, organisations can develop applications and achieve impressive levels of sophistication in record times.

One of the primary contributors to our development maturity is the plethora of Open-Source components that developers can leverage. A seemingly infinite collection of code from users across the world, available to you, for free. This obviously introduces Open-Source benefits, but it can also introduce Open-Source problems.

I remember coding my first website. I developed it in Perl as it was easier than C, and at that time helper modules were scarce. I coded my own cookie handler, I worried about execution times and had to keep the page small for a better end-user experience. After all that, my website looked terrible. Mostly just GIFs and an “Under Construction” banner.

Fast forward and any website can look amazing with little effort. Thanks to component libraries like Bootstrap, the UI heavy lifting has been done. Forms function seamlessly because of the Milk module, notifications pop-up thanks to the Toast modules; the list goes on, and on, and on.

Your new software solution will then likely sit upon more Open-Source. You might be hosting it on Linux OS, Apache, and PostgreSQL all of which heavily leverage Open-Source components.

If you’re reading this and thinking you purchase everything from IBM, Dell and Oracle so Open-Source is not my concern, you might want to think again. A lot of what is sold under an off-the-shelf banner is a solution-focused collection of Open-Source components with a commercial wrapper. If you’re lucky it might even be AI-powered and blockchain-enabled, but that depends on how good the vendor's marketing department is.

Open Source is a good thing, it’s all around us, and it’s here to stay. However, the “Open-Source Problem” will rear its head from time to time in meetings, and it’s a fair comment as increasingly as we start to see attackers use components as a vector.

So how can we achieve an acceptable level of risk when our system development relies heavily on Open-Source?

We can easily make this a very complicated solution. However, entertain me for a moment and let’s try a simple approach and apply a few understandable steps:

Trust it

• It’s all about trust. Do you trust the individual, the group or the organisation developing and maintaining the Open-Source Component?
  
  Do you trust them today, and will you be able to trust them next year to put in the required effort to maintain the component? Do you trust them not to sell to a Russian software house now that they’re downloaded over a million times? If you were the unpaid brain behind a popular component and a software house offered to continue the maintenance while giving you $100k, would you say no because of their political leaning?
  
  Trust is difficult. You need to work out how you evaluate trust and how often you reassess your decision.
  
  Look at historical behavioural trends. Past trends don’t predict the future but they’re better than blindly guessing. Ask yourself, is the component growing in popularity? Does it have a supportive community? Do the maintainers respond to bugs and vulnerabilities in a positive way? Do the maintainers live in an evil underground lair?
  
  Answers to simple questions such as these can normally give you 80% of what you need to know and there is a range of tools which can help you automate these steps.

Don’t fully trust it

• Just because you think you can trust something, does not mean you should rely on trust alone. That’s where you need defence in depth.
  
  Layered security controls and design patterns such as defence in depth are why your organisation remains safe when mistakes happen or when fixes such as patches take time to deploy. Most software at some point in its life will require patching, Open-Source Components are not exempt from this.
  
  Many of your Open-Source components will let you down at some point! You must prepare for this in your architecture by building in layers of defence. Control such as a WAF could have given you the ability to apply a temporary fix preventing Log4Shell from affecting your application.

Monitor it

• Finally, you need to monitor it. If you implemented the Duck component and suddenly it begins to Bark, then something might be wrong.
  
  Understanding how a selection of components is intended to function or has historically functioned is important. To understand if a system has rogue components (or users) you must have either an understanding of what good looks like or know upfront what poor behaviours you’re trying to catch.

When applied pragmatically, a few simple steps such as the above can bring a project reliant on Open-Source into risk tolerance.

Open-Source components can introduce risks if not deployed mindfully, but I often find the “Open-Source Problem” is a label attached to the symptoms resulting from a bigger problem. Poor Secure Software Development Lifecycle Management.

It’s beyond the scope of this article, but ask yourself a few questions:

• Does your organisation have coding standards?
• Do you develop unit and integration tests?
• Does your development lifecycle use key management in the CI/CD pipeline?
• Do your developers undergo regular secure code enablement training?
• Does your Agile development practice look like the Waterfall methodology but with new tooling?

If the answers to the above are not easy to satisfactorily evidence in your organisation, I would suggest Open-Source is only one of your problems. You likely have broader and more pressing secure development concerns.