Security scan
How Lyna scans your project, what each check means, and why a check that did not run is never shown as clean.
The Security scanner checks your project for exposed secrets, injection, weak access control and other common vulnerabilities. It runs inside your project's sandbox, lists what it found, and can hand the findings to the AI to fix. Serious findings stop a publish until you deal with them.
What you can do
- Run a Quick scan, or a Deep scan for a fuller review.
- See 20 checks, each marked passed, failed or not run.
- Read each finding with its severity, file, line and a recommendation.
- Send one finding, or all of them, to the AI to fix.
- Ignore a finding that is not a risk in your project, with a reason.
- Write project notes that help the deep scan.
- See every package your project uses and the known advisories against it.
Run a scan
Open Security
Open DevTools from the bottom bar of the editor and choose the Security tab.
Pick a depth
- Quick scan looks at the code, the secrets, the packages, the configuration and, if your project has a database, its row level security.
- Deep scan does all that, then asks the AI to review your routes and data access. It takes longer. Some checks can only be settled by a deep scan.
Read the result
The header shows the score (Secure, Needs review or At risk), when the scan ran, and whether it is Up to date or Out of date. The coverage line shows how many checks passed, failed or did not run.
You can also ask the AI in the chat to check your project for security issues. It runs the same scan.
The 20 checks
| Checks | What they look for |
|---|---|
| Cross-site scripting, SQL injection, Command injection, Code injection, Input validation | Untrusted input that reaches HTML, a query, a shell or eval without checks. |
| Secrets | API keys, tokens and passwords written in the code or in files the app serves. |
| Access control, Authentication | Routes and data that anyone can reach without signing in or without the right role. |
| Row level security | Database tables that are open to every visitor. |
| Information disclosure | Error details, source maps or data that should stay private. |
| Server-side request forgery, Path traversal, Open redirect | Requests, file paths and redirects that a visitor can steer. |
| CORS, Security headers | Server and browser settings that make attacks easier. |
| Cryptography | Weak or misused hashing and encryption. |
| Dependencies | Packages with known vulnerabilities. |
| Cross-site request forgery, File upload, Rate limiting | Forms, uploads and endpoints that can be abused. |
Not run is never clean
A check only passes when the scan could really check it. When it could not, the check shows not run with the reason, for example:
- connect a database to check this, for row level security when the project has no database.
- run a deep scan to verify this, for checks such as access control and authentication after a quick scan.
- the code scanner did not run, when part of the scan failed.
If some parts of the scan did not run, the panel says so: the result is not a clean bill of health. Run the scan again, or run a deep scan.
Findings
Findings are grouped by severity: Critical, High, Medium, Low and Info. Each one shows its category (Secrets, Frontend, Edge Function, Database, Authentication or General), the code that triggered it and a Recommendation.
- Fix asks the AI to fix that finding.
- Reference in chat adds it to your message so you can ask about it.
- Fix all or Send all to AI hands every finding to the AI at once.
When your code changes after a scan, the result is Out of date and the fix actions are turned off, so the AI never works from old line numbers. Run the scan again first.
Ignore a finding
If a finding is not a risk in your project, open the finding and choose Ignore this finding in its actions. Explain Why is this not a risk?, then choose Ignore finding.
An ignored finding stays in the list, in its own group, with your reason. It no longer counts in the score and does not block publishing. Choose Restore to count it again.
Ignored findings are saved in your project, in .lyna_ai/security/ignored.json, so they are part of your Git history and your team can see them.
Project notes
Some facts cannot be read from the code: who signs in, which data is private, which risks your team accepts. Write them in Project notes. The deep scan reads them as context. They are saved in .lyna_ai/security/memory.md.
Notes add context, they never hide findings
Project notes can help the deep scan find more. They cannot turn a finding from the quick scan into a pass.
Dependencies
The Dependencies list shows every package your project uses, its version, its advisories and the version that fixes each one. Search it, turn on Vulnerable only, or choose Download list. Packages only used in development are marked Dev.
Publishing and security
When you publish, Lyna checks the latest scan.
| Finding | Effect on publish |
|---|---|
| Critical or high, in your code or database | Blocks publishing |
| Critical or high, in a package | Advisory |
| Medium, low or info | Advisory |
| Ignored | Advisory |
A blocked publish shows Resolve security issues before publishing. Fix the findings, ignore the ones that are not a risk, or choose Publish anyway.
Publish anyway keeps the risk live
Publish anyway puts your site online with the vulnerabilities still in it. The deployment is marked Published with override.