SCA Feedback/suggestions 2024

dan.brown_0128

In re-evaluating the SCA Functions of Proget 2024, we've come up with a few functionalities that would be big benefits. Posting it publicly in case others have similar thoughts

Be able to add a link to our CI build and CD deployment on a build's release (for Inedo, this was mentioned in EDO-10735)
This could probably be as simple as adding two optional fields in the "Create Build" modal and/or in the build promotion process. Of course this would also want/need to be implemented into the pguitl CLI.
Dependent Package's 'Usage in Projects' should show latest version in addition to prior versions (EDO-10736)
It'd be helpful to quickly see all versions of an SCA project that reference a specific version of a dependent package. Right now it's labeled for the Latest version, although on our instance it appears to not correctly show the latest.
Link between SCA Build and the artifact
Bringing back up this topic from last year. Having a way to link an SCA Project/build back to the artifact that corresponds to the full BOM would be great, especially if it shows the vulnerabilities of the package discovered from the BOM analysis. This would let us block downloading of packages we've built that may now contain vulnerabilities that have come up over time.
I wrote up a more narritive version of what I'm thinking:

Imagine we have MyCorp.Package v1.0.0 which is a nuget stored in the internal-apps feed

It has dependencies of Ext.Dep.1.1.1 and Ext.MS.Dep2.2.2 which are in the approved-nuget feed

We upload the SBOM

If you go to Ext.Dep or Ext.MS.Dep in approved-nuget feed you will see that each is used in the MyCorp.Package project (makes sense, those are dependencies of the package).

But if you go to MyCorp.Package in internal-apps, you don't see it used in a project, since its not a dependency, but rather is the project itself. Wouldn't it make sense for this to link? That way if your package has a vulnerable dep (and the project shows vulnerabilities), you can see that at the top level (and maybe block downloading the applications package)t at the top level (and maybe block downloading the applications package)

atripp

Hi @dan-brown_0128 ,

Thanks for sharing!

#1 and #2 will be pretty easy UI changes - and I'm almost certain there's already a URL for Builds, but it's just not linked.

#3 is complicated, since we do not model package consumers (which would allow you to say "show me all packages that use X") nor do we have the concept of "application packages" (e.g. MyCorp.Package is also a project), so we'd have to really think about how to create a use case for this.

As an FYI, our team we're currently pretty heads-down on feeds (new Maven feed, then Rust/Cargo, Terraform, PHP/Composer, C++/Conan), PostgreSQL migration, and a few other things, but our rough plan is to resume working on SCA stuff in Q1.

If these are a particular blocker for rolling out the feature, we can consider to shift focus.

dan.brown_0128

For #3 (which unfortunately is probably the biggest potential win for us), I might have an idea...

Currently when editing the Project's settings, you can specify Feeds - which I'm understanding are the feed(s) that provide the packages outlined in the SBOM - ie the dependency source from the build).

What if at that level it was broken out to input/output feeds? The artifact MyCorp.Package, which resulted in the SBOM, was stored in the "internal-apps" feed, and it was built using dependencies in the "approved-nuget-feed." Now, this would assume that the project name and resultant package name are the same, but that shouldn't be too unreasonable.

Again at a high level, what we're wanting is to be able to block our custom built packages if its dependencies (identified by SBOM) become vulnerable (or are otherwise deemed noncompliant). Since these packages will never be known by any OSS index or the ProGet Security, it wouldn't be flagged by traditional vulnerability means, and that's why the SCA/SBOM is useful.

atripp

Hi @dan-brown_0128,

Thanks we'll definitely keep this in mind when we explore updating/expanding the feature!

In the meantime, I think there might be a better workflow for you to consider. We wouldn't recommend using "download blocking" for an application packages like this.

The reason is... the status could change, and when you go to deploy the application, it will probably fail in an inconvenient place and the person doing the deployment won't quite get why there's a random error/crash.

Instead, how about using pgutil builds audit as a means to achieve a similar goal? You would run it as a deployment precheck, and the tool would output errors if the compliance status of packages were not acceptable. This will be much more intuitive of a failure, and you could run it early in the process.

I'm not quite sure if pgutil builds audit is suitable today, but I know that's on our shortlist to get working, and create HOWTO guides for using it.

Cheers,
Alana

dan.brown_0128

The reason for blocking application packages like this, that have vulnerable dependencies, comes down to security governance. While yes, it can be inconvenient if a package that has worked before is now blocked, that does prevent us from introducing known vulnerabilities into our environment. In the event of an emergency deployment (ex prod rollback, etc), we could apply a temporary exemption to allow the package to still deploy -- after doing a risk assessment.

To use the log4j example again -- if we have an application that was built with a vulnerable version of log4j, nobody would want that package to get deployed again (while also remediating it anywhere that it was already deployed). From what I can tell the most effective way would be to block the download from ProGet - if we can leverage it's automatic blocking functions.

Adding the audit into the deployment process is definitely one way to partly add this security layer but it'd require active implementation for all of our deployments, and opens more opportunity for teams to skip or work around it. Basically its better than nothing yes, but it's not the most effective security enforcement measure.