HawkScan 6.0.0 — Standalone Binary, No Java Required

HawkScan 6.0.0 ships as a native binary. Java is now bundled in — you no longer need to install or manage a JDK or JRE on your machine or in your CI environment to run HawkScan.

On first run, hawk extracts a trimmed Java runtime and its supporting libraries into ~/.hawk/bin/ and launches normally. Subsequent runs skip straight to scanning — extraction only happens when you upgrade to a new version. The bundled runtime is entirely self-contained and won’t interfere with any JDK you already have installed.

What This Means for You

No Java prerequisite. Drop hawk into any machine or pipeline and run it. No JAVA_HOME setup, no version mismatch surprises, no java -version check before you get to work.

Simpler CI/CD. Remove any Java installation steps from your GitHub Actions, GitLab CI, or other pipeline configs. The hawk binary is the only thing you need.

Same install paths, same commands. Homebrew (brew install stackhawk/cli/hawk), the macOS PKG, the Windows MSI, and direct binary downloads all deliver the same self-contained executable. Nothing about how you invoke hawk changes.

Docker works the same way. The Docker container (stackhawk/hawkscan) continues to work as before. Internally it now uses the same binary approach — the Java runtime is pre-installed into ~/.hawk/bin/ at image build time rather than relying on a system JDK, keeping the container behavior consistent with local installs.

hawk op is now built in. Previously, StackHawk platform operations required a separately installed hawkop binary. Starting with 6.0.0, hawk op is fully integrated into hawk — no separate install, no separate binary to keep in sync. Because hawk op runs entirely in the Rust layer, it also launches instantly without waiting for the Java runtime to start.

OS-Native Certificate Trust

HawkScan now automatically trusts your operating system’s certificate store on every platform. This means it works out of the box behind transparent TLS-intercepting proxies — Zscaler, Netskope, corporate CAs, and similar tools — with no manual configuration.

The Rust launcher harvests OS root certificates and passes them to the scanner as an additive trust bundle. Your existing JDK truststore is preserved; OS roots are merged in on top. The net result: if your browser trusts a certificate, hawk does too.

This is enabled by default. To disable it (revert to bundled-roots-only behavior):

hawk scan --no-native-truststore
# or
USE_NATIVE_TRUSTSTORE=false hawk scan

hawk scan --no-native-truststore
# or
$env:USE_NATIVE_TRUSTSTORE = "false"; hawk scan

For proxies that require explicit configuration (username/password, NTLM, or a specific CA cert file), see Outbound Proxy Config Options in the CLI reference.

Non-Interactive Auth: hawk init --browser

hawk init now accepts a --browser flag for fully non-interactive device-flow authentication. When passed, it skips all TTY prompts — the existing-key confirmation dialog and the “log in via browser / enter key manually” menu — opens the browser immediately, and always prints the authentication URL to stdout so agents can capture and surface it.

hawk init --browser
# Open this URL to authenticate:
#   https://auth.stackhawk.com/activate?user_code=XXXX-XXXX

Without --browser, the interactive prompt remains unchanged: you’ll be asked whether to log in via browser or enter a key manually.

ZIP Distribution Removed

The hawk-{version}.zip download is no longer available as a distribution format. If you have pipelines or scripts that download the ZIP directly, migrate to the OS- and architecture-specific binary instead:

Binaries are available at https://download.stackhawk.com/hawk/{VERSION}/{PLATFORM}/hawk (Windows: hawk.exe). Use the platform identifiers from the table above for {PLATFORM}.