Links to OSV IDs aren't clickable

[evverx]

Describe the bug

scorecard dumps OSV IDs like

      "details": [
        "Warn: Project is vulnerable to: GO-2022-0646",
        "Warn: Project is vulnerable to: GHSA-hqxw-f8mx-cpmw",
        "Warn: Project is vulnerable to: GHSA-3633-5h82-39pq / GO-2022-1004"
      ],

and provides a link to the documentation where osv.dev is mentioned so to get to actual entries it's necessary to click on a couple of links, copy-paste the IDs and so on. I don't think it's particularly usable.

Reproduction steps
To get those unclickable OSV IDs it should be possible to pass something like

--verbosity debug --show-details --checks Vulnerabilities --repo=https://github.com/ossf/scorecard --format json

to scorecard or visit, say, https://securityscorecards.dev/viewer/?platform=github.com&org=ossf&repo=scorecard (which consumes those OSV IDs as well). They flow to security dashboards as well.

It was originally reported in #2979 (comment).

Expected behavior
I'd expect scorecard to make those OSV IDs clickable so people wouldn't have to jump through hoops to just view OSV entries.

I guess it can be argued that the output of scorecard shouldn't be consumed by people (and I'd agree with that) but either way various scorecard UIs should make those IDs clickable.

[spencerschrock]

In the pure results, I think having something like this would get repetitive (although we do this with the stepsecurity links):

      "details": [
        "Warn: Project is vulnerable to: https://osv.dev/vulnerability/GO-2022-0646",
        "Warn: Project is vulnerable to: https://osv.dev/vulnerability/GHSA-hqxw-f8mx-cpmw",
        "Warn: Project is vulnerable to: https://osv.dev/vulnerability/GHSA-3633-5h82-39pq / GO-2022-1004"
      ],

They flow to security dashboards as well.

The sarif output supports markdown, so should be possible if we restructure to support check specific logic somewhere. Quick search has somewhere around here:

scorecard/pkg/sarif.go

Lines 601 to 609 in 4cd5446

	func createDefaultLocationMessage(check *checker.CheckResult, score int) string {
	details := filterOutDetailType(check.Details, checker.DetailInfo)
	s, b := detailsToString(details, log.WarnLevel)
	if b {
	// Warning: GitHub UX needs a single `\n` to turn it into a `<br>`.
	return messageWithScore(fmt.Sprintf("%s:\n%s", check.Reason, s), score)
	}
	return messageWithScore(check.Reason, score)
	}

results viewer

my guess is this is something the badge viewer could support with some regex

[laurentsimon]

I think we have all the basic block to do that:

• Vuln structure https://github.com/ossf/scorecard/blob/main/clients/vulnerabilities.go#L41-L44, we can add a URL
• LogMessage supports URL findings https://github.com/ossf/scorecard/blob/main/checker/check_result.go#L84 and we can record it https://github.com/ossf/scorecard/blob/main/checks/evaluation/vulnerabilities.go#L50-L52
• structured results also support URL path https://github.com/ossf/scorecard/blob/main/finding/finding.go#L41

Limitation:
If we want the vulnerability check to report the path where the dependency was defined (lock file, manifest) AND its URL, then we cannot support this today. Once we have migrated the check to the structured result, I think we can make use of the remediation https://github.com/ossf/scorecard/blob/main/finding/finding.go#L90-L96 in combination with https://github.com/ossf/scorecard/blob/main/finding/finding.go#L222-L234 to set the custom URL. If we want the URL to be parsable via a proper field (instead of being buried in the remediation text), we may also add a field to Finding https://github.com/ossf/scorecard/blob/main/finding/finding.go#L90-L95, like URL...?

[evverx]

If we want the URL to be parsable via a proper field (instead of being buried in the remediation text)

To me URLs would be more helpful in context. I think it should be possible to move links to OSV IDs to separate fields and let people scroll down a bit but I think ideally files/issues on GitHub in the other checks like

... 'write': .github/workflows/verify.yml:24: ...

should be clickable too and those links should probably be embedded in the remediation text (when they are shown in various UIs at least).

[evverx]

Apparently issues here are ignored until they're closed automatically so I'll go ahead and close it manually.

[spencerschrock]

Apparently issues here are ignored until they're closed automatically so I'll go ahead and close it manually.

We tried to revert the auto-close in #3493 (although it looks like we didn't, so we're explicitly doing so in #3513). Like many open source projects, we unfortunately have to pick and choose the issues we work on based on priority.

Note: I still find these UX requests/feedback helpful, even if we don't have the resources to immediately address them.