Open Source Hygiene
Open source code has become an integral part of modern software development. It accelerates innovation by providing developers with ready-made components that the developers can incorporate in their projects. However using open source components can present a significant security risk if they are not properly tracked an managed.
Keeping track of open source components including the versions, new vulnerabilities, license information and maintenance status is known as open source hygiene.
Poor Open Source Hygiene
Applications that have poor open source hygiene are exposed to vulnerabilities that can adversely affect the users of said application. The Confidentiality, Integrity and Availability (CIA) triad of the data can be affected by poor open source hygiene.
Applications that have no manifest files i.e. package.json, requirements.txt etc, make it hard for other developers and users to understand which packages were used to build the application. If there is no manifest when developing application it would be difficult to understand what open source dependencies the application relies on. It also becomes very hard to update a package if there is a vulnerability that must patched otherwise it could have severe consequences on the data and the CIA can be adversely affected.
In a given scenario we have a java application that makes use of the log4j library. Sometimes in the past there was a critical vulnerability log4shell (CVE-2021-44228) that was a must patch for any and all application using the affected version. If there is no manifest file and the developers did not keep track of the open source components in their application it would be difficult and time consuming to track which application are affected.
In another scenario we have a legacy application where we do have a manifest file however there is no tracking of which packages are no longer being updated or have been deprecated by the developers. Hence if there is a vulnerability in said package, it will not get patched since no one is working on it.
Improving Open Source Hygiene
In order to prevent the issued described in the two scenario's above there are some steps, procedures and workflow that can utilized while developing applications to improve open source hygiene
Inventory Open Source Components
This is the first step to a good open source hygiene, which is knowing the open source packages that are in the code base and consequently in the application. Making use of manifest files is a very good step and if one is inheriting a legacy application with no manifest files then using software component analysis (SCA) tools Dependency-check tools can be helpful.
Regularly Check for Vulnerabilities
Now that we have the inventory of our open source packages, hopefully by use of manifest files, said open source packages should be regularly checked for any vulnerabilities and if the code base is affected the package should be update to mitigate the identified vulnerability. Checking the National Vulnerability Database (NVD) is a good choice.
Update Regularly
Keeping open source components up to date with the latest releases, even with update with no security fixes ensure that new features are available and prevent technical debt in the future if it has to be updated for a security fix.
Use Maintained Open Source Components
One should always ensure that the packages that are being used are being updated and not deprecated or abandoned. This ensures if there is a vulnerability identified, it will be fixed and wont be left without a patch. However, if that is only the only package, look for other packages that provide similar functionality and which is maintained
Implement a Policy for Using Open Source Components
Have a clear policy and guidelines on the usage of open source components, which can include items described above. This ensure that a standard is followed when developing new application or maintaining legacy applications.