When looking at any developing technology, the two questions that a security professional should ask are the same: How can that help us? And how will it hurt us? GenAI is, in a sense, a new automation technology. It can provide incredible efficiencies for AppSec and development teams. However, it can also create and expose security vulnerabilities, and become a powerful tool for malicious actors. 

Recognizing these challenges and opportunities, we are focusing on building the AI-powered AppSec platform of the future – both to empower you and your teams with AI, and to protect you from it. This post offers a deep look at our vision, highlighting our dual focus on streamlining the developer experience and safeguarding against emerging AI-powered threats.

Making AppSec Easier for Developers

The cornerstone of our strategy revolves around our dedication to improving developer efficiency. We are committed to enhancing the overall experience that developers have with application security, making their jobs easier and apps more secure. 

Most developers don’t have much experience with application security; therefore, they often do not have the knowledge to quickly remediate a vulnerability. Coming up with a solution can be difficult and time-consuming. Checkmarx has typically addressed this through Codebashing, our interactive security learning and development program. The addition of the GenAI-based Guided Remediation feature to our platform allows developers to quickly interpret, and act on, security scan results, drastically reducing the time between spotting and addressing vulnerabilities.

Making AppSec easier for AppSec teams with AI

One of the core challenges in the field of AppSec lies in its very nature. AppSec is, by definition, the intersection of two different disciplines: application development and security. Every application is different. Despite the use of open-source software, the variations in codebases are endless. This can lead to low accuracy results from many AppSec tools. Therefore, these tools should be tuned and customized for each application they interact with to properly find vulnerabilities with a low rate of false positives. Many AppSec teams don’t have the skillset to do this in the first place, and for those that do it can still take time and energy from both AppSec and development teams. Clearly, there are multiple roles here for AI to play.

First, there is an opportunity for GenAI to address the skills and resource gap in AppSec teams. At Checkmarx, we’ve just unveiled new GenAI features in the platform to alleviate the need for security professionals to spend hours mastering intricate query languages. Through the Checkmarx One platform, you can now generate custom security queries with ease, ensuring better security outcomes and a more user-friendly experience.

The increasing number of necessary AppSec tools, combined with the proliferation of new applications and microservices-style codebases, has led to a glut of vulnerability data coming from different sources in different formats. This creates a major challenge for AppSec and development teams in prioritizing where to focus their efforts. This presents a massive opportunity for AI to sift through this data, correlate the results, and present AppSec teams with reliable guidance on where to prioritize. 

AI’s Role in the Evolution of Software Supply Chain Security

Historically, any major change in architecture, technology, and tooling has introduced new vulnerabilities and new threats from malicious actors. AI is no different. When added to the developer workflow, AI introduces potential new vectors for attackers to take advantage of. This is leading to new threats, particularly in the emerging field of software supply chain security.

We are at the forefront of identifying and countering these AI-specific threats, with examples such as:

• AI Hallucinations: These are false data points or patterns that AI models might “perceive” due to adversarial inputs or misinterpretations, which can be exploited by malicious actors.
• Prompt Injections: Threat actors can manipulate AI models by introducing or “injecting” specially crafted prompts, tricking the system into undesired behaviors or outputs.
• AI Secret Leakage: There’s a potential risk of AI models inadvertently revealing confidential information they were trained on, offering a goldmine for cybercriminals.

It’s crucial for developers and AppSec teams to understand that generated code isn’t inherently safer than open-source code. Many code generation tools rely on open-source materials, which can have their own set of vulnerabilities. Recognizing the risks of external code sources, we aim to guide developers through the complexities of using code from open-source platforms and AI-generated systems. By collaborating with large language models such as ChatGPT, we empower developers to securely leverage AI code generation tools to scrutinize their generated code. This proactive approach helps in identifying potential vulnerabilities, especially in code sourced from open-source materials.

So, what now?

In the complex realm of application security, our AI-driven approach stands out as both innovative and essential. By enhancing developer skills and providing tools to combat emerging threats, we are not only shaping the present but also envisioning a safer future for application security. 

To hear more about Checkmarx’s AI vision and strategy, join us at our upcoming Deep Dive Webinar, AI-Powered AppSec, on November 7, 2023.

Organizations must take steps at every stage of the software supply chain to ensure developers’ environments. Enterprises must also make sure processes and secured, so you aren’t leaving your business vulnerable to next-generation SCS attacks, like AI package hallucinations, dependency confusion, typosquatting, and repojacking. 

Let’s dive into a brief history of how “supply chain security” has evolved to the point we are today, what organizations must consider when securing their software supply chain, and how Checkmarx is proactively building new solutions to address this complex and ongoing issue. 

Our mission to secure the entire software supply chain

For the past 10 years, security professionals have been trained that before you release code, all high vulnerabilities need to be identified and fixed. But over the last few years especially, the world has changed. According to GitHub, open source is now the foundation of more than 90% of the world’s software.  Organizations are now facing a shifting attack landscape, along with an overwhelming number of vulnerabilities. The attack landscape is moving from the application itself, to where there are new vulnerabilities and weaknesses – in the process surrounding your development, and the components you use to build your application. 

What software supply chain security really means

Traditionally, supply chain security was to a way to gain visibility and mitigate 3rd-party code vulnerabilities through SCA. But as time went on and as new attack types emerged. In a 2021 executive order, software bill of materials, or SBOMs, are required for all software sold to the US federal government. The mandate underscores the importance of an accurate list of all open-source software ingredients found in a software-based product. The market quickly realized that the scope of software supply chain attacks, and how we prevent these attacks, go way beyond SBOMs and malicious packages.  

Supply chain security is defined as a specific aspect of application security that focuses on protecting the software development process and the components used in that process. Software supply chain security is not a single solution; it is a discipline. 

Supporting the SLSA Framework

The Supply-chain Levels for Software Artifacts (SLSA) framework, developed in collaboration with the OpenSSF and Google, addresses the growing concern of software supply chain security, offering a structured approach to assessing and improving the integrity of software components used in development. 

SLSA introduces key concepts like artifacts, provenance, digests, immutable references, and build integrity, that provide a systematic way for the software industry to secure the development lifecycle and promote consistent security standards.

Understanding that the full scope of SCS is beyond a single tool, Checkmarx has implemented a broader strategy to cover things outside of your typical application security posture management, in full alignment with the SLSA framework. 

How Checkmarx is helping you secure your software supply chain

Today, Checkmarx is providing expert guidance and proven solutions to manage open-source risk, along with new and exciting solutions to start protecting your entire supply chain today. 

In the last few years, one of the biggest emerging threats have been malicious packages – notably different from vulnerable packages. In the SLSA framework, malicious packages are a form of dependency attack where attackers inject or contribute malicious code into open-source projects that your developers download and build into your applications. Once downloaded, the attacker’s malicious code is running within your applications, with whatever unknown intent the package carries. 

Checkmarx SCA, introduced in 2021,  was a major step in helping organizations identify and start reporting on their open-source vulnerabilities. We were the first vendor to include malicious package detection inside our SCA solution. Since then, our research team has inspected over 7.6 million open-source packages for all kinds of threats, finding 200,000+ malicious packages. We make that threat intelligence available to you, either in our SCA product, where findings are in the portal or directly in developers’ IDE, or through an API-based threat intelligence feed. 

Checkmarx SCA enables automated SBOM generation, and Checkmarx Container Security, which works with Checkmarx SCA, identifies vulnerabilities in open-source packages included in container images. Together with our partners at Sysdig, we recently announced runtime insights, so organizations can get the full picture of pre-production and deployment, gaining visibility into which container images are in-use and prioritize the ones that pose the most risk.

We realized customers need support in prioritization, especially with all these newly discovered vulnerabilities, so we released Exploitable Path. It’s a unique feature that allows our customers to prioritize vulnerabilities in open-source libraries.  

When you look at the SLSA framework, we also have always led the way in terms of identifying Infrastructure-as-Code (IaC) misconfigurations. We are the driving force behind the most downloaded open-source tool in this area – Keep Infrastructure as Code Secure, or KICS for short.

All of these are important tools in managing open-source risk, but we are not stopping there. 

Since GenAI  is becoming a popular resource for developers to generate code, a variety of new SCS attacks have recently emerged, such as: 

• AI hallucinations: These are false data points or patterns that AI models might “perceive” due to adversarial inputs or misinterpretations, which can be exploited by malicious actors.
• Prompt injections: Threat actors can manipulate AI models by introducing or “injecting” specially crafted prompts, tricking the system into undesired behaviors or outputs.
• AI secret leakage: There’s a potential risk of AI models inadvertently revealing confidential information they were trained on, offering a goldmine for cybercriminals.

In August, Checkmarx introduced the industry’s first plugin to detect and prevent attacks against ChatGPT-generated code. The plugin enables developers to easily scan their ChatGPT-generated code for vulnerabilities within the ChatGPT interface, receive instant feedback on potential vulnerabilities or validation of open-source packages, and employ protection against malicious open-source packages. 

Now, we’re leading the way again, and broaden the definition of software supply chain security, beyond just malicious packages, to every component in, and every tool used to build your applications. As part of the Checkmarx One 3.0 launch, we’re taking it  one step further, introducing two new capabilities –Secrets Detection and Project Scorecard.

Prevent secrets from leaking on external tools with Secrets Detection  

Secrets, such as passwords, API keys, cryptographic keys, and other confidential data, are a frequent target of a distributed supply-chain attack.  

Secrets can easily be mistakenly shared on external tools like slack, confluence, twitch, and documentation pages.

Secret detection isn’t new – we have one of the most popular open-source tools for secret detection. 2MS from Checkmarx has over 2 million downloads, and anyone can get started today by detecting secrets such as login credentials, API keys, SSH keys and more hidden in code, content systems, chat applications and more. 

If you are a Checkmarx One user, Secret Detection is now available directly in the Checkmarx One platform.  

Tackle the most vulnerable projects first with Project Scorecard 

One of the latest additions to the Checkmarx Supply Chain Security portfolio is Project Scorecard, which enables organizations to check their own projects quickly and see the most vulnerable or at-risk projects, allowing enterprises to prioritize which to tackle first.

Project Scorecard leverages the format from a popular tool, the OSSF Scorecard, which assesses open-source projects for security risks through a series of automated checks. 

These checks cover different parts of the software supply chain including source code, build, and dependencies, and assigns each check a score of 1-10. An auto-generated “security score” helps users as they decide the trust, risk, and security posture for their specific application. 

While an important tool in combating the uptick of open-source software attacks, open-source projects are only a portion of the projects in your application. Checking the process and components of owned projects is an important element in securing the total software supply chain.  

With Project Scorecard, users can auto-generate a security score for their own projects based on a series of checks, including: 

• Binary Artifacts – Is the project free of checked-in binaries? 
  • Branch Protection – Does the project use branch protection? 
  • CI Tests – Does the project run tests in CI, e.g., GitHub Actions, Prow? 
  • Code review – Does the project practice code review before code is merged? 
  • Dangerous workflow – Does the project avoid dangerous coding patterns? 
  • Vulnerabilities – Does the project have unfixed vulnerabilities? 

By utilizing the Project Scorecard, as part of the Checkmarx Supply Chain module, we allow enterprises to quickly see the most vulnerable or at-risk projects, and ultimately help prioritize which to tackle first. 

Taking the next step to secure your software supply chain  

It’s important to take steps to secure your software supply chain today; detecting supply chain attacks in code packages, securing your developer’s evolving workstations supports rapid development while reducing risk. 

Current Checkmarx One or Checkmarx SCA customers will have access to all these tools within the platform. 

If you’re not already a Checkmarx One customer, you can start securing your software supply chain today with too many secrets (2MS), available as an open-source project on GitHub.

We’re incredibly excited to announce these new features to help you secure your software supply chain, but we’re only getting started. The work of securing the software supply chain is never done, as bad actors identify innovative new ways to capitalize on gaps in process and components, so stay tuned for more exciting announcements. 

If you’d like to learn more register now to join us for our technical deep dive webinar on Nov 6th, “Secure your software supply chain”.

Making matters worse, while many API Security solutions may tout that they are “shifting left,” there’s a fundamental gap in their testing methodology, creating an opportunity for threat actors to capitalize on your zombie and shadow APIs. 

Many solutions today can’t identify zombie and shadow APIs, since they’re only scanning live traffic. 

Considering the rise of API Security attacks, it’s more important now than ever before to test during the API development process, as well as before they are pushed to production.  

What are zombie and shadow APIs

No matter how sophisticated a development team may be, undocumented APIs are likely hiding in your organization. Documented APIs are those APIs that development teams have provided the AppSec team with API documentation files, like RAML files, Swagger files, or OpenAPI files. These files describe what an API is, what it looks like, where it lives, and what parameters it has. 

Existing API security solutions like DAST, WAFs, and API gateways can only protect what they know. They must be configured per API to protect that API. What that means is that if the AppSec team doesn’t have the API documentation, or, if that documentation is incorrect, AppSec can’t configure the WAFs or gateways to protect those APIs. 

Shadow APIs are created under the radar—typically for a small use case, or they are created and deployed outside of an organization’s official API governance, visibility, and security controls. Shadow APIs may not have the proper authentication and access gates in place, or they may expose sensitive data improperly. Most importantly, with that lack of documentation, existing API security solutions can’t protect them.  

Zombie APIs arise in a slightly different way. For example, an organization could have a frontline API that was in production for some time, like an old version of a login API. When it’s time to update the application and login service, you have a new version of the same API. When developers create an updated API, they often don’t decommission the old version right away. Instead, the new API runs alongside the older API to ensure that the user experience isn’t impacted if any issues arise.

Eventually, you might forget about version one, since traffic is no longer going to the old login page, and your development team’s focus is now on version two. The problem is that the API is still lurking behind the scenes, leaving you potentially vulnerable to an attack. Since shadow and zombie APIs aren’t properly documented, a WAF doesn’t know about it, and can’t protect it accordingly. 

The problem with API discovery solutions today

There are new types of API threat protection solutions that have entered the market in recent years. Many API discovery solutions or threat protection solutions integrate with your WAFs, gateways, load balancers, and other network devices to analyze the traffic logs. By analyzing the traffic, they find all the API endpoints that that traffic is going to – they discover the APIs by looking at your live traffic going through these devices. 

It certainly helps, but it doesn’t solve the problem. 

The furthest left these solutions go is API documentation, but that doesn’t protect against undocumented APIs, or even worse, the APIs that are documented incorrectly. Many organizations don’t have a single choke point in application infrastructure that can integrate with, and see, all API traffic. 

So, while other solutions may say that they “shift left” in the SDLC, it’s often not the case.  WAFs say they shift left, but in reality, they only sit in front of production APIs. API threat protection solutions say they shift left, but they’re analyzing traffic to those live production APIs, on the far-right side of the SDLC. Instead, a shift left and integrate right approach is needed… 

Shift left, and integrate right, to protect your APIs

Instead of relying on API traffic, Checkmarx believes a shift left and integrate right approach for API Security is best, securing APIs as they’re being developed, as they’re being pushed into production, and helping you identify and protect against shadow and zombie APIs. 

Starting with the source code

Checkmarx API Security focuses on starting with the source code, understanding that there are likely gaps in API documentation. Checkmarx SAST identifies vulnerabilities, while Checkmarx API Security discovers the APIs in code, and builds a Global API inventory, along with API documentation risk by automatically scanning source code at check-in or code merge. 

For API-first organizations, that means you can easily validate API documentation in design, then compare against implementation to identify discrepancies. Checkmarx API Security of course scans API documentation (i.e., Swagger, RAML) files before your developers start coding to ensure that security is added into the design phase. This helps enforce API design best practices and assesses your overall API design for misconfigurations, identifying risks in path definitions, authentication schema, and transport encryption. For code-first organizations, it means you can discover and inventory every API in source code without requiring proper documentation, first. 

Change log to better leverage existing APIs

APIs allow developers to create modular software components that can be reused across different projects. Instead of rewriting the same code multiple times, developers can use an API to achieve the desired functionality. The problem we often see, is that without the full history or context behind a given API, developers may fear leveraging the API and modifying it for their needs. As a result, developers will often create a new API from scratch. 

The change log provides a full history of every change made to a given API, giving developers the full confidence they need to leverage existing APIs. Beyond developers having the full history at their fingertips, AppSec managers can also leverage the change log to quickly identify, for example, if a given public-facing API has a recent change adding sensitive data. As a result, developers and AppSec teams can better align with the true spirit of APIs; their agility, and ability to be repurposed, by finally having all the context they need to confidently leverage and repurpose existing APIs.   

A better developer experience

Checkmarx API Security integrates and automates scans in the tools developers use, enabling developers to remediate vulnerabilities in their favorite tools allowing them to kick off an application scan at any time using the CLI, and not wait until after code check-in to focus on security. It also provides guided remediation to help resolve vulnerabilities faster by prioritizing, recommending mitigation points, and surfacing just-in-time learning for discovered vulnerabilities. 

Single view to manage all API risk

Providing AppSec managers a full view of all APIs, Checkmarx aggregates and correlates the results from all the different scan engines for a more accurate picture of your application security. The Global API Inventory is where all of your APIs from all of the different projects are viewable in one place. This view helps AppSec teams focus on the most critical issues by prioritizing API vulnerabilities based on their real impact and risk.  

What’s new in Checkmarx 3.0

Brand new this fall, we now have pre-production testing of all the APIs in DAST.  This new capability complements our original shift-left approach with one that now also integrates right.The integration of DAST and API Security provides a more comprehensive view of API security risks, enabling customers to identify and remediate risks earlier in the development lifecycle. It works by DAST executing the API to evaluate the security risk. With a complete and up-to-date inventory, you can figure out the risk of the API before it goes into production.

Also new in the Checkmarx One 3.0 launch, Checkmarx API Security now automatically scans API documentation files, saving you time and effort vs. scanning API documentation files manually. This works when a user defines a rule in the project or globally using regex on the destination of the swagger files, so that every API security scan will scan the same swaggers without having to upload them manually. For example, a user could write a regex that scans all swagger files according to the *swagger.json regex. When someone adds a new swagger that matches this regex and pushes the code, the engine will run API Security with the new swagger.

You can’t secure what you can’t see

Checkmarx API Security provides complete API visibility, providing the most accurate and up-to-date view of the entire API attack surface, eliminating the problem of shadow and zombie APIs.  

A true shift-left approach means we discover APIs at the source, to find every API that’s written in the code, to identify and fix problems earlier and faster in the SDLC. 

Prioritized remediation helps developers and AppSec teams focus on the most critical issues. 

The total result is a holistic view of application security risk, scanning the entire application with a single solution, and removing the need for additional API-specific tools. 

While scanning source code and identifying shadow and zombie APIs is a big leap for API Security, we’re just getting started. Stay tuned for an upcoming announcement to correlate source code with runtime to better prioritize risk and improve accuracy.  If you’d like to learn more about Checkmarx API Security, register for the upcoming webinar  “Shift Everywhere to Secure APIs” on October 30^th, where you’ll hear from Checkmarx API Security Product Manager Liad Levy.