SSC processing error on some inputs

[rsenden]

Current Behavior

Some SARIF files fail to be imported due to an SSC artifact processing error.

Expected Behavior

All valid SARIF files should be successfully imported into SSC.

Steps To Reproduce

As an example, the WebGoat5.0.fpr.sarif sample file included in this repository fails to be processed by current SSC versions, resulting in the following exceptions in ssc.log:

[ERROR] com.fortify.manager.BLL.impl.FPRBLLImpl - Error parsing issues: WebGoat5.0.fpr.sarif.zip
com.fortify.manager.exception.FMDALException: Unable to execute batch.
...
Caused by: org.springframework.dao.DataIntegrityViolationException: PreparedStatementCallback; SQL [INSERT INTO finding(projectVersion_id,guid,name,description,findingType) VALUES(?,?,?,?,?)]; (conn=64) Data too long for column 'guid' at row 1; nested exception is java.sql.BatchUpdateException: (conn=64) Data too long for column 'guid' at row 1

Anything else?

The issue data generated by the parser plugins is used calculate a correlation guid; apparently this calculation sometimes generates values that are too large to be stored in the guid database column. This calculation is done by SSC, hence this is considered to be an SSC bug, not a parser plugin bug.

Subject to change, this is currently planned to be fixed in SSC 25.4. Customers affected by this issue may consider opening a support case, referencing engineering ticket OCTCR11A1806016.

[rsenden]

SSC engineering did some research; root cause is that with the mentioned input file, the parser plugin sets the category field to a very long string. Although SSC team agrees that SSC should handle this better (either no error or more accurate error), we may also want to consider a fix in the parser plugin as having a very long category makes it difficult to navigate the results in SSC:

In the mentioned input file, the parser plugin reads the category from the shortDescription property in the rules object, which, according to SARIF specification §3.49.9, SHOULD be a single sentence that is understandable when visible space is limited to a single line of text.

In this case, shortDescription indeed always seems to be a single line, but it's a very long line, so questionable whether this is according to the specification. Also, shortDescription contains unresolved placeholders that are being stripped by SSC as they look like HTML tags, resulting in incomplete descriptions being shown in SSC.

For now, given that this is an unusual input (why would you want to convert a Fortify FPR file into SARIF format using SARIF MultiTool, and then import that SARIF file into SSC, rather than importing the original FPR file?), we'll leave this as-is for now.

If we ever receive actual user reports about similar issues, for example in case other tools produce shortDescription contents in their SARIF output that are not suitable for use as the Fortify Category, we'll need to update the parser plugin to handle this better. The parser plugin already falls back to using other fields like rule name or id if shortDescription is not available, so the easy fix would be to just not use shortDescription at all for Fortify category. However:

• This could potentially change the category name for already existing issues in customer SSC instances
• According to SARIF specification §3.49.2, rule objects may potentially contains only shortDescription or fullDescription, not any of the other fields, which is likely the reason why we look for shortDescription in the first place

Some ideas:

• Change the order in which the plugin looks for SARIF fields, for example first use rule name, fall back to id if name not available, and eventually fall back to shortDescription if no other rule properties are available. Note that this may still result in category names being changed for existing scan results.
• Keep existing field lookup order, but only use shortDescription if it doesn't exceed a certain number of characters, or if none of the other rule fields are available (in which case we might want to trim the shortDescription.
• Throw a proper exception if we can't determine a proper category (shortDescription too long, and/or none of the other rule fields available).

Anyway, as stated above, we'll only change this behavior if customers run into similar issues.

[MonsieurCo]

Hello @rsenden,

I am reaching to you because i am experiencing similar issues on SARIF format
I am scanning some test project, here is my issues :

for this project https://github.com/bnematzadeh/grpc-web-playground
I am scanning with opengrep and there is the output on SARIF format

grpc-web-playground_20251117_154952_report.sarif (the file is in text format since i can´t upload SARIF format here )

I have this error on client side ( no ssc log sorry i don´t have access to them)

Exception: An unexpected error occurred during scan processing: com.fortify.manager.exception.FMScanParseException: Parsing error while parsing scan vulnerabilities: Cannot deserialize value of type 'java.net.URI' from String "2_Server Streaming/client/client.js": not a valid textual representation, problem: Illegal character in path at index 8: 2_Server Streaming/client/client.js at [Source: (com.fortify.util.io.RegionInputStream); line: 1, column: 3213] (through reference chain: com.fortify.ssc.parser.sarif.domain.Result["locations"]->java.lang.Object[][0]->com.fortify.ssc.parser.sarif.domain.Location["physicalLocation"]->com.fortify.ssc.parser.sarif.domain.PhysicalLocation["artifactLocation"]->com.fortify.ssc.parser.sarif.domain.ArtifactLocation["uri"]); session b8mvd7v78ni6a

for these project :

• Tiredful-API
• yrpreyLibrary
• yrpreyTasksPython

Here is the SARIF if you want to dig more into it :

• Tiredful-API_20251117_154952_report.sarif
• yrpreyLibrary_20251117_154952_report.sarif
• yrpreyTasksPython_20251117_154952_report.sarif

Thanks for your consideration

[MonsieurCo]

For the first issue i am implementing a fix if you want I'll submit a pull request
the issue was explicit
the others i have to investigate more and ask for my fortify logs

[rsenden]

Hi @MonsieurCo, thanks for reporting this. To accept pull requests, officially we need a signed contributor agreement to avoid any copyright & ownership issues; see CONTRIBUTING.md.

Not sure when I'll have time to look into these issues, I'll ask a colleague to have a look as I'll be away for the next two weeks. Once you have the SSC logs, it would be useful if you can share them (or at least the relevant portion/stack traces), but please make sure that they don't contain any sensitive data. Note that there's the main ssc.log file, but also a separate plugin-framework.log; depending on the root cause, detailed error information might be in either log file.

[rsenden]

@MonsieurCo Thanks for raising a PR, this has now been merged and released in v1.7.1