Report Outdated Components (OWASP Top 10: A06:2021)

[walterdeboer]

Outdated Components is in the OWASP Top 10: A06:2021 – Vulnerable and Outdated Components

Dependency Track knows of outdated component, but does not show them in the Audit Vulnerabilities overview when there is no known vulnerability

If added two PR's so outdated component with no known vulnerabilities are included in the Audit Vulnerabilities overview :

• Update findings endpoint to include outdated component findings #2521
• Include outdated component in the Audit Vulnerabilities overview frontend#435

It uses the folowing PR so only stable versions are reported:

• Restrict latest versions to stable highest releases only for all default repositories #2501

N.B. only direct dependencies are reported as these are the ones you could update yourself

closes #2514, #2500, fixes #513, #1374, partly fixes #2003, #1833

Please share your thoughts! :-)

[stevespringett]

I would not expect to find outdated components while in the "Audit Vulnerabilities" tab. Most large software applications with hundreds or thousands of OSS components will use a lot of out-of-date components, most will not be vulnerable. It will be frustrating for users to have to paginate through the noise to find the vulnerabilities. This would be a UX disaster if implemented.

This information should either be on a dedicated tab, or not included at all since users can create policy for outdated components which would then trigger a violation.

[walterdeboer]

Hi Steve, thanks for your reply. I've restricted the outdated components to the direct components only, to prevent frustration for the users. Only the components are shown, that you can update yourself. I think this makes it actionable and "Auditable"? Although I agree "Violations" does not cover it,

I'm not sure what you mean by "since users can create policy for outdated components"? Are you refering to #2537 ? Dependency Track now only supports a Component Age policy and a Component Version policy, but both are unsuitable to detect outdated components as you would need to know if there is a newer stable version available. Another issue with the policy overview is that it's missing the "evidence". I'd like to see the latest version available.

I hope you do see the value added by reporting the outdated components and showing the latest stable version available? I'm open to moving the outdated components on a dedicated tab (and a separate endpoint). The new tab could show:

• an overview of outdated components
• the latest stable version for each outdated component
• current vulnerabilities if any for each outdated component
• solved vulnerabilities in the latest version? This would probably need some extra effort.

Please advice on how to proceed?

[walterdeboer]

Or maybe just an extra filter switch on the components tab to exclude al non-outdated components would do the same?

[stevespringett]

Hmmm. The outdated only switch is really interesting. I like that approach. I could see this morphing into a dropdown with a few more options in the future, such as listing only the components whos hash value does not match the repository, etc.

[nscuro]

Another issue with the policy overview is that it's missing the "evidence". I'd like to see the latest version available.

That is a more general enhancement that I also thought about. It would be great if we had a human-readable justification for each policy condition violation, similar to assertion failure messages produced by Hamcrest / AssertJ. e.g.

Expected component license "AGPL-3.0" to not be contained in license group "Copyleft", but it is

or

Expected the maximum distance to newest available version to be major=2/minor=/bugfix=, but was major=3/minor=1/bugfix=0

That would provide more context to the user as to what was expected, and why exactly that expectation was violated.

[walterdeboer]

Ok, a switch it will be :-)

#2568
DependencyTrack/frontend#437