# Pentesting in CI/CD: which releases should trigger a test Source: https://aipentestservices.com/guides/pentesting-in-ci-cd/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Pentesting in CI/CD: which releases need a test, how to test on staging, how to send scope deltas and how to retest fixes. Includes a release trigger table. > **Short answer:** Do not run a pentest on every commit. Test after releases that change authentication, authorization, data access, payments, file handling or public API surface. Use a staging copy with test accounts, send the tester a scope delta for each release, and retest fixes. Excession Labs offers recurring testing after releases, with scope agreed in writing. 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](/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. > **CI/CD trigger decision table:** | What changed in the release | Test? | What to hand the tester | > |---|---|---| > | Login, sessions, password reset, MFA, SSO | Yes | Changed flows, test accounts per role | > | Roles, permissions, tenant or org logic | Yes | Role matrix, new and changed endpoints | > | New or changed API endpoints that read or write user data | Yes | OpenAPI diff, auth requirements | > | Payments, billing, plans, entitlements | Yes | Test mode details, price and plan list | > | File upload, import, export, webhooks | Yes | Limits, allowed types, target hosts | > | New third-party integration with data flow | Yes | What data goes out, which keys are used | > | Infrastructure or gateway change (CORS, headers, WAF) | Yes, small | The config diff | > | Dependency update with no behavior change | Usually no | Rely on dependency scanning | > | UI text, styling, internal refactor with tests passing | No | Nothing | > | Hotfix for a known security bug | Retest only | The finding ID and the fix commit | 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](https://listings.pcisecuritystandards.org/documents/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r1.pdf)). 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](https://wstg.owasp.org/) 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](https://penetrationtestservices.com/retesting/) 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](/guides/is-ai-pentesting-safe-in-production/) gives the rules. For the price drivers of recurring work, see [pricing](/pricing/). ## Questions ### Can I run an AI pentest on every pull request? We do not offer automated per-commit testing. Use fast checks, such as tests and static analysis, on each commit. Use a pentest for releases that change risk. A scoped test needs written authorization and review of the evidence. ### Should I test staging or production? Prefer staging for risky or destructive checks. Use production only when staging differs too much from it. Production tests use test-owned accounts and data, with bounded tests and stop conditions. ### What is a scope delta? A scope delta is the list of what changed since the last test: new endpoints, changed roles, new integrations and removed controls. It lets the tester focus on the change, not on the whole app again. ### How do I know a fix worked? Retest the finding with the same request that proved it, plus controls. A fix is confirmed when the original effect no longer occurs and the working protections still hold. ## Sources - [OWASP Web Security Testing Guide](https://wstg.owasp.org/) - [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment (2008, final)](https://csrc.nist.gov/pubs/sp/800/115/final) - [PCI SSC: PCI DSS v3.2.1 to v4.0 Summary of Changes (requirement 11.4)](https://listings.pcisecuritystandards.org/documents/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r1.pdf)