Quick start

This walkthrough takes you from a fresh machine to a completed scan in under five minutes.

1. 1

   Install VirtualSpace AppSec

   Download the installer from your order confirmation or the VirtualSpace website. Run the setup and follow the prompts. The application installs to your local machine with all dependencies bundled.

   InstallationCopy

   // Run the installer
   VirtualSpace-AppSec-Setup.exe

2. 2

   Activate your license

   Launch the application. On first run you will be prompted to enter your license key from your order confirmation email. The license is node-locked to your machine.

3. 3

   Run your first scan

   In the Dashboard panel, click Browse to select a source folder you own or are authorized to review. Then click Run Analysis in the header bar. The scan modal will show real-time progress as each analysis phase completes.

System requirements

VirtualSpace AppSec runs as a native Windows desktop application. The installer bundles all required runtimes and dependencies.

Operating systems

Hardware

The scan engine is multi-threaded and benefits from additional CPU cores during Deep scans. Memory pressure is the dominant factor when scanning large source projects.

Runtime dependencies

The installer ships every runtime it needs. The Visual C++ Redistributable and all other dependencies are bundled into the application. No additional software installation is required.

Installation

VirtualSpace AppSec is distributed as a self-contained Windows installer. The installer bundles all dependencies, registers the application, and creates a desktop shortcut.

Windows installation

Download the installer from the VirtualSpace website or your order confirmation email.

// Run the installer with progress UI
Start-Process 'VirtualSpace-AppSec-Setup.exe' -Wait

// Silent install, no UI, log to file
VirtualSpace-AppSec-Setup.exe /S /D="C:\Program Files\VirtualSpace"

// Extract the portable ZIP and run directly
Expand-Archive VirtualSpace-AppSec-portable.zip -DestinationPath C:\Tools\VirtualSpace
Start-Process C:\Tools\VirtualSpace\VirtualSpaceAppSec.exe

Installation layout

After installation the application is structured as follows. The data directory stores license files, scan cache, and intermediate results.

License activation

VirtualSpace AppSec uses a license-based activation model. Each license is node-locked to a single machine. The client sends a hashed machine fingerprint and the license key over HTTPS during activation. No source code or scan results are transmitted.

Activating your license

On first launch, enter the license key provided with your purchase. The application validates the key against the license server and caches the activation locally. After successful activation, the license file is stored in %PROGRAMDATA%\VirtualSpace\license.dat.

Deactivation

To transfer a license to a different machine, deactivate on the current machine first. If the current machine is no longer accessible, contact support to release the seat manually.

Your first scan

This walkthrough runs a scan through the application GUI and explains the output. If you have not yet installed the application, see Installation first.

Loading a target

Open the application. In the Dashboard panel you will see the source-path selector at the top. Click Browse and select a source folder you own or are authorized to review. The application loads the project and displays the detected languages and file count in the status bar.

Running the analysis

With a target loaded, click Run Analysis in the header bar. A modal appears showing real-time progress as the scanner moves through each phase. The progress log displays each analysis step with colour-coded status indicators. Warnings about detected vulnerabilities appear inline as they are found.

Reading the results

When the scan completes, results populate across the application panels:

• Dashboard. Severity counter cards (Critical, High, Medium, Low), a security score circle (0 to 100), and a list of recent scans.
• Findings. Aggregated list of all detected issues with severity badges, descriptions, and code locations. Filterable by severity level.
• Insights. Compliance posture, trend analysis across consecutive scans, and a prioritised remediation queue.

Architecture

The VirtualSpace AppSec scanner is a six-stage pipeline. Every stage runs locally on the scan host, including the AI classifier. The only network call in the entire pipeline is the license validation in stage one, and it carries a hashed machine fingerprint and your license key.

Pipeline stages

Each stage is described in detail below. Stages run sequentially; the output of one stage is the input to the next.

1. Source discovery. Walks the selected project folder, identifies supported source files, and parses each file into an abstract syntax tree.
2. Language detection. Identifies each file's language from its extension and contents so the right language-specific rule set is applied.
3. Pattern scan. Applies the active rule pack against the parsed source. Each rule is a YARA-like pattern annotated with severity, CWE mapping, and a remediation hint.
4. Heuristic flow. Builds a data-flow graph from the source and identifies dangerous patterns that span multiple functions. For example, tainted user input flowing into a sink without sanitisation.
5. AI classifier. Findings from stages three and four are scored by the bundled language model. The model runs locally and is purpose-built for security pattern recognition. Low-confidence findings are dropped; high-confidence findings are ranked.
6. Aggregator. Deduplicates overlapping findings (the same root cause flagged by multiple rules) and emits the final report.

Language detection

Language is identified per source file, by file extension and source content, so that the right language-specific rule set applies to each file. VirtualSpace determines the language during stage two of the pipeline so subsequent stages can apply the correct rules.

Detection signals

The detector combines four classes of signal. No single signal is sufficient. High-confidence detection requires agreement across at least three.

• File extension. The file's extension is the first signal: .c and .cpp indicate C/C++, .py indicates Python, .js and .ts indicate JavaScript/TypeScript, and .cs indicates .NET.
• Language syntax and keywords. Language-specific syntax and keywords in the file body confirm the language, for example def and import for Python, using and namespace for .NET.
• Import and include statements. The #include, import, require, and using statements in the source reveal both the language and the libraries each file depends on.
• Project manifest files. Manifest files in the project root, such as package.json, requirements.txt, .csproj, and CMakeLists.txt, identify the language family at the project level.

Supported languages

Automatic detection

When a source folder is loaded via the Browse button, the application automatically detects each file's language from its extension and contents. The detected languages are displayed in the scan progress log and determine which language-specific vulnerability rules are applied.

The scan engine

The scan engine is the heart of the product. It is implemented as a pipeline of independent analysers that each take the parsed source as input and emit a list of candidate findings. The aggregator then deduplicates, ranks, and triages those candidates into the final report.

Analysers

VirtualSpace ships thirty-two analysers, grouped into four families. Custom analysers can be added through the rule pack format described under Custom rules.

Confidence model

Every finding carries a confidence score between 0.0 and 1.0. The score represents the AI classifier's estimate of the probability that the finding is a true positive. By default, only findings with a confidence above 0.6 are surfaced. This threshold can be adjusted in the Scan Settings panel.

Scan depths

VirtualSpace offers three scan depths. Each depth runs a different subset of the analyser pipeline and represents a different trade-off between completeness and elapsed time. Choose the depth that matches your stage in the development lifecycle.

Comparison

Severity model

VirtualSpace assigns one of four severity levels to every finding. Severity is determined by the rule that fired, modulated by the AI classifier's confidence and by environmental context. For example, a finding in internet-facing code is upgraded one level versus the same finding in an internal tool.

Security score

The summary panel reports a security score on a 0-100 scale. The score is derived from the number and severity of findings, weighted by confidence. Critical findings have the largest impact on the score.

Dashboard

The Dashboard is the landing panel and primary control surface. It contains the target selector, severity counters, a security score visualisation, and a list of recent scans.

Target selector

The source-path selector sits at the top of the Dashboard. Click Browse to open a folder dialog and select a source project you own or are authorized to review. The status bar updates to confirm the source path is loaded.

Severity counters

Four metric cards display the count of findings by severity: Critical, High, Medium, and Info / Low. These update in real time as the scan progresses and reflect the final tally when the scan completes.

Security score

The security score is a value from 0 to 100 displayed as a radial gauge. It is computed from a weighted sum of findings by severity, clamped to the 0-100 range. Higher severity findings have a larger impact on the score.

Recent scans

The recent scans list shows previously scanned projects with their date, time, and severity badge breakdown. This provides at-a-glance historical context without leaving the Dashboard.

Code Review

The Code Review panel performs AI-assisted static analysis on source code. The analyzer is a purpose-built language model that ships with the installer and runs entirely on your machine. It is designed exclusively for vulnerability detection, taint analysis, and remediation guidance, so it has a small footprint and does not require GPU hardware. No code submitted through this panel ever leaves your device.

The panel offers two modes, selectable via the tab bar at the top.

Snippet mode

The Snippet panel contains the source-input editor. Paste source code into the editor area. Supported languages are indicated by the badges above the editor: C/C++, Python, .NET, and JavaScript/TypeScript. The line counter at the top right displays current usage against the 1,000-line limit per submission. The 1,000-line ceiling is per submission, not per session. There is no limit on how many submissions you make.

Running analysis

Click Run Analysis to process the code with the local engine. The analyzer processes the snippet and returns structured findings with severity ratings, descriptions, code locations, CWE classification, and recommended fixes. Use Clear to reset the editor for a new local analysis.

Analysis results

Results appear below the editor with the same severity badge format used throughout the application. Each finding card shows a title, severity level, CWE pill, line number, the offending snippet, and a remediation recommendation.

Project mode & local agents

Project mode in the Code Review panel scans an entire source tree, not a single snippet. It is the closest analog to running an automated security review across a repository. Switch to it from the tab bar at the top of the Code Review panel.

Selecting a folder

Click Select folder in the Project source card. A native folder picker opens. Choose the repository root or any subfolder. The scanner walks the tree, indexing supported source files while skipping vendor and build directories.

Skipped directories

To keep the scan fast and noise-free, the indexer skips well-known directories that contain third-party code, build artifacts, or virtual environments.

• .git, .hg, .svn
• node_modules, vendor, bin, obj
• __pycache__, .venv, venv, env
• dist, build, target, .next, .cache
• .idea, .vscode

Files larger than 2 MB are skipped. Folder traversal is capped at depth 8 and 800 files per scan to keep wall-clock time predictable on large monorepos.

Supported file types

The indexer accepts the following extensions. Each file is dispatched to the agent that handles its language family.

Local agents

Four agents run in parallel across the indexed source tree. Each agent owns a detection family and writes findings into the shared results panel.

• Pattern Agent. Walks the syntax tree and matches against 142 rule signatures spanning OWASP Top 10 (2025), CWE/SANS Top 25, and PCI DSS.
• Taint Agent. Traces user input from sources (request handlers, file readers, network sockets) to dangerous sinks (SQL queries, command execution, output rendering) and flags any path that lacks sanitization.
• Crypto Agent. Inspects cryptographic primitives, key handling, and PRNG use. Flags deprecated ciphers (DES, RC4, MD5, SHA-1), insecure modes (ECB), hardcoded IVs, and weak seeding.
• Secrets Agent. Entropy scan plus format detectors for embedded API keys, tokens, database passwords, and connection strings. Distinguishes real secrets from high-entropy false positives.

Running the scan

Click Run local agents. The agent dots turn green and pulse to indicate active work. As findings land, they appear in the Project findings list below, sorted by severity. Each finding shows the file path, line number, CWE ID, the offending source line, and a remediation recommendation.

Reading results

Results are sorted by severity, then by file path. Each finding includes:

• Title and severity badge
• CWE classification pill
• Relative file path with line number
• The exact source line that triggered the detection
• Plain-language description of the vulnerability
• Concrete remediation recommendation

Detection Modules

The Detection Modules panel controls which detection modules are active during source analysis passes. Each module targets a specific vulnerability class and can be toggled independently.

Detection modules

The first six modules are enabled by default. Supply Chain Failures ships disabled and can be enabled per scan. Disabling a module excludes its findings from the scan results entirely, which is useful for narrowing scope when auditing a specific vulnerability class.

Findings

The Findings panel aggregates all detected security issues from the most recent scan into a single, filterable list with CWE classification and remediation context.

Severity filters

The filter bar at the top provides buttons for All, Critical, High, Medium, and Low. Clicking a filter shows only findings at that severity level. Each finding card displays a title, severity badge, description, and a code location string identifying the function or offset where the issue was detected.

CLI loader

VirtualSpace AppSec ships with a command-line interface (vsappsec) for terminal-driven scans and CI/CD pipelines. The CLI is a thin wrapper around the same local engine the desktop GUI uses. There is no separate code path, no separate license, and no cloud component.

The CLI is the recommended integration point for build-time security gates. It runs entirely locally, returns standard exit codes for pipeline use, and emits SARIF 2.1.0 for ingestion into GitHub Code Scanning, GitLab Security Dashboards, Azure DevOps, and any other SARIF-aware platform.

Basic invocation

// Scan a single source file
vsappsec scan ./src/auth_service.py

// Scan a project folder (Project mode equivalent)
vsappsec scan ./src --depth=deep --rules=owasp,cwe,pci

// Emit SARIF for CI ingestion
vsappsec scan ./src --format=sarif --output ./reports/findings.sarif

// Fail the build if any critical finding is reported
vsappsec scan ./src --fail-on=critical

Loader output

When invoked interactively, vsappsec scan prints a colored progress trace with millisecond timestamps, an INFO / PASS / WARN / FAIL level tag, the message, and an optional CWE / severity annotation. Findings are emitted inline as they are detected so the trace doubles as a live audit log.

Exit codes

The --fail-on flag controls which severity levels cause a non-zero exit code, making the CLI usable as a build gate.

Security Insights

The Insights panel provides contextual recommendations and prioritised remediation guidance based on scan results. It contains three cards:

• Compliance Posture. Maps scan results against OWASP Top 10 (2025) and CWE/SANS Top 25 to identify coverage gaps and compliance status.
• Trend Analysis. Historical severity distribution and regression tracking populate after consecutive scans of the same target, enabling week-over-week comparisons.
• Priority Remediation. A weighted remediation queue based on exploitability, blast radius, and fix complexity. Critical findings are always listed first.

Scan Settings

The Scan Settings panel controls analysis depth, engine behaviour, and heuristic thresholds.

Scan depth

Three radio options control the scan depth: Quick (fast single pass), Standard (full static analysis pass), and Deep (exhaustive audit with heuristic passes). Standard is selected by default. Scan duration varies with project size and complexity.

Analysis modules

Toggle individual analysis modules on or off. Available modules include heuristic pattern matching, CVE / NVD correlation matching, experimental detector vectors (beta), and embedded resource extraction. All are enabled by default except the experimental detectors.

Engine

Engine-level settings control resource usage: parallel analysis workers (enabled by default), low-memory mode for machines with less than 512 MB available, and caching of intermediate results to speed up consecutive scans.

Rulesets and Policies

The Rulesets panel manages detection rule sets and compliance mappings. Rule sets can be imported, exported, and toggled between Active and Inactive states.

Built-in rule sets

Custom rules

Click Add Custom Rule to define your own detection policies. Custom rules follow the same YAML format as built-in rules and can target specific CWEs, severity levels, and code patterns. Use Import Ruleset and Export Ruleset to back up or transfer rule configurations.

Memory corruption

The Memory Corruption module covers stack buffer overflows, heap overflows, use-after-free, double-free, and out-of-bounds read/write patterns. These remain the most common source of remote code execution in C and C++ code. VirtualSpace detects them through pattern matching on dangerous APIs (strcpy, strcat, sprintf, gets) and heuristic flow analysis that tracks tainted user input into stack and heap buffers.

void handle_request(char* user_input) {
  char buffer[64];
  strcpy(buffer, user_input);  // CWE-120: classic stack overflow
  process(buffer);
}

void handle_request(char* user_input) {
  char buffer[64];
  strncpy(buffer, user_input, sizeof(buffer) - 1);
  buffer[sizeof(buffer) - 1] = '\0';
  process(buffer);
}

Injection flaws

SQL, command, LDAP, XPath, ORM, and template injection are detected by tainting user-input sources and tracking the taint through the control-flow graph until it reaches a sink. A finding is raised when a tainted value reaches a sink without passing through a recognised sanitiser.

XSS / output encoding

The XSS module detects reflected, stored, and DOM-based cross-site scripting patterns. It inspects output encoding mechanisms and analyses web interface components in the code for unsafe rendering of user-controlled data.

Cryptographic failures

Covers deprecated ciphers (DES, RC4, MD5, SHA-1), insecure modes (ECB), hardcoded IVs and keys, weak PRNG seeding, insufficient key length, and misuse of high-level cryptographic APIs such as calling CryptAcquireContext with PROV_RSA_FULL when PROV_RSA_AES is required.

Secrets detection

Detects embedded API keys, authentication tokens, database passwords, connection strings, and other hardcoded credentials in your source. The scanner uses entropy analysis combined with format-specific pattern matching (AWS keys, GitHub tokens, generic high-entropy strings) to distinguish real secrets from false positives.

Dynamic execution

The Dynamic Execution module flags use of eval(), exec(), Runtime.exec(), system(), insecure deserialization sinks (pickle, BinaryFormatter), and runtime code generation patterns. These represent the highest-risk code paths because they can convert data-plane input into control-plane actions.

SSRF & access control

In the OWASP Top 10 (2025) release, Server-Side Request Forgery was folded into the A01 Broken Access Control category, reflecting how SSRF is most commonly exploited in cloud environments to reach internal services or instance-metadata endpoints. VirtualSpace AppSec treats the two as a single detection family.

The SSRF detector flags outbound HTTP requests where the target URL is influenced by external input without being validated against an allowlist. It traces taint from request handlers, message-queue consumers, and form processors into requests.get, http.Get, HttpClient.GetAsync, and equivalents. Access-control checks complement this by detecting authorization functions that are reachable from unauthenticated code paths.

def fetch_avatar(request):
    url = request.args['url']      // tainted source
    return requests.get(url).content  // CWE-918: SSRF sink

ALLOWED_HOSTS = {"cdn.example.com"}

def fetch_avatar(request):
    url = request.args['url']
    host = urlparse(url).hostname
    if host not in ALLOWED_HOSTS:
        raise ValueError("host not allowed")
    return requests.get(url, allow_redirects=False).content

Supply chain failures

Supply Chain Failures is a new dedicated category in the OWASP Top 10 (2025) release, separated out from the previous "Vulnerable and Outdated Components" entry to reflect how the SolarWinds, log4j, and 3CX incidents reshaped industry priorities. The Supply Chain module covers risks that originate outside your own code base.

• Vulnerable dependencies. Cross-references resolved imports against a local snapshot of the CVE / NVD database and known-malicious packages.
• Dependency confusion. Detects internal package names that are not registered on the public registry, leaving them exploitable via name-squatting.
• Dependency integrity. Flags dependencies and packages pinned to unverified or unsigned sources, or that fail integrity checks.
• Reproducibility hints. Reports build steps that fetch artifacts without integrity pinning (no SHA-256 hash, no lock file).

The Supply Chain module ships disabled. Enable it from the Detection Modules panel for full coverage.

OWASP Top 10 (2025)

The OWASP rule pack maps every analyser in the memory, crypto, auth, and input-validation families to the relevant OWASP category and reports compliance per category in the summary panel.

CWE/SANS Top 25 (2025)

The CWE pack covers all twenty-five entries on the SANS Top 25 most dangerous software weaknesses list. Each finding reports its CWE ID and a link to the corresponding entry on cwe.mitre.org.

PCI DSS v4.0.1

The PCI DSS pack focuses on requirement 6.2.4 (secure coding) and the cryptographic requirements in section 3 (protect stored cardholder data). Compliance status is displayed in the Security Insights panel.

Custom rules

You can author custom rule packs in YAML. A rule pack is a list of rules, each defining a name, a CWE mapping, a severity, a pattern (regex over source or a YARA-like rule body), and a remediation hint.

# custom-rules.yaml
pack: acme-internal
version: 1
rules:
  - id: ACME-001
    name: Internal logger leak
    cwe: CWE-532
    severity: medium
    pattern: 'AcmeLog::WriteSensitive'
    recommendation: "Replace with AcmeLog::WriteRedacted."
  - id: ACME-002
    name: Unsanctioned crypto provider
    cwe: CWE-327
    severity: high
    pattern: 'CryptAcquireContext.*PROV_RSA_FULL'
    recommendation: "Use PROV_RSA_AES (provider type 24)."

NIST SP 800-218 (SSDF)

The NIST rule pack maps findings to the Secure Software Development Framework requirements. It covers thirty-one rules aligned with NIST's guidance on secure development practices, vulnerability response, and software integrity verification. Active by default.

OWASP LLM Top 10 (2025)

The LLM rule pack targets vulnerability patterns specific to applications that integrate large language models: prompt injection, insecure output handling, training data poisoning, model denial of service, and supply chain vulnerabilities in AI/ML pipelines. Ships inactive by default; enable it in the Rulesets panel for applications that interact with LLM services.

Troubleshooting

Quick reference for the most common issues encountered when running VirtualSpace AppSec.

Scan fails immediately

If Run Analysis reports a failure before any progress, the selected path most likely contains no supported source files. VirtualSpace analyzes C/C++, Python, JavaScript/TypeScript, and .NET source. Re-select a folder that contains supported source files via Browse and confirm the status bar reports the detected languages before re-running the scan.

License invalid or expired

If the application shows a license error on launch, the cached license file at %PROGRAMDATA%\VirtualSpace\license.dat is either missing or out of date. Re-enter the key from your order confirmation email. The CLI returns exit code 10 in this state for build pipelines.

Project scan returns zero findings

The Project mode walker caps itself at 800 files, skips files over 2 MB, and ignores standard vendor / build directories (node_modules, .git, dist, __pycache__, etc.). If a tree contains nothing under those limits, the scanner reports zero findings without an error. Select a subfolder that contains primary source files to scan instead.

CI build keeps passing even with findings

The CLI returns 0 unless --fail-on is passed. To gate a pipeline, run vsappsec scan ./src --fail-on=high (or medium, critical, etc.). The mapping from severity to exit code is documented in the CLI loader section.