We believe, Checkmarx continues to maintain its strong position in the AST market and we’re very proud of that.  More and more organizations are embedding AST throughout their modern application development and cloud-native initiatives, driving rapid AST market growth that trends alongside the proliferation of software amidst worldwide digital transformation.

We believe that the observations made by Gartner support the need for enterprises to not only implement a strong foundation of testing proprietary code and open source libraries via SAST and SCA scans, but to also account for emerging cloud-native technologies including APIs, containers, microservices, and Infrastructure as Code (IaC). Beyond that, evolving risks in the open source supply chain continue to increase as more open source becomes part of today’s codebases.  

To address the growing need of AST solutions that fit well into modern application development, we released the Checkmarx AST Platform late last year. And just last month, we added Checkmarx Supply Chain Security to our portfolio of solutions. Built for the cloud development generation, our AST Platform delivers essential application security testing services from a unified, cloud-based platform. In one scan, it analyzes source code, open source dependencies, supply chain risks, and IaC templates, correlates and verifies the results, and augments them with expert remediation advice. Best of all, these services integrate right into your existing software development tools and processes.

Application security testing solutions that address the broadening risk landscape are no longer a ‘nice to have,’ but rather a ‘must have,’ and today, it’s imperative to leverage innovative solutions that address all code types and the associated risks within modern applications. As a result,  Checkmarx is laser-focused on helping our customers navigate software complexity and expand their test coverage to address the way applications are being developed and deployed, so they can improve the security and quality of their software without slowing down development. With 16+ years of innovation in AST, we remain committed and intensely passionate about delivering powerful solutions to organizations that thrive on the software they develop.

As we celebrate being named a Leader in the 2022 Gartner Magic Quadrant for Application Security Testing, we’d like to thank our incredible customers, partners, and employees who have been, and will continue to be, the cornerstone of our success.

Read the Full Report

Download a complimentary copy of the 2022 Gartner Magic Quadrant for Application Security Testing here.

To learn more about the Checkmarx AST Platform and our suite of Checkmarx AST solutions, visit: www.checkmarx.com

¹Gartner, Magic Quadrant for Application Security Testing, Dale Gardner, Mark Horvath, and Dionisio Zumerle, 18 April 2022.

Gartner Disclaimer:

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Gartner and Magic Quadrant are registered trademarks of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

The Evolution of TTP

In the very beginning of cyberattacks, attackers would spend time creating self-propagating viruses and worms to exploit vulnerable operating systems and desktop applications. For example, the “I Love You” virus, which dates back to the year 2000, infected over ten million computers worldwide. Names like Code Red, SQL Slammer, Sobig, MyDoom, Netsky, Stuxnet, Zues, and so on, made headlines all over the globe. As a result, antivirus companies proliferated, holes were plugged in operating systems, devices and perimeters were hardened, bug bounties were initiated, and many of these TTPs were defeated.

During much of this same period, a new genre of TTPs emerged in concert with these highly successful malware examples, and phishing became the new name – of an old game. Since perimeter and workstation defenses were somewhat difficult to overcome from the outside-looking-in, attackers knew that if they could fool someone into clicking on a link in an email, back doors could be opened, and perimeter defenses may well be defeated.

Therefore, a whole new generation of malware surfaced in the form of ransomware and botnets. For example, names like Locky, Tiny Banker Trojan, Mirai, WannaCry, Petya, and many more were the next malware variants to gain notoriety. Email phishing defenses, spam detection systems, employee email phishing training, etc. proliferated and helped defeat some of these attacks.

As a result, attackers likely began to conclude, “If we can infect a software supply chain, our malware proliferation and victim count could grow exponentially.” And in December of 2020 they did just that. The SolarWinds supply chain attack took place, leading to both government and enterprise data breaches that made headlines worldwide. However, the SolarWinds’ attack was leveraged against a commercial software supply chain and was not necessarily focused on what is called the open source supply chain.

Why Supply Chain – Why Now?

Today’s attackers realize that infecting the supply chain of open source libraries, packages, components, modules, etc., in the context of open source repositories, a whole new Pandora’s box can be opened. And as we all know, once you open that box, it’s nearly impossible to close. In fact, Checkmarx leadership saw this coming. Back in December of 2019, Maty Siman, Founder and CTO of Checkmarx contributed to this predictions blog.

Maty wrote, “With organizations increasingly leveraging open source software in their applications, next year, we’ll see an uptick in cybercriminals infiltrating open source projects. Expect to see attackers ‘contributing’ to open source communities more frequently by injecting malicious payloads directly into open source packages, with the goal of developers and organizations leveraging this tainted code in their applications.

As we see this scenario unfold, there will be a growing need for processes like developer and open source contributor background checks [contributor reputation]. Currently, open source environments are based entirely on trust – organizations typically don’t vet developers’ past projects or reputations. However, as attackers take advantage of open source projects, this trust will begin to erode, forcing organizations to take proactive mitigation steps by thoroughly vetting the open source code within their applications, as well as those providing it.”

So, as we see here, Maty Siman was spot on. Not only did Checkmarx see attacks on the open source supply chain coming, in fact, they did something about it by acquiring Dustico in August of 2021. Now, TTPs like dependency confusion, typosquatting, repository jacking (aka ChainJacking), and star jacking are the new name of the game. In fact, Checkmarx just released a new white paper today, Introduction to Supply Chain Attacks, explaining how these attacks actually work.

Landscape Changer: Checkmarx Supply Chain Security

As a result of Maty’s predictions (which did come true, by the way), and their proactive stance on defeating supply chain attacks, Checkmarx just announced a new arrow in the quiver of enterprise-class, open source supply chain defenses. Checkmarx SCA with Supply Chain Security (SCS) is now available, and the solution sets an entirely new bar for all SCA solutions.

Checkmarx is first to market with supply chain defenses organizations need now which include:

• Health and Wellness, and Software Bill of Materials (SBOM)
• Malicious Package Detection
• Contributor Reputation
• Behavior Analysis
• Continuous Results Processing

In addition to our white paper on supply chain attacks, Checkmarx released another white paper today, Don’t Take Code from Strangers – An Introduction to Checkmarx Supply Chain Security. This paper goes into detail about topics like SLSA, traditional code analysis, and pushing boundaries in secure software supply chain innovation.

Checkmarx SCA with Supply Chain Security (SCS) offers a more comprehensive approach to preventing supply chain attacks and securing open source usage by enabling developers to perform vulnerability, behavioral, and reputational analysis from a single, integrated platform. By natively integrating advanced behavioral analysis into SCA, Checkmarx provides developers with a streamlined, frictionless user experience to enhance their organization’s supply chain security.

To learn more about Checkmarx SCA with Supply Chain Security, you can request a demo here.

But modern applications also present some steep challenges, not least in the realm of security. In order to thrive in the modern development landscape, developers and AppSec pros alike must be sure that their security skills can address the variety of threats that teams face today – a time when cyberattacks are growing steadily in frequency and scope.

Here’s a list of four essential security skills that anyone involved in modern application development should possess.

IaC Security

Infrastructure-as-Code (or IaC) tools have become an essential part of many modern application development workflows. Using IaC, teams can automatically provision large-scale software environments, which maximizes scalability and minimizes the risk of configuration mistakes due to human error.

But the downside of IaC is that, if the configurations applied using IaC templates contain security issues, those issues will be proliferated across your entire environment. And in most cases, the IaC tools themselves do nothing to alert you to potential security issues.

That’s why developers and AppSec teams must learn to follow security best practices when configuring IaC templates, such as:

• Secure your secrets: Don’t hard-code passwords or other secrets into IaC templates. Store them in an external secrets manager instead.
• Modularity: Keep IaC templates short and modular. Trying to cram too much configuration into a single template increases the risk of making a mistake.
• Use default settings with care: Don’t blindly trust default IaC settings. Make sure you tailor templates to your environment.

Just as important, teams should use IaC scanning tools to validate their IaC configurations prior to applying them. IaC scanners automatically check IaC templates for misconfigurations that could create security issues.

Open Source Security Risks

There are many excellent reasons for modern development teams to leverage third-party open source code. Open source saves time because it allows you to reuse code that someone already wrote rather than having to write it yourself from scratch. It is also often easy to customize. And it’s usually free of cost, which is never a bad thing.

Yet open source also poses some significant security risks when you incorporate it into your applications. You can’t guarantee that third-party open source developers adhere to the same security standards that you do when they write their code.

For that reason, it’s critical to know where in your application you incorporate open source code, and also to scan that code to identify known vulnerabilities within it.

Container Security

Modern applications are often deployed using containers. Because containers – and the orchestration platforms used to manage them (like Kubernetes) – add another layer of infrastructure and complexity to your software stack, they create a variety of potential security risks that would not be present if you were deploying applications directly on a host OS, without having a container runtime and orchestrator in the equation.

Modern developers and AppSec teams need to know what these risks are and take steps to address them. A full discussion of container security is beyond the scope of this article, but basic concepts include:

• Image security: Securing container images by ensuring that any external components on which they depend are secure, as well as using a container image scanner to check for vulnerabilities.
• Configuration security: Scanning the configuration files that are used to deploy and orchestrate containers. Like IaC templates, these files can contain configuration mistakes that enable security breaches.
• Runtime security monitoring: Using monitoring tools that can collect and analyze data from across complex containerized environments (which means collecting data from various containers, from all of the operating systems running within the cluster of servers that hosts your containers, and from the orchestration platform) to detect signs of breaches at runtime.

Microservices Security Risks

Microservices have become massively popular because they make it easy to build agile, scalable applications that lack a single point of failure, among other benefits.

But microservices also significantly increase the complexity of application architectures, which in turn increases the risks of security issues. Because microservices rely on the network to communicate with each other, there is a higher risk of sensitive data exposure. Insecure authentication and authorization controls between microservices could enable a breach to spread from one microservice to an entire app. Security problems with the tools used to help manage microservices (like service meshes) create another set of security risks to manage.

As with container security (which, by the way, is a closely related topic, because microservices are often deployed using containers), there is more to say about microservices security than we can fit into this article. But some core microservices security best practices for developers and AppSec teams to follow include:

• Microservices isolation: When designing your microservices architecture, strive to isolate each microservice as much as possible. Allow interactions between services only where strictly necessary.
• Authentication and authorization: Always require authentication and authorization for microservices to communicate with each other.
• Network isolation: Isolate the internal networks that microservices use from the public Internet, and never expose a microservice directly to the Internet unless it needs to be.

Conclusion: Modern Application Development Requires Modern Application Security

Most of the security challenges discussed above simply didn’t exist ten years ago. Back then, no one was provisioning hundreds of servers using IaC templates or deploying applications with highly complex architectures based on microservices and containers.

But those practices are the norm for modern application development. Developers and AppSec teams must respond by ensuring that they are able to leverage the tools and skills necessary to meet the modern security risks that go hand-in-hand with modern application development.

Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure, and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.

Click here to learn more about security in the context of Modern Application Development