frogbot can panic when JF_ALLOW_PARTIAL_RESULTS=true
A pull request for this has already been merged.
- #998 by @eranturgeman — merged
- Dominant language
- Go
- Stars
- 372
- Forks
- 107
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 5
Description
Describe the bug
While running a Frogbot scan (frogbot scan-pull-request), with environment variable JF_ALLOW_PARTIAL_RESULTS=true, frogbot panicked.
Possible fix: check for nil in scanpullrequest.go:
func filterJasResultsIfScanFailed(targetResult, sourceResult *results.TargetResults, scanType jasutils.JasScanType) {
+ // Guard against nil JasResults - if either source or target has nil JasResults, there's nothing to filter
+ if sourceResult.JasResults == nil || targetResult.JasResults == nil {
+ return
+ }
+
switch scanType {
case jasutils.Applicability:
if isJasScanFailedInSourceOrTarget(sourceResult.JasResults.ApplicabilityScanResults, targetResult.JasResults.ApplicabilityScanResults) {
log.Debug(fmt.Sprintf(vulnerabilitiesFilteringErrorMessage, scanType.String()))
sourceResult.JasResults.ApplicabilityScanResults = nil
}
Current behavior
While running a Frogbot scan (frogbot scan-pull-request), with environment variable JF_ALLOW_PARTIAL_RESULTS=true, frogbot panicked.
...
19:12:00 [Debug] [Thread 0] Skipping SCA for /tmp/jfrog.cli.temp.-1763146928-1759940729/modules/digicert_automation as no dependencies were found in the target
19:12:00 [Debug] Diff scan - converting to new issues...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x90 pc=0x11c38dc]
goroutine 1 [running]:
github.com/jfrog/frogbot/v2/scanpullrequest.filterJasResultsIfScanFailed(0xc002f66850, 0xc0003a2070, {0x172ca7e, 0xd})
/var/opt/jfrog/pipelines/data/release_frogbot/runs/5625032/steps/Release/40097658/dependencyState/resources/frogbotGit/scanpullrequest/scanpullrequest.go:323 +0xdc
github.com/jfrog/frogbot/v2/scanpullrequest.filterOutFailedScansIfAllowPartialResultsEnabled(0xc00017c200, 0xc00017c000, 0x1?)
/var/opt/jfrog/pipelines/data/release_frogbot/runs/5625032/steps/Release/40097658/dependencyState/resources/frogbotGit/scanpullrequest/scanpullrequest.go:312 +0xa7
github.com/jfrog/frogbot/v2/scanpullrequest.auditPullRequestSourceCode(0xc000484a08, 0xc000458d80, {0xc000036570, 0x2a}, {0xc000e88240, 0x29})
/var/opt/jfrog/pipelines/data/release_frogbot/runs/5625032/steps/Release/40097658/dependencyState/resources/frogbotGit/scanpullrequest/scanpullrequest.go:276 +0x3f9
github.com/jfrog/frogbot/v2/scanpullrequest.auditPullRequestCode(0xc000484a08, 0xc000458d80, {0xc000036570, 0x2a}, {0xc000e88240, 0x29})
/var/opt/jfrog/pipelines/data/release_frogbot/runs/5625032/steps/Release/40097658/dependencyState/resources/frogbotGit/scanpullrequest/scanpullrequest.go:240 +0x289
github.com/jfrog/frogbot/v2/scanpullrequest.auditPullRequestAndReport(0xc000484a08, {0x19b15c0?, 0xc0006d62d0?})
/var/opt/jfrog/pipelines/data/release_frogbot/runs/5625032/steps/Release/40097658/dependencyState/resources/frogbotGit/scanpullrequest/scanpullrequest.go:173 +0x26c
github.com/jfrog/frogbot/v2/scanpullrequest.scanPullRequest(0xc000484a08, {0x19b15c0, 0xc0006d62d0})
/var/opt/jfrog/pipelines/data/release_frogbot/runs/5625032/steps/Release/40097658/dependencyState/resources/frogbotGit/scanpullrequest/scanpullrequest.go:102 +0x330
github.com/jfrog/frogbot/v2/scanpullrequest.(*ScanPullRequestCmd).Run(0xc00049c4e0?, {0xc000484a08, 0x1, 0x1}, {0x19b15c0, 0xc0006d62d0}, 0xc0004a0840)
/var/opt/jfrog/pipelines/data/release_frogbot/runs/5625032/steps/Release/40097658/dependencyState/resources/frogbotGit/scanpullrequest/scanpullrequest.go:54 +0x2c6
main.Exec({0x198d340, 0x2cac020}, {0x173a398, 0x11})
/var/opt/jfrog/pipelines/data/release_frogbot/runs/5625032/steps/Release/40097658/dependencyState/resources/frogbotGit/commands.go:103 +0x45e
main.GetCommands.func1(0xc00043bbc0?)
/var/opt/jfrog/pipelines/data/release_frogbot/runs/5625032/steps/Release/40097658/dependencyState/resources/frogbotGit/commands.go:34 +0x2c
github.com/urfave/cli/v2.(*Command).Run(0xc000336580, 0xc00043bbc0, {0xc000465020, 0x1, 0x1})
/home/frogger/go/pkg/mod/github.com/urfave/cli/v2@v2.27.4/command.go:276 +0x7be
github.com/urfave/cli/v2.(*Command).Run(0xc000336c60, 0xc00043ba40, {0xc000032140, 0x2, 0x2})
/home/frogger/go/pkg/mod/github.com/urfave/cli/v2@v2.27.4/command.go:269 +0xa45
github.com/urfave/cli/v2.(*App).RunContext(0xc000384600, {0x1999210, 0x2cac020}, {0xc000032140, 0x2, 0x2})
/home/frogger/go/pkg/mod/github.com/urfave/cli/v2@v2.27.4/app.go:333 +0x5a5
github.com/urfave/cli/v2.(*App).Run(...)
/home/frogger/go/pkg/mod/github.com/urfave/cli/v2@v2.27.4/app.go:307
main.ExecMain()
/var/opt/jfrog/pipelines/data/release_frogbot/runs/5625032/steps/Release/40097658/dependencyState/resources/frogbotGit/main.go:25 +0x13b
main.main()
/var/opt/jfrog/pipelines/data/release_frogbot/runs/5625032/steps/Release/40097658/dependencyState/resources/frogbotGit/main.go:14 +0x18
...
Reproduction steps
export JF_ALLOW_PARTIAL_RESULTS=true- launch frogbot. (In this case, it was
frogbot scan-pull-requestin a repo of mine containing multiple python projects defined with requirements.txt files managed with pip)
Result: frogbot does its thing for a while, but then panicks after reporting [Debug] Diff scan - converting to new issues...
Expected behavior
frogbot should run without panicking
JFrog Frogbot version
2.29.1
Package manager info
multiple requirements.txt (pip).
Git provider
Bitbucket Server
JFrog Frogbot configuration yaml file
No response
Operating system type and version
linux
JFrog Xray version
3.107.11
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in scanpullrequest/scanpullrequest.go at filterJasResultsIfScanFailed, identified by the panic stack trace. Reproduce with JF_ALLOW_PARTIAL_RESULTS=true using frogbot scan-pull-request and the described Python projects, then verify the scan completes without a nil-pointer panic.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli, security
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100