// VEYRA CODE
Understand what is actually shipping.
Veyra Code reads your authorized repositories the way an application security engineer would: it maps what the application exposes, where trust boundaries are supposed to be, and where the code fails to enforce them.
Static application security testing
Injection, unsafe deserialization, path traversal, server-side request forgery, template injection, and the other classes that turn a single unvalidated input into a compromise.
Dependency analysis
Direct and transitive dependencies resolved against known vulnerability data, with reachability considered so an unused package does not generate the same urgency as one on a live request path.
Secret detection
Credentials, API keys, tokens, and private keys committed to source — including history, where secrets most often survive long after someone thinks they removed them.
Authentication logic
How sessions are issued, validated, and revoked. Where authentication is applied inconsistently, and which routes silently skip it.
Authorization logic
Whether the code verifies that the authenticated caller is permitted to act on the specific object requested — the check most commonly missing in multi-tenant applications.
Database access patterns
Queries that are not scoped to a tenant, raw query construction, over-permissive selects, and data access that bypasses application-level controls.
Input validation
Where untrusted input enters, how far it travels before it is validated, and which sinks it can reach.
Cross-repository correlation
Services rarely live alone. Veyra links a route in one repository to the service, client, or shared library in another so a boundary that spans repositories is still visible.
Your source code is some of your most sensitive data.
Veyra is built to hold as little of it as possible, for as short a time as possible.
Permissions Veyra requests
Repository contents: read. Metadata: read. Pull requests: read, only when the feature requires it. Veyra does not request write access, and cannot modify, merge, or delete your source code. Any future capability that needs additional permission will be requested separately and explicitly.
Language and ecosystem coverage.
Coverage depth varies by ecosystem. Where analysis is shallower, Veyra says so in the assessment rather than reporting a clean result it cannot support.
| Ecosystem | Static analysis | Dependencies | Route discovery |
|---|---|---|---|
| JavaScript / TypeScript | Full | npm, yarn, pnpm | Express, Fastify, Next.js, NestJS |
| Python | Full | pip, Poetry, uv | Django, Flask, FastAPI |
| Ruby | Full | Bundler | Rails |
| Go | Full | Go modules | net/http, Gin, Echo, Chi |
| Java / Kotlin | Full | Maven, Gradle | Spring Boot |
| PHP | Standard | Composer | Laravel, Symfony |
| C# / .NET | Standard | NuGet | ASP.NET Core |
| Infrastructure as code | Full | — | Terraform, Docker, Kubernetes manifests |
Working in something not listed? Tell us what you build — coverage is prioritized by what customers actually ship.
What a code finding looks like.
This is the canonical example used across this site. It comes from an intentionally vulnerable demonstration application, not from a customer.
// invoices are fetched by id for any authenticated session
router.get('/invoices/:invoiceId', requireAuth, async (req, res) => {
const invoice = await db.invoices.findById(req.params.invoiceId)
if (!invoice) return res.status(404).json({ error: 'not_found' })
return res.json(invoice) // returned without ownership validation
})The route authenticates. It does not authorize. Veyra links the handler to the public endpoint that reaches it and to the billing datastore behind it, which is what raises this from a code smell to a critical finding. See the full finding on the homepage
Common questions
Does Veyra store our source code?
Is our code sent to a third-party AI provider?
Can Veyra open pull requests to fix issues?
What happens to monorepos?
Start with a baseline assessment.
Authorize your assets and receive a prioritized view of what is actually exposed.