You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Severity: High in Docker mode (compensating control for Critical #3 root cause tracked in #26)
Evidence
All scoped variants declare timeOutInSeconds: 600: api/config.yaml:717 (wizcli_iac), api/config.yaml:791 (wizcli_sast), api/config.yaml:828 (wizcli_vulns); wizcli_secrets at api/config.yaml:573 is on the same profile.
Docker WaitContainer(timeOutInSeconds int) ignores the parameter and waits on ContainerWait(context.Background(), ...) at api/dockers/api.go:100. The K8s path does enforce TimeoutSeconds at api/kubernetes/api.go:198.
analyzeWizCLI recognizes ERROR_AUTH_WIZCLI and ERROR_RUNNING_WIZCLI_SCAN at api/securitytest/wizcli.go:128.
Impact
In Docker mode, a Wiz auth or cloud-scan hang can hold the scanner goroutine indefinitely and delay final analysis persistence. Until #26 (root fix) lands, there is no upper bound at all.
Recommendation
Wrap each wizcli auth … and wizcli scan dir ./code … invocation with the timeout shell builtin and a per-stage budget (suggested split of the 600 s envelope: ~120 s auth, ~420 s scan, leaving slack for clone + output handling). On timeout, emit the existing ERROR_AUTH_WIZCLI / ERROR_RUNNING_WIZCLI_SCAN sentinels so analyzeWizCLI already routes the failure correctly — no Go-side changes required.
Severity: High in Docker mode (compensating control for Critical #3 root cause tracked in #26)
Evidence
timeOutInSeconds: 600:api/config.yaml:717(wizcli_iac),api/config.yaml:791(wizcli_sast),api/config.yaml:828(wizcli_vulns);wizcli_secretsatapi/config.yaml:573is on the same profile.WaitContainer(timeOutInSeconds int)ignores the parameter and waits onContainerWait(context.Background(), ...)atapi/dockers/api.go:100. The K8s path does enforceTimeoutSecondsatapi/kubernetes/api.go:198.analyzeWizCLIrecognizesERROR_AUTH_WIZCLIandERROR_RUNNING_WIZCLI_SCANatapi/securitytest/wizcli.go:128.Impact
In Docker mode, a Wiz
author cloud-scan hang can hold the scanner goroutine indefinitely and delay final analysis persistence. Until #26 (root fix) lands, there is no upper bound at all.Recommendation
Wrap each
wizcli auth …andwizcli scan dir ./code …invocation with thetimeoutshell builtin and a per-stage budget (suggested split of the 600 s envelope: ~120 s auth, ~420 s scan, leaving slack for clone + output handling). On timeout, emit the existingERROR_AUTH_WIZCLI/ERROR_RUNNING_WIZCLI_SCANsentinels soanalyzeWizCLIalready routes the failure correctly — no Go-side changes required.Dependencies
cmdblocks — keep aligned with [34/48] Sparse-checkout shell logic duplicated across every scanner cmd block in config.yaml #44 (sparse-checkout duplication).Cross-references
docs/assessments/wizcli-performance-assessment-01.md— Confirmed finding Wiz - 'main' Branch Scan Overview #3, Probable chore: replace CI/CD with OSS-ready pipeline #7 (outage behavior).WaitContainertimeout dead), [34/48] Sparse-checkout shell logic duplicated across every scanner cmd block in config.yaml #44 (block-duplication risk).Verifiable by: Static analysis;
bash -non rewritten blocks; injection test that drops Wiz egress (also enables Issue Wiz-06/11).