Import SARIF results as security hotspots

SonarQube
, ,
1

Can I import SARIF results as security hotspots?
At present, according to the document, I can import SARIF results as vulnerabilities, but its life cycle is unmanageable.
I want to import SARIF results as a security hotspot. Do you currently support this function? If not, is there a plan in the future?
Thanks, my English is not very good.

2

Hey there.

It’s not supported to import SARIF results as Security Hotspots – we don’t expect external tools to raise issues that match our definition of a security hotspot.

A security hotspot highlights a security-sensitive piece of code that the developer needs to review. Upon review, you’ll either find there is no threat or you need to apply a fix to secure the code.

Do you have an example of an issue raised by another tool matching this definition?

3

For the static application security scanning tool, I think many results need to be reviewed to determine whether it is a real security problem or a false alarm.
For example, the scanning results of Semgrep tool, I think it is consistent with the definition of security hotspot.

1 Like
5

Hello,

Today, there is a problem with the SARIF format: it doesn’t allow to specify somewhere a property to qualify what is reported. For us, it means we don’t know how to map a SARIF finding with our own type of findings (Bug, CodeSmell, Vulnerability, or Hotspot). By default, because the majority of the SARIF producers are SAST-related, we decided (and it’s an arbitrary choice) to map all SARIF findings to Sonar Vulnerability. That’s not the best and we know it.

Now that you know the constraint, what would be the ideal way to tell Sonar which type of findings you are about to load?

Alex

1 Like
7

@Alexandre_Gigleux Thanks for your reply.

I think it is more appropriate for the “SAST” tool to map SARIF results to “Security Hotspots” than “Vulnerability”. Security problems usually need to be analyzed to confirm whether they are real problems, and SARIF provides additional information that can be used in “Security Hotspots”, such as “remedial measures”. However, for the SARIF results of the “Code Quality” tool, it may be more appropriate to map to “Bug” and “Code Smell”.

Due to the limitation of SARIF, the result cannot be accurately mapped to the SonarQube problem type. But I think it can at least allow users to choose to map SARIF to the specified problem type, such as using “sonar. bug. sarifReportPaths” to map to “Bug” type problems, and using “sonar. hotspots. sarifReportPaths” to map to “Security Hotspots” type problems, although this is not the best way.

Further, users can convert the “SARIF” format to the “Generic issue import format” (It’s not difficult) and then import it to SonarQube, so that users can choose to map the type of each specific problem (but unfortunately, at present, only the conversion to BUG, VULNERABILITY, CODE_SMELL is supported, and Security Hotspots are not supported).

I don’t deny the current implementation of SonarQube. I mentioned “Security Hotspots” in the topic because SonarQube cannot change the status of the problem (such as being marked as false positive) after importing a third-party problem, so it can’t manage the life cycle of the problem. I think this is very important. I found that the problem of security hotspots can do this, so I hope to add “security hotspots” to the problem types that support conversion.

I also do not deny the scanning function of SonarQube. The quality and safety scanning of SonarQube itself is worthy of recognition, but since the support of third-party reports has been added, I hope this function can do better.

Thanks again for your reading and reply!

1 Like
9

To add to this, it would be great to have full control over how SARIF issues are mapped but if the SARIF format doesn’t support that then this becomes harder.
Perhaps we could have some way to control the mapping in general from SARIF levels to a combination of SonarQube severity and potentially vulnerability/bug etc
Certainly I would like to see at least

  • The ability to change what null/empty maps to
  • The ability for the report as a whole to be mapped to a different category - maybe for SARIF producer foo I want everything to be a hotspot but for SARIF producer bar I want them to be vulnerabilties or bugs…

At the moment we get for example with TFLint, not following the snake_case naming convention is classified as a vulernability - this is clearly nonsense and devalues “vulnerabilitiy” - the danger is that people start to ignore “vulnerabilities” because they know they are false

10

Dear community,

Waiting for a solution from SonarSource, I made a small utility script to convert SARIF to Generic Sonar report format. That way we can specify the type of issue.

The script is designed to rely only on Python’s standard library.
It’s working flawlessly inside the Sonar Scanner CLI official Docker.

Hope it will be useful for you too.