Another maintainer of an open-source software project has decided to no longer actively update an IP address parsing utilities used widely by JavaScript developers.

The "ip" project is now only available in a read-only format on the GitHub software repository after a vulnerability discovered earlier this year was assigned a common vulnerabilities and exposure (CVE) 2023-42282 identifier.

Many open-source software projects are labors of love involving a few core unpaid maintainers that lack the resources to investigate, verify and remediate every vulnerability. In fact, as in this case the developer of the "ip" project rejects the severity of the CVE assessment.

However, as more organizations make use of that software, the need to remediate a potential vulnerability becomes a more pressing application security issue.

Paul Nashawaty, practice lead for application development at the Futurum Group, said the challenge is not every CVE reported is equally severe. Many libraries are flagged with CVEs due to potential vulnerabilities that could be exploited under specific conditions. Developers of those libraries often argue that these vulnerabilities are unlikely to be exploited in real-world scenarios, he added.

Regardless of who assumes responsibility for that risk, malware often exploits the interactions between multiple components. Each component may be secure in isolation but can be combined in ways that produce insecure behavior. This issue underscores the importance of focusing on the security of the whole system rather than just individual parts, said Nashawaty.

As such, organizations need to understand all the risks that dependencies on any one piece of software can create, he added.

In general, the open-source community is wrestling with how to secure open-source software projects lacking a large community of developers who can help remediate vulnerabilities. The efforts include making available additional developers to fix specific vulnerabilities when needed.

At the same time, however, many organizations are revisiting software supply chains that include open-source software. If the project lacks the resources to remediate a vulnerability that gets discovered promptly, many of those organizations opt to reduce their dependency on it.

Each DevSecOps team needs to decide to what degree they are comfortable with open-source software. However, the days when developers routinely downloaded code anywhere they happened to have found it are ending. Cybercriminals have become especially adept at tracking known vulnerabilities, so any time one is disclosed it's usually not long before there are attempts to exploit it.

Of course, depending on where code is running, there is a world of difference between there being a vulnerability and the odds that it will be exploited. Many DevSecOps teams today are still comfortable running software with known vulnerabilities if, for example, that application is not accessible via the internet.

One way or another, however, the security of the software that is deployed in IT environments needs to improve. After all, software that is inaccessible today might easily become inadvertently accessible via the internet tomorrow as more applications are integrated. In that sense, many DevSecOps teams may determine the better part of valor is to be safe no matter where the software runs versus being sorry tomorrow.