Pentesting Overview

Codity Pentesting tests your running application the way an outside attacker would — from the public internet, against the live site, with no access to your source code. It is separate from the scanning that happens on a pull request: code scanning tells you what is wrong in the code you are about to merge, pentesting tells you what is exposed on the system your customers actually use.

Every assessment ends in a report you can hand to a customer, an auditor, or a security questionnaire: findings with severity, CVSS score, CWE reference, evidence, reproduction steps, and remediation guidance.

Two kinds of assessment

Everything starts from a domain you have proved you control. From there you can run either of two assessments against it, and most teams run both.

A black-box scan builds a picture of your public footprint from information already published about you — certificate records, public DNS, and public network registration data. Your application receives nothing from Codity, so it is safe on production at any time, including on infrastructure you do not host.

An active test crawls the running application and, from Standard mode upwards, attacks the parameters it finds with the classes of payload an attacker would use — injection, cross-site scripting, template injection, path traversal, command injection — then checks the responses for evidence of a real vulnerability. It runs in one of three scan modes: Quick, Standard or Deep. See Scan Modes.

Both are bought one run at a time, and each mode is priced separately.

Why findings are trustworthy

Automated web scanners are notorious for noise. Codity separates two kinds of result and treats them differently:

• Something the scanner observed. A missing security header, a cookie without the right flags, a value disclosed in a response. The scanner proved it by reading the response, so it is reported as observed and enriched with a severity, a CVSS score and remediation.
• Something the scanner attacked. A payload was sent to a parameter. Whether that proves a real, exploitable vulnerability is a judgement, so every one of these goes through a second, evidence-based validation pass that reads the exact request sent and the exact response returned. A candidate the evidence does not support is discarded and never reaches your report.

What survives is written up with:

• A severity and a CVSS 3.1 score and vector
• The CWE class of the weakness
• The endpoint, HTTP method and parameter involved
• The captured request and response evidence
• A reproduction step or proof of concept you can run yourself
• Remediation guidance specific to the finding

How a scan runs, end to end

1. Add a domain and prove you control it. Nothing can be scanned until this passes — see Domain Verification.
2. Choose the assessment. A black-box scan runs straight against the verified domain. An active test runs against a target URL you configure under that domain — see Active Test Targets.
3. Start the run. Pentests are bought one run at a time, so you pay for the assessment at the moment you start it. The whole run is validated first, so nobody is charged for a scan that would have been refused.
4. Watch it. The Reports tab updates itself every ten seconds while a scan is in flight; you can close the tab and come back.
5. Read the report. When the run completes, findings are listed in the dashboard and the full report is available as a PDF or as JSON — see Reports and Findings.

info

One assessment runs at a time per organization. If a scan is already queued or running, start the next one when it finishes.

Where to find it

Open Pentesting in the Codity dashboard. The page has three tabs:

• Domains — add domains, prove ownership, and start black-box scans
• Active DAST — configure the URLs, modes and credentials active tests use
• Reports — every run, its status, its findings, and its downloads

Rules of engagement

Codity will only test a domain that your organization has cryptographically proven it controls, and it will only send traffic to hosts inside that verified domain. This is enforced on every run, not just at setup. Scope and Safety explains exactly what Codity will and will not touch, which is usually the page your infrastructure or hosting provider will want to see.