How Debuggix Works
Architecture, Engines, and AI Filtering

A technical overview of the platform that runs 9 security engines in parallel, applies AI context filtering, and deletes your code immediately after scanning.

Overview

Debuggix is a security scanning platform that orchestrates multiple open-source security engines to analyze your codebase in a single operation. It is not a single scanner. It is a unified orchestration layer that runs 9 engines in parallel, collects their findings, and applies an AI-powered filtering system to remove false positives.

The platform is designed for development teams who need comprehensive security coverage without the operational overhead of configuring and managing multiple standalone tools. There is no CLI to install, no configuration files to write, and no rules to maintain. You paste a GitHub URL, and the platform returns a prioritized report of real security issues in approximately 60 seconds.

The Problem Debuggix Solves

Running a single security engine misses entire categories of vulnerabilities. Semgrep catches code patterns but does not check dependencies. Trivy finds CVEs but does not detect hardcoded secrets. Gitleaks scans for credentials but ignores infrastructure misconfigurations. No single engine provides comprehensive coverage.

Running multiple engines separately produces hundreds of raw findings. In our benchmark of 100+ repositories, a typical scan produced 97 raw findings across 9 engines. Most of these were false positives originating from test files, build artifacts, example code, or documented intentional patterns. Triaging these manually takes hours. Most developers abandon the scanner entirely after the first noisy report.

Existing solutions that attempt to combine multiple engines are priced for enterprises with dedicated security teams. Snyk costs $25+ per user per month and requires configuration. Checkmarx and Veracode require custom enterprise contracts. Individual developers and small teams are left with single-purpose open-source tools that each cover one vulnerability category and produce raw, unfiltered output.

The 9 Security Engines

All 9 engines execute in parallel. No engine waits for another to complete. Results are streamed in real-time, deduplicated, and passed to the AI filter as a single correlated dataset.

Engine	Category	Detection Capabilities
Semgrep	Static Analysis (SAST)	SQL injection, XSS, path traversal, deserialization bugs, unsafe code patterns across 20+ languages
Bandit	Python Security	Hardcoded credentials, unsafe deserialization, subprocess injection, Python-specific vulnerabilities
Gitleaks	Secrets Detection	Hardcoded API keys, passwords, tokens, and credentials in current source code
TruffleHog	Git History	Secrets buried in commit history, tags, and branches that may have been deleted from the current codebase
Trivy	Dependencies & Containers	Known CVEs in package dependencies, container image vulnerabilities, misconfigurations
ESLint	JavaScript/TypeScript	Security-specific linting rules for JS and TS codebases (eslint-plugin-security)
Hadolint	Dockerfiles	Unpinned base images, running as root, missing .dockerignore, shell pipefail warnings
Checkov	Infrastructure as Code	Terraform misconfigurations, open S3 buckets, overly permissive IAM policies, Kubernetes security issues
OSV-Scanner	Open Source Vulnerabilities	Vulnerabilities from Google's OSV database across npm, PyPI, Go, Rust, and other ecosystems

How AI Noise Filtering Works

The AI filter is the primary differentiator between Debuggix and running the same engines locally or via CI/CD. Without it, you receive hundreds of raw findings. With it, you receive the handful that actually require attention.

Documentation Parsing

Before classifying any finding, the AI reads your project's documentation files: README.md, SECURITY.md, CONTRIBUTING.md, and any docs/ directory contents. This provides critical context about your project's purpose, security posture, and which patterns are intentional. A repository marked as "deliberately vulnerable for training purposes" is treated completely differently from a production payment API.

Context Detection by File Role

The AI identifies the semantic role of every file in your repository based on path patterns, naming conventions, and content analysis:

• Test directories (tests/, spec/, __tests__/) receive lower severity for most finding types
• Build scripts (scripts/, tools/, Makefile) are evaluated with appropriate context
• Example code (examples/, samples/) is flagged as informational only
• Documentation files (*.md, docs/) are scanned but findings are deprioritized
• Vendor directories (node_modules/, vendor/, third_party/) are excluded from most rule-based engines

Confidence Scoring (0-100%)

Every finding receives a confidence score based on multiple signals:

• Engine consensus: How many independent engines flagged the same underlying issue
• Documentation evidence: Whether the project's documentation indicates the pattern is intentional
• File role weighting: Production files receive higher weight than test or example files
• Historical patterns: Whether similar findings have been marked as false positives in similar projects

Findings with scores above 90% appear in the Needs Attention tab. Findings between 70% and 90% are flagged for review. Findings below 70% are placed in the Reviewed tab but remain accessible for manual inspection.

Cross-Engine Deduplication

When multiple engines flag the same underlying vulnerability from different analytical perspectives, the AI consolidates them into a single finding. For example, a hardcoded credential might be detected by Semgrep (pattern matching), Gitleaks (regex scanning), and TruffleHog (entropy analysis). Instead of three separate alerts, you see one finding with context aggregated from all three engines.

Scan Pipeline: Step by Step

1. Submit a repository. Paste a public GitHub URL or authenticate via GitHub OAuth to access private repositories.
2. Repository is fetched. The platform clones the repository into an isolated, ephemeral environment with no network access to other services.
3. 9 engines execute in parallel. All security engines run simultaneously. The process typically completes within 60 seconds.
4. Raw findings are collected. Each engine's output is aggregated into a single structured dataset.
5. AI reads project documentation. README, SECURITY.md, and other documentation files are analyzed for context.
6. Findings are classified. The AI assigns confidence scores, deduplicates across engines, and separates findings into Needs Attention, Review, and Reviewed categories.
7. Report is generated. The final report is stored in your account. You can view it in the dashboard, export as JSON, or generate a shareable link.
8. Source code is deleted. The ephemeral container is destroyed. No source code is retained on Debuggix systems.

Zero Retention Policy

Debuggix operates on a strict zero-retention policy for source code. After a scan completes, all cloned repositories, temporary files, build artifacts, and logs are permanently deleted from the scanning environment. Only the findings report (which contains no source code) is retained for your review.

• No code storage: We cannot recover your code after a scan. We do not want to. The architecture is designed to make retention impossible.
• No AI training: Your code is never used to train, fine-tune, or improve any AI model.
• No third-party sharing: Your code never leaves the ephemeral container except to return the findings report.
• Data encryption: TLS 1.3 for all data in transit. AES-256 for all data at rest.
• Your data, your control: You can delete any scan result from your account at any time. Deletion is permanent and cannot be undone.

Verified Badge System

Repositories that complete a scan with zero critical or high-severity findings in the Needs Attention category earn a verified badge. The badge is dynamic—it automatically updates when the repository is rescanned. Green indicates a clean security status. Orange indicates issues require attention. Red indicates critical vulnerabilities were found.

Inline badge (130 × 20 pixels, matches Shields.io dimensions):

[![Verified by Debuggix](https://api.debuggix.space/badge/inline/owner/repo)](https://debuggix.space/verified)

Full badge (240 × 68 pixels, featured placement for README headers):

[![Debuggix Security Verified](https://api.debuggix.space/badge/owner/repo)](https://debuggix.space/verified)

Replace owner and repo with your GitHub username and repository name. Badges reflect the most recent completed scan. No API key is required.

Plans and Limits

Plan	Price	Scans per Month	Private Repos	AI Fixes	API Access	Team Seats
Free	$0	10	❌	❌	❌	1
Pro	$29/month	100	✅	✅	❌	1
Pro+	$50/month	500	✅	✅	✅	3

All plans include all 9 engines. No credit card is required for the Free tier. The first scan on any repository is unlimited regardless of plan. Pro and Pro+ plans bill monthly and can be cancelled at any time. Enterprise pricing for more than 500 scans per month is available upon request.

Integrations

Integration	Availability	Plan Required	Description
GitHub OAuth	✅ Available	Free+	Sign in with GitHub. Connect private repositories for scanning.
GitHub PR Integration	✅ Available	Pro+	Auto-create pull requests with AI-generated fixes directly from scan findings.
Slack Notifications	✅ Available	Pro+	Receive scan completion alerts and finding summaries in Slack channels.
Webhooks	✅ Available	Pro+	Configure outgoing webhooks to trigger actions when scans complete.
REST API	✅ Available	Pro+	Programmatically trigger scans, retrieve results, and manage badges.
GitHub Actions	Q3 2026	All	Trigger scans from CI/CD pipeline with a single YAML workflow file.
VS Code Extension	Q3 2026	Pro+	Inline findings and one-click fixes within the editor.
CLI Tool	Q3 2026	Pro+	Local scanning from the terminal. No API calls. Instant feedback.

API Access

The Debuggix REST API is available to Pro+ subscribers. It provides programmatic access to the platform's core functionality for integration into your own tools, dashboards, and automation pipelines.

Available endpoints:

• POST /v1/scans – Trigger a new scan on a repository
• GET /v1/scans/{id} – Retrieve scan status and results
• GET /v1/scans/{id}/findings – Retrieve findings filtered by severity
• GET /v1/badge/{owner}/{repo} – Get the current badge status as JSON
• DELETE /v1/scans/{id} – Delete a scan result

API keys are managed from your Account Settings → API Keys. Each key can be scoped to specific permissions (read-only, write, admin) and can be revoked at any time. All API requests require authentication via Bearer token over HTTPS.

Team Management Available in Pro+

Pro+ subscribers can manage multiple team members from a single account. Team members can be assigned different permission levels to control access to scan results and account settings.

Team features:

• Up to 3 team seats included in Pro+ (additional seats available for $15/month each)
• Role-based access control: Admin, Member, and Viewer roles
• Shared scan history across team members
• Audit logging of all team actions (coming Q3 2026)
• SSO via GitHub Organizations (coming Q4 2026)

To invite team members, navigate to Account Settings → Team Management. Invited members receive an email with a link to join your organization account.

Privacy and Security

• No code retention. Source code is deleted immediately after scanning completes. Zero exceptions.
• No AI training. Customer code, findings, or scan metadata are never used to train or improve AI models.
• Encryption standards. TLS 1.3 for all data in transit. AES-256-GCM for all data at rest.
• Ephemeral environments. Each scan runs in an isolated container that is destroyed after the scan completes. No data persists between scans.
• Data ownership. You own your scan results. Export them as JSON or delete them permanently from your account at any time.
• Third-party audits. Annual penetration testing by independent security firms. SOC 2 Type II in progress (expected Q4 2026).

For complete details, read our Privacy Policy, Terms of Service, and Security Overview.

Frequently Asked Questions

Do you store my source code?

No. Source code is fetched into an ephemeral container, scanned, and then the entire container is destroyed. We cannot recover your code after a scan completes. This is a deliberate architectural decision, not a policy promise.

How long does a scan take?

Approximately 60 seconds for most repositories. Very large codebases with over 100,000 files may take 2-3 minutes. The 9 engines run in parallel to minimize total execution time.

Can I scan private repositories?

Yes. Pro and Pro+ plans include private repository scanning. Connect your GitHub account via OAuth from the Integrations page. Your GitHub token is stored encrypted and used only for repository access during scans.

What languages do you support?

The combined engines support JavaScript, TypeScript, Python, Go, Rust, Java, PHP, Ruby, C, C++, Shell, Dockerfiles, Terraform, and Kubernetes configurations. Not every engine runs against every language. The platform auto-detects which engines to execute based on your repository's file contents.

How accurate is the AI filter?

In our benchmark of over 100 repositories, the AI filter achieved 92% noise reduction. A scan producing 134 raw findings typically surfaces 6 to 10 real issues. Deliberately vulnerable training projects are correctly identified with zero false positives.

Can I use Debuggix in my CI/CD pipeline?

GitHub Actions integration is in development for Q3 2026. Currently, scans are triggered manually through the web dashboard or programmatically via the REST API for Pro+ subscribers.

What happens to my scan results?

Scan results are stored in your account for 90 days by default. You can view them in the dashboard, export them as JSON, share a public link, or delete them permanently at any time.

How do I get the verified badge?

Run a scan on your public repository. If the scan completes with zero critical or high-severity findings in the Needs Attention category, your repository automatically qualifies for the badge. Copy the markdown from the scan results page and paste it into your README.

Do you offer SOC 2 compliance?

SOC 2 Type II audit is in progress with expected completion in Q4 2026. Contact support for the current audit status or to receive a copy of the report when available.