Projects, builds and SCA.

dlundqvist

Hi,

I'm currently evaluating ProGet and have some questions.

The product I'm working with does not generate packages as such during its build. Rather various archives that contain installation scripts or add-on products that are managed by the base product. I suppose these would be Assets in your terminology. From my understanding Builds can only contain proper packages? And not Assets?
Given above I suppose we could package our artifacts as Universal Packages. I've done that for one artifact but it's not clear how I can add that package to a build. I tried using the web UI but I don't know what "purl" is supposed to look like. Do you have any information about that?
If Universal Package is the way to go, how can I add that during the build with "pgutil"? It seems "pgutil" can only scan for dependencies, and can't see how it would pickup our Universal Packages.
Would SCA be able to scan our Universal Package? It's an archive containing RPMs (among other files) that is to be installed on a server.
From our Universal Package can ProGet detect/correlate dependencies from feeds/connectors?

Thanks in advance.

atripp

Hi @daniel-lundqvist_1790 ,

I'm not really sure what you're trying to accomplish, but I'll try to give some background surrounding your questions.

First, some quick terminology:

Assets are basically just files in folders, like an S3 bucket or share drive. You could put whatever you'd like in an asset directory.
A Build is basically a "set of related SBOM files" and is basically a way to organize/track SBOMs and their compliance
An SBOM is basically a list of purls (package type/names/versions/etc) and purls almost always refer to third-party, OSS packages. However, ProGet can (and often will) cache these OSS packages in feeds.
Universal Packages are intended for your own, proprietary content. They are basically an alternative to storing things in folders or in a file like myApp-3.2.zip
Dependencies in Universal Packages always reference other a Universal Package or range of packages; they are basically just another metadata field like package description, but with a standard format

I can't say if Universal Packages or Builds/SBOMs are a good fit for your product. It really depends on what what problems you're trying to solve. If you can talk more about that, we'll try to help better.

That said, you could technically craft an SBOM that references Universal Package purls (pkg:/upack/myPackage@4.2.1), and then create/add that to a build, but it doesn't make a lot of sense to me. SBOMs (and SCA in general) is intended for OSS compliance, and that's how ProGet uses it.

pgutil builds scan will generate and upload a basic SBOM file during the build process for .NET, npm, and Python applications. It's basically a lightweight alternative to CycloneDX, which also generates SBOM files.

As for dependencies, neither pgutil nor CycloneDx will read "dependency metadata" from package manifest files; instead they inspect the packages that were installed/downloaded by the build tool. Package dependencies are somewhat orthogonal to SCA/SBOM.

I'm not sure if any tool out there can generate an SBOM file given a list of rpm packages, but they're pretty easy to create with a script and upload to ProGet.

Hope that helps,
Alana

dlundqvist

Hi,

Thanks for your response. And apologies for my delayed response, I got sidetracked with things for a while.

That Builds are tied to SBOM and only to other packages indirectly was the missing link for my understanding. Thanks.

Besides proxying public repositories for Debian, CentOS, npm and maven we want to have one authoritative place that knows what builds/releases are made up of, and potentially download them from. This is where feeds/connectors and SBOM/SCA come in. I believe feeds/connectors will work fine, I still have some more tests to do there.

For the products I'm working with I don't think pgutil scan will work out of the box. We would be fine with finding solutions to create/manage SBOM ourselves, if it means we can still use the rest of the functionality.

Regarding which problems we're trying to solve:

One place where we pull packages/dependencies from (possibly curated).
One place which is the source what a build/release is (possibly given a SBOM)
Fulfill current and coming legislations when it comes to software security and supply chain risk management.

Given my new understanding on how ProGet operates I believe it would work for us, but there are still a few thing I would to verify. Our trial license expire while I was tied up with other things, would it be possible to get an extension to that?

atripp

Hi @daniel-lundqvist_1790 ,

Based on the problems you're trying to solve, I think ProGet sounds like a good fit.

There are quite a few tools that can generate an SBOM document in the CycloneDX format that ProGet uses; see https://github.com/CycloneDX for the most popular ones. We consider pgutil scan to be a "lightweight" version that works in most cases.

But I think you'll just want to generate your own. It's a pretty simple XML format and easy enough to generate. ProGet can just acts as the SBOM repository in this case.

There shouldn't be a problem to extend the trial extension; you're able to request one on MyInedo on the day of expiry.

Cheers,
Alana

dlundqvist

Hi again,

It seems I can only request trial for Basic Edition. I would like to verify a few things that only exist in Enterprise Edition. How could I request and extension of that?

Thanks in advance,
Daniel

atripp

Hi @daniel-lundqvist_1790 ,

You can select the edition you'd like to trial within the software itself, under Admin > License Key.

Thanks,
Alana