Increment risk score based on BOM age

[mieliespoor]

Current Behavior

The age of the BOM has no impact on the risk score.

Proposed Behavior

It should be possible to provide a sliding scale in the settings on how the BOM age impacts the risk score. He is an example:

Days	Score Impact	Type
0-90	0	Once
91-120	10	Once
> 120	5	Daily

This means that up to 90 days, there will be no impact on the risk score. If the BOM age is more than 90 days old, the configurable score impact will be 10, whereas any BOM older than 120 days will see the risk score change on a daily basis by 5 points.

This all should be configurable where I can add finer grained day counts could be added, so more rows with rules, and/or the score impact value can be changed.

Doing this will allow us to highlight very easily when BOM age as this then have an impact on the risk rating/score for the specific project.

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this enhancement was already requested

[stevespringett]

Interesting idea. I think we need to flush it out a bit.

• What is the use case for increasing the risk score based on BOM age?
• What problems will this solve?
• What problems will this create?

Based on an informal survey, about 20% of DT adopters use it for evaluating BOMs in their procurement and M&A processes. The age of a BOM should be roughly the same as the age of the software they've procured. If the software is a year old, the BOM is expected to also be a year old.

However, there may be some benefits for an "BOM age policy" for internally developed software where a BOM that's generated as part of a build process is pushed to DT.

[mieliespoor]

At the moment, we have deployed Dependency-Track to publish the BOM's for our internally built and published apps. We still need to track other tools we deploy and use, but that is not our primary focus.

Corporate Security has a requirement that we need to perform certain security scans at least once every 90 days. We are also not allowed to publish any service which has critical vulnerabilities into production. We have some quality dashboards which we use to track our engineering quality and we pull in a range of metrics from different sources like Sonarqube, 42Crunch and now also the Risk Score from Dependency-Track.

Because Dependency-Track, catalogs the BOM for each service we will then be able to easily track the production age of each application along with the inherent security risk of the application. Now it can be argued that because Dependency-Track continually pull in new vulnerabilities, it negates the need to import a new BOM every x number of days, because by building the app again won't impact the vulnerability count, but it also could.

Another aspect to all of this is that we have a corporate security requirement that all OS patching need to happen at least once every 90 days. This is OK for instances where you deploy your code to a VM as you can manage your code and host independently, but in the case where you deploy your code in a docker container, that container need to be patched every 90 days because you still need to pull in the OS patches for that base container. With this in mind, we then need to track the age of our applications to easily determine their age. If you then haven't published your service within the last 90 days, it means you missed out on OS patching (container level) for at least 90 days meaning your service is compromised on the security front.

Admittedly, I don't see this being used by every user of Dependency-Track, but I do see the value in having the ability to enable this and include this metric into the risk score.

[mieliespoor]

A problem this could create is that it will artificially increase the risk score of a project if such a feature would be enabled and you don't expect it.

An example where this won't work would be where you manage the BOM for third-party software. Lets use the Sonarqube example. We only install LTS versions. Ignoring patch versions for a second, this means that your BOM can easily age to more than 3 months. This will then artificially increase the risk score for a product over which you have no control. In cases such as that, I won't be enabling this feature.

In our environment, I won't however be adding any BOM to Dependency-Track where we track internally built software. We will be deploying an additional instance for keeping track of third-party software like Dependency-Track / Sonarqube / etc.

[valentijnscholten]

It could be configurable per project. But how does it help your use case if the age of the BOM is embedded in the risk score in an possibly untransparent way? The risk score could be 100 because of vulnerabilities or because of the BOM age. It might be more reliable and transparent to "just look at the last BOM import timestamp" in your assessment script/tool, just as your are probably looking at the exact count of critical vulnerabilities?

[schlenk]

Isn't this just a proxy indicator for "detect out of date and EOL components"?

Or maybe for CI breaking down and not uploading fresh SBOMs.

[stevespringett]

I agree @schlenk. I've always used the term "freshnessometer". We have the metrics to build a freshnessometer for components, although we don't do a good job of visualizing the data today. We could do the same thing with BOMs as well, and potentially allow for filtering of the freshness metrics by project or tag. But IMO, these are separate metrics and not necessarily part of a risk score, although they optionally could be.

[mieliespoor]

Yes, that is an angle I didn’t consider. And stating it like that, I agree that maybe combining that metric with the risk score is maybe not the best idea.

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.