B701: Extend Jinja2 checks to cover dynamic template source execution

[invoke1442]

Is your feature request related to a problem? Please describe.
Bandit already has Jinja2-specific checks in jinja2_templates.py (B701 for autoescape=False), but it does not warn when non-literal template source is executed through Jinja2 APIs such as:

from jinja2 import Template

def render(instructions):
    return Template(instructions).render()

or

from jinja2 import Environment

def render(instructions):
    env = Environment()
    return env.from_string(instructions).render()

These patterns are relevant for SSTI-style bugs, even when autoescape is not the issue.

Describe the solution you'd like
It would be useful to extend the existing Jinja2 checks to also flag dynamic template source execution in:

• jinja2.Template(...)
• jinja2.Environment.from_string(...)

A small but important detail is that SandboxedEnvironment().from_string(...) should not be flagged, since that is a common fix pattern:

from jinja2.sandbox import SandboxedEnvironment

def render(instructions):
    env = SandboxedEnvironment()
    return env.from_string(instructions).render()

Describe alternatives you've considered
Implementing a separate rule is possible, but since Bandit already has Jinja2-specific checks, extending the existing Jinja2 rule family would likely be more consistent than adding a completely separate plugin.

Additional context
The goal here is intentionally narrow:

• warn on non-literal template source passed to Jinja2 template construction / from_string
• avoid trying to do full taint tracking
• avoid flagging SandboxedEnvironment().from_string(...)

So this should be a relatively small, focused enhancement rather than a broad new dataflow feature.

Love this idea? Give it a 👍. We prioritize fulfilling features with the most 👍.

[Lifeng-Zhou-China]

How about its practicality in large-scale projects

[invoke1442]

I prepared a self-contained reproducer for this rule refinement.

Environment used in the package:

• Tool: Bandit
• Bandit version: 1.9.4
• Rule id: B960
• Rule name: ssti_usercontrolled_template_entrypoints
• Rule package version: rule6073-bandit-plugin 0.1.0

The package contains 3 samples:

• repro/vuln.py -> Template(instructions) -> should be reported
• repro/plain_environment.py -> Environment().from_string(instructions) -> should be reported
• repro/fixed.py -> SandboxedEnvironment().from_string(instructions) -> should not be reported

Reproduction:

./run_repro.sh

Observed result:

• repro/fixed.py is not reported

This keeps reporting unsafe dynamic Jinja2 template source execution while avoiding the SandboxedEnvironment().from_string(...) fix-side false positive.

b960-sandboxedenvironment-reproducer-attachment.tar.gz

[invoke1442]

@Lifeng-Zhou-China I think it is still practical for large-scale projects, because this is a narrow AST-level refinement rather than a heavy dataflow feature.

It keeps reporting the unsafe dynamic-template entry points (Template(...) and plain Environment().from_string(...)), and only excludes the common SandboxedEnvironment().from_string(...) fix pattern. In practice, that mainly helps reduce fix-side noise at low implementation/runtime cost.

The reproducer above shows the exact expected behavior.