Integrating open source security tools into your SDLC
Change always has costs connected to it. Change needed when moving security “left” in your software development lifecycle is no exception. One way to curb costs when you leap into DevSecOps is to integrate open source security tools into the process.
Such tools are especially important as the software development process accelerates. That’s because the faster code is implemented, the more vulnerability issues it’s likely to have. Limiting vulnerabilities in deployed code should be the top goal of a DevSecOps program. Next in importance, is producing more secure software by teaching developers how to do that, providing processes and tools for application security standardization, and demonstrating software security maturity through metrics and assessment.
Even before you introduce open source tools into your pipeline, they can play a role in teaching your developers about writing secure software. For example, OWASP (Open Web Application Security Project) publishes a list of proactive controls to help developers do that. The concise list—explanations are two or three pages long—includes:
- Define security requirements.
- Leverage security frameworks and libraries.
- Secure database access.
- Encode and escape data.
- Validate all inputs.
- Implement digital identity.
- Enforce access control.
- Protect data everywhere.
- Implement security logging and monitoring.
- Handle all errors and exceptions.
OWASP also makes a vulnerability-riddled program called Juice Box that gives developers hands-on experience with an insecure application. Developers can test their knowledge of OWASP Top 10 vulnerabilities, as well as others, as they try to hack the app and rack up points.
Another free OWASP offering for developers are cheat sheets. They form a knowledge base of common security issues found in Web apps and how to mitigate them. For example, there’s a cheat sheet on password storage that explains typical errors made when storing passwords and how to use encryption and hashes to protect passwords from bad actors.
Threat modeling, which is performed during the design phase of a feature, can be used to address vulnerabilities before any code is written. OWASP makes an threat modeling open source tool called Threat Dragon that’s geared toward developers. It’s built around four essential questions. What are we building? What can go wrong? What are we going to do about that? Did we do a good enough job?
Tools in the pipeline
A number of open source tools are available to implement DevSecOps in your pipeline. Here are a few.
Static Application Security Testing (SAST)
SAST tools are used on code before you compile or run it. SAST tools analyze applications at the source code level. They can uncover errors in written code but not in code execution. In addition to finding security issues, they can find problems with documentation, bad coding standards, and performance. Automation is a key consideration when choosing a SAST because you want to continuously identify quality defects and security vulnerabilities as code is written so they can be addressed early in the SDLC.
Other SAST tools can scan a variety of languages. Google SearchDiggity, for instance, provides a source code security analysis of nearly every open source code project in existence. Graudit will scan multiple languages for security flaws, as well as SonarQube, which provides continuous inspection of code quality to perform automatic reviews of code for bugs, vulnerabilities, and code smells.
Dynamic Application Security Testing (DAST)
DAST tools monitor an application while it’s running. Typically, DAST tools test only exposed HTTP and HTML interfaces for web-enabled applications. The tools are easier to use than SAST tools, but they generate less information about what they find, leaving it up to the developer to find and fix vulnerable code.
DAST apps are available in both free and open source flavors for a number of platforms and as a service. Arachni, for example, is a free Ruby framework designed for penetration testers and administrators to assess the security of their web apps. It supports the big three desktop operating systems—Windows, MacOS and Linux—while tools like AppTrana and WebCookies perform their scans from the cloud.
OWASP sponsors an open source DAST project called ZAP—Zed Attack Proxy—for Windows, Unix/Linux, and MacOS supported by hundreds of volunteers. Not only can it automatically find security vulnerabilities in web applications as they’re being developed and tested, but it’s also useful for experienced pen testers performing manual tests.
Other open source DAST offerings for Windows, Unix/Linux, and MacOS include Grendel-Scan, which also has an automated testing module, and Wapiti, which does “black box” scans of the web pages on which the target apps reside and looks for scripts and forms into which it can inject data.
In addition to scanners for web apps, there are also open source DAST tools for securing web servers. Nikto, which supports Unix/Linux, performs tests for more than 6400 potentially dangerous files and Common Gateway Interface flaws, outdated versions of over 1,200 servers, and version-specific problems for more than 270 servers. Wikto will perform similar tests on Windows servers and has added features, such as a back-end miner and tight Google integration.
Interactive Application Security Testing (IAST)
IAST is a relatively new technology for finding security flaws in apps. Like DAST tools, IAST tools analyze running applications. Unlike DAST tools, IAST tools use code instrumentation to observe application behavior and data flow so they can provide developers with the information they need to pinpoint flaws and fix them. At this time, there’s only one free—with registration—IAST tool, Contrast Community Edition. The tool for Java code can be used on one application with up to five users.
Software Composition Analysis
Software Composition Analysis tools are used to analyze open source libraries and components used by an application. Vulnerabilities in open source components can evade other kinds of testing so it’s important to include an SCA tool in the DevSecOps pipeline. OWASP makes two SCA tools: Dependency Check and Dependency Track.
Dependency Check identifies dependencies in a project and checks if there are any known, publicly disclosed vulnerabilities in them. The tool fully supports Java and .NET and experimentally supports Ruby, Node.js, and Python. There’s also limited support for C/C++ build systems.
Dependency Track keeps tabs on all third-party components in all applications created or consumed by an organization. It’s integrated with an assortment of vulnerability databases, including the National Vulnerability Database (NVD), NPM Public Advisories, Sonatype OSS Index, and VulnDB from Risk Based Security.
When incorporating open source security tools into your DevSecOps pipeline, you’ll want to automate as many of the security tests as possible. The tests should be automated at every major commit of code by development or operations, even at the very early stages of a project. The idea is to create short feedback loops so the DevOps teams are notified of potential security problems within short time frames. That way, the teams can mitigate the problems as part of their daily workflow and when they’re digestible—not at the at the end of the software development lifecycle when fixes can become complex, time-consuming, and expensive.