Comment by Vates
17 hours ago
When one OAuth token can compromise dev tools, CI pipeline, secrets and deployment simultaneously, something architectural has gone wrong. Vercel have had React2Shell (CVSS 10), the middleware bypass (CVSS 9.1), and now this, all within 12 months.
At what point do we start asking questions about the concentration of trust in the web ecosystem?
It's funny that at the engineering level we are continuously grilled in interviews about the single responsibility principle, meanwhile the industry's business model is to undermine the entirety of web standards and consolidate the web stack into a CLI.
Coming from a company that makes infrastructure out of a view layer / vDOM library - I think anyone relying on Vercel has only themselves to blame.
That and also the CEO posting a photo of him posing with a war criminal. Using let alone relying on Vercel baffles me.
Which one? There's so many these days I've lost track.
It feels like the political forces underpinning the software industry are coming to light but it seems like there are two opposing forces now instead of just one.
It's interesting that Next is becoming so popular when LLMs supposedly have a capability to work with all these other frameworks that don't create a dependency on something like Vercel.
You have no idea how indifferent security officers can be-even when you point out critical issues. The other day, we flagged that a customer’s database had users with excessive privileges. Their only question: “Can this be exploited from the outside?”
No, but most breaches today come from compromised internal accounts that are then used to break everything.
What's the problem to have local API connected in HTTP? We are within the enterprise network.
And that's how I passed for a annoying "PM". With half of the program management complaining that I was slowing down things until 6m later, the head of risk management told them to get lost.
> the head of risk management told them to get lost
That's why it's important to org-chart engineer for security, if a company is really serious.
The answer is Yes, this can be exploited from the outside by taking over dev machines and using their access.
If you answer No and complain that it’s not taken seriously, it’s at least in part because you didn’t show the risk clearly.
The problem with security is that often it's cheaper to deal with the bad outcome than to prevent it. Actually getting security right is very expensive because it requires virtually every engineer to have some security awareness, and engineers who can be trusted with that tend to be difficult to find. Meanwhile if you have a security incident you say "sorry", maybe you pay a small fine, and a month later everyone had already moved on.
This misalignment is especially bad at startups. In my experience security is only prioritized when driven by the customer and is largely a performative box checking exercise.
JavaScript living only as a built artifact in an s3 bucket makes for a much simpler life.
until someone starts a botnet making your S3 invoice to $10k. Pay per usage is always a liability.
It is horrendous that aws doesnt allow any usage limits.
Polite reminder as to why Domain Driven Design is super-important. It makes more sense to spend 80% on DDD initially and then only 20% on the code (80-20 rule) vs the other way round. Or you will end up in a clusterfuck like this.
Domain Driven Design is something that I have only come to know with full understanding at my current job and oh my it is useful. It's not a silver bullet, but for complex domains it's a must.
GitHub looking awful quiet in the corner on the room there
The whole hiring system needs to be eradicated. You get grilled by incompetents, who ask one question, never ask back when you provide something that is debatable, they give zero feedback and then you see what kind of errors these "elitist" engineers make. Burn it to the ground.
Best hiring systems I saw were when actual engineers hiring for their team were doing the bulk. You get a gauge of what you can expect and them too.
three critical vulns in 12 months is a pattern not a coincidence. the SRP point is sharp - we interview engineers on isolation principles then build platforms that are the opposite of that.
[dead]