Is your implication that hyperscalers (big companies) will always do better at this than smaller companies?
Just becuase a company has more money doesn’t mean they direct that money well, and even money directed well at the wrong people will result in failures.
Sometimes compliance do help improve security. Hyperscalers have resources for that. They have resources and they do security well. Hyperscalers are treated as critical infrastructure.
One person's machine being compromised does not bring the whole org down.
No one ever got fired for putting creds in AWS Secrets Manager. I'd take the hyperscaler every time because even if something happens, it is a very defensible decision.
Unfortunately the cost of HSM is the cost of two of them, overprovisioned for your projected needs over years, and staff who know how to use them safely both in terms of security design and not losing access to everything in case of an issue.
I am sorry, this is "Resolved"? How can they even consider marking this resolved in any situation. Yeah we exposed your env vars but we told you about it over email so it's all good... We dont know how or to what extend though.
> As an eternal reminder of the need to do better?
Eternity is a very, very long time. Longer even than 80 years (arguably the total age of the whole "programmable electronic computing and data storage machines" industry), you know?
So I don't think that having an open issue in a bug tracker forever is even possible; not that it would even serve as a remainder — I assure you, most long-existing firms have "ignore open issues older than X years" filter enabled by default in their Jiras or whatever people use nowadays, those are only ever looked at once year by the upper management when they're out of ideas.
As far as my personal life is concerned, I honestly don't think I'm going to 'build and deploy' anything to any SaaS that isn't directly in my control for a while.
damn, i've been thinking about the same recently. saas is dead, at least developer oriented saas for sure. the only things i rely on are my own self hosted git (not public to the web), and that's it. all other "developer oriented saas" has been replaced with a home made version with claude. probably not safe from hacking, but id rather take the risk of someone targeting ME specifically, than let all the "saas platforms" store all my data and get hacked every monday and friday
The biggest case for building bespoke software is that you drop your attack surface area and it’s not as lucrative to hack one person. Don’t even expose it to the internet if you don’t need to and just run Tailscale.
I don't see bespoke software as a viable alternative because probing for vulnerabilities is both getting cheaper by the day, and also massively parallelizable.
Someone will inevitably spin up a large swath of agents running an abliterated pareto curve model and point them at the internet.
Not to mention your bespoke tool is likely way less hardened than the existing player in the space.
I was also referencing that using commercial software usually brings features you probably don’t use. Those features probably require new NPM packages so by building a bespoke software, you only build features you need.
Tailscale got hacked recently as well, didnt they (?). I think they did, the whole system is poisoned, because I believe one of the vectors had to do with eMudhra certs, which again, is not an issue specific to them, or something they had any say on it... there is literally no escape these days it would seem.
they had a priviledge escalation vulnerability that requires the attacker to already be a part of the tailnet, and more specifically allows a user-to-root escalation devices the attacker can tailscale ssh to.
> Not trying to play down the vuln (its important), but its not a free-for-all RCE that some ppl are acting like it is. [1]
eMudhra/TLS certificates have nothing to do with this (?).
I don't disagree with you, but I think generally when the mistake involves compromised user data, the answer is a bit more emotionally driven. People get rightfully mad when things like that happens, and services usually keep the incident in a "Mitigated" status while they "work with their customers to ensure blah blah blah" or whatever. Everywhere I've personally worked the Mitigated->Resolved involves publishing a postmortem, repair items, and general assurances or safe guards based on learnings from the incident that the issue won't happen again. However, the industry as a whole doesn't have a standard for what the line between Mitigation and Resolution is.
So the active incident is now fixed and they've already reached out to impacted customers but they can't mark it as resolved yet because they are still yet to publish a more detailed blog post?
Okay so let's just say you are one of those affected users
The founder of the company has already emailed you with details and their support team is around for you to ask any follow-up questions. Also the bug/exploit has been fully fixed
At this point are you saying you would actually be upset and leave because the incident on their status page has been marked as resolved?
What makes you think it's fixed? They just state that they "blocked the exploit", and that could mean anything:
- did they just take the affected API offline?
- or did they just disable the account of the attacker?
- or is the exploit actually being fixed?
Environment variables are sensible data, and marking a security incident as resolved with that little detail is quite a take. Even changelog entries for harmless bug fixes are more detailed.
I assume it's fixed based on it being marked resolved and from what was communicated. Yeah I agree it's a major issue but if it's fixed what they have done so far seems totally fine
To use a fearful, apt analogy: resolving the operational issue isn't just plugging the hole in the dam, its also fixing the damage by pumping the water out and then addressing the damages.
In your analogy they can't pump the water out. Now it's up to their users to rotate their keys. How do you expect them to do that sort of thing on behalf of their users?
That doesn't even make sense. People use environment variables to store things like API keys for third-party services. How do you expect them to magically rotate or decommission those keys?
They are no longer exposing anything, so they no longer have an incident.
Their customers now have an incident that will be resolved once their secrets are rotated. Maybe they also need to do previous intrusion forensics… In any case, not triggers problem anymore.
This should not be marked as "resolved". "Mitigated" until some percentage of customers ack the email notification at least (track clicks, get teams on Zoom call, etc.).
Holy smokes, is security just not a priority at all anymore? Like in what world do we live in, that this is acceptable. And at the volume this has been happening, bad guys are having a FIELD DAY.
In my experience, small teams put security off because someone on the dev team has some security experience, or thinks they do. But it is never the priority, there is always something more urgent to ship, and nobody has real skin in the game because it is not their job. Then shit happens. They rush to hire a security team, and that team spends the next few years fighting the culture.
Hand-made code is riddled with dirty hacks and exploits that LLMs have no problem finding. I would not trust any software that is not using frontier models to fix the messy human code.
Oh that is right, the frontier models yield amazing architecture and secure code in the form of aislop.
There is a difference between using AI to find bugs in written software than using AI to write bug free software, completely different set of skills and outcomes. Most of the high profile stuff you see is AI being driven by people who would have solved the same problem just in slower time going through the code. AI is as good as the operator.
Given the recent Claude Code remote access tool, it would be wise to not install any new software, or use any package manager for a few weeks as they could have already been silently backdoored during the aftermath of that incident.
The very fact that Nextjs vibe projects need an external (and paid!) background jobs / async service show how much of an anti pattern that this framework and similar are. Just use a sensible stack from day one that can handle concurrency out of the box like Elixir or something with established open source background jobs library. Then you can worry less about this kind of paid 3rd party nonsense. Ditto on auth. I just can't fathom outsourcing these types or core functionalities, the operational, security and cost risks make very little sense when there's libraries that do this out of the box.
Trigger and friends exist precisely because Node is not a serious backend runtime so you have to reach for bolt-ons for every little thing. No matter if trigger is open source or managed, it's an anti-pattern. Erlang/Elixir, C#, Go etc all handle this sort of async natively, literally out of the box. Mature frameworks like Rails, Django have pretty easy to use officially libraries as well. This has been a solved problem for literally decades.
The reason people are using these paid queue services is because Node sucks. Isn't it better to use an open source library or adult backend stack which solved this problem 30 years ago?
Trigger is literally open source. That has nothing to do with how mature the node ecosystem is. If you want in-process queue systems you have a lots of other mature options. Trigger is a dedicated queue system, it runs in its own process and can be used from any language through its API. You seem to talk confidently about a topic I don’t think you understand.
Go has lots of mature in-process queue systems, yet River exists, because in lots of situation it makes perfect sense to have your job queue in its own process
Unfortunately for infra startups, I think we're going to see a convergence back to hyperscalers as a result of incidents like this and railway.
There's no amount of "nicer to use" that can replace security, at least certainly when selling to enterprises
Also, a trick i've started doing is encrypting my env vars, then hard-code the decryption key in the code
Just becuase a company has more money doesn’t mean they direct that money well, and even money directed well at the wrong people will result in failures.
One person's machine being compromised does not bring the whole org down.
Eternity is a very, very long time. Longer even than 80 years (arguably the total age of the whole "programmable electronic computing and data storage machines" industry), you know?
So I don't think that having an open issue in a bug tracker forever is even possible; not that it would even serve as a remainder — I assure you, most long-existing firms have "ignore open issues older than X years" filter enabled by default in their Jiras or whatever people use nowadays, those are only ever looked at once year by the upper management when they're out of ideas.
Someone will inevitably spin up a large swath of agents running an abliterated pareto curve model and point them at the internet.
Not to mention your bespoke tool is likely way less hardened than the existing player in the space.
they had a priviledge escalation vulnerability that requires the attacker to already be a part of the tailnet, and more specifically allows a user-to-root escalation devices the attacker can tailscale ssh to.
> Not trying to play down the vuln (its important), but its not a free-for-all RCE that some ppl are acting like it is. [1]
eMudhra/TLS certificates have nothing to do with this (?).
[1] https://news.ycombinator.com/item?id=50266179
How they handle the communication on the incident is crucially as important as remediating the original cause.
Just the fact that they are doing this means I will probably never use this service or recommend this service to anyone else.
The founder of the company has already emailed you with details and their support team is around for you to ask any follow-up questions. Also the bug/exploit has been fully fixed
At this point are you saying you would actually be upset and leave because the incident on their status page has been marked as resolved?
- did they just take the affected API offline?
- or did they just disable the account of the attacker?
- or is the exploit actually being fixed?
Environment variables are sensible data, and marking a security incident as resolved with that little detail is quite a take. Even changelog entries for harmless bug fixes are more detailed.
Their customers now have an incident that will be resolved once their secrets are rotated. Maybe they also need to do previous intrusion forensics… In any case, not triggers problem anymore.
I was able to patch before it was exploited but that definitely made me question the service.
But could also be any of the recent supply chain attacks hitting a dev too i guess
There is a difference between using AI to find bugs in written software than using AI to write bug free software, completely different set of skills and outcomes. Most of the high profile stuff you see is AI being driven by people who would have solved the same problem just in slower time going through the code. AI is as good as the operator.
Im now thinking about just running tart VM's on my mac to do my regular stuff from.
Go has lots of mature in-process queue systems, yet River exists, because in lots of situation it makes perfect sense to have your job queue in its own process