In the world of software development, there are two kinds of fundamental code from which to build systems. There is open-source software (OSS) and there is closed source software. Closed source, which is made “in house”, is protected and private. You can think of it as IP.
Whereas, OSS is like a community garden for software developers to pick up existing, ready made building blocks for their systems. Instead of writing from scratch, they can use fully formed components and modules. According to an article from Forbes, 96% of scanned applications contain OSS components. With those numbers it’s clear that OSS is a deeply embedded part of software development culture, and it’s one that must be properly balanced and managed.
A brief history, how the OSS library was born.
The idea of the open code library is one built on a desire to contribute, as well the sweetness of being a part of a like-minded community. In 1991, Linus Torvalds, the grandfather of OSS, was working on a free open source operating system as a hobby. After some time, he made his project public and requested feedback in order to improve it. It was from this humble seed that the mammoth that is OSS today, was born.
20 years later Linus mentioned in a Ted Talk that for him, it was simply having 100 people interested enough in his work that was the peak of his satisfaction. 100 was this critical mass, and not the jump to 10,000 he states, which made him feel like he was a valuable part of a greater whole. Together he and his community were working towards something meaningful.
Today, OSS is maintained and improved upon by an army of volunteers, unpaid. How large is the army? 100 million strong, at least. Like Linus, many programmers find a deep sense of purpose in contributing to the whole. They get to enjoy the fruits of their labor and know that those fruits are being enjoyed by others.
So, what’s the risk?
With so many contributors and frankly so many components of OSS- it’s hard to manage security. By its nature, there is no fence protecting this wholesome and pure garden. Anyone can walk in and grab an apple, which is great, but it also means that anyone can walk in and try to exploit it. Which is not so great.
In 2021, a very widely used, and thought to be secure component of open source code was exploited. This component, called log4j, is built into the foundation of millions of systems. And its exploitation was the wake up call, the breaking of innocence regarding the community garden. They needed a fence.
The issue is, a fence is not possible. What is possible is checking on the fruit before consuming it to make sure that it’s secure and vulnerability free. The question becomes- who is responsible for this monitoring? Well, we definitely don’t think it’s software developers.
After log4j, the US government decided to take matters into their own hands and committed to monitoring the community garden. They did so by creating a database that identifies which components have vulnerabilities.
How can you keep your software safe?
The best way to do this is by first becoming aware and understanding what your source code is made of. This is accomplished by ordering what’s called a software bill of materials. At BonCode, we offer this service and check your components against this US database. From there we are able to help identify the level of risk a vulnerability presents, and subsequently, which components need to be updated within your system. One of the key metrics we look at is how often a component with an identified vulnerability shows up in your source code. Say that vulnerable component “X” shows up 15 times in your code. Not a terrible concern. But say it shows up 6,000 times- that means your software is facing considerable exposure and the risk needs to be mitigated.
Ultimately, as was shown in the log4j example, the risk of leaving outdated open source components in your software is essentially like having a flimsy lock on the front door of your home. It might work, but if someone pushes hard enough, they could break in. With this understanding, the US government will no longer purchase or incorporate software which does not have a bill of materials and the requisite upgrades in accordance with the database. Seems like a pretty strong message about the importance of this stuff, doesn’t it?
By scanning your source code and open source components with BonCode you can be sure that your components are up to date and secure. We would love to help you do so!
