Security overview

Protect your AI-built sites with built-in dependency audits and secret scanning — catch known vulnerable packages and committed API keys before you publish.

Volnyn helps reduce common application security risks during development and before publishing. It does this by identifying potential vulnerabilities through automated analysis of your site's own source.

The built-in Security scan checks two things:

1. Dependency vulnerabilities — declared npm packages against the OSV vulnerability database
2. Exposed secrets — provider-shaped API keys and credentials committed into source files

These tools support safer shipping, but they do not replace a thorough security review. You are responsible for ensuring that your site meets the security requirements appropriate for its use case, especially if it handles sensitive data or performs critical functions.

These tools help identify common security issues, but they cannot guarantee complete security. For apps handling sensitive data or critical functionality, consider an additional professional security review.

Built-in security scan

Volnyn provides one built-in scanner for AI-built sites. Open Security in the site sidebar and click Run scan.

The scan reads the same project files a GitHub sync would send. It never walks node_modules — only your own source.

Dependency audit

The dependency pass looks at package.json (dependencies and devDependencies) and queries OSV.dev for known advisories.

Findings include:

• Package name and version used for the lookup
• Severity (critical / high / medium / low)
• Advisory IDs and a link to details

If a site has no package.json, or no declared dependencies, this pass returns nothing.

Secret / API key scan

The secrets pass greps your source for provider-specific key shapes — deliberately narrow patterns so random base64 does not flood the report. Examples include:

• AWS access key IDs
• GitHub personal tokens
• Stripe, OpenAI, Anthropic, and Google API keys
• Slack tokens
• Private key blocks
• Supabase service-role JWTs
• Twilio auth tokens
• Generic hardcoded api_key / secret / password / token assignments

Lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lockb) are skipped because they legitimately contain key-shaped strings.

When security scans run

Volnyn runs security scans on demand. There is no automatic scan on every edit.

On demand

Open the site Security page and click Run scan. Use this after significant code changes, before a public launch, or when investigating a specific concern.

Each run:

• Takes a few seconds for typical projects
• Stores the latest result on the site so the page shows Critical / High / Medium counts and the last-scan time
• Replaces the previous result (there is no scan history archive on the page)

Before publishing

There is no hard block on publish today, but you should resolve critical findings — especially exposed secrets — before making a site public. Publishing with unresolved critical issues is strongly discouraged for production apps or apps handling sensitive user data.

How Volnyn helps keep your sites secure

Protecting API keys

Frontend code runs in the browser. Secrets pasted into client-side files can leak to anyone who views the page source or a public repo.

If the scanner reports an exposed secret:

1. Rotate the key at the provider (treat it as compromised).
2. Remove it from source.
3. Store it in environment / server-side config instead of hardcoding it in the frontend.

Prefer describing integrations in chat (“connect service X to generate text”) and letting the assistant wire a secure server-side path, rather than pasting live credentials into prompts or files.

Identifying vulnerabilities in dependencies

Third-party libraries are a common source of risk. Even popular packages can ship advisories later.

The dependency audit flags packages with published OSV advisories so you can:

• Ask the AI to upgrade the package
• Bump the version in package.json yourself
• Open the advisory Details link to assess impact

Keeping dependencies current is an ongoing habit — re-run the scan after upgrades.

Acting on security findings

After a scan, the Security page shows summary tiles (Critical, High, Medium, Files scanned) and two detail lists when needed.

Review findings

Severity pills help you triage. Start with critical, then high.

Fix exposed secrets

1. Rotate the credential at the provider.
2. Delete the hardcoded value from the file shown in the finding (file:line).
3. Re-run Run scan to confirm the finding is gone.

Fix vulnerable dependencies

1. Open Details on the advisory for remediation guidance.
2. Ask the AI assistant to upgrade the package, or edit package.json yourself.
3. Rebuild / republish as needed, then re-run the scan.

Clean result

If both lists are empty, the page shows No issues found — no known-vulnerable declared dependencies and no credentials matched in source.

Where to open Security

1. Open an AI-built site in the dashboard.
2. In the site sidebar, go to Security (or visit /user/site/security).
3. Click Run scan.

If the current site is not an AI website, the page explains that the scan is only available for AI-built projects.

What the scan does not cover

Be clear about scope so you do not over-trust a green result:

• It does not run dynamic penetration tests against a live URL.
• It does not lint database row-level security (RLS) or cloud IAM policies.
• It does not scan node_modules or remote CI artifacts.
• It does not prove the absence of XSS, CSRF, or auth bugs — only the two passes above.
• Version ranges in package.json are resolved to a concrete version for OSV; lockfile-accurate trees are not fully expanded.

Use the scan as an early warning system, then apply normal secure-development practices for anything sensitive.

Related

• Publishing your site — ship after you have reviewed critical findings
• Create your first website — build an AI site you can scan