Comment by robomc

Comment by robomc 6 days ago

From the CEO's response:

> On January 24, 2025, security researchers from Kudelski Security disclosed a vulnerability to us through our Vulnerability Disclosure Program (VDP). The researchers identified that Rubocop, one of our tools, was running outside our secure sandbox environment—a configuration that deviated from our standard security protocols.

Honestly, that last part sounds like a lie. Why would one task run in a drastically different architectural situation, and it happen to be the one exploited?

KingOfCoders 6 days ago

Yes, all the tools are fine and secure and sandoxed, just this one tool that was kind of randomly chosen by the security researcher because it is a tool that can execute Ruby code inside the environment - one could argue an especially dangerous tool to run - was not safe.

Reply View 0 replies

jdlshore 6 days ago

Not sure why it seems like a lie. Oversights like this happen all the time.

Reply View 2 replies

cube00 5 days ago

It seems like a lie because they tried to hide this incident by deflecting to a PR fluff post first [1]
They only published a proper [2] disclosure post later once their hand was forced after the researcher's post hit the HN front page.
[1]: https://news.ycombinator.com/item?id=44954242
[2]: I use that term loosely as it seems to be AI written slop.

Reply View | 0 replies
wheelerwj 6 days ago

100%. Sounds like a very common oversight at many companies.

Reply View | 0 replies

[removed] 6 days ago

[deleted]

Reply View 0 replies

sophacles 6 days ago

> Why would one task run in a drastically different architectural situation

Someone made a mistake. These things happen.

> and it happen to be the one exploited?

Why would the vulnerable service be the service that is exploited? It seems to me that's a far more likely scenario than the non-vulnerable service being exploited... no?

Reply View 2 replies

bigiain 6 days ago

> > Why would one task run in a drastically different architectural situation
> Someone made a mistake. These things happen.
Some company didn't have appropriate processes in place.
For ISO27001 certification you at least need to pay lip service to having documents and policies about how you deploy secure platforms. (As annoying as ISO certification is, it does at least try to ensure you have thought about andedocumented stuff like this.)

Reply View | 1 reply
- sophacles 5 days ago
  
  Ah yes processes.... things done by humans. When stuff is done by humans, mistakes happen - no matter what the process is. Go do a search for the phrase "wondering how this could happen" and find millions of news articles about mistakes happening despite processes being in place!
  
  Reply View | 0 replies

Romario77 6 days ago

because researchers from Kudelski Security most likely tried different static analysis tools and they didn't work the way Rubocop did.

They don't write the details of how they got to this particular tool - you could also see from the article they tried a different approach first.

Reply View 2 replies

robomc 6 days ago

> because researchers from Kudelski Security most likely tried different static analysis tools and they didn't work the way Rubocop did.
Yes but that's kind of the point - they say this issue that takes you directly from code execution to owning these high value credentials was only present on rubocop runnners but isn't it a bit coincidental that the package with (perhaps, since they chose it) the easiest route to code injection also happens to be the one where they "oops forgot" to improve the credentials management?
It just seems very convenient.

Reply View | 0 replies
KingOfCoders 6 days ago

I've read it differently, they chose Rubocop not because it worked, but because it allows to execute Ruby code.

Reply View | 0 replies