11
3 Comments

I realized my security scanner was showing users too much information

Building VibeSafe has taught me something I didn't expect:

Finding security issues is only half the problem. Helping people understand what to do next is just as important.

Our first approach was simple — scan the code, find issues, and show the results.

But as the scanner became more powerful, the results became more complicated.

A developer could see:

🔴 Critical issues
🟠 High-risk issues
🟡 Medium issues
📁 File locations
💻 Code snippets
🛠️ Recommended fixes

Technically, that's useful.

But for someone who isn't a security expert, it can quickly become overwhelming.

So we're changing the experience.

Instead of simply saying:

"You have 8 security issues."

We want VibeSafe to answer three questions:

1. What is wrong?
2. Why does it matter?
3. How do I fix it?

And then make it easy to fix → rescan → verify.

That's becoming an important part of what VibeSafe is about.

AI makes it incredibly easy to build an app quickly.

But getting from "it works" to "it's safe to ship" is a different problem.

That's the problem I'm trying to solve.

I'd love feedback from other founders:

When a security tool gives you a long list of issues, what information do you actually want to see first?

posted toAvatar for product Vibe Safe
Vibe Safe
  1. 1
    I would show the release decision first, not the issue list: ‘safe to ship,’ ‘ship with accepted exceptions,’ or ‘block release,’ with the exact evidence behind that decision. Severity alone is hard to act on because eight findings can mean one real release blocker or eight low-context warnings. Then keep the fix → rescan → verify loop, but preserve which code version was scanned so the result remains reproducible after the next AI-generated change.
    1. 1

      This is a really useful perspective. I especially like the idea of showing the release decision first rather than making users interpret a list of severity levels.

      “Safe to ship / Ship with exceptions / Block release” could make the result much more actionable.

      And the reproducibility point is important too. With AI-generated changes happening so frequently, knowing exactly which version was scanned and being able to compare the result after a rescan would make the fix → rescan → verify loop much more meaningful.

      I’m going to add this to our product thinking. Thanks for the detailed feedback! 🙌

      1. 1
        Glad it's useful. I'd tighten my earlier wording to 'passes these release checks,' with the commit and scan coverage visible. A clean scan doesn't establish that the whole app is safe. That narrower label still helps someone decide what to do next without overstating what the scanner verified.