With product security becoming an increasingly important aspect of software development, “shift left” is gaining wide acceptance as a best practice to ensure security is baked into development early. More and more traditional (read: incumbent) security companies are releasing shift-left products and capabilities, and the practice is becoming almost de facto for engineering teams.
However, the industry has begun to realize that simply “shifting left” is hardly enough for a continuous delivery world. High velocity, progressive development teams are embracing a new and trending “born left” security approach, where security aspects - like more and more product-related aspects - are addressed starting from the first line of code. This means product security isn’t just delivered by the developer team, but is rather owned by them.
Understanding this shift, comes with the realization that already burdened developers are faced with additional responsibilities that are continuously dropped in their lap. This has led the industry to hunt for ways to provide solutions and tools that help developers manage this growing workload, including security, and maintain velocity.
We acknowledge that currently the open source “shift left” tooling doesn’t solve the overhead put on the developers (due to the noise these create, and the burden of learning security in general and the ropes of each open source tool). That is on our shoulders to solve.
But still, not all open source tools are created equal, and there are quite a few open source security tools that are not-only developer-friendly, but provide much-needed security controls early in the development cycle. That’s why we’ve compiled a list of 5 security tools that we believe all developers should know about, and consider adopting if they do not have such a control currently in place. This post will provide a quick overview of what makes a tool developer-friendly. We will then introduce a tool per security domain and its coverage, do a quick dive into how they work, and why you should consider adopting it into your toolchain.
What makes a tool developer-friendly?
Let’s start by defining what makes tools ‘dev-friendly’ in the first place.
To me, a dev-friendly tool sets out to make developers (and dev leaders) lives easier by either simplifying tasks or speeding up processes.
Open source
One of the greatest benefits of open source tools is that they are free to use (of course check the license first!), so there is no need for budget approval, and you can try a tool out locally (you should probably make sure to verify before using it on any company resources - more on that later), without having to commit to it. Instead of lengthy selection processes, you can simply try it out and see how you like it. In addition, and this is particularly critical for security tools, as the name implies, they provide you access to the entire codebase, so that you don't have any surprises regarding what actions the tool is performing when running it in your environment.
Runs locally first...
Running code locally from your terminal allows software developers to launch and test code with one simple command. The ability to run a tool locally ensures that you can get immediate feedback and easily tweak the configuration. When launched from a container, you don't even have to bother with possible environment issues related to compilation.
... and then in the CI/CD pipeline
Tools that can be integrated into the CI/CD pipeline have higher value. Once I have used a tool locally and found it to be useful, then my next move would likely be to run it continuously as part of my development lifecycle - and not only on my local machine, consuming my local resources. Of course, once a tool and process is part of the pipeline, the benefits are also extended across the entire dev team and codebase. So, starting locally is an advantage, but then being able to easily integrate the new tool into existing environments and processes is an advantage as well.
Part of the developer work environment
Developers should not be wasting time switching between development tools and security tools. All the tools on this list either run in the CI/CD pipeline (e.g. Github Actions) or as a plugin into the IDE. Context switching has been proven to adversely affect flow and productivity. The less context switching, the greater the development velocity, and happiness.
Great Documentation
I believe this requires little explanation...if a user doesn’t know how to use your tool practically then, you’ve gained very little by releasing it.
Readily available documentation made for dev professionals can make or break a smooth user experience. With great “how-to” documentation, ramp-up time is much shorter.
The better the documentation, the smoother the learning curve, and the easier to troubleshoot, making the tool significantly easier to adopt.
Configurable output formats
If you can receive a tool’s output in multiple formats, it then becomes possible to ingest this output by another tool through an API or other form of integration, allowing you to manipulate and analyze results in other tools. If results are only readable by humans, what you can then do with those results is limited and requires human effort - i.e. time that you simply don’t have.
So without further ado...
5 Open Source Security Tools We Love - And You Should Too
Based on the 5 criteria above, I’ve collected five security tools that are dev friendly, and I’ve enjoyed using them as a security engineer.
The list aims to cover various domains of code analysis tools that should be a part of minimal requirements for security applied to development processes:
- Static application security testing (SAST)
- Dynamic application security testing (DAST)
- Hard-coded Secrets detection
- Infrastructure as Code analysis (IaC)
Pycharm Python Security Scanner
Pycharm Python Security Scanner is a security scanner for Python code wrapped as a Pycharm plugin, checking for vulnerabilities while also suggesting fixes. Alongside acting as a comprehensive security scanner, it also offers some additional extensions that can run dependency check analyses as well, which are quite useful.
What makes it unique is that beyond being a plugin, it is also available as a CI/CD workflow for GitHub Actions in the Github Marketplace.
Semgrep
Semgrep is a highly-configurable SAST tool that looks for recurring patterns in the syntax tree. It can either run locally using Docker or be integrated into the CI/CD pipeline with Github Actions.
Results are delivered as JSON files, allowing you to pipe the results into other tools, like jq in order to manipulate them.
gitLeaks
Gitleaks is a great project used to quickly detect hard-coded secrets based on a configuration file containing hundreds of built-in regex expressions tailored to find API keys of popular SaaS. It can run locally using Docker and or be integrated into the CI/CD pipeline with Github Actions. Results are delivered in various formats.
The rules can be easily extended to match your internal patterns and homegrown tools as well.
ZAP
OWASP's Zed Attack Proxy (ZAP) is another open source tool, used for dynamic scanning (DAST) built by the OWASP team (the same folks who gave us the Top 10 Security Vulnerabilities). It can run locally using Docker and provides a Github workflow to run in the CI/CD pipeline.
The common output for this tool is an HTML report, but you can also receive the output in JSON with an addon.
KICS
KICS is used to perform code static analysis of infrastructure, and includes about 1,400 rules supporting various platforms like Terraform, CloudFormation, Ansible or Helm Charts. It can run locally using Docker and can be integrated into the CI/CD pipeline with Github Actions.
High Velocity Development and Security
Development teams are being tasked with end-to-end responsibility and ownership of their products - whether it’s production readiness, performance or security, while all along there’s the pressure to ship code to production with high velocity.
This growing challenge is what set us out on a mission at Jit, to ease this growing burden on developers making the ownership of product security much simpler - from the planning, through open source orchestration and more, based on an MVS approach (Minimum Viable Security). Basically this manifesto says start small, and constantly iterate, you don’t need to build a fortress on Day 1, but have baseline security controls, and grow from there.
As I mentioned above, while dev-friendly security tools offer great benefits, the growing responsibility assigned to developers requires a shift in today’s approach - one that requires a minimum viable mindset and automated orchestration, so that devs will be able to own product security without compromising velocity.
Top comments (1)
I heart OSS - great writeup and shout out to some excellent projects.