// METHODOLOGY
How Veyra evaluates application risk.
Security tooling asks for a lot of trust. This page describes exactly how findings are produced, how they are scored, what is tested, and — just as importantly — what is not.
-
01 DISCOVER
Understand authorized assets
Establish exactly what is in scope: repositories, applications, domains, APIs, and environments. Record the authorization, the limits, and the person who granted it. Nothing is analyzed before this stage completes.
-
02 MAP
Build application and API relationships
Construct a model of the environment — services, routes, data stores, authentication boundaries, third-party integrations — and link each element to the code that implements it.
-
03 ANALYZE
Run security analysis
Static analysis, dependency analysis, secret detection, configuration review, and non-destructive external checks, each producing raw findings into a normalized pipeline.
-
04 CORRELATE
Connect related weaknesses
Deduplicate across techniques, then connect findings across code, APIs, dependencies, and external assets to identify paths from an entry point to something worth protecting.
-
05 VERIFY
Increase confidence in meaningful findings
Corroborate against independent signals and, where safe and authorized, reproduce the issue. High-severity findings can move through human verification before being called confirmed.
-
06 PRIORITIZE
Rank by actual risk
Score severity against a defined model and order the queue by the risk each finding creates for your business, not by scanner category or raw count.
-
07 REMEDIATE
Provide engineering guidance
Deliver a specific fix for your stack, the security pattern that prevents the class of issue returning, and every sibling location affected by the same weakness.
-
08 REASSESS
Determine whether remediation worked
Rescan the affected components after a fix is deployed, confirm the issue is genuinely resolved rather than relocated, and watch for regressions if it later reappears.
What Veyra tests, and what it does not.
The most useful thing a security vendor can publish is an honest boundary. A tool that implies total coverage teaches you to trust a clean report you should not trust.
IN SCOPE
- Source code in authorized repositories
- Direct and transitive dependencies
- Secrets in code and commit history
- API routes discovered from source
- Authentication and authorization logic
- Input validation and data-flow paths
- Security configuration and infrastructure as code
- Authorized external assets: DNS, TLS, headers, exposed services
- Correlation across all of the above
OUT OF SCOPE
- Destructive exploitation of any kind
- Denial of service or load testing
- Social engineering and phishing of your staff
- Physical security
- Any asset not explicitly authorized
- Third-party SaaS you use but do not control
- Business logic requiring domain knowledge Veyra has not been given
- Compliance certification — Veyra does not issue any
Where automation is genuinely weaker than a human
Automated analysis is excellent at breadth, consistency, and never getting bored. It is weaker at business logic flaws that depend on understanding what your product means — a discount that can be applied twice, a workflow state that should be unreachable, a permission model that is correct in code but wrong as a policy. A skilled penetration tester still finds things Veyra will not. Veyra is designed to make that engagement start from a much cleaner baseline, not to replace it.
Severity model.
Severity is assigned against defined criteria. It is not inflated to make a report look more valuable, and it is not deflated to make a security score look better.
| Severity | Definition | Expected response |
|---|---|---|
| Critical | Exploitable with little effort and causes severe consequence: cross-customer data access, authentication bypass, remote code execution, or unauthorized financial action. | Fix now. Alerted immediately on verification. |
| High | Serious consequence but requires some privilege, chained conditions, or a narrower window. | Fix in the current cycle. |
| Medium | Real weakness with limited direct impact, or meaningful impact that requires improbable conditions. | Schedule into normal work. |
| Low | Minor weakness, defence-in-depth gap, or hardening opportunity. | Address opportunistically. |
| Informational | No direct security impact. Context, inventory, or observations worth knowing. | No action required. |
Factors considered
- Exploitability
- How much effort, skill, and access an attacker needs.
- Authentication requirements
- Whether the issue is reachable unauthenticated, or requires a valid account.
- Privileges required
- Whether an ordinary account is enough, or elevated access is needed first.
- Sensitive data exposure
- The category and volume of data reachable — personal, financial, credential, or health-related.
- Financial impact
- Whether the issue permits unauthorized financial actions or exposes financial records.
- Cross-customer impact
- Whether one tenant can reach another tenant’s data. Weighted heavily in multi-tenant products.
- Destructive capability
- Whether the issue permits irreversible change: deletion, cancellation, transfer.
- Public accessibility
- Whether the affected surface is reachable from the internet.
- Attack complexity
- Whether conditions outside the attacker’s control are required.
- Blast radius
- How far consequence spreads beyond the immediate component.
- Confidence
- How certain Veyra is that the finding is real. Scored and reported separately, never blended into severity.
Confidence is reported separately.
Blending certainty into severity is how security tools lose the trust of engineering teams. Veyra keeps them apart.
| Confidence | Basis | How it is presented |
|---|---|---|
| 90–100% | Corroborated by multiple independent signals and, where safe and authorized, reproduced. | Confirmed finding. Eligible for human verification and “Verified” status. |
| 70–89% | Strong evidence from code and surrounding context, without safe reproduction available. | Probable finding, with the supporting evidence shown. |
| 50–69% | Matches a known weakness pattern, but context is incomplete. | Requires investigation. The ambiguity is stated explicitly. |
| Below 50% | Insufficient evidence to raise responsibly. | Not shown as a finding. Retained as signal for future correlation. |
The rule that governs everything here
A critical finding is never presented as a confirmed vulnerability unless the evidence supports it. Where human verification is included in your plan, a security engineer reviews the evidence, confirms the finding is real, and records who verified it and when.
What the score means — and what it does not.
A single number is useful for tracking direction over time and for communicating with people who will never read a findings queue. It is dangerous if anyone treats it as a guarantee.
The Veyra Security Score runs from 0 to 100 and is calculated across eight weighted categories. It moves as findings are introduced and resolved, so the trend line is generally more informative than the number on any given day.
DISCLAIMER — SHOWN IN PRODUCT
A Veyra Security Score represents observed security posture across monitored assets. It does not guarantee the absence of vulnerabilities.
A score of 100 means Veyra found nothing across what it monitors, using the techniques it applies. It does not mean the application is invulnerable, and Veyra will never present it that way.
Common questions
How do you avoid drowning us in false positives?
Who performs human verification?
Do you follow OWASP or CWE?
What if we disagree with a severity rating?
How long does an assessment take?
Read the method, then see it applied.
A baseline assessment runs this methodology against your authorized environment and returns findings you can act on.