Continuous AI Runtime Verification

WhiteHaX AI-DAST for CI/CD pipelines

Add WhiteHaX AI-DAST to GitHub Actions or GitLab CI/CD so deployed AI applications are tested at runtime before risk reaches production. The pipeline complements SAST by validating the live AI endpoint, collecting evidence, and feeding remediation back into the next code update.

View Pipeline Review Integration Details
CI/CDGitHub Actions and GitLab CI/CD ready
REST APIAutomated scan trigger and result retrieval
EvidenceSARIF or GitLab DAST report artifacts
WhiteHaX AI-DAST GitHub CI/CD pipeline flow
Why DevOps Buyers Should deploy AI Behavioral DAST

Runtime AI security validation without rebuilding the delivery pipeline

WhiteHaX AI-DAST enhances AI AppSec for teams that already run CI/CD and release gates, with runtime verification for LLM, RAG, agentic AI, and AI App deployments.

1

Catch runtime AI failure modes

Test deployed AI behavior for prompt injection, jailbreaks, data leakage, abuse patterns, behavioral threats, response-time issues, AI-speicfic DoS and cost-amplification risks.

2

Keep existing SAST gates

Continue to run SAST on code push, pull request, or merge request. WhiteHaX AI-DAST starts after the runtime deployment target is updated.

3

Produce CI-native reports

Publish findings in the format each DevOps platform understands: GitHub code scanning through SARIF, or GitLab native DAST JSON artifacts.

Pipeline Model

SAST first, AI-DAST after deployment, fixes loop back to code

The operatal flow is straightforward: analyze code early, fix code findings, deploy only when the SAST gate is clean enough, run WhiteHaX AI-DAST against the runtime target, then feed runtime findings into the next development cycle.

GitHub Actions Pipeline SARIF to code scanning
GitHub CI/CD validation flow with SAST, WhiteHaX DAST, analysis, and remediation loops
Trigger WhiteHaX AI-DAST after a successful runtime deployment. Use deployment_status.environment_url for AWS or other cloud deployments that publish a reachable environment URL.
GitLab CI/CD Pipeline gl-dast-report.json
GitLab CI/CD validation flow with SAST, WhiteHaX DAST, analysis, and remediation loops
Run WhiteHaX AI-DAST as a post-deploy security-verification stage. Pass the deployed runtime URL explicitly through dotenv, CI/CD variables, or environment context.
Technical Scope

High-level architecture for an AI-DAST gate

The CI job is intentionally small. It retrieves the runtime target URL, calls a Python bridge script, uses WhiteHaX REST API credentials to trigger or retrieve scan results, then writes a CI-native report artifact.

WhiteHaX API credentials are stored as CI secrets or protected CI/CD variables.
Runtime target URL is supplied by the deployment event, environment URL, dotenv artifact, or explicit variable.
The Python bridge keeps WhiteHaX REST API calls isolated from pipeline YAML.
Findings are converted into the platform-native security report format.
Critical findings can be configured as a reporting signal or a release-blocking gate.

Reusable integration

InputsWHITEHAX_URL, WHITEHAX_API_KEY, TARGET_URL or CI_ENVIRONMENT_URL.
ExecutionPython script calls WhiteHaX REST API and normalizes findings.
GitHub Outputwhitehax_results.sarif uploaded with github/codeql-action/upload-sarif.
GitLab Outputgl-dast-report.json declared under artifacts:reports:dast.
Target ModeAWS deployment status only applies when the runtime server is in AWS.
Local RuntimeUse a self-hosted runner, reachable staging endpoint, VPN path, or controlled tunnel.
Platform Integrations

GitHub and GitLab use different report mechanics

The WhiteHaX scan logic can be reused, but the pipeline report output need to match the DevOps platform.

GitHub Actions SARIF

  • Trigger after a successful deployment_status event when the deployed target URL is available.
  • Pass WHITEHAX_URL, WHITEHAX_API_KEY, and TARGET_URL through the Actions environment.
  • Write whitehax_results.sarif at the workspace root.
  • Upload findings with github/codeql-action/upload-sarif@v3.
  • Use if: always() plus a file-exists check so scan failures still surface diagnostics when a report is produced.
permissions: security-events: write, contents: read

GitLab CI/CD DAST JSON

  • Run the job as a post-deploy security-verification stage or as an explicitly triggered pipeline.
  • Pass the runtime URL through WHITEHAX_TARGET_URL, TARGET_URL, or CI_ENVIRONMENT_URL.
  • Write gl-dast-report.json at the workspace root.
  • Declare the result with artifacts:reports:dast.
  • Use the correct predefined variable CI_PIPELINE_SOURCE when writing pipeline rules.
artifacts: reports: dast: gl-dast-report.json
Runtime target rule: AWS deployment status checks only apply when the runtime server is actually deployed in AWS and exposes a reachable environment URL. For local or private targets, the runner must be able to reach the target; localhost in a hosted runner means the runner itself, not a developer workstation.
Purchasing Case

What the buyer gets

For a DevOps purchasing owner, the business case here is not a standalone scanner. It is a repeatable release-control mechanism for AI applications that immediately fits into existing development pipelines and creates audit-ready reports.

Substantially reduce release risk

Validate the running AI service before production exposure, especially for RAG, agents, copilots, AI APIs, and document-ingestion workflows.

No process disruption

Adopt as a CI/CD job using existing secrets, runners, stages, and artifact handling rather than introducing a separate manual process.

Better accountability

Make AI runtime security findings visible in the same DevOps systems used for code security, release status, and remediation ownership.

WhiteHaX AI-ASM Context

AI-native behavioral testing above & beyond traditional web DAST

WhiteHaX AI-ASM is designed for AI deployments, including public chatbots, internal copilots, AI search and retrieval, code assistants, content generation systems, AI APIs, and agentic/RAG applications.

Relevant AI-DAST test areas

Prompt injections, jailbreak, model-hijacking attempts, beahavioral threats and state-full attacks.
Confidential data, PII, and compliance leakage probes.
Malicious document upload and RAG manipulation scenarios.
AI specific denial-of-service (DoS), cost or resource amplification, slowloris and rate-limit bypass.
LLM API abuse, misuse, API key manipulation and other subversion attempts.
MCP Server abuse, MCP DoS and other manipulation scenarios.
Response-time, performance, and resilience checks for deployed AI endpoints.

Ready to evaluate WhiteHaX AI-DAST in your pipeline?

Start with a staging runtime target, connect GitHub or GitLab, and decide whether findings are report-only or release-blocking.

Request Trial