6 comments

[ 3.3 ms ] story [ 34.7 ms ] thread
This article's interesting. But my biggest takeaway is the existence of Bandit [1]. It looks really neat.

This "try_except_pass" check for example [2], is a great one. It might be rated "Low" severity from a security context. But from a functionality point-of-view, it's high on my list. It masks NameError among many others. You very nearly always want NameError to propagate, lest you conceal a glaring design error.

[1] https://github.com/openstack/bandit

[2] https://github.com/openstack/bandit/blob/430dfceca9cebd7ebe4...

Yeah. Bandit is really nice. We're also really excited about it and are working on enabling many of the checks :).
This bit is interesting:

"Thanks also to the Dropbox product security team for feedback on docs and signal/noise issues"

Dropbox, as I remember it, is distributed as "encrypted" pyc files and a modified python runtime that decrypts them. This implies that "secrets" are in their python runtime binary.[1]

Makes you wonder what their feedback on signal/noise was,then...perhaps something that kept this from being used to trivially retrieve the keys :)

[1] https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...

Excellent idea. I would assume there would be many false positives when adding unit tests (e.g. faking out a password), so I wouldn't be so sure to add it to an automated gating system. Although, I guess you can choose non-random strings for unit tests.
There's also the option of using "# nosec" for those parts of the code. I opened an issue upstream to be more fine-grained about nosec, to be able to disable individual test numbers, like "# nosec-B103".