# REST API Common Deployment Scenarios ## Using GET Issues v5 API with False Positive Support The GET Issues v5 API endpoint provides enhanced functionality over previous versions, including false positive support and improved filtering capabilities. This guide demonstrates how to use the v5 endpoint effectively. ### Overview The v5 issues endpoint (`/api/rest/v5/issues`) offers several key enhancements: * **False Positive Support**: Access `fpDescription` field for false positive information * **Enhanced Metadata**: Includes `createdAt` and `fingerprintHash` fields * **Vulnerability Tags**: Access `vulnerabilityReportIssueTags` array * **Improved Filtering**: Filter by `fixReportId` parameter for targeted queries ### Step 1: Get Available Fix Reports ([`GET fix-reports v2`](https://apidocs.mobb.ai/mobb-rest-api#tag/fix-reports/get/api/rest/v2/fix-reports)) First, retrieve all available fix reports to identify the ones you want to query: ```bash curl -X GET "https://api.mobb.ai/api/rest/fix-reports" \ -H "x-mobb-key: YOUR_API_KEY" \ -H "Content-Type: application/json" ``` **Sample Response:** ```json { "getReportsApiV2": { "fixReport": [ { "id": "f1fdee4c-9a62-4913-a179-18d07ec11a0e", "createdOn": "2024-01-10T23:41:53.650049+00:00", "expirationOn": "2024-01-24T23:41:53.650049+00:00", "createdByUser": { "email": "antony.demo@mobb.ai", "id": "1f7ba60a-b4b8-4a08-91b9-d3a8c4af814d" }, "vulnerabilityReport": { "vendor": "snyk", "project": { "id": "276cd1ed-64b7-496e-ad14-98eb6f55d5e0", "name": "My first project" } }, "repo": { "name": "mobb-circleci-integration", "originalUrl": "https://github.com/antonychiu2/mobb-circleci-integration", "reference": "main" } } ] } } ``` ### Step 2: Query Issues with Fix Report ID ([`GET issues v5`](https://apidocs.mobb.ai/mobb-rest-api#tag/issues/get/api/rest/v5/issues)) Use the fix report ID from Step 1 to get issues with enhanced metadata and false positive information: ```bash curl -X GET "https://api.mobb.ai/api/rest/v5/issues?fixReportId=f1fdee4c-9a62-4913-a179-18d07ec11a0e" \ -H "x-mobb-key: YOUR_API_KEY" \ -H "Content-Type: application/json" ``` ### Step 3: Understanding the v5 Response The v5 response includes enhanced fields not available in previous versions: **Key New Fields:** * `fpDescription`: Description when an issue is marked as false positive * `createdAt`: Timestamp when the issue was created * `fingerprintHash`: Unique fingerprint for the issue * `vulnerabilityReportIssueTags`: Array of tags associated with the issue **Sample v5 Response:** ```json { "getIssuesApiV5": { "vulnerability_report_issue": [ { "id": "dda692d7-0bd4-46b9-a978-3bbb09ac583f", "vendorInstanceId": null, "vendorIssueId": "371", "issueType": "browser.security.insecure-document-method", "severity": "error", "issueLanguage": "javascript", "state": "FalsePositive", "createdAt": "2025-10-22T19:10:24.36944+00:00", "fingerprintHash": "413f05ef11f75684c85c0d09f132770a", "vulnerabilityReportIssueTags": [ { "vulnerability_report_issue_tag_value": "FALSE_POSITIVE" } ], "fix": null, "fpDescription": "This issue is a false positive. This is not an XSS vulnerability. The code is setting innerHTML to a hardcoded constant value (wysihtml5.INVISIBLE_SPACE = '\\uFEFF') which is a Unicode zero-width no-break space character. There is no user-controlled input being inserted into the DOM - only a predefined, safe constant string. The value is not derived from any external source, user input, or dynamic data that could contain malicious content." } ], "hasNextPage": false } } ``` ### Filtering Options #### Filter by Specific Issue ID ```bash curl -X GET "https://api.mobb.ai/api/rest/v5/issues?issueId=abc12345-e89b-12d3-a456-426614174003" \ -H "x-mobb-key: YOUR_API_KEY" ``` #### Filter by Fix Report ID ```bash curl -X GET "https://api.mobb.ai/api/rest/v5/issues?fixReportId=123e4567-e89b-12d3-a456-426614174000 -H "x-mobb-key: YOUR_API_KEY" ``` ### Common Use Cases 1. **Quality Assurance**: Review `fpDescription` to understand why issues were marked as false positives 2. **Issue Suppression for SAST Scanners**: Use false positive descriptions to improve scanning accuracy 3. **Reporting**: Generate reports showing false positive rates and reasons 4. **Issue Tracking**: Track issue lifecycle with `createdAt` timestamps and `fingerprintHash` for deduplication ### Best Practices for using [`GET issues v5`](https://apidocs.mobb.ai/mobb-rest-api#tag/issues/get/api/rest/v5/issues) * **Use Fix Report ID Filtering**: Always filter by `fixReportId` when querying specific fix reports to reduce the response size. * **Handle Pagination**: Check `hasNextPage` field and implement pagination for large result sets. If the result set exceeds 1000 entries, the response will be trucated with `hasNextPage` set to `true`. To obtain the full result set, the user will need to capture the last `issueId` and re-run the same API again by supplying the `issueId` to obtain the next 1000 results. Repeat until `hasNextPage` returns `false`. * The issue result sets are chronologically ordered from earliest to latest ## Parsing Fix Confidence and Fix Rating from Fix Report Details API This guide explains how to interpret the response from the [`GET fix-reports/{fixReportId}`](https://apidocs.mobb.ai/mobb-rest-api#tag/fix-reports/get/api/rest/fix-reports/{fixReportId}) API. ### How to obtain fix confidence status The `confidence` field in the API response allows you to determine if a fix is considered "Stable" or "Adaptive". * **`"confidence": 90`**: indicates **Stable Fix**, which are deterministic fixes * **`"confidence": 50`**: indicates **Adaptive Fix**, which are fixes generated using intelligent AI techniques that may require closer review. For more details on Stable vs Adaptive fixes, see [Working with the Fix Report](https://docs.mobb.ai/mobb-user-docs/getting-started/working-with-the-fix-report). **Sample Output (Truncated):** ```json { "fixReport": [ { "fixes": [ { "id": "51c6cce5-8374-4357-bda8-9a8e03f98e4b", "safeIssueType": "SQL_Injection", "confidence": 90, } ] } ] } ``` ### How to obtain Fix Rating The `sharedState` object contains the `fixRatings` array, which details user sentiment and feedback on a fix. * **Vote Score (`voteScore`)**: * `1`: **Thumbs Up** * `-1`: **Thumbs Down** * **Fix Rating Tag (`fixRatingTag`)**: Reason for rejection (if `voteScore` is `-1`). * Values: `BAD_PATTERN`, `BREAKING_FIX`, `FALSE_POSITIVE`, `OTHER`, `UNRESOLVED_FIX` * **Comments (`comment`)**: Improved context provided by the user. * **User Info**: `email` and `name` of the reviewer. For more information on how to submit feedback via the UI, see [Providing Fix Feedback](https://docs.mobb.ai/mobb-user-docs/more-info/providing-fix-feedback). **Sample Output (Truncated):** ```json { "fixReport": [ { "fixes": [ { "id": "51c6cce5-8374-4357-bda8-9a8e03f98e4b", "sharedState": { "isArchived": false, "fixRatings": [ { "voteScore": -1, "fixRatingTag": "FALSE_POSITIVE", "comment": "This query is already parameterized elsewhere.", "user": { "email": "user@test.com", "name": "First and Last Name" }, "updatedDate": "2025-12-09T20:03:52.535734+00:00" } ] } } ] } ] } ``` ## Retrieving a Concise False Positive Summary ### Overview When Mobb marks an issue as a false positive, it generates a detailed `fpDescription` explaining exactly why the issue is not a real vulnerability. These descriptions are intentionally thorough — often spanning multiple paragraphs — to provide developers and security engineers with a complete rationale. However, in many integration scenarios, a full-length explanation is impractical. For example: * **SAST scanner suppression comments** embedded directly in source code have strict character limits. * **Ticketing systems** (e.g., Jira, Linear) benefit from a concise one-line summary rather than a wall of text. * **Dashboards and reports** that surface FP justifications inline need a short, readable blurb. * **CI/CD pipeline logs** where brevity improves readability. The [`GET /api/rest/fp-summary`](https://apidocs.mobb.ai/mobb-rest-api#tag/issues/get/api/rest/fp-summary) endpoint solves this by returning a trimmed version of the false positive description — capped at 280 characters. *** ### Step 1: Identify the False Positive Issue and Capture Its `fpId` ([`GET issues v5`](https://apidocs.mobb.ai/mobb-rest-api#tag/issues/get/api/rest/v5/issues)) Query the v5 issues endpoint, filtering by your fix report ID. In the response, look for issues with `"state": "FalsePositive"` — these entries include an `fpId` field that uniquely identifies the false positive record. ```bash curl -X GET "https://api.mobb.ai/api/rest/v5/issues?fixReportId=a210dd07-a9df-4c2b-ad89-22343a580148" \ -H "x-mobb-key: YOUR_API_KEY" \ -H "Accept: application/json" ``` **Sample Response (relevant fields shown):** {% code overflow="wrap" %} ```json { "getIssuesApiV5": { "vulnerability_report_issue": [ { "id": "2df47df3-b139-4d6b-bf04-ac06bc514ef4", "vendorIssueId": "257", "issueType": "XSS", "severity": "error", "issueLanguage": "javascript", "state": "FalsePositive", "createdAt": "2026-03-04T18:10:11.439502+00:00", "fingerprintHash": "3c448e02f9ce40437d49864480ddffae", "vulnerabilityReportIssueTags": [ { "vulnerability_report_issue_tag_value": "FALSE_POSITIVE" } ], "fix": null, "fpId": "e0d33c87-8602-4267-a720-190ef66c8a54", "fpDescription": "This issue is a false positive. The flagged code at lines 430-442 involves retrieving a user record from the database using `req.params.userid`, updating the user's status field with a validated value from `req.body.status`, and then saving the record. On line 442, if an error occurs during the save operation, `res.status(500).send(err)` is called. This is NOT an XSS vulnerability because:\n\n1. The `err` object is a server-side error object generated by the database/ORM layer (likely Mongoose based on the `.save()` pattern), not user-controlled input.\n\n2. The `req.params.userid` is used only for database lookup and is never rendered in HTML context in this code path.\n\n3. The `req.body.status` value is strictly validated on lines 425-428 to only allow 'active' or 'inactive' before being assigned to the user object.\n\n4. The error response on line 442 sends the error object directly via Express's `res.send()`, which will serialize it as JSON or text. This is not a DOM manipulation or HTML rendering context where XSS could occur.\n\n5. While sending raw error objects to clients is poor practice from an information disclosure perspective, it does not constitute XSS as there is no user-controlled data being reflected into an HTML/JavaScript execution context.\n\nThe trace does not show any path where user input reaches a DOM sink like innerHTML, document.write(), or similar XSS-prone methods." } ], "hasNextPage": false } } ``` {% endcode %} Note the `fpId` value (`e0d33c87-8602-4267-a720-190ef66c8a54`) from the response — you will use this in the next step. *** ### Step 2: Retrieve the Concise FP Summary ([`GET fp-summary`](https://apidocs.mobb.ai/mobb-rest-api#tag/issues/get/api/rest/fp-summary)) Pass the `fpId` captured in Step 1 to the `/api/rest/fp-summary` endpoint to retrieve a condensed, 280-character-maximum summary of the false positive justification: ```bash curl -X GET "https://api.mobb.ai/api/rest/fp-summary?fpId=e0d33c87-8602-4267-a720-190ef66c8a54" \ -H "x-mobb-key: YOUR_API_KEY" \ -H "Accept: application/json" ``` **Sample Response:** {% code overflow="wrap" %} ```json { "getFpSummary": { "fpId": "e0d33c87-8602-4267-a720-190ef66c8a54", "fpDescriptionShort": "[marked FP by Mobb] False positive flagged as XSS; error is DB/ORM-generated, params are non-HTML rendered, body input is validated, and error is JSON serialized, not reflective in HTML/JS context." } } ``` {% endcode %} The `fpDescriptionShort` field contains the concise summary, ready to be embedded in code comments, tickets, or pipeline output.