ProGet SCA: SBOM export does not work + UI issue

jw

Stumbled across two issues during SCA testing and a question related to SBOM export:

1. SBOM export does not work

Clicking on "Export SBOM" and choosing either JSON or XML both leads to a popup with the following error message:

The webpage at https://x.x.x.x/0x44/ProGet.WebApplication/Inedo.ProGet.WebApplication.Pages.Projects.Builds.ExportSbomPage/ExportSbom?projectId=5&buildNumber=3.0.0-beta.2024-03-04.9999&format=xml might be temporarily down or it may have moved permanently to a new web address.

Exception in the Diagostics Center:

An error occurred in the web application: Value cannot be null. (Parameter 'key')

URL: https://x.x.x.x/0x44/ProGet.WebApplication/Inedo.ProGet.WebApplication.Pages.Projects.Builds.ExportSbomPage/ExportSbom?projectId=5&buildNumber=3.0.0&format=json
Referrer: https://x.x.x.x/projects/builds/export-sbom?projectBuildId=6
User: xxxxxxxxx
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
Stack trace: at System.Collections.Generic.Dictionary`2.FindValue(TKey key)
at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& value)
at Inedo.ProGet.Projects.BomUtil.Munge(Bom bom, IEnumerable`1 originalBoms)
at Inedo.ProGet.Projects.BomUtil.ExportBuild(Int32 projectId, String buildNumber)
at Inedo.ProGet.Projects.BomUtil.ExportBuildJsonAsync(Int32 projectId, String buildNumber, Stream output)
at Inedo.ProGet.Projects.BomUtil.ExportAsync(AhHttpContext context)
at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

2. Question about SBOM export

When uploading a SBOM as JSON and then using the "Export SBOM" functionality and selecting JSON again, what happens during export?

Is the uploaded JSON returned exactly (identical file hash) like it was uploaded, or is there some "processing" in-between, e.g. it is run through CycloneDX Models/APIs and the exported SBOM is a new output which might have different package orders, etc.?

3. Build version numbers are cut off on the projects page

stevedennis

Hi @jw,

[1] Based on the stack trace, I think the issue is that one of the SBOM documents you uploaded has a Component with a null/missing Purl field. Obviously this should error, but that's what the error must be looking at the code. If you can confirm it, that'd be great.

[2] ProGet is considered the "source of truth", so a new SBOM document will be generated based on the build packages. That SBOM will then be augmented with some information in the original SBOM(s), such as component "Pedigree", "Description ", etc.

[3] Thanks, we'll try to play with CSS to improve this down the line.

Thanks,
Steve

jw

[1] Based on the stack trace, I think the issue is that one of the SBOM documents you uploaded has a Component with a null/missing Purl field. Obviously this should error, but that's what the error must be looking at the code. If you can confirm it, that'd be great.

Yes, we are adding components with type Application that represent parts of our product into the SBOM via CycloneDX libraries. As these do not come from a package manager, they do not have a purl.

According to the spec that should be ok.
https://cyclonedx.org/docs/1.5/json/#components_items_purl

[2] ProGet is considered the "source of truth", so a new SBOM document will be generated based on the build packages. That SBOM will then be augmented with some information in the original SBOM(s), such as component "Pedigree", "Description ", etc.

Good to know, thank you.

stevedennis

@jw thanks for clarifying! We'll get the error fixed, but these would not show up in the export, since they are not a build package then

jw

@stevedennis

Was the 3rd point addressed yet? I tried clearing the browser cache, but it still looks like this for me in 2024.7:

stevedennis

@jw this was not addressed; the "build pipelines" are fairly primitive ProGet 2024, and we plan to review it as a whole as we get more feedback from users

If you click on "all builds" that might be the view you are expecting

jw

In this case, allow me to sneak in my feedback instead. ;)

At the moment we are not planning to use the "build pipelines" feature at all. So from our point of view, it would be good if there was a way to opt-out of it.

For this page that would basically mean the previous behavior: When one clicks on a project and the "build pipelines" feature is disabled, it would directly navigate to the "all builds" page like before.

stevedennis

Hi @jw,

We'd love to learn more - why not?

We envisioned that there would be lots and lots of builds in the Build stage (i.e. created by a CI server), and the ones released might got to a stage like Production.

Thanks

jw

Our leading system, when it comes to deciding what state a build is in, is our build server. So, it does not really make sense for us to maintain this state in another system.

Also, similar to you guys, we are a product-based business, so we need to assume that all our stables releases are in production somewhere at any time.

In ProGet we just want to see how issues with our dependencies (license, vulnerabilities) are changing over time. To keep down the "CI beta build spam", we will either use the archiving feature or maybe even clean out old beta builds since it makes no sense to keep tracking those.

stevedennis

@jw thanks for clarifying!

The pipelines in ProGet are not really meant to track status. The main reason for the build stages is to control automatic archival, issue creation, and notifications. For example, your stable releases might stay in a "Released" stage indefinitely.

We also had (in the preview feature) threre build statues: Active, Archived, Released. We don't use Released currently, but definitely something we may bring back. You don't want to delete a Released build, but you would probably want to delete an Archived build.

Anyway, I'd check out the pgutil builds promote command - that way you can keep your "archival rules" in ProGet.