Ruby Fights Supply-Chain Attacks With Filter Offering 'Cooldown' Before Installing New Packages (rubygems.org) 19
Most supply-chain attacks using Ruby's package hosting site "exploit a narrow window," according to a new blog post form Ruby core maintainer Hiroshi Shibata.
So its packaging-managing Bundler tool now offers a filter that blocks new version until it's been public "for at least N days. Releases too new to have been scrutinized are passed over in favor of ones that have aged past the window." The feature was designed in the open, drawing on how other ecosystems approach the same problem. It is opt-in, and complements rather than replaces existing defenses like mandatory 2FA and trusted publishing... Cooldown is unset by default, so a project without it keeps resolving to the newest versions.... Passing 0 disables cooldown for the run...
Cooldown is most useful as one part of the wider security investment happening on rubygems.org. The registry now validates gem contents at push time and checks logins against Have I Been Pwned so that compromised passwords cannot be reused, work described in Protecting rubygems.org from the outside in. A dedicated team is running AI-assisted vulnerability scanning against the most critical gems, backed by Alpha Omega and Anthropic, and the direction of all of this is tracked on a public roadmap. Trusted publishing and mandatory 2FA already raise the bar for who can push a release in the first place.
So its packaging-managing Bundler tool now offers a filter that blocks new version until it's been public "for at least N days. Releases too new to have been scrutinized are passed over in favor of ones that have aged past the window." The feature was designed in the open, drawing on how other ecosystems approach the same problem. It is opt-in, and complements rather than replaces existing defenses like mandatory 2FA and trusted publishing... Cooldown is unset by default, so a project without it keeps resolving to the newest versions.... Passing 0 disables cooldown for the run...
Cooldown is most useful as one part of the wider security investment happening on rubygems.org. The registry now validates gem contents at push time and checks logins against Have I Been Pwned so that compromised passwords cannot be reused, work described in Protecting rubygems.org from the outside in. A dedicated team is running AI-assisted vulnerability scanning against the most critical gems, backed by Alpha Omega and Anthropic, and the direction of all of this is tracked on a public roadmap. Trusted publishing and mandatory 2FA already raise the bar for who can push a release in the first place.
And how will that help? (Score:2)
It just adds some latency. This will not fix the missing reviews or reputation checks.
Re:And how will that help? (Score:4, Interesting)
Well, it lets some people have long cooldowns make the rest of their ecosystem suckers.
Of course, this *also* means the people with high cooldowns get to be vulnerable to security problems longer because they will be applying cooldown to security fixes...
But yes, some sort of actual curation would be the best mitigation, particularly to allow trustworthy critical security updates through quickly instead of those getting caught in the cooldown.
Re: (Score:3)
A lot of supply chain attacks are compromised user accounts. So its not uncommon for that user, or someone else involved in the project to recognize an unexpected release. Generally it also gives a chance for security companies to detect malicious code.
Ironically of course it also slows down adoption of security fixes so as a developer you'll need to monitor for important disclosures.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You are hallucinating.
Will encourage sleeper attacks (Score:3)
Re: (Score:2)
Indeed. With the xz attack we have seen that and if they had not been technologically incompetent, it would have worked. Such an attack is also not very expensive. An expert for a year full-time is maybe 200k, maybe less.
Re: (Score:2)
Indeed. With the xz attack we have seen that and if they had not been technologically incompetent, it would have worked.
They apparently rushed because additional protections were about to be put in place and they needed to get the exploit vector deployed before that happened. The lesson was the same as it always is, haste makes waste.
Such an attack is also not very expensive. An expert for a year full-time is maybe 200k, maybe less.
No one has officially identified the origin of the xz exploit attack, but in any case, the exploit was long term and slow (so as not to arouse suspicion), so not even full time effort (and while some countries would pay more than $200K for a full time employee capable of such work, some countri
Re: (Score:2)
True, but in most cases, the malicious package is created by an attacker, side-stepping the original developer. When they realise they've been side-stepped, they take steps to resolve the problem and delete the malicious package - without even looking in it to see what it does. It doesn't take an actual exploit using the malicious package to trigger some sort of mitigation. That's a very different attack pattern to someone taking years to hit a specific target.
The likes of the cesspool of nodejs/npm could p
Learn to pin your dependecies (Score:4, Informative)
Just pin your dependencies. To an EXACT version, with a hash. No loose versioning or version auto-updates in the pipeline. Detect outdated versions automatically but update manually, after a full review, and a full av scan of the built environment before the release. Know and control what goes into the production environment. In other words, you're a professional - act like it.
Re: (Score:2)
If you download your dependencies at compile-time, you are already screwed. The only protection is local copies of older versions.
Re: (Score:3)
Agreed, but in practice it requires all your dependencies to do the same. All it takes is one of them to have a missing version and you'll go pulling it in at 'latest'. You can freeze it at that point for your subsequent deploys, but it'll still have shafted you in dev while you were revving some version or other.
Strictly freezing versions of the entire dependency tree is probably the best method there is, but it sure adds to the management overhead. You've still got to vet every single dependency at the ve
Re: (Score:2)
IMHO, this is why the industry moved to vendor maintained software repositories with signed code and such - rpm/yum, deb/apt, etc..
The central place does the vetting, and you get the latest stable version. Something needs a hot fix? They push it out, and you install on your own security updates schedule. And it should be ensuring they maintain backward compatible API's / ABI's, pushing major version changes to new packages if needed (ex. keepass / keepass2).
Requiring everyone that (builds and) installs your
The state of Ruby supply chain security (Score:4, Informative)
Re: (Score:2)
Indeed. What they are doing does not work and cannot work. The only thing that saved them up to now is an absence of attackers. With AI, that is going to change as now the technologically incompetent can do it as well on high amateur level. Which the highest level LLM-type AI can perform at, but which is plenty for the low amateur level "security" the defenders are using here.
Looks like amateur hour in software is slowly coming to a close. Good.
Re: (Score:1)
Not a web dev in any way..... but Ruby has at least some use? The solution tells me usage is not extensive and if it works a comfortable little niche is reinforced.
Accountability. (Score:2)
The problem with this approach is, it only works as long as someone does the checking. In practice everyone turns on 'safe update channel' and nobody actually tests the bleeding edge, ten days elapse, and the malicious code flows into the 'safe channel'.
It is like sending for help in a first-aide situation, you need to point at someone specifically, make eye contact and say "YOU! go get help" if you just shout 'someone get help' and go back to recuse breathing or whatever you're occupied with everyone will