Hi @Ashley , Amazing, thanks for this investigation! This is very helpful. You've also captured the exact issue we have with a lot of these APIs; no real specs (or worse... wrong specs), which involves a reverse engineering effort. This quote is wonderful: In summary, due to the lack of an official JSON schema and potential changes between npm versions, it's crucial to treat the npm audit --json output structure as subject to change. Relying solely on the npm CLI source code for the most accurate and up-to-date information is recommended, along with implementing robust version checks and testing in your development processes. Wouldn't it be nice if we could build our products like that! Anyway, I was curious and I asked internally, and the original engineer is almost certain that npmjs used to have the CVE number there, which we also used to emit until changing to PGVD number in ProGet 2023. But that is consistent with their position of "we don't do specs, just read the latest commit to figure it out. But it doesn't really matter, that's what we have now... To ensure consistency with the public npm registry, would it be possible to change ProGet to use a number for the id field on the audit response? If you discovered this in ProGet 2025, we'd just change it in ProGet 2026 and not worry about it. But we need to be super-careful making API changes in a maintenance release. We can't quite get away with Microsoft/GitHub levels of quality :) Seemingly harmless changes lead to broken builds, which are really painful to debug; for example, we recently added upload-time to PyPI API. That caused older versions of the pip client to break due to a bug in how they parsed dates. There are probably too many client/versions to answer the question "what is this field even used for and what are the consequences of changing it?" Perhaps an easier route is to just get pnmp to change to a string, like the rest of them? Or, just ignore it and "let it be"? Over time, if you follow our recommend best practices, these audits will show fewer and fewer vulnerabilities. We plan to continuously refine the PVRS algorithm to better combat both "vulnslop" (i.e. AI-discovered and AI-generated vulnerabilities that cannot be exploited in any real-world scenario nor would cause any real-world harm if so) and misreporting. Thanks, Steve

Hi @Ashley , It sounds like you're definitely looking in the right place / setting the right configuration. X-Forwarded-For should do the trick, but something as silly as a typo (which I've done several times) will make it not work. Here are the settings we recommend: proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $http_host; proxy_set_header X-Forwarded-Port $server_port; And as an FYI, here is the code we use to get the ClientIP adddress. public static string GetClientIPAddress(this AhHttpRequest request) { ArgumentNullException.ThrowIfNull(request); var forwardedFor = request.Headers["X-Forwarded-For"]; if (!string.IsNullOrWhiteSpace(forwardedFor)) { var ips = forwardedFor.Split(','); var clientIp = ips.FirstOrDefault(); if (!string.IsNullOrWhiteSpace(clientIp)) return stripIpv4OverIpv6(clientIp.Trim().Truncate(50)!); } return stripIpv4OverIpv6((request.NativeRequest?.HttpContext?.Connection?.RemoteIpAddress?.ToString() ?? request.UserHostAddress).Truncate(50)!); static string stripIpv4OverIpv6(string ip) { if (ip.StartsWith("::ffff:") && ip.Contains('.')) return ip["::ffff:".Length..]; return ip; } } Although I think the stripIpv4OverIpv6 bits may be relatively new. Thanks, Alana

Hi @Ashley, Glad to hear that fixed the issue with the Project Name! You are partially right on the noncompliance. The publish date is definitely causing most of the packages to be noncompliant. Based on your logs, I'm also seeing at least one deprecated package as well. I see you already have another forums post about the recently published issue. I believe we can continue that issue there and close this one out. Thanks, Dan

Thanks @atripp, that makes sense. I was having another issue with pgutil which turned out to be my fault, however I believe there is a follow on issue to do with the compliance analysis for project builds that have yet to have been pulled to ProGet. More detail on my original post here: https://forums.inedo.com/topic/5733/proget-unable-to-publish-sbom-from-pgutil/4. @Dan_Woolf suggested continuing the topic here as it's related to non-compliant packages and what I believe to be the recently published rule. Is this something you can take a look at? Thanks!

Hi @ashleycanham , This is a fairly complicated issue behind the scene, and is related to how these packages have multiple casings across different versions. This is something that should be addressed with PG-3100. After upgrading, you'll want to re-index the feed. If any packages still have incorrect casing, you can re-upload them to ProGet to correct the names. -- Dean

Hi, We upgraded to 2025.9 after testing in our dev environment and ProGet is now importing PyPi packages from the drop folder Thanks!