This wasn’t my first attempt at writing software, in fact, I have been coding in various guises for over 40 years. During that time, I created personal collections of subroutines with common functions which could then include with any software I was developing. While you might be thinking… (yawn) “So what??”, the fact is that I didn’t use a Git repository or download publicly available frequently used functions from external sources. I wrote each of them myself for a specific utility purpose.

Any flaws in the applications or subroutines I built, I created. The corollary of course is that I couldn’t take advantage of the work others had done, and exploit solutions to common functions that might be more elegant than mine. My way of developing was slower than it would have been to use other people’s code, ideas, and methodologies, but I did not wade in the software swamps of flaws, unintended consequences or backdoors from the host of open-source contributors who publish content on repositories that potentially expose users to threat actors…

Some may think that the “many eyes” theory (aka Linus’s law) applies to Open Source Software (OSS). The theory goes along the lines that more people reviewing software from more perspectives will result in fewer bugs and therefore improved code quality, even if some of those eyes are the bad guys. The corollary to Linus’s law is the legacy principle of “security via obscurity”. The danger of proprietary code created with a “single vision” development methodology, which refuses to consider other views and perspectives, is that it may incorporate weaknesses (e.g., Log4j being a threat to a very high proportion of Java applications) thereby subjecting high-value targets to attack.

Recently cyber security conversations have begun to centre around software asset management. Where board level discussions view software from a licensing or permitted access perspective, given the monetary impact of software on an organisation, there may be a strong desire to control software deployed across an environment and its usage.

The idea of software development in discussions within an organisation, is often based on a legacy vision of programmers working singularly, or collaboratively, creating lines of code in the pursuit of a grand solution for a vendor. Software is assumed to come from a secured environment where the vendor maintains complete control of every line of code produced.

In today’s competitive business environment, costs are always under scrutiny. Organisations assess software licensing agreements forensically. Part of that assessment may include the discussion of whether #oss could cost effectively replace vendor #proprietary solutions. On a spreadsheet, moving away from a legacy software can make a lot of sense. However, the cost of making such a change may be greater than it first appears, taking into account the costs of securing the environment(s) where OSS run.

When business thinks of OSS, things like CRM systems spring to mind, but OSS includes a lot of things that aren’t immediately apparent to everyone like:

• Browsers (think Mozilla Firefox)
• Office suites (i.e., LibreOffice)
• Operating Systems (like Linux)
• Programming languages (including Java, Python or PHP)
• Blockchain (i.e., Ethereum, Hyperledger, Ripple)

If a company decides to transition from proprietary to OSS, they need to understand who has visibility of the internal workings of the code they have chosen. If anyone can see the internal structure of a software solution, that “anyone” will include hackers and other threat actors.

Proprietary software vendors may also incorporate OSS content into their product lines, allowing for quick releases of new features/functions or adaptation of software to new environments (perhaps #containerization or #virtualization). As with any use of OSS, there is a risk of creating new attack vectors for hackers to exploit.

In the November/December 2021 timeframe, there was a lot of discussion about the Apache #log4j OSS logging tool that is present in a significant percentage of Java application environments. It caused widespread concern being easy to exploit, ubiquitously present, and could (and did) have disastrous consequences.

Not only do software vendors need to look at their own use of Log4j, they need to look at subroutines and any subroutines used in those subroutines and so forth. Because of the “recursive” nature of the software development model, even with the knowledge that vendors and/or company development teams have reviewed their code for direct calls to Log4j, the risks associated with recursive use has caused Log4j to be classed as an “endemic” risk. In the same way that humans have learned to live with endemic diseases, companies now “need to learn to live” with the risks of Log4j and the myriad of other OSS flaws that may yet come to light regardless of whether they implement complete OSS solution suites or rely solely on proprietary vendor solutions.

So, how do companies protect themselves from “Open-Source Software”? The “knee-jerk” reaction is to remove all OSS software from the company. That may not be a practical solution, given:

• Costs of proprietary software
• Delays to new products/solutions being developed completely in-house
• Lack of available candidates with the technical skills, including secure design and coding, needed for bespoke development of new software and solutions
• Size of the payroll required to have enough staff to build everything a company could possibly need

While these steps would ensure software portfolio faults may be more easily attributed to one particular party (the vendor), these could end up driving a company into bankruptcy either through sheer costs or the inability to react quickly to market opportunities.

So, if we can’t do without “Open Source Software”, then what’s the alternative? If we consider the organisations which most benefit from the use of OSS, perhaps they should be contributing to its production – including for example by contributing funding toward specific security reviews and penetration testing rather than purely benefiting from “free use”. This would be similar to the business concept that any company building solutions internally will need to budget ~15-20% annually of the original build effort to maintenance of the proprietary software. Reasoning for the estimates comes from the fact that typical commercial software costs 20-25% for maintenance and support.

In order to address the vulnerabilities inherent in software, regardless of provenance, consider the following:

• First, understand that everyone is in pretty much the same boat, so it’s not just you or your organisation, which levels the playing field a bit

• Second, address the risks which arise from OSS being present in your environment:

• • A Cyber Security Survey will help identify the areas of highest risk
  • Run scheduled vulnerability including software vulnerabilities
  • Create or acquire a “Software Bill of Materials” for software in your environment
  • Establish a regular software patching program
  • Establish a Security Target Operating Model

• Third, educate your workforce on cyber security principles, as well as your corporate cyber posture, policies, and procedures

• Fourth, once you know your organisations internal Cyber Maturity, review the Cyber Maturity of all of your partners and technology suppliers so you can understand the areas of greatest exposure in case of an attack.

Once you design and implement a cyber security programme, complete your first assessments, and have a roadmap for improvement, then create a series of playbooks to cover the scenarios of greatest risk to your organisation. Having playbooks in hand will allow you to communicate staff responsibilities effectively and they can work as templates for table-top exercises to ensure outcomes are as expected.

Altus has introduced cyber conversations as a way to stop pushing products and packaged services as "the solution" to every businesses’ Cyber concerns and to start collaborative dialogues. With decades of financial services expertise and working along-side organisations like The Cyber Resilience Centre for the South West and APMG International, our goal is to support organisations at any and all stages of their Cyber journey.