Tech utopia or security risk?
The ideals behind open source software (OSS) are championed by many. Publicly shared code, which can be accessed, modified, improved and distributed freely by anyone. A truly collaborative effort for the greater good. With complete transparency, OSS should, in theory, be completely secure. However, certain security risks lie within this digital utopia, which is important to be aware of.
Does complete transparency equal complete security?
Just because code is available doesn’t necessarily mean that anyone will look at it. Many popular open-source projects are maintained by a minuscule number of developers, who are usually unpaid volunteers. Let’s take Monero, with a core team of just seven developers and an average of ten monthly contributors. At the other end of the scale is Linux, which according to the latest statistics, has over 4000 current contributors. Due to the sheer scale of the code – more than 30 million lines in the case of Linux, the number of bugs that need fixing runs into the hundreds. And even if a bug is found, there is no guarantee that it will be fixed quickly.
No quick fix
According to a recent report by the Linux Foundation, the average time to fix a vulnerability in OSS is 97.8 days, which leaves the software open to attack for over three months. While we think of OSS as an altruistic idea, it is important to remember that anyone finding a weakness may not create a patch but instead exploit it for nefarious means.
Real examples of security breaches
The issue of OSS security is not something which can be ignored. Recent security breaches include the well-publicised Log4j hack, as well as the colors.js and fakers.js sabotage. Both of these incidents caused very real issues, as so many businesses rely on open source enterprise software to keep them running.
Protect yourself!
The reliance on OSS will only grow further, and as the majority of people working on OSS code do not gain from it financially, the incentive to fix issues quickly is not always there.
That’s why anyone using OSS code to create new applications – or who relies on it for the smooth running of their business – should consider using professional help to assess the security of their open source solutions.
One way of doing this is by producing a Software Bill of Materials (SBOM), which should be an essential part of your DevOps process. Essentially, it’s simply a continuous, comprehensive list of all the components in your project, rather like the list of ingredients required for a recipe.
By using an SBOM and itemising everything you’re using, obsolete or unsafe code becomes much easier to identify. SBOM usage is something we will be looking at in more detail in our next blog post.
Protect yourself today – begin your complimentary assessment for an objective and an unbiased view of your software landscape.