Automatisation

This blogpost is a curated list of tools related to software security automation in the container era.

Intended audience: Anyone that is somehow related to making and/or running software. Bonus points if you are Dev/Sec/Ops (Strike out what does not apply).

By Quentin Anglade, professional tinkerer and security freak @ Objectif Libre

Software security automation, from development to runtime

If you want to make good software, it needs to be secure. And if you want to make secure software, there are tools that can help you, but nothing will help you more than respecting best practices. This article is not really about security best practices, sorry. You can read OWASP’s secure coding practices for a good overview of best practices. The Open Web Application Security Project (OWASP) is a “worldwide not-for-profit charitable organization focused on improving the security of software”, it’s a good place to find useful software security related resources. This article is more a curated list of tools that you might want to use to help you build secure software in the agile/devops era.

During development

Beside respecting best practices, there are not many tools that will accompany developers while there are actually coding. Most of the work would be done during continuous integration. There are still some tools that can help, such as linters. Linters analyze your code as you type it and can prevent flaws, but mostly they help developers respect norms, guidelines, and other conventions.

  • Sonarlint, open-source linter available for a number of IDEs / Editors for JS, TypeScript, Python, and PHP with its standalone version. When connected to SonarQube it can support more languages depending on your editor.
  • Language-dependent linters: you may find what fits your need in this collection or here.

Beside tools & automation, doing code reviews by peers, having a bug-bounty program and regularly doing security audits by trusted 3rd parties are always welcome when it comes to the security of your software. Audits are expensive, but code reviews and bug bounty can easily be set up and prove to be efficient.

CI/CD

Static code analysis

Static code analysis is the art of analyzing source files to detect problems before they even appear. It can prevent dangerous flaws like buffer overflows or SQL injections but do not rely solemnly on it. Due to the nature of static code analysis, it usually gives many false positives and fails to detect a number of flaws such as bad configuration, authentication and control access, bad cryptography usage, etc. Today most tools do more than just checking for flaws, they can give a number of metrics to make not just secure software, but overall good software. Tools:

  • Sonarqube: open-source, free community edition includes Java, JavaScript, C#, TypeScript, Flex, Python, PHP, Web, XML. If you want more languages, you can buy commercial editions with more languages or use free plugins. Integrates well with revision control software, build systems and CI Engines and has lot of features.
  • LGTM, a free service for open-source projects but not for private ones. Supports Java, Python, JavaScript, TypeScript, C and C++.
  • Language-dependent tools
  • Codebeat, another free service for open-source projects. Supports Swift, Objective C, Exlixir, Go, Ruby, Pyhton, Java, Kotlin, JS and Typescript.
  • Codacy, yet another free service for open-source projects. Supports Scala, Java, JavaScript, Python, Ruby, PHP, Apex, JSP, XML, Velocity, VisualForce, C#, JSON and Kotlin.

Vulnerable dependencies

Software is like the death star: it is as strong as its weakest point. Your software probably has a lot of dependencies, and if one of those dependencies has a critical flaw, your software has a critical flaw. Better safe than sorry, checking if a project’s dependencies have known vulnerabilities is essential. In no particular order, some tools you might want to use:

  • Snyk has a huge vulnerability database across several languages (JS, Java, Scala, Python, Ruby, Go, PHP, .Net). You have unlimited tests on open source projects and 200 per month for private projects on the free tier.
  • Language-dependent tools:
  • Github Enterprise
  • Gitlab EE

Vulnerable environment

If you use containers to deploy and run software, there is another vulnerability layer: the environment your applications runs in. But don’t worry, there is a wonderful tool that does the job. Its name is Clair, it can scan docker images and report if there are any known vulnerabilities. There’s no reason to not use it. Clair is integrated into a number of tools, mainly docker registries:

You should also use lynis. It does not scan your container images but performs an audit based on the Dockerfile. It can also be used to audit Linux/Unix systems.

Vulnerability scanners

We’ve covered the possibility of your software environment or dependencies having flaws, but what if it’s your software itself that is vulnerable? Fortunately there are tools that can help:

  • Zed Attack Proxy (ZAP), an OWASP project that “help you automatically find security vulnerabilities in your web applications”. It is widely used and has a big community.
  • Arachni, similar to ZAP as it is a “web application security scanner framework”. It is way more modular than ZAP as it is a Ruby framework but its community is not as big as ZAP’s one.

Both tools have a CLI that you can use in your CI/CD pipeline. See this article for more details on the pros and cons of each tool.

Runtime

There is a lot to do in order to secure an entire infrastructure: firewalls, DDOS protection, monitoring, logging, etc. I will focus mainly on the container level. Most of the tools here are policy-based, which means you will probably have to write your own rules according to your software and its environment:

  • Docker: Docker has some often forgotten capabilities, like Seccomp profiles and ressources limitations. Feel free to use them, it’a already there if you use Docker.
  • AppArmor: “an effective and easy-to-use Linux application security system”. It’s a mandatory access control (MAC) system built in a kernel module. You can assign to a program a profile that specifies what it can and can’t do (filesystem, network, etc.). Works with Docker.
  • SELinux: similar to AppArmor, it is also a MAC system built in a kernel module. It is a more powerful (and complex) tool, but it is quite difficult and tedious to set up to the point where most people just disable SELinux. Read this article for more details on the downsides of SELinux. You can also read RedHat’s documentation about SELinux and Docker.
  • Falco: “behavioral monitoring software designed to detect anomalous activity based on the Sysdig monitoring technology”. It works well with containers, comes with a lot of sane rules and allows you to take action when rules are trigered. A simple example is “If a shell is spawned with an attached terminal, take action”, the action can be anything from killing the container to sending a message on slack. It’s a very powerful and customizable tool.
  • Cilium “brings API-aware network security filtering to Linux container frameworks like Docker and Kubernetes.”. It uses the new BPF (Berkeley Packet Filter) in the Linux Kernel to filter network packets at different levels (L3, L4, and L7).
  • kube-bench: “checks whether Kubernetes is deployed securely”. If you are using kubernetes for deploying your containers, feel free to use this tool that uses the CIS (Center for Internet Security) benchmark.

To scan your servers, virtual machines or instances, you should use vuls.io. It’s an agent-less vulnerability scanner for linux and freeBSD. It can run locally or via ssh, scan for OS and non-OS packages and notify via slack or email. There is a terminal-based and a Web UI to view results.

To automate reactions to security related events, you can use CSF (Continuous Security Framework), a tool developed in-house at Objectif Libre. This is a generic tool that allows you to easily script responses to a number of events: a new vulnerability in your containers, an image request from kubernetes, a new kubernetes ressource created, etc. With its simple and modular design you can adapt it to suit your needs without much work.

Conclusion

You (and everyone on this planet) need to respect security best practices, no tool will prevent catastrophic security breaches if you don’t. But using the right tools at all development steps can prevent a lot of potential vulnerabilities. It does take a lot of time and effort to integrate security tools in your development pipeline, but security should be a priority before it is too late.