Hi @dbojak,

Great questions, and we're happy to help.

We're currently working on developing our best practices for application activity, and I'd like to share our current guidance, which is a work in progress. This is based on working closely with customers over many years, both proactively (developing policies) and reactively (actively helping investigate after an incident).

(Work in Progress)

Before looking to "ingest all the logs", identify a clear scenario that's contextualized to the product. For example, what does the Information Security team have in mind for monitoring, incident investigation, and compliance? What kind of incidents? What monitoring do they anticipate? And compliance with what?

ProGet attempts to provide appropriate "visibility into user activity and administrative actions", so if there are gaps I would start there. What is missing? How does duplicating data help? Etc.

For example, knowing which users download which Microsoft-owned packages on which day/time is not only impractical, but it serves no conceivable business benefit nor reduces any risk. But it could impact developer productivity and will increase costs across the board.

In addition, Microsoft Sentinel doesn't provide any contextualized visibility and, chances are, you will just end up back in ProGet searching for data anyway. So all the time and bandwidth spent exporting/duplicating data just ends up being waste.

That said, we don't have any built-in functionality to export this data, but it's relatively easy to export/ingest from the EventOccurrences table. These work differently in each product, but are similar in design.

[1] We do not have a documented, exhaustive list of audited event types exists per product, but it's relatively easy to attain through SELECT * FROM EventTypes type of query. That's the "source of truth" for events

[2] Direct database is the only option; we consider it quite stable, and it hasn't changed since like 1.0 of the products; there hasn't been any real demand to redesign or enhance it

[3] Audit events are never automatically purged, nor can they be deleted from the UI/API; they can only be manually purged from the database

As for the gaps you identified, those are things we can certainly consider addressing, provided it's within the confines of the existing design. It's relatively easy to add a new event type (if needed) or add additional audit data.

Overall, it's meant to be an "audit trail" instead of "change log" -- so it's not always the most user-friendly, uses more system-level concepts, and prefers immutable IDs over names.

Hope that helps!

STeve

Hi @amy.j ,

The URL doesn't appear to be a valid Debian repository.

Navigating to the root gives an AccessDenied error. In a normal repository, there is usually a kind of file list/system. But that's not required.

The root of a Debian repository has a dists folder, and then a folder for each contained distro, and a Release index file. I tried to navigate to $ROOT_URL/dists/trixie/Release but received the same error message. I also tried stable, but it didn't work. Maybe there's a dist that will work, but I don't know what it would be.

Thanks,
Steve

Hi @caterina ,

The "manually blocked" workflow you described is not recommended anymore; the sheer number of new vulnerabilities (including all the AI-generated, non-exploitable "vulnslop" entries) make that workflow imprudent. In addition, most vulnerabilities will be discovered long after you add the package to your product.

If you haven't read it already, I'd check out Vulnerability Management Done Right with ProGet, which helps prioritize.

That said, it's possible to configure a similar workflow; we describe it a "triaged approach" in Overriding Assessments & Default Behavior.

It's also possible to assess a vulnerability even though no packages are impacted; in the above screenshot, you would just click "Monitor" and then override the assessment to something else.

Hope that helps,
Steve

Hi @carl.westman_8110,

There's no problem adding an encryption key to an existing instance without one.

The data will still be stored in plain text and can be read without a problem.

The next time you edit (save) the connector data, the secrets (password) will be stored as encrypted. Obviously, if you removed or changed the encryption key, you wouldn't be able to read the data again.

For this, there's really no preferred operation when it comes to SQL Server vs PostgreSQL.

Thanks,
Steve

Thanks @caterina!

Just to give you some more technical context, which you probably already figured out...

The "old" vulnerability model worked by downloading a datafile from security.inedo.com, unpacking it, and inserting rows in the PgvdVulnerabilities and PgvdPackageNames tables. Those tables contained every vulnerability in our database and it was a bit tricky to know which of those vulnerabilities related to package versions "in" ProGet. The PgvdAssessments table helped somewhat.

The "new" model works by downloading an indexed database file. The "Assess Vulnerabilities" function (which rurns on that download job as well) will iterate over all vulnerabilities in that database and adds/removes rows to the PgvdVulnerabilities26 tables as needed (including PgvdPackageVersions), which makes it much easier to know if a vulnerability impacts a version "in" ProGet by looking at the database.

There are most certainly edge cases and glitches in this, so don't hesitate to let us know if you spot any odd behavior.

Thanks,
Steve

Hi @caterina,

It's quite complicated and there are a lot of technical details that I'm not immediately familiar with. To properly answer, I'd need to set up a reproduction case and then attach a debugger to give you a more technically precise answer on why it's displaying that way.

We may even need to do a whole database backup, since it might be specific to your configuration. I really don't know how much of an investigation it would require.

We added the dotted line as primarily a way for us to identify the system state when there are issues reported. Previous version of ProGet also had provisional assessments, but it was never visually indicated.

Anyway, if you're seeing any problems jut let us know -- this shouldn't have any impact outside of the dotted-line display on some pages.

Thanks,
Steve

Hi @caterina ,

The dotted border indicates what we call a provisional assessment; we don't have a great description for what that means, but that's what you'll see when a package is not local or cached in ProGet.

Without getting into too many technical details, that's the expected behavior (i.e. not in the database, not on the SCA > Vulnerabilities page). Once the Vulnerability Download job (or Admin > Vuln Types > Reassess) runs, it should become a normal assessment (i.e. show in the database, etc).

In any case, whether an assessment is provisional or not shouldn't have any impact on compliance analysis. The most notable impact is that it won't show up on the SCA > Vulnerabilities page until another job identifies the package as being "in" ProGet.

Thanks,
Steve

Hi @amy.j,

Good news! We've decided to correct this, along with some other errant behavior with carrying over certain server-side metadata from connectors.

We are planning to ship this in the upcoming maintenance release (scheduled for August 7) via PG-3342 (FIX: Ensure correct server-side metadata (publish date, listed, deprecated) is set when adding package via pull, download, or promote from remote connectors).

This is currently in testing / code review now, asit's a bit of a riskier change. But assuming there's no issues with it, it will be available after the release.

Thanks,
Steve

Hi @amy.j ,

This behavior is expected, as the publish date is not carried over via a promotion.

In retrospect, it should have - but this is the sort of behavior we need to be careful about changing in a maintenance release. We'll discuss this internally and decide - please stay tuned, wehope to update by end of next week.

Thanks,
Steve

Hi @daniel.mccoy_4395 ,

This is how unlisted packages are designed to work; it's just a flag in the metadata, and clients will treat it however they'd like. Visual Studio hides them but lets you download them, ProGet shows them with a little "unlisted" icon.

As for the download error, the 400 sounds like you've configured "download blocking" perhaps? Check the feed's policy settings.

We generally don't recommend configuring download blocking, but using pgutil builds scan instead; see https://guides.inedo.com/vulnerability-management/containment/

Hope that helps,

Steve

Hi @olivier-piron_7128 ,

I'm afraid this behavior is somewhat expected because TRK.0 is not a valid version number.

ProGet has some limited support for invalid version numbers, but this use case falls into one of those unsupported cases.

The reason is that ProGet is "package server" (as opposed to a file server), and all of the maven-metadata.xml files are generated by ProGet, on demand, based on items in the database. Uploads of maven-metadata.xml are simply ignored.

Compare this to Nexus (a file server), which serves the client-uploaded maven-metadata.xml files, and whatever other items were uploaded to whatever directory.

TRK.0-SNAPSHOT is technically a valid artifact name but an invalid version number, so it's treated like an artifact. And, since there are no releases of that package, you get a 404.

In this case, we would suggest you to switch to using actual version numbers. My guess is that TRK.0 is some kind of work-around for something. You could instead do 9999.9.9 or something, if you needed that kind of work-around.

Hope that helps,
Steve

Hi @jeremy-oaks_9309 ,

Just wanted to respond to this real quick:

I have ~80k packages (~600GB) -- so we're opting for the stand-alone database for performance purposes

Based on this information we still recommend using the embedded database; it's almost always going to be more performant as well as simpler to maintain. 80k is not that many packages by any stretch.

While @pg_user_8607 is correct in that it's a bit easier to monitor database performance, investigate issues like bad queries, and do DBA maintenance tasks - that's all technically "our job". From a user perspective, the only required "database maintenance" should be backing up the files.

We certainly don't mind the help (and users like @pg_user_8607 have helped us out a lot!!), and it may be quicker if you "know what you're doing" to get to a root issue, since we're not all exactly experts at all these layers. But I just wanted to make sure you were aware of the pros-and-cons.

Thanks,
Steve

Hi @gbeckett ,

There are Feed Names (which you can configure) and API endpoints (which you cannot configure).

Our general guidance on feed names is internal-nuget or public-nuget, but we've seen cases where a lot of feeds are needed. I suppose tenant namespace like tenant1-nuget might work too. But like naming of everything else, you'll figure it out as you go.

While you can't change API endpoints, you could use the alternative /endpoints url if you really wanted. So instead of /nuget/public-nuget it would be /endpoints/public-nuget. Honestly I wouldn't bother... it's just a URL that no one really sees, and that's actually going to make it more of a pain to support. That's why we don't expose this.

Some ecosystems (like Docker) only support one registry per domain/port, which is why Docker feeds have no prefix. We work-around this by using namespaces.

One option I'm considering is layer a proxy in front of ProGet, to provide the URL rewriting to map to ProGet-compatible names.

Please don't do this :) We do not recommend nor do we support URL rewriting like this. People have figured out how to do it, but it causes lot of headaches and it will be painful to debug. Which is why we don't support it. Again... it's just a URL that no one really sees after you enter it.

Hope that helps!

Thanks,
Steve

Hi @brandon_owensby_2976,

I wasn't able to reproduce this issue, but looking over the code, I can see a few scenarios in which "not configured to allow access to encrypted values" will trigger, even if that's not accurate. It's not trivial to rewrite that to provide a more accurate error message or credential resolution, so we'll add this to our BuildMAter 2027t roadmap and review it more closely then.

In the meantime, I would just use a variable and duplicate the information.

Thanks,
Steve

Hi @brandon_owensby_2976 ,

You are correct, the $BranchName function is a build-information function that provides which branch a build was created from. It's a slightly different concept than the "default branch" that is associated with a release.

If changing your workflow to align with more standard practices isn't in the cards, then you may want to create a custom extension that will allow you to create your own variable functions and operations. This will make adding things like this easy and if it's something we think is generally useful, then we can generally add it in.

Although it's not supported in the SDK, if you take a reference to the core assembly (buildmaster.dll), you can invoke database commands like Releases_GetRelease to find that information easily.

Thanks,
steve

Hi @andreas-unverdorben_1551 ,

I'm afraid this is a problem with our upstream source (GHSA). Long story short, the datafile is incorrect and does not specify a range.

We do not have any plans to build a system/module that allows us to "override" data in the upstream datasources at this time, so the only way we can really address it is by fixing the upstream source.

I believe the best route to do that would be to submit a pull request to the GHSA repository against the related datafiles (e.g. GHSA-4r6h-8v6p-xvw6.json)

In this case, they are missing a "fixed" event in the range:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            }
          ]
        }
      ]

Here's what it needs to look like:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": " 0.19.3"
            }
          ]
        }
      ]

Thanks,
Steve

Hi @brandon_owensby_2976 ,

You can configure release settings on an application-by-application basis under the Settings tab. In this case, you'd set Release Usage to be Optional or Disabled.

If Release Usage is set to Required, users must select a release when creating a new build; this was the deefault in older versions of BuildMaster.

https://docs.inedo.com/docs/buildmaster/modeling-your-applications/buildmaster-releases

Cheers,
Steve

@Nils-Nilsson excellent, let us know as you have other feedback too! This is definitely an area we intend to keep improving in throughout ProGet 2026+

Hi @carl-westman_8110 ,

Thanks for sharing that. This isn't a symptom of "server overload" that we've seen before.

The error you shared is occurring on Feeds_GetFeeds, which is definitely not an intensive query, and I would not expect that to be timing out at all. It's just SELECT * FROM [Feeds].

However, that's a similar symptom to the "AzureSQL resource throttling" that we've seen on other users: another query is being throttled (for example, something that joins on [Feeds]), and that is causing a cascading impact on other queries.

We don't have enough information to say that's the case here. But, an easy way to test would be to up your DTUs substantially.

Otherwise, the next troubleshooting step is to try to identify the cause of the timeouts, which involves looking at HTTP Access logs and jobs occurring around the same time under Admin > Scheduled Jobs.

Thanks,
Steve

Hi @carl-westman_8110 ,

Under Admin > Diagnostic Center, you should see some error-level messages logged. Can you share those? That will help us identify what the actual error messages are.

Under Admin > Scheduled Jobs, what do you see scheduled at midnight? Are you aware of other external scheduled jobs, for example backup or nightly builds?

One thing to be aware of... users with similar symptoms have discovered they were "rate limited" by Azure SQL. This doesn't lead to resource graph spikes or "419 errors" (like an API rate limit), but query throttling; some queries simply take 100x longer. And this eventually leads to random errors.

I think 10DTU is relatively small, so this could be happening? Anyway the error messages will show.

This may be a good opportunity to migrate to PostgreSQL, which will not have any kind of limits.

Thanks,
Steve