Skip to content

feat: Guard against nil response in code security attach methods - #4696

Open
LemonCondor wants to merge 1 commit into
google:masterfrom
LemonCondor:fix/codesec-attach-nil-resp
Open

LemonCondor wants to merge 1 commit into
google:masterfrom
LemonCondor:fix/codesec-attach-nil-resp

Conversation

@LemonCondor

@LemonCondor LemonCondor commented Oct 31, 2026 •

Copy link
Copy Markdown

EnterpriseService.AttachCodeSecurityConfigurationToRepositories and OrganizationsService.AttachCodeSecurityConfigurationToRepositories dereference resp.StatusCode as soon as Do returns an error:

resp, err := s.client.Do(req, nil)
if err != nil && resp.StatusCode != http.StatusAccepted {
    return resp, err
}

Client.Do can return a nil *Response together with a non-nil error — for example on a transport error, or when the request context is canceled (bareDo returns (nil, ctx.Err())). In those cases the check above panics with a nil pointer dereference instead of returning the error to the caller.

The intent of the check is only to swallow the expected 202 Accepted for these async "attach" endpoints. The canonical, nil-safe form of exactly this pattern is already used elsewhere in the package, e.g. AppsService.DeleteInstallation in apps.go:

if err != nil && (resp == nil || resp.StatusCode != http.StatusAccepted) {

This PR adds the missing resp == nil || guard to both code-security methods and adds regression tests that drive the Do-failure path with a canceled context (the existing tests only reach the Do-failure path via a NewRequest failure, which returns before the buggy line, so the crash was uncovered).

Disclosure

This was found and prepared during LLM-assisted code review using GitHub Security Researcher, an open-source code-analysis tool I maintain. I reviewed the change myself, confirmed the nil-return paths in bareDo/Do, and verified go vet and the affected tests pass locally.

@google-cla

google-cla Bot commented Oct 31, 2026

Copy link
Copy Markdown

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@gmlewis

gmlewis commented Oct 31, 2026

Copy link
Copy Markdown
Collaborator

Hi @LemonCondor - thank you for your PR.

Unfortunately, this PR has two committers to it:

The following contributors were found for this pull request:

✅ 22a1fcc Author: @LemonCondor <yo12​@outlook.com>
❌ 22a1fcc Co-Author: <no
y​@anthropic.com>

and since anthropic is never going to sign the CLA, you have two options:

  1. rewrite this PR such that you are the only committer and then force-push to this PR
  2. close this PR, write a new one with only one committer and then open a new PR with that single committer

Sorry for the inconvenience.

@codecov

codecov Bot commented Oct 31, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.64%. Comparing base (64e5188) to head (e08f70d).
⚠️ Report is 18 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #4696      +/-   ##
==========================================
+ Coverage   98.63%   98.64%   +0.01%     
==========================================
  Files         201      203       +2     
  Lines       18912    19027     +115     
==========================================
+ Hits        18653    18769     +116     
+ Misses        259      258       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

EnterpriseService.AttachCodeSecurityConfigurationToRepositories and
OrganizationsService.AttachCodeSecurityConfigurationToRepositories
dereference resp.StatusCode when Do returns an error. Client.Do can
return a nil *Response together with a non-nil error (e.g. a transport
error or a canceled context), which makes these methods panic with a nil
pointer dereference instead of returning the error.

Add the `resp == nil ||` guard already used by the canonical form of this
pattern elsewhere in the package (e.g. AppsService.DeleteInstallation in
apps.go), and add regression tests that drive the Do-failure path with a
canceled context.
@LemonCondor
LemonCondor force-pushed the fix/codesec-attach-nil-resp branch from 22a1fcc to e08f70d Compare October 31, 2026 15:49
@gmlewis gmlewis changed the title Guard against nil response in code security attach methods feat: Guard against nil response in code security attach methods Oct 31, 2026
@gmlewis gmlewis added the NeedsReview PR is awaiting a review before merging. label Oct 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

NeedsReview PR is awaiting a review before merging.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants