Add auto-remediation to InsecureDependencyResolution.qhelp

[JLLeitschuh]

Adds an automated remediation suggestion to InsecureDependencyResolution.qhelp.

I authored an open rewrite recipe that can be leveraged, free for OSS, to automatically remediate this security vulnerability. The source for this recipe can be found here: https://github.com/openrewrite/rewrite/blob/cfd371c295950ee3f3ee4b15f43cb13c37ed130f/rewrite-maven/src/main/java/org/openrewrite/maven/security/UseHttpsForRepositories.java

[aschackmull]

Looks plausible to me. @atorralba any comments?

[atorralba]

Although this looks good from a security perspective, I've checked with our product team and unfortunately we'll need to reject this. Automated fixes isn't something that we want to suggest we're tackling right now — even if it's only a link to an external project, it could send the wrong message from a product perspective.

[JLLeitschuh]

Automated fixes isn't something that we want to suggest we're tackling right now — even if it's only a link to an external project, it could send the wrong message from a product perspective.

Can you elaborate? CodeQL is free for OSS, and Moderne & OpenRewrite is free for OSS. If this solution helps simplify a fix that an OSS maintainer can perform, why wouldn't you want to provide this suggestion to them?

it could send the wrong message from a product perspective.

What message are you concerned that could be sent here?

[atorralba]

Automated fixes is a concept that could make sense to add in one way or another to CodeQL in the future, but it needs to be well-thought. Our concern is that users could get the message that we have decided to tackle automated fixes right now by recommending an external tool to do so. And also, only mentioning it in one query would add to the confusion.

We appreciate the contribution, but it has deeper implications than it would initially seem and it's a can of worms we don't want to open right now.

[JLLeitschuh]

It sounds like this concern and resultant decision is originating from GitHub offering a product for sale, over GitHub offering a security tool designed to secure OSS ecosystems. This balance and this decision seems at-odds with the mission of the GH Security Lab and various proclamations that have been made GitHub regarding the desire to help support securing OSS.

[atorralba]

Reopening the PR since the discussion is active and we can try to find an intermediate solution.

This balance and this decision seems at-odds with the mission of the GH Security Lab and various proclamations that have been made GitHub regarding the desire to help support securing OSS.

I don't think my previous comments should be interpreted in those terms, and I apologize for any miscommunication on my end. What we are trying to achieve here is that users understand that we're not specifically providing any automated remediation advice, because doing so implies some risk of breaking the users' source code and that liability shouldn't be on CodeQL. I'm going to defer to @turbo on this one if further clarification is needed.

Having said that, we suggest the following:

Since we usually add links to technical blog posts or articles that explain a vulnerability and offer remediation advice (that the reader needs to understand and implement in their codebase appropriately, becoming responsible for it), what would you think of creating a post like that yourself for this vulnerability? In it you could add any remediation advice you find appropriate, including a link to your OpenRewrite recipe. And then there should be no issue in adding a link to that article in the references section of this query (in this PR or in a new one).

[JLLeitschuh]

What we are trying to achieve here is that users understand that we're not specifically providing any automated remediation advice, because doing so implies some risk of breaking the users' source code and that liability shouldn't be on CodeQL. I'm going to defer to @turbo on this one if further clarification is needed.

Is this liability from a legal perspective, or from a 'do no harm' perspective?

I believe that the licensing terms on this repo and on OpenRewrite are sufficient to protect from a legal perspective.

• codeql/LICENSE

  Lines 15 to 21 in 75265f7

  	THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
  	IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  	FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
  	AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
  	LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
  	OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  	SOFTWARE.

• https://github.com/openrewrite/rewrite/blob/3cac3a0fd2a402c2dbd6a0cb516cf94d5b33c7c4/LICENSE#L153-L163

because doing so implies some risk of breaking the users' source code and that liability shouldn't be on CodeQL.

By "broken code" do you mean "broken and unable to compile", or "broken" as in "this code change claims to fix the vulnerability, but is actually insufficient"? If it's the former, I'd expect that developers would run their code changes through a CI/CD process before just merging the changes. Moderne's solution supports generating a pull-request. If the concern is about whether or not a fix is sufficient or not, I can understand the concerns around liability here.

In this case, I can offer you a very high confidence that this particular recipe will fix the vulnerability. There are other recipes I'm working on that have a lower chance, or may not fix more complicated code paths. I think that setting appropriate expectations when linking to a recipe is appropriate.

[JLLeitschuh]

Since we usually add links to technical blog posts or articles that explain a vulnerability and offer remediation advice (that the reader needs to understand and implement in their codebase appropriately, becoming responsible for it), what would you think of creating a post like that yourself for this vulnerability? In it you could add any remediation advice you find appropriate, including a link to your OpenRewrite recipe. And then there should be no issue in adding a link to that article in the references section of this query (in this PR or in a new one).

This level of indirection seems silly and bureaucratic. Also, I struggle with long-format article writing. Would GitHub be willing to support this by providing a technical writer to work with me on creating this article? I'm willing to do this, if GitHub is willing to also assist me with support from the writing side.

[yo-h]

The decision on whether to merge this in its current form or in a modified form falls outside of the engineering team. @turbo, please provide guidance from a product perspective on how to proceed.