Technical and Product News and Insights from Rackspace
One of the many benefits of using and working with Python is its ability to
introspect itself. This empowers us to write and use tools to analyze the
projects we use and write. Tools written in Python can use the built-in
module to parse and analyze other Python code into an “_A_bstract _S_yntax
_T_ree”. Perhaps you’ve heard of Flake8, PyFlakes, PyLint, Radon, or another
tool that provides style checking, lint discovery, or complexity computation?
They all use the AST to provide that functionality. There’s also a tool called
Bandit that uses the AST to provide static security analysis of Python
TLS and SSL are two critical technologies which underly much of the secure communications that occur on the internet. Over the past few years, spurred by increasingly effective attacks and a desire for new functionality, SSL and TLS have seen many new features, as well as practical improvements.
Python is currently in a transitional period between Python 2 and Python 3. For
the past few years, all new feature development has been happening on Python 3,
including new features in Python’s
ssl module. This means that Python 3 users
have had acccess to these improvements to TLS, but Python 2 users (still the
majority of Python users) have been falling behind.
In the last several years and with the advent of social coding sites like GitHub, there has been an increasing openness in code sharing. This is great on so many levels as it promotes the open source model, and in general is a nice thing.
One security side effect has been the accidental disclosure of sensitive information in the code that is shared publically. This problem existed before with things like database or SMTP passwords in configuration files but in the world of cloud and API keys this problem increases in its severity.
Whereas database servers were generally well protected and so even accidentally revealing the password was not the worst thing to happen, exposing API keys on public repositories has serious consequences. You have given someone the keys to your whole cloud kingdom. With these keys one can spin up servers, view your data, upload illegal data and the list goes on. Hackers are most likely searching on these repositories for such information.
We recently had a good debate in the Rackspace tech community on this topic and this post tries to present some best practices and also some ways to clean up should it happen.