I have been asked many times over the year how I have my python development environment setup, and while some of the tooling has changed a little over the years, the changes have been surprisingly minor. I figured it was about time to document what I’m using, and how I have it all setup.
What I Use I have been using a Mac as my primary workstation since some time in 2004, so I will warn that some of this tooling is fairly MacOS specific, however most of it should be usable regardless of the operating system you’re on.
As pyTenable starts to near it’s 3rd birthday, I’ve started working on a complete rewrite of the codebase. For a number of reasons, the current v1 code has become a monstrosity of tests, repeated code, and assumptions in the APIs that are no longer correct. Thats not to say that it doesn’t work, or even work well for what folks are using it for, just that code maintainability has been a concern as of late.
The more integrations I write the more it becomes apparent that there is no consistency in User-Agent strings for the purposes of identification of whom is making what calls. It’s something that folks are supposed to do with making API calls, yet most folks don’t even bother with it. It creates nothing but issues when the people managing the application you’re talking to doesn’t inform the admins who you are or what you’re doing.
With all of the work thats been done with the pyTenable library, I reached a point where I was using pyTenable’s core APISession, APIEndpoint, and APIIterator classes a lot for external work. It seemed only logical to separate these base classes from pyTenable and wrap them up into their own library to act as a framework for folks looking to build their own API libraries. The end result of this is the new Python RESTfly library, which is focused on providing a basic scaffolding to make writing API libraries similar to pyTenable’s easy and and effective.
So I decided to start looking at Visual Studio Code with most of the folks I know dropping Sublime like it’s a bad habit and see what all of the hubbub is about. I will have to say that after some tweaking I’ve been pleasantly surprised with how well VSCode works. It’s taken a lot less tweaking to get it to a point where I’m happy with it than it ever did with Sublime Text, and it even has some really nice features out of the box for Python.
The pyTenable library has been rapidly evolving over the past few months. The library has seen a lot of expansion and maturation over the last several weeks. Going from version 0.1.0 at the time of last post to now 0.3.3, there has been a lot of work done to lay scaffolding for the SecurityCenter package. SecurityCenter (recently re-branded as Tenable.sc) is as large, if not larger a project as Tenable.io was.
After nearly 8 months of on-and-off development (mostly off, day-job work keeps my busy), I’m proud to announce that pyTenable has hit version 0.1.0. While this may not seem like much, it’s been a lot of work to bring it across this line in the journey so far. All of the Tenable.io Vulnerability Management API are now pythonized. Further everything in the tenable_io module has been tested out (519 tests!). Tenable has also seen fit to link to pyTenable as an official module for working with our products.
I have started working through all of the various fabric files I have and started centralizing them and cleaning them up for general consumption. These fabric scripts cover a variety of tasks from deployment and maintenance of various products to deploying some of my code. I will be updating the repository as needs arise, and as always am welcome to any input.
Using my fabric files is actually pretty simple, however you need to have fabric installed on your workstation before anything will work.
I’m proud to announce the general availability for pySecurityCenter version 2.1.x accessible from PyPI immediately. pySC 2.1 supports connectivity to SecurityCenter 5, which leverages a completely new RESTful API. Because of this, the pySC SecurityCenter 5 support will be an evolving process. Whats implemented today will not be changing, however many of the convenience functions that pySecurityCenter has for SecurityCenter 4.x have not been coded into the SC5 module, as enumeration for the API is still active.