Weston Steimel

We could probably start by just using the data from https://osv-vulnerabilities.storage.googleapis.com/PyPI/all.zip since the python GHSA info is included there now and is already in OSV format.

For the deployed artifacts of a .NET Core app I think you typically end up with something like `.deps.json`. This is an example output for `TestApp.deps.json` ```json { "runtimeTarget": {...

Also, if it's helpful the NuGet scanning currently implemented in [aquasecurity/trivy](https://github.com/aquasecurity/trivy) is at https://github.com/aquasecurity/go-dep-parser/tree/main/pkg%2Fnuget. Also, it's worth considering that the .net core dependencies spec went through several iterations in earlier...

I was hoping to get a chance to look at this one during my break, but so far things haven't really gone to plan. Still a possibility I might get...

Another thought I had here is that it would be great to eventually support somehow extracting the version information from the compiled DLLs themselves. I believe that information is persisted...

Also, should we consider eventually having two separate cataloger packages here, one `dotnet` for the modern cross-platform version (also sometimes referred to as .NET Core) and a separate package `dotnetframework`...

@cpendery , thanks, that would be fantastic!

As an example, this is what the `DESCRIPTION` file looks like for the [odbc](https://cran.r-project.org/package=odbc) package ``` Package: odbc Title: Connect to ODBC Compatible Databases (using the DBI Interface) Version: 1.3.3...

I had always envisioned some other tool after syft doing the enrichment. Then you have a trail from the original sbom and an option to use the enrichment or not...

Yep, thanks @rigzba21, I had thought a bit about trying this before but never got around to it. One thing that will be interesting here is syft already identifies packages...