igorandri

You are right, I'm not happy about apps still leaking the data. For now, my message is to go and click the Fix button. I know it won't reach everyone, but I think it's important people hear it and do it. In the meantime, we are stepping up our game and taking this feedback super seriously. There will be a few releases that will definitely improve the security baseline of Lovable apps.

no, it's all in Free tier. You can even enable auto-fix, so that you don't even need to look at scanner findings anymore.

I see it as an opportunity to educate the builder community on importance of using the provided security tooling. What I'm asking users is to use tools while building. Our tools explain security in business terms and give people tools to bridge the technical gap. Is it always enough? No, there's no perfect tool or approach, there will always be space to improve. But as you can see, if apps continue to expose the data, the actual blame falls on us - and there's no intention to say. And we are taking it as an input to improve our tools, UX, auto-fix tooling, user messaging and have more ways for users to build secure apps.

in many cases, it's hard to understand and know is something is by design or by mistake. We are looking into having a path to take down apps that grossly violate privacy and data protection. It's a bit tricky legally so we need to find a good balance. Our thinking is so far: notification with ask to fix, grace period, if no action and no improvement - soft block until issues fixed.

We are training our agent and models to get really good at RLS. A lot of projects mentioned in the research are created with older models, unfortunately. Which means, a worse starting point compared to where the models are today. Yet, they have access to latest scanners which are also optimized and trained on good and bad RLS outcomes. Our ask today is to click Free Fix and do not ignore warnings (incl email and in-app notifications to builders). Enabling auto-fix is another great way to decrease risk of your app. Also, soon we will have gates against publishing of anything with Critical issues in it, available to all tiers.

working on it!

We are moving this feature to all paid tiers soon. I agree that scanning on schedule needs to be available to everyone.

Auto-fix is tricky to get right without breaking the apps (imagine us having 99% of auto-fix success, at the scale of 10M apps, it would mean breaking 100 000 apps). We need to get really good at it - otherwise people will be burned by it and will never trust it again. But it's getting really good, I hope we will be able to release soon.

We are investing millions per year into free security tooling. There will be even more changes democratizing security coming out soon, with more features moving to Free/Pro tiers from higher tiers - watch our release announcements. Free and accessible is our core strategy for security features. It's our way to act on the feedback, accept the blame, and find new ways to engage the users and help them fix their apps. I think it's important to be here and engage in the discussion - to learn, share my point of view, and get back to work on securing every app on Lovable with more insights of struggles and issues of builders and the community.

We are investing millions per year into free security tooling. There will be even more changes democratizing security coming out soon, with more features moving to Free/Pro tiers from higher tiers - watch our release announcements. Free and accessible is our core strategy for security features. It's our way to act on the feedback, accept the blame, and find new ways to engage the users and help them fix their apps. I think it's important to be here and engage in the discussion - to learn, share my point of view, and get back to work on securing every app on Lovable with more insights of struggles and issues of builders and the community.

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.

Indeed, we are looking into having a path to take down apps that grossly violate privacy and data protection. It's a bit tricky legally so we need to find a good balance. Our thinking is so far: notification with ask to fix, grace period, if no action and no improvement - soft block until issues fixed.

That's our thinking with auto-fix - no matter how good are findings or warnings, or modals blocking publish, some apps will still do it. We work hard on promoting auto-fix, and free fix-all functionality so that users do not hesitate to use it.

Igor here, Head of Security at Lovable. Thanks to the Crissy Field team for their work. The root cause in these apps was insufficent Row-Level Security, which is exactly what our scanning is built to catch. We scan every app automatically before publish and offer a deeper SAST scan, both free for all users. When we flag findings, users can select “Fix” and Lovable will help resolve them. They can also enable auto-fix, which resolves security findings in the background, and block publishing entirely when there are critical findings.

But a warning only helps if it’s acted on, and the people affected here are end users who did not action provided findings.

Our work is to help users ship secure apps. We keep investing in making security tools better and easier to use, taking on as much of the security load as we can, shipping more secure code by design, and fixing more issues automatically.

I personally believe that making security accessible is what leads to making software accessible. We’re committed to both.

You can read more about our approach: https://lovable.dev/blog/find-it-fix-it-ship-it