> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vibely.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Project security view

> Scan a project for vulnerabilities, review findings by severity, fix them from the chat, and control what can block a publish.

The **Security view** shows security findings for a single project. It runs Vibely's built-in scanners over your code, dependencies, and linked Supabase database, groups what they find by severity, and turns each finding into a fix you can send from the chat.

<Frame>
  <img src="https://cdn.vibely.sh/doc/v1/features-security-project-view.webp" alt="Scan, review, fix from chat" width="1200" height="675" />
</Frame>

To open it, select **Manage** in the editor header, then select **Security**. The publish dialog also shows your latest scan result and links to the Security view when it finds critical issues.

<Tip>
  The Security view covers one project. To monitor findings across every project in your workspace, use the [Security center](/features/workspace/security-center). For guidance on writing secure code in the first place, see [Security best practices](/features/security/best-practices).
</Tip>

## Why use the Security view

* **Catch issues before you publish.** Misconfigured database access, exposed secrets, and vulnerable packages are easier to fix before real users arrive.
* **Focus on what matters.** Findings are grouped by severity, so you can fix errors first and review the rest later.
* **Fix from the chat.** Each finding carries its own fix prompt, so you don't have to explain the problem to the agent yourself.
* **Know when results are stale.** The scan status tells you when your project has changed since the last scan.

## Understanding scan status

The status next to **Security scan** summarizes the whole project:

| Status | What it means |
| - | - |
| **Up-to-date** | Every scanner has run and its findings still reflect the current code. |
| **Outdated** | The project changed since a scanner last ran, so its findings may be stale. |
| **Scanning** | A scan is running now. |
| **Failed** | A scanner hit an error. Its area wasn't checked; the others still count. |
| **Never run** | No scan has completed on this project yet. |

Findings describe a snapshot of your code. When you edit the files a finding points at, it doesn't update on its own: the status changes to **Outdated** and you run a new scan.

The view also shows a **Security score** (**Excellent**, **Good**, **Fair**, or **At risk**) based on your open findings.

## Run Basic and Deep scans

Use the buttons at the top of the view. Both scans are free.

| Scan | What it checks | When it runs |
| - | - | - |
| **Basic scan** | A fast pass over your code: code security and sensitive data | Automatically in the background on every publish, or when you select it |
| **Deep scan** | Everything: code, dependencies, row-level security, database, and sensitive data | When you select it, or when you ask for a security scan in the chat |

The row-level security and database scanners need a linked [Supabase](/integrations/supabase) project. Without one, they're skipped with an info note and the other scanners still run.

Run a scan:

* before publishing
* after significant code or database changes
* after adding or updating packages
* periodically for apps in production

## Included security findings

| Scanner | What it looks for |
| - | - |
| **Row-level security** | Tables with RLS turned off, and policies so permissive they protect nothing |
| **Database security** | Supabase advisor findings, such as risky `SECURITY DEFINER` functions and exposed auth tables |
| **Code security review** | Hardcoded secrets, dynamic `eval`, dangerous HTML, and secrets leaking into client code. On mobile projects, also insecure `AsyncStorage` use, unvalidated deep links, and cleartext traffic |
| **Dependency audit** | Packages in `package.json` with known vulnerabilities |
| **Sensitive data (PII)** | Personal data written to logs, to storage, or to unencrypted fields |

Mobile projects get the mobile rules automatically.

## Review and fix findings

All findings appear under **Detected issues**, grouped by severity. Filter by severity at the top of the list.

| Severity | What to do |
| - | - |
| **Error** | Exploitable as written. Fix before you publish. |
| **Warning** | A real weakness that needs judgment, often a policy or a package where the right fix depends on your app. |
| **Info** | Worth knowing, such as a skipped scanner or a pattern that's fine here. |

Expand a finding to see which scanner produced it, the file and line, an explanation, and a **Suggested fix**. If the latest scan found nothing, the view says so, but a clean scan doesn't guarantee your app has no security risk.

You can address findings in several ways:

* **Fix one finding.** Select **Fix**. Vibely writes a prompt naming the finding, the file and line, and the suggested fix, and puts it in the chat. Review it, send it, and check the changes like any other edit.
* **Fix everything open.** Select **Try to fix all** to put one prompt covering every open finding in the chat.
* **Update vulnerable packages.** Select **Auto-fix deps** to upgrade vulnerable packages to their fixed versions. It only makes non-major upgrades, because a major version can change behavior. Majors are left for you to decide.
* **Ignore a finding.** If a finding doesn't apply, select **Ignore this finding** and give a reason. The reason is logged with your name, and you can **Unignore** it at any time.

Always review the changes and test your app after a fix.

## Review project dependencies

The **Project dependencies** card lists packages with known vulnerabilities from the latest deep scan. Select **Export JSON** to download the list for an audit or compliance review.

## Leaked password protection

When a Supabase project is linked, the view shows a **Leaked password protection** switch. Turn it on to block sign-ups and password changes that use passwords found in known data breaches (Have I Been Pwned).

## Improve scan accuracy with security memory

Select **Edit security memory** to add project-specific context. The scanners read it on every run. Use it to explain things that look wrong but are correct in your app, for example:

```text wrap theme={"system"}
The /admin route is behind Cloudflare Access; ignore unauthenticated-access warnings on it.
```

<Warning>
  Use security memory to give context about your app, not to dismiss real issues.
</Warning>

## Publishing and security

Every publish starts a Basic scan in the background. It doesn't block that publish: the deploy proceeds and the findings land in the Security view.

Workspace owners and admins can go further with settings in **Settings → Privacy & security**. They apply to every project in the workspace:

| Setting | Effect when on |
| - | - |
| **Require basic security scan before first publish** | A project's first publish is blocked until a scan has completed. Republishing a live project isn't affected. |
| **Block publishing with critical issues** | Publishing is blocked while any open **Error** finding exists. |
| **Block publishing with PII** | Publishing is blocked while any open error or warning **Sensitive data** finding exists. Business plan. |
| **Who can publish externally** | Limits who can publish. Business plan. |

A blocked publish tells you which setting blocked it. The same rules apply to web publishing and mobile store submissions. See [Privacy & security](/features/workspace/privacy-security).

### Before a mobile build

A web deploy can be rolled back in a minute. A native binary in store review can't. Once submitted, you wait out the review, then submit a new build and wait again. So on mobile, scan first:

<Steps>
  <Step title="Run a Deep scan before the build">
    From the Security view, or ask for a security scan in the chat.
  </Step>

  <Step title="Clear every Error finding">
    Judge warnings case by case. Fix errors.
  </Step>

  <Step title="Then start the build">
    See [Ship to stores](/features/mobile-apps/ship).
  </Step>
</Steps>

## Scheduled scans

On the **Business** plan, workspace admins can run deep scans on a schedule (weekly or monthly) for all projects or published projects only. Set this up in the [Security center](/features/workspace/security-center).

## Best practices

* **Keep findings current.** Rescan when the status says **Outdated**, especially after adding features, changing database access, or updating packages.
* **Fix errors first.** Error findings are usually exploitable.
* **Combine scans with a review.** Now and then, ask the agent to review your app's security in the chat. A narrative review can catch issues the scanners miss.
* **Be deliberate when ignoring.** Ignore a finding only when it clearly doesn't apply, and revisit ignored findings as your app changes.
* **Keep monitoring after publishing.** New features and new vulnerabilities in packages both create new findings.

<Warning>
  Automated scans catch common issues, but they can't guarantee complete security. For apps that handle sensitive data or payments, consider a professional security review.
</Warning>

## FAQ

<AccordionGroup>
  <Accordion title="How do I open the Security view?">
    Select **Manage** in the editor header, then **Security**.
  </Accordion>

  <Accordion title="What does Outdated mean?">
    Your project changed since a scanner last ran, so its findings may no longer match your code. Run a Basic or Deep scan to refresh them.
  </Accordion>

  <Accordion title="What's the difference between a Deep scan and asking the agent to review security?">
    A Deep scan runs Vibely's scanners and updates the findings in the Security view. Asking the agent to review your app's security in the chat gives you a written review and recommendations, and uses credits like any other chat turn. They're complementary.
  </Accordion>

  <Accordion title="Who can run scans and fix findings?">
    Anyone with edit access to the project. Viewers can see the Security view but can't run scans or change findings.
  </Accordion>

  <Accordion title="What happens if I publish with critical findings?">
    Unless your workspace has **Block publishing with critical issues** turned on, the publish goes ahead. The publish dialog shows how many critical issues were found so you can review them first.
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="Security best practices" icon="shield-check" href="/features/security/best-practices">
    Avoid the most common findings in the first place.
  </Card>

  <Card title="Security center" icon="building-shield" href="/features/workspace/security-center">
    Findings and dependency risk across your workspace.
  </Card>

  <Card title="Privacy & security settings" icon="lock" href="/features/workspace/privacy-security">
    Publishing gates and other workspace policies.
  </Card>

  <Card title="Publish your app" icon="rocket" href="/features/deploy/publish">
    Where the publish-time scan runs.
  </Card>
</CardGroup>


## Related topics

- [View and edit your project's code](/features/projects/code-editor.md)
- [Find your way around the editor](/features/projects/editor.md)
- [Workspace Insights](/features/workspace/insights.md)
- [Vibely for Enterprise](/introduction/enterprise.md)
- [Workspace security center](/features/workspace/security-center.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.