At ISC2 Security Congress 2024, delegates explored the cybersecurity considerations attached to the growing use of open source technology and asked whether complete access to the code base tempers benefits with increased security risk.

Andrew BoyleDiscussion of open source software does tend to divide any audience. At ISC2 Security Congress 2024 in Las Vegas, Andrew Boyle, CISSP, Distinguished Digital & Cybersecurity Technologist at Booz Allen Hamilton questioned whether the transparency brings with it too great a vulnerability risk.

On one side of the fence are those that Boyle describes as fans of “COTS” (Commercial Off-The-Shelf) software. Opposite them are the open source community whose view tends to be fairly well-known (no acquisition or maintenance costs, no vendor lock-in, scaling up and down without costing or wasting money, and so on).

A report Boyle cited said that up to 90% of modern software includes open source elements, with open source included to some extent in a massive 98% of codebases. He clearly seemed determined not to sit on the fence: “Whose holidays in 2021 were ruined with Log4j ?” he asked.

This question was compunded by Boyle’s observation that the idea that transparency of code (that is, the ability to look at the source code and maybe even change it) increases security was offset by the point that fewer than 10% of us actually modify open source code to fit our purposes.

Who Should Test?

The observation was noted that COTS is subject to thorough cyber testing and certification, whereas with open source code we’re expected to do that ourselves because the producers may not have done … not least because almost a quarter of top open source products have just a single developer working on 80% of the code. This leaves little resource in the open source world for the testing element that prevails in COTS.

“Okay, how many [of you] like to do the cybersecurity and the documentation?”, asked Boyle. Two hands in the audience went up. Then for a quiz question: “How much more popular is the usage of Log4j version 2.x than Log4j v1.x?” … which turned out to be a trick question because despite it being almost ten years from its end-of-life date, Log4j 1.x is still ever so slightly more common than the more secure 2.x.

“How many organizations using open source software are rigorous about their Software Bill of Materials (SBoM)?” was the question Boyle posed to attendees at Congress. Hard to tell, came the answer, but given that open source software may well rely on other open source components, which may rely on other open source components, which may … well, you get the idea … this means that if organizations do not use automated SBoM monitoring software then it can be impossible for cybersecurity professionals to keep track of nested dependencies that may go 10, 11 or more layers down.

Boyle cited the so-called “Left-Pad” incident in which a developer who wrote an innocuous, 11-line OS JavaScript library got into a trademark dispute with a company, took his library offline, and (much to his surprise) impacted what is believed to be millions of users.

Open Source Remains Essential

Although Boyle was constructive in detailing the various potential shortcomings of the open source software base, the message turned around into something less negative, but with caveats of how one can take open source software and deploy it in a way that ensures it remains usable, useful and secure:

  • If you want to use open source software, the SBoM is absolutely critical: use automated tools to ensure that you know what you are using, particularly the elements that are buried many layers deep in sub-sub-sub-sub-modules
  • Keep your open source software up to date, but cautiously: on balance newer is better, but be cautious of bleeding-edge versions that might have been compromised but nobody has yet noticed
  • Understand code dependencies. Boyle was right to call it out because this is one of the key things you need to do and the SBoM is just one of the tools that can help you
  • Be sensible about your choices. Prefer repositories with code signing over random sites that you haven’t heard of, for instance, and make the most of the vetting services of well-known organizations like Google and its Assured Open Source Software regime
  • Train everyone across the board who might have something to do with the decision to adopt open source modules and the development of software that uses them. Forewarned is forearmed
  • Don’t trust anything or anyone in the open source supply chain: scan, monitor and act on alerts because no matter how rigorous you are about understanding the provenance of your software, just remember that the likes of SolarWinds were pretty rigorous too

Should you shun open source software, according to Andrew Boyle? No. But don’t just accept all the open source supporters’ cheerleading at face value either. Be cautious. Have controls. Be skeptical about the stereotypical claims of the community about how open things are, because few of us actually do anything about this.

Because software is like anything in our organization: before we do it, we need to understand and deal with the risk. Once we’ve mitigated the identified risks, there is every chance that the end result can be of benefit to the organization.