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.

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.

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

1. 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.

2. 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.

3. 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)

I've noticed that other Artifact management systems are offering products for IaC Scanning -- looking for vulnerabilities, known misconfigurations, best practices, etc. This could be a feature that would be a nice supplement to ProGet.

Most of what I've seen has the IaC scanning centered around Terraform templates. I'm using ARM/Bicep since we're completely Azure based for cloud presence.

I'm not 100% sure how the other products are doing IaC scanning -- it may be along the lines of scanning a Terraform Private Registry, ensuring that modules there are up to standards. With Bicep/ARM, Azure provides Template Specs as a manner of storing and cataloging private modules that can be imported into templates. I don't think its prudent to reinvent Template Specs into ProGet, but it would be nice to get the best practice and quality checks to be made against ARM/Bicep templates stored inside of artifacts in ProGet.

In our instance, the templates are typically stored inside of a nuget package, although a universal package could be used instead.

Are there any others looking into IaC scanning, particularly in an Azure + ARM/Bicep organization?

I wonder if its an issue if the old JSONPath was pulled locally first, then jsonpath was pulled. Right now, we just have a workaround by disabling npm audit support in ProGet, which allows our builds to run, but that disables a legitimate feature because of this one edge case.

My guess is that some DB cleanup would need to happen to purge JSONPath and jsonpath from all memory?

Thanks for the details. We did delete jsonpath and JSONPath from our local feed, but once ProGet caches the jsonpath package locally, it starts to display as JSONPath on the ProGet site. Is there a way to force the site to recognize it as jsonpath instead since v1.1.1 is the only one locally?

The vulnerability has already been assessed as "Not Applicable" and that's where the "info" comes up, as shown by your code snippet. The problem is that NPM does not have info as a classification and cannot parse it

Part of the issue here is that the results from ProGet do not match that of the public registry. Yes, it is an edgecase where there are 2 packages with the same name but different capitalization, but its also a fairly common package.

npm audit is a step that is run by default as part of npm install and other standard functions. This is to advise of package updates, end of support, and vulnerabilities by priority. Simply replacing NPM with pgutil is not a small feat, especially with standard common tooling already in use across the field.

The fact that our builds fail because of the mismatch is problematic, and shows that two unique packages are being mixed by ProGet. The audit caught it, and prevented the two from being crossed

We ran into an issue when a NPM package has a vulnerability, but an exception has been made to allow the package download. The example we have was static-eval v 2.1.1

We have an exception on the PGV-2133354 vulnerability since it has been withdrawn.

npm audit and npm install fail because the severity level of the vulnerability with exception is info which is not a supported level by NPM. the output from npm is:

npm ERR! undefined is not iterable (cannot read property Symbol(Symbol.iterator))

NPM Audit Severity Levels
And you can see in the NPM Audit code that it does not expect info as a severity level

Output from ProGet npm/v1/security/advisories/bulk endpoint:

Right now we are NOT able to build with this package without disabling vulnerability detection, which is not permitted by corporate policy. How can we correct the output from ProGet so that npm will successfully build

we recently had users having issues if their NPM project depended on the jsonpath package. Our NPM feed uses a connector to the public NPM registry, and we had pulled version 1.1.1 to our local proget. Apparently when this was done, the package was saved to ProGet as JSONPath.

This resulted in the packument data pull in npm audit to fail since the metadata JSON (at https://progetserver/npm/feedname/jsonpath) had the name JSONPath but the package name is all lower case.

Removing the package and all versions from ProGet and clearing it from disk does appear to work, but once we pull it back into ProGet, it will fail.

NPM is very clear in their documentation that package names should always be all lowercase because of case sensitivity differences between OSes.

How can we fix ProGet so that we can pull the jsonpath package locally but keep the proper naming convention?