Penetration Testing Fundamentals for Development Teams

1. Penetration test vs. vulnerability scan: the crucial difference

A vulnerability scan is an automated, signature-based comparison of an application or infrastructure against known vulnerabilities, outdated software versions, and typical misconfigurations. Tools like Nessus, OpenVAS, or OWASP ZAP in automated mode deliver a long list of potential issues within a few hours, prioritized by CVE score. That's fast, cheap, and repeatable at will, but it also produces a significant number of false positives and misses vulnerabilities that emerge from the interaction of several individually harmless features.

A penetration test, by contrast, simulates a real attacker: a human, assisted by tools, chains individual weaknesses into an actual attack path, checks for business logic flaws such as manipulable pricing or bypassable discount rules, and delivers a proof of concept for every critical finding instead of just a suspicion. The two methods complement each other rather than replace one another: automated scans ideally run weekly or with every deployment, while a full pentest typically happens annually or before major architecture changes.

2. Black-box, grey-box, and white-box: the three testing approaches

In a black-box test, the test team receives no internal knowledge at all, only the URL or IP address of the target, exactly like an external attacker without insider knowledge. This delivers the most realistic outside perspective, but the achievable depth is limited by the test's fixed time budget, since a lot of time goes into pure information gathering that a real attacker could stretch over weeks or months.

A white-box test gives the test team full access to source code, architecture documentation, and test accounts for every role, which makes it very close to a targeted code security review and, as a result, uncovers deep logic flaws that would be nearly invisible from the outside. A grey-box test sits in between: the team typically gets a low-privilege customer account, similar to what a registered user or an attacker with leaked credentials would have. For e-commerce stores, grey-box is usually the most sensible choice, because it realistically exercises the checkout, the customer account, and API endpoints with an actual session, without exposing the entire codebase upfront.

3. Scoping: what belongs in the test and what doesn't

A precise scoping document lists exactly which domains, subdomains, IP ranges, and API endpoints may be tested, in which environment (staging or production), and within which time window. Equally important is the explicit list of excluded systems, such as a payment provider within a third party's PCI DSS scope, or embedded marketing tools for which no permission from the respective vendor exists. Without this level of precision, tests risk accidentally hitting infrastructure that isn't theirs to touch.

Allowed and prohibited techniques belong in the scope just as much: denial-of-service tests, social engineering against employees, or physical access attempts are excluded by default unless separately agreed upon. Testing against the production environment carries real risk to data integrity and availability, so a staging environment with realistic but anonymized data is the preferred choice. If production must still be tested, destructive actions like actually capturing a payment should be explicitly excluded from scope.

# rules-of-engagement.yaml - Scoping document for a penetration test
# This document must be signed by an authorized representative
# of the target organization BEFORE any testing begins.
engagement:
  client: "Mironsoft Demo GmbH"
  target_systems:
    - "https://shop.example.com (production, read-only actions only)"
    - "https://staging.shop.example.com (staging, full test allowed)"
  excluded_systems:
    - "Payment provider APIs (PCI DSS scope, third party)"
    - "Third-party marketing tools (no authorization from vendor)"
  test_type: "grey-box"
  test_window:
    start: "2026-08-03T08:00:00+02:00"
    end: "2026-08-07T18:00:00+02:00"
  allowed_techniques:
    - "authenticated and unauthenticated web application testing"
    - "API security testing (REST, GraphQL)"
    - "business logic abuse testing"
  prohibited_techniques:
    - "denial of service / load testing"
    - "social engineering against employees"
    - "physical access attempts"
  emergency_contact:
    name: "Lead Developer, Mironsoft"
    phone: "+49 30 000000"
    escalation_sla_minutes: 30
  authorization:
    signed_by: "CTO, Client GmbH"
    signature_date: "2026-07-20"
    written_permission_reference: "SOW-2026-0142"

4. Authorization: written permission is mandatory, not optional

Any penetration testing technique performed against systems without prior written authorization is unauthorized access and is a criminal offense in practically every jurisdiction, regardless of good intent. In Germany, this falls under Sections 202a and 202c of the Criminal Code (unauthorized access to and preparation of unauthorized access to data), in the US the Computer Fraud and Abuse Act applies, and comparable laws exist in most other countries. A verbal agreement, an informal Slack message, or the mere assumption that "this should be fine" are not sufficient. What's required is a signed rules-of-engagement or statement-of-work document with an exact scope, a test window, and a signatory who actually has the authority to grant permission for the systems in question, not just any employee.

For infrastructure hosted by a cloud provider, CDN, or SaaS vendor, permission from the client alone is often not enough. Providers like AWS or Azure require a separate advance notification through their own forms for certain types of testing, because shared infrastructure could otherwise be affected. The signed authorization document must also include an emergency contact and clear stop conditions, so testing halts immediately the moment something unexpected happens, such as evidence of an already existing, active breach of the system.

5. Internal security review vs. external pentest

An internal security review carried out by the organization's own development team, consisting of code review, dependency scanning, and threat modeling, is inexpensive, can run continuously, and benefits from deep knowledge of the codebase. The downside lies in blind spots: the same assumptions that caused a bug in the first place often cause reviewers to overlook that exact bug, because nobody is actively thinking against their own architecture.

An external penetration test brings an independent, adversarial mindset and experience across many different codebases and attack patterns that is rarely available internally at that breadth. Compliance frameworks like PCI DSS or ISO 27001, as well as many cyber insurance policies, generally require independent external evidence anyway. The downside is the higher cost and the fact that it's only a point-in-time snapshot. The most sensible combination of both worlds: continuous internal review plus automated scanning as part of everyday operations, complemented by a periodic external pentest before major releases or at least once a year.

The table isn't about competition, but about two complementary layers of quality assurance. Scans cover breadth and run automatically with every deployment, a pentest covers depth and finds exactly the vulnerabilities where automation structurally fails.

6. How development teams prepare for a pentest

Before the actual test begins, a stable, production-like test environment with the same dependencies and versions should be in place, including test accounts for every role named in scope, from an anonymous guest to a restricted admin role. Logging and monitoring must be active so that test activity can later be cleanly reconstructed within the organization's own systems. Freezing non-essential deployments during the test window prevents the scope from shifting under the testers while the engagement is underway.

An internal point of contact with the authority to pause the test immediately in case of a critical live issue should be reachable for the entire duration. At minimum, ops or SRE staff and relevant security stakeholders need to know that an authorized test is running, so that legitimate test traffic isn't mistaken for a real attack and doesn't trigger an unnecessary incident response process.

7. During the test: communication and monitoring

An agreed communication channel with a daily status update and a clear escalation path for critical findings is part of every professional test. Critical findings, such as an actively exploitable remote code execution or an openly accessible customer database, should be reported immediately rather than only in the final report, so the development team can start remediation in parallel instead of staying exposed for days.

Monitoring, WAF, and IDS stay active under normal operation unless explicitly agreed otherwise, since disabling them would hide exactly the real-world resilience the test is meant to evaluate. An exception is pure business logic testing, where blocked requests would only generate unnecessary noise. Every test action on the pentester's side is documented per the rules of engagement and can be cross-referenced against internal logs, so anomalies can quickly be attributed to the authorized test instead of triggering a false alarm.

#!/usr/bin/env bash
# recon.sh - Automated recon strictly within an authorized pentest scope
# This script refuses to run without explicit, written consent references.
set -euo pipefail

readonly SCOPE_FILE="./scope.yaml"
readonly CONSENT_REF="${CONSENT_REF:?Set CONSENT_REF to the signed authorization/SOW reference, e.g. SOW-2026-0142}"
readonly TARGET="${1:?Usage: recon.sh <target-domain>}"

# Hard stop: never proceed without a scope file and a consent reference
if [[ ! -f "$SCOPE_FILE" ]]; then
  echo "[ABORT] No scope.yaml found. Testing without written authorization is illegal." >&2
  exit 1
fi

if ! grep -q "$TARGET" "$SCOPE_FILE"; then
  echo "[ABORT] Target $TARGET is not listed in the authorized scope. Stopping." >&2
  exit 1
fi

echo "[INFO] Authorization reference: $CONSENT_REF"
echo "[INFO] Target confirmed in scope: $TARGET"

mkdir -p "results/$TARGET"

# Passive/low-impact recon only, no exploitation, no load testing
nmap -sV --top-ports 100 -oN "results/$TARGET/nmap.txt" "$TARGET"
curl -sI "https://$TARGET" -o "results/$TARGET/headers.txt"
subfinder -d "$TARGET" -silent -o "results/$TARGET/subdomains.txt"

echo "[DONE] Recon completed within authorized scope for $TARGET"

8. After the test: assessing and prioritizing findings

A good pentest report structures every finding with a severity rating, usually based on CVSS, reproduction steps, evidence, the affected component, and concrete remediation guidance. Development teams should prioritize findings by actual exploitability and business impact, not by CVSS score alone: a finding rated "high" in an internal admin tool with no external exposure may in practice be less urgent than a "medium" finding that's directly reachable from checkout.

Every finding should be assigned a clear owner and a deadline, staggered by severity, for example critical the same day, high within the current sprint, medium in the next release cycle. Findings belong in the same issue tracker as regular bugs, instead of disappearing into a separate PDF that nobody ever opens again. A verified retest should be mandatory for every critical and high finding before it's marked as closed.

{
  "finding_id": "PT-2026-0142-007",
  "engagement_reference": "SOW-2026-0142",
  "title": "IDOR in order detail endpoint allows viewing foreign orders",
  "severity": "high",
  "cvss_v3_1": {
    "vector": "AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
    "score": 6.5
  },
  "affected_component": "Mironsoft_SecurityDemo/Controller/Order/ViewVulnerable.php",
  "test_type": "grey-box",
  "reproduction_steps": [
    "Authenticate as customer A",
    "Request GET /order/view?order_id=<order id belonging to customer B>",
    "Observe full order data of customer B in the response"
  ],
  "evidence_reference": "evidence/PT-2026-0142-007-response.json",
  "business_impact": "Exposure of customer names, addresses and order contents to unauthorized users",
  "remediation": "Verify order ownership against the authenticated customer session before returning data",
  "status": "open",
  "discovered_date": "2026-08-04",
  "retest_required": true
}

9. Remediation, retesting, and continuous security

Fixing only the specifically reported instance of a vulnerability is rarely enough. Teams should deliberately search for the same pattern elsewhere in the codebase, for example by grepping across every controller that handles customer-owned resources when a single controller was found missing an ownership check. A regression test that fails if the vulnerability is reintroduced belongs to the fix just as much as the fix itself.

A retest by the same pentesting firm against the fixed code confirms that the fix actually closes the gap rather than just changing the symptom, and the resulting clean report is often exactly what compliance frameworks and cyber insurance require as evidence. Pentest results belong in the team's long-term security backlog, not in a one-time checkbox for the compliance department. Recurring engagements over several years show whether the number and severity of findings actually trend downward from release to release.

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Acl/etc/acl.xsd">
    <acl>
        <resources>
            <resource id="Magento_Backend::admin">
                <resource id="Mironsoft_SecuritySuite::security" title="Security Suite" sortOrder="200">
                    <!-- Separate, narrowly scoped resource so pentest-related settings
                         are never reachable by default admin roles -->
                    <resource id="Mironsoft_SecuritySuite::pentest_mode"
                              title="Penetration Test Mode"
                              sortOrder="10"/>
                    <resource id="Mironsoft_SecuritySuite::findings"
                              title="Findings Register"
                              sortOrder="20"/>
                </resource>
            </resource>
        </resources>
    </acl>
</config>

10. Summary

Penetration testing fundamentals for development teams come down to a handful of core principles: a pentest is not a substitute for automated vulnerability scans, it's a complementary, manual review that finds business logic flaws and chained vulnerabilities that scanners structurally miss. Black-box, grey-box, and white-box differ in how much knowledge the test team has, with grey-box offering the best compromise between realism and depth for most e-commerce stores. Written authorization with a clear scope, a defined time window, and a genuinely authorized signatory is mandatory, any testing activity without that permission is unauthorized access and a criminal offense.

Internal security review and external pentest aren't mutually exclusive, they complement each other: continuous internal review as part of everyday operations, a periodic external pentest as an independent outside perspective. The real value of a pentest only materializes after the test, when findings are properly prioritized, assigned owners and deadlines, actually fixed, and confirmed through a verified retest, rather than gathering dust as a PDF in a folder.

11. FAQ: Penetration Testing Fundamentals for Development Teams