Static Analysis (SAST)
How Trace's SAST engine finds code-level vulnerabilities — including AI-specific ones — without rule files.
Trace's SAST engine is the part of the platform that reads your source code and finds the vulnerabilities a rule-based scanner can't reach: business-logic bugs, multi-file data flow, auth bypasses, unsafe deserialization, and the subtle issues that only become visible when you understand what the code is trying to do.
How it works
Traditional SAST tools work by matching code against a fixed set of patterns. The patterns catch some real issues, but they miss anything that doesn't fit a template — and they generate a lot of noise on the things that do. Trace takes a different approach.
The engine reads your code the way a security engineer would. It maps the architecture, identifies the attack surface (entry points, auth boundaries, sensitive operations), and traces how user input flows through your system. For every potential issue, it follows the data across files and services to confirm whether the path is actually exploitable — and discards anything it can't substantiate.
The result is that a finding doesn't reach your dashboard unless the engine can articulate the attack vector, the exploit scenario, the prerequisite access, and the impact — with code citations to back it all up.
What it finds
Trace's SAST engine reports on CWE-categorized vulnerabilities including (but not limited to):
- Injection — SQL injection (CWE-89), command injection (CWE-78), NoSQL injection, template injection, LDAP injection.
- Authentication and authorization — Auth bypass, missing authorization checks (CWE-862), insecure direct object references (CWE-639), session fixation.
- Server-side request forgery — SSRF (CWE-918), open redirect (CWE-601).
- Deserialization — Unsafe deserialization (CWE-502), prototype pollution (CWE-1321).
- Cryptographic weaknesses — Weak algorithms, hardcoded keys, missing certificate validation.
- Business logic flaws — Race conditions, missing rate limits on sensitive endpoints, broken access controls that pass a rule scanner but fail a thinking reviewer.
- AI and LLM application risks — Prompt injection (direct and indirect), unsafe tool use in agent loops, missing output validation on model responses, untrusted-content injection into RAG context, secret exposure through model prompts, and the rest of the LLM-specific attack surface that traditional SAST tools weren't built for.
The engine isn't limited to a fixed taxonomy — if a bug class doesn't have an established name, Trace will still surface it and explain why it's exploitable.
Language support
Trace's SAST engine is language-agnostic. Because the engine reasons about code semantically rather than matching language-specific patterns, it works on any language the underlying model can read — including TypeScript, JavaScript, Python, Go, Java, Kotlin, Ruby, C#, Rust, PHP, and more. There are no language-specific rule packs to install or maintain.
This matters most for polyglot codebases — microservices written in different languages, infrastructure-as-code mixed with application code, generated bindings — where rule-based scanners typically have coverage holes.
What you get for each finding
Each SAST finding carries the full context an engineer needs to triage and fix it:
- Location — file path, start and end line, and a snippet of the relevant code.
- Attack vector — how an attacker would reach this code (e.g. "unauthenticated HTTP request to
/api/upload"). - Exploit scenario — a concrete walkthrough of what an attacker could do.
- Prerequisite access — what level of access an attacker needs (none, authenticated user, admin, etc.).
- Impact — what they'd gain (data exfiltration, RCE, privilege escalation).
- Remediation guidance — the specific change required to fix the issue.
- CWE classification — for compliance and risk-tracking integrations.
Severity is set automatically based on the engine's assessment of impact and exploitability, and a CVSS score is calculated for integration with your risk-tracking systems.
The exploit scenario field is concrete. For an XSS finding, for example, you'll see the attacker payload that triggers the bug — not just a generic description of the class — along with the affected file, attack vector, and impact.

Deduplication
A vulnerability that's been reported once doesn't get reported again on every subsequent scan. Trace fingerprints each finding by file path, CWE classification, and line range — so as the code moves around, the same underlying issue stays linked to the same vulnerability record.
When the code is fixed, Trace detects that the finding no longer appears, and the vulnerability moves to FIXED with the resolving scan ID. If the issue regresses, the vulnerability automatically reopens.
Configuration
There are no rule files to write. The engine runs out of the box on every repository you connect. During onboarding, the Trace team will tune severity thresholds, suppression rules, and PR behavior to fit your codebase — most of which can be adjusted from your organization's settings later.