Working with the Fix Report

The fix report page allows you to browse through the fixes available for your project

Fix Report Overview

The top banner provides users with the following information:

• Overview of the fix report, such as the name of the project, repository link, branch name, git hash, and whether there are code version issues.

• Analysis version: If multiple versions are available, click on the drop-down to select other previous runs.

• Report expiry. (default is 2 weeks). If extension is required, click on the 3 dots to extend it by 30 days.

• Fix status: Calculates the number of fixes in ready, committed, and downloaded status.

• Top issues by Type: This chart shows the number of fixes available by top issue types.

Issue Categorization

The issues reported by your SAST report will be categorized into one of 3 categories: Fixable issues, Irrelevant Issues, and Remaining Issues. See below for more details

Issue Categorization - Fixable Issues

By selecting the "Fixable Issues" category. Your fix report will display the actionable fixes that you can review and commit directly to your repository.

Issue Categorization - Irrelevant Issues

By selecting "Irrelevant Issues", you will be able to see issues that are most likely false positives or irrelevant to your current context. There are various types of reasonings that you may observe when you are in this view:

• - Autogenerated code refers to code that is generated automatically by tools or frameworks as part of the build or runtime process. This categorization highlights that the issue resides in non-manual code, which often requires tool-specific solutions or exemptions.

• - False positive indicates the finding reported in your SAST report is not a real security issue and is potentially incorrectly flagged by the SAST tool. The specific reasoning will be outlined

• - Test code refers to code that resides in a test-specific path or context. This categorization indicates that it supports testing scenarios and is isolated from production use.

• - Suppressed indicates the issue was suppressed in the scan report (Mostly applies to Fortify results).

• Auxiliary Code - Code that is included in the codebase but does not impact the application's runtime behavior or security posture.

Here is an example of a False Positive detection in action:

Example of a false positive detection

Issue Categorization - Remaining Issues

By selecting the "Remaining Issues" category, you will see the list of issues that Mobb does not have a fix yet.

Due to Mobb's mandate to only release deterministic and validated fixes, certain issues in your SAST report will not be fixed by Mobb yet. If you'd like Mobb to fix these issues, please reach out to us at [email protected]!

Bulk Commits Best Practices using the Fix Side Panel

The side panel is a powerful tool designed to streamline your review process, especially when dealing with multiple fixes. Instead of navigating away, you can leverage the side panel to inspect each fix in detail.

Best Practice for Bulk Commits:

1. Review Individual Fixes: Click on a fix in the list to open it in the side panel. Here, you can examine the code changes, verify they are correct, and ensure no logic is broken.

2. Explain Fix: If you need more context, use the "Explain Fix" feature within the side panel to understand the "why" and "how" behind the remediation.

3. Take Action: Some fixes might require additional input or validation. Perform these actions directly in the side panel to make the fix "ready to go".

4. Select for Commit: Once you are satisfied with a fix, select its corresponding checkbox on the left. Repeat this for all valid fixes.

This workflow ensures that you are fully confident in every change you submit, even when processing large batches of fixes.

Performing the Bulk Commit

Once you have selected the fixes you want to include:

1. Select the checkbox for the issue type (if you want to select all remaining) or ensure your specific fixes are selected.

2. Confirm the number of fixes you will be committing

3. Select either "Commit Fixes" or "Download"

4. If "Commit Fixes" is selected, this will bring up the "Commit changes" screen which will allow you to submit the fixes

Search and filtering fixes

You can filter the fixes by using the "Add filter" button. There are different filter parameters available:

• Dev Owner

• Issue Type

• Status

• Confidence

• PowerUp

• Severity

• Language

• Effort

Fixing Effort

Fixing effort is an indicator of the level of effort required to complete a particular fix. This can be viewed in the fix report page under the "Effort" column as shown:

Currently, there are 3 levels of fixing effort:

• Easy / One-click fix - Mobb has all the information it needs, and no further actions are required.

• Additional Actions Required - Mobb has most of the info it needs, but provides you with the opportunity to influence the fix further.

• Dev research required - Mobb has most of the info it needs, but may require you to perform some additional research to validate and finalize the fix.

Confidence

Confidence levels indicate the maturity and reliability of Mobb's fixes. This classification helps you understand the development status and expected quality of each fix type:

• - Stable fixes follow deterministic algorithms and industry best practices for fix implementation. They have been thoroughly tested and validated, providing the highest level of confidence for production use.

• - Adaptive are AI-generated fixes that intelligently adapt to your specific coding patterns and style, providing contextually appropriate solutions that seamlessly integrate with your existing codebase.

Fix Explanation

Mobb provides detailed explanations for how and why each fix was implemented in a specific way. This feature helps developers understand the security remediation logic and learn from Mobb's fix strategies.

Accessing Fix Explanations

When viewing an individual fix, you'll find an "Explain Fix" button that generates an AI-powered explanation of the applied fix.

Clicking this button generates a comprehensive explanation that provides detailed insights into the security fix implementation:

This explanation typically includes:

• Security Fix Explanation - A detailed overview of the vulnerability type and the remediation approach

• What Changed - Specific code modifications made by the fix

• New Dependencies Added - Any libraries or packages added to support the fix

• Sanitization Applied - How user input is being sanitized or validated

• How the Fix Works - Technical details on the remediation mechanism

• Example - Practical examples showing before and after code states

• How to Use This Pattern in Your Code - Guidelines for applying similar patterns elsewhere

• Key Takeaways - Important security principles and best practices

• Important Note - Additional considerations or warnings about the fix approach

Fix Status

As each row corresponds to a fix, every fix has an associated fix status.There are three possible statuses:

• Fix available A fix is available for this file. The next step is to review the proposed changes and commit them to the repository.

• Committed The fix has already been committed to the repository. A link is provided to the pull request or commit where the fix was applied, allowing you to review the changes directly in your SCM. The fix has been downloaded as a patch file (.diff). From there, it can be reviewed and committed as part of the developer's normal workflow.

Optional Branch Prefix

Mobb allows you to specify an optional branch prefix when submitting fixes. This helps you follow your team's branch naming conventions (e.g., feature/, fix/, security/). The prefix will be prepended to the branch name in the format {prefix}/{branch-name}.

Branch prefix option for a single PR

This option is also available when performing bulk commits:

Branch prefix option for bulk commits