Request for Creation of API for Package Auditing Before Dependency Restoration

fabrice.mejean_5174

Hello,

I would like to submit a request for the creation of an API dedicated to auditing packages prior to the restoration of dependencies within our software factory. Currently, we utilize Native APIs to validate the dependencies used by an application before restoration. However, this approach has certain limitations that lead us to seek a more efficient solution.

Below are the key functionalities we would like to see implemented in this new API:

Verification of Package Promotion:

Currently, the existing API verifies if the package has been promoted, but it does not confirm whether the package is still present in the target. We would like a more thorough method that utilizes the package API to verify the presence of the package.

Status of Obsolete Packages:

There is currently only a "set package status" API, but no "get package status." We need functionality that allows us to retrieve the status of packages to identify those that are obsolete or blocked from downloading.

Vulnerability Checks:

We need to verify package vulnerabilities and indicate those that are blocked from downloading due to critical vulnerabilities, along with their severity ratings.
The goal of this API would be to perform a complete audit of dependencies before the build process, preventing issues during package restoration. This would enable developers to quickly diagnose and resolve installation problems, ultimately saving them a significant amount of time.

Additionally, I want to highlight that the current audit API requires the registration of a build to function, which is not feasible in our context, especially for builds that have not yet been initiated.

Thank you for considering this request. I am available for any further information or to discuss the details related to this proposal.

Best regards

Fabrice MÉJEAN

stevedennis

Hi @fabrice-mejean_5174 ,

Thanks for the suggestion; to help move this forward, we thought about this from a technical standpoint. We're a little hesitant to call the command pgutil packages audit since there's already an audit command for builds and vulnerabilities.

One idea is to deprecate pgutil vulnerabilities audit and call it pgutil packages audit instead.

In any case, this new command is a combination of pgutil builds audit and pgutil vulns audit.

The pgutil packages audit command would input a project, something like this:

pgutil packages audit --project=c:\projects\MyProject.csproj

Behind the scenes, pgutil would parse and POST a packageset:

POST /api/sca/audit-packages
[ 
    {
        "name": myPackage
        "version": 1.2.3
        "type": "nuget"
    },
    {
        "name": myPackage
        "version": 1.2.3
        "type": "nuget"
    }
]

The API would return an array I suppose (we don't have any samples for that, but it's a serialized BuildInfo.cs), and the end result would look like this:

$> pgutil packages audit --project=c:\projects\MyProject.csproj

Parsing MyProject.csproj... found X packages.

Azure.Core-1.35.0
 Compliance      : Compliant
 License         : MIT
 Vulnerabilities : None

Microsoft.Extensions.Configuration.EnvironmentVariables 8.0.0 
 Compliance      : Noncompliant
 License         : MIT, Apache-2.0
 Vulnerabilities : PG-123456 (High)
   the vulnerability title of this vulnerability goes here

The API could obviously contain more info. It's documented via serialized .cs classes here:
https://github.com/Inedo/pgutil/tree/thousand/Inedo.ProGet

Thanks,
Steve