gitops-workflow

Download the script first, inspect it, verify its checksum, then run it. Do not pipe curl/wget output directly to sh/bash. Prefer package manager installs.

Likely FP if the download is from a well-known installer domain (e.g., brew.sh, rustup.rs), though this pattern is inherently risky even with trusted sources.

Validate and sanitize all user-provided URLs before making server-side requests. Resolve DNS and verify the IP is not in a private range before connecting.

Likely FP if the URL fetch is for a well-known public API endpoint that is hardcoded (not user-controlled) in the tool configuration.

Validate and sanitize all user-provided URLs before making server-side requests. Resolve DNS and verify the IP is not in a private range before connecting.

Likely FP if the URL fetch is for a well-known public API endpoint that is hardcoded (not user-controlled) in the tool configuration.

Avoid depending on packages that could be subject to typosquatting or name confusion. Verify package ownership, check download counts, and audit the package source before adding dependencies.

Likely FP if the flagged package is a well-known, high-download-count package from a verified publisher.

Break chained commands into discrete, individually validated steps. Avoid piping untrusted output directly into a shell interpreter.

Likely FP if the matched text is a documentation example showing a common installer one-liner for a well-known tool with a canonical URL.