Vulnerability Assessment & Penetration Testing

External, internal, and application-layer testing against OWASP Top 10, API Security Top 10, and cloud-specific attack paths. Manual tradecraft, CVSS-scored findings, retest included.

Audit category · 04 of 08

Scope

What this covers

VAPT is shorthand for two related but distinct exercises: a vulnerability assessment (breadth — what issues exist?) followed by a penetration test (depth — which of them can actually be exploited, and to what effect?). Both are in scope.

External infrastructure

Internet-facing assets: public IPs, exposed services, subdomains, cloud storage, certificate posture. Starts from what an unauthenticated attacker can see.

Internal infrastructure

Post-perimeter testing. Lateral movement, privilege escalation, flat-network failure modes. Simulated via VPN or an assumed-breach access pattern.

Web application

OWASP Web Security Testing Guide. Authn / authz, injection, SSRF, IDOR, business-logic flaws, session management, client-side controls.

API

OWASP API Security Top 10. Broken object-level authorization, broken function-level authorization, mass assignment, excessive data exposure, rate-limiting.

Cloud-native

Attack paths specific to cloud: IMDS exposure, assumable roles, over-scoped OIDC trust policies, metadata exfiltration, lateral movement via IAM.

Secure code review

Targeted review of security-sensitive code paths — authentication, authorization, cryptography, input validation, secret handling.

Why it matters

Scanners find vulnerabilities. Humans find exploits.

Automated scanners are fast, thorough about known patterns, and blind to anything that requires chaining findings or understanding business context. An IDOR that trivially leaks every customer's invoice will not be detected by a scanner because the scanner does not know what “every customer's invoice” means.

A penetration test exists to simulate an attacker who does understand context. That is where real risk lives, and it is the evidence most buyers, insurers, and compliance frameworks (SOC 2, ISO 27001, PCI DSS) explicitly require on an annual basis.

Method

How we test

We follow the Penetration Testing Execution Standard (PTES) with OWASP WSTG and OWASP API Security Top 10 as per-domain references. Every engagement has a documented rules-of-engagement (RoE) signed before testing begins.

Phase 1

Scoping & RoE

In-scope systems, out-of-scope systems, test windows, emergency contacts, data-handling rules, social-engineering authorization (default: off).

Phase 2

Recon & enumeration

Subdomain enumeration, asset discovery, technology fingerprinting, authenticated-user provisioning, access-key provisioning for cloud accounts.

Phase 3

Vulnerability assessment

Automated scanning (Burp Suite Pro, Nuclei, Nessus) to establish the breadth baseline. Findings triaged for false positives.

Phase 4

Manual exploitation

The actual penetration test. Chain findings, escalate privilege, exfiltrate test data, demonstrate impact. Every successful exploit documented with proof-of-concept.

Phase 5

Reporting

Executive summary, technical narrative, findings register with CVSS scores, remediation guidance. Delivered under NDA within one week of test close.

Phase 6

Retest

Once remediations are claimed complete, we retest each finding and update its status in the register. Retest is included, not a separate engagement.

Deliverables

What you get

Executive summary (2–3 pages) — plain-English risk narrative suitable for board, insurer, or buyer distribution.
Technical report (30–80 pages depending on scope) — full methodology, per-finding proof-of-concept, reproduction steps, remediation guidance.
Findings register (CSV / JSON) — machine-readable, CVSS-scored, integrable with your issue tracker.
Attestation letter — signed confirmation of testing period and overall outcome, suitable for SOC 2, ISO 27001, PCI DSS, or customer security questionnaires.
Retest report — each remediated finding verified and re-scored; residual issues surfaced explicitly.

Patterns

Common findings

The findings most often elevated to high or critical in a cloud-native pen test:

Broken object-level authorization (IDOR).

/api/orders/123 returns order 123 regardless of who is authenticated. The single most common high-severity finding in modern web apps because scanners cannot detect it without business context.

Server-side request forgery to cloud metadata.

An image-fetch, webhook, or PDF-renderer endpoint that proxies arbitrary URLs. Combined with IMDSv1 (or misconfigured IMDSv2) this leaks instance credentials directly.

Secrets exposed in client-side bundles.

API keys, service-role credentials, or internal URLs shipped to the browser in webpack bundles. Usually stem from a single environment-variable mix-up during build configuration.

Over-scoped OIDC trust on CI/CD roles.

A GitHub Actions or GitLab OIDC trust policy that allows any repo in the organization (or worse, any repo) to assume a production role. Fix with subject-condition narrowing.

Broken function-level authorization on admin endpoints.

Hidden admin UIs disabled by the frontend but still routable. Authentication is enforced; authorization is not. Every authenticated user is an admin.

Legacy authentication flows with missing rate limits.

Login, password-reset, and MFA-verify endpoints without adaptive rate limiting. Enables credential stuffing, user enumeration, and MFA bypass via brute force.

FAQ

Questions we get asked

Black box, grey box, or white box? +

Grey box is our default for web and API tests. Credentials are issued for each relevant role. White box (with source code review) is available and produces the deepest results. Pure black box is available on request but rarely the best use of budget.

Do you test production? +

Yes, with RoE. Production testing is the only way to surface issues that stem from real data, real scale, and real third-party integrations. Destructive actions (DoS-style testing, chaos injection) are out of scope by default.

Will the test take the site down? +

Testing is performed at a rate that simulates an intelligent attacker, not a load generator. Traffic thresholds are agreed in the RoE. Any unintended impact triggers an immediate pause.

Are your testers certified? +

Lead testers hold OSCP, CRTP, or equivalent offensive-security certifications, and CISSP for the consultative side. Certification is a proxy for methodology, not skill — we do not bill on credentials, only outcomes.

How does this satisfy our SOC 2 / ISO 27001 / PCI DSS pen-test requirement? +

All three require an annual penetration test from an independent party. Our attestation letter and report package are written to be handed directly to an auditor.

How often should we test? +

Annually at minimum for SOC 2 / ISO 27001 / PCI DSS. Additionally after any major release, architectural change, or incident. For regulated environments we recommend continuous ASM with full VAPT annually.

Methodology references: PTES, OWASP WSTG, OWASP API Security Top 10. See also Security Posture and CI/CD & DevSecOps.

Start with a free Cloud Health Check.

A scoped-down CloudCheck 360° of your current environment. Delivered in five business days, no commitment.

Book a Health Check See engagement packages