Skip to content
This repository was archived by the owner on Jul 30, 2026. It is now read-only.
This repository was archived by the owner on Jul 30, 2026. It is now read-only.

[11/48] CONFIG: Wrap wizcli auth and wizcli scan with command-level timeout in all four WizCLI cmd blocks #65

Description

@anota-fernandocosta

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.

Dependencies

Cross-references

Verifiable by: Static analysis; bash -n on rewritten blocks; injection test that drops Wiz egress (also enables Issue Wiz-06/11).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions