{"id":53648,"date":"2025-06-16T11:59:49","date_gmt":"2025-06-16T15:59:49","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=53648"},"modified":"2025-06-16T11:59:49","modified_gmt":"2025-06-16T15:59:49","slug":"can-you-support-open-source-preliminary-assessment","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/can-you-support-open-source-preliminary-assessment\/53648\/","title":{"rendered":"How to choose open-source solutions for your organization"},"content":{"rendered":"

According to the 2025 State of Open Source report<\/a>, 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 \u2014 meaning they\u2019re 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?<\/p>\n

Updates and patches<\/h2>\n

Since updating OSS in good time is the most widespread problem, examine potential OSS-contenders-for-adoption from this perspective very carefully. It\u2019s easy to check the frequency and scope of updates, as well as their content, right within the application\u2019s 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.<\/p>\n

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

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.<\/p>\n

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

All of this will help you understand how much effort will go into maintaining the product. You\u2019ll need to allocate internal resources for support. It\u2019s not enough to simply assign responsibility; dedicated work hours will be required for these and related tasks.<\/p>\n

Vulnerabilities<\/h2>\n

To accurately predict how often you\u2019ll face cybersecurity issues, it\u2019s best to evaluate the product\u2019s 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.<\/p>\n

For popular products and packages, a good approach is to check already existing heuristic assessment results from tools like OpenSSF Scorecard<\/a>. 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.<\/p>\n

In addition, examine public vulnerability databases like NVD<\/a> and GitHub advisories<\/a> 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\u2019s popularity rather than poor development practices. However, the types of defects and how developers have responded to them are what\u2019s truly important.<\/p>\n

Dependencies and supply chain<\/h2>\n

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 \u2014 even malicious code. The key question here is how quickly patched component updates make their way into the project you\u2019re considering.<\/p>\n

To assess this, you\u2019ll need SBOM (software bill of materials) or SCA (software composition analysis) tools. Available open-source solutions like OWASP Dependency-Check<\/a> or Syft<\/a> can build a project\u2019s 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.<\/p>\n

Examine the list of dependencies thoroughly to determine if they\u2019re sourced from trusted and well-vetted repositories, if they\u2019re popular, and if they have digital signatures. Essentially, you\u2019re assessing the risks of their being compromised.<\/p>\n

While you could theoretically check for vulnerabilities in dependencies manually, if an OSS project is already deployed in a test environment, it\u2019s much more straightforward to use tools like Grype<\/a>.<\/p>\n

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.<\/p>\n

If a project uses outdated dependencies and generally isn\u2019t ideal from a cybersecurity standpoint, it\u2019s 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\u2019s wise to evaluate options for professional technical support for that specific product from the outset.<\/p>\n

Compliance with internal and regulatory requirements<\/h2>\n

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\u2019ll have to develop it all yourself, which again means allocating significant time and resources.<\/p>\n

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<\/a>, 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\u2019t violate any of them. These processes can be largely automated with specialized tools such as the OSS Review Toolkit<\/a>, but the automation will require clear policies and effort from your development team.<\/p>\n

Support costs<\/h2>\n

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\u2019ll need to allocate hours of relevant specialists. If your team doesn\u2019t have the necessary expertise, you\u2019ll have to hire someone. Those primarily responsible for OSS support and security will also need time and a budget for constant ongoing professional development.<\/p>\n

If your internal team\u2019s 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 \u2014 which specialize in application operations, and managed hosting providers \u2014 for specific applications (Kube Clusters, MongoDB Atlas, and the like).<\/p>\n

Beyond time and expertise, the cost and complexity of technical support are also influenced by the organization\u2019s overall readiness for widespread open-source adoption:<\/p>\n