One of the most common types of questions that we get asked is “Every version is vulnerable. What should I do?”
In many cases this is cited as a reason for delaying the upgrade of a project dependency. Even when this situation exists, we believe that upgrading to newer versions of OSS components should be encouraged and developers should be empowered by their management to upgrade frequently. As published in our State of the Software Supply Chain Report, older software has a higher frequency of bugs, including security vulnerabilities disclosed to the public. In addition, as OSS projects make fixes and develop new features, they introduce breaking API changes. All three of these aspects represent technical debt that, as time goes by, makes it more and more difficult for developers to upgrade their OSS dependencies.
Organizations that have a process to continually review their policy violations in Nexus IQ Server and discourage developers from ignoring these issues are better able to encourage them to upgrade. They are building best practices that make it easier to respond quickly when an upgrade is really needed, leading to better software with less security risks.
While it would be ideal to choose a different component or framework, this is not always practical to do in the short term. A member from the security team should partner with a member of the development team to understand the vulnerability and assess the risk to the application. On future scans, the IQ Server will still identify the vulnerability in the affected component in order to maintain visibility of the potential risk to the application. If the policy action has been set to “fail”, this would result in a failed build. If the mitigating controls have been successfully implemented, a failed build is not ideal, and very disruptive.
If the latest version doesn’t resolve the issue, some times the risk can be mitigated without changing the component or version. The IQ Server has a “waive” feature for this very reason. The example below walks through a real-world example. (NOTE: the ability to waive a Security violation for a specific CVE was added in IQ Server Release 53, if you are on an older version, please upgrade. If you are on a previous release, you will need to waive at the policy level, which waives all security issues, or set the security status, which is limited to the application scope).
EXAMPLE: Express.js
Express.js, or simply Express, is a web application framework for Node.js, released as free and open-source software under the MIT License. It is designed for building web applications and APIs.
When building and scanning an Express-based appliction, you may notice that IQ Server identifies the following:
Selecting the “Vulnerabilities” tab, we can learn more about the vulnerability SONATYPE-2012-0022:
In the “Recommendation” you’ll see “While there is no non-vulnerable version of this component, the vulnerability was fixed at the runtime level (within NodeJS itself). Upgrading NodeJS to a version after or including 0.9.4 will remediate this issue.”
NodeJS 0.9.4 is very old. Once you have verified that your application is running on a more recent release of NodeJS, you can go back to the “Policy Violations” tab and select the blue “Waive” button for the SONATYPE-2012-0022 violation:
In this scenario, the mitigating control is specific to the application’s runtime, so you will likely want to apply the waiver to only this application. However, if you can be certain that all of your applications are running on a newer version of NodeJS, you have the option of increasing the scope of the waiver and applying it to the Organization or globally (Root Organization):
