How to choose open-source solutions for your organization

According to the 2025 State of Open Source report, 96% of surveyed companies use open-source applications. Their wide selection, customization options, and zero licensing costs are highly appealing. However, more than half of the firms surveyed face significant challenges with ongoing maintenance of open-source apps. A staggering 63% struggle to keep solutions updated and apply patches. Close behind are issues with cybersecurity, regulatory compliance, and the presence of end-of-life (EoL) open-source applications — meaning they’re no longer supported. So, how can you minimize the likelihood of these problems, and what should you look for when selecting open-source software (OSS) for implementation?

Updates and patches

Since updating OSS in good time is the most widespread problem, examine potential OSS-contenders-for-adoption from this perspective very carefully. It’s easy to check the frequency and scope of updates, as well as their content, right within the application’s public repository. Pay attention to how well-documented the updates are; what kinds of issues they resolve; what new features they add; how often minor fixes are released a few days or weeks after a major version; and how quickly bug-related requests are closed.

Standard tools like Git Insights, along with supplementary services such as Is it maintained?, Repology, and Libraries.io, can help answer these questions. Libraries.io immediately shows which outdated dependencies the current version uses.

Pay special attention to security-related updates. Are they released separately, or are they bundled with functionality updates? Typically, developers choose the latter path. In that case, you need to understand how long security updates might have been waiting for release.

In addition, assess how complex the process of installing updates is. Official documentation and support can be a starting point, but they aren’t enough. Thoroughly reviewing user community feedback will likely be more helpful here.

All of this will help you understand how much effort will go into maintaining the product. You’ll need to allocate internal resources for support. It’s not enough to simply assign responsibility; dedicated work hours will be required for these and related tasks.

Vulnerabilities

To accurately predict how often you’ll face cybersecurity issues, it’s best to evaluate the product’s engineering culture and cybersecurity hygiene from the get-go. While this can be labor-intensive, you can use automated tools to perform an initial, high-level analysis.

For popular products and packages, a good approach is to check already existing heuristic assessment results from tools like OpenSSF Scorecard. It provides a variety of cybersecurity hygiene data, ranging from the number of unpatched vulnerabilities and the presence of security policies to the use of fuzzing and dependency pinning.

In addition, examine public vulnerability databases like NVD and GitHub advisories to understand how many flaws have been discovered in the project, their criticality, and how quickly they were fixed. A high number of vulnerabilities in and of itself may indicate the project’s popularity rather than poor development practices. However, the types of defects and how developers have responded to them are what’s truly important.

Dependencies and supply chain

Nearly every OSS project relies on third-party open-source components, which are often undocumented. These components are updated as per their own schedules, and they can contain bugs, vulnerabilities — even malicious code. The key question here is how quickly patched component updates make their way into the project you’re considering.

To assess this, you’ll need SBOM (software bill of materials) or SCA (software composition analysis) tools. Available open-source solutions like OWASP Dependency-Check or Syft can build a project’s dependency tree, but these are usually designed for projects already in operation, deployed in your own repositories or container images. Therefore, a deep dive into dependency analysis is best performed on a product that has already passed the preliminary evaluation and is a serious contender for a place in your infrastructure.

Examine the list of dependencies thoroughly to determine if they’re sourced from trusted and well-vetted repositories, if they’re popular, and if they have digital signatures. Essentially, you’re assessing the risks of their being compromised.

While you could theoretically check for vulnerabilities in dependencies manually, if an OSS project is already deployed in a test environment, it’s much more straightforward to use tools like Grype.

A huge hidden challenge is monitoring updates. In theory, every dependency update for a project needs to be re-checked. In practice, this is only feasible with automated scanners; other approaches are simply too expensive.

If a project uses outdated dependencies and generally isn’t ideal from a cybersecurity standpoint, it’s obviously better to look for an alternative. But what if the business insists on a specific solution because of its core functionality? The answer is the same as always: conduct a deeper risk analysis, develop compensating controls and, most importantly, allocate significant resources for ongoing maintenance. Internal resources are often insufficient, so it’s wise to evaluate options for professional technical support for that specific product from the outset.

Compliance with internal and regulatory requirements

If regulatory policies that apply to your company cover your chosen software and the data within it, develop a plan for compliance audits right away. Very large enterprise-grade open-source applications sometimes come with supporting documentation that can simplify certain types of audits. If not, you’ll have to develop it all yourself, which again means allocating significant time and resources.

Nearly every piece of software in every industry will require a license compliance audit. Some open-source components and applications are distributed under restrictive licenses, like AGPL, which limit how you can distribute and use the software. Thanks to SBOM/SCA analysis, you can inventory all licenses for your software and its dependencies, and then verify that your use case doesn’t violate any of them. These processes can be largely automated with specialized tools such as the OSS Review Toolkit, but the automation will require clear policies and effort from your development team.

Support costs

After analyzing all these aspects, you should have a clear picture allowing you to compare different approaches to application support. For support by an in-house team, you’ll need to allocate hours of relevant specialists. If your team doesn’t have the necessary expertise, you’ll have to hire someone. Those primarily responsible for OSS support and security will also need time and a budget for constant ongoing professional development.

If your internal team’s resources are insufficient for support (due to limited staff or expertise), there are at least two types of professional outsourced technical support: firms like Red Hat — which specialize in application operations, and managed hosting providers — for specific applications (Kube Clusters, MongoDB Atlas, and the like).

Beyond time and expertise, the cost and complexity of technical support are also influenced by the organization’s overall readiness for widespread open-source adoption:

• Does your cybersecurity team have vulnerability scanners and risk management tools that are well-adapted to OSS?
• Do your IT asset tracking and monitoring tools support OSS projects and components?
• For in-house development teams, are image, repository, and other code source scanning processes included in your CI/CD pipeline? Specialized security solutions, such as Kaspersky Hybrid Cloud Security, can automate this aspect.
• Has your company developed a policy regulating OSS usage, and is there a clear understanding of who makes decisions and who is responsible for operational matters?

Furthermore, it’s crucial to consider the broad spectrum of open source risks, including abrupt project discontinuation, a proliferation of minor dependencies, and other supply-chain risks.