Hi @bobmaurer ,

Thanks for the inquiry! Hope you don't mind a little push back on this -- but we'd encourage your security team to read our Vulnerability Management Done Right with ProGet.

While we understand where they're coming from, the "weekly download" report is an anti-pattern these days and will lower the organization's security posture... which probably goes against their mission

The main reason is that it improperly treats vulnerabilities as security incidents while providing no realistic path to mitigate them. This is backed by a huge body of research, including our own State of Software Supply Chain Security and reports from industry analysts.

For example, they see "Joe Developer downloaded JsonLib 3.4.1, which has PGV-12345" -- what exactly are they going to do with that information? Contact Joe and ask him how he used it? Do they expect Joe to trace through 1000's of transitive dependencies across dozens of projects to see if he even knows where it's used? Tell him to uninstall it? Try to figure out if he caused damage? Or what application it was added to?

Obviously not, because there will be so many packages with vulnerabilities that no one knows where they came from. The "best case" is to get aggregate data -- and ProGet already provides that, but by application/deployment state (which is what really matters).

Anyway -- the best way to handle this is by implementing Software Composition Analysis in ProGet - we have all the tools to help Prepare for a Category 5 Vulnerability

Thanks,
Steve

Hi @brandon_owensby_2976 ,

This is a generic forums system that we're using for public-facing support of a niche software product, so most of the features like voting/reputation don't really apply.

Honestly I didn't even know those were features.... we recently upgraded the software, so maybe these were added? Anyway I just disabled them since we don't use them :)

We have internal tracking for everything - either as a scheduled YouTrack ticket (which we link to) or a roadmap item (internal project tracking) that we periodically review and schedule as tickets.

Thanks,
Steve

Hi @clsa,

If you're talking about the certificate errors under Admin > HTTPS, I wouldn't worry about those. An application does not need to validate its own certificate; it's only used to encrypt/decrypt the traffic.

The server transmits a copy of the certificate (without the private key), and the client validates the certificate before transmitting data.

Without getting into too many technical details, the only thing that really matters is if clients can connect to the application (ProGet) using HTTPS or not. There are a lot of reasons that may prevent the application from self-validation and it's not really worth trying to fix, since it's only used on that page to help catch basic errors.

Thanks,
Steve

Hi @clsa ,

We're not aware of any bugs or issues; SSL and Certificate handling is all done at the Operating System (Windows) or Platform (.NET) level; we just point the system to the file. In my experience there's usually some obscure registry setting that will control stuff like this.

Thanks,
Steve

Hi @brandon_owensby_2976 ,

You may be right here; we'll just need to dig in and research a bit more. "Everyone" tests with and assumes a Linux Stack when working with Docker containers/agents, so it's likely this is just an edge case that we need to review further.

We'll add this to our roadmap to do down the line.

Thanks,
Steve

@brandon_owensby_2976 thanks!! This one was also added to our roadmap to review.

@brandon_owensby_2976 thanks for the heads-up! We'll also review this down the line in our roadmap

@brandon_owensby_2976 thanks for the heads up; we'll add this to our roadmap to fix.

Hi @brandon_owensby_2976 ,

As I mentioned earlier, this is an issue with the dotnet container for Windows, not BuildMaster:,

The underlying error appears to becoming from the dotnet tooling. Though it's hard to say without troubleshooting further. Basically, something in the stack is calling the Linux tool id , which isn't going to work on a Windows container.

When you installed Git (which is basically a Linux tool), it must have included a Windows-version of id . That allowed the dontnet container to then work. You're probably the first person whose tried to use the dotnet container without installing Git as well ;)

As for a better way, just run on a small Linux VM instead on your Windows desktop (Hyper V). You're going to run into a lot of headaches if you try to use Docker Desktop.

Thanks,
Steve

Hi @dbojak ,

We do User-driven Development, so this is something we could work on after customer onboarding.

The audit changes you describe seem reasonable, although we would obviously need to work together to translate that to product-specific terms; e.g. there are no "feed security policies", just scoped privilege/restrictions that associate a principal with a task, and those are either are added/deleted. You'll understand these as you learn our product a bit more, however.

And obviously there are also some technical limitations far beyond ProGet - for example, knowing which user downloaded a package requires that user first authenticating to the feed. Otherwise these kind of changes are relatively easy to implement and something we can often add in maintenance releases.

However, it's unlikely we will add SIEM integration as a feature; it'd be a substantial undertaking that is like 95% outside of ProGet's core functionality, and would require continuously supporting third-party log aggregation platforms we have zero exposure to. We would need to see (1) a lot more demand, and (2) user-created prototypes that extract/convert from the database.

A handful of users have written "log exporters" to tools like Splunk, but they are so highly specific to their requirements that it would be impossible to generalize as an open-source tool, let alone a product feature.

Thanks,
Steve

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