Open-source software powers much of the internet, from websites and mobile apps to cloud services and business systems. Yet some projects rely on just a handful of developers to maintain their code and release updates. A flaw in a widely used library can affect thousands of applications, while limited time and resources can delay fixes.
How open-source software spreads
Open-source software makes its source code available for people to inspect, use and modify under a licence. Developers reuse code rather than build every part from scratch. The Android Open Source Project (AOSP) is one consumer-facing example of the software layer, while businesses use tools such as Netty and Spring Framework.
Maintainers review code, fix bugs and release updates. Companies using open-source software, whether the full stack or part of the software layer, track the components they use and check whether a vulnerability affects them. A fix does not automatically reach every application or device that relies on it.
According to IBM and Red Hat, business applications use open-source components for networking, authentication, encryption, cloud services and AI. A flaw can force many organisations to review their systems. Components included indirectly through other software can be harder to identify.
Vulnerabilities in the report
The IBM and Red Hat report describes a supply-chain attack involving Ultralytics, an open-source Python project used for computer vision. In December 2024, attackers compromised its GitHub Actions build environment and inserted malicious code into packages published on PyPI, a platform for distributing Python software. Four affected releases were removed.
The incident shows that attackers can target software build and distribution systems, not just source code. Businesses must check whether they downloaded the affected package.
The report also discusses Netty, a framework that helps applications communicate over networks. A May 2026 security release addressed 12 known vulnerabilities affecting its functions. A fix does not automatically update every application using Netty. The report notes that every organisation must identify affected systems, test the fix and deploy it.
Spring Framework, used to build Java applications, had a vulnerability affecting versions through 5.3.18; version 5.3.19 included a fix. Older applications may need compatibility checks before upgrades.
The report models a hypothetical vulnerability involving JAXB, a tool that helps Java applications exchange data in XML format. IBM and Red Hat estimated that 285,000 of three million production Java applications could use a potentially vulnerable version. Fixing the issue separately could require 5.7 million engineering hours and cost $712.5 million. These are estimates, not actual losses.
Why maintaining projects is difficult
Maintenance continues after release: developers review code, respond to bugs, test changes and publish security updates. This work is harder to sustain alongside other jobs, responsibilities or limited financial support.
According to Tidelift’s State of the Open Source Maintainer 2024 survey, 50 per cent of respondents said they were inadequately compensated or not paid at all. Another 48 per cent felt underappreciated or described the work as thankless, while 43 per cent said maintenance added to their personal stress. Sixty per cent had quit or considered quitting maintenance work.
Tidelift also found that paid maintainers were 55 per cent more likely than unpaid maintainers to carry out important security and maintenance practices. This is an association, not proof that payment alone causes better security.
The Linux Foundation’s 2024 Global Spotlight Insights Report found that 50 per cent of respondents said their open-source contributions were unpaid. Lack of time due to personal commitments was cited by 63 per cent, while 34 per cent cited lack of funding. Two in five organisations employed maintainers to support critical projects, and 74 per cent of those organisations said they gained high value from doing so.
Too few contributors can leave a project dependent on a small group. Replacing a departing maintainer takes time. Users may expect quick fixes without contributing code, testing or money, while new vulnerabilities create urgent work.
Risks for businesses and users
A system may remain vulnerable if a fix is not installed. Companies must identify affected versions, test patches and deploy them, which takes time across older systems. A compromised package can also create supply-chain risk.
Delays do not always originate with maintainers. Companies may take time to identify components, assess risk, test updates and deploy them. Device makers also need to integrate and distribute fixes. These device examples are illustrative, not specific cases in the report.
For large organisations, the same component may appear across many teams, products and older systems. Without an up-to-date inventory, security teams may not know where to begin or which business units need to act first. A written process can set owners, deadlines and escalation steps for critical fixes.
What it means for India
For Indian IT services companies, banks, startups and device makers, key questions are whether they track components, monitor security notices and install critical fixes promptly. Do they fund projects, contribute code or staff time, and maintain software bills of materials (SBOMs)?
According to TCS, the company helped an unnamed Indian private-sector bank establish an Open Source Program Office to assess security, licensing, obsolete software and support risks across applications and infrastructure. The public case study does not name the bank or say whether it funds maintainers or sets patch deadlines.
Companies can support projects through donations, employee contributions, testing or paid support. They can assign responsibility for dependencies and set patch deadlines.
Open-source security is a shared responsibility. Maintainers need time and support to find and fix problems, while businesses must know where affected code is used and ensure updates reach production systems. A patch only reduces risk when organisations relying on it can put it into practice.
