The Developer's Security Tool Chain
An article from DZone's upcoming Guide to Application Security, looking at the kinds of tools you need to deal with security defects.
Join the DZone community and get the full member experience.Join For Free
Security is a critical concern for the modern developer, but it is just one of many requirements to be managed. Like many non-functional requirements (scalability, fault tolerance, performance, testability, accessibility), security is far easier to build in from the beginning as opposed to “tacking on” at the end. The most effective way to accomplish this is to embed security into the software development life-cycle (SDLC). Beyond effectiveness, we want to make security efficient. As such, any process should be implemented with as much automation as possible to ensure accuracy and save time and effort.
When thinking about security in the SDLC, there are a number of natural touch-points: locations where the technology can be instrumented to account for security. The sections below walk through each phase of the SDLC and cover tools you can implement to strengthen the security posture of your applications.
Requirements, Analysis, and Design
The highest value security activity at this stage is threat modeling. Threat modeling is simply a structured approach to evaluating the risks applicable to your application. This involves both identifying and addressing risks. There are various threat modeling tools available. A couple of free options are the Microsoft threat modeling tool and Mozilla seasponge.
To get people interested and excited about threat modeling, there have been several games developed based on the threat modeling process. These games are a fun way to introduce developers to the process. A couple of good examples are The Elevation of Privilege and OWASP Cornucopia.
Construction (Implementation, Coding)
There are a number of security tool categories that are useful in the construction phase of the SDLC:
Static analysis tools evaluate source code (or bytecode, or binary code) in order to find defects. There are a number of different types of analysis that can be performed, but static analysis for security typically concerns itself with defects related to configuration or data/control flow analysis.
Since these tools work on source code, they are sensitive to the target language and frameworks. As such, a comprehensive list would be quite long. Still, here are a few examples of open-source tools in this area:
Secure libraries typically focus on a particular security area of concern (authentication, encoding, cryptography), and provide a coherent API for dealing with that issue. Examples include:
Authentication / Access Control
These libraries provide a pattern for implementing authentication and access control primitives within your application, and typically integrate with common tools and patterns (e.g., Spring Security, Apache Shiro).
Cryptography is one area of security where you do not want to build your own tooling. Cryptography is a nuanced field, and applied cryptography (practical application) is often very difficult to get right. Use a trustworthy library with a sane API (eg. Nacl, Keyczar).
XSS safe templating languages (context aware automatic escaping)
This family of tools is useful, particularly those that are context aware (proper output encoding is tricky!). Relying on an existing library or tool that handles automatic context-sensitive escaping is a big help towards preventing XSS (eg. Ctemplate, closure templates, GWT, secure-handlebars).
Object Relational Mappers (ORM)
These are useful tools to prevent SQL injection. When used properly, ORMs safely encode information sent to a database. As these tools are language (and sometimes framework) specific, choose an appropriate library for your situation.
Secure HTTP headers libraries
A number of HTTP headers (eg. Content Security Policy, Strict Transport Security) have been created to provide security protection for web applications. There are now several language and framework specific tools that allow developers to automatically render these headers. Web frameworks in particular are starting to add these features.
Protecting data in transit is a critical issue, and doing so typically relies on TLS. While there are many providers of TLS certificates, there is one provider that is taking a new and exciting approach for developers. Let's Encrypt is a new certificate authority that will provide TLS certificates for free with a very straightforward registration process. If you are interested in studying this topic more deeply, I recommend the book Bulletproof SSL and TLS by Ivan Ristic.
3rd Party Library Security
Modern applications are built on top of a plethora of software dependencies. While this is great for software reuse, it can pose security issues. The libraries on which developers depend often have known security problems. If you are building an application using these libraries, you have now inherited those problems. There are a couple of open-source solutions that can help you address this issue:
This project provides a number of ways to integrate (build tool, CI, manual, etc.) into an application, and it determines if any of your dependent libraries have known vulnerabilities. This tool applies to a number of different languages and frameworks.
There is a security maxim known as the “defender's dilemma,” which states that while defenders have to protect against every attempted attack, an attacker only has to find a single weakness to be successful. Given this challenge, developers must utilize every advantage they can. One capability a developer can add to an application is the ability to automatically protect itself. While this may sound complex, it is actually quite simple.
As a developer, you implicitly understand expected patterns of behavior for your application, namely reasonable bounds of usage. If a user is accessing the application in an incorrect way, you can track their activity and stop them (e.g. fraud detection, API rate limiting). This idea can be used to address many usage patterns throughout an application. By tracking suspicious user activity, the application can automatically respond to attacks and protect itself.
One open-source tool that provides this capability is OWASP AppSensor.
In the last couple of years, tools in this space have made great strides in becoming developer-friendly in a couple of ways: adding APIs and providing continuous integration (CI) capabilities.
Dynamic analysis could be used to describe many tools in the security space. This section focuses on tools that function as a user would, essentially making requests and analyzing responses to determine if application vulnerabilities exist. There are a number of tools in this area that are open source:
Behavior-Driven Development Security Testing
The tools below have extended the BDD model to integrate common security testing tools into the CI process, verifying your security requirements as your code progresses through the CI pipeline.
Communications Security Analysis
TLS configuration can be complex. The settings that are considered safe today may not be a year from now. Notably, there have been several changes in the last 3-5 years that have had a significant impact on the definition of a safe TLS baseline configuration.
Keeping up with these changes can be difficult and time consuming. Luckily there are services available that will consume your site, and score you on your configuration. These services also give you recommendations of how to strengthen your configuration.
One such tool is ssltest.
Security Headers Analysis
Security headers for HTTP(S) have largely been created to help address some of the practical engineering challenges around securing large web applications. The list of available headers is growing, and keeping track of them and their uses in your application is becoming difficult. Two tools that can help both in implementing these headers (recommendations, policy builder tools), as well as verifying their use, are Security Headersand Report URI.
Maintenance (Release, Response)
From a security perspective, the tooling in this space has improved greatly in the last 3-5 years due to the DevOps movement.
Monitoring applications for their real-time security posture is important. Consistent logging coupled with good analysis tools is a good step towards monitoring. A few relevant tools are listed below:
ELK (Elasticsearch, Logstash, and Kibana)
This is a popular log reporting stack that is often used to analyze both standard application logs as well as security events.
This tool builds on top of Elasticsearch and provides flexible alerting and reporting based on anomalous events.
Implementing this tool implies management of the application and tool in production as part of security analysis. (See self-protecting applications above).
CM tools are not directly security tools in and of themselves, but they do benefit security. Using CM tools allows the developer to explicitly define the desired state of the deployed stack/container/application environment. By doing this, the configuration can be reviewed and approved. Additionally, tooling to verify the safety of the configuration is possible. There are a number of popular tools available for configuration management:
Note: This space is quickly changing (e.g. containers), and may look different soon. However, the power of being explicit about the desired state of your infrastructure, coupled with the ability to verify that desired state through configuration, is a powerful security capability.
Security is a critical concern for the modern developer. Embedding tooling and automation in the SDLC provides powerful capabilities for increasing the security posture of applications. There are a number of tools that can be applied at each phase of the SDLC to help you achieve a highly effective and efficient level of security.
Opinions expressed by DZone contributors are their own.