Look into the PackageURL format

[johnkors]

https://www.riskbasedsecurity.com/2018/08/thoughts-on-the-ntia-software-component-transparency-meeting/

https://github.com/package-url/packageurl-dotnet

[stevespringett]

I'd really be interesting in having this project support PackageURL.

The project I work on, Dependency-Track, has support for NPM Audit, OSSIndex, VulnDB, with a few others in the works. The entire project is based on the simple concept of using standardized software bill of material documents, and in doing so, we're able to produce some really accurate results. If the bill-of-material format is https://www.nuget.org/packages/CycloneDX, then it supports both direct and transitive dependencies. So an entire solution or project(s) would be imported into Dependency-Track and continuously analyzed. PackageURL is becoming an important standard (already adopted by Dependency-Track and OSSIndex) with supporting being planned by RedHat, SPDX (Linux foundation) and others.

If this project were to support PackageURL, I'd be able to easily integrate it into Dependency-Track as a source of vulnerability intelligence.

However, in order to do so, the feed would also need to adopt:

• Severity (CVSSv2, CVSSv3, or CRITICAL/HIGH/MEDIUM/LOW)
• Reference to CVE (if one exists)
• A unique identifier (i.e. RETIRENET-1, RETIRENET-2, etc) for each vulnerability. This could be as simple as Content/7.json. There isn't anything in the spec that indicates that the content in 7.json is unique though. So this would either need to be stated, or a new field added to the json to indicate its unique identifier.

If RetireNet were integrated into Dependency-Track (again requires PackageURL and the few things above), the users of the platform would see a RetireNet configuration screen similar to whats here: https://docs.dependencytrack.org/usage/scrm/ along with a RetireNet label next to each of the vulnerability identifiers when viewing results.

One question though. I went through all the feeds and noticed all the vulnerable components were System or Microsoft. Does this project focus specifically on core libraries or is there interest in tracking third-party libraries as well?

[johnkors]

Hi, Steve! The dotnet-retire project basically came out of the need to scan my own projects for the vulnerabilities as provided by Microsoft thru the announcement repos. I wrote a small note about it at our blog.

It's basically an interim solution until @blowdart solves this part of the dotnet SDK, similar to npm audit. That's at least my expectation of what they are going to produce. As far as I know, he's in the start phase of that project at Microsoft, but I know very few details other than it spanning 6 or so teams at MS. It would be nice if they adhered to an adopted standard as well — but maybe you've already talked to them about PackageURL?

From what I gathered, MS were a bit reluctant to du vulnerability flagging on other components than their own, so maybe there will still be a need for maintaining tracking for non-MS components by the community in a central db.

But to answer your last question: no, there's no reason to restrict the flagging on MS components at all. It's just what was the most critical and most visible when I created the tool.