Just to give you some more technical context, which you probably already figured out...

The "old" vulnerability model worked by downloading a datafile from security.inedo.com, unpacking it, and inserting rows in the PgvdVulnerabilities and PgvdPackageNames tables. Those tables contained every vulnerability in our database and it was a bit tricky to know which of those vulnerabilities related to package versions "in" ProGet. The PgvdAssessments table helped somewhat.

The "new" model works by downloading an indexed database file. The "Assess Vulnerabilities" function (which rurns on that download job as well) will iterate over all vulnerabilities in that database and adds/removes rows to the PgvdVulnerabilities26 tables as needed (including PgvdPackageVersions), which makes it much easier to know if a vulnerability impacts a version "in" ProGet by looking at the database.

There are most certainly edge cases and glitches in this, so don't hesitate to let us know if you spot any odd behavior.

Thanks,
Steve

no need to do such a deep dive
I was just curious about the new data structure and I noticed that the "old" table "PgvdAssessments" contained all assessments, also the auto-assessed ones. And the table "PgvdAssessments26" is empty.
I just wanted to make sure that this is somehow intended and does not cause any further issues.
As long as we still get all vulnerabilities for a project everything is ok
I will let you know if we encounter any problems.

Thanks
Caterina

It's quite complicated and there are a lot of technical details that I'm not immediately familiar with. To properly answer, I'd need to set up a reproduction case and then attach a debugger to give you a more technically precise answer on why it's displaying that way.

We may even need to do a whole database backup, since it might be specific to your configuration. I really don't know how much of an investigation it would require.

We added the dotted line as primarily a way for us to identify the system state when there are issues reported. Previous version of ProGet also had provisional assessments, but it was never visually indicated.

Anyway, if you're seeing any problems jut let us know -- this shouldn't have any impact outside of the dotted-line display on some pages.

Thanks,
Steve

so the package is coming from a connector but it has been retrieved via ProGet and is used in projects. I can also see it if I search for "Local and Cached" packages.
Is that enough to be seen as "in" ProGet? Or what is the exact definition of being "in" ProGet? Maybe I have a different understanding of that.

Because I ran the job again via Admin -> Vuln Types -> Reassess and it is still dotted.

Thanks
Caterina

The dotted border indicates what we call a provisional assessment; we don't have a great description for what that means, but that's what you'll see when a package is not local or cached in ProGet.

Without getting into too many technical details, that's the expected behavior (i.e. not in the database, not on the SCA > Vulnerabilities page). Once the Vulnerability Download job (or Admin > Vuln Types > Reassess) runs, it should become a normal assessment (i.e. show in the database, etc).

In any case, whether an assessment is provisional or not shouldn't have any impact on compliance analysis. The most notable impact is that it won't show up on the SCA > Vulnerabilities page until another job identifies the package as being "in" ProGet.

Thanks,
Steve