Image courtesy xkcd . Do you really know what’s in open source code?
Do you want to?
Because face the facts: your organization is making use of open source code right now – and you probably have no idea what’s in it, how recently it has been updated, or even if you’re allowed to use the code in your proprietary projects!
Whether you know it or not, your developers are likely leveraging open source tools to speed up the development process and enhance the functionality of your product.
This can come with many great advantages for the development team and your organization as a whole, but you might also be thinking of what the disadvantages of using open source code could be. One of them is the potential for a bad actor to gain access to the source code (or for the original developer to sabotage the project themselves, like in the case of “faker.js” and “colors.js” ) and modify the source to contain malicious code.
Another consequence that your organization could face is accidentally using open source code with licensing that makes it illegal to distribute your software unless it is also open source and offered for free, otherwise you could face copyright infringement penalties.
There are several steps your organization should take to begin managing open source code in your environment to improve the overall visibility and security of the situation.
Maintain a List of Open Source Libraries
One of the first things you should start doing to manage open source code is to inventory and track what open source projects your developers are actually using.
This list should ideally be kept in a repository that all developers have access to and are able to update when they have a new open source library to add. Track and record the library being used, its current version number, when it received its last update, and what type of licensing the open source library utilizes.
The list should also be reviewed on a quarterly or annual basis determined by how frequently it is being updated. When you begin to put the list of open source libraries together, it is important to socialize the new process to developers so the list can be properly maintained.
Having a full inventory of your open source libraries makes it easier to identify if your organization is vulnerable to new exploits and gives developers full insight into the various open source tools being leveraged in the development environment.
Restrictions on Outdated and EOL/EOS Libraries
Now that you have a shiny new list of all of your open source libraries, it’s time to determine if any of them should be decommissioned or replaced.
Any libraries or projects that have reached their End of Life or End of Support should no longer be used in your production environment – the risk they pose to your organization is high and will only grow as time goes on.
This is because once a library is no longer being supported, it won’t be patched against new vulnerabilities or updated to work with newer software and operating systems.
It’s important for your organization to identify any libraries fitting this criteria and immediately create a plan for remediation. Your organization may decide to put tighter restrictions on component age and not allow the use of any libraries that have not received an update within the last 3 years for example.
It is up to your organization to determine the risks and benefits when deciding on open source library age restrictions.
Library Update Requirements
Once you’ve identified and resolved the libraries that have reached their End of Life, you should take a closer look at when the remaining libraries on your list were last updated.
It is important to stay up-to-date on your patching and have it done at regularly scheduled intervals. It can be easy for open source libraries to go unpatched, because it’s usually not at the top of developers’ minds while they’re focused on improving and testing your product.
Implementing a process for planned and consistent updates to open source libraries is key to reducing your risk exposure to new exploits. What this looks like will depend on your environment – it is best to plug this practice into existing processes.
Next, you should start determining which open source libraries are coming from trusted repositories that your organization knows they can rely on to be stable and secure. There is no simple answer as to what repository can be trusted or not – it is up to each organization to decide their criteria on what makes a trusted repository.
Restrictions on Acceptable Licenses
All open source software is licensed in one way or another and which license is being used can vastly change how you are allowed to use it in your own proprietary software.
There are a variety of different open source licenses, so it’s important to check the license of any open source libraries or software that your organization is using.
Some licenses allow for the open source code to be used and licensed within your own software, while other licenses require the use or modification of open source code to also remain open source, meaning you can’t actually sell your product (at least not legally).
This distinction can be made by determining if the license is permissive or copyleft .
Permissive licenses do allow you to use open source code in proprietary software, while copyleft licenses do not allow you to use open source code in proprietary software.
Developers should be permitted to use code and libraries with permissive licensing and prohibited from using any with copyleft licensing.
Public Repositories and Open Source Contributions
When managing open source code, it’s important to look at code that’s been externally developed – but you shouldn’t forget to discuss internally developed code as well.
While your developers may be pulling code from public repositories, it is extremely important to make sure they are not also committing internally developed source code to public repositories. There could be massive ramifications if it was found that your organization’s proprietary code had been pushed to a public project.
The best approach for avoiding this is to raise awareness of the issue and properly train developers on best practices. Describe the importance of managing open source code in your environment from a security perspective, but also explain to developers that it will make the development process more efficient and streamlined because it’ll give them more immediate insight into approved libraries or repositories and they’ll know what tools their team members are using and proficient in.
Another thing to consider when working with open source code is how your team will handle the discovery of any vulnerabilities they find while working with the code.
It’s almost always best for your organization to reach out to whomever maintains the open source code and bring the vulnerability or finding to their attention so they can implement a fix for it. You may want your developers to have a legal review before submitting any open source findings or other company intellectual property to an open source repository or developer.
Open Source Policy
By now, you’ve got your open source practices into shape!
You’ve created a list of all of your open source libraries.
You’ve decommissioned any libraries that have reached their End of Life.
You’ve implemented a process for updating open source libraries and automated patching for those from trusted sources.
You’ve determined if the libraries you are using have permissive or copyleft licensing and prohibited the use of the latter.
And you’ve created guidelines for using and committing code to public repositories and projects.
But what’s next?
You need to document and then socialize these changes to the development team and other relevant stakeholders. This will ensure they are formalized within the organization, maintained over time, and are scalable as you grow. Creating documentation might seem like a chore, but the benefit is worth it!
The best way to do this is to create an Open Source Policy.
Even if your Open Source Policy only covers the topics detailed in this article, you’ll find yourself to be much more confident in the security and reliability of the open source code being used in your environment.
Conclusion
Open source code relies on trust – but you can’t just trust everybody who contributes to know what they’re doing (or to not be malicious). Having good open source code practices and documenting them in a policy will help your developers securely use open source code in their projects.
Good luck cleaning up your open source code usage!
Want to get great cybersecurity content delivered to your inbox? C lick here to sign up for our monthly newsletter, Tales from the Click.
