5 Essential open source product-security tools for developers you need to know

About

This content is brought to you by Jit - a platform that simplifies continuous security for developers, enabling dev teams to adopt a ‘minimal viable security’ mindset, and build secure cloud apps by design from day 0, progressing iteratively in a just-in-time manner.

‍

As cybersecurity becomes increasingly important in software development, the “shift left” security approach is widely recognized as a best practice for ensuring superior product security. Numerous traditional security firms are introducing shift-left products and capabilities, and the concept is gaining traction.

However, the industry is beginning to understand that merely “shifting left” is insufficient in a world of continuous delivery. High-speed, forward-thinking development teams are adopting a new “born left” security strategy. In this approach, security considerations - like many other product aspects - are addressed right from the first line of code. Product security is not just delivered by the development team; it is owned by them.

Recognizing this shift and the potential additional burden on already strained developers, the industry is seeking solutions and tools to help developers manage security while maintaining agility.



We understand that today’s “shift left” open sources are not alleviating the overhead placed on developers due to the noise created and the burden of learning security and navigating each open-source tool. It’s our responsibility to address this issue.

Nevertheless, some open source security tools are more developer-friendly than others. That’s why we’ve compiled a list of five security tools that we believe developers should be aware of. This article provides a brief overview of the top open source software and explains why we consider them to be developer-friendly. We will delve into each security area they cover in our forthcoming post and discuss why you should consider using them.

What makes a tool developer-friendly?

I first wish to define what I mean by ‘dev-friendly’ tools.

To me, a dev-friendly tool makes developers' (and dev leaders') lives easier by either making tasks simpler or speeding up processes. To be more specific:

Open source

Open-source software is free, so there is no need for budget approval, and you can try out a tool without having to commit to it. Instead of lengthy selection processes, you can simply try it and see how you like it. In addition, and it is particularly critical for security tools, they let you read the entire source code 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 in the CI/CD pipeline have a higher value. Once I have used a tool locally and found it to be useful, then, next, I would like it to run continuously as part of my development lifecycle - and not only on my local machine, using up 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, start locally is an advantage, but being then able to easily merge into the environment 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.

Great Documentation

I believe this requires little explanation...

Readily available documentation made for dev professionals can make or break smooth usage. With great “how-to” documentation, ramp-up time is much shorter.

The better the documentation, the shorter the learning or troubleshoot curve and the easier the tool is to adopt.

Configure the output format

If you can output the results of a certain tool in multiple formats, you then allow yourself to pipe results into 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 security tools for developers you should know

Based on the above 5 criteria, I’ve collected five security tools that are dev friendly.

The list aims to cover various family of code analysis tools that should be part of some minimal requirements for security:

• Static application security testing (SAST)
• Dynamic application security testing (DAST)
• Hard-coded Secrets detection
• Infrastructure as Code analysis (IaC)



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 analysis as well.

What makes it unique is that beyond being a plugin, it also available as a CI/CD workflow for GitHub Actions in the Github Marketplace.

‍



Semgrep is a highly-configurable SAST tool, looking for 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 is a great project used for detect very efficiently high-coded secrets based on a configuration file containing hundred 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.

‍



OWASPs Zed Attack Proxy (ZAP) is another open-source tool, used for dynamic scanning (DAST). It can run locally using Docker and is providing a Github workflow to run in the CI/CD pipeline.

The common output for this tool is a report in HTML but you can also get it in JSON using some addon.



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.

Summary - Some thoughts on high velocity development and security

At Jit, our mission is to provide developers with an end-to-end solution for owning product security, from planning, through open-source orchestration, following an MVS approach (Minimum Viable Security).

Development teams are being tasked with end-to-end responsibility and ownership of their products, while all along there’s the pressure to ship code to production with high velocity.

Like 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 on velocity.