Hosting request - Update on the security audit part

[wfoll...@cloudbees.com]

Hello there,

To give you a bit of context, let me give you my definition of the return on investment (ROI) for the security team. I consider the investment mainly as time and task difficulty. For the value, it's mainly the number of users receiving a more secure application.

Directly from this, when the team is spending one day auditing a plugin with 100k installations, or one with less than 1k, the ROI is completely different.

Since ~one year, the security team was directly involved in the auditing of the plugin hosting requests on https://github.com/jenkins-infra/repository-permissions-updater/. As I want to optimize the effort dedicated by the team in the tasks with good ROI, the team invested some time implementing bot commands to ease the process.

I am writing this message to tell you that since some minutes ago, we are starting sort of a beta of a new automation on the hosting request process. When a hosting request is created, a security scan will be performed on the candidate repository. If there are findings (including false positives), the author is requested to either correct them, justify them or provide a suppression. The security scan can be re-triggered using a command (/request-security-scan).

Ideally this automation should cover the previously manual audit. The review of the audit report / justifications is still undefined.

The security team will carefully observe the automation to ensure it's working as expected and provide the desired value.

With this initiative, I hope the security team will be able to provide more value to the project as a whole.

Best regards,

Wadeck

PS: We are keeping a very generic name for the "Security scan" even if it's based on the CodeQL rules that Daniel introduced some time ago. The idea behind this is to not bind ourselves to a single tool.