Security engineers know that some critical vulnerabilities don’t appear in simple scans. They cross language boundaries, involve dynamic behavior, or emerge from patterns that don’t exist in any public rule set. Traditional SAST tools, especially those built on static rules or syntax matching, weren’t designed to catch these risks. Graph-based analysis changes that. It enables context-rich, behavior-based detection that goes far beyond pattern matching by modeling the entire code base to complete a unified graph, including control flow, data flow, and code dependency structure. This approach reveals deep, multi-step vulnerabilities that legacy tools routinely miss. 

Modern AppSec is more fragile than it looks. Rule-based scanners give the illusion of coverage, but they buckle under complexity when applied to agentic workflows, AI-generated code, and multi-language repos. We’ve identified eight high-impact vulnerability types that expose the limits of this old model. Each one is a card in the unstable tower of traditional AppSec. The more you rely on brittle scanning logic, the closer you collapse. Here’s a look at what we’ll explore in more technical detail:

♠ Ace of Spades: Cross-Language or Cross-Module Dataflows

The Most Dangerous Card in the Deck: When user input crosses boundaries, TypeScript to Go to Java, it becomes nearly impossible for rule-based scanners to follow. 

• The Problem: In modern microservice architectures, data often flows across multiple services written in different languages. For example, a user input starts in a TypeScript frontend, travels through a Go service, and lands in a Java backend that persists the data. The risk? Input validation might be missing at each stage, leading to injection or data corruption deep in the stack.
• Why It’s Missed: Traditional SAST tools scan individual languages or modules in isolation. Even with multi-language support, they often lack correlation across services, mainly when logic is distributed via message queues, protobufs, or serialized payloads. This can obscure full data flow and lead to missed issues.
• What Qwiet Sees: Qwiet’s proactive detection system automatically detects and parses every language in a monorepo, then merges the code into a single Code Property Graph. This means Qwiet can trace an attacker-controlled input as it crosses service boundaries, transforms through serialization, and eventually hits a vulnerable sink in another language. This proactive approach is critical for detecting chained exploits that span the entire application architecture, giving you the confidence that your system is secure.

♦ King of Diamonds: Vulnerabilities in Custom or In-House Frameworks

The Card You Think Is Safe: Internal libraries look polished and trusted but are invisible to tools that rely on public rule sets. 

• The Problem: Many enterprises build internal templating, authentication, or logging libraries. These in-house tools don’t have public CVEs or security advisories, but they often include logic that could be exploited if misused.
• Why It’s Missed: Legacy SAST tools depend on known vulnerabilities in public packages or hardcoded patterns for widely used frameworks. If a function or class doesn’t match a predefined signature, it’s invisible to the scanner. Worse, rules become fragile or impossible to write if the internal library uses non-standard naming or obfuscated logic.
• What Qwiet Sees: Qwiet doesn’t rely on fixed rules. Its AI can infer “policy” by analyzing how data flows through custom code. If a function behaves like a sink (e.g., writing to disk, executing a command, or modifying headers), Qwiet identifies it as such, even without external metadata. This adaptability allows Qwiet to surface vulnerabilities in internal frameworks, meeting your unique security needs without extra configuration or rule writing.

♥Jack of Hearts: Hidden or Dynamic Injection Paths via Reflection

The Deceptive Card: Reflection-based logic, dynamic method calls, and obfuscated inputs are easy to miss if you only look for known patterns. 

• The Problem: Developers sometimes dynamically construct method names or class paths at runtime, especially in C#, Java, Python, and JavaScript. Injection vulnerabilities can be introduced through reflection or eval-like functions, which are often used to generate code that can include attacker input dynamically.
• Why It’s Missed: Most scanners look for direct calls to dangerous functions (e.g., exec, system, eval). The pattern isn’t apparent if user input is concatenated, passed through multiple layers, or only used in a dynamic call. Additionally, traditional SAST cannot often track how strings are built over time.
• What Qwiet Sees: The CPG models are not just a function call but also show how values are constructed and used over time. Qwiet can identify that input passed through several layers of string manipulation is ultimately used in a reflection-based call or evaluated at runtime. It sees the full dataflow path even if the sink isn’t explicitly called in the source file.

♠ Queen of Spades: Complex Concurrency or Race Conditions

The Silent Saboteur: Concurrency issues don’t raise a flag until something breaks in production. Legacy scanners don’t model thread interactions or lock states, but Qwiet does, and it sees shared state manipulation across concurrent code paths.

• The Problem: When an application accesses shared resources across threads without proper locking, it can lead to data corruption, unexpected behavior, or even privilege escalation. These concurrency issues are subtle and context-dependent.
• Why It’s Missed: Static analysis engines traditionally struggle with concurrency modeling. Many tools avoid it altogether because accurately simulating thread interactions, locks, and asynchronous behavior is challenging using linear code analysis.
• What Qwiet Sees: While not perfect, Qwiet’s CPG can often represent concurrency primitives like mutexes, channels, async/await, and promises. It blends deterministic analysis with fuzzy inference, assigning likelihoods to thread interactions. This helps surface issues like race conditions or improper lock use, even when the timing and data flows aren’t explicit.

♣ Eight of Clubs: Secrets in Non-Traditional File Types

The Hidden-in-Plain-Sight Card: Hardcoded secrets often appear in YAML blobs and JSON configs or are buried inside minified files. Regex scanners won’t catch them.

• The Problem: Sensitive data like API keys, access tokens, or credentials can be hard coded anywhere, including YAML files, JSON blobs, shell scripts, and even inside minified libraries.
• Why It’s Missed: Many tools only scan files with known extensions or look for a few common keywords. They might also ignore high-entropy values or long strings if they’re not in .env or .config files. Regex-based secrets detection tools are easy to bypass with minor formatting changes.
• What Qwiet Sees: Qwiet uses pattern-based and entropy-based scanning to examine every file in the repository, including non-code files. This approach allows Qwiet to identify potentially sensitive data, such as base64 strings, hexadecimal blobs, or suspicious high-entropy tokens, even when hidden within YAML files, JSON blobs, shell scripts, or minified libraries. By analyzing commit history and context, Qwiet can also determine whether a secret is truly sensitive or simply appears to be.

♣ Seven of Clubs: Custom Cryptography or Faulty Key Management

The “Looks Secure” Card: Custom encryption routines and roll-your-own key derivation rarely hold up to scrutiny.

• The Problem: Developers sometimes try to “roll their own” crypto, combining key bytes from multiple variables, slicing random seeds, or misusing PRNGs. These techniques often weaken encryption or expose secrets.
• Why It’s Missed: If a scanner only checks for known weak crypto APIs (e.g., MD5, DES), it won’t catch bespoke routines. Worse, tools that don’t trace key derivation logic or entropy sources will assume the code is secure because it avoids blocked functions.
• What Qwiet Sees: Qwiet utilizes data flow analysis and machine learning to identify risky patterns such as partial environment variable use, weak randomness, or multi-source key derivation, even if the function isn’t labeled as cryptographic. By tracking key construction across functions, files, and modules, Qwiet’s behavioral model understands the intent and can identify complex security issues that traditional SAST tools might miss.

♥  Ten of Hearts: Nested or Double-Layered Templating Injections

The Second-Order Trap Card: User input that flows through one template engine and gets re-evaluated by another introduces hard-to-catch injection paths. 

• The Problem: User input might first pass through a server-side template and later be re-expanded in a client-side framework like Angular or React. This sets the stage for second-order injection vulnerabilities where the input isn’t dangerous at first but becomes executable when reinterpreted downstream.
• Why It’s Missed:
• Traditional scanners typically stop at the first expansion layer. They might flag a server-side injection but fail to follow how transformed output becomes active code in a second templating engine, especially if it spans files, frameworks, or execution contexts.
• What Qwiet Sees: Because templates, when compiled or interpreted, generate executable code, Qwiet’s Code Property Graph captures how data is transformed and re-evaluated across those layers. It can trace input through templating engine A into serialized or stored output and back into execution within engine B. This multi-context awareness makes it possible to detect nested XSS, DOM-based scripting, and sandbox escapes that traditional tools miss.

♦ Nine of Diamonds: Obscure or Edge-Case API Abuse

The Forgotten Risk: Most scanners’ rule sets don’t maintain old APIs and obscure libraries, but that doesn’t make them safe.

• The Problem: Older or rarely used libraries can expose dangerous behavior such as obscure deserialization methods, malformed HTTP header setters, or legacy access control calls. These APIs may be safe in most cases but vulnerable under specific conditions.
• Why It’s Missed: Rule-based scanners often skip over APIs that aren’t well-known. If there’s no recent CVE, no GitHub discussion, or no clear signature, the tool ignores it. Over time, these edge cases become blind spots.
• What Qwiet Sees: Based on context and input flow, Qwiet flags unusual function calls that look suspicious. Even if the API isn’t flagged in a rulebook, Qwiet’s ML-generated policies can detect misuse based on its behavior, e.g., passing unsanitized input into a method with a side effect or elevated privilege implication.

Policy Without the Burden of Policy Writing

Unlike tools that depend on brittle regex patterns or manually maintained rules, Qwiet shifts the model entirely. It treats policies as code-aware graph traversals, detecting sinks, tracing flows to exposed APIs, and identifying where validation or sanitization happens. There’s no need to write or update static rules. Qwiet’s AI learns directly from your codebase and evolves with it, allowing security teams to focus on fixing what’s exploitable instead of managing policy logic.

See It in Action

Want to see how a Code Property Graph works in practice?

Download our technical whitepaper to explore how Qwiet’s graph-based engine and AI-driven analysis uncover vulnerabilities legacy SAST tools can’t see. Or, schedule a demo to see how your code looks in the graph.