Established methodologies, adapted to your scope.
The exact methodology and test cases are adapted to the agreed scope of each engagement.
Public, widely used references — not proprietary checklists.
CyberZ is not accredited, certified or endorsed by OWASP or any standards body. We use the current version of each reference at the time of testing and state which references applied in every report.
OWASP Web Security Testing Guide
Comprehensive testing methodology reference
Our primary reference for web application test cases: information gathering, configuration, identity, authentication, authorization, session management, input validation, error handling, cryptography, business logic and client-side testing.
OWASP Application Security Verification Standard
Open standard and basis for application security verification
Used to structure coverage and to describe, in the report, which verification areas were exercised. Coverage level is agreed per engagement; ASVS is a reference, not a certification.
OWASP API Security Top 10
API-specific risk reference
Frames API testing around object- and function-level authorization, property-level exposure, resource consumption, business flows and unsafe consumption of third-party APIs.
Penetration Testing Execution Standard
Applied where appropriate — network and infrastructure
Guides pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation and reporting for external and internal network engagements.
Common Vulnerability Scoring System
Severity scoring
Each finding receives a CVSS base score and vector. Final severity may be adjusted for your context and the adjustment is explained in the finding.
NIST guidance
Applied where appropriate
NIST publications on security testing and assessment inform planning and reporting where your program references them. CyberZ does not certify alignment with any NIST framework.
How an application test unfolds.
Phases overlap in practice, and network or cloud engagements follow their own sequence. Depending on the agreed scope, some phases are expanded and others are omitted.
Reconnaissance & mapping
Understand the application, its roles, entry points and dependencies. Enumerate the attack surface in scope.Identity, authentication & sessions
Credential handling, MFA, password reset, session lifecycle, OAuth / OIDC and token validation.Authorization & tenancy
Systematic role, tenant and object-level access testing — the source of most impactful findings in SaaS.Business logic
Workflows, state, sequencing, quotas and race conditions tested against how the product is meant to behave.Input handling & injection
Injection classes, XSS, CSRF, SSRF, file handling and traversal, with manual validation of any automated results.Configuration & infrastructure
Headers, CORS, TLS, exposed services and cloud configuration within the agreed scope.Validation & reporting
Every finding reproduced, scored, documented with evidence and remediation, then retested after your fix.
Scored with CVSS, explained in context.
CVSS gives a consistent base score. Context — what data is behind the flaw, which role is required, what compensating controls exist — can move the final severity, and the report says why.
| Severity | Band | Meaning |
|---|---|---|
| Critical | CVSS 9.0–10.0 | Direct compromise of systems or data with little or no preconditions. Reported immediately. |
| High | CVSS 7.0–8.9 | Significant impact such as cross-tenant data access or privilege escalation, typically requiring authentication. |
| Medium | CVSS 4.0–6.9 | Meaningful weakness with limited impact or notable preconditions; should be scheduled for remediation. |
| Low | CVSS 0.1–3.9 | Minor issue or defense-in-depth improvement with low direct impact. |
| Info | No score | Observations and hardening recommendations that are not vulnerabilities on their own. |
Tools enumerate. People find the flaws that matter.
Automated scanners are used where they are efficient: enumerating endpoints, fingerprinting components, covering known vulnerability signatures. Their output is a starting point, never a finding — every result is validated by hand before it appears in a report.
Authorization, tenancy, business logic, chained weaknesses and anything that depends on understanding what the application is supposed to do are tested manually. That is where most of the engagement time goes, and where the findings that change a risk picture come from.
Request a security assessment.
Tell us what you need tested, when, and which evidence you need at the end. We reply with scoping questions, not a sales deck.