SAST

Static Application Security Testing for code-level vulnerabilities.

SAST (Static Application Security Testing) is PrismSec's code-level vulnerability detection engine. It analyzes your source code to find security flaws like SQL injection, cross-site scripting (XSS), authentication bypasses, and insecure deserialization — before they reach production.

Unlike traditional SAST tools that rely on pattern matching, PrismSec uses context-aware data flow analysis to trace how untrusted input moves through your application and identify real exploitable vulnerabilities.

What SAST Detects

PrismSec's SAST engine covers the OWASP Top 10 and beyond:

Injection Vulnerabilities

| Vulnerability | Description | Example Language | |---------------|-------------|------------------| | SQL Injection | Untrusted input in SQL queries | Python, PHP, Java, JavaScript | | Command Injection | Untrusted input in shell commands | Python, Node.js, PHP | | LDAP Injection | Untrusted input in LDAP queries | Java, Python | | NoSQL Injection | Untrusted input in MongoDB/Redis queries | JavaScript, Python | | XML Injection | Untrusted input in XML parsers | Java, Python, PHP |

Cross-Site Scripting (XSS)

| Type | Description | Example | |------|-------------|---------| | Reflected XSS | User input reflected in HTML without escaping | JavaScript, PHP, Python | | Stored XSS | Malicious script stored in database and rendered later | All web frameworks | | DOM-based XSS | JavaScript manipulates DOM with untrusted input | JavaScript, TypeScript |

Authentication and Authorization

| Vulnerability | Description | |---------------|-------------| | Authentication Bypass | Missing or weak authentication checks | | Privilege Escalation | Users can access higher-privileged functionality | | Insecure Session Management | Weak session tokens, session fixation | | Missing Authorization Checks | Endpoints accessible without permission validation |

Cryptography Flaws

| Vulnerability | Description | |---------------|-------------| | Weak Algorithms | Use of MD5, SHA1, DES, or other deprecated algorithms | | Hardcoded Keys | Encryption keys stored in source code | | Insecure Random | Predictable random number generation for security-sensitive operations | | Missing Encryption | Sensitive data transmitted or stored without encryption |

Insecure Deserialization

| Vulnerability | Description | |---------------|-------------| | Unsafe Unpickling | Untrusted data deserialized in Python (pickle, yaml.load) | | Java Deserialization | Untrusted data deserialized in Java (RCE risk) | | JSON/XML Deserialization | Unsafe deserialization of complex objects |

Path Traversal

| Vulnerability | Description | |---------------|-------------| | Directory Traversal | User input used to construct file paths without validation | | File Inclusion | Local or remote file inclusion vulnerabilities | | Arbitrary File Write | User-controlled file paths in write operations |

Other Vulnerabilities

  • Server-Side Request Forgery (SSRF) — User input used in HTTP requests
  • Open Redirects — Unvalidated redirects to user-supplied URLs
  • CSRF (Cross-Site Request Forgery) — Missing CSRF tokens on state-changing requests
  • Information Disclosure — Sensitive data leaked in logs, error messages, or API responses
  • Race Conditions — Time-of-check-time-of-use (TOCTOU) vulnerabilities

How SAST Analysis Works

PrismSec's SAST engine performs data flow analysis to trace how untrusted input propagates through your code.

Data Flow Analysis

PrismSec identifies three key elements:

  1. Sources — Where untrusted input enters the application:

    • HTTP request parameters (GET, POST, headers, cookies)
    • File uploads
    • Database queries (if the database contains user-supplied data)
    • Environment variables (in some contexts)

  2. Sinks — Dangerous operations that can be exploited if they receive untrusted input:

    • Database query execution
    • Shell command execution
    • HTML rendering
    • File system operations
    • HTTP requests

  3. Sanitizers — Functions that validate or sanitize input:

    • Input validation (regex, type checks, allow-lists)
    • Output encoding (HTML escaping, URL encoding)
    • Parameterized queries (SQL)

Example:

from flask import request
 
def search_users():
    # Source: untrusted input from HTTP request
    query = request.args.get('q')
    
    # Sink: SQL query execution
    results = db.execute(f"SELECT * FROM users WHERE name LIKE '%{query}%'")
    
    return results

PrismSec detects:

  • request.args.get('q') is a source (untrusted input)
  • The input flows into the SQL query string
  • db.execute() is a sink (dangerous operation)
  • No sanitizer is applied

Severity: Critical (SQL Injection)

Context-Aware Severity Adjustment

PrismSec adjusts severity based on context:

  • Authentication-protected endpoints — If a vulnerable endpoint requires authentication, severity may be downgraded from Critical to High
  • Internal APIs — If the vulnerable code is only accessible from internal services, severity is reduced
  • Dead code — If the vulnerable function is never called, severity is Low

PrismSec's context-awareness reduces false positives and helps you focus on the vulnerabilities that matter most.

Auto-Fix Support

Many SAST findings can be fixed automatically. See Auto-fix PRs for details.

Example auto-fixes:

  • SQL Injection → Replace string concatenation with parameterized queries
  • Command Injection → Replace shell string interpolation with argument arrays
  • Hardcoded credentials → Move to environment variables
  • Weak cryptography → Replace deprecated algorithms with modern alternatives

Example Findings

SQL Injection (Python)

Vulnerable code:

def login(username, password):
    query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
    user = db.execute(query).fetchone()
    return user is not None

PrismSec finding:

🔴 Critical: SQL Injection in login()

File: auth/login.py
Line: 3

Description:
User input (`username` and `password`) is concatenated directly into a SQL query.
An attacker can inject SQL commands to bypass authentication or extract data.

Data Flow:
Source: username (function parameter, untrusted)
  ↓
Sink: db.execute(query)

Recommendation:
Use parameterized queries:

query = "SELECT * FROM users WHERE username = %s AND password = %s"
user = db.execute(query, (username, password)).fetchone()

XSS (JavaScript)

Vulnerable code:

function displayComment(commentText) {
    const commentDiv = document.getElementById('comments');
    commentDiv.innerHTML += `<p>${commentText}</p>`;
}

PrismSec finding:

🟠 High: Cross-Site Scripting (XSS)

File: comments.js
Line: 3

Description:
Untrusted input (`commentText`) is rendered in HTML without escaping.
An attacker can inject malicious JavaScript that executes in other users' browsers.

Data Flow:
Source: commentText (function parameter, untrusted)
  ↓
Sink: element.innerHTML (DOM manipulation)

Recommendation:
Use textContent for plain text or sanitize HTML:

commentDiv.textContent += commentText;

Or use a library like DOMPurify:

commentDiv.innerHTML += DOMPurify.sanitize(commentText);

Command Injection (Node.js)

Vulnerable code:

const { exec } = require('child_process');
 
function convertFile(filename) {
    exec(`ffmpeg -i ${filename} output.mp4`, (err, stdout) => {
        console.log(stdout);
    });
}

PrismSec finding:

🔴 Critical: Command Injection in convertFile()

File: converter.js
Line: 4

Description:
User input (`filename`) is interpolated into a shell command.
An attacker can inject shell commands by manipulating the filename.

Example exploit:
filename = "input.mp4; rm -rf /"

Recommendation:
Use argument arrays instead of shell strings:

const { execFile } = require('child_process');

execFile('ffmpeg', ['-i', filename, 'output.mp4'], (err, stdout) => {
    console.log(stdout);
});

Supported Languages

PrismSec's SAST engine supports:

  • JavaScript / TypeScript — Node.js, React, Vue, Angular
  • Python — Django, Flask, FastAPI
  • Go — Standard library, popular frameworks
  • Java — Spring Boot, Jakarta EE
  • PHP — Laravel, Symfony, WordPress

See Supported Languages for details.

Best Practices

  • Review High and Critical SAST findings immediately — These are likely real vulnerabilities
  • Use auto-fix for common patterns — Saves time and ensures secure code
  • Combine SAST with testing — Security tests validate that fixes work as expected
  • Educate your team — Use findings as teaching moments to improve secure coding practices

Next Steps