What problem are you trying to solve?
The roadmap calls for Regex-based detection. This is trivial to evade, and I fear will create more gaps in detection. For example, an obfuscated infostealer may be missed by a purely regex based detection.
What feature would solve this?
AST-level call/argument inspection
This is a proven detection method that scales well and minimizes false negatives. It's the core logic behind PyCQA's Bandit. Rather than relying on regex, we imitate Bandit's code --> AST and use that to detect potentially malicious behavior. The correlation point remains the same if we want it to.
| Signal |
AST shape |
| Sensitive-dir enumeration |
os.path.join / pathlib.Path with credential-path string args (~/.ssh, ~/.aws/credentials) |
| Credential-pattern regex |
re.compile() / re.findall() where the pattern arg contains credential labels (password, token, secret) |
| SSL verify disabled |
verify=False keyword arg on HTTP calls, ssl._create_unverified_context() |
| External config fetch |
Network calls (STDLIB002 overlap) with URL args pointing to pastebins, raw gists, IP literals |
| Value truncation before send |
[:N] slice on file-read / env-lookup results flowing into network calls |
What does success look like?
Detection works on AST, not source text:
- A credential-harvesting
setup.py with whitespace/comment injection between the call and its arguments still fires signals. Regex-based detection would miss this.
- Obfuscated credential paths built via string concatenation (e.g.,
os.path.join(home, ".ss" + "h")) are caught via the resolver.
False-positive calibration:
- A legitimate SSH utility that reads
~/.ssh/config and makes no network calls does NOT promote to HIGH.
- A package that uses
re.compile(r'password') for config parsing with no network/file exfil does NOT promote.
- A package that sets
verify=False with an inline comment (test/dev context) fires the individual signal but does NOT trigger cluster promotion alone.
Anti-goals:
- No baseline or training phase. Every scan is standalone.
- No cross-file correlation in v0.13.0. Signals correlate within a single file only.
- No new runtime dependencies.
- No changes to existing STDLIB signal IDs or behavior. CRED signals get their own ID range.
- Not a general-purpose taint tracker. The truncation-before-send signal uses scope-local heuristics, not interprocedural data flow.
What alternatives have you considered?
I thought about imitating tree sitter, but I opted to go with the logic that Bandit uses as it is purpose built for the Python ecosystem. As shown above, I did consider Regex, but I strongly believe that this will provide stronger detection logic than regex alone.
Why does this matter?
The roadmap lists credential-exfil detection with regex-based approaches for credential-pattern matching. Regex on source text is the weakest detection surface pydepgate could choose here. It's trivially evaded by string concatenation, variable indirection, whitespace injection, or comment insertion between tokens. AST-level call/argument inspection with resolver-backed partial evaluation is meaningfully harder to evade. The attacker can't defeat it with "pass" + "word" because the resolver reconstructs the value. They can't defeat it with whitespace or comments because the AST discards those. They can't defeat it with variable indirection for simple cases because get_qualified_name already resolves dotted attribute chains. This is detection that regex fundamentally cannot provide, and it fits cleanly into the analyzer architecture pydepgate already has.
How critical is this to your use of pydepgate?
Blocking. I can't adopt pydepgate without it.
Estimated implementation effort (your best guess)
- Large
Does this have security implications?
Yes. This directly affects security behavior.
Security notes (if applicable)
This is core detection logic so, by definition, this affects security behavior. In my opinion, it strengthens pydepgate and uses Python strengths to its advantage.
Context (optional)
No response
Before submitting
What problem are you trying to solve?
The roadmap calls for Regex-based detection. This is trivial to evade, and I fear will create more gaps in detection. For example, an obfuscated infostealer may be missed by a purely regex based detection.
What feature would solve this?
AST-level call/argument inspection
This is a proven detection method that scales well and minimizes false negatives. It's the core logic behind PyCQA's Bandit. Rather than relying on regex, we imitate Bandit's code --> AST and use that to detect potentially malicious behavior. The correlation point remains the same if we want it to.
os.path.join/pathlib.Pathwith credential-path string args (~/.ssh,~/.aws/credentials)re.compile()/re.findall()where the pattern arg contains credential labels (password,token,secret)verify=Falsekeyword arg on HTTP calls,ssl._create_unverified_context()[:N]slice on file-read / env-lookup results flowing into network callsWhat does success look like?
Detection works on AST, not source text:
setup.pywith whitespace/comment injection between the call and its arguments still fires signals. Regex-based detection would miss this.os.path.join(home, ".ss" + "h")) are caught via the resolver.False-positive calibration:
~/.ssh/configand makes no network calls does NOT promote to HIGH.re.compile(r'password')for config parsing with no network/file exfil does NOT promote.verify=Falsewith an inline comment (test/dev context) fires the individual signal but does NOT trigger cluster promotion alone.Anti-goals:
What alternatives have you considered?
I thought about imitating tree sitter, but I opted to go with the logic that Bandit uses as it is purpose built for the Python ecosystem. As shown above, I did consider Regex, but I strongly believe that this will provide stronger detection logic than regex alone.
Why does this matter?
The roadmap lists credential-exfil detection with regex-based approaches for credential-pattern matching. Regex on source text is the weakest detection surface pydepgate could choose here. It's trivially evaded by string concatenation, variable indirection, whitespace injection, or comment insertion between tokens. AST-level call/argument inspection with resolver-backed partial evaluation is meaningfully harder to evade. The attacker can't defeat it with
"pass" + "word"because the resolver reconstructs the value. They can't defeat it with whitespace or comments because the AST discards those. They can't defeat it with variable indirection for simple cases becauseget_qualified_namealready resolves dotted attribute chains. This is detection that regex fundamentally cannot provide, and it fits cleanly into the analyzer architecture pydepgate already has.How critical is this to your use of pydepgate?
Blocking. I can't adopt pydepgate without it.
Estimated implementation effort (your best guess)
Does this have security implications?
Yes. This directly affects security behavior.
Security notes (if applicable)
This is core detection logic so, by definition, this affects security behavior. In my opinion, it strengthens pydepgate and uses Python strengths to its advantage.
Context (optional)
No response
Before submitting