Introduction

Q: Is it possible for a commercial enterprise to implement an application security program with only opensource tools?

A: tl;dr – Yes, it’s possible!

Oftentimes organizations face a lack of funding to implement a commercial, “turnkey” application security solution. As an alternative, it might be worth evaluating opensource solutions. It’s important to note the term opensource comes with the understanding that many “free” application security tools are not “free” for commercial use. This post provides true opensource alternatives for companies looking to fill gaps within each phase of the development lifecycle that won’t impact the budget or cause a legal/licensing issue.

Selecting security tools for modern software stacks, homogeneous environments, or small dev teams are relatively straight forward to select and implement. However, at the core of many organizations, there exists technical debt and legacy systems. Corporate enterprises also have the added burden of a diverse set of languages and frameworks that have either grown organically, by acquisition, or both. Another issue is that large teams or companies with many development teams need a way to effectively scale application security to all developers and to cover most all technologies. The article addresses the latter.

Lifecycle – DevOps, DevSecOps, Secure Development

Any term is appropriate for describing the development approach when it comes to application security. For simplicity (and brevity), it will be referred to as “SDL”. Regardless of methodology, iteration speed, or codebase, security should not be considered a blocker. Security can be injected within each phase of the SDL without adversely impacting development, while simultaneously improving the quality and security of the final product.

The following phases are typically present in most SDL’s. The sections below include opensource products that match capabilities commonly found within each phase.

Plan

Threat modeling is an activity to discuss what can go wrong. Most modeling can be accomplished with a meeting, whiteboard, and dry erase markers. If whiteboarding doesn’t cut it, both Microsoft and OWASP provide free tools. Microsoft’s is called “MS Threat Model” and OWASP’s is called Threat Dragon. Both have very good capabilities.

BTW, OWASP will be mentioned a lot in this post due to their commitments to opensource and application security.

Code

Static Application Security Testing (SAST) is security-based code analysis. Linters, code style, and code quality tools exist for just about every language, but they are not focused on security. There are also security-based static code analysis for individual languages that may not have quality aspects to them. SonarQube is a popular tool because it provides a little bit of both quality and security wrapped into one tool that supports many languages. The basic version is free for enterprise use, and enterprise licensing is offered as well. SonarQube identifies what it calls “Security Hotspots” and “Security Vulnerabilities” in code for the more popular languages it supports. If a better SAST tool is eventually implemented by your enterprise, SonarQube is still worth keeping around for code quality and code style purposes.

Build

CycloneDX is a Software Bill of Materials (SBOM) standard that identifies a format for listing the components that make up a piece of software. CycloneDX is another OWASP project and could also be included under the “Plan SDL” phase above because it helps to understand the components that make up your software inventory. It is placed in the build phase because it is generated by incorporating it into the software’s build process. Many plugins are offered to create an SBOM listing based on your language and build solution.

Software Composition Analysis (SCA) looks at vulnerabilities found within opensource components. Dependency Track is another OWASP project that ingests an SBOM file and uses it to validate against several freely available threat intelligence and vulnerability databases. It incorporates results into a web application that quickly sets up and runs on Docker.

A Binary Repository is a place to secure your own build artifacts, containers, and 3rd party components thru a local proxy. Like SonarQube, Nexus has a “Freemium” consumption model that includes plenty of language support and integrations.

Security Automation? Yes, I could have used the term CI/CD. Yes, it makes sense to integrate security checks into continuous integration and deployment scenarios. However, it may not always be practical, culturally appropriate, or there are just too many roadblocks. Regardless of what it’s called or where it takes place, Security Automation encompasses any phase of the SDL where automation makes sense. There are many automation solutions in this space and Jenkins is one example, or simply a good scripting language like Python or PowerShell can be utilized to automate application security needs.

Test

Dynamic Application Security Testing (DAST) identifies flaws in web applications. Items like server misconfiguration, cross-site scripting, and business logic errors. Unlike SAST, the exploitability can be proven with penetration tests (pen tests). OWASP Zed Attack Proxy (ZAP) was developed for pen testing and it can be automated. Another pen test product, Burp Suite provides a freemium version but it’s ability to automate is limited with the community edition. Both products have a strong community behind them, so you don’t have to be an experienced hacker or start tests from scratch.

Release/Deploy

Configuration Management was often exploited by adversaries in the early days of cloud and in the creation of cloud-native applications. It still is! The Shared Responsibility Model states that cloud providers are responsible for security of the cloud, and their customers are responsible for security in the cloud. It means that cloud providers will give you a securable environment, but it’s ultimately up to you to configure it securely to meet your needs.

The Quay project provides a Docker container vulnerability capability with a scanner called Clair. It is also the basic image scanner for AWS ECR.

Infrastructure as Code (IaC) is a best practice for cloud and infrastructure. Automation here makes sense, especially in cloud environments where it is simple to both provision and tear down infrastructure. Just as it is easy for an engineer to misconfigure infrastructrure manually, it is easy to misconfigure infrastructure as code (IaC). Only with IaC, the security vulnerability can be propagated across an environment. KICS, by Checkmarx provides a scanning capability to help identify issues prior to deployment.

ScoutSuite provides a complete cloud account scan that identifies cloud security misconfigurations. It is easy to set up and with some security automation can be used to oversee a fleet of cloud accounts.

Operate

In Application Security, operations is about the ongoing maturity and assurances of the software product. An operational area where application security provides value is with Maturity Modeling. The determination and measurement of the security level of software is valuable from compliance, audit, and strategic perspectives. A great way to build a solid software assurance capability for the enterprise is to implement one of the following models that best meet its needs.

• OWASP Software Assurance Maturity Model (SAMM)

• OWASP DevSecOps Maturity Model (DSOMM)

• Minimum Viable Secure Product (MVSP)

Pros and Cons

The primary benefit of opensource application security tools mentioned here is that they are ok to use in a commercial environment without a budget impact. All products mentioned have broad community support and some are backed by a for-profit enterprise offering freemium editions.

A few drawbacks of an entirely free opensource application security stack is the lack of perceived quality, and the amount of ramp up time. Nearly all of the tools require infrastructure to run and ongoing maintenance. Also important is the resource skillset, and availability to both operate and maintain.

Summary

Determining Total Cost of Ownership (TCO) when evaluating opensource tools to commercial tools is difficult to measure. It comes down to the age-old question of “Buy versus Build”. The opensource route is akin to build given the increased time and effort needed to stand up all the tools, compared to buying a commercial off the shelf (COTS) application security solution.

One thing is for certain, any effort to improve the security posture of applications is better than no effort. Doing so might just upset those happy adversaries!