Issue Date Guidance

SonarQube Server / Community Build Product Manager for a Day
1

Hello, our company scans every repository for dependency vulnerabilities, static analysis and dynamic scanning every day. I’m running into problems with SonarQube’s “issue date”. I can have a repository with zero “issues” yesterday. A new CVE will come out today, our scanner will find it and the issue is marked with an “issue created date” that might be 200 days old. This isn’t an issue that was open/closed/reopened/…". Brand new issue.

  • I have all SCM turned off, as I don’t care who did what when. I care the CVE is 1 day old and I expect our teams to resolve “blockers in x days”, “critical in x days”. So, when a team has a clean repo and then a new issue is created, getting a 200 day old count doesn’t make them happy.
  • I have tried messing w/ “new code” a few different ways. Right now I have it set so that each scan is “new code”. The behavior of the “issue creation date” is the same no matter what I do.
  • Currently we use API calls against SonarQube open issue creationDate to count issue age.

I realize that I’m using a plugin to load dependency vulnerability information and so your response might be, “not our problem”. If that’s the case, is it impossible to ask that the API return audit flags like “actually_created_date”. I need that date badly to ensure teams are in compliance.

Thanks.

2

Hey there.

To be honest, this is one of the issues with trying to make SonarQube (as it works today) behave as a SCA tool when it isn’t intended to be. It’s not really meant for issues that can’t be backdated. You might be better off exploring other tools for SCA right now.

And – if the goal is a failing Quality Gate, you can make sure these are “Blocker” issues and add a Quality Gate condition on “No Blocker Issues On Overall Code”)

If you need this data in SonarQube just for reporting externally based on a date… you’re right, the issue creation date is going to be difficult.

I have asked for this before! I think that having a backdated date and a “when SonarQube first knew about this issue” date is super important, for some different reasons. We also already have this data in the database, but not exposed by API.

I’ll move your post to the “Product Manager for a Day” category. No promises on a short-term solution.

3

Hello Colin,

I appreciate the quick honest answer. As someone trying to cover the OWASP top 10, SonarQube is a great landing place for our repositories. Please consider adding that audit information. I’m responsible for scanning about 15 million lines of code a day. For my team, SonarQube becomes less valuable as a landing spot and I’ll start to look at other tools that give me age information.

Again, I’m the one bending SonarQube, I get that completely. I appreciate any time you all have to consider dropping audit information into the API responses.

Justin