On this page
Automation on every build, people on every release
Scanners and static analysis belong in the pipeline: they are fast, cheap and catch known patterns. They do not understand your roles, tenants or business rules, which is where serious findings live. Continuous penetration testing adds people at the point that matters, the release, and keeps them focused on the change.
How a release-triggered test works
- A release goes out. Your pipeline deploys a new version, and the release is flagged in the PTaaS platform, for example a GitHub Actions notice that v2.14 reached production.
- You request a test the day you ship. Choose a release test for the new features, a full application pentest, or a pipeline and cloud review covering CI/CD, containers, Kubernetes and infrastructure as code.
- Testers work on the change. Authorisation is already on file, so testing starts straight away on new endpoints, roles and flows.
- Findings flow to the backlog. Each verified finding is published with evidence and fix guidance and sent to Jira or GitHub.
- The fix ships, the retest follows. You request a retest with a note on what changed; the tester verifies it with before-and-after evidence.
What to test on each release
- New or changed API endpoints and their authorisation checks
- New roles, permissions or admin functions
- Changes to login, password reset, MFA or session handling
- Payment, pricing, approval or other business-logic changes
- New third-party integrations, webhooks and file uploads
- Anything that changes how one customer’s data is separated from another’s
Testing the pipeline itself
The delivery chain is part of the attack surface. A compromised runner or leaked deploy key reaches production faster than any application bug.
- CI/CD pipelines
- Who can trigger which job, fork pull requests that can read secrets, self-hosted runner isolation.
- Secrets
- Credentials in build logs, environment variables and git history.
- Containers
- Base images, root users, exposed ports and image provenance.
- Kubernetes
- RBAC, service accounts, network policies, pod security and the API server.
- Infrastructure as code
- Terraform, CloudFormation and Helm reviewed before they reach production.
Our cloud penetration testing guide covers AWS, Azure and GCP in more depth.
Keeping it audit-ready
Each test cycle produces a dated, scoped and retested report, so continuous testing doubles as continuous evidence for SOC 2, ISO 27001 and buyer reviews. See what PTaaS is, how it compares in PTaaS vs traditional penetration testing, and the PTaaS platform features that matter.
Watch a release test from start to finish
The walkthrough on the continuous penetration testing page shows a release test, a finding sent to Jira and a verified retest. Get a quote for your pipeline.
Frequently asked questions
Can penetration testing be part of a CI/CD pipeline?
Yes. Automated security checks can run on every build, and expert penetration testing can be triggered by releases: when a version reaches production or staging, a release test is requested and testers focus on what changed.
What should be tested on each release?
New and changed endpoints, new roles or permissions, changes to authentication or payment flows, new integrations and any change to how tenants are separated. Full application tests then run on a regular cycle.
Does continuous penetration testing slow down deployments?
No. Release tests run alongside the release rather than blocking it, and findings arrive in the platform and in Jira or GitHub as they are verified, so teams fix them in the normal flow of work.
What is pipeline security testing?
A review of the CI/CD system itself: pipeline permissions, runners, secrets handling, pull requests from forks, build integrity, container images, Kubernetes configuration and infrastructure as code.
Faisal Khan is a Director at Sumrite, where he oversees penetration testing, risk assessment and compliance engagements for SaaS and enterprise clients. Case studies are anonymised and published with client permission.
