§Methodology

V-Standard 2026.3

An open methodology for remote security assessment. Its 60 check groups describe assessment areas; specific tests depend on technologies, access and agreed scope. Results are recorded in the report and public certificate record.

60
check groups
6
domains
52
core checks

Edition 2026.3 · Effective from 2026-07-01

How the methodology is built

01

Check groups, not tool output

Each check group aggregates multiple automated tests and, where the level requires, expert scenarios. A group passes only when every test in it passes or is formally not applicable.

02

Methods are declared

Every check states its method: automated, SCA/CVE matching, secret scan, SAST, manual scenario, evidence review, or a combination. The method is printed on the Trust Page.

03

Scope is fixed before testing

Components, domains, environments and exclusions are agreed in writing and cannot be narrowed after a finding.

04

Evidence is kept, details are not published

We store the evidence for every result. Trust Pages carry only a safe public summary — never vulnerability details, secrets, private URLs or code.

05

Versioned

The catalogue is versioned by edition. A certificate always names the edition it was verified against.

Catalogue of checks

Sixty check groups. The letter and number of a check are stable across editions and appear on every Trust Page. Levels: V1 covers domain A; V2 adds B; V3 adds C; V4 adds D and E. Domain F is an add-on to any level.

See the automated coverage behind these perimeter groups →

A

External perimeter

Everything an attacker can reach without credentials: domains, TLS, DNS, mail authentication, exposed services and the software versions behind them.

12 checks
  • A01
    TLS configuration and certificate validity

    Supported protocol versions and cipher suites, certificate chain, expiry, revocation information, key strength and known TLS weaknesses on every public endpoint in scope.

  • A02
    HTTPS enforcement and HSTS

    Plain-HTTP requests are redirected to HTTPS, HSTS is present with an adequate lifetime, and no content in scope is served over an unencrypted channel.

  • A03
    DNS configuration and zone hygiene

    Authoritative servers, DNSSEC where applicable, dangling records that allow sub-domain takeover, zone transfer exposure and consistency between public and expected records.

  • A04
    Email authentication (SPF, DKIM, DMARC)

    Sender authentication for the product's domains: SPF syntax and scope, DKIM signing, DMARC policy and reporting, MTA-STS where present.

  • A05
    HTTP security headers

    Content-Security-Policy, frame protection, content-type sniffing, referrer policy, permissions policy and cache directives on sensitive responses.

  • A06
    Exposed services and open ports

    Inventory of listening services on the public perimeter, unexpected management ports, databases or message brokers reachable from the internet.

  • A07
    Known-vulnerable software versions

    Identified server software, frameworks and components on the perimeter are matched against published vulnerability records (CVE/NVD, CISA KEV, vendor advisories).

  • A08
    Administrative interfaces and default credentials

    Administration panels, monitoring dashboards and management consoles reachable from the internet; default or vendor credentials on any such interface.

  • A09
    Information disclosure

    Version banners, directory listings, debug endpoints, source-control folders, environment files, backups and stack traces reachable on the perimeter.

  • A10
    Cookie security attributes

    Secure, HttpOnly and SameSite attributes on session and sensitive cookies, cookie scope and lifetime.

  • A11
    Redirects and mixed content

    Open redirects, insecure downgrade paths and mixed-content resources on pages in scope.

  • A12
    Vulnerability disclosure channel

    A published way to report a vulnerability (security.txt or equivalent) that reaches a responsible person and is answered.

B

Application and API

How the product authenticates, authorises and isolates its users, and how it handles hostile input across the web application and its APIs.

14 checks
  • B01
    Authentication

    Credential policy, multi-factor availability, brute-force and credential-stuffing protection, safe handling of failed logins and enumeration.

  • B02
    Session management

    Session identifier generation, rotation on privilege change, expiry, revocation on logout and concurrent-session handling.

  • B03
    Authorisation and roles

    Role model enforcement on every function and object: horizontal and vertical privilege escalation, insecure direct object references, mass assignment.

  • B04
    Tenant and data isolation

    Separation of data between organisations or accounts in a multi-tenant product: queries, storage, caches, background jobs and exports.

  • B05
    Input handling and injection

    Server-side injection classes — SQL, NoSQL, command, template, path traversal, server-side request forgery, XML external entities — across the endpoints in scope.

  • B06
    Client-side security

    Cross-site scripting (reflected, stored, DOM-based), cross-site request forgery, clickjacking and unsafe client-side storage.

  • B07
    API authentication and object-level authorisation

    Token handling, key rotation, object- and property-level authorisation on API resources, function-level access control.

  • B08
    API inventory and exposure

    Undocumented or deprecated endpoints, debug and internal APIs reachable from outside, excessive data exposure in responses.

  • B09
    Rate limiting and abuse controls

    Limits on authentication, messaging, export and other resource-intensive operations; protection against automated abuse.

  • B10
    File upload and processing

    Type validation, size limits, storage location, execution prevention and safe processing of uploaded content.

  • B11
    Error handling and logging hygiene

    Error responses do not leak internals; logs do not contain secrets or excessive personal data; failures are recorded.

  • B12
    Business logic abuse

    Workflow bypass, price or quantity manipulation, replay of one-time actions and race conditions in the key flows in scope.

  • B13
    Account recovery flows

    Password reset, email change and account recovery: token strength, expiry, single use and protection against takeover.

  • B14
    Third-party integrations and callbacks

    Webhook signature verification, OAuth flows, callback URL validation and least-privilege scopes for integrated services.

C

Code and supply chain

The source code, its dependencies and the pipeline that turns them into a running product — from secrets in history to build provenance.

9 checks
  • C01
    Dependencies and known CVEs

    Software composition analysis of direct and transitive dependencies against published vulnerability records; unmaintained and end-of-life components.

  • C02
    Secrets in code and history

    Credentials, tokens, keys and certificates in the repository tree, commit history, build configuration and container layers.

  • C03
    Static analysis (SAST)

    Rule-based analysis of the source for injection, unsafe deserialisation, cryptographic misuse, insecure defaults and dangerous functions, with manual triage of findings.

  • C04
    Software bill of materials

    A machine-readable SBOM (CycloneDX or SPDX) exists, matches the deployed build and can be regenerated by the pipeline.

  • C05
    CI/CD security

    Pipeline permissions, secret handling in jobs, third-party actions and images, artefact signing and separation between build and deploy credentials.

  • C06
    Dependency pinning and integrity

    Lock files, version pinning, integrity hashes and controlled registries for packages, base images and build tools.

  • C07
    Container image security

    Base image currency, vulnerable packages, secrets in layers, running as root and unnecessary capabilities.

  • C08
    Repository protection and code review

    Protected default branches, mandatory review, signed commits or verified authorship, and restricted force-push.

  • C09
    Build provenance and artefact integrity

    Reproducible or attested builds, artefact signatures and verification before deployment.

D

Infrastructure

Cloud identity, network boundaries, secrets, patching, logging and recovery — the platform the product runs on.

8 checks
  • D01
    Cloud identity and least privilege

    Root and administrative accounts, MFA enforcement, role scoping, long-lived keys and cross-account trust in the cloud accounts in scope.

  • D02
    Public storage and data exposure

    Object storage, snapshots, databases and file shares reachable without authentication or with over-permissive policies.

  • D03
    Network segmentation and firewalling

    Security groups, network ACLs, private subnets for data stores, bastion access and east-west restrictions.

  • D04
    Secrets management

    Central secret storage, rotation, access auditing and absence of secrets in configuration files, images or environment dumps.

  • D05
    Patch and vulnerability management

    Defined patch cadence, tracking of published vulnerabilities for the stack in use and evidence that Critical fixes are applied within the declared window.

  • D06
    Logging, monitoring and alerting

    Security-relevant events are logged centrally with retention, alerting on authentication anomalies and administrative actions, and protected from tampering.

  • D07
    Backup and recovery

    Backup coverage of production data, encryption of backups, off-site copies, restoration tests and recovery time objectives.

  • D08
    Hardening baselines

    Operating system and service configuration against a documented baseline, unnecessary services disabled, administrative access restricted.

E

Data and processes

How data is protected at rest and in transit, and whether the organisation has working processes for incidents, changes, vendors and deletion.

9 checks
  • E01
    Encryption at rest

    Encryption of databases, object storage, backups and disks holding customer data; algorithms and key ownership.

  • E02
    Encryption in transit

    Encryption of internal service-to-service traffic, database connections and administrative channels, not only the public edge.

  • E03
    Key management

    Generation, storage, rotation, separation of duties and revocation for cryptographic keys and signing material.

  • E04
    Access reviews and offboarding

    Periodic review of who has access to production, timely removal on role change or departure, and administrative account inventory.

  • E05
    Incident response

    A written plan with roles, contacts, severity definitions, customer notification rules and evidence of at least one exercise or real incident review.

  • E06
    Vulnerability handling process

    Intake of external reports, triage, severity assignment, remediation deadlines and communication back to the reporter.

  • E07
    Change management

    Changes to production are reviewed, tested, approved and can be rolled back; emergency changes are recorded.

  • E08
    Vendor and third-party risk

    Inventory of sub-processors and critical vendors, their access, contractual security obligations and periodic review.

  • E09
    Data retention and deletion

    Defined retention periods, working deletion on customer request, deletion from backups within a declared window.

F

AI/Agent Security add-on Add-on

Additional checks for products that embed language models or agents acting on behalf of users. Available as an add-on to any level.

8 checks
  • F01
    Prompt injection resistance

    Direct and indirect prompt injection through user input, retrieved documents and tool outputs; separation of instructions from data.

  • F02
    Tool and action authorisation

    Every action an agent can perform is bound to the permissions of the user it acts for, with confirmation for irreversible operations.

  • F03
    Output handling and sandboxing

    Model output is treated as untrusted: rendering, code execution, file and network access are constrained.

  • F04
    Data leakage via model context

    System prompts, other users' data and secrets cannot be extracted through the model; context is scoped per user.

  • F05
    Retrieval and training data access controls

    Retrieval sources respect the requesting user's permissions; training or fine-tuning data is governed and free of customer secrets.

  • F06
    Model and prompt supply chain

    Provenance of models, weights, prompts and plug-ins; version pinning and change review.

  • F07
    Rate, cost and abuse controls

    Limits on token usage, tool invocations and cost per user; detection of automated abuse.

  • F08
    Logging and human oversight

    Agent actions are logged and attributable; high-impact actions have a human checkpoint; users can see what was done on their behalf.

Severity model

Findings are rated with CVSS v4.0 as the baseline and adjusted for the business context of the product — data sensitivity, exposure and exploitability in the real deployment.

CriticalDirectly exploitable with severe impact: remote code execution, authentication bypass, cross-tenant data access. Blocks issue at every level.
HighExploitable with significant impact or a chain of conditions. Must be remediated for V3 and V4; disclosed as an open count for V1 and V2.
MediumLimited impact or requires unlikely preconditions. Remediation plan agreed; does not block issue.
LowHardening opportunity with negligible direct impact. Reported for information.
InfoObservation without security impact.

Known-vulnerability coverage

Vulnerability databases contain thousands of records about software weaknesses. We match identified components and versions to relevant records, then assess applicability within the agreed scope.

Database size is not a test count. The report identifies the components actually assessed, methods, results and limitations.

Relation to industry approaches

The methodology takes into account and uses elements of recognised industry approaches:

OWASP ASVSOWASP SAMMNIST SSDFCISA SBOM guidanceOWASP API Security Top 10OWASP GenAI Security

CyberSecurityV does not claim formal accreditation, partnership, certification by, or full conformance to these organisations or standards.