administrators group

stevedennis

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

rhessinger

Hi @hardik.turakhia,

When you say external (org) PostgreSQL database, are you referring to a PostgreSQL database you are already hosting in your network and the one that is in the docker compose was for testing? Or are you just trying to host PostgreSQL in a separate container than ProGet, but both controlled by that single Docker compose file? If you are not using HA/Load Balancing, we recommend using the Embedded database. In a HA/Load Balancing environment, we recommend using InedoDB.

If you are still planning to use an external PostgreSQL database (InedoDB or PostgreSQL directly), here are some things to get you started. First, only InedoDB or ProstgreSQL 17 is supported. With that said, your ProGet service in your compose file is not quite right. You have duplicate volumes and your environment variables are using unsupported keys. A good starting point for you should be to review our Docker Compose guide and our Docker guide. Based on that, here is a better ProGet service node that can get you started.

  pg:
    image: proget.inedo.com/productimages/inedo/proget:26.0.9
    container_name: proget
    restart: unless-stopped
    ports:
      - "8624:80"
    volumes:
      - ./proget-packages:/var/proget/packages
    networks:
      - proget
    environment:
      - PROGET_POSTGRES_CONNECTION_STRING: Server=postgres;Port=5432;Database=proget;Password=Pass@123;Username=root;
      - PROGET_ENCRYPTION_KEY: ${ENC_KEY}

I removed the volumes for database and backups since you are planning to use an external database. I'm also using ./proget-packages/ for the volume mount. You had duplicates specified in your volume mounts, so update that path if you want to store it elsewhere. Then you need to specify the connection string for your PostgreSQL database in the PROGET_POSTGRES_CONNECTION_STRING environment variable. Lastly, I added the encryption key environment variable. You can generate this initially using head -c16 /dev/urandom | xxd -p -c32, then you will want to make sure you do not change it going forward. That should be enough to get you up and running.

For other volumes you might want to use see our other volumes section in our Docker guide. For other supported environment variables, see our supported environment variables section in our Docker guide.

Thanks,
Rich

stevedennis

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

stevedennis

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

gdivis

Hi @joris.guex

You're right! It looks like ProGet is reporting the second value of the range as if it was an exclusive bound rather than inclusive. Somehow it has been like this for years.

Anyway, it looks to be a trivial fix, so we should be able to get this in this Friday's release of 2026.9. I've created PG-3350 as the tracking issue for it.

Thanks for reporting the problem!
-Greg

atripp

Hi @amy.j ,

If the package is already cached in ProGet, then the publish date is already set. So, i would make sure to delete the package and try it again.

Otherwise, can you share more specifics? That way we can create a reproduction case.

Thanks,
Alana

stevedennis

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

stevedennis

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

stevedennis

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

stevedennis

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

administrators

Posts

Member List