Micro Focus is now part of OpenText. Learn more >

You are here

You are here

The top open source tools to secure your app sec pipeline

public://pictures/Robert-Lemos-Technology-Journalist-Lemos-Associates.jpg
Rob Lemos Writer and analyst
 

Whether you call it shifting left, modern application security, or DevSecOps, integrating security testing throughout the software development and deployment pipeline is not a single project—it's a continuing effort.

Open-source tools can help immensely. Not only are they a good way to get started, allowing companies and DevOps teams to gain experience in integrating security tooling into the pipeline, but they can help companies create the structure they need to incorporate security into development.

Shannon Lietz, team leader and director of DevSecOps at financial software and services firm Intuit, frequently evaluates open-source tools for use by the company's estimated 4,500 developers. Open-source applications-security tools often are perfect for filling a niche, she said.

"The open-source community is really smart because, in terms of the capability that you can get from the tools, it's a single-function gap that they are filling. But a lot of times they have limitations or only work in certain environments."
Shannon Lietz

Corresponding to the seven general steps of DevOps—design, develop, build, test, stage, deploy, and monitor—Lietz recommends seven security steps that should be integrated into the process:

  1. Design: Attack mapping, or threat modeling
  2. Develop: Code analysis, or static application security testing (SAST)
  3. Build: Dependency checking, or software composition analysis (SCA)
  4. Test: Artifact analysis
  5. Stage: Degradation monitoring
  6. Deploy: Security regression
  7. Monitor: Adversary monitoring, or threat intelligence

Here are the top tools for each step in the DevSecOps pipeline. While these tools are not all strictly open source, every tool does have a free version that can be used.

1. Threat Modeling

OWASP Threat Dragon

Threat modeling should be the first security step, because it informs the design of the application and can give developers an idea of what security threats might affect their application. OWASP Threat Dragon is an open-source threat modeling tool that can be used through a web application or an installable version for the Windows, macOS, and Linux operating systems.

The downside of OWASP Threat Dragon is that the tool is hooked extensively into GitHub, so if you use a different repository system, you will likely have to find an alternate tool.

Alternatives

2. Static Application Security Testing (SAST)

SonarQube Community

SonarQube is an open-source source-code analysis tool that has community-supported development, but also has paid tiers for companies. While OWASP maintains a list of source-code analysis tools, including many open-source projects, most tools only support a few, or a single, programming language, and many tools have not been well maintained.

SonarQube shines with its support for many languages—27, at last count—making it a strong common platform for companies to use for analysis. "There are often plugins for [your IDE] that are individual for specific languages, but I generally default to SonarQube, because it is multi-language, and I often end up in multi-language projects," Lietz said.

Alternatives

3. Software Composition Analysis

OWASP Dependency Track

Dependency Track creates a software bill of materials and monitors the use of software components across the application portfolio to assess the risk that those components pose. The software identifies known vulnerabilities in components, license risk, and out-of-date libraries with built-in support for the major package-management ecosystems, including JavaScript (NPM), .NET (NuGet), Python (PyPI), Java (Maven), and Gems (Ruby).

Alternatives

4. Security Testing

Threat Playbook

While Threat Playbook is threat modeling software (see No. 1), the tool also turns threat models into code that can be used as security test cases to run in a continuous integration/continuous deployment (CI/CD) environment. The tool shines with its collaborative capabilities and is intended to plug into a DevOps software pipeline.

"Their model focuses on what your stories are, what your threat model is, and whether it has been tested," Lietz said. "This is helping to figure out if you did all the work to build a component part or good set of component parts that work together."

Alternatives

5. Degradation monitoring

Deepfence Threat Mapper Community Edition

When staging applications for testing, DevOps teams need to ensure that errors have not crept into their configuration files and infrastructure—that is, that they have not degraded. Threat Mapper helps by giving teams the ability to visualize their cloud infrastructure and provides vulnerability management for all infrastructure components. The software ties into Kubernetes to automate coverage.

Alternatives

6. Security regression

Faraday

Faraday allows DevOps teams to move from threat models to a red-team approach to regression testing. Faraday manages testing by integrating with a variety of tools normally used in vulnerability assessments and penetration tests.

"Faraday has been out for a very long time, and red teamers really like it," Lietz said. "They give you a lot of options to do more than security regression, but I would just use that one."

Alternatives

7. Adversary monitoring

Panther SIEM

Panther allows DevOps teams to analyze the logs of running applications to determine what attackers may be doing in real time. Like security information and event management (SIEM) systems used by analysts in security operations centers (SOCs), the software combines log data with indicators of compromise and threat intelligence to alert teams to potential attacks and compromises.

"It is tightly integrated with the cloud, so it is not like you are going to download this and work anywhere else than the cloud ... although it's tightly integrated with AWS," Lietz said. "They give you the ability to build the notion of what could go wrong with your application and add a compliance view to that."

Alternatives

How far can open source go?

Depending on how many security-focused developers are on your DevOps teams, open-source tools can serve many needs. But for teams that need support, deeper coverage of threats and vulnerabilities, or the ability to scale to thousands of systems, commercial security tools—or the commercial versions of open-source products—are a must, said Lietz.

Open source can help you at a minimum, but when you are dealing with complexity and scale problems, that's when you have to switch over,"she said.

"A lot of companies these days shift from open-source to commercial products, and the way they are doing that is to modify the open-source tools to work with scale."
—Shannon Lietz

Keep learning

Read more articles about: SecurityApplication Security