Pentesting in CI/CD: which releases should trigger a test

Pentesting in CI/CD ties security testing to your release process. You choose which releases need a test, give the tester a staging copy and a list of changes, and retest the fixes. A full pentest on every commit is outside this model.

Excession Labs does not offer automated per-commit testing. We offer recurring testing after releases, with the scope for each round agreed in writing. See per-release testing.

Which releases warrant a pentest?#

A release warrants a test when it changes who can do what, or what data leaves the system. Small copy and style changes do not. Copy this table into your release checklist.

Use the table as a default, then adjust. If you are unsure, ask what an attacker would gain from the change.

Compliance programs may add their own timing. PCI DSS 4.0 requirement 11.4, for example, covers penetration testing methodology (see the PCI SSC summary of changes). Read the text with your assessor. Do not assume a test satisfies a standard.

Why not test every commit?#

A pentest is not a unit test. A pipeline check runs in minutes and has a fixed answer. A pentest needs authorization, a scope, judgment and review of the evidence. Match each check to its job:

• Every commit: unit tests, static analysis, dependency checks, secret scanning.
• Every deploy to staging: smoke tests, authorization regression tests that your team writes.
• After a risky release: a scoped pentest on staging.
• After a fix: a retest of that finding.

Authorization tests that your team writes for CI catch many regressions. A test that logs in as user A and requests user B's record should fail the build if it returns data. The pentest then looks for what those tests missed.

How should you test on staging?#

Test on staging when the risky checks could harm production data. Staging should match production in code, configuration and roles. If it does not, say where it differs. A finding on staging that does not exist in production wastes time, and a clean result on a staging copy with different settings can mislead you.

Prepare four things:

1. A staging URL that matches the release you want tested.
2. Test accounts for each role, plus two accounts in different tenants.
3. Synthetic data, not copies of customer data.
4. A rollback plan and a named contact who can answer during the test.

Written authorization comes first. We test only with written authorization from the system owner. If your staging runs on a cloud or SaaS you do not own, check that provider's rules for security testing before you start.

What is a scope delta and how do you send one?#

A scope delta is the difference between the last tested state and the release to test. It tells the tester where to look first. Your CI/CD system already holds most of it.

Send these items with each request:

• The release tag or commit range.
• New, changed and removed endpoints (an OpenAPI diff works well).
• Changed roles, permissions or feature flags.
• New integrations, webhooks or file handlers.
• Known issues you do not want re-reported.

The tester still checks nearby areas, because a change to one endpoint can break a control on another. The delta focuses effort. It limits the report to the listed items only if the written scope says so.

The OWASP Web Security Testing Guide lists the areas that sit near a change: session management, authorization, input validation and business logic.

How do you retest fixes in the release flow?#

Retest each fix with the same request that proved the finding, plus controls. Excession Labs can retest fixed findings, and Incursion supports retesting a finding. Agree in the written scope whether a retest is free and how long it takes.

A retest answers three questions:

1. Does the original effect still happen? (It should not.)
2. Do the controls still hold? (Nonexistent IDs, another account's token, anonymous callers.)
3. Did the fix open a nearby path? (Same class of check on sibling endpoints.)

Link each fix commit to its finding in your tracker. When the retest passes, close the ticket with the evidence reference. The retesting page on penetrationtestservices.com shows what a retest result looks like.

What does a release flow with pentest triggers look like?#

This flow works for most teams:

1. Merge and deploy to staging. Fast checks run.
2. The release manager checks the trigger table.
3. If a trigger applies, send the scope delta and confirm authorization.
4. The test runs on staging with test accounts.
5. You fix findings. You ask for a retest.
6. You release to production when the high-severity items are fixed or accepted.
7. For a risk that staging cannot show, agree a bounded production check with test-owned data. The production safety guide gives the rules.

For the price drivers of recurring work, see pricing.