[raesene9]

For all the people who are rightly concerned about these attacks here's a a couple of questions

- Would you pay money for access to a package repository that had good security practices? How much would you pay? Would you accept delays in library updates to allow for security checks? If so, how long a delay would be acceptable.

- Have you ever looked into the security practices of open source applications or libraries that you wanted to use and had the information you did or did not find affect your decision to use that software?

- How often do you use the inventory of all the libararies you have, to periodically check on the provenance of those libaries and that they are maintaining good security practices?

Ultimately these problems (like most) are one of incentives. It's very easy to build software very quickly using the huge number of open source components that are freely available.

Whilst speed of development and price are the primary considerations, it's not going to be surprising that security takes a lower rung on the ladder.

[sundayedition]

I used to work for the government and we had a private gem server that introduced much for what you're asking about; delays in releases as a trade-off for security practices. Ultimately, I don't think there was any tooling available to automate the vulnerability scanning enough that a private server gives you much of a jump start on any kind of CVE that bundle audit wouldn't already catch. The workaround of needing to hit GitHub directly to get a current version and bypass the private server is also available.

Additionally, GitHub provides a bundler-audit like service for free. And, identifying those that are t CVEs yet seems like something scriptable but also obfuscatable (on the attacker end).

I don't think any team I've been on (federal or private) would pay extra for this kind of service given the frequency with which we do updates and the amount of effort that needs a careful developer spends when doing these updates. The most recent breaches have been noted well I'm advance of any updates we would have done.

I'd be glad to be wrong about it because I think a few more tools in this space would only help the community.

It would be nice if a service could summarize the differences in actual gem releases, to make things like the changelog and the diff easily digestable for all the available updates though (versus a scan/lint). That would let a developers more easily identify these kinds of breaches than cloning and diffing.

[whorleater]

Half of these is the Red Hat business model.