There are a plethora of free and Open Source AppSec testing tools available on the internet and many of them are quite good – some top-of-mind shining examples (picked at random, of course) are KICS, DustiLock, and ChainAlert. With so many free and open source AppSec tools available, it may be tempting to question, “do enterprises really need to purchase Application Security Testing solutions?” After all, most organizations have teams of in-house developers who are naturally inclined to the line of thinking of we can build that, or why pay for something we can get for free? And any CISO would be remiss if he or she didn’t consider at least some free tools, to help keep expenses to a minimum and organizational leadership happy.
However, as tempting as it may be to roll up your sleeves and follow an entirely free and open-source approach to AppSec testing solutions, CISOs and AppSec teams need to be aware of all of the considerations when it comes to building or selecting AppSec solutions, including total cost of ownership (TCO), opportunity cost of building, integrating, and maintaining custom AppSec solutions, and keeping abreast of the ever changing attack landscape. All of these factors culminate into overall risk—risk to an organization’s data, its customers, and its reputation.
Total Cost of Ownership (TCO) and Opportunity Cost
Most free or open-source tools are technology-specific (e.g., language, framework, technology). This means to adequately cover and help secure custom application code, third-party code, infrastructure as code, APIs, or other software attack vectors (e.g., software supply chain), many different tools are needed and often one suite of tools won’t work across multiple projects. This produces a disjointed approach to AppSec within DevSecOps and relegates control to individual developers with little oversight from security teams or executives.
Pragmatically, these tools all work differently, they do not integrate, they are rigid in terms of how they may be implemented, and they do not scale to an enterprise level. To integrate effectively, organizations will need to devote man hours building, plumbing, and operationalizing them along with their required supporting infrastructure and applications (whether on-premises, or in the cloud). This also means that organizations will need to devote time and resources to updating, maintaining, and troubleshooting these solutions, ultimately increasing the total cost of ownership (TCO) of these otherwise free tools.
Moreover, AppSec leaders and CISOs need to weigh the opportunity costs of Dev and DevOps teams not focusing on building or facilitating the production of the enterprise’s actual product. As an example, if your organization’s primary product is mobile applications, any developer, DevOps, or Security time spent customizing, integrating, or modifying AppSec testing software to meet the enterprise’s needs is time not spent building mobile apps.
Deploying, integrating, and maintaining custom solutions is only half the battle. Factor in the various results across multiple scan engines, such as SAST, SCA, SCS, API Security, and Infrastructure-as-Code, it becomes readily apparent that being able to consume and prioritize results within a single platform can save significant time and overhead in identifying and remediating risks in applications.
Commercial products also come with a simple, predictable cost structure, which makes budgeting and planning AppSec initiatives and calculating ROI much easier.
Siloed Knowledge and Threat Intelligence
Most AppSec professionals (or teams) are knowledgeable about pockets of vulnerabilities, application code weaknesses, runtime environments, developer operations, technology stacks in use, and available tooling; as such, they are only able to provide expertise that is narrowly focused and may not encompass the entire attack landscape of an organization. For this reason, many (if not most) companies (even the big ones) either need or want to leverage the expertise of application security companies—from a product or partnership perspective.
Building a completely bespoke or piecewise AppSec solution introduces a significant risk of “unknown unknowns,” where organizations can potentially suffer from tunnel vision, focusing only on security vulnerabilities or exploits they or their teams have observed. This has the potential to introduce significant blind spots and overlooked vulnerabilities with potential dire consequences – with the ever evolving threat landscape, relying on internal teams or unknown (hopefully) benevolent open source contributors may result in organizations being reactive rather than proactive, subjecting it to potential, existential risk.
One particularly illuminating example is without the benefit of supply chain security capabilities, developers and AppSec teams would have to continuously monitor social media or GitHub comments for all versions of the open source packages they’re using within their projects, both explicitly and as dependencies, which could easily number in the hundreds of thousands.
Support, Maintenance, and Updates
Another pitfall to consider when it comes to open source or free solutions is they often do not offer the same level of customer support relative to that of a commercial AppSec solution. Software or feature support aside, consultation, planning, education, and developer adoption services are all lacking or non-existent for free or open-source solutions. Consumers of these kinds of solutions (vs. commercial) will have to navigate significant overhead to manage many disparate tools, slow reactions (by maintainers of the tool) as threats emerge or change, and incomplete or defective offerings where nobody can be held accountable.
Support and services aside, commercial AppSec solutions offer consistent and reliable updates and maintenance. Commercial AppSec vendors have quality-focused teams to test and validate their application and software updates prior to their release. In contrast, open-source projects typically rely on a community of engaged volunteers to perform quality assurance functions ad-hoc, then report findings back to project maintainers.
Checkmarx itself has several open-source application security testing projects that are very active and are updated on a daily or weekly basis. Today, a quick review of our very active projects shows dozens of open issues and pull requests that ostensibly fix defects or proliferate new capabilities that are needed by the community. This merely reiterates that the responsiveness in open-source projects to issues and challenges—even for projects that are highly crowd-sourced and supported diligently—are, in most cases, not sufficient (on their own) for enterprises.
Conclusion
Ultimately, the decision to approach AppSec testing using either open source and in-house developed tools or commercial AppSec solutions boils down to risk. Organizations and enterprises have a risk budget much in the same way they have an OPEX or CAPEX budget—and the two are inversely proportional. While open source or in-house developed AppSec solutions minimize upfront or short-term costs, it’s at the expense of operations, maintainability, flexibility, and risk exposure.
For enterprises, while free and open-source tools can augment an existing AppSec program or solution, they simply cannot meet the organization’s needs in terms of ease-of-use, maintainability, or service and support on their own.
About Checkmarx
Checkmarx’s comprehensive and integrated Application Security Testing Platform provides a robust, flexible, and extensible AppSec solution that allows organizations to leverage our years of experience, research, and understanding in an easy-to-use platform.
