But there is a tradeoff.

The faster code is created, the faster security issues can enter the codebase too.

AI-generated code can introduce vulnerable packages, insecure coding patterns, exposed secrets, and risky infrastructure configurations just as easily as it can generate productivity gains. And when teams are moving at AI speed, traditional AppSec processes often cannot keep up.

Security reviews that happen during a pull request, in CI/CD, or after code is merged come too late. By then, the developer has already moved on, forgotten the original context behind the code, or shipped the issue downstream.

That is why security has to move earlier in the process, closer to the moment code is created.

Traditional AppSec Was Not Built for AI-Native Development

Most AppSec programs still rely on a familiar model: developers write code, scanners run later, and security teams review the results afterward.

That model already struggled to keep up with modern development, and in an AI-native workflow, it breaks completely.

When developers are using AI to generate code, update dependencies, create infrastructure-as-code (IaC) templates, or accelerate repetitive tasks, the volume of changes increases dramatically. Teams are no longer reviewing a handful of manual changes at a time. They are reviewing far more generated code, and often with less scrutiny because the pace of work is so much faster.

That creates a growing execution gap between how fast code is produced and how fast security can respond.

Bringing Security Directly Into Windsurf

Developer Assist brings AppSec directly into Windsurf, so developers can identify and fix issues while they are still coding.

Instead of waiting for a pull request review or a pipeline scan, developers get immediate feedback directly in the editor. Vulnerabilities, risky dependencies, secrets, infrastructure misconfigurations, and malicious packages can all be surfaced in real time as code is written or modified.

That matters even more in an AI-native editor like Windsurf, where code is not just being typed manually. Files may be generated, updated, or rewritten by AI assistants in seconds.

Developer Assist helps ensure those changes are reviewed with security in mind before they move downstream.

What Developer Assist Catches in Real Time

• Vulnerabilities in custom code
• Risky open source dependencies
• Exposed secrets and credentials
• IaC misconfigurations
• Malicious or suspicious packages
• Insecure AI-generated code patterns

Scans happen automatically as developers work, including when files are edited, saved, opened, or updated by AI. That means developers can catch issues while they are still in the context of writing the code, when fixes are faster, easier, and far less disruptive.

This is especially important for open source packages and AI-generated code. It’s easy for an AI assistant to recommend an outdated package version, insecure configuration, or code snippet that looks correct but in reality introduces risk.

Developer Assist gives developers a way to validate those changes before they make it into the codebase.

Security Without Breaking Developer Flow

The biggest challenge with traditional AppSec is not just that it happens too late. It is that it interrupts developers at the worst possible moment.

No developer wants to stop what they are doing, switch tools, wait for a scanner to finish, or debug a security finding days after they wrote the code.

The best security tools are the ones developers barely notice because they fit naturally into the workflow.

That is what makes Developer Assist a strong fit for Windsurf. Developers can stay in the editor, keep moving quickly, and still get the security guidance they need when it matters most.

See Developer Assist in Windsurf

Checkmarx is partnering with Windsurf through Agentic Labs to give developers hands-on experience with Developer Assist in an AI-native coding environment.

These labs allow developers to explore how real-time vulnerability detection, dependency analysis, secret detection, and inline remediation work directly inside Windsurf. Instead of reading about secure AI-assisted development, developers can experience what it looks like in practice.

As AI-native development becomes more common, security teams will need to shift from scan-and-fix-later to secure-as-you-generate.

Because in an editor like Windsurf, code is moving too fast for anything else.

In tools like Cursor, developers are increasingly prompting, reviewing, editing, and accepting work produced by AI. Entire functions, files, fixes, and dependency updates can be generated in seconds.

That shift is changing the role of the developer.

Instead just authoring code, developers are becoming reviewers and orchestrators of AI-generated work. They are evaluating suggestions, validating changes across multiple files, deciding which fixes to accept, and making sure generated code is ready for production.

That can dramatically improve productivity. But it also introduces a new challenge: developers are now responsible for reviewing far more code than they ever actually wrote.

Cursor Is Changing How Developers Build

One of the biggest advantages of Cursor is its ability to take on larger coding tasks.

Developers can ask Cursor to generate new functions, refactor existing code, update dependencies, make changes across multiple files, or suggest fixes for bugs. Instead of spending time on repetitive implementation work, developers can focus more on direction, validation, and refinement.

That changes the development workflow in an important way.

Developers are no longer reviewing only a handful of lines they wrote manually. At any time they may be reviewing dozens or hundreds of lines of AI-generated code, often spanning multiple files, packages, or services.

When that happens, security issues can spread just as quickly as productivity gains.

AI Can Introduce Risk at Machine Speed

AI-generated code is not automatically secure.

An AI assistant can recommend outdated dependencies, insecure coding patterns, weak authentication logic, vulnerable package versions, exposed secrets, or infrastructure configurations that create unnecessary risk.

And because Cursor can generate changes so quickly, those issues can make their way into the codebase faster than traditional AppSec tools can catch them.

Security reviews that happen in pull requests, CI/CD pipelines, or after code is merged are often too late. By then, the developer has already accepted the code, moved on to another task, or lost the context behind why the change was made.

The faster AI-generated code moves, the more important it becomes to validate that code before it is accepted.

Bringing Security Into the Review Process

Developer Assist brings security directly into Cursor so developers can validate AI-generated code while they are still reviewing it.

Instead of waiting for a later-stage scan, developers can get immediate feedback directly in the editor. Vulnerabilities, risky dependencies, secrets, infrastructure issues, and malicious packages can all be surfaced before the generated code is accepted or committed.

That is especially important in Cursor, where developers are often reviewing larger, more complex sets of generated changes.

Developer Assist helps developers move from simply accepting AI-generated output to actively validating it.

What Developer Assist Helps Cursor Users Validate

• AI-generated code for insecure patterns
• Multi-file changes that may introduce risk
• Dependency upgrades and package recommendations
• Exposed secrets and credentials
• Infrastructure-as-code (IaC) misconfigurations
• Malicious or suspicious packages
• Suggested remediations before they are accepted

Scans happen automatically while developers work, including when files are opened, edited, saved, or updated by AI.

That means developers can review security findings while they are still in the context of evaluating the generated code, instead of discovering issues much later in a pull request or pipeline scan.

Trust, But Verify

AI coding tools like Cursor are changing how software gets built.

They allow developers to move faster, automate repetitive work, and focus more on problem solving than implementation. But they also introduce a new responsibility: developers need to validate the code they did not write themselves. The gap between generation and validation is where risk accumulates, and it grows as speed increases.

The future of development is not about choosing between speed and security. Cursor can generate code in seconds, but speed means nothing if the code introduces vulnerabilities before it reaches production.

Developer Assist gives developers a way to close that gap, so AI-generated code secure, compliant, and ready to ship.

New IDEs don’t change how developers think about security, they change how fast security problems appear. 

Kiro, an agentic development environment built by Amazon Web Services (AWS), is gaining attention because it fits neatly into modern development workflows: fast feedback, AI-assisted coding, and a familiar Visual Studio Code–based experience.

But as with any productivity-focused Integrated Development Environment (IDE), increased speed also means increased risk. Code is written faster, dependencies are introduced more often, and vulnerabilities surface earlier in the lifecycle. 

That puts pressure on security tooling to meet developers where they already work. 

For developers and software builders  the requirement is straightforward: 
security controls must function inside the IDE, not downstream in CI/CD pipelines or external dashboards. Developers should be able to identify issues as code is written, understand the impact, and move forward without context switching. 

The good news is that adopting a new IDE like Kiro does not require rethinking your security tooling from scratch. If an IDE is built on VS Code foundations, existing IDE-native security workflows can carry over with minimal friction. 

This post walks through how to use Checkmarx inside Kiro today, covering installation, configuration, and running real security scans directly in the IDE without relying on proprietary APIs, special agent commands, or experimental integrations. 

Installing the Checkmarx Developer Assist in Kiro 

Checkmarx Developer Assist is delivered to developers through the Checkmarx IDE extension, which can be installed directly in Kiro. 

From within the Kiro IDE, open the Extensions view and search for Checkmarx. Install the official Checkmarx extension, which enables Checkmarx Developer Assist capabilities inside the editor. The same extension is used across supported VS Code based IDEs, allowing developers to bring Assist into their existing workflows without additional setup. 

After installation, the extension prompts you to authenticate and connect to your Checkmarx environment. Once authenticated, Checkmarx Developer Assist becomes active for the open workspace, using your existing tenant configuration and security policies. 

No Kiro specific configuration is required. Assist operates within the IDE, analyzing the code and dependencies in your active project and providing security insight directly where development happens. 

With the extension installed and connected, Checkmarx Developer Assist is ready to support secure development inside Kiro. 

 
Getting Checkmarx Developer Assist Ready in Your Workspace 

Once the Checkmarx extension is installed, getting started with Checkmarx Developer Assist in Kiro is intentionally simple. 

After signing in to your Checkmarx One environment, the extension uses the open workspace in Kiro as the context for analysis. There is no need for developers to manually create or configure projects inside the IDE. Checkmarx Developer Assist analyzes the source code and dependencies present in the workspace and applies your organization’s existing security policies automatically. 

Security rules, thresholds, and policy logic are inherited from Checkmarx One, so developers do not need to manage or customize security settings locally. This keeps the experience lightweight while ensuring that the guidance provided by Assist aligns with how your organization defines risk. 

With authentication complete and a workspace open, Checkmarx Developer Assist is ready to provide security insight as developers write and review code in Kiro. 

Using Checkmarx Developer Assist During Development in Kiro 

With Checkmarx Developer Assist active in the workspace, security analysis becomes part of the normal development flow inside Kiro. 

As developers write or review code, Assist analyzes the source files and dependencies in the open workspace and surfaces security findings directly in the IDE. These insights are presented with context, including severity and location, helping developers understand potential risk without leaving their editor. 

Rather than acting as a separate security step, Assist supports developers as they work, highlighting issues early and reducing the likelihood of discovering problems later in the pipeline. Because the analysis is based on the current state of the workspace, the feedback developers receive is directly tied to the code they are editing. 

Checkmarx Developer Assist focuses on visibility and understanding. It helps developers identify insecure patterns and vulnerable dependencies as they appear, using the same policies and rules defined in Checkmarx One. This ensures that the guidance provided in Kiro reflects organizational standards without requiring developers to manage security settings themselves. 

By bringing security insight directly into the IDE, Checkmarx Developer Assist enables teams to move quickly while maintaining confidence in the code they are producing. 

Reviewing Assist Insights in Checkmarx One 

While Checkmarx Developer Assist delivers security insight directly in Kiro, the same findings are also available in Checkmarx One for broader visibility and coordination. 

As analysis runs against the code in the developer workspace, results are reflected in Checkmarx One, where AppSec and engineering teams can review findings across projects and contributors. This provides a centralized view of security risk without requiring developers to change how they work in the IDE. 

Checkmarx One preserves the context surfaced by Assist, including severity and vulnerability details, making it easier for teams to track patterns, understand risk trends, and align remediation efforts across the organization. Developers see issues as they write code, while security teams gain visibility into what is happening across repositories and teams. 

This shared visibility helps bridge the gap between development and security. Developers receive timely feedback inside Kiro, and AppSec teams retain the governance and reporting capabilities they need, all grounded in the same policies and analysis logic. 

By combining IDE level insight with platform level visibility, Checkmarx Developer Assist supports secure development without fragmenting workflows or forcing teams into separate tools. 

Bringing Security Into AI-Assisted Development with Kiro 

AI-assisted IDEs like Kiro are changing how developers write code. Faster iteration, smarter suggestions, and tighter feedback loops are becoming the norm. As development accelerates, security needs to keep pace without adding friction or slowing teams down. 

Checkmarx Developer Assist brings security insight directly into that workflow. By operating inside the IDE, Assist helps developers understand risk as code is written, using the same policies and standards defined across the organization. There is no need to wait for pipeline feedback or switch tools to gain visibility. 

With Checkmarx Developer Assist running in Kiro, teams can adopt new development experiences with confidence, knowing that security remains part of the process from the first line of code. 

The rise of AI coding assistants has made this even more common. Developers are pulling in more packages than ever, often generated automatically by the assistant, and the pace of change is speeding up. AI accelerates delivery, but it also accelerates the number of risky dependencies entering the pipeline. Teams end up with more vulnerable or malicious packages, more refactoring work, and a growing pressure to remediate issues at a scale that traditional workflows cannot keep up with.

This is exactly why Checkmarx One Developer Assist exists. It brings verified security intelligence into the IDE so developers can fix issues quickly and safely, even as AI increases the volume of code they produce.

Inside Developer Assist, Safe Refactor focuses on one of the most painful and time consuming tasks in this new reality: upgrading vulnerable or malicious packages without breaking the codebase. It takes the error prone work of package refactoring and turns it into a guided, predictable workflow inside the IDE. Developers stay in flow, security gets clean upgrades, and no one loses hours chasing breaking changes.

Why Package Upgrades Are So Painful

Upgrading a vulnerable or malicious package should be simple. The reality is never simple.

A single upgrade requires:

• Reading release notes and migration guides.
• Figuring out which APIs changed or were deprecated.
• Searching the entire repo for functions and imports that rely on the old version.
• Updating them manually.
• Rebuilding until everything stops breaking.

This is not a one-click task. It is research plus refactoring plus debugging. That is why teams often defer upgrades even when they know the package is a risk.

Safe Refactor removes that hesitation. It makes the entire process fast, predictable, and safe to apply.

What Safe Refactor Actually Does

Safe Refactor focuses on one job: helping developers upgrade problematic packages without breaking their code.

Here’s how it works:

It identifies packages that need attention

Developer Assist flags packages that are vulnerable or malicious. The developer does not need to hunt them down.

It recommends the correct safe version

Instead of guessing or relying on AI to pick something, Safe Refactor uses verified Checkmarx data to suggest the right version to upgrade to.

It analyzes the codebase to find every impacted file

This is where the time savings become real. Safe Refactor looks across the project and finds all the places where the old version is used and where the code will break if left untouched.

It shows the developer exactly what needs to be updated

Safe Refactor presents a clear list of files and precisely what code needs to change for the upgrade to succeed. No wandering through the repo, no digging through docs.

The developer reviews and applies the changes in the IDE

Everything happens in one place. Every change is visible, explainable, and easy to accept.

This is not a blind AI rewrite. It is a guided, transparent update that gives developers confidence the refactor is complete.

Why This Saves Hours of Work

If you have ever upgraded a package that touches twenty files, you already know the math.

Without Safe Refactor:

• One to three hours of research.
• Another hour or two updating code in each affected file.
• More time debugging when the build breaks or tests fail.
• Even more time chasing down edge cases you missed the first time.

With Safe Refactor:

• Identify the package.
• Accept the upgrade.
• Review the changes.
• Move on.

This is the kind of time savings that developers feel immediately. Instead of blocking real work, the upgrade becomes part of the normal flow.

Why AppSec and Leadership Care

Security teams get safer upgrades because developers are no longer avoiding them. Every change is rooted in verified Checkmarx intelligence, and every update is easy to apply and understand. CISOs see reduced risk from vulnerable packages and fewer hours wasted on preventable rework. It is a cleaner, faster path to a healthier dependency landscape.

The Takeaway

Safe Refactor is not trying to refactor your entire codebase. It is focused on a very real, very common workflow that burns time and introduces risk. By helping developers upgrade packages safely and completely, it turns a disruptive task into a quick, trusted step in the development process.

If you want to see how much time your team can save, we can package this into a demo that shows the before and after experience using a real world vulnerable library example, reach out and schedule a demo today! Or, if you prefer, come to one of our bi-weekly webinars where you can see Checkmarx One Assist in action, and ask questions!

A consistent pattern and a new challenge are starting to emerge among development teams leveraging AI to generate code. Teams celebrate a bump in efficiency and then watch PR queues swell, security backlogs grow, and delivery slow.  

The bottleneck is not keystrokes; it’s our ability to secure the code as fast as it’s being generated. If code quality and risk posture are decided after the commit, you pay a “rework tax” that multiplies as the volume of code rises. 

This tax is why pre-commit agentic AI security is crucial: When AI is in the loop, helping write “live” code,  Agentic AppSec AI doesn’t wait to comment on a pull request after a scan finishes, but rather, ‘sits’ together with the developer while code is being written to prevent mistakes and ship secure changes on the first try. 

Why post-commit breaks down at AI speed 

Post-commit assistance still has value, but it is reactive by design. DORA reports slower throughput and weaker stability as GenAI use climbs. 

More unchecked code enters the pipeline without early prevention, which multiplies PR loops, review delays, and rework. 

 When issues show up in PRs or build results, you trigger a long chain of handoffs. The developer has already context-switched to the next task. Now they must jump back into the previous code, recreate the problem, debate fix approaches in comments, run again, and wait for another review. Multiply that by hundreds of generated code snippets, upgrades, and merges. 

Four problems show up fast: 

1. Rework tax: Every hop in the loop adds time. A simple fix can take hours or days once you include triage and re-review. 

2. Context loss: The best moment to fix a bug is right when the developer wrote it. Minutes later is worse. Days later ancient history for the developer, and requires more resources and attention.  

3. Flooded PRs: Comment storms and scan noise delay merges and sap energy. Engineers start to treat security as a second inbox. 

4. Debt by default: If the team is judged by throughput, issues get deferred. Debt rises quietly until it is loud and costly. 

What is pre-commit agentic security? 

Think of an AI teammate that prevents risk before code ever leaves the developer’s workstation. It runs where the developer works, understands the file and project context, and gives fixes that are specific to the code that is being edited. 

It also enforces a light gate at commit time, so obviously insecure changes do not enter the pipeline. 

That is the job description for our Developer Assist agent inside Checkmarx One Assist. Here is how it maps to real developer moments: 

• Real-time protection while typing. The agent detects vulnerabilities early and offers targeted fixes that fit the code style and framework in use. The fix cycle shrinks from weeks to minutes because the developer never needs to leave the IDE. 

• Find and fix breaking changes during upgrades. The Agent automates dependency impact analysis, highlights API differences between versions, and suggests the code updates required. Upgrades move from risky all-hands moments to routine work. 

• Smarter SCA in the IDE. The agent surfaces license and risk information for any chosen package, flags malicious or suspect options, and recommends safer alternatives before you import. 

• Secrets detection and remediation. The agent catches leaked credentials as you write and guides safe rotation and handling. 

• Context-aware fix suggestions. Not generic snippets, but fixes that align to the specific sink, source, and data flow in your codebase. 

• Pre-commit protection. Lightweight checks at commit time stop insecure changes at the source so fewer issues hit CI. 

Pre-commit Assistant Translated into Numbers: Time and Efficiency  

Here is a simple back-of-the-napkin example. Say your team upgrades a core package from v3 to v4. It is referenced in 12 files with about 30 call sites. Here is what that looks like three different ways. 

Manual path 

• Find every usage with code search, confirm each reference, and map the blast radius. About 45 minutes. 

• Read release notes and migration guides, compare old and new APIs, and sketch the refactor plan. About 60 minutes. 

• Update imports, fix each call si te, re-run tests, and chase compile errors. About 150 minutes. 

• Open a PR, wait on CI, address comments, and re-run. About 90 minutes. 
  Total time about 5.75 hours. At 100 dollars per hour that is roughly 575 dollars for one upgrade. 

Post-commit assistant path 

• Commit the upgrade, let your build pipeline flag breakages, then accept suggested fixes and iterate in the PR. 

• You still pay the triage and re-review tax, but some edits go faster. 
  Total time about 3.5 hours. About 350 dollars. 

Pre-commit with Developer Assist and Safe Refactor 

• Select the target version in the IDE. Safe Refactor analyzes the codebase, lists breaking changes across the 12 files, and proposes concrete edits at each call site. 

• Apply edits, compile locally, run tests, and commit once. 
  Total time about 1.5 hours. About 150 dollars. 

Numbers will vary by repo and library, but the pattern is consistent. Prevention compresses loops. Short loops keep throughput and stability. Long loops add risk, noise, and cost. 

Where post-commit still matters 

Pre-commit should be the first line of defense, not the only line. You still want pipeline and PR scans as a fail-safe and as proof that standards were met. You still need portfolio-level visibility so AppSec and engineering leaders can decide what matters most across applications, not just inside one IDE session. 

In our world, this is where ASPM comes in. It aggregates and correlates findings, applies organizational risk logic, and feeds those priorities back to developers so the pre-commit agent is guided by what the business cares about. 

A quick tour of developer workflows that benefit immediately 

• Writing new code: Real-time detection and context-aware fixes keep issues from ever leaving the editor. 

• Adding or upgrading a dependency: SCA capabilities in the IDE allow developers to evaluate the package choice in the moment and helps avoid license and security landmines. If you do upgrade, the Safe Refactor feature analyzes blast radius, highlights breaking API changes, and proposes code edits that compile. 

• Handling credentials: Catch and remove 170+ types of exposed credentials (API keys, tokens, SSH keys, encryption keys, etc.) before commit. 

• Hitting commit: The agent enforces a light, fast gate that prevents known bad changes. Your pipelines see less noise. PRs merge faster. 

What to look for if you are a CISO or head of engineering 

If you are comparing agentic approaches, use a checklist that prioritizes prevention and adoption. 

• Does the agent work pre-commit in the IDE, not only after scans finish? 

• Are fixes context aware and specific to the codebase, not generic snippets? 

• Does it bring ASPM priorities into the IDE, so developers fix what matters most? 

• Can it automate package upgrade remediation by analyzing dependency impact? and suggesting code changes 

• What is the false positive rate and how quickly can developers accept or dismiss results? 

• Does pre-commit protection reduce PR noise and shorten time to merge in real projects? 

What changes when prevention becomes the default 

Teams that move security left in a meaningful way report quieter PRs, faster merges, and fewer fire drills. Developers keep the efficiency they were promised by AI because they spend less time reworking code that already landed. AppSec shifts from traffic cop to coach. Leaders get cleaner telemetry and a risk posture that improves as output scales. 

That is the outcome we are aiming for with Checkmarx One Assist and the Developer Assist agent. Keep the second line of defense strong but win the battle where it starts. At the keyboard. Before the commit. 

Learn more about Developer Assist

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.