Use Cases

The GitLab CI/CD integration supports different workflows depending on when and how you want to run security scans. Choose the approach that fits your development process.

Scan on Every Push

Automatically scan every code change to catch vulnerabilities early in development.

Best for:

• Teams practicing continuous integration
• Early detection of security issues
• Fast feedback loops for developers

How it works:

Code Push → Pipeline Starts → Security Scan → Results in MR

Configuration:

security-scan:
  rules:
    # Run on every merge request
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    # Run on every push to main
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Considerations:

• Scans run frequently, ensure your scanner can handle the load
• Use shorter scan profiles for faster feedback
• Consider guardrails to automatically block risky merges

Scan Release Candidates

Scan applications after deploying to a staging environment before promoting to production. This approach validates the actual deployed application rather than just the code.

Best for:

• Teams with staging/pre-production environments
• Validating deployed applications (not just code)
• Release gate decisions
• Compliance requirements

How it works:

Deploy to Staging → Security Scan → Review Results → Decide to Promote

Configuration:

stages:
  - build
  - deploy-staging
  - security-scan
  - approve
  - deploy-production
 
deploy-staging:
  stage: deploy-staging
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com
 
security-scan:
  stage: security-scan
  needs: ["deploy-staging"]
  # ... scan configuration ...
  # Point SCAN_PROFILE_TOKEN to your staging environment profile
 
approve-release:
  stage: approve
  needs: ["security-scan"]
  script:
    - echo "Release approved"
  when: manual  # Manual gate after reviewing scan results
 
deploy-production:
  stage: deploy-production
  needs: ["approve-release"]
  script:
    - ./deploy.sh production
  environment:
    name: production

Considerations:

• Scans the actual deployed application with real configuration
• Longer scan times are acceptable since this is a release gate
• Review results manually before promoting to production
• Can use guardrails to automatically block promotion

On-Demand Trigger

Add a button in the GitLab pipeline UI to trigger scans when needed, in addition to automatic triggers.

Best for:

• Ad-hoc security assessments
• Pre-release verification
• Investigating specific concerns

Configuration:

Add a manual trigger alongside your automatic rules:

security-scan:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_PIPELINE_SOURCE == "web"
      when: manual  # Also allow on-demand trigger from GitLab UI

Combining Approaches

Most teams benefit from combining pipeline-triggered scans with scheduled scans configured in the Detectify Platform:

Example multi-approach configuration:

# Fast scan on merge requests
security-scan-mr:
  extends: .security-scan-base
  variables:
    SCAN_PROFILE_TOKEN: $QUICK_SCAN_TOKEN  # Lighter scan profile
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 
# Thorough scan on release candidates
security-scan-release:
  extends: .security-scan-base
  variables:
    SCAN_PROFILE_TOKEN: $FULL_SCAN_TOKEN  # Comprehensive scan profile
  rules:
    - if: $CI_COMMIT_TAG  # Run on tagged releases

Next Steps

• Configuration Reference - All available options
• Guardrails - Optional: Automatically block pipelines based on findings