Integrating open source security tools into your SDLC
Change always has costs connected to it. And 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 code is likely to have more vulnerability issues when implemented faster. 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.
DevSecOps: Integrating Security
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) published a list of proactive controls to help developers do that. The list is concise, as explanations are only two or three pages long. The list 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. This program gives developers hands-on experience with an insecure application. Developers can test their knowledge of OWASP Top 10 vulnerabilities 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. It also includes how to use encryption and hashes to protect passwords from bad actors.
Threat modeling is performed during the design phase of a feature. It can be used to address vulnerabilities before any code is written. OWASP makes an threat modeling open source tool called Threat Dragon that is geared toward developers. It is 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 security 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. This is important because you want to continuously identify quality defects and security vulnerabilities as code is written so that they can be addressed early in the SDLC.
Other SAST tools can scan a variety of languages. For instance, Google SearchDiggity. This tool 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, 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. However, they generate less information about what they find. This means they are leaving it up to the developer to find and fix vulnerable code.
Other open source DAST offerings for Windows, Unix/Linux, and MacOS include Grendel-Scan. This tool also has an automated testing module. Another option is Wapiti, which does “black box” scans of the web pages on which the target apps reside. Wapiti also 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. Additionally, it looks at 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. Therefore 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 (SCA) 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. As such, 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. Regardless, this is important 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. By the same token, it means the problems are not at the at the end of the SDCL when fixes can become complex, time-consuming, and expensive.