There is a lightweight standard for bom called cyclonedx though (https://cyclonedx.org/).
Cyclonedx can be output as either xml or json, which can be consumed in an application such as dependency-track. The problem though, is that dependency-track consumes the bom file and does not keep it.

Of course, it's possible to Asset Directory could be used as a bom repository, though pushing files to a git repository might be better in that regard, since it's easier to download the whole repo and compare files.

Just curious if Inedo has any thoughts about sboms (software bill of materials) and how they can be stored outside of a service which tracks dependencies.

I'm starting to see a need for a service that makes it easy to find a sbom from somewhere, similar to how a package repository works.

Case:
You have created a new application or updated the application, and you've created a bom file.
The bom file isn't necessarily pushed automatically to a service (such as dependency-track), but put in a repository which then can be pulled when the application is finally pushed to QA or Production.

@Stephen-Schaff We're also considering locking down nuget.org, so the more info we have in ProGet, the better.

Is it possible to add a filter which hides packages that are less than x days old in the connector settings? This is specifically packages that are pulled through external package repositories.

The date could be published date noted in the package.

From a security point of view, it would be ideal that a package gets a few days or a week, to see if there are bugs or updates during that time period before actually pushing the package into the feed via the connector.

Why: For instance NPM
Recently the UA-parser-js was discovered to have malicious code and it took 4 days(?)
https://snyk.io/vuln/npm:ua-parser-js

After recent events in the NPM community regarding ua-parser-js, makes me concerned having unmonitored package sources in our enviroment. Doesn't seem like there are package repositories available for flutter quite yet, that mitigates that concern.

What does the roadmap look like now?

Seems like flutter is gaining more traction and is the preferred way to create mobile applications quickly.

Is it possible for Inedo to consider having the option of a test upgrade license for ProGet?
I've read the agreement, but I'm wondering if there's a possibility to figure out something that would benefit both Inedo and the customers.

In my case after being stuck with a maven issue, where the error was an edge case and took a lot of time for Inedo to figure out, I had to go back and forth on ProGet versions in my production environment to recreate the case. I also timed the up and downgrades within lunchbrakes and activity in the company. This is probably not ideal, though Inedo Hub made the up and downgrade easy by clicking a few buttons on the server.

Some would argue that the ProGet Free edition might be a good option to use during a test period. But since it does not come with Active Directory integration, that creates an complication where the AD integration might not work after an upgrade (which has happened a few times in the past).

I'm not looking for example a complete ProGet, but something that lets the customer

• have a few feeds and connectors for a given type to check if an upgrade affects the feeds in any way
  • meaning - severly limited
• check if the application comes up at all
• debug ProGet without halting Production

In actuality the ProGet version I'm talking about, would be even more limited than ProGet Free since it cannot be used for anything else but test the upgrade.

With the amount of feed types Inedo offers, ProGet is bound to have one or two bugs that is missed in QA.

That's great :)
"Feed Usage Instructions" or "Feed Usage Guide"?
"Getting started using the feed"?
I'm wondering though; should the help button be separate from the feed options? It's not always easy for end users to spot that the button is a drop down. Actually I gotten a lot of questions about features that were hidden in the dropdown.

I don't usually experience that people ask for help options in software, instead they ask the person who knows the software best. Especially if there's nothing leading them in any direction. People don't look for a help option, they just assume it should be there (from what I've observed).

Having said that, a "help me" option makes it easier to direct the end users attention. Right now, I'm writing "help me" guides for all sorts of feeds, but the guides are all in confluence, so the end user will need to know about the link to the information. I want the users to be as independent as possible, meaning that the tool guides the users as much as possible without having to ask a colleague. Especially, if everything is setup correctly on the software side (ie ProGet).

Customizing the help page could be useful, if there are extra steps that needs be considered. F.ex. we have an internal proxy in our network, that may make our package repository unresponsive. So being able to add info about the setup for the proxy may be helpful.

Also noted that the "description" field for a given field, isn't used for anything (ProGet 5.3.33)? It does not show for any sort of user, which is sort of sad, since I want to inform the user the purpose of the feed. Some users have started consuming an internal library feed (no connectors, just packages), instead of the feed consisting of internal and external connectors.

At the very least, a bulk operation would help.

@stevedennis said in Feature Request - ProGet - Update vulnerability list if a package is not available in any feed:

I did just want to confirm this bit...

Manually by version, where the version is either removed entirely or unlisted .. very ineffective.

Are you referring to deleting/removing vulnerabilities, or the packages themselves? Are you using "retention rules" to clean-up the old chocolatey packages?
Basically the feature idea I'm thinking essentially a checkbox on the Retention Rules, where it deletes the vulnerabilities when the package is deleted, if no other packages are using it. That seems like the easiest and most explicit way to manage going forward

I'm referring to the deleting/removing vulnerabilities.
Yes, we are using retention rules to remove old chocolatey packages. We currently allow 10 versions of each package, anything older gets deleted.

A checkbox sounds like a good idea.