Clarification on Creation Date for Dependency Vulnerabilities

Hi everyone,

I am trying to get a better understanding on what the Creation Date in SonarQube is for our vulnerable dependencies. If anyone could please give a thorough explanation, then that would be great. I thought the creation date is the date when the issue shows up in your code. However, how can an issue’s creation date be longer than how long I have been using SonarQube for? For example, if an issue is from 4.8 years ago but we have only been using SonarQube for about 3 years. How could this be?

We use the Dependency Check to find vulnerable dependencies and SonarQube reads and visualizes the Dependency Check Report. If there is no issue date or SLA in the Dependency Check Report, could SonarQube be incorrectly parsing the information?

Also, how do companies typically view the age of an issue? If the CVE was published 3 years ago but existed in the code for 5 ½ years, then would you say the CVE was 3 years old, since that’s when it was published? Or would you say it’s 5 ½ years because that’s how long it was in the code for?

Thanks in advance!

Hey there.

Issues in SonarQube are subject to issue backdating, which makes sense for all of Sonar’s native use-cases (if we develop a new rule, it’s not fair to put all those issues in the New Code Period). Following Clean as You Code, developers can’t be made immediately liable for issues they did not introduce.

For SCA purposes (raising issues on vulnerable dependencies)… this makes less sense. And, there’s not much we can do about that :confused: This is functionality offered by a community supported plugin.

@Colin Thank you! Is there a way to change how SonarQube calculates the creation date? Could we use a CVE’s publication date as the creation date instead of when it first existed in the code? For example, we have vulnerabilities that weren’t published in the NVD until 2023 but existed in our code since 2022. So, the creation date is labeled as 2022. Is there a way to set the creation date as 2023 instead of that 2022?

Or, are there APIs that can track other time frames (ex: an API that will show you the number of days that the vulnerability has existed in your code starting when it was either published in the NVD or starting when it existed in the code after it has already been published

vs when they were identified like how SonarQube does?)


There’s no mechanism to adjust how SonarQube calculates the issue date. I can only really refer you to raise an issue on GitHub - dependency-check/dependency-check-sonar-plugin: Integrates Dependency-Check reports into SonarQube if the issue import isn’t meeting your needs. This is a community-supported plugin.