Custom import of security hotspots for a typescript project


We have an angular/typescript project, where we would like to do security scanning by means of the eslint rules Microsoft has developed here:

I have got the custom import working using the eslint importer. But potential issues gets marked as code smells. We would like to use the “Security Hotspots” review feature to handle these issues.

Is there any way to accomplish that? We could use the Generic issue format import instead, but it does not look like it supports importing of Security Hotspots

We are on SonarQube 8.9 (Developer Edition)

Hello @cnoergaard and welcome to the community

I would say that you are right, it’s not possible to import external issues as security-hotspots because security-hotspots are not strictly considered as issues (they have a different UI, workflow etc).

I took a quick look at the Microsoft eslint plug-in you point out to us, in order to identify the value, in addition to the in-house SonarSource analyzers, that it can provide:

Microsoft eslint plugin rule Corresponding SonarSource rule rule type
no-caller S2685 Code Smell
no-delete-var S2870 Code Smell
no-eval S1523 Security Hotspot
no-implied-eval S1523 Security Hotspot
no-new-func S1523 Security Hotspot
node/no-deprecated-api Not supported, doesn’t seem super valuable to track usage of deprecated node APIs?
@microsoft/sdl/no-angular-bypass-sanitizer S6268 Security Hotspot
@microsoft/sdl/no-angularjs-bypass-sce Not supported, S6268 could be extended with these sce checks (*)
@microsoft/sdl/no-angularjs-enable-svg Not supported, S6268 could be extended with these svg checks (*)
@microsoft/sdl/no-angularjs-sanitization-whitelist Not supported, these dangerous functions are deprecated in angular 1.8.1
@microsoft/sdl/no-cookies S2255 Security Hotspot
@microsoft/sdl/no-document-domain It seems that is not possible to overwrite document.domain in modern browsers
@microsoft/sdl/no-document-write S5696 Vulnerability
@microsoft/sdl/no-electron-node-integration Electron/desktop apps are out of our scope for the moment but it could be a good idea for a new rule in our future plans
@microsoft/sdl/no-html-method S5696 Vulnerability
@microsoft/sdl/no-inner-html S5696 Vulnerability
@microsoft/sdl/no-insecure-url S5332 Security Hotspot
@microsoft/sdl/no-msapp-exec-unsafe Check related to an “Internet explorer” library
@microsoft/sdl/no-postmessage-star-origin S2819 Vulnerability
@microsoft/sdl/no-unsafe-alloc Could be a good idea for a new rule (*)
@microsoft/sdl/no-winjs-html-unsafe Check related to the old/not super popular WinJS library
@microsoft/sdl/react-iframe-missing-sandbox Could be a good idea for a new rule (*)
react/no-danger S5696 Vulnerability
@typescript-eslint/no-implied-eval S1523 Security Hotspot

As you can see, most of the relevant rules from Microsoft eslint plugin are already supported in SQ. There are certainly some interesting checks (*) that SQ doesn’t natively support at the moment, we will discuss internally about them and possibly add them to our backlog.


1 Like

Thanks @eric.therond.

The rule we are mostly interested in getting checked that we did not find support for is @microsoft/sdl/no-angular-bypass-sanitizer. As you wrote it is now supported by rule S6268 that you added support for in SonarQube 9.0.

We will upgrade to 9.0 ASAP