Skip to main content

About Veracode Fix

Veracode Fix is an intelligent remediation solution that helps your development teams reduce the time and effort they spend securing their applications. Developers can use Fix to get AI-generated code patches, review the suggested patches, and directly apply them to flaws in their application source, without writing any code.

How Veracode Fix helps developers​

Veracode data shows that organizations are not keeping up with their security debt. Developers lack the training, experience, and tools to find and fix security findings in their code. A 2022 report by Techstrong Research showed that 73% of developers are expected to write secure code, but lack the adequate tools and knowledge.

The amount of time it takes for developers to remediate only half of their open findings in a given codebase continues to grow. Typically, developers must update codebases that have several security findings, and they are responsible for the overall security of any applications they build with these codebases. Their organization might also hold them accountable for addressing the security debt of their applications. Developers must spend time and work through the frustration of finding, researching, and fixing, security findings that they might not have created, in code they might not have written.

Veracode Fix provides contextual suggestions for each finding. Developers can quickly review and apply each suggested fix to their code, which can reduce the time they spend researching and fixing findings in all codebases.

How Veracode Fix works​

Veracode Fix uses a combination of your application source files and the findings from a Static Analysis of your application. It identifies flaws in the source code and suggests fixes you can apply to mitigate the flaws. Fix uses a machine learning (ML) model that continually trains on thousands of samples of vulnerable code with suggested code patches. These patches come from real-world code that contains the appropriate fix for a security issue. Veracode continually curates these patches against its data set of Static Analysis flaws and against flaws in real-world code.

Each time you run Fix, it does the following:

  1. Uploads a copy of your source files and SAST results file to the Veracode Intelligent Remediation Engine.
  2. Uses the ML model to compare the code in your source files to its code samples.
  3. Returns a numbered list of issues, in your IDE or command prompt window, which are the flaws you can fix. Each issue shows the Common Weakness Enumeration (CWE) ID, a brief description of the flaw, and the line of code where the flaw exists.
  4. After you specify the issue you want to fix, Fix matches the patch in the code sample to your code and returns a list of between one and five suggested fixes. If no fixes are available, instead of suggesting fixes that might fix a flaw, Fix returns No fixes found.
  5. After you specify the fix you want to apply, Fix applies the patch by rewriting the code that contains the flaw.
  6. Discards the copy of your source file, so that it is no longer available to Veracode.

After you apply a fix for a routine injection flaw, such as CRLF injection, cross-site scripting (XSS), or SQL injection, Veracode recommends that you test your code before committing it. For other flaw categories, you might need to perform other tasks. For example, if Veracode recommends that you update a hashing algorithm to a version that is more cryptographically secure, such as moving from MD5 to SHA, you must update any instances of hashed data. If the hashed data is part of an interface, you must also update the definition for that interface, including all parties that use that definition.

Best practices​

Consider the following best practices when you use Veracode Fix.

Rebuild and scan after you fix a flaw​

To ensure a flaw is fixed, after each fix you apply, Veracode recommends that you always:

  • Rebuild your application.
  • Run a Static Analysis on the application to generate new scan results.
  • Re-run Fix on the application.

You can apply multiple suggested fixes to your application without rebuilding and rescanning it between fixes. Although, if an applied fix causes the build to break, you might find it easier to troubleshoot the errors with fewer code changes from the applied fixes.

Resolve build errors after applying a fix​

Fix attempts to verify that all suggested fixes are compilable, but you might apply a fix that is incompatible with your application.

For example, a fix might use an import statement that adds a new library, so that the applied fix can use a supported cleansing function. This change requires an update to your package manager file, such as pom.xml, but Fix does not update this file. This change might cause your application build to fail. To fix the build, you can review your code to see if the applied fix added an import statement and, if it did, add the library to your package manager file.

If your application fails to build after you apply a fix, continue with your regular development processes, such as unit testing, to understand what broke and to resolve the errors. Because Fix makes highly constrained changes to only the area of code where the flaw exists, developer usually do not need to intervene. There could be cases where Fix adds code, such as the import statement in the previous example, which would require a developer to modify code outside the file in which they are working.

Even if an applied fix breaks a build, the flaw is still fixed. Developers might need to spend additional time modifying their code to reach a successful build, but they still spend much less time learning about a flaw and attempting to fix it manually, without Fix.

If your application fails to build after applying a fix, and fixing the package manager file does not resolve the problem, please contact Veracode Technical Support.

Supported integrations​

Veracode Fix is integrated with the following products:

Account requirements​

To use Fix, you must have one of the following accounts:

  • User account with the Submitter user role.
  • API account with the Submitter API role.

Supported languages​

Supported CWEs​

Fix supports the following CWEs for each supported language. For the complete list of CWEs that each Veracode scan type supports, see Veracode and the CWE.

C#​

  • 73: External Control of File Name or Path
  • 80: Improper Neutralization of Script-Related HTML Tags in a Web Page (HTML Injection)
  • 89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection)
  • 117: Improper Output Neutralization for Logs
  • 201: Information Exposure Through Sent Data
  • 209: Information Exposure Through an Error Message
  • 316: Cleartext Storage of Sensitive Information in Memory
  • 327: Use of a Broken or Risky Cryptographic Algorithm
  • 331: Insufficient Entropy
  • 352: Cross-Site Request Forgery (CSRF)
  • 404: Improper Resource Shutdown or Release
  • 601: URL Redirection to Untrusted Site ('Open Redirect')
  • 611: Improper Restriction of XML External Entity Reference

Go​

  • 73: External Control of File Name or Path
  • 78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
  • 117: Improper Output Neutralization for Logs

Java​

  • 80: Improper Neutralization of Script-Related HTML Tags in a Web Page (HTML Injection)
  • 89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection)
  • 113: Improper Neutralization of CRLF Sequences in HTTP Headers
  • 117: Improper Output Neutralization for Logs
  • 159: Improper Handling of Invalid Use of Special Elements
  • 209: Generation of Error Message Containing Sensitive Information
  • 327: Use of a Broken or Risky Cryptographic Algorithm
  • 331: Insufficient Entropy
  • 404: Improper Resource Shutdown or Release
  • 502: Deserialization of Untrusted Data
  • 597: Use of Wrong Operator in String Comparison
  • 601: URL Redirection to Untrusted Site ('Open Redirect')
  • 611: Improper Restriction of XML External Entity Reference

JavaScript and TypeScript​

  • 73: External Control of File Name or Path
  • 78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
  • 80: Improper Neutralization of Script-Related HTML Tags in a Web Page (HTML Injection)
  • 89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection)
  • 113: Improper Neutralization of CRLF Sequences in HTTP Headers
  • 117: Improper Output Neutralization for Logs
  • 209: Generation of Error Message Containing Sensitive Information
  • 311: Missing Encryption of Sensitive Data
  • 312: Cleartext Storage of Sensitive Information
  • 327: Use of a Broken or Risky Cryptographic Algorithm
  • 352: Cross-Site Request Forgery (CSRF)
  • 601: URL Redirection to Untrusted Site ('Open Redirect')
  • 611: Improper Restriction of XML External Entity Reference
  • 614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

Kotlin​

  • 80: Improper Neutralization of Script-Related HTML Tags in a Web Page (HTML Injection)
  • 89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection)
  • 113: Improper Neutralization of CRLF Sequences in HTTP Headers
  • 117: Improper Output Neutralization for Logs
  • 331: Insufficient Entropy

PHP​

  • 73: External Control of File Name or Path
  • 80: Improper Neutralization of Script-Related HTML Tags in a Web Page (HTML Injection)
  • 89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection)
  • 117: Improper Output Neutralization for Logs

Python​

  • 73: External Control of File Name or Path
  • 78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
  • 80: Improper Neutralization of Script-Related HTML Tags in a Web Page (HTML Injection)
  • 89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection)
  • 295: Improper Certificate Validation
  • 327: Use of a Broken or Risky Cryptographic Algorithm
  • 331: Insufficient Entropy
  • 601: URL Redirection to Untrusted Site ('Open Redirect')
  • 757: Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')

Scala​

  • 78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
  • 80: Improper Neutralization of Script-Related HTML Tags in a Web Page (HTML Injection)
  • 89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection)
  • 117: Improper Output Neutralization for Logs
  • 611: Improper Restriction of XML External Entity Reference

Technical support​

If you need help, contact Veracode Technical Support or visit the Community.