This could be the perfect ending to a cybersecurity film, but it’s even better—it’s the exciting reality of ZAP’s core team joining Checkmarx to deliver the best in Dynamic Application Security Testing (DAST)! ZAP project leaders Simon Bennetts, Ricardo Pereira, and Rick Mitchell are joining Checkmarx to help develop the next generation of our enterprise-grade DAST solution. They will continue to support the open-source project and grow the ZAP community. This transition allows them to focus fully on advancing DAST.

What is DAST?

For those unfamiliar, DAST is a technique used to test web applications by detecting vulnerabilities while they are running. Unlike static analysis, DAST doesn’t require access to source code, making it essential in identifying security risks that emerge in live environments. This widely adopted tool helps uncover vulnerabilities that may remain hidden during static analysis.

What is ZAP?

ZAP (Zed Attack Proxy) is the world’s most widely used web application scanner, having been downloaded millions of times. This popularity is one of the reasons Checkmarx initially integrated it into its DAST solution.

Simon Bennets, Ricardo Pereira and Rick Mitchell are ZAP’s project leaders and have been contributing, guiding and reviewing any contribution to the open source project.

What does it mean for Checkmarx customers?

For users of Checkmarx DAST, our commercial offering, this collaboration means they will now benefit from the unmatched expertise of the ZAP core team. Checkmarx will continue to empower organizations to secure their applications from code to cloud. The ZAP team’s deep knowledge, gained from contributing to nearly every aspect of ZAP, adds tremendous value to Checkmarx’s already robust offering.

Checkmarx will gain unique insights and focus, enabling us to drive faster enhancements to Checkmarx DAST. The Checkmarx research team, working alongside ZAP’s leadership, will improve the accuracy of the engine, reducing false positives, and helping customers focus only on relevant findings. The team will also enhance key features like scan rules, automation, and authentication.

For customers already using our DAST solution, the usage will remain seamless. The new features developed with the ZAP core team will be integrated into our existing solution and available “out of the box” in Checkmarx DAST.

A unified view of vulnerabilities

By combining Static Application Security Testing (SAST), DAST, and API security testing into a single platform, Checkmarx provides a unified view of vulnerabilities, allowing for comprehensive analysis. This holistic approach to vulnerability management, which includes both static and dynamic analysis, along with API security, ensures better prioritization and more efficient remediation.

Integrating DAST in the Checkmarx One platform helps secure applications by detecting vulnerabilities in live environments and throughout the SDLC. Correlation between the different results adds a layer of  prioritization, making remediation more efficient. It’s a key part of our vision for managing application risk, spanning from development to runtime insights (code-to-cloud).

What does it mean for ZAP and the open source community?

Moving forward, ZAP will be known as “ZAP by Checkmarx” and will continue as a separate, community-driven project under the Apache v2 license. As Simon noted in his blog, “This is by far the biggest investment any one company has made in ZAP and ensures that ZAP will continue to thrive.”

For the open-source community, this collaboration is great news. Checkmarx  has a proven track record with open-source projects such as KICS, 2MS, CxFlow, Vorpal, ImageX and many others, contributing significantly to the community.

Personally, as the previous Product Manager for our open-source secret detection solution (2MS) and through my work with our research team identifying malicious packages, I’ve always felt a close connection to the open source community. I’m happy to have another opportunity to contribute.

The ZAP community will benefit from our company’s expertise and resources, enabling the development of key features requested by the community. ZAP by Checkmarx will continue to be a community-driven, open-source DAST solution, while our enhanced Checkmarx DAST will build upon and improve on our existing solution.

This marks a significant step in expanding our dynamic application security testing capabilities and strengths our commitment to Checkmarx DAST, with the knowledge and support of the ZAP project leaders.

If you’d like to learn more, feel free to contact us.

Intro

In an era where misinformation and identity theft pose significant threats, the security of survey platforms is crucial, particularly during pivotal global election cycles. The Checkmarx research team recently identified two Cross-site scripting (XSS) vulnerabilities on Gallup’s website. XSS is a vulnerability that might enable attackers to bypass the same origin policy, impersonate users (and perform actions on their behalf), and access their data. This vulnerability can potentially allow attackers to gain full control over an application’s functionality and data, especially if the affected user has privileged access.

The types of XSS vulnerabilities found are:

• Reflected XSS – type of cross-site scripting that occurs when an application unsafely includes data from an HTTP request directly in its response.

• DOM-based XSS – this type of cross-site scripting occurs when client-side JavaScript unsafely processes data from an untrusted source, often writing it back to the DOM, as was the case in Gallup’s systems.

This blog examines these vulnerabilities, their potential impact, and the broader implications for digital security in the field of public opinion research.

Reflected Cross Scripting – gx.gallup.com

CVSS Score: 6.5 Medium CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Description

The /kiosk.gx endpoint did not properly sanitize or encode the query string ALIAS parameter value before including it on the page.

Figure 1: Exploiting the issue to display the document’s domain

Figure 1 shows the execution of JavaScript code included in the vulnerable parameter. This endpoint doesn’t require the victim to be authenticated.

If left unaddressed and exploited by malicious actors, these vulnerabilities could lead to the execution of arbitrary code in the victims’ navigation session context. This could result in unauthorized actions being performed on their behalf. It’s important to note that this endpoint is commonly used to access Gallup surveys, which may make users more susceptible to exploitation. This could lead to unauthorized access to personally identifiable information (PII), manipulation of user preferences, and other detrimental actions.

In this proof of concept (PoC) video, we show how this vulnerability could be exploited to manipulate the victim’s shopping cart. The victim innocently visits a specially crafted URL to participate in a “work-life balance” survey. Unbeknownst to them, the malicious URL triggers the browser to load a JavaScript file from a remote location controlled by the attacker. This script leverages a JSONP endpoint (https://buy.gallup.com/store/gallup/SessionToken) to retrieve and exfiltrate Digital River API access tokens to a server controlled by the attacker. With these tokens, the attacker gains access to the victim’s PII and can add a new product to the shopping cart, illustrating the potential risks of this vulnerability.

The JSONP endpoint plays an important role in this attack scenario. The gallup-session-token cookie is required to get the access tokens. Nevertheless, it is not accessible to JavaScript (httpOnly), and the browser refuses to include it in cross-site requests. SameSite attribute is set to None, and the server has Access-Control-Allow-Origin set to *.Exploit methodology

The following URL would pop a dialog box like the one shown in Figure 1:

https://gx.gallup[.]com/kiosk.gx?ALIAS=%22);alert(document.domain)//&TYPE=q12

DOM-Based Cross-Site Scripting – my.gallup.com

CVSS Score: 5.4 Medium CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Description

The /_Portal/ApplicationAsync endpoint did not properly sanitize nor encode query string searchTerm parameter value before including it into the page.

Figure 2: Exploiting the issue to display the document’s domain

Figure 2 shows the execution of JavaScript code included in the vulnerable parameter. The vulnerable endpoint requires authentication.

Malicious actors might exploit this issue to execute arbitrary code in the victims’ navigation session context and perform actions on their behalf.

In the above PoC video, this issue is exploited to take over a victim’s account (account takeover). The victim visits a specially crafted URL that includes a payload to pull a JavaScript file from a remote location controlled by the attacker. That script is responsible for 1) rendering my.gallup.com inside an iframe, 2) automating the required workflow to change the victim’s email, and 3) pinging the attacker’s remote server with the new email address associated with the victim’s account. From here, all the attacker needs to do is recover the account password, and set a new one.

Exploit methodology

The following URL, after logging in, will pop dialog box like the one shown in Figure 2:

https://my.gallup[.]com/_Portal/ApplicationAsync?gssClientId=dduOMXW7d71AS3U _2BFMiMY8EiRX0WxJVn_2FHNUkaHb4okdayR4Pz6_2BetryXCC5aLQ2&dashbo ardWidgetId=AQICAHgcAgLcqG_2BjL48JMeAx11Kd4K4khEMoYzbmIpOoa9wRw QHwBn_2B2jOYRmEThy2bBjhebAAAAeDB2BgkqhkiG9w0BBwagaTBnAgEAMGI GCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMwOTTYIEr2OY_2B8xLiAgEQ gDW9L_2B9lkGghNQqrG7K_2BQ36lyXdiSZZEDX3JBsqfhN3ST3LlZ_2FgMDzhuz_2BrcRxStCcFpuhu5Zw_3D_3D&eCode=LEARN#/search?searchTerm=%3Cimg%20src=x%20onerror=alert(document.domain)%3E

After validation to avoid these vulnerabilities, we recommended:

• Properly encode data according to the output context it will be included before appending it to the response markup (HTML) or page DOM – Document Object Model.
• Consider adding/adjusting the Content Security Policy (CSP) to restrict locations where the browser can fetch and execute scripts.

References

• CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site
• A03:2021 – Injection, OWASP Top 10 2021
• Cross Site Scripting Prevention Cheat Sheet, OWASP Cheat Sheet Series
• Testing for Reflected Cross Site Scripting, OWASP Web Security Testing Guide
• Content Security Policy (CSP), Mozilla Developer Network Scripting’)

Timeline

• 23-June-2024 Full findings reported to Gallup’s incident response team
• 25-June-2024 Gallup confirmed receiving the report
• 11-July-2024 vulnerabilities were reviewed and found to be fixed.
  
  

In March 2023, the White House published the National Cybersecurity Strategy. In July, the White House followed that up with the National Cybersecurity Strategy Implementation Plan.

As we wrote in a blog post earlier this year:

“With the introduction of the National Cybersecurity Strategy earlier this year, the US Government has started to use its influence and buying power to alter the behavior of all software producers. The US Government is the world’s largest consumer of IT products and services in dollars. It appears they will be using that buying power to add additional cybersecurity requirements for all software purchased. Companies will be faced with the options of changing their behavior or walking away from selling to the federal government.

The National Cybersecurity Strategy makes the case that there must be a shift of the burden for cybersecurity from the consumers of software to the producers of software. One of the requirements they are implementing is that all software vendors attest that they developed their software in accordance with NIST 800-218, the Secure Software Development Framework, or SSDF.”

Companies providing software to government customers need to certify that their development process meets certain standards known as the Secure Software Development Framework (SSDF).

The Secure Software Development Framework (SSDF) is composed of “fundamental, sound, and secure recommended practices based on established secure software development practice documents” and organized into four groups:

• Prepare the Organization (PO): Ensure that people, processes, and technology are prepared to perform secure software development at the organization level.
• Protect the Software (PS): Protect all components of the software from tampering and unauthorized access.
• Produce Well-Secured Software (PW): Produce well-secured software with minimal security vulnerabilities in its releases.
• Respond to Vulnerabilities (RV): Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar ones in the future.

What CEOs Need to Do Right Now

1. Understand the Requirements: Familiarize yourself with NIST 800-218 and the SSDF.
2. Designate a Responsible Leader: Assign a high-level leader, such as the CISO, to oversee SSDF compliance.
3. Conduct an Internal Audit: Ensure your software development lifecycle (SDLC) aligns with SSDF practices.
4. Leverage Tools: Use tools like Checkmarx One and Codebashing to meet SSDF standards.
5. Sign the Attestation Form: Verify the security practices and sign the Secure Software Development Attestation Form.

Taking these steps will help secure your software development processes and maintain your business relationship with the federal government.

What NIST 800-218 Requires

NIST 800-218 is not strictly a compliance requirement but rather a set of best practices. The Secure Software Development Framework (SSDF) Is a core set of high-level secure software development practices that can be integrated into each SDLC implementation.

So, it isn’t a compliance framework—it’s a set of principles that should be followed. This is an important distinction since Checkmarx supports the implementation of many of those practices.

Why Now?

On March 11th, the Cybersecurity and Infrastructure Security Agency (CISA) released a critical form—the Secure Software Development Attestation Form. This stems from government mandates (OMB memorandums M-22-18 and M-23-16) aiming to improve software security for government use.

The form requires a signature from a high-level leader within your software company, potentially the CEO. The deadline is coming up fast!

Submitting false information is a crime. Simply checking “yes” to all questions without truly adhering to secure development is a risky strategy.

This is the opportunity for CEOs to verify with their teams if they are managing their SDLC securely and maturing their security practices.

The Attestation Form has a short list of basic software security requirements which are a small subset of the NIST Secure Software Development Framework (SSDF). It has examples for each task to simplify the requirements, which are sometimes less straightforward for CEOs.

CEOs and CISOs should audit their requirements, replacing the examples in the Attestation Form with their own material.

This form signifies a growing focus on secure software development within the government sector. Understanding these requirements and taking them seriously is crucial for companies doing business with the American federal government.

According to the press release from CISA, this is “a critical step towards ensuring software producers who work with Government provide securely developed products” and “furthers the President’s National Cybersecurity Strategy, which made clear that the “most capable and best-positioned actors in cyberspace must be better stewards of the digital ecosystem.””

How Checkmarx One Can Help Achieve Compliance

Checkmarx products and services help organizations meet the requirements of the SSDF.

Checkmarx’s Assessment and Advisory services, in particular the APMA framework, can help identify gaps and create an actionable workplan to improve your AppSec program.

We have mapped where specific requirements of NIST 800-218 align with the APMA framework, so you can be confident that your AppSec program meets the SSDF standards. The practices are implemented through a combination of tools such as Checkmarx One, in conjunction with the relevant processes and procedures being put into place.

We previously laid out which of these requirements are supported by Checkmarx.

Checkmarx One supports many of these regulations with a comprehensive AppSec platform that provides differentiated users and roles, full records and audits of activities, and comprehensive security controls across the entire SDLC—from SAST and SCA to API Security, Container Security, Infrastructure as Code, and more.

Here are just a few examples of how Checkmarx helps organizations meet SSDF’s requirements:

• PO.2.2: Role-based training for personnel with responsibilities that contribute to secure development. Checkmarx Codebashing directly supports PO.2.2 by offering developers constantly updated secure code training.
• PS.3.2: Collecting, safeguarding, maintenance, and sharing of data for all components in each software release, such as in a software bill of materials (SBOM). Checkmarx supports this with Checkmarx SBOM, designed to meet these compliance challenges head-on and provide an automated and efficient solution for generating and maintaining SBOMs.
• PW.5: Source code adherence to secure coding practices. Checkmarx SAST can automatically scan your application’s source code, identify vulnerabilities, and even automatically remediate it at a click of a button. Developers can get real-time feedback on their code to ensure it meets secure coding practices.

If you have any questions or would like to have a deeper discussion on implementation in support of SSDF, please contact us.

CNAPPs are often presented as the go-to tool for cloud security, promising comprehensive protection for cloud-native applications. However, these platforms have built-in limitations that may leave organizations exposed to security risks and breaches – a fact that is not always emphasized. 

1. Designed for the cloud…only 

CNAPPs are tailored for cloud-native environments, often overlooking security needs in traditional on-premises environments. A cloud-only approach presents hurdles for organizations operating in both cloud and on-premises environments, due to lack of comprehensive coverage across diverse development landscapes. Without security measures for hybrid environments, organizations must either contend with heightened security risks and compliance issues or manage separate tools lacking integrated and correlated security insights. 

2. The focus is on runtime 

CNAPPs prioritize addressing threats and risks during the runtime phase. While they excel at identifying runtime threats, vulnerabilities introduced during the coding and testing phases of the Software Development Life Cycle (SDLC) may go unnoticed. This delayed increases the likelihood of security issues going unaddressed until they become critical problems in production, putting the business at risk for security breaches and data compromises. 

3. Infrastructure vs. Application Security 

By prioritizing the protection of cloud infrastructure, CNAPPs fall short by offering limited capabilities for identifying and mitigating vulnerabilities within the application code itself, making them an incomplete solution. Securing infrastructure is essential, but it must be complemented by robust application code security for comprehensive protection. 

4. Limited code-level visibility 

CNAPPs face a significant challenge detecting vulnerabilities at the code level due to their limited visibility into application code. Unlike more comprehensive AppSec solutions that can cover hybrid environments, CNAPPs often rely on third-party tools for code analysis. These tools are often not in-depth and can result in challenges when identifying and managing vulnerabilities. As a result, security teams have a tough time spotting risks in the application code or tying vulnerabilities in production to their location in code for developers to remediate. 

5. Incomplete API security coverage 

CNAPPs lack comprehensive coverage for API vulnerabilities. API security is vital for securing modern applications relying on APIs for communication. CNAPPs often develop their own API security features in-house, but these are seen as ad hoc at best. Due to their focus on runtime, they frequently miss crucial aspects of securing APIs.  

6. No developer focus 

Developers were never part of the CNAPP plan. Their emphasis on infrastructure security has little developer involvement, which means CNAPP vendors are not focused on developers – their needs or integrating with their workflows and tooling.  CNAPPs often fail to provide developer-friendly capabilities, impacting the developer experience and collaboration in software development.  

7. Inadequate IDE integration 

Developers rely on IDEs for coding. However, if these IDEs are not integrated with, and able to, bring insights directly into the developer working environment, developers will not receive real-time feedback on security concerns, making it difficult to fix them quickly. Since CNAPPS integrate in at the runtime stage, there is a major delay in vulnerability discovery. This increases the chance of undiscovered vulnerabilities until runtime, potentially exposing applications to malicious actors. 

8. Limited remediation guidance 

Without clear guidance, prioritizing and resolving security risks becomes difficult. CNAPPs offer insufficient guidance for remedying identified vulnerabilities in code. Any remediation advice provided tends to lack specificity from a developer’s perspective, making it hard for them to enact effective fixes.  

9. Detection vs Prevention 

CNAPPs primarily focus on monitoring and responding to security risks, rather than proactively preventing. This limitation hampers organization’s ability to effectively prevent application-specific vulnerabilities and security challenges from going live. Without the ability to enforce preventive security policies and stop the build process at the coding stage, CNAPPs struggle to provide comprehensive protection against vulnerabilities in code making it to production.   

By integrating Checkmarx with a CNAPP solution, organizations can overcome the built-in limitations of CNAPPs. We offer advanced security tools to support the entire development life cycle for hybrid cloud environment. This integration enhances developer workflows by delivering real-time security feedback during coding, enabling early detection and remediation of vulnerabilities. With our proactive security approach, vulnerabilities are addressed throughout the software development lifecycle, correlating runtime insights from CNAPPs for better risk prioritization and reducing alert noise by up to 90%. By enforcing customizable security policies and mitigating API-related threats, we bridge the gap between cloud infrastructure security and application security, providing a comprehensive solution for securing cloud-native applications. 

• The critical vulnerability CVE-2024-34359 has been discovered by retr0reg in the “llama_cpp_python” Python package.
• This vulnerability allows attackers to execute arbitrary code from the misuse of the Jinja2 template engine.
• Over 6k AI models om HuggingFace using llama_cpp_python and Jinja2 are vulnerable.
• A fix has been issued in v0.2.72
• This vulnerability underscores the importance of security in AI systems and software supply chain.

Imagine downloading a seemingly harmless AI model from a trusted platform like Hugging Face, only to discover that it has opened a backdoor for attackers to control your system. This is the potential risk posed by CVE-2024-34359. This critical vulnerability affects the popular llama_cpp_python package, which is used for integrating AI models with Python. If exploited, it could allow attackers to execute arbitrary code on your system, compromising data and operations. Over 6,000 models on Hugging Face were potentially vulnerable, highlighting the broad and severe impact this could have on businesses, developers, and users alike. This vulnerability underscores the fact that AI platforms and developers have yet to fully catch up to the challenges of supply chain security.

Understanding Jinja2 and llama_cpp_python

Jinja2: This library is a popular Python tool for template rendering, primarily used for generating HTML. Its ability to execute dynamic content makes it powerful but can pose a significant security risk if not correctly configured to restrict unsafe operations.

`llama_cpp_python`: This package integrates Python’s ease of use with C++’s performance, making it ideal for complex AI models handling large data volumes. However, its use of Jinja2 for processing model metadata without enabling necessary security safeguards exposes it to template injection attacks.

[image: jinja and llama]

What is CVE-2024-34359?

CVE-2024-34359 is a critical vulnerability stemming from the misuse of the Jinja2 template engine within the `llama_cpp_python` package. This package, designed to enhance computational efficiency by integrating Python with C++, is used in AI applications. The core issue arises from processing template data without proper security measures such as sandboxing, which Jinja2 supports but was not implemented in this instance. This oversight allows attackers to inject malicious templates that execute arbitrary code on the host system.

The Implications of an SSTI Vulnerability

The exploitation of this vulnerability can lead to unauthorized actions by attackers, including data theft, system compromise, and disruption of operations. Given the critical role of AI systems in processing sensitive and extensive datasets, the impact of such vulnerabilities can be widespread, affecting everything from individual privacy to organizational operational integrity.

The Risk Landscape in AI and Supply Chain Security

This vulnerability underscores a critical concern: the security of AI systems is deeply intertwined with the security of their supply chains. Dependencies on third-party libraries and frameworks can introduce vulnerabilities that compromise entire systems. The key risks include:

• Extended Attack Surface: Integrations across systems mean that a vulnerability in one component can affect connected systems.
• Data Sensitivity: AI systems often handle particularly sensitive data, making breaches severely impactful.
• Third-party Risk: Dependency on external libraries or frameworks can introduce unexpected vulnerabilities if these components are not securely managed.

A Growing Concern

With over 6,000 models on the HuggingFace platform using `gguf` format with templates—thus potentially susceptible to similar vulnerabilities—the breadth of the risk is substantial. This highlights the necessity for increased vigilance and enhanced security measures across all platforms hosting or distributing AI models.

Mitigation

The vulnerability identified has been addressed in version 0.2.72 of the llama-cpp-python package, which includes a fix enhancing sandboxing and input validation measures. Organizations are advised to update to this latest version promptly to secure their systems.

Conclusion

The discovery of CVE-2024-34359 serves as a stark reminder of the vulnerabilities that can arise at the confluence of AI and supply chain security. It highlights the need for vigilant security practices throughout the lifecycle of AI systems and their components. As AI technology becomes more embedded in critical applications, ensuring these systems are built and maintained with a security-first approach is vital to safeguard against potential threats that could undermine the technology’s benefits.

But what if you could get reliable guidance and a suggested fix for those vulnerabilities? You can now – using Generative AI.  

We previously announced AI Guided Remediation for IaC, and now we’re happy to now introduce AI Security Champion with auto-remediation for SAST. 

This  solution goes beyond mere identification by offering actionable fixes alongside each finding.

These recommendations, tailored to the specific vulnerability, allow developers to:

• Deepen their understanding of the issue’s nature and impact.
• Navigate the remediation process with confidence, saving time and resources.
• Make the fix as quickly and easily as possible.

Introducing AI Security Champion for SAST

AI Security Champion for SAST uses the power of GenAI to propose code to fix each vulnerability.

The AI Security Champion goes beyond simply identifying vulnerabilities. While guided remediation provides AI-generated assistance, suggestions, explanations, and other guidance in human-readable language, auto-remediation provides the actual code that can be used directly within the development workflow. 

This empowers developers to confidently navigate the remediation process, saving valuable time and resources, enabling developers to review and then automatically implement the fix. It’s as simple as copy and paste (and soon, we will also add the ability to automatically implement it at the touch of a button)!

This integration signifies a significant advancement in the realm of application security testing. By harnessing the power of artificial intelligence, we are excited to offer a streamlined and efficient approach to vulnerability remediation, enabling organizations to achieve their security goals without compromising development velocity.

How It Works

AI Security Champion with auto-remediation is an integral part of the Checkmarx One platform, which makes it easy to adopt and implement. The new AI Security Champion function meets developers where they are – within the integrated development environments (IDE) that developers are already using. 

Initial Setup

To set it up, select the “AI Security Champion” plugin from the plugins menu within Checkmarx One.

Then connect to ChatGPT. 

Make AI Your Newest Security Champion

Once it’s set up, this is where to start moving forward. Everything takes place in the IDE as Checkmarx is fully integrated. Developers stay in their natural environment. 

After set up, select a vulnerability from Checkmarx One results.

Select the “AI Security Champion” tab from the Checkmarx One results and click Start Remediation.

AI Security Champion shows the developer the following:

1. Confidence score –  On a scale of 0 (low)-100 (high), indicates the degree of confidence of how exploitable the vulnerability is in the context of your code.
2. Explanation – An OpenAI-generated description of the vulnerability. 
3. Proposed remediation –A customized code snippet, generated by OpenAI, that can be used to remediate the vulnerability in your code. 
4. “Ask a question” – A further prompt to ask AI Security Champion about the vulnerability or proposed code.

How to Get Started

Checkmarx SAST users on Checkmarx One can get started straight away. Simply enable AI Security Champion.

Taking advantage of the capabilities presented by AI are just another reason to use Checkmarx One. Existing CxSAST users can work with their customer success manager to migrate to Checkmarx One.

Existing customers can contact their account manager to learn more. Everyone else, contact Checkmarx today.  

The pressure to deliver quickly and efficiently is pervasive. Speed often comes at the expense of security. To address this, the “shift left” philosophy has gained traction among development teams. This emphasizes the importance of integrating security measures early in the development lifecycle, rather than as an afterthought. We have also spoken about the need for security to be integrated throughout the entire SDLC –  allowing you to secure your applications from the very first line of code, to runtime and deployment in the cloud.

The rationale behind this strategy is straightforward: identifying and resolving security issues during the initial stages of development is significantly more cost-effective and less risky than making changes after deployment. By addressing security considerations earlier in the development process teams can prevent future headaches. This can also help get software to production faster, as it’s easier to fix in the development cycle.

The best way to secure applications is to bake security into the code from the start. Developers play a critical role in securing the software by adopting security best practices. However, that’s easier said than done. There is a gap between theoretical best practices and truly embedding security into development.

The security gap in software development

Software developers aren’t security experts. According to the Forrester report, “Show, Don’t Tell, Your Developers How To Write Secure Code,” none of the top 50 undergraduate computer science programs in the United States require a secure coding or secure application design class.

Bridging the skills gap and fostering security awareness among developers is critical. This is why Checkmarx offers security training such as Codebashing. However, training doesn’t equal  instant changes. As a result, developers are relying on AI-generated coding due to the speed it provides and the mistaken belief that AI-generated code is somehow more secure. 

The new frontier of AI-generated code

Traditional software development workflows are being reshaped with the proliferation of AI-generated code. GenAI tools, such as GitHub Copilot or Amazon CodeWhisper, fundamentally alter the coding process by providing suggestions, autocompleting code, and automating repetitive tasks. This shift represents a significant advancement in the field, with AI-driven assistants seamlessly integrated into coding workflows, enhancing human capabilities, and expediting development cycles.

AI-generated code is a double-edged sword. While it offers the potential of productivity boosts and tapping into collective knowledge, there are potential risks.  Research into the increasing prevalence of AI-generated code and its potential to redefine software engineering practices, has also identified the potential of reduced code quality and security risks.

Often ignored by developers, AI tools can generate insecure code. According to research, “Participants with access to an AI assistant were also more likely to believe they wrote secure code, suggesting that such tools may lead users to be overconfident about security flaws in their code.”

Introducing real-time scanning in the IDE

Real-time scanning in the IDE offers a security best practice for developers that complements Checkmarx SAST. It analyzes and provides real-time insights for:

• Human-generated code as it’s being written by software developers
• AI-generated code using tools such as GitHub Copilot

This is a plugin for Visual Studio Code, and it scans in milliseconds, providing instant responsiveness in the IDE and even can scan source code repositories. In internal tests, we scanned over 1 million lines of code in under 10 seconds – much faster than other “developer-friendly” solutions. 

Security best practices

Real-time scanning in the IDE provides the first step to ensure that source code follows security best practices. It’s not intended to replace thorough testing by your application security team or that undertaken by Checkmarx SAST, but rather to ensure that code – particularly AI-generated code – follows secure coding best practices. It does not test an entire application, but rather code snippets – a specific line of code plus the nearby lines of code. The scope of the analysis is a relevant short piece of code. By providing a few lines of code, the scanner provides a security review and points to potential issues that a developer should consider. 

Unlike a complete SAST scan, it doesn’t find attack vectors such as SQL injection. It works by analyzing the adjoining lines of code so, unlike complete SAST solutions, it is not fully application aware.  It looks at the “micro” — a few lines of code and provides suggestions for remediating the code snippets. 

 This makes it easy for developers to fix their code as they are writing it. 

This is a win-win for security. By giving developers the opportunity to implement security best practices, it produces less and more accurate SAST results for the AppSec team.

How to get it

Real time insights are available in a freemium model. Users can get real time insights within a command line interface (CLI) executable available for free.

Additional features and real-time in-IDE scanning are available for customers with the “AI Security“ package. If you’re an existing customer, contact your account manager for more details. Not yet a customer?  Get a free demo.

There are two key challenges around AI that make this an essential area for AppSec platforms to address. 

The first is that AI is disrupting the developer workflow that AppSec teams have worked hard to integrate with. We know that AI Large Language Models (LLMs) do not understand secure coding practices, however developers are increasingly relying on them to maximize their coding output. This results in a flood of insecure code being directed at already resource constrained AppSec teams. AppSec teams are finding themselves in an increasingly untenable situation, especially since many developers don’t understand or practice security coding, nor prioritize AppSec. 

This brings us to the second challenge: AppSec is already hard! AppSec teams are generally under-resourced; they rely on working with cross-functional teams with often opposing incentives; and they face an increasingly complex code environment. Analysis and prioritization of vulnerabilities has already been difficult, and they have long given up on the idea of getting their vulnerability count to zero. 

AppSec teams require cutting edge tools to keep pace – and Checkmarx delivers. Last year Checkmarx pioneered a strategic approach to help AppSec organizations get the most out of AI.  Today, we are excited to announce the second wave of AI Security features from Checkmarx!  

Checkmarx’ AI Vision

Checkmarx has a clear vision for the future of AI in supporting AppSec, and sees 3 key opportunities where we can provide meaningful assistance to our customers:

1. The Developer Workflow: Developers are, and will continue to use, AI for code generation. By plugging AppSec tools directly into the AI tools, Checkmarx aims to help secure code from the first line written, while also securing the software supply chain.
2. Accelerate AppSec Teams: AppSec teams want to use GenAI as a productivity tool in the same way that everyone else does. Checkmarx is creating tools and platform features to simplify AppSec management and increase daily efficiency for AppSec teams .
3. AI-Based Attacks: The use of new technology always brings new risks, and AI tools are no different. Checkmarx will help customers protect against risks targeting AI tools in the new developer workflow.
   

Building towards this vision, Checkmarx has already supplied developers with core features to help support the changing developer workflow experience that AI has created.  These include our AI Security Champion for Infrastructure as Code (IaC), our AI Query Builder for reducing false positives, and our Checkmarx GPT integration that helps developers understand the open source risks of generated code.  

Our newly launched features build on that momentum with more ways that allow developers to embrace AI in a way that is both comfortable to their workflow, and is mindful of the business’s responsibility to their (and their customers) data. 

Auto Remediation for SAST

Resolving security vulnerabilities is a necessary evil for developers. It is often time consuming and involves significant research and context-switching.  Each vulnerability has its own background that needs to be understood before a meaningful solution can be drawn up and implemented. 

Our new auto remediation for SAST functionality, part of our AI Security Champion plugin, aims to significantly shorten the time and effort needed for developers to remediate vulnerabilities. Now developers can get meaningful recommendations presented to them, directly in their IDE, on how to resolve specific SAST vulnerabilities, making (not just finding but) resolving vulnerabilities much more practical and reasonable. 

Want to learn more? Read about it here.

Checkmarx GPT

Code is code, regardless of if it is written by a developer, or copied and pasted from OSS, or generated by AI.  It all needs to be scanned, and if you want to scan AI generated code successfully then you need to do it in real time.  Checkmarx demonstrated how to do this with our initial Checkmarx GPT integration for ChatGPT, which allowed Checkmarx to analyze the generated code for malicious packages, hallucinations, and potential versioning and licensing challenges.  We have further extended the Checkmarx GPT functionality by including the ability to perform a SAST scan as part of the process.  Now, developers using ChatGPT can leverage a full security check of the generated code in real  time and get remediation advice for specific vulnerabilities.

GitHub Copilot Integration

In the spirit of our Checkmarx GPT plugin, we know that many developers are using Copilot to drive their code generation needs. Many developers have Copilot integrated directly into their IDE, and just as we did with ChatGPT, we knew we needed to provide a real-time scan for Copilot-generated code.  Our VS Code Plugin for Checkmarx now supports real-time IDE scanning for all types of code, including Copilot generated code, which allows developers to get a super fast SAST scan of the code, as it’s being created. 

Read this blog post to get more details.

Prompt Security

Checkmarx cares about your data.  We understand that for many organizations considering leveraging Generative AI, the risk of your data being accidently leaked is a tough to weigh out. Checkmarx is partnering with Prompt Security to help secure all uses of Generative AI in an organization: from tools used by your employees to customer facing applications. Checkmarx and Prompt are working together to help AppSec understand what is being passed to a Large Language Model, and providing ways to sanitize and block unwanted data from being shared. 

AI in Your AppSec Program

It can get overwhelming trying to keep track of all the developments around AI. We are convinced they need to be integrated into your existing AppSec program purposefully, with a defined strategy and plan. So, we incorporated AI into our AppSec Maturity Model  – APMA. When we discuss and assess your AppSec program with you, we will also consider your organization’s AI strategy. We will then work with you to build a way to leverage AI opportunities, while protecting against AI-related risks, using our AppSec AI solutions and best practices.

Learn More

As the adoption of generative AI in software development continues to grow, Checkmarx remains dedicated to guiding organizations through their AppSec journeys. By focusing on enhancing the developer experience, reducing false positives, and addressing the unique threats posed by AI, Checkmarx is paving the way for a more secure digital future. Our investment in advanced solutions reflects our commitment to not just identifying problems but also providing the solutions that empower developers to build safer, more secure software in the age of AI.

We’re at RSA this week and we encourage you to stop by our booth to see and participate in live demos of our most recent announcements, and check out the additional blogs linked within this blog post for more details! 

The US government’s Cybersecurity & Infrastructure Security Agency (CISA) and National Security Agency (NSA) summed up the value of an SBOM in their recent publication “Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption”.

SBOMs provide improved visibility into the pedigree of the software that the customer organization is evaluating, deploying, and/or operating within their environment. This increased visibility into all software is critical for proper supply chain risk management and overall enterprise risk management. SBOM content provided to and consumed by customers informs risk management for customer organizations without impacting sensitive intellectual property interests of software suppliers. Even before the SBOM data is consumed by the customer, the customer benefits from the supplier having the SBOM data and the potential to use it to inform risk decisions. This does not guarantee that the supplier will use this data, but having the data is a necessary first step.

If a supplier does not have visibility into their software supply chains, customers should be cautious of the trust placed on that software and its supply chain. While there may not be any currently known active exploits or vulnerabilities, such a supplier may not be in a position to make any claims or assurances. A supplier that provides an SBOM signals its visibility, and the quality of this visibility, into its supply chains.

The Executive Branch has issued multiple cybersecurity guidance documents over the past couple of years – from the National Cybersecurity Strategy, to different Office of Management and Budget (OMB) Memorandums, and to a variety of agency specific planning documents. One of the common threads throughout nearly all this guidance is that software producers should be held to a higher standard when it comes to producing secure software, and that the SBOM is the key deliverable to ensure that happens.

We can (and I do often) debate the actual value of an SBOM within the broader picture of application security as a measure of risk, but that debate is unlikely to persuade the US Government from mandating SBOMs from software vendors.  SBOM can be a valuable tool for risk reduction but, in itself is insufficient. In my opinion,  it is more important how you use the insight provided by the SBOM to manage risk, than collecting an SBOM itself.

So, what is happening?

Some highlights from what I know as of today:

• The Department of Homeland Security will be mandating SBOMs within all existing and future contracts.
• The Army is formally asking industry on how best it can mandate SBOMs.
• DHS and the Cybersecurity Infrastructure Security Agency (CISA) has started the process of requiring contractors to attest that all software produced was done in accordance with NIST 800-218, which includes SBOMs (sort of).
• The Department of Defense (DoD), General Services Administration (GSA), and National Aeronautics and Space Administration (NASA) has proposed updates to Federal Acquisition Regulation to include mandating the delivery of SBOMs.
• The Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) issued public guidance on how customers of SBOMs can effectively consume SBOMs, and why they should require them from their software vendors.

I suspect this is just the tip of the iceberg given that OMB literally is directing federal agencies to adopt SBOMs through M-22-18. This is no longer a question of if, but rather of when, and how.

I spent 24 years in the Air Force, primarily within the complex DoD acquisition process. I’m going to get out my acquisition crystal ball and forecast how I think this will play out over the next year or so. I think there will be some significant challenges for the US Government to achieve the value they desire from SBOMs, and I will discuss what challenges I think they will have.

All Proposals Will Require SBOMs

We are seeing this trend start already, just search SAM.GOV for SBOM. I expect all Request for Proposals to require the vendor to submit SBOMs. The submission will be mandatory and failure to submit the SBOM is likely to result in being non-compliant and excluded from the award.

The easy contracting approach is to just require the SBOM within the proposal, and the box is checked. I think this approach will be used for a vast majority of acquisitions. I think we will see a subset of the acquisitions that incorporate the SBOM within the technical evaluation process. Once this approach happens, the complications start.

To effectively incorporate the SBOM into the technical evaluation process, the Government is going to be challenged in a) ensuring that the SBOM is comprehensive, b) dealing with what may be false positives, and c) how do you assess it in a protest resistant manner. While this could be a valuable tool in the technical assessment, this will lead to several successful protests before the Government develops protest proof processes to incorporate SBOMs into the technical evaluation.

All Contracts will Require SBOM as a Deliverable

I expect every contract to include an SBOM as a deliverable. I think that this will be the minimum. This doesn’t mean that anyone will look at or use the SBOM for anything. For many, it will be a checkbox to meet agency guidance. Overtime and with software or cybersecurity specific acquisition programs, I think we’ll see the contracts to go beyond just requiring a deliverable.

We see this already in the draft language for the DHS, which requires delivery of an SBOM that certifies that all software delivered to be free from all known vulnerabilities. This is an unrealistic requirement and that opens the discussion on what to do with the vulnerabilities included in the SBOM. Even the DHS understands this, since they continue in their draft language to require the vendor to provide a plan to remediate all the vulnerabilities identified in the SBOM.

As a minimum, I expect all contracts to require an SBOM to be delivered. For software and cybersecurity focused programs I expect:

• Either monthly or quarterly deliveries of an SBOM
• SBOMs being delivered with each software release
• Companies having to provide and maintain a remediation plan – this may be called a Plan of Actions & Milestone (POA&M), a Risk Register, or something new

Security will have Consequences

I see a lot of opportunity to use SBOM’s to influence vendor behavior. I expect that there will be a few attempts at this in the short-term, but we are unlikely to see this broadly adopted until sometime in the future. It will take some time to build up the skill and government resources to do this effectively, and to do so in a manner that a) avoids outright conflict with the vendor, and b) doesn’t drive away the vendors you are interested in from the acquisition to start with.

My experience leads me to two conclusions about incentives: a) the Government is more comfortable doing negative incentives, and b) positive incentives are more effective than negative incentives. So, I’m going to skip the negative incentives and focus on positive incentives.

While Fixed Price Contracts have been all the rage for recent development efforts, I think those days may be numbered. I think SBOMs, and more importantly the vulnerability data can easily be incorporated in both award fee and incentive fee determinations. So, for cost plus contracts, I think the vendor’s profits will get tied to the deliverable of software with objectionably measurable minimum number of vulnerabilities.

My favorite approach here would be the use of a Cost Plus Incentive Fee (CPIF) contract, where the incitive fee is based on the measured security risk posture of the software being delivered. The higher the security posture, the higher the incentive fee is to the contractor. Using third party tools like Checkmarx One, would allow the contractor to know objectively before the software release is submitted to the Government of the measured security posture. The same tooling would be used by the Government to generate the incentive fee. This is important since there needs to be agreement on how the incentive fee will be calculated to be effective, and the contractor must have a good understanding of their score in time to change their behavior. As a cloud native solution, the Government could provide the contractors Checkmarx One accounts as Government Furnished Information/Equipment (GFI/GFE) which can effectively negate the contractor’s argument on how different their internal tooling is compared to the Governments measurements.

I like CPIF because they are supposed to be more objectively measurable and with tools like Checkmarx One, fairly simple and straightforward to implement. This approach can also work with Cost Plus Award Fee (CPAF) contracts as part of the award fee determination process. Award Fees are notoriously subjective, so it may be more of a challenge for a contractor to characterize the return on any investments in improved application security to their profit. Award Fees are a powerful tool for incentives if used properly, and can use objective inputs such as application security risk scores, as well as subjective observations.

Whether the incentive is based on CPIF or CPAF, the reality is that application security will have consequences. Specifically, application security will directly impact the developer’s profit, as it should. The beauty of using a tool like Checkmarx One is that both the developer and the Government will have the same application security picture, and the developer can make an informed decision on the prioritization of application security knowing the potential impact to contract compliance and profitability.

Next Steps

It really doesn’t matter what kind of software you develop; you would be wise to ensure that you have the ability to generate an SBOM. While the US Government is working on mandating SBOMs for software delivered to the Government, the European Union’s draft Cybersecurity Resiliency Act (CRA) is likely to mandate SBOMs for all software sold commercially within the EU. At some point once SBOMs are in place within the US Government, large enterprise customers will be expecting the same. Don’t fight it, figure it out and build out the capability. This includes working with your entire supply chain to ensure you have a complete accountability of the software within your product. But please don’t build SBOMs for SBOM sake. Use SBOMs as a tool to identify and prioritize risks and take action to reduce the risk posture of your product.

Application security is here to stay and SBOMs are an inherent part of application security. I’m excited to be in Checkmarx, where we are leading in the building of tools that help developers meet the upcoming US Government requirements. My passion is to enable innovative companies to sell to the US Government, but you can’t sell if you can’t produce an SBOM. If you’d like to learn more about Checkmarx, and how Checkmarx One can get your company prepared for the upcoming SBOM requirements, please reach out to us. We’d be happy to help you be successful in all thing’s application security, including SBOMs.

We are pleased to announce that we are building on our long-standing partnership and earlier integrations with JetBrains’ flagship, IntelliJ IDEA. This will deliver the full power of the Checkmarx One Application Security Platform into key JetBrains tools. Individual developers and teams will be able to boost their security performance while continuing to deliver applications at speed.

Partnering for Secure Code Productivity 

In 2022, Checkmarx and JetBrains first partnered by bringing Checkmarx SCA capabilities natively into IntelliJ IDEA Ultimate through the Package Checker. Using the pre-installed Packager Checker plugin, five million developers can use IntelliJ IDEA to initiate Checkmarx SCA scans directly from their development environment. This can be done for free, without the need to become a Checkmarx customer, with detailed results showing OSS vulnerabilities as soon as the scan is complete. Frictionless integration, with modern application development workflows, makes it easier to secure applications before they are compiled, instead of waiting for deployment to identify vulnerabilities. 

Building on this initial launch, the Checkmarx SCA plugin is also available for a wide range of JetBrains developer tools including WebStorm, PyCharm, Rider, ReSharper, Qodana, and GoLand.

Building #DevSecTrust 

The next phase of our partnership with JetBrains is now live. Checkmarx customers can now bring the full functionality of the Checkmarx One 3.0 application security platform, including SAST, SCA, and IaC security, to IntelliJ IDEA through the Checkmarx One JetBrains Plugin.  

We know that making security tools available to developers doesn’t automatically lead to more secure code. Fast, secure application development is the goal, but this is hard to achieve if security tools lack intuition and cause friction in developer workflows. To help developers, Checkmarx One doesn’t just provide detailed information on each vulnerability discovered, including remediation recommendations and examples. We also enable the developer to navigate with one click from the identified vulnerability directly to the best fix location in the source code, so no time is wasted.

Focusing on exploitable vulnerabilities is also critical to effective and efficient remediation. That’s why the newest releases of JetBrains’ IntelliJ IDEA, WebStorm, PyCharm, Rider, and ReSharper tools include Checkmarx’s Exploitable Path capabilities for Java, JavaScript, C#, and Python languages. This capability gives developers the ability to see whether there’s a path from the project code into the vulnerable package code through which the vulnerable packages could be exploited. Developer teams can focus on the remediation of actively exploitable vulnerabilities first so their time is spent on the most critical areas. 

Our #DevSecTrust approach can also be seen in reducing the number of irrelevant alerts. Checkmarx starts work before it is integrated into the IDE. It can be finely tuned by AppSec teams to ensure the accuracy of scans and effective prioritization of findings. Noise is reduced before it enters the workflow, so developers can be confident that the vulnerabilities they are being alerted to are genuine and they know what needs to be prioritized for fixing. This ultimately helps CISOs drive strategic initiatives to uplevel application security posture. 

Collaborative Development with Security in Mind

Checkmarx One 3.0 can also be integrated into TeamCity, a powerful CI/CD tool for DevOps teams of any scale, developed by JetBrains. This means organizations can normalize the inclusion of security scanning in team application development projects.

The Checkmarx One TeamCity plugin enables users to trigger SAST, SCA, IaC Security, and API Security scans directly from a TeamCity project. It provides a wrapper around the Checkmarx One CLI Tool which creates a zip archive from a source code repository and uploads it to Checkmarx One for scanning. This plugin provides easy integration with TeamCity while enabling scan customization using the full functionality and flexibility of the Command Line Interface (CLI) tool.

Key features of the TeamCity plugin include:

• Automatically triggering CxSAST, CxSCA, IaC Security, and API Security scans from TeamCity projects.
• Use of CLI arguments to customize scan configuration.
• Automatic updates to the latest plugin version.
• Interface for viewing scan results summary and trends in the TeamCity environment.
• Direct links from within TeamCity to detailed Checkmarx One scan results and reports.
• Generating SBOM reports.

This helps teams enhance software security, governance, and reporting.

A Powerful Partnership

JetBrains and Checkmarx are recognized leaders in their fields, and this long-term partnership unites us in delivering a game-changing developer experience, raising the profile of AppSec without compromising productivity or workflows. This empowers CISOs to elevate code security and deliver more secure apps, faster.

Getting Started

It couldn’t be easier to get started with Checkmarx in JetBrains tools. Our dependency checker plugin is already a native part of all JetBrains IDEs, so developers can access advanced SCA right now.

The Checkmarx One 3.0 plugin can be easily installed by Checkmarx customers into the IntelliJ IDEA development environment from the Checkmarx marketplace. It is also available as an on-premises solution. Similarly, the TeamCity plugin can be installed for customers with a Checkmarx account and is also available on-premises if required.For more information, contact the Checkmarx Team or watch our latest joint webinar today.