I think the problem is rooted in consideration of the architecture itself. The post mentioned one of the common patterns where people leave permissions too wide, suggestion is to let another LLM take a run at it to make some changes.
My personal reading is that people find it easier to put another bandaid on the top of existing one on the name of security. A sprawl of monitoring and automation tool give a sense of security while adding to the cost. It might be worthwhile to let it be visible to user, who can see the data, who can modify the data when it comes to self vs other and authenticated vs unauthenticated. And of course people are going to try to save money, these scanning features are going to show up as additional bill pretty soon.
We noticed that many projects come from earlier builds. Roughly speaking, building an insecure app is much harder today than 6-12 months ago. Agent will protest and try to suggest alternatives if the builder asks to have no security, for example. But some folks find it easier to build with no RLS and then add them later. But for a complex app, it's a hard task, things break etc. In our blogs, videos and office hours, I always recommend building with all security features on from the beginning, never trying to slap it on top after the fact
We are committed to keeping scanners free. A new UX for security rolls out soon (this month), will get a better understanding of what is wrong, who can see what and why important to fix.
Yes unfortunately security suffers a similar fate everywhere. For MVPs its a cost which is not tied to any revenue so it gets pushed on. Over the period of time you have built ecosystem of applications and services in a incremental way to provide features that customer asked for. Ironically no customer asked for the security explicitly, it was that non-functional requirement that exists in bare bones in some form. Its most likely not the part of architecture for sure in almost all the places, if an architecture exists.
The biggest revenue you will get is from enterprise customers and thats your biggest risk too if security goes south. You already have advantage of being close to customer stories and usage behavior. Some one within the company needs to build the platform again from grounds up with all these security requirements baked into the architecture, sort of parallel project one would say.
> We are committed to keeping scanners free.
This sounds like a good sentiment in theory, however this is a double edged sword. Scanning costs money to you as company and that cost is going to make it to the customer one way or another
My personal reading is that people find it easier to put another bandaid on the top of existing one on the name of security. A sprawl of monitoring and automation tool give a sense of security while adding to the cost. It might be worthwhile to let it be visible to user, who can see the data, who can modify the data when it comes to self vs other and authenticated vs unauthenticated. And of course people are going to try to save money, these scanning features are going to show up as additional bill pretty soon.
We are committed to keeping scanners free. A new UX for security rolls out soon (this month), will get a better understanding of what is wrong, who can see what and why important to fix.
The biggest revenue you will get is from enterprise customers and thats your biggest risk too if security goes south. You already have advantage of being close to customer stories and usage behavior. Some one within the company needs to build the platform again from grounds up with all these security requirements baked into the architecture, sort of parallel project one would say.
> We are committed to keeping scanners free.
This sounds like a good sentiment in theory, however this is a double edged sword. Scanning costs money to you as company and that cost is going to make it to the customer one way or another