June 13th 2020
Shifting left is a development principle which states that security should move from the right (or end) of the software development life cycle (SDLC) to the left (the beginning). In other words: security should be integrated and designed into all stages of the development process. This new shift requires developers to take more ownership of security and security principles. The good news is that there are lots of tools available to help developers in this process.
In this blog we will break up Application Security into key areas and walk through some free and open-source solutions that will help developers and organizations make sure, at every stage of their SLDC, the incremental changes they make improve the overall quality and security of their software.
Shifting left may feel like adding extra work to a developer’s already full plate, but in reality, it empowers developers to learn more about great security practices which results in less time spent fixing bugs and more time spent building great applications.
It is important to realize that all application security vulnerabilities cannot be fixed by a single product. Successful security requires a layered approach with many lines of defence for different stages of the SDLC.
The tools we will investigate cover:
- SAST – Static Application Security Testing
- DAST – Dynamic Application Security Testing
- IAST – Integrated Application Security Testing
- RASP – Run-time Application Self Protection
- Dependency Scanning
- Secrets Detection
While it is true that vulnerabilities picked up early are easier – and cheaper – to remediate, you cannot rely on finding all vulnerabilities during the early stages of the development. Security needs to be a concern throughout the entire SDLC.
Static Application System Testing – also known as “white box testing”, is the most common and earliest category of automatic application security. SAST scans an application’s source code to discover any known vulnerabilities. Because SAST does not require an application to be compiled or running to start detecting vulnerabilities (unlike DAST) it can be implemented very early in the SDLC.
It also enforces coding guidelines and standards without executing the underlying code. This category of application testing has a wide variety of solutions available, so when deciding on using one, make sure the solution is well supported and maintained and works within your technology stack. Here are some of the best free SAST tools.
NodeJs Scan has a command line interface for easy integration with DevSecOps CI/CD pipelines and produces results in JSON.
A configuration file is available for each language which can be modified for customized searches. Overviews of files, as well as an entire codebase, can be visualized through stats and pie charts. The program can detect buffer overflows and flaws in Java code that may contain OWASP security risks.
Widely regarded as one of the best automated code review tools available in the market. SonarQube has thousands of automated Static Code Analysis rules. SonarQube also supports 27 languages which are a mix of both modern and legacy so that SonarQube can cover your entire project and its continuous development.
Interactive Application Security Testing – Which is also sometimes known as “grey box” testing, is technology that combines elements of both SAST and DAST simultaneously. It is typically implemented as an agent within the test runtime environment (for example, instrumenting the Java Virtual Machine [JVM] or .NET CLR) that observes operation or attacks and identifies vulnerabilities.
Contrast is another developer-first product that is able to go deeper into vulnerabilities when compared to other SAST and DAST tools which are blind to the runtime context of applications such as the controller, application logic, data layer, presentation view, user libraries, open-source components, and application server.
Runtime Application Self Protection – is configured on a server and kicks in when an application runs. It’s designed to detect attacks on an application in real-time. When the application begins to run, RASP can protect it from malicious input or behavior by analyzing both the app’s behavior and the context of that behavior. By using the app to continuously monitor its own behavior, attacks can be identified and mitigated immediately without human intervention.
Sqreen’s Runtime Application Self-Protection identifies attacks that exploit vulnerabilities in production by leveraging the full execution context of requests.
Dependency Scanning helps to automatically find security vulnerabilities in your dependencies while you are developing and testing your applications, for example when your application is using an external (open source) library which is known to be vulnerable.
Snyk is a developer first organization with well maintained open-source solutions for developers and effective enterprise solutions available for larger organizations.
Snyk has a range of great features that help make security part of the development process from day one such as the ability to detect vulnerabilities from within your IDE and native git scanning to test projects within the repositories. Snyk also provides a security gate to prevent new vulnerabilities from passing through the build process and a production environment to test your running environment to verify there is no exposure to existing vulnerabilities.
Whitesource like Snyk has some great free tools for developers as well as large enterprise solutions for larger organizations. WhiteSource Bolt for GitHub is a FREE app, which continuously scans all your repos, detects vulnerabilities in open source components and provides fixes. It supports both private and public repositories.
Over 200 programming languages are supported with continuous tracking of multiple open source vulnerabilities databases like the NVD.
Secrets detection is often confused with SAST because both scan through source code. Unlike SAST, which is concerned only with the current version of an application, secrets detection is concerned with the entire history of the project. Version control systems such as git, keep track and store all changes to an project. If previous versions of source code contains hard-coded secrets within, that were removed in late stages, code reviews and SAST tools will miss these secrets which may end up in a git repository and become compromised. This is why secrets detection is a category on its own.
GitGuardian’s technology works by scanning developers repositories for evidence of secrets.
GitGuardian covers more than 300 different types of secrets from keys to database connection strings, SSL certificates, usernames and passwords. These secrets are detected through a combination of algorithms, including sophisticated pattern matching techniques. GitGuardian can be integrated with your GitHub account and configured within minutes and developers can use the GitGuardian API to detect secrets in any services including within directories, email clients or Slack channels.
With so many solutions available it can feel daunting to decide what tool to select within each category. Always consider how each tool fits into your current workflow as even great tools can be rendered useless if they become too difficult to use.
Each application is different and the tools outlined above should be considered a minimum level of protection, but you and your organization may need more detailed solutions. Security is one of the most highly valued skills in a developer, although shifting security “left” can seem like a daunting task, it is a worthwhile investment to understand and implement these systems within your entire development life cycle.