Considerations for Open Source and Proprietary Application Security Solutions

The process of writing code (and the code itself) has changed dramatically: functionality and end-goals for code execution are lightyears ahead of where we began. The software development tools to support the magic of coding have spurred a new process with a fancy name, DevOps, which has enabled developers to deploy code faster than ever before. However, code vulnerabilities live on the other side of this magic and there's an increasing need to release secure code. It is not enough to write code quickly and not consider security. You must make sure it does not expose vulnerabilities that can have a critical impact on the organization. Despite commercial and open source tools that perform Application Security Testing (AST) becoming available to help development teams write secure code, not all developers and organizations have adopted security best practices and made the subsequent shift from DevOps to DevSecOps. Learn how to take an integrated approached to embedding security into DevOps here. >> AST tools span the software development life cycle (SDLC) – from code-writing to production environments. Naturally, there's a market divide between open-source AST, developed in software communities, typically available free of charge, and commercial AST vendors. Teams might want to use either open source or proprietary application security solutions for different reasons. We’re going to shed light on similarities and difference between open source and proprietary AST so you can gain a better understanding of which will support your development, security, and operations needs and goals. Let's explore these two types of code-scanning solutions, and which is right for your team right now.

The Power of Community

One of the most significant advantages of any open-source project, and not just regarding AST solutions, is the community. Open source is, to the benefit of the end-user, powered by an entire, hidden developer community that happily contributes code to a given project. Open source code projects took us to Mars - what could be a stronger tribute to the developer community's power? NASA and Microsoft back this popular project, ensuring that committed code is vetted, issues receive due attention, and the community is properly supported in reaching and setting new goals. It’s wise to research who orchestrates community efforts and understand if the people or organization will continue to prioritize the projects for the next five plus years, ensuring that you have a product that you may rely on for the foreseeable future. Open source projects that provide the foundation for a commercial offering, where the core of the commercial product is available as open source but a vendor layers ‘value-add’ features like reporting, enhanced capabilities, or integrations into a comprehensive platform, are arguably the safest bet. Projects like this are better supported because an organization’s revenue stream relies on it. The downside? Some developers might be less inclined to contribute to a project that is also generating commercial revenue for a company. However, if an open source project isn’t backed by an organization that doesn’t continuously reinvest its resources in fostering the community, developers might lack a real commitment to the project, so the results aren't as impressive. It turns out that shepherding a successful open source project can be as much work as writing the code itself, and often less rewarding. Sometimes the work of maintaining a project becomes just that – work. That’s when things can go wrong: bugs and features often go neglected.  Over time, users search to look for other solutions, which isn't simple if the deployment process requires a lot of effort. Look at how many years of market leadership, vision, and development is behind an AST solution. Also check out Gartner and other analyst reports that evaluate these solutions based on the engine accuracy and performance, and roadmap, reassuring the users both for today and the future.

The Premium of Freemium

While the accuracy, dedicated support, and R&D teams provide a clear win for commercial solutions, it wouldn't be a fair debate unless we mentioned the price. Open source projects have a forever free or freemium usage model, so the cost of commercial AST solutions may sway a smaller development team's decision. As such, open source can be either an excellent way to either support complimentary AppSec solutions within your pipeline or an ideal entry-point for a smaller development team to start an AppSec program. Yet we, also, encourage to do your due diligence regarding who and how open source projects are supported. Then, depending on the reliability of the tool, crunch the numbers to see what's the hidden cost of an implementation full of friction and the ultimate cost of a breach? If you're in this position, remember that most companies also offer basic packages or code scanning functionality that scales as you scale.

Develop-Centric for Accelerated Time to Market

Developers’ ability to focus is paramount for companies hitting their release targets. If you’re juggling point-products, developers will need to toggle between multiple UIs and spend considerable time making sense of the different security scan reports before remediation. As someone involved with the procurement of application security solutions, you need to make sure the following is covered in either a commercial or open source tool:

1. Accuracy
2. Extensive language coverage
3. Vulnerability prioritization based on severity or exploitability
4. Scans for different types of code in the various stages of the SDLC
5. Ability to customize and tune

If you find that any of the five factors above are lacking, you might find yourself piecemealing multiple open source solutions together, getting tangled in a web of remediation that will surely decelerate DevOps. That workflow alone doesn't provide a positive developer experience, but even each tool as a standalone project won't support developers’ focus and accelerating time to market, either.

Accuracy

Regarding the accuracy of the engines, this is, also, highly variable between engines and languages. There are open source engines that boast excellent results with impressive accuracy.  For example, every Application Security Engineer and vendor will recognize the open source SAST solution “Brakeman” as a leading SAST solution for Ruby code. Other open source engines are less accurate than their commercial counterparts for all the reasons mentioned above. Typically, at best, the results will show false positives, requiring additional monitoring by the user. At worst, scans may contain false negatives, opening the possibility of known vulnerabilities exposure in the application production environment.  So, what was now a free solution is costing you more in the long run. Even if you don’t decide on open source AST, you’ll most likely leverage OSS in some way, so you’ll need to secure it. Learn more about Software Composition Analysis to scan third party and open source code in “The Ultimate Guide to SCA.” >>

Integrations throughout the SDLC

Accuracy, performance, and data insights that bring together results from multiple scans (SAST, SCA, IAST, IaC scanning) will help you insert security and shift left without slowing down the SDLC but asking developers to toggle to another UI or work around a clunky integration is a friction point. Solid integrations throughout the SDLC are the name of the game. To enjoy the benefits of AST without slowing DevOps, meet the developers where they are. Most proprietary solutions have extensive integrations that streamline DevSecOps workflows. For example, you can automate scans, whether by GIT events as part of the CI process, or you can automate reporting to a system like JIRA. But you could also find an open source solution for which you can build custom scripts.

Language Support

Additionally, there is typically much more robust support for multiple languages. Most open-source scanning engines know how to work with a limited list of languages, and legacy languages have almost no place in open-source projects. Consequently, you must accumulate a stack of open source scan engines to support all the languages that your development team uses in your own proprietary code and open source libraries – each with different syntax, formats, reporting structure, and learning curves. If you can, look for solutions that are built to be extensible.

Choose a Solution and Use It

Today we are witnessing more attacks that the production of secure code could avoid. Companies and organizations developing software are coming to a fuller understanding that releasing secure code is not just a box to check for compliance. It is the additional barrier against the next attack. As we detailed, there are advantages to both open source and proprietary solutions. Regardless of what is suitable for your team at this point, do your research, do your due diligence. Choose and use one of them, and do not give up on it. Unsure which is right for your team? Click here to schedule time with an AppSec expert. >>

Related Resources

Explore Checkmarx Documentation More Software Composition Analysis Articles