DEV Community

Arturo Enrique Mata Garcia
Arturo Enrique Mata Garcia

Posted on

More Than Just a Scanner: Architecture of a Self-Hosted DAST Engine for SPAs and CI/CD

#devops #cicd #security #architecture

Traditional DAST tools are often a massive headache for modern development teams: they are slow, tightly coupled to third-party cloud services, and worst of all, completely blind to Single Page Applications (SPAs) built with React, Vue, or Angular where routing and application logic live entirely on the client side.

If you are shipping software fast, you need a tool that speaks your language: a native, portable binary with zero heavy runtime dependencies (no Python or pip required in production) that integrates seamlessly into your CI/CD pipelines to enforce real security gatekeeping.

Meet VORTEX Assessment Engine, developed by Arturo Mata.
Official documentation and interactive diagrams are also available at matarturo.github.io.

If you are a pentester, DevSecOps engineer, or web developer, you have likely suffered through traditional DAST tools. They are sluggish, heavy, and above all, clueless about modern web applications.

SPAs built with React, Vue, or Angular rely almost entirely on JavaScript. Legacy crawlers get lost, fail to discover dynamic routes, and let critical vulnerabilities slip by—alongside exposed frontend secrets.

VORTEX Assessment Engine was built to solve precisely that problem. It is a self-hosted, high-performance DAST engine engineered specifically to evaluate SPAs with a deep focus on JavaScript analysis and native CI/CD pipeline integration.

🔬 Architecture: A Self-Hosted Engine

Unlike commercial SaaS scanners that require shipping your application code to an external cloud, VORTEX runs entirely within your own infrastructure. This guarantees:

  • Privacy: Your target application never leaves your secure perimeter.
  • Total Control: You know exactly where and how the scan execution takes place.
  • Automation-First: Easily embed it into a Bash script or native pipeline step. 
┌───────────────────────────────────┐
│        YOUR INFRASTRUCTURE        │
│                                   │
│   ┌───────────────────────────┐   │
│   │   VORTEX Assessment       │   │
│   │        Engine             │   │
│   └─────────────┬─────────────┘   │
│                 │                 │
│                 ▼                 │
│          WEB APPLICATION          │
│            TARGET                 │
└───────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

🕸️ Why Does VORTEX Understand SPA's?

Conventional DAST scanners rely heavily on static HTML parsing. VORTEX incorporates an SPA-optimized crawler that performs the following actions:

Renders and discovers dynamic routing structures across React, Vue, and Angular applications.

  • Performs deep parsing of JavaScript bundles to hunt down:
  • Exposed API keys
  • Authentication tokens
  • Hardcoded credentials
  • Sensitive internal configuration secrets

🔬 Evaluation Flow

A typical security assessment with VORTEX follows this streamlined execution sequence:

               APLICACIÓN WEB
                     │
                     ▼
            ┌─────────────────┐
            │     VORTEX      │
            │     Crawler     │
            └────────┬────────┘
                     │
                     ▼
           SPA / Route Discovery
                     │
                     ▼
          JavaScript Analysis
                     │
                     ▼
          Security Assessment
                     │
                     ▼
            ┌─────────────────┐
            │    RESULTS      │
            └────────┬────────┘
                     │
            ┌────────┼────────┐
            ▼        ▼        ▼
          HTML      JSON     SARIF
Enter fullscreen mode Exit fullscreen mode

VORTEX fires targeted security tests (SQLi, XSS, Path Traversal, etc.) directly against the discovered surfaces. This rigorous JavaScript inspection uncovers severe flaws that standard black-box scanners routinely miss.

🔬 Real-World Environment Demonstration

⚡ A Native, Frictionless Binary

VORTEX is distributed as a self-contained, native Linux binary. This design delivers distinct performance advantages:

  • Zero requirements for Python, pip, or fragile runtime dependencies.
  • No Node.js engine required on the target execution host.
  • Ultra-lightweight footprint (averaging under 6% CPU utilization and 62 MB of RAM during standard scans).
  • This native portability allows you to spin up VORTEX inside staging servers, auditing workstations, or ephemeral Docker containers without complex setup overhead.

🔌 Native CI/CD Integration

One of the greatest friction points in DevSecOps is integrating security testing without turning pipelines into delivery bottlenecks. VORTEX outputs native SARIF 2.1.0 reports, enabling strict security gatekeeping across popular developer platforms.

GitHub Actions (.github/workflows/security.yml)

YAML
name: VORTEX Security Assessment

on:
  push:
  pull_request:

jobs:
  vortex:
    name: VORTEX Security Scan
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install VORTEX
        run: |
          curl -sSL [https://raw.githubusercontent.com/matarturo/vortex/main/install.sh](https://raw.githubusercontent.com/matarturo/vortex/main/install.sh) | sudo bash

      - name: Run VORTEX
        run: |
          vortex [https://my-app.com](https://my-app.com) --output /opt/vortex/reporte/reporte.sarif

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: /opt/vortex/reporte/reporte.sarif
Enter fullscreen mode Exit fullscreen mode

GitLab CI (.gitlab-ci.yml)

YAML
vortex_security:
  stage: test

  script:
    - curl -sSL [https://raw.githubusercontent.com/matarturo/vortex/main/install.sh](https://raw.githubusercontent.com/matarturo/vortex/main/install.sh) | bash
    - vortex [https://my-app.com](https://my-app.com) --output /opt/vortex/reporte/reporte.sarif

  artifacts:
    when: always
    paths:
      - /opt/vortex/reporte/
Enter fullscreen mode Exit fullscreen mode

Azure DevOps (azure-pipelines.yml)

YAML
steps:
- checkout: self

- script: |
    curl -sSL [https://raw.githubusercontent.com/matarturo/vortex/main/install.sh](https://raw.githubusercontent.com/matarturo/vortex/main/install.sh) | sudo bash
    vortex [https://my-app.com](https://my-app.com) --output /opt/vortex/reporte/reporte.sarif
  displayName: 'VORTEX Security Assessment'

- task: PublishBuildArtifacts@v4
  inputs:
    pathToPublish: '/opt/vortex/reporte'
    artifactName: 'VORTEX-Reports'
  displayName: 'Publish VORTEX Reports'
Enter fullscreen mode Exit fullscreen mode

⚡ Quick Installation

Want to test the VORTEX Community Edition? No credit card is required to get started.

Install on Ubuntu / Debian

curl -sSL -o install.sh [https://raw.githubusercontent.com/matarturo/vortex/main/install.sh](https://raw.githubusercontent.com/matarturo/vortex/main/install.sh)
chmod +x install.sh
sudo ./install.sh
Enter fullscreen mode Exit fullscreen mode

Run Your First Local Assessment

vortex --local --port [PORT_NUMBER]
Enter fullscreen mode Exit fullscreen mode

🔗 Useful Links & Documentation

Conclusion & Call to Action

VORTEX was built to bridge the gap between fast-paced modern software development and offensive security requirements.

Clone the repository, test out the Community edition against your local SPAs, and drop a star on the repo or share your feedback to help drive the project forward. See you in the code!

Top comments (2)

Collapse
 
raknaos profile image
Baptiste Le Bouquin •

The self-hosted angle is what sells this for me. We run a small fleet of headless browser agents on a VPS and every third-party scanner we trialed wanted to ship our URLs through someone else's cloud, which is a non-starter when the whole point is finding the leaks.

Two things from experience that you've clearly thought about but deserve emphasis:

Bundle analysis is criminally underrated as a DAST feature. Most exposed-key incidents I've seen didn't come from misconfigured servers — someone imported a maps/token/panel key client-side and shipped it to prod. Catching that pre-merge in CI beats any runtime scan.

The SPA crawler part is where these tools usually fall apart in practice: client-side routers that rewrite history on scroll, guard-based routes that only render after an auth check, lazy chunks that only load after interaction. Static HTML parsing never sees any of it.

Question: how does VORTEX handle authenticated areas? Behind-login routes are where the interesting bugs usually live, but they're also where scanners either give up or start brute-forcing login forms. We ended up bridging real browser sessions into headless via cookie transfer to get past that — curious whether you'd rather keep VORTEX unauthenticated-only and leave the session problem to CI secrets.

Collapse
 
matarturo profile image
Arturo Enrique Mata Garcia •

Thanks for the detailed analysis, Baptiste! You’re absolutely right on both points: bundle analysis is a goldmine that most people overlook, and SPAs can be a minefield for static crawlers.

Regarding your question, VORTEX supports authenticated areas in two ways:

  1. Command-line credentials

You can provide --username and --password, or use --login-path to configure a custom login endpoint. VORTEX uses Playwright to automate the login flow and maintains the resulting session while exploring protected routes.

  1. External cookies

If you already have a valid authenticated session—for example, from your own headless agent—you can pass the session cookies to VORTEX. This allows the crawler to reuse the session instead of authenticating again. It is particularly useful in corporate environments that rely on MFA or SSO.

For MFA-protected environments, cookie transfer is generally the way to go. VORTEX does not brute-force passwords or perform password-guessing attacks against login forms; it is designed to evaluate authenticated attack surfaces, not to break into accounts.

The workflow is as follows:

  • When the user provides --username and --password, VORTEX attempts to authenticate once in order to explore protected routes.
  • If it discovers exposed credentials—for example, credentials embedded in a JavaScript bundle or configuration file—it reports them as a security finding, such as hard-coded or default credentials. It does not perform dictionary attacks against the login form.
  • VORTEX also supports cookie transfer and --login-path, which help avoid repeated authentication in environments that use MFA or SSO.

For SPAs that authenticate through an API, you can use --login-path and/or provide session cookies. This allows VORTEX to maintain an authenticated session without requiring it to repeat the login process.

These capabilities are included in the Community edition, allowing you to test the complete flow.

Thanks for reading and for sharing your experience! If you have any other questions, feel free to open an issue in the repository.