Today we added a section to our website to highlight open source software that we have been working on.
For years we have been contributing to open source security software. But even with our contributions, it is pretty clear that we are net winners in the grand scheme of things - or to say that another way - we use more open source than we are able to contribute.
In addition, we have found that in many cases, designing for open source actually makes our tools better. Specifically, if we build something truly custom for a client, it can be very myopic - focused on exactly their problem. When we look at it as open source, we imagine the related use cases and get better and broader feedback to round out the tools features. Not only that, if you want to use a tool and can actually update it, influence the roadmap, and take it from one place to the next, that could be hugely valuable.
Ultimately, there are plenty of problems to solve - so it seems like the least we can do as a thriving company is to try to contribute to the broader good. Sometimes that means our clients have to also be on board to open source work they are paying us for. So we owe them a debt of thanks too.
We wrote the GAA (Go Away Auditor) tool because we wanted to make it easy to do user audits on the platforms we commonly see our clients using: Google Apps, AWS and GitHub.
In the short term, we should be adding better data structures and automation templates so that this can be integrated into a CI/CD pipeline and people can get automated user audits.
We may also make it easy to push these results into securityprogram.io. One thing we’re seeing is a potential area to release a tool that can be used on its own but may have certain value when managed or data is collected from it and stored over time. That way, we can publish open techniques and provide ways to extend and integrate tools while also providing the managed data collection and lifecycle that many folks also need. Kind a neat new paradigm for us.
We built S3S2 for a client that wanted lots of partners to be able to securely share data with them in S3. While the clients practices in AWS and S3 were solid, there was a lot of fear that partners would make mistakes with data and not handle it properly. So S3S2 is designed to allow:
Company A to build a profile and generate keys. Then distribute the program, the config and the public key to N partners.
Then each partner can use S3S2 to push files to S3 where they would be encrypted potentially both with GPG and AWS SSE (via KMS). But S3S2 wouldn’t let them push files if they weren’t encrypted.
Glue has received by far the most time from our team and has been a longstanding area of focus. Glue is built in Ruby and aims to be the glue in the dev tool chain that makes it easy to run arbitrary security tools and get results in the places we most want them (eg. Jira).
An example of the intended workflow with Glue is:
Linked in references is a talk where I talk about Glue and live code a new tool.
We have lots of ideas for open tools. Some are harder than others. Some require more input or resources. A smattering:
We actually have a network scanner, a cloud scanner, a code review assist tool and a cloudtrail log analyzer that we built that we might open source.
What new open source software would you like to see? Maybe we can build it together?