
Finding secrets in Python source code - ryan_lane
https://eng.lyft.com/finding-a-needle-in-a-haystack-b7e0627b01f6#.x7et0d9t4
======
wyldfire
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](https://github.com/openstack/bandit)

[2]
[https://github.com/openstack/bandit/blob/430dfceca9cebd7ebe4...](https://github.com/openstack/bandit/blob/430dfceca9cebd7ebe4c808f65bcace22965911e/bandit/plugins/try_except_pass.py)

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

~~~
nbadg
I would be ecstatic if Bandit integrated with Code Climate.

But wait, there's more! 18F is discussing pushing for exactly that. [1]
There's also a sorta-recent call on Twitter to figure out interest. [2] Speak
up if you think it would be useful!

[1] [https://trello.com/c/PTL7z9uU/20-investigate-writing-a-
code-...](https://trello.com/c/PTL7z9uU/20-investigate-writing-a-code-climate-
platform-engine-for-bandit)

[2]
[https://twitter.com/aidanfeldman/status/695670289879928832](https://twitter.com/aidanfeldman/status/695670289879928832)

------
tyingq
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...](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwjcvMTKt-
vKAhWhloMKHSEZB50QFghEMAE&url=http%3A%2F%2F0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com%2F12058-woot13-kholia.pdf&usg=AFQjCNEkxjJCRSHvlUSJq6GcOW97ieZp_A&sig2=IUF09dc40fq8G0kUFWI3CQ)

------
pm90
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.

~~~
ryan_lane
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".

