Verdicts Explained
Understanding BLOCKED, REVIEW, and CLEAR
We found critical security issues that should be fixed before deploying to production.
Examples:
- • Hardcoded API keys or secrets in source code
- • Known critical vulnerabilities in dependencies
- • SQL injection patterns
Action: Fix these issues before deploying.
We found issues that might be intentional or context-dependent. A human should review before deploying.
Examples:
- • Public API keys (might be intentional for client-side use)
- • Medium-severity dependency vulnerabilities
- • Patterns that look suspicious but might be safe in context
Action: Review the findings and decide if they're acceptable for your use case.
We didn't find any of the issues we scan for. Based on our checks, the code appears safe to deploy.
Important: CLEAR means we didn't find issues in what we scan. It does not mean your code is 100% secure. We cover approximately 70% of common security issues.
Why three verdicts?
Security isn't binary. Some issues are clearly dangerous (BLOCKED). Some need human judgment (REVIEW). And when we don't find anything, we tell you (CLEAR) — but we're honest that we don't catch everything.