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.

Reach out for a live demo today to see for yourself!

One continually evolving attack vector for nefarious actors is the software supply chain, particularly within open source software package solutions and repositories.  Many of these exploits are not sophisticated, but they are particularly potent due to their ease of execution, potential wide impact across organizations and projects, and difficulty to detect.  These exploits include, but are not limited to:

• RepoJacking – identifying vulnerable legitimate open source repositories (e.g., no 2FA authentication) and using brute-force or phishing tactics to secure access to the project and surreptitiously adding code or dependencies without the original authors or consumers noticing. Additionally, attackers have leveraged the user renaming capability within GitHub to take over a previously legitimate project.
• StarJacking – effectively “cloning” the star rating/download numbers of an upstream project to lend (false) credibility to a nefarious package (e.g., creating a new package on PyPi and sending PyPi metadata indicating it is a fork of a legitimate project, whereas in fact it is not).
• TypoSquatting – creating malicious packages with names derived from other popular reputable packages in the hopes that developers typo the name in their package manifests and pull the malicious package on accident (e.g., attackers naming an NPM package reqest, reuqest, requesst in hopes a developer makes a mistake an imports the attacker’s package rather than the legitimate one)
• Dependency Confusion – cloning the code from a legitimate project and simply adding an otherwise unneeded package dependency on a malicious package. This attack can be implemented by RepoJacking or an iteration on the above Typo Squatting.
• Source Control Action/Automation Manipulation – leveraging CI automation tools (e.g., GitHub actions) to automatically build and run malicious code during push or release actions

Checkmarx team of researchers and engineers proactively pull down and test thousands of packages published weekly within a dedicated “detonation chamber” environment to identify and index nefarious or exploited packages and we report our findings to the relevant package management platform.  In our testing, we have observed many of these exploits occurring “in the wild,” and while there are no clear-cut solutions, there are relatively small actions we as open source community members can take to avoid hackers from exploiting the fruits of their spoils. These actions include (but are not limited to):

• Developers can ensure they only import dependencies (and those dependencies’ dependencies) that are needed.
• Developers can ensure our package manifests are free of typos and are using strict versioning so as to prevent automated upgrading of packages
• Developers can leverage both static and dynamic code scanning and SCA analysis to identify vulnerabilities early and ensure their projects and software are not “calling home” to unknown destinations
• Open source developers can implement 2FA for their open source software project repositories to prevent brute force attacks and takeover of projects
• Package and repository solutions (e.g., NPM, Pypi, GitHub) can enforce project forking tracking and improve project credibility enforcement to prevent or mitigate StarJacking
• Package and repository solutions, open source developers, and security organizations can establish and agree upon a common standard for identifying and flagging malicious software packages and repositories to improve identification, detection, and removal of malicious software packages and code (target resolving the “Package Naming Problem”)

Ultimately, improving security within the open source community is our responsibility as developers, project contributors, and stewards. Checkmarx can help you and your organization protect your applications from software supply chain vulnerabilities through our suite of application scanning tools such as Checkmarx Supply Chain Security offering (SCS), SAST, and KICS, all of which are available as services within the integrated Checkmarx One platform. Often, and given the nature of supply chain attacks, we need to correlate the results from multiple scans to identify vulnerabilities or malicious code within our projects.

With Checkmarx Fusion correlation engine integrated within Checkmarx One, we automate and illustrate the results from these multiple scans to make it simple and easy for developer teams and information security teams to identify and remediate quickly. Lastly, be sure to check out our open source tool, ChainJacking, which can help you identify which of your direct GitHub dependencies are susceptible to RepoJacking attacks.

For more information, watch our recent session at The Linux Foundation Open Source Summit North America entitled The Simple, Yet Lethal, Anatomy of a Software Supply Chain Attack presented by Jossef Harush, Head of Engineering of Supply Chain Security at Checkmarx. Additionally you can download the Understanding Open Source Supply Chain Attacks whitepaper.