The support lifespan of software components and the lifetime of an application

Most open-source software projects announce in advance how long their versions will receive maintenance. Long Term Support (LTS) means that critical bugs and security vulnerabilities in a version will be fixed for a defined period. End-of-Life (EOL) is the moment when that period ends.

The Node.js project defines end-of-life as follows: once a version reaches end-of-life, it receives no further updates, including security patches, and applications running on that version remain exposed to security issues and bugs that will never be fixed. The project also stresses that if a vulnerability fixed in newer versions also affects older versions, no new release will be made for the older versions, and those who use them become immediately exposed to attacks exploiting the disclosed vulnerabilities. The same statement notes that many industry audits do not accept unmaintained runtime environments.

In Node.js, each major version stays in the Current phase for six months. Up to and including Node.js 26, odd-numbered versions fall out of support at the end of these six months, while even-numbered versions move into the LTS phase. The project states that the LTS phase generally guarantees that critical bugs will be fixed for a total of 30 months, and that applications in production should use only versions in the Active LTS or Maintenance LTS phase.

According to the schedule in the Node.js release repository, as of 23 October 2026 the situation is as follows:

• Node.js 20 (Iron): support ended on 30 April 2026.
• Node.js 22 (Jod): is in the maintenance phase; support will end on 30 April 2027.
• Node.js 24 (Krypton): the start of the maintenance phase is planned for 20 October 2026; support will end on 30 April 2028.
• Node.js 26: is in the Current phase; it is planned to move into the LTS phase on 28 October 2026 and to be supported until 30 April 2029.

The project is changing the calendar starting with Node.js 27. Under the new arrangement, one major version will be released each year, every major version will move into the LTS phase, and 36 months will pass from a version's entry into the Current phase to its end-of-life. The project also notes that the dates in the calendar may change. What matters for institutions is knowing on what date the version they use will fall out of support, and planning the upgrade before that date.

The current version of the OWASP Top 10 list, which ranks web application security risks, was published in 2025. The category ranked third in this version, A03:2025 Software Supply Chain Failures, states that the scope of the risk first listed in the 2013 list as the use of components with known vulnerabilities has expanded to cover all supply chain failures. The category counts vulnerable, unsupported or outdated software as part of this risk, and stresses that tying patching to a slow schedule can needlessly leave institutions exposed for days, even months.

OWASP's prevention recommendations include generating and managing a Software Bill of Materials (SBOM) centrally for the entire software, maintaining a continuous inventory of component versions on both the client and server side, removing unused dependencies, continuously monitoring sources such as CVE, and having a patch management process in place. The US Cybersecurity and Infrastructure Security Agency (CISA) defines an SBOM as a nested inventory of the parts that make up software components.

Another resource that can be used for prioritisation is CISA's Known Exploited Vulnerabilities (KEV) catalogue. The catalogue lists vulnerabilities known to have been exploited in real attacks, and CISA recommends that organisations use this catalogue as an input in prioritising vulnerability management. If a component in use has a vulnerability listed in this catalogue, that is a sign the update should not be delayed.

The Information and Communication Security Guide, prepared pursuant to Presidential Circular No. 2019/12 on Information and Communication Security Measures, sets out direct measures for public institutions on this subject. In version 1.1 of the guide, published by the Siber Güvenlik Başkanlığı in March 2026, the main relevant measures are as follows:

These measures show that support lifespan is a compliance matter that institutional management, as well as the technical team, needs to follow. The guide's audit questions also include whether the currency of application components is checked at regular intervals, and what activities are carried out when an outdated version is detected.

Support lifespan risk can largely be managed at the contracting stage. It is recommended that the institution explicitly regulate the following matters in its tender specification and maintenance contract:

• That the application runs on versions of the runtime environment, framework and libraries supported by their producers, both at the moment of delivery and throughout the contract term.
• That the versions of the main components used, together with their support end dates, are listed in the delivery documents and that this list is kept up to date.
• An update plan showing within what period security updates will be applied and on what schedule major-version transitions will be carried out.
• Regular scanning of dependencies against known vulnerabilities and reporting of findings to the institution; priority being given to vulnerabilities listed in the KEV catalogue.
• A machine-readable Software Bill of Materials (SBOM) being provided to the institution with each delivery.
• That when a component's support end date approaches, the contractor notifies the institution in advance and carries out the migration work within the scope of the contract.

The Node.js project notes that commercial support services exist for versions that have reached end-of-life, but stresses that this path should be seen as a temporary solution and that the goal should always be to upgrade to supported versions. For institutions too, the lowest-cost path is to make upgrading, before support ends, part of regular maintenance.