Enable Jenkins Security Scan

[strangelookingnerd]

It is stated in the JENKINS SECURITY POLICY that

The Jenkins project takes security seriously. We make every possible effort to ensure users can adequately secure their automation infrastructure. To that end, we work with Jenkins core and plugin developers, as well as security researchers, to fix security vulnerabilities in Jenkins in a timely manner, and to improve the security of Jenkins in general.

We as plugin developers should try our best to support this. One way of doing so is to enable the Jenkins Security Scan on this repository. For more details see the documentation.

This PR may create new issues in the Code scanning section of this project once it is merged. I'd be happy to try and help resolve those if necessary.

Please note this PR was created semi-automatically. If you find any issue with it, don't hesitate to ping me.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[sephiroth-j]

Only 16% of the "findings" relate to classes that use a code related to Stapler. Only 4% are legitimate findings. I am not willing to add a scanner that has a false positive rate of 96%.

[strangelookingnerd]

Only 16% of the "findings" relate to classes that use a code related to Stapler. Only 4% are legitimate findings. I am not willing to add a scanner that has a false positive rate of 96%.

Unfortunately I am unable to view the findings. So it is hard for me to tell if they are legitimate or what needs to be done - maybe someone from Jenkins security team can help out? @Wadeck

Just for clarity, I understand that dealing with false-positives is cumbersome - however I personally feel that if legitimate security issues can be prevailed it should still be considered.

[Wadeck]

We encourage plugin maintainers to provide feedback about the scan reports, to see what could be improved. The rate of false positives is a known issue for some of the rules.

Now, if you encounter false positives, they can be marked as accepted and they will not show up again. If we are able to catch even just one vulnerability, that's worth the effort.

The Jenkins security team will review the status of the scan in your repository.

[daniel-beck]

In this particular case, the vast majority of the false positives are coming from the naming of the functional interface method #doWithRetry, which matches Stapler's naming convention. Since Jenkins 2.154 without Stapler-related arguments, annotations, or return type, this is a false positive finding; unfortunately I failed to make that work correctly in JST when I tried a few years ago. I filed jenkins-infra/jenkins-codeql#44 to track this.