With product security becoming an ever-more important aspect of software development, security “shift left” is gaining wide acceptance as a best practice to ensure high quality of product security. More and more traditional security companies are releasing shift-left products and capabilities, and the term is gaining momentum.

However, the industry starts realizing that just “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 aspects of the product - are addressed starting from the first line of code and product security isn’t just delivered by the developer team, but is rather owned by them.

Understanding this shift, and realizing the burden potentially added (that comes along) on top of the already burdened developers’ shoulders, the industry is hunting for ways to provide solutions and tools that may help developers manage security and keep agile.

We acknowledge that today, “shift left” open sources aren’t solving the overhead put on the developers (due to the noise created, and the burden of learning security and learning the ropes of each open-source). That is on our shoulders to solve.

But, still, some open source security tools are way more developer-friendly than others, that’s why we’ve put together a list of 5 security tools that we believe developers should know of. This post is providing with a quick overview of those tools and why we consider them developer-friendly. We will dive into each security area they cover in our upcoming post and why you should also consider using it.

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) life easier by either making tasks simpler or speeding up processes. To be more specific:

Open source

Open source tools are 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 tweak easily the configuration. When launched from a container, you even don't 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 higher value. Once I have used a tool locally and found it to have 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.