Add support for "dotnet-retire"

[cmenzi]

I've just found RetireNet. This tools produces massive more information and also finds some vulnerabilities.

• It scans all transitive dependencies,
• It includes .NET Framework / .NET Core version aswell
  • I think this is very important, because MSFT mostly publish vulnerabilities for a specific .netcore version

Maybe you can include dotnet-retire and create a bom.xml out of scan results from dotnet-retire. Or add parameter to add additional input from output

Regarding CycloneDX Spec, it's also possibile to add vulnerabilities to the bom.xml

What do you think?

[stevespringett]

Ideally, RetireNet would produce a valid CycloneDX BOM, similar to what Retire.js already does. So it could be used as an alternative way to create BOMs from .NET projects and optionally generate the vulnerabilities in the BOMs as well.

But in order for their BOM to be useful, the project needs to support Package URL. Refer to RetireNet/dotnet-retire#33, and optionally CPE.

I would recommend creating an enhancement request for that project to support the output of CycloneDX with the vulnerability info.

[cmenzi]

I've just created the issue. Saw that you also added your comments in the issue you mentioned. 👌

RetireNet/dotnet-retire#66

[coderpatros]

Hmm... could I add the dotnet retire vulnerable packages as a vulnerability source to Dependency-Track @stevespringett? (MIT licence) Any minimum requirements/gotchas that I should be aware of?

The only well structured information besides package name and version is this...

"link": "https://github.com/dotnet/corefx/issues/19535",
"description" : "Microsoft Security Advisory 4021279: Vulnerabilities in .NET Core, ASP.NET Core Could Allow Elevation of Privilege",

[coderpatros]

Or, given the low quality and how specific this vuln information is, should I just write a tool to fetch the information and create the vulns in DT via the API?

[stevespringett]

If RetireNet ever supports Package URL, then yes, I plan to support it as an analyzer in Dependency-Track. Their data feed is missing a few things however.

• unique (per vulnerability) identifier.
  • What do we call it?
• severity
• purl (Look into the PackageURL format RetireNet/dotnet-retire#33)
• source (some vulns reference CVEs, others reference GHSAs, others don't reference anything other than a Microsoft alert.

If their data improves, there's a lot of potential for integration.

[johnkors]

Hi 👋 Re:dotnet-retire:

It's totally doable to go thru the list and add more metadata and output formats. If you want to contribute adding packageUrl support, I'm happy to review and merge.

With that said, I think we should also consider the fact the Nuget team and @blowdart is also working on a similar concept. They have a design spec going here: https://github.com/NuGet/Home/wiki/Flag-vulnerable-packages

As far as I understood, they will only flag Microsoft projects/nugets (correct me if I'm wrong, @blowdart ?), and will be based Github Security Alerts.

The initial focus is on leveraging GitHub's Security Workflow and integration with GitHub's GraphQL API.

Allowing other feeds other than Github seems to be in the backlog, at least.

The design spec did not mention formats or Package URL, but maybe you could get in touch with the nuget team around that..?

If dotnet-retire like functionality is supported natively by nuget, then I think we should deprecate dotnet-retire at that stage. So maybe it's more worthwhile heading down that route instead..?

[johnkors]

Did you consider adding the Github Security Advisory Events as a source directly?

https://help.github.com/en/github/managing-security-vulnerabilities/browsing-security-vulnerabilities-in-the-github-advisory-database#about-the-github-advisory-database
API: https://developer.github.com/v3/activity/events/types/#securityadvisoryevent

[mtsfoni]

As dotnet-retire has retired, I opened a new issue regarding using the NuGet vulnerability scan:

#805