Basically if the library uses eval() it's probably a good idea to avoid it if possible.
Basically if the library uses eval() it's probably a good idea to avoid it if possible.
For example here's Python dataclasses in the standard library using exec() to create the `__init__` and other methods that go on your dataclass:
https://github.com/python/cpython/blob/main/Lib/dataclasses....
Here's Pydantic using it for a jupyter notebook check:
https://github.com/pydantic/pydantic/blob/594effa279668bd955...
here's Pytest using it to rewrite modules so that functions like assert etc. are instrumented by pytest:
https://github.com/pytest-dev/pytest/blob/eca93db05b6c5ec101...
Here's the decorator module using it (as is the only way to do this in Python) to create a signature matching decorator for an arbitrary function:
https://github.com/micheles/decorator/blob/ad013a2c1ad796996...
All of these libraries are completely secure as eval/exec are used with code fragments that are generated by the libraries, not based on untrusted input.
eval() /exec() are not running executable files, just Python code, the same way all the rest of the package is already doing.
My favorite case was when a newbie coder used eval() to evaluate something that looked json-ish, which, came from an api request.
It seems you can’t run bandit on deps, but perhaps if you fork them and build yourself?
If you are security conscious, having a rule that you can only install from a local pypi with packages you have forked would be a more defensible perimeter. But, a maintenance pain for sure.