Welcome to Ansede Discussions!

[mattybellx]

RFC: Taking Ansede Static to the Next Level (Enterprise-Grade SAST)
The Vision
First off, a huge thank you to everyone using and contributing to ansede-static. We've built an incredibly fast, offline, zero-dependency engine that excels at catching the logic bugs (like IDOR and Missing Auth) that traditional regex-based scanners miss.

Right now, our AST-based heuristics are strong. However, to evolve from a "pattern-hunter" to a true vulnerability prover—capable of competing with enterprise tools like CodeQL or Semgrep Pro—we need to move beyond single-file Abstract Syntax Tree (AST) traversal.

We are opening this discussion to plan the three major architectural upgrades required to make ansede-static a full-release, state-aware engine.

The 3 Core Upgrades

1. Control Flow Graphs (CFG) for Path Sensitivity
   Currently, we read code structurally. If our engine sees user input hitting a database execution, it flags it. But it struggles to evaluate if an if statement prior to that execution securely guards the code.

The Goal: Build an intermediate layer that translates the AST into a Control Flow Graph (CFG). This will allow the engine to "walk" execution paths and dramatically reduce false positives by recognizing when a threat is neutralized by an authorization check or validation step.

Discussion point: Should we build a lightweight CFG generator from scratch to keep our zero-dependency promise, or integrate an existing lightweight library?

2. Type Inference & Resolution
   Dynamic languages are notoriously hard to scan. Right now, if the engine sees data.execute(input), it might not know if data is an unsafe shell wrapper or a harmless custom object.

The Goal: Add a semantic type-tracking layer. For Python, this means parsing typing hints and tracking variable inheritance. For JS/TS, this means potentially hooking into the TypeScript Compiler API's TypeChecker.

Discussion point: How can we best achieve semantic awareness without heavily bogging down the scan speed?

3. Global Cross-Module Call Graphing (Deep Inter-procedural Taint)
   While we have local inter-procedural taint tracking, modern vulnerabilities often span multiple files. Data enters a route in api.py, is processed in logic.py, and is executed in database.py.

The Goal: Implement a pre-scan "Linking Phase." We need to build a global registry of functions and classes to create an application-wide Call Graph. This will allow us to track tainted variables across file boundaries seamlessly.

Discussion point: What are the most memory-efficient ways to represent a whole-project graph in memory before executing the ruleset?

How You Can Help
We want to hear your thoughts before we start writing code!

Maintainers & Toolsmiths: What pitfalls have you seen when implementing CFGs or Call Graphs in Python/JS?

Security Researchers: What edge cases in type inference usually cause the most false positives?

Contributors: Which of these three pillars interests you the most? Drop a comment below if you want to help architect one of these modules.

Let's build the best open-source, zero-dependency SAST out there. Drop your thoughts, feedback, and architecture ideas below! 👇

[mattybellx]

please read https://github.com/mattybellx/Ansede/blob/main/Ansede_SAST_Architecture_Blueprint.md

[CloudJunkie420]

Отличный инструмент.