How to Use AI-Assisted Code Remediation: Perforce Klocwork [DEMO]

Overview: Accelerate Code Fixes with AI-Assisted Code Remediation in Perforce Klocwork 

Move from detection to resolution faster with AI-assisted remediation, eliminating manual fix discovery. 

Watch as Perforce expert Steve Howard demonstrates how to: 

• Generate AI-powered fixes directly from Klocwork findings: See how developers can trigger AI-assisted remediation from within the IDE, using Klocworks’s diagnostic context to produce accurate fixes aligned with coding standards. 
• Leverage deep analysis context for more accurate remediation: Watch how Klocwork’s inter-procedural analysis and MCP server provide rich context, enabling AI to deliver more precise, explanation-backed fix recommendations. 
• Automatically validate fixes with reanalysis: Learn how Klocwork re-runs analysis after every AI-generated change to confirm the issue is resolved, and that no new issues are introduced. 
• Maintain full developer control with review and approval workflows: See how developers review, refine, document, and approve AI-generated fixes before committing, ensuring compliance and control in safety-critical environments. 

Experience the power of AI-Assisted Code Remediation for Yourself 

See how your team can move from find → fix → verify faster — with the accuracy and confidence needed for safety-critical code — in a Klocwork free trial. 

 Request Free Trial 

Full Transcript  

Quick demonstration of how we can use the new before Static Analysis AI auto-remediation tools within Visual Studio Code IDE to quickly find and fix, alongside the static analysis, of course, the issues that we're getting reported. 

So, we're starting with this project, OpenSSL, for which we've created the central server-side project and performed at least one baseline analysis with the various rules and configuration turned on that we wish to follow. So, in this case, we're using the CWE standards for reporting of security vulnerabilities. 

Within Visual Studio Code, we've installed the Before Static Analysis plugin, this time configured to use Klocwork as the engine, and also the GitHub Copilot Chat plug-in as well for Visual Studio Code. Those two are going to work together. 

The project settings, obviously, we've used setup for Klocwork in this case, as I say, and we've connected it to the OpenSSL Central project, and so that when we perform our local edits within the code, in this case, this file X509name.C, you can see that automatically the analysis runs, and we generate the list of findings. 

In this case, we have three findings. 

So, these are two critical null pointer dereferences, which are CWE 476 and 690 reference issues. There's two of those. And then there is also the one for an unused local variable, sort of a lesser issue, and this is CWE 563. 

Now, in the case of the last issue that we see reported here, you'll note that it's got a local sighting in terms of where it's come from, and that means that this is something that I've introduced, having made changes to my code recently following what I checked out, whereas the first two here both have system flags, meaning that those were created and known about already in our baseline analysis. So, they were already present, essentially, in the master branch, whereas this one was a local issue. 

So, for the local issue, I can now click on that, and, obviously, you're having understood what the problem is. Maybe I can choose to fix this using the Klocwork tools. So, by Klocwork tools, what we're actually doing here is taking the analysis data from the Klocwork analysis results, and we're passing that out to GitHub Copilot to interact with the AI LLMs that it's using, and, in this case, we're using Claude, although we do have, depending on your account options here, we have options for other engines, such as GPT, or, if you're in a commercial account, then even local analysis—sorry—local AI models as well. 

So, as a result of that, it's gone off and worked out what the problem is and provided us with a suggested fix. 

And then, at that point, we can choose to either keep that change or undo it. And, in this case, we may wish to keep it. 

It's a simple fix, and the explanation for the fix, and what was provided by the AI, is also detailed in the chat window here. 

So, that was essentially a full running commentary of what was done, what we found in terms of how to fix it, and then the suggested fix, which I've accepted. As soon as we've accepted the fix, the analysis is automatically triggered. So, you can see here we've actually configured this to run incremental analysis on every single change to the file. And, as a result of that, of course, we now get the updated results. And I'm pleased to say that the suggested fix was indeed a valid fix for that particular issue. It was a very simple case. 

Again, we can apply the same here for also our sort of backlog issues. Now, in this case, we may or may not wish to show those to the developer, on the basis that we do want them actually changing code that's in the master branch already, or would we prefer to focus them on just fixing the new issues that they introduce as they create new code and change code? 

Because that's obviously a lot safer, to make sure that that's never entered into the code stream, of course. 

But, for anything where we're actually looking at the backlog issues, we may want to be a little bit more cautious and not have them just simply go and change that. So, we can choose to hide or show these, what we call backlog issues, alongside the new issues. 

In this case, we're going to also apply the same approach here and actually ask for a fix again from the AI. Off it goes to go and follow that same process. 

And this is a bit more of a complex issue, and so the data that we have, the data point here, sorry, which is assigned a pointer from the call out to this X509name entry, getData function method, is going to potentially be null, and if it's null, then you can see the highlighted issues on two lines, 41 and 42, that would then potentially dereference that null pointer, and that's fundamentally the issue. 

Rather conveniently, the suggested fix, in this case, actually resolves both of those issues by checking whether data is null. And, if not a valid pointer, it will return one at that point, meaning the rest of the function is skipped. Now, you may or may not wish to do something like that in terms of the resolution. 

But, in this case as well, we're happy with the fix, let's say, so we're gonna keep that. But we would also like to add a little commentary as to why this bit of code has been changed. Because, bear in mind, this is something that's changing from the master branch, so it's not part of our developer's actual development here. I'm pleased to show that, of course, the issue has now been reported as fixed by the analysis being updated. So, that one's great as well. We'll keep that. 

But we will just ask here, GitHub Copilot, to please add a comment to explain this fix in the code and attach also the CWE reference for the original defect. So, we can just simply ask Copilot to go away and make a further change to our code, in this case, because obviously we have changed something which, as I say, is in the master branch already. It's something unrelated to the new code we were developing, perhaps. 

So, we really should explain this change, and that's what it's given us here. So, you can see we've now also got a second change to the code as a result of this, and it's telling us, okay, this CWE that we had originally, CWE 476, has been resolved by adding the following code on lines 46 and 47, just to protect the use of an uninitialized pointer on the following lines.