Here’s an interesting slightly different spin on the otherwise tired “Open Source” vs. “Closed Source” being more secure debate!
The topic is inspired by a conversation with a client that is using a whole slew of old open source libraries. They know they need to update those libraries, but it is very difficult because they are using them as part of a distribution of a commercial product that they are paying for. So, they buy XYZ product and pay good money for it. XYZ product brings in all of these dependencies that are problematic. The customer can’t update the libraries because it may break the commercial product and because the commercial product is large and not open source, they can’t see and edit the code to fix issues that arise. Ultimately, it seems like that’s the vendor’s responsibility. But that doesn’t mean they see it that way.
The obvious avenue for recourse is to tie payment to keep the libraries up to date. That isn’t standard contract language … yet.
Another way to hedge in this situation is, of course, to avoid commercial platforms that don’t have a strong track record of updating their dependencies. It would be interesting to see a scorecard or standardized assessment method to keep track of which vendors and which products do well keeping up with updates in their dependencies. It seems like it might be relatively easy to ascertain …
In this case, we have an organization that went all in on a commercial platform and even has their own code built on top of it. Now they wonder if they should have built from a lower level base so that they wouldn’t be locked into a platform that they really can’t update. Interesting design decision, right!?
We spend a fair amount of time building and using OWASP Glue to improve security automation at clients. The idea is generally to make it easy to run tools from CI/CD (eg. Jenkins) and collect results in JIRA. In a way, Glue is like ThreadFix or other frameworks that collect results from different tools. Recently, we thought it would be cool to extend some of what we were doing to AWS. We have our own scripts we use to examine AWS via APIs but we realized that Scout2 was probably ahead of us and it would be a good place to start.
The fine folks at NCCGroup wrote and open sourced a tool for inspecting AWS security called Scout2. You can use it directly, and we recommend it, based on the description here: https://github.com/nccgroup/Scout2. It produces an HTML report like this:
For most programmers, running Scout2 is easy. It just requires a little bit of python setup and an appropriate AWS profile. So it wasn’t so much the barrier to entry that made us want to integrate it into Glue so much as the idea that we could take the results and integrate them into the workflow (JIRA) that we are using for other findings from other tools. We thought that having an easy way to pull the results together and publish them based on Jenkins would be pretty useful.
What’s Coming with Glue
Glue has been a fun project that we’ve used opportunistically. The next set of goals with Glue is to clean it up, improve tests and documentation and prepare for a legitimate 1.0 release. At that point, we’ll probably also try to get Glue submitted for Lab status as an OWASP project.
Today I gave a talk at a company’s internal security conference about automation. The slides are on speakerdeck. A video is on vimeo.
The point of the talk was threefold:
- Explain where automation works well and examples of where we use it with OWASP Glue
- Explain newish cool automation like cloud analysis and pre-audit preparation
- Talk about how really, automation can only get us so far because we need the interaction and communication to fix things
I’d be interested to hear feedback!
Here at Jemurai, we have at least a few Hamilton fans. OK, I might be the biggest … but I’m definitely not alone.
At our quarterly meeting in early April, we were talking about our window of opportunity and “not throwing away our shot”, and somehow we started talking about “The Ten Duel Commandments” song and how cool it would be to do a version of it for the OWASP Top 10.
After no more than a few days later, one of our key contributors, Corregan Brown, had written lyrics. A week later we had an audio version. Now here’s a video to back it up. All written and produced by Corregan. I enjoy it because it is factual, educational, clever and fun. Thanks, Corregan!
Of course, this is just an artistic rendition to draw attention to the great work OWASP and the Top 10 project team has done.
Ten OWASP Commandments from Jemurai on Vimeo.
There have been several recent improvements with Glue. Its been awesome to have more people committing to the project and adding in different ways.
One is related to ZAP integration, which is finally getting more of the attention it needs. Another is related to reporting to JIRA. Still another is a way to fail builds only on certain thresholds of errors. We have also been working on integrations for Contrast and Burp. We’ve added a more representative Jenkins Build Pipeline integration example.
We added support to search for entropy in passwords via TruffleHog.
What would you like to see in Glue? Where do you think we need to be to get to a credible 1.0?
At Jemurai, we contribute extensively to OWASP Glue and use it on some of our projects where it makes sense to tie together automation around security. We kept seeing the same types of integration challenges and found that it was useful to have a common starting point to solve them. It is far from perfect and we would refer people to alternatives like ThreadFix and OWTF
What is Glue?
Glue is basically a Ruby gem (library) that knows how to run a variety of security tools, normalize the output to a set structure and then push the output to known useful places like Jira. We package Glue in a docker image to try to make it easy to set up all the different important moving parts (eg. Java, Python, Ruby and tools). You can get and run Glue from docker as easy as:
docker run owasp/glue:0.9.3
Or, for a more helpful example, we can run brakeman and get the output as follows:
docker run --rm owasp/glue:0.9.3 -t brakeman https://github.com/Jemurai/triage.git
The idea behind Glue is to be able to process different types of files via Mounters. Then to be able to analyze using different Tasks, filter with different Filters and report with different Reporters (CSV, Jira, Pivotal, etc.). Ultimately, there are the concept of stages that can be easily extended. The reason I’m writing the post today is because I wanted to add a Bandit task and it was so easy that all I had to do was add this one file: https://github.com/OWASP/glue/blob/master/lib/glue/tasks/bandit.rb.
When I was done, you could run bandit from the Glue docker image and push results to Jira or anywhere else:
docker run --rm owasp/glue:0.9.3 -t bandit https://github.com/humphd/have-fun-with-machine-learning.git
The following diagram illustrates the stages of the pipeline of functions that Glue performs.
Check out Glue or reach out if you want to talk about some of the common challenges in security automation.