Your business may rely on open-source software without anyone choosing a product labeled “open source.” It can be part of a commercial application, a website, a network appliance, or a tool your team uses directly. The useful question is not whether it exists in your environment. It is how the relevant parts are maintained.
Open-source software makes source code available under a license that defines permitted use. That can support useful development and scrutiny. It does not automatically mean a product is secure, supported, free of cost, or unsuitable for business. The implementation and the people maintaining it deserve the same practical attention as other technology.
Find out who is responsible for fixes
A project may have active maintainers and a commercial support option. It may also depend on a small team with limited resources. If the software matters to your operation, ask who tracks advisories, who tests updates, and who can act when a component needs replacement. Do not assume someone else is watching because the code is public.
CISA’s Open Source Software Security Roadmap addresses the importance of understanding open-source use and reducing ecosystem risks. For a business buying an application, a practical application is to ask the vendor how it manages dependencies and how relevant vulnerabilities reach its customers as fixes or guidance.
Source: CISA Open Source Software Security
A dependency can be several layers down
An application can include libraries and other components that include further dependencies. A software bill of materials, or SBOM, can help identify components. It is an inventory aid, not proof that every item is safe or that a particular vulnerability is exploitable in your deployment. Someone still has to interpret the information.
- Use approved sources for downloads and updates.
- Maintain an inventory of business-critical applications and the vendors supporting them.
- Ask how dependencies are reviewed and updated in custom or vendor-maintained software.
- Track products or components that are no longer supported.
- Have a way to test a security update and recover if it disrupts the application.
Avoid turning every advisory into a panic
A vulnerability notice may matter urgently, or it may concern a feature your environment does not use. Assess the affected version, configuration, exposure, available mitigation, and business impact. The answer should be documented by someone who understands the deployment. Ignoring all advisories and treating all of them as equal emergencies are both poor operating habits.
This is one of the places where context matters more than finding a command online. An update can affect integrations, licensing, compatibility, or a critical workflow. RIKR helps businesses approach support and patching with that context, including coordination with the application vendor when specialist knowledge is needed.
Choose software you can sustain
The right solution may be open source, commercially licensed, or a combination. Consider support arrangements, required expertise, upgrade paths, and the effort to change later. A low purchase price is not the complete cost of maintaining a system. An expensive license is not evidence that all maintenance has been handled.
You do not need to become a software supply-chain specialist to ask a good question: who will tell us when this needs attention, and who will do the work? A clear answer is a useful part of any technology decision.
Related: a practical vendor security review
Related: patch management for business
Explore RIKR managed IT support
Written by Joshua Price
Back to the blog