Skip to Content
PlatformUse CasesPre-Production Scanning

Pre-Production Scanning

Detectify can be integrated into your CI/CD pipeline to test applications in staging environments before deployment to production. This enables security teams and developers to catch vulnerabilities early, when they are cheapest to fix.

Why Scan Before Production

Vulnerabilities found in production require urgent remediation under pressure. The same vulnerability found in a staging environment can be fixed as part of the normal development workflow before any users are affected.

Pre-production scanning helps teams:

  • Prevent vulnerable code from reaching production — Block deployments that introduce critical vulnerabilities
  • Reduce remediation costs — Fix issues during development rather than in emergency production patches
  • Shift security left — Make security testing a standard part of the development lifecycle
  • Build developer confidence — Developers get feedback on security issues alongside functional testing

Integration Approaches

API-Triggered Scans

Use the Detectify REST API to start scans as part of your CI/CD pipeline. A typical workflow:

  1. Code is merged and deployed to a staging environment
  2. The CI/CD pipeline calls the Detectify API to start a scan against the staging URL
  3. The pipeline polls the scan status API until the scan completes
  4. The pipeline retrieves findings and evaluates them against defined policies
  5. The deployment is approved or blocked based on the results

This approach works with any CI/CD platform that can make HTTP requests: GitHub Actions, GitLab CI, Jenkins, Azure DevOps, CircleCI, and others.

Internal Scanning Agent for Staging Environments

If your staging environment is not publicly accessible, deploy the Internal Scanning agent in your staging infrastructure. The agent can scan applications that are only reachable from within your private network, and results flow through the same API and dashboard.

This approach is particularly useful for:

  • Staging environments behind VPNs
  • Applications running on private Kubernetes clusters
  • Services in isolated network segments

Scan Profiles for Staging

Configure dedicated scan profiles for your staging environments with settings optimized for CI/CD:

  • Faster scan completion — Use targeted module sets rather than full scans
  • Staging-specific authentication — Configure credentials for your staging environment
  • Appropriate rate limits — Staging environments may have different capacity than production

Deployment Gates

A deployment gate is a policy that determines whether a deployment should proceed based on scan results. Common gate policies include:

  • Block on critical findings — Halt deployment if any critical-severity vulnerability is found
  • Block on high and above — Halt deployment for high or critical findings
  • Warn only — Log findings without blocking deployment, useful during initial rollout
  • Custom policies — Block based on specific vulnerability types (for example, always block on SQL injection)

Implement deployment gates by checking the scan results API response against your policy in your CI/CD pipeline script.

Example: GitHub Actions Workflow

A simplified example of integrating Detectify into a GitHub Actions deployment pipeline:

  1. Define a workflow that triggers after deployment to staging
  2. Use the Detectify API to create and start a scan
  3. Poll the scan status endpoint until completion
  4. Fetch findings and check against your severity threshold
  5. Pass or fail the workflow step based on results

Refer to the Detectify REST API documentation for endpoint details and authentication.

Best Practices

  • Start in warning mode — Begin with non-blocking deployment gates while you tune scan profiles and address existing vulnerabilities
  • Use targeted scans — Run focused module sets in CI/CD to reduce scan time. Save comprehensive scans for scheduled runs
  • Dedicate staging credentials — Use separate scan credentials for staging to avoid interfering with production sessions
  • Set reasonable timeouts — Define maximum scan durations that fit within your deployment pipeline SLAs
  • Track baseline findings — Distinguish between pre-existing vulnerabilities and newly introduced ones

Next Steps

Last updated on