Injection Path Detection: Griffin AI vs Mythos

A SQL injection finding that says "this query() call is dangerous" is not a finding. A finding that says "user input from the /login endpoint flows through these eight functions and reaches query() unsanitized" is. The shape of the report determines whether engineering can act on it. Griffin AI is built around path-first analysis; Mythos-class general-purpose tools tend to operate sink-first, and the difference shows up directly in the actionability of the output.

What path-first analysis means

The taint path — source → intermediate transformations → sink — is the actual vulnerability. The sink alone is just a function call. Path-first analysis treats the path as the unit of work: every taint analysis result is a path, with explicit source, sink, and intermediate steps. Findings are paths, not sinks.

Sink-first analysis lists every dangerous-looking function call in the codebase and asks the user to determine whether each is reachable from untrusted input. The work of figuring out the path is left to the consumer.

For an SQL injection scanner, the difference is concrete: path-first surfaces "input from request body reaches query() through the formatOrderId helper without parameterization" — sink-first surfaces "this codebase has 47 query() calls" and leaves the engineer to evaluate each.

Where pure-LLM tools land

Mythos-class tools usually fall somewhere between the two. The model is asked to identify suspect call sites and produces output that mixes signal and noise. The path information, when included, is often partial — covering one or two hops rather than the full source-to-sink walk.

The failure mode for security teams using sink-first or partial-path analysis: every finding requires investigation. The triage cost per finding stays high; the team gets through fewer findings; the backlog grows.

How Griffin AI structures the output

Each injection finding includes:

• Source. Specific entry point (HTTP route, message queue handler, file reader) with the parameter or property carrying the taint.
• Path. Ordered list of functions traversed, each with the taint variable name and any transformations applied.
• Sink. The dangerous call, the argument that receives the taint, and the dangerous behaviour (raw string concatenation, dynamic table name, etc.).
• Sanitizer status. Whether any sanitization was applied along the path; if so, whether it was appropriate for the sink.
• Exploit hypothesis. A concrete payload that would trigger the vulnerability through the identified path.
• Suggested fix. The minimal change that closes the path — typically the appropriate sanitizer or the parameterized API at the sink.

This structure makes findings reviewable in minutes rather than hours.

Coverage across injection classes

Path-first analysis applies the same approach to multiple injection classes:

• SQL injection with raw string concatenation, dynamic table/column names, and unsafe ORM usage.
• NoSQL injection in MongoDB, Redis, Elasticsearch query construction.
• Command injection through exec, spawn, shell invocation patterns.
• Path traversal through file reads, includes, and template rendering.
• LDAP injection through unsanitized DN construction.
• XPath injection in XML query construction.
• Server-side template injection in Jinja2, Mustache, Handlebars, EJS, and similar.
• Header injection / response splitting through unsanitized header values.

Each follows the same source → path → sink → sanitizer-status structure. Customers get consistent reporting across classes; engineering teams get a consistent fix workflow.

A concrete example

A Spring Boot application has a controller method that takes a sortBy query parameter and constructs a JPA query string with it. The taint path:

1. Source: @RequestParam String sortBy in OrderController.list().
2. Hop 1: sortBy passed to OrderService.listSorted(sortBy) unchanged.
3. Hop 2: OrderService constructs a JPQL string: "SELECT o FROM Order o ORDER BY o." + sortBy + " ASC".
4. Sink: entityManager.createQuery(jpqlString) executes the constructed string.
5. Sanitizer status: none. No allowlist check. No JPA criteria builder.

Griffin AI surfaces this as one finding with the full path, the dangerous behaviour ("dynamic ORDER BY column injection allows arbitrary expression evaluation in JPQL"), the exploit hypothesis (sortBy=id; UPDATE Orders SET status='paid' WHERE 1=1 --), and the suggested fix (allowlist sortBy against the known column set).

A sink-first or partial-path tool surfaces "the createQuery call uses dynamic content" and leaves the engineer to walk back to the source manually. The same vulnerability, very different time-to-remediation.

What to evaluate

Three concrete checks during procurement:

1. Show the platform a vulnerable application with a 5-hop SQL injection path. Does the output include the full path, or only the sink?
2. Show the platform an injection that has been partially mitigated with an inappropriate sanitizer. Is the partial mitigation correctly identified?
3. Look at five findings the platform produces. Can a senior engineer review each one in under 10 minutes?

The third check is the operational truth. Findings that take longer than 10 minutes to evaluate are findings that compete for time the team does not have.

How Safeguard Helps

Safeguard's path-first injection analysis covers SQL, NoSQL, command, path, LDAP, XPath, template, and header injection classes consistently. Findings include source, path, sink, sanitizer status, exploit hypothesis, and suggested fix as structured data. Griffin AI generates the exploit hypothesis and the fix recommendation; the deterministic engine produces the path. For organisations whose triage backlogs are dominated by injection findings, the path-first structure compresses time-to-remediation by an order of magnitude in customer-reported metrics.