Were you aware that there is a security project for OpenStack? I recall hearing about it at the Grizzly summit, specifically around the Vulnerability advisories that had just become widely available, but beyond that I wasn’t aware that there was much else going on! It turns out that beyond the advisories (that users submit as they are found and fixed/addressed), there is a proper process for submitting a security bug so that the potential vulnerability is hidden from public view until it can be verified and a patch created. Unfortunately, the process is not well know, and even the speakers at this evening’s OpenStack SV meet up were aware that most developers are either completely unaware, or just don’t think until after they’ve already submitted a patch to Gerrit (by which time it’s too late to ‘hide’ the patch until it’s accepted). This is a real issue given that the goal is to embargo security vulnerabilities until an accepted patch is available, and managers of public OpenStack systems have had a chance to patch their systems!
Bandit - security lint function against any Python project Click To Tweet
Two key projects that can help OpenStack projects reduce security vulnerabilities are the Bandit project, which provides a security lint function (developed for OpenStack, but works on any Python project), and Syntribos, which creates fuzzed inputs (large blogs of random data), to test for overflow or other input vulnerabilities.
A demo of Bandit looked at the class of errors currently in some randomly selected OpenStack projects, and while there were a large number of Low priority issues and a few Medium severity issues, there were no High priority issues found, which seems like a good thing! The presenters also mentioned that they hoped that more folks would focus on fixing even the low priority issues, as any potential issue could end up providing an attack vector.
Syntribos - Fuzz your API inputs for security Click To Tweet
The other project that was highlighted was the Syntribos project, which is designed to create Fuzzed inputs against the API interfaces to OpenStack projects (or likely any API based project). There is more setup required than for Bandit (which as a linter, just needs to be run against a project), but the results can help catch otherwise difficult to find security gaps. This project is one that could really use some hands on support from the community to get better coverage against the myriad of OpenStack projects.
While not the most exciting topic for many attendees (many of whom I suspect were more interested in general functionality in the OpenStack space), there was good engagement, and a couple of interesting Q&A questions as well. The one that had many people interested was a question about a compliance validation test/suite/tool to ensure some baseline level of functional security for an OpenStack service. The presenters pointed to a project that was effectively just announced last week, the ansible-openstack-security project, that actually looks at securing the underlying OS on which OpenStack runs. This project specifically was one that was mentioned both as a “good thing” and as an example of what might be needed in the OpenStack community not only for the platform (where it’s targeted) but for the service itself.
The latest from #OSSFO on #OpenStack #Security from the January SV meetup Click To Tweet