GitLab CI/CD

Integrate Strix security testing into your GitLab CI/CD pipelines for automated vulnerability detection

You can integrate Strix into GitLab CI/CD pipelines to automatically run security tests on merge requests, commits, or scheduled intervals. This provides continuous security testing within your GitLab workflow.

Quick Start Pipeline

Here’s a minimal .gitlab-ci.yml configuration that runs Strix on every merge request:

stages:
  - security

strix-scan:
  stage: security
  image: docker:latest
  services:
    - docker:dind
  
  before_script:
    - apk add --no-cache curl bash
    - curl -sSL https://strix.ai/install | bash
  
  script:
    - strix -n -t ./ --scan-mode quick
  
  variables:
    STRIX_LLM: $STRIX_LLM
    LLM_API_KEY: $LLM_API_KEY
  
  only:
    - merge_requests

This pipeline uses Docker-in-Docker (dind) service to run the Strix sandbox container. Ensure Docker is enabled in your GitLab Runner configuration.

Prerequisites

1. Enable Docker support

   Ensure your GitLab Runner has Docker-in-Docker (dind) or Docker socket access enabled.

2. Configure CI/CD variables

   Add these variables in Settings → CI/CD → Variables:

   • STRIX_LLM - Your LLM provider and model (e.g., openai/gpt-5)
   • LLM_API_KEY - Your LLM API key (mark as masked)

   Optionally add:

   • LLM_API_BASE - Custom API endpoint
   • PERPLEXITY_API_KEY - For enhanced search capabilities
3. Get API credentials

   Obtain an API key from your chosen provider:

   • OpenAI for GPT models
   • Anthropic for Claude models
   • Strix Router for multi-provider access

Complete Pipeline Examples

Merge Request Scanning

Scan code changes on every merge request with artifact storage:

stages:
  - security

strix-mr-scan:
  stage: security
  image: docker:latest
  services:
    - docker:dind
  
  before_script:
    - apk add --no-cache curl bash
    - curl -sSL https://strix.ai/install | bash
  
  script:
    - strix -n --target ./ --scan-mode quick
  
  variables:
    STRIX_LLM: $STRIX_LLM
    LLM_API_KEY: $LLM_API_KEY
    STRIX_REASONING_EFFORT: "medium"
    DOCKER_TLS_CERTDIR: "/certs"
  
  artifacts:
    when: always
    paths:
      - strix_runs/
    expire_in: 30 days
  
  only:
    - merge_requests

Scheduled Comprehensive Scans

Run deeper security assessments on a schedule:

stages:
  - security

strix-weekly-audit:
  stage: security
  image: docker:latest
  services:
    - docker:dind
  
  timeout: 2h
  
  before_script:
    - apk add --no-cache curl bash
    - curl -sSL https://strix.ai/install | bash
  
  script:
    - strix -n --target ./
  
  variables:
    STRIX_LLM: $STRIX_LLM
    LLM_API_KEY: $LLM_API_KEY
    PERPLEXITY_API_KEY: $PERPLEXITY_API_KEY
    DOCKER_TLS_CERTDIR: "/certs"
  
  artifacts:
    when: always
    paths:
      - strix_runs/
    expire_in: 90 days
  
  only:
    - schedules

Multi-Stage Pipeline

Integrate Strix into a multi-stage deployment pipeline:

stages:
  - build
  - test
  - security
  - deploy

build:
  stage: build
  script:
    - echo "Building application..."
  # Your build steps

test:
  stage: test
  script:
    - echo "Running tests..."
  # Your test steps

strix-security:
  stage: security
  image: docker:latest
  services:
    - docker:dind
  
  before_script:
    - apk add --no-cache curl bash
    - curl -sSL https://strix.ai/install | bash
  
  script:
    - strix -n --target ./ --scan-mode quick
  
  variables:
    STRIX_LLM: $STRIX_LLM
    LLM_API_KEY: $LLM_API_KEY
    DOCKER_TLS_CERTDIR: "/certs"
  
  artifacts:
    when: always
    paths:
      - strix_runs/
  
  allow_failure: false  # Block deployment if vulnerabilities found
  
  only:
    - main
    - develop

deploy:
  stage: deploy
  script:
    - echo "Deploying application..."
  # Your deployment steps
  only:
    - main

Multi-Target Testing

Test both source code and deployed staging environment:

stages:
  - security

strix-multi-target:
  stage: security
  image: docker:latest
  services:
    - docker:dind
  
  before_script:
    - apk add --no-cache curl bash
    - curl -sSL https://strix.ai/install | bash
  
  script:
    - |
      strix -n \
        -t ./ \
        -t https://staging.your-app.com \
        --scan-mode quick
  
  variables:
    STRIX_LLM: $STRIX_LLM
    LLM_API_KEY: $LLM_API_KEY
    DOCKER_TLS_CERTDIR: "/certs"
  
  only:
    - staging

Authenticated Testing

Perform grey-box testing with credentials:

stages:
  - security

strix-authenticated:
  stage: security
  image: docker:latest
  services:
    - docker:dind
  
  before_script:
    - apk add --no-cache curl bash
    - curl -sSL https://strix.ai/install | bash
  
  script:
    - |
      strix -n \
        --target https://staging.your-app.com \
        --instruction "Perform authenticated testing using credentials: $TEST_USERNAME:$TEST_PASSWORD"
  
  variables:
    STRIX_LLM: $STRIX_LLM
    LLM_API_KEY: $LLM_API_KEY
    TEST_USERNAME: $TEST_USERNAME
    TEST_PASSWORD: $TEST_PASSWORD
    DOCKER_TLS_CERTDIR: "/certs"
  
  when: manual
  only:
    - staging

Runner Configuration

Docker-in-Docker (dind)

The recommended approach uses Docker-in-Docker:

image: docker:latest
services:
  - docker:dind

variables:
  DOCKER_TLS_CERTDIR: "/certs"
  DOCKER_DRIVER: overlay2

Docker Socket Binding

Alternatively, bind the Docker socket (requires privileged runner):

variables:
  DOCKER_HOST: unix:///var/run/docker.sock

before_script:
  - apk add --no-cache docker-cli

Binding the Docker socket requires a privileged runner and may have security implications. Use Docker-in-Docker when possible.

Pipeline Configuration Options

Timeout Settings

Set appropriate timeouts based on your scan depth:

strix-scan:
  timeout: 1h  # Options: 30m, 1h, 2h

• Quick scans: 30 minutes
• Standard scans: 1 hour
• Comprehensive scans: 2 hours

Environment Variables

Basic Configuration

variables:
  STRIX_LLM: $STRIX_LLM
  LLM_API_KEY: $LLM_API_KEY
  DOCKER_TLS_CERTDIR: "/certs"

Handling Results

Artifacts Configuration

Save scan results as pipeline artifacts:

artifacts:
  when: always  # Save even if job fails
  paths:
    - strix_runs/
  expire_in: 30 days
  reports:
    dotenv: strix_runs/.env  # Optional: export variables

Conditional Failure

Control whether vulnerabilities block the pipeline:

strix-scan:
  # ... other configuration ...
  
  allow_failure: false  # Block pipeline on vulnerabilities
  # or
  allow_failure: true   # Continue pipeline, but mark as warning

Optimization Tips

1. Use quick scan mode for MRs

   Enable --scan-mode quick for faster merge request feedback:

   script:
     - strix -n --target ./ --scan-mode quick
   
2. Adjust reasoning effort

   Set STRIX_REASONING_EFFORT="medium" for faster CI/CD runs:

   variables:
     STRIX_REASONING_EFFORT: "medium"
   
3. Cache Docker images

   Enable Docker layer caching to speed up image pulls:

   variables:
     DOCKER_DRIVER: overlay2
   
4. Separate quick and deep scans

   Use quick scans for merge requests and scheduled jobs for comprehensive testing:

   only:
     - merge_requests  # Quick scan
     - schedules       # Comprehensive scan
   

Troubleshooting

Docker Permission Issues

If you encounter Docker permission errors:

variables:
  DOCKER_TLS_CERTDIR: "/certs"
  FF_NETWORK_PER_BUILD: 1

Runner Compatibility

Ensure your GitLab Runner supports Docker:

# /etc/gitlab-runner/config.toml
[[runners]]
  executor = "docker"
  [runners.docker]
    privileged = true
    volumes = ["/certs/client", "/cache"]

Memory Limits

For large scans, increase memory limits:

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_MEMORY: "4g"

Installation Failures

If the installation script fails:

before_script:
  - apk add --no-cache curl bash ca-certificates
  - curl -sSL https://strix.ai/install | bash
  - export PATH="$HOME/.strix/bin:$PATH"

Security Best Practices

Always mark sensitive variables as “Masked” and “Protected” in GitLab CI/CD settings to prevent exposure in logs.

• Protect variables - Mark API keys as masked and protected
• Limit scope - Only scan authorized targets
• Use protected branches - Run comprehensive scans only on protected branches
• Review findings - Set up notifications for security findings
• Rotate credentials - Regularly rotate API keys

Next Steps

• Review GitHub Actions integration for comparison
• Learn about Docker configuration for custom sandbox setups
• Explore CLI options for advanced configuration