At Checkmarx, we’ve been building to this point for a long time. While we’re best known for SAST and SCA, we released KICS (Keep Infrastructure as Code Secure) as a free open-source tool in 2021 (also available on Checkmarx One) and partied like it was 2024 when it recently hit(and now well over 4 million). We launched Container Security in 2020 as well as the industry’s only shift-left API Security solution in 2022. We introduced our own cloud-native platform (Checkmarx One) in 2021 as a key milestone in our own cloud journey. We know what it means to be cloud-native, and we know what’s required to secure cloud-native applications.

That’s why we’re super excited about this launch. Checkmarx is already the #1 provider of cloud-native application security. This launch is a feather in the cap of everything we’ve done up to this point, but also a stepping stone for where we want to go next, helping organizations secure your applications wherever they are, whether they’re on-premises applications running in your data center or cloud-native applications deployed in the cloud.

But first…what does cloud-native mean?

There are a lot of buzzwords and jargon, but the concept is simple. Cloud-native simply means that an application was specifically designed to run in a cloud environment. But what does that mean?

If we start with your traditional monolithic application, you can deploy it on Amazon EC2 and – technically – now you’re in the cloud. But scaling the application is horribly inefficient. Like any complex piece of machinery, your application has many parts – some that have plenty of capacity, and a few that are bottlenecks. But because a monolithic application is a single piece of software, you must deploy another entire instance of that application. You have to scale the entire application as a single unit, even the parts that don’t need it.

In a cloud-native architecture, you would split out the different parts of the application into different software components that you can now deploy and scale independently – these are your microservices. All your microservices then talk to each other (so they can work together as a larger application) via predefined interfaces – these are your APIs. And because you might be deploying each microservice many (many) times, you want to remove the possibility of human error. This means you package a golden copy with everything it needs to run in a container, a technology that enables you to easily spin it up and run it anywhere. And finally, you automate the configuration of all the infrastructure needed to deploy that application with Infrastructure as Code.

CNAPP is not enough; you also need cloud-native application security.

In the past couple of years, Cloud-Native Application Protection Platforms (CNAPP) have emerged as a hot new security technology. It’s not difficult to see why, as it’s right there in the name – cloud-native applications and platform. CNAPP evolved from two sub-markets, Cloud Workload Protection Platform (CWPP) and Cloud Security Posture Management (CSPM) – and you can immediately tell what CNAPP solutions focus on – cloud workloads and cloud security posture (again, it’s right there in the name).

CNAPP solutions secure the cloud runtime environment, including network security (like firewalling and microsegmentation), monitoring application workloads, investigating anomalies in application behavior, and ensuring proper configuration of cloud infrastructure. That’s a lot of ground for a single vendor or platform to cover, and no CNAPP vendor does it all well today. Each vendor has different strengths based on what part of the market it grew out of, CWPP or CSPM. And that’s why many organizations today already have multiple CNAPP solutions.

But runtime environments are only half of the security story. If you have vulnerabilities in your application, you want to close them at the source and that requires shifting left into the development environment. And with everything it has to do already, CNAPP just doesn’t do application security well. That’s where we come in. Checkmarx has always focused on securing application development, with everything you need from the first line of code to packaging it in containers to deploying in the cloud. Not in the cloud? We help you cover your entire application footprint, whether it’s the latest cloud-native applications or a legacy application that you prefer to keep a little closer to home.

Reduce the noise and focus on what really matters

Cloud-native applications are complex, with many steps and moving pieces in the software development process. You need to scan your proprietary code for vulnerabilities and identify vulnerabilities (and malicious code) in open source software. You need to scan your container images to make sure your golden copy is as vulnerability-free as possible. And you need to scan your IaC templates to identify misconfigurations or other security issues. That means that application security has traditionally required a lot of tools, and lots of tools means lots of noise. This has been a major challenge for application security teams and the developers they serve.

At Checkmarx, we put a lot of effort into reducing noise. We start by making each solution as accurate as possible. You can see it in the results of our recent comparative testing, showing significantly higher accuracy for Checkmarx SAST and SCA vs. one of our “developer-focused” competitors – out of the box with no tuning (which means it gets even better with tuning). We also launched our next-generation SAST engine in January, with a new lightweight scan and super-low false positives with no tuning required, ever. And finally, we just announced our in-IDE, real-time code scanning in AI Security, providing immediate feedback to developers as they’re writing their code.

We also correlate data between solutions wherever possible with our correlation layer, which we launched back in 2022. An example of this is our exploitable path feature, which correlates findings between SAST and SCA to identify the vulnerabilities in open source libraries that are actually in functions or methods called by your source code, and therefore exploitable in your application. We tested our exploitable path feature in the Tolly report, and the results show that it’s easy for anybody to claim to have a feature like correlation, but there’s a difference between having it and doing it well (hint: we do it well).

Finally, we announced Application Risk Management last June. Application Risk Management builds on our correlation, with the ability to see risk across all your applications at a glance. This allows you to focus on the most critical applications first, or those with the highest amount of risk. Its very premise is reducing the noise and helping you focus on what really matters, i.e., “If you have only 30 minutes to do something right now, what would you do and where would you focus?”

Introducing Checkmarx ASPM

Until now, the focus of Fusion and Application Risk Management has been helping you get more out of your Checkmarx solutions. But we know that you have other AppSec tools in your environment that you need to manage as well. That’s why we’re introducing Checkmarx ASPM. ASPM builds on our existing correlation, prioritization, and risk management capabilities with Bring Your Own Results (BYOR). You can take advantage of all the correlation special sauce (like exploitable path) that we build into our products, as well as ingest data from using industry-standard SARIF files. This allows you to manage your entire AppSec posture with Checkmarx One, across both Checkmarx and any other solution you may have (including our competitors). One dashboard, one correlation engine, one risk management view, and one workflow for analyzing and triaging vulnerabilities for your developers to remediate.

Read the blog post to learn more about Checkmarx ASPM.

Correlating runtime data from CNAPP partners

This launch also builds on two partnership capabilities that we previously announced. Our integrations between Container Security and Sysdig and Wiz really highlight the potential of code to cloud security to reduce the noise. Just as exploitable path identifies vulnerabilities in open source libraries that aren’t in functions or methods called by your code, our integrations with Sysdig and Wiz give you additional tools with which to prioritize where you focus:

• With Sysdig, we help you identify vulnerabilities in open source libraries that aren’t actually called by your application in the runtime environment. This means that, while those vulnerabilities technically exist in your application, the likelihood of them being exploited is far lower than others in libraries that are called by your application at runtime.
• Our Wiz integration allows us to identify the container images that have been deployed in a cloud environment and are Internet-facing. This means that they can be more easily attacked and have a higher risk than those that cannot, helping you prioritize remediation for projects based on their network exposure in runtime.

Bringing you Cloud Insights

For those of you who may not have a CNAPP solution like Sysdig or Wiz today, we’re launching Cloud Insights. This capability is included with Checkmarx ASPM and connects Checkmarx One directly with your cloud infrastructure, where we can pull data from various infrastructure components to identify the containers running in the cloud. This allows us to identify projects and microservices that are Internet-facing in the runtime environment, similar to our integration with Wiz.

We then correlate this with our own vulnerability data to enhance our risk scoring in Application Risk Management and make it easier for you to understand your holistic application risk. Equally importantly, it helps us connect the dots between containerized microservices running in your cloud environment back through the software development lifecycle (SDLC) and to the specific software projects and code repositories in which they live. This gives you full visibility into your applications from end to end, or from code to cloud. Cloud Insights supports AWS EKS environments today, with other cloud providers to come in the future.

To learn more about Cloud Insights, read the announcement blog post here.

Taking AppSec to the board

And finally, we’re also announcing our new Executive Overview dashboard. Available to all Checkmarx One customers, the Executive Overview dashboard takes all the data available in Checkmarx One and gives you a bird’s-eye view of your entire application security program. You can measure and track your most important application security KPIs in a single place, including mean time to remediate (MTTR), vulnerability density, and  application rating score. It also includes advanced filtering capabilities, such as by , application, or project, to customize your view based on your organization hierarchy, application structure, or other needs. You can track how your application security capabilities are being used across all your applications under development, and identify trends or anomalies in that adoption.

Get all the details about the Executive Overview dashboard here.

How to get started

Like everybody else’s, your SDLC is complex with many steps and many moving pieces, and there’s a lot of noise you must sift through. Checkmarx helps you reduce the noise and focus on what really matters, by correlating data across of your application security solutions (Checkmarx and third-party), prioritizing the most critical vulnerabilities to fix first, and giving you full visibility into your application risk. We’re super excited about how Checkmarx ASPM, Cloud Insights, and Executive Dashboard (along with our integrations with Sysdig and Wiz) can help you secure your cloud-native applications from end to end and code to cloud.

If you’re on Checkmarx One, reach out to your account manager to learn how to get these capabilities today. If you’re new to Checkmarx or Checkmarx One, fill out this form to get started.

Disclaimer: no AI was harmed in the creation of this blog post.

As a result, security and development teams are focusing on how to best secure their growing API footprint. With many API security solutions on the market, it can be hard to determine which one is the right choice for your organization. Here is a quick checklist to leverage during your evaluations: 

1. Can it find all your APIs?

For any API security solution, its ability to secure APIs relies on knowing what APIs exist. Many solutions require security teams to upload API documentation, such as Swagger or RAML files, which define an API. This approach relies on developers properly documenting their APIs, uploading documentation to a common repository (such as Postman), and keeping documentation up to date as the APIs evolve. 

Other solutions discover APIs by watching where traffic goes, by monitoring traffic on a CDN or integrating with hardware appliances, including API gateways, web application firewalls (WAFs), or load balancers, where API traffic flows. This requires the AppSec team knowing all the network chokepoints that API traffic flows through, which isn’t always easy in a changing network environment. Not only that, but it is easy to miss traffic to APIs that are publicly exposed but see little traffic.

Checkmarx starts by scanning your application source code, so we can discover all the APIs in your application. This approach does not require APIs to be properly documented (although that’s still good development hygiene), and can be done without having to integrate with your network infrastructure.

2. What about shadow and zombie APIs?

Shadow and zombie APIs are a big challenge with most API security solutions. A shadow API is another name for an undocumented API. Traditional API security solutions, such as WAFs and API gateways, require API documentation to configure protection – they cannot protect what they don’t know. AppSec teams are often not aware of these APIs and refer to these as shadow APIs.

A zombie API is an API that has been abandoned or forgotten. Organizations can inadvertently create zombie APIs when creating new versions of an API. In this situation, organizations often choose to leave the original API in production for a limited time, to ease the migration of users and traffic to the new API. However, they might forget to decommission it after the migration. Zombie APIs may see little traffic after users have been migrated but remain exposed for attackers to find.

Checkmarx helps you identify shadow and zombie APIs by comparing your global API inventory – the full list of APIs discovered in your application source code – with API documentation provided by your developers. This allows us to identify gaps in documentation and work with your developers to close them.

3. Discovering APIs and identifying vulnerabilities

Discovery is only the first step when it comes to securing your APIs. Once you’ve built a full inventory of your APIs, the next step is to identify what vulnerabilities they may have. Runtime solutions such as API gateways and WAFs can tell you what types of attack traffic may be targeting your APIs (and hopefully block it), but they can’t tell you if the targeted APIs are vulnerable to detected (or undetected) attack traffic in the first place.

Checkmarx layers our API Security solution on top of Static Application Security Testing (SAST) to not only discover APIs, but also identify vulnerabilities in your application source code and connect them to individual APIs. Checkmarx provides an API-centric view into your vulnerabilities, allowing you to see a breakdown of detected vulnerabilities by API, so you can focus your efforts on securing your most critical APIs.

4. Find and fix vulnerabilities – earlier in the SDLC

The cost to fix a software problem discovered in production is 100x more costly than if fixed in the design phase, and 15x more than during the coding phase. This provides a powerful incentive to find and fix vulnerabilities as early in the software development lifecycle (SDLC) as possible. However, most API security solutions focus on APIs already deployed in production environments, where identified vulnerabilities are the costliest to fix.

Because Checkmarx discovers APIs and identifies vulnerabilities in your application source code, we help organizations fix vulnerabilities in the coding phase where they can be remediated faster, with less disruption, and at lower cost. Checkmarx also identifies data discrepancies between API documentation and source code to address both improperly coded APIs as well as API drift. And finally, Checkmarx provides an API change log to help you understand the full history of changes to an API so you can understand how risks were introduced over its lifecycle.

5. Standalone solution vs AppSec platform

Modern applications continue to evolve, with greater complexity and more pieces to secure that need more security tools to secure them. Application security teams have more tools than they can properly manage, an issue that is magnified when every tool needs to be managed separately. 

Consider API security solutions that simply discover APIs in production environments. Arming AppSec teams with that information is a good start, but those APIs must still be tested to identify vulnerabilities – either the live API with a Dynamic Application Security Testing (DAST) tool or the source code with a SAST tool. And even if the solution identifies vulnerabilities in an API, now AppSec teams must manually correlate identified vulnerabilities with those identified by other tools.

Checkmarx approaches API security as a part of a more holistic approach to application security. Our Checkmarx Oneplatform provides organizations with all of the tools needed to secure every part of the application, including not just SAST, DAST, and API security, but also Software Composition Analysis (SCA), Software Supply Chain Security (SSCS), Container Security, and IaC Security. 

6. Automate as part of. your DevSecOps pipeline

As development becomes more agile, development teams are becoming more fragmented – often by design. This allows different developers or teams of developers to work on different parts of an application independently of each other. This also can make it more difficult for AppSec teams to stay on top of changes to the application. In this type of development environment, AppSec teams know that the only way to ensure security checks always take place is to automate scans at different parts of their DevSecOps pipeline. 

With Checkmarx One, integrating with any tool in the SDLC, from software repos to build tools, is as simple as a few clicks of the button. Checkmarx integrates with the broadest range of SDLC tools in the industry and, as a unified AppSec platform, integrates all of our AppSec solutions with any SDLC with a single set of integrations.

7. Who’s responsible for fixing?

AppSec teams know that their job is to find security vulnerabilities – but not fix them. AppSec teams don’t touch application code and need development teams to fix the vulnerabilities. However, finding the developer responsible for one specific API in a live application can be difficult. That’s one reason why it’s more costly to fix a software issue in production than during the coding or design phases, because you often don’t know who’s responsible for fixing any issue that’s discovered. 

But when you find vulnerabilities by scanning application source code, you know who owns the project where the code is found. This makes it easy to assign identified vulnerabilities to a developer to fix. Checkmarx automatically creates and assigns bug tickets for discovered vulnerabilities, automating the process of getting security issues into the hands of the developers who can fix them.

8. Make it easy for developers to fix vulnerabilities

Traditional API security solutions, like WAFs and API gateways, can identify potential exploit attempts in live traffic targeting an API, but they can’t tell you whether a targeted API is vulnerable to any particular exploit. Identifying vulnerabilities in live APIs requires scanning the application with a DAST tool – either as part of a penetration test or automated in the DevSecOps pipeline. But even with a DAST tool, developers still must debug the API to understand an identified vulnerability before they can fix it.

As part of our overall developer experience, Checkmarx makes it extremely easy for developers to fix any identified vulnerabilities, with capabilities such as:

• Feedback tool integration – Checkmarx can automatically log bug tickets (e.g., JIRA) for discovered vulnerabilities and assign them to developers. Even better, we’ll automatically close the ticket when the vulnerability has been fixed.
• IDE integration – Checkmarx integrates with all the most popular IDEs to bring security findings into developers’ existing workflow, making it easy for them to fix vulnerabilities without ever leaving their environment.
• Best-fix location – tells you the exact line of code to optimally fix a vulnerability. Because of how applications work, fixing a vulnerability at the best-fix location can potentially address multiple vulnerabilities at once.
• Guided remediation – Checkmarx provides instructions on how to remediate a detected vulnerability – both in the bug ticket as well as in the IDE, to help developers even with limited AppSec expertise to fix vulnerabilities.

Checkmarx API Security

Checkmarx takes a different approach to API security. We help organizations discover all their APIs in code – including shadow and zombie APIs – and address security issues earlier in the SDLC, where they are less disruptive, time consuming, and costly to fix. Checkmarx API Security is available on our award-winning Checkmarx One enterprise AppSec platform, enabling AppSec teams to tackle API security as one part of a broader and more holistic application security strategy.

Because what do you look for in an AppSec platform? Gartner published its latest Hype Cycle for Application Security, 2023 in July. What’s always fascinating with the Hype Cycle is the juxtaposition of market interest and customer adoption. For example, Application Security Posture Management (ASPM) is currently at the very Peak of Inflated Expectations. Everybody is talking about it. Vendors are positioning themselves. Customers are trying to understand what ASPM can do for them, because Gartner says it’s going to have a transformational business impact…in two to five years.

This challenges us to think about and evaluate AppSec platforms in a different way. Every enterprise has a technology roadmap of when they plan to purchase and deploy different technologies over the next five years, and AppSec is no different. Our customers typically start with SAST. Then, they move to SCA. Then, they move to API security, supply chain security, or Infrastructure as Code security. The purpose of a platform is to make it easier to integrate all these different solutions into your technology stack. But that means you’re also making a bet. Because it’s not just about which platform best meets your needs today, but also going forward. You’re making a bet that the platform you choose today will continue to meet your technology needs in the future when you’re actually ready to adopt.

That’s why the Checkmarx One 3.0 release is so exciting. There are always new features and capabilities. Now we can start talking about how those new features and capabilities connect us from where we started when we launched Checkmarx One almost exactly two years ago, to where we’re going, and how we’re building the AppSec platform of tomorrow. 

AI-Powered Application Security

You don’t need me to tell you that AI is popping up everywhere. At Checkmarx, we’re focused on tackling the three grand challenges that AI brings to AppSec:

• AI is disrupting the developer workflow. In Stack Overflow’s 2023 Developer Survey, 72% of developers believe their workflow for writing code will be very or somewhat differently just one year from now, because of AI tools. For AppSec teams, the question is how to keep up with and adapt to that change.
• AI will introduce new threats. Change in application architecture or software development always has the potential to introduce new attack vectors. We’ve already seen examples of AI hallucination attacks, but these are just the beginning as developers increasingly embrace new ways to build applications.
• AI can democratize AppSec. AppSec has always been a challenge, with not enough resources or expertise. Today, responsibility is increasingly shifting to developers, which will exacerbate the problem. However, embracing AI in AppSec can enable and better support developers to build increasingly secure applications.

We’re building the AI-powered enterprise AppSec platform. With version 3.0, you’ll see new innovations across all our solutions and technologies that both leverage AI and help you better respond to the coming AI tsunami in your own organizations.

Seamless Developer Experience

Checkmarx One 3.0 includes many improvements to our overall developer experience, and also introduces a new way to approach it. When most vendors approach developer experience, they typically start with integrating AppSec into the developer workflow. At Checkmarx, we start even earlier with the accuracy of our solutions and the prioritization of our findings, because that reduces the noise that enters the developer workflow in the first place.

We’re especially excited about the new AI Query Builder. AppSec practitioners know that application security is hard. No AppSec solutions are 100% accurate out of the box. Every application is different, and every solution needs to be tailored to each application to minimize false positives and negatives. Checkmarx SAST has always provided 40+ presets to start tuning out of the box, as well as a custom query builder to further refine it. Now, AI Query Builder gives every customer the ability to tune their SAST, even if they have limited AppSec expertise.

Expanded Supply Chain Security

Checkmarx has always led the way in Software Supply Chain Security (SSCS). We were the first Software Composition Analysis (SCA) vendor to introduce malicious package detection. Checkmarx Labs inspects over 7.6 million open source packages for all kinds of threats as part of our open source security initiatives, and we’ve identified over 200k malicious packages to date.

For most of our customers, malicious package detection is an easy first step into SSCS because it takes advantage of their existing SCA product to manage malicious packages – in the same way they manage vulnerable packages today. As part of Checkmarx One 3.0, we’re excited to expand our vision, and portfolio, with secrets detection, project scorecard, and AI code generation to help our customers protect more and more of their software supply chain.

End-to-End API Security

Last August, Checkmarx introduced API Security as the industry’s only true shift-left API security solution. We started with the capabilities needed to discover and inventory APIs in source code, which was (and still is) a unique approach to combatting the problem of shadow or undocumented APIs. In April, we introduced Checkmarx DAST, which provided an opportunity to expand on what we launched and build an end-to-end API Security solution. 

Like a Web Application Firewall (WAF) or API gateway, most DAST solutions require you to tell them where your APIs are, typically with some form of API documentation like a Swagger file, before they can test your APIs. This means that they can’t help with shadow or undocumented APIs. By integrating API Security and DAST together, Checkmarx One 3.0 now can discover every API in your source code, including shadow or undocumented APIs, and test them in live applications with DAST, allowing your enterprise to shift everywhere.

Get the Most Out of AppSec Consolidation

We’ve been talking about consolidation for as long there have been point solutions. Many of you have security technology stacks with hundreds of different tools, which presents a challenge for operational management, vendor management, and costs. 

At Checkmarx, our vision is to be your enterprise AppSec platform and help you bring all your AppSec solutions under one roof, behind a single pane of glass, and with an additional correlation and prioritization layer to enable your teams actually reduce risk. With Checkmarx One 3.0, we’re building on our launch of Fusion last year, Application Risk Management this past June, and our recent Sysdig integration announcement to show you how this comes together in an extensible AppSec platform that helps you shifts everywhere from pre-production to production.

Learn More

We’re excited to introduce these new capabilities as part of our Checkmarx One 3.0 launch. There’s just so much here that everything above feels like only the introduction. We’re just starting to unpack everything that’s in this release and what it can mean for you. To learn more about these capabilities, join us in our platform launch event today (or watch the recording after) or our deep-dive webinars into each of the topics above at the end of October. For Checkmarx customers, please reach out to your account team to learn more about these (and more).

^[1] Source: Gartner, Hype Cycle for Application Security, 2023, Dionisio Zumerle, 24 July 2023

As I walk around the RSAC show floor today, I see the word, “platform,” everywhere. Every security vendor has a “platform.” Everybody’s talking about their “platform.” I’m sure that many of you have a similar reaction — this is a word that has lost its meaning. Admittedly, we also talk (a lot!) about our Checkmarx One Application Security Platform. So what does “platform” mean to us? And what should it mean to you?  

When we look at how you develop and secure your applications, our job is to make your job easier. So our platform combines all of the different tools you need to secure your application development, including SAST, SCA, supply chain security, API security, Infrastructure-as-Code (IaC) security, and container security. You can trigger all of these through a single scan. You can see and triage all your vulnerabilities in one place. You can deploy everything more easily and automate across your applications, with a single set of SDLC integrations. And you can make it easier for your developers to fix things, with IDE integration, feedback tool integration, PR decoration, and more. 

Our platform is also how we roll out new products and capabilities. When we launch a new product, it’s automatically incorporated into your existing workflows. When we release new features, you automatically get them in your existing products. And today, we’re introducing a number of new and updated products and capabilities across our platform as part of our April 2023 platform launch.  

Dart and Flutter support 

Programming language support is #8 on our Top 10 Key Considerations when choosing a SAST solution as part of an AppSec platform. Most organizations actually have a broad requirement, from current languages you’re coding with today, to the long tail of older languages in your legacy applications, to future languages that you don’t know about yet. 

With this release, Checkmarx SAST introduces the industry’s first support for Dart and Flutter, two of the fastest growing client-side programming languages and application development kits on the market today. Dart and Flutter support continues our commitment to have the broadest language support on the market, and helps you build modern digital experiences that stretch across platforms but are increasingly driven by mobile. 

Private packages 

Software composition analysis (SCA) has traditionally focused on open source risks, including license risks and known vulnerabilities. More recently, Checkmarx introduced detection of malicious packages in open source software as the second step in software supply chain security (with SBOM generally regarded as the first step). 

Now, we’re introducing support for private packages — software packages and libraries that are not publicly available, typically stored in private package repositories or internal registries. Checkmarx SCA can now scan and analyze private packages and identify vulnerabilities that may exist within them, providing organizations with a comprehensive view of their software stack and broadening what’s typically included in software composition analysis.  

You can read more about Private Packages on Thursday in a blog post from our of Head of Product, Steve Boone. 

Exploitable path for C# 

Is a vulnerability actually exploitable? Every SCA solution can tell you if a vulnerability is present in an open source package used by your application, but that doesn’t mean it’s exploitable.  

When we talk about “platform” at Checkmarx, we talk a lot about synergies between the different AST solutions that we offer on our platform. Exploitable path is a really cool feature that combines the insight from Checkmarx SAST and SCA products, and tells you when your proprietary code actually calls vulnerable code in an open source package. This is a powerful feature that relies on having SAST and SCA capabilities not just on the same platform, but talking to each other in useful ways. 

With this release, Checkmarx SCA adds C# to the list of supported programming languages where this feature is available. 

SCA available for all developers in Visual Studio Code 

For developers using Visual Studio Code, Checkmarx has always offered a Visual Studio plugin that brings the results of Checkmarx One (SAST, SCA, and IaC) scans directly into your IDE. Now, we’re making Checkmarx SCA available for free through the Visual Studio plugin, so that all developers (regardless of whether you’re a Checkmarx customer) can scan and analyze their open source packages for vulnerabilities. 

New DAST offering 

For organizations looking to test throughout your SDLC, Checkmarx is bringing our DAST offering directly onto Checkmarx One. This means that you can now scan your proprietary code using SAST on the same platform that you use to scan your compiled applications with DAST. Enabling common integrations means that both SAST and DAST scans can be automated as part of your SDLC. More importantly, you can see all of your vulnerabilities in one place, triage for your developers using the same workflow, and send to them to fix using the same feedback tool integrations (e.g., JIRA). You can read more about Checkmarx DAST in this blog post by Andrew Schmit, and see it in action here. 

Easier shadow API detection 

Last August, we introduced the industry’s first “shift left” API Security solution that identified API vulnerabilities in code, rather than waiting for applications to be built and deployed. One of the central advantages was that we could scan proprietary code to discover and inventory your API endpoints defined in code, and compare that to the list of documented APIs, and identify your shadow APIs before they get out to production. 

With the April 2023 platform launch, we’re making it easier to do so by allowing you to set up API documentation scanning as part of your unified scans for any software project. You can see Checkmarx API Security in action here.

Supply Chain Threat Intelligence 

In case you missed it, Checkmarx announced the availability of our Supply Chain Threat Intelligence offering back in January. Supply Chain Threat Intelligence takes all of our latest threat intelligence on malicious packages, used by our security researchers to identify attackers such as RED-LILI and Lofygang, and makes them available to customers via a simple API call. This allows you to build that intelligence into your automated SDLC workflows, even if you’re not a Checkmarx One customer. 

New secrets detection engine 

Finally, Checkmarx is releasing a new secret detection engine, aptly named Too Many Secrets (2MS). In the context of applications, secrets are sensitive information such as passwords, API keys, cryptographic keys, and other confidential data that an application needs to function but should not be exposed to unauthorized users. As part of the development process, developers often use collaboration tools like Confluence to share secrets necessary to develop an application. And then, because we all forget about things, these secrets can be accidentally published and disclosed.  

2MS is an open source project dedicated to helping people protect their sensitive information like passwords, credentials, and API keys from appearing in public websites and communication services. Read more about 2MS tomorrow in a blog post from its product manager, Bryant Schuck, and download the project yourself from GitHub. 

Learn more 

We’re excited to introduce these new capabilities as part of our April 2023 Platform Launch, as we continue to enhance our platform to make your jobs easier. For Checkmarx customers, please reach out to your account team to learn more about these (and more). 

Because the problem is organizational, the solution to the problem can’t be a reactive one. It must be proactive. With API Security, Checkmarx is taking a fundamentally different approach, a true shift-left approach to help proactively address the problem of shadow and zombie APIs.

What is an API?

API stands for Application Programming Interface. It’s a set of definitions and protocols (e.g., REST, SOAP) that define how you can communicate with a software component or service. This may sound abstract, but it’s really not. It’s basically just a mechanism to perform a transaction – you request information by asking the right question, and the application provides it in response.

Think of the real-world analogy of a bank transaction. I can go into a bank and request money by filling out a withdrawal slip and handing it to the teller, along with my ID to prove that I’m the account owner. Here, I’m the client. The teller is the API. My name, account number, and ID are the parameters that I pass to the API. The money being withdrawn is the data. And the deposit slip is the API documentation.

Why are APIs important?

APIs are a key architectural component that enables broader architectural changes like cloud migration, shift to microservices-based architectures, and agile development. APIs allow for an application to be broken down into multiple smaller components (e.g., microservices), by establishing a clearly defined protocol for those different components and services to communicate and share data with each other.

Figure 1: an example ecommerce web application comprised of microservices deployed across multiple cloud providers and SaaS services.

For example, organizations building a cloud-native application typically split the application into many smaller microservices that must communicate with each other to comprise the whole. This allows them to scale different microservices with different scaling requirements independently of each other to better take advantage of the cloud. In addition, different developer teams can build, deploy, and update different microservices independently of and in parallel with each other, allowing them to move and release software faster.

What is API security?

When you visit a website in your browser, that browser may be showing content and data retrieved from different backend application services using APIs. Likewise, when you open a mobile app on your phone, that mobile app also typically retrieves data from backend services using APIs. These browsers and apps are communicating with APIs over the open Internet, which means… that those APIs must be publicly available on the Internet.

When you combine that with the fact that the primary purpose of APIs is to share data – and share data more efficiently – APIs are ripe for abuse. What type of abuse? The OWASP Foundation maintains a list of the API Security Top 10 risks to help security professionals understand the different types when building APIs. Erez Yalon does an excellent job breaking these down here. Regardless, with the prevalence of publicly exposed APIs, it is no wonder that the number of API-based attacks are increasing. In this recent example, Checkmarx researchers discovered a vulnerability in the Amazon Photos Android app that would have allowed an attacker to steal a user’s Amazon access token and use it to authenticate with and access other API-based Amazon services to steal PII (Personally Identifiable Information) or other information.

API security refers to the task of securing APIs from attack, either by identifying and blocking live attacks, or fixing vulnerabilities in APIs before they go live and can be attacked.

Why is this a problem now?

API security has always been a problem. However, recent years have seen rapid growth in the use of APIs when building modern applications. For example, Postman reported a 56% growth YoY in the number of API requests in its 2021 State of the API Report. And 49% of developers surveyed said that more than half of their organization’s development effort was dedicated to APIs – an increase of over 40% from the previous year.

This growth has dramatically increased both the attractiveness of APIs as a target of attack, as well as the severity of the challenge facing application security teams. The size of the problem keeps getting bigger every year. Security teams are realizing that they cannot kick the can down the road forever, or continue reactively plugging holes, and need a permanent solution now.

OK. So why hasn’t this problem already been solved?

First, a disclaimer – there are existing API security solutions today. In the AST (Application Security Testing) market, vendors including Checkmarx have always helped secure applications against OWASP API Top 10 risks, simply by scanning API code for vulnerabilities. And runtime solutions like web application firewalls (WAFs) and API gateways have provided varying levels of API protection capabilities for years. However, these solutions have not solved the problem, because the problem is not really that we cannot protect an API against attack. The problem is that security teams do not know what APIs they have.

Figure 2: existing API security approaches are limited by what they can see.

Consider a WAF (Web Application Firewall). Security teams can configure a WAF to protect an API. This requires registering the API with the WAF appliance, so it knows where the API is (the URL), what it looks like (parameters), and what good traffic looks like (a positive security model). Because an organization can have 100’s or 1000’s of APIs that frequently change, manually registering every API is not practical. The better way is to import API documentation or design files that describe the API in a standard format, such as Swagger, RAML, or Open API. However, there are two problems here:

1. The first is that many APIs are not documented. Sometimes, developers do not document an API. Other times, nobody shared that documentation with security. Regardless, if security teams do not have the documentation, then they do not know about the API, and they cannot configure the WAF to protect it.
2. The second problem is that Swagger and RAML files are typically created in the design phase before coding begins. APIs then must be coded, and developers may inadvertently stray from the design when coding the API. Bugs happen. Many API vulnerabilities result from differences between an API’s documentation and what was actually written in code, and these cannot be found by looking at the documentation.

More recently, API threat protection solutions have entered the market to discover undocumented APIs. These work by integrating with WAFs, API gateways, and other network devices such as load balancers. They analyze the traffic going through them to discover some of your shadow APIs that the traffic is going to, but cannot solve the problem, because:

1. They are limited to what they can see. They can only see the traffic going through the devices they integrate with. If there are APIs that are not behind these devices, then they cannot see them. Think about your application infrastructure. How many services do you have, and where are they deployed? How many WAFs, API gateways, and load balancers are in your environment that would need to be integrated with? And how often does your infrastructure change, affecting where services are deployed and where traffic flows?
2. The other problem is that you are still trying to fix the problem in production. While these solutions may claim to be “shift left,” analyzing live traffic to APIs already in production is not. First, APIs may already be under attack. But more importantly, discovering APIs in production means that security teams must go back and find the developers who coded them. And by the time they do, those developers have already moved on to other projects and have to context-switch back, lowering their productivity and slowing down those other projects.

Figure 3: Checkmarx takes a fundamentally approach to discovering and inventorying APIs

Great, how do you do it differently?

Checkmarx API Security takes a true shift-left approach to help customers address the problem of shadow and zombie APIs. This is a fundamentally different approach to the problem than other solutions described above, which follows several key tenets:

Figure 4: Four key pillars to the Checkmarx solution

• Discover and inventory APIs in source code:

All the solutions described above are dependent on security teams knowing all the chokepoints in the application infrastructure through which API traffic flows. The problem is that most security teams do not know all the chokepoints for all their applications, and the chokepoints they do know continuously change as application services are deployed, moved, or changed.

Instead, Checkmarx scans application source code as it is checked in to discover and inventory all the APIs that are written and exist in code. This happens while scanning source code for vulnerabilities, which we then connect to the specific APIs in which those vulnerabilities are found to provide an API-centric view on risk. Imagine being able to look at all your APIs, pick your most critical ones (for example, your login APIs), and prioritize vulnerabilities in those APIs based on severity.

• Compare source code with documentation:

Many API vulnerabilities happen when an API is coded in a different way than what was documented. That means you cannot identify a risk or vulnerability solely from looking at the documentation. You also cannot configure security controls without validating the documentation.

Rather than rely solely on API documentation, Checkmarx API Security does two things:

1. First, it identifies APIs that exist in source code but do not exist in documentation. Providing this inventory of undocumented APIs gives you a complete view into your shadow and zombie APIs, regardless of where they are or whether they are behind a WAF.
2. Then, we look at the documented APIs and compare how the API is written in code against its documentation to identify data discrepancies that can lead to a vulnerability.
3. Make it easier for developers to fix problems before APIs go into production

Checkmarx API Security integrates with Checkmarx SAST to scan source code as it’s checked in. When vulnerabilities are found, Checkmarx automatically creates bug tickets (such as with JIRA) for that vulnerability. This puts the vulnerability in a context that developers understand and are used to fixing as part of their day-to-day routine – the software bug.

Security teams can identify shadow APIs and track vulnerabilities discovered as the API code is first checked in. This allows security to work with closer developers earlier in the SDLC, to properly document APIs and address any vulnerabilities found.

So, what’s the bottom line?

Taking a true shift-left approach can give security teams complete visibility into their API footprint. By integrating with the SDLC during the design, coding, and check-in phases, Checkmarx API Security offers an easier way to keep up with the continuous change in the API environment – and enable your developers to fix any problems found.

Figure 5: taking a true shift-left approach to API security allows you to discover all your APIs

But perhaps the final advantage is that, with Checkmarx, this can be done without the need for any additional tooling. You don’t need to purchase, deploy, and manage an API-specific solution that doesn’t solve the entire problem. Instead, you can find your shadow and zombie APIs with the same AST solution you already have and are already using to find and fix vulnerabilities.

To find out more, go to https://checkmarx.com/product/api-security