render-deploy

Download the file first, verify its integrity (checksum, signature), inspect it, then run it. Prefer package managers over raw downloads. Never fetch-and-run in one step.

Likely FP if the target is a well-known installer (e.g., rustup, Homebrew) from its canonical HTTPS domain, though the pattern is inherently risky.

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.

Pin the downloaded resource to a specific version or commit hash, and verify its integrity with a checksum (SHA-256). Avoid fetching scripts or binaries from arbitrary URLs at runtime.

Likely FP if the download URL points to a well-known CDN or package registry (e.g., npmjs.com, pypi.org) and is pinned to a specific version.

Replace conditional download-and-install logic with explicit dependency declarations in a manifest file (package.json, requirements.txt). Verify checksums for any runtime downloads.

Likely FP if the conditional install is documentation showing standard prerequisite checks (e.g., checking if a tool is installed before installing it).

Pin the curl/wget download to a specific URL with version and verify the downloaded file's SHA-256 checksum before using it. Prefer package manager installs over raw downloads.

Likely FP if the download is from a well-known canonical source (e.g., official GitHub release) and the documentation includes checksum verification steps.

Pin system packages to specific versions where the package manager supports it. Document the exact packages required and prefer containerized environments to avoid system-wide changes.

Likely FP if the match is standard setup documentation listing well-known system packages (e.g., apt install git curl) that are prerequisites.

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.

Replace GitHub raw.githubusercontent.com references with pinned commit SHAs instead of branch names (e.g., /commit-sha/file instead of /main/file). Branch references are mutable.

Likely FP if the raw GitHub URL points to a versioned release tag in a well-known repository, though even tags are technically mutable.

Change the MCP server URL to localhost or a trusted internal endpoint. If a remote server is required, verify the domain ownership and use HTTPS with certificate validation.

Likely FP if the URL points to example.com, a documentation domain, or a well-known SaaS API endpoint (e.g., api.openai.com).

Avoid loading configuration or behavior-controlling content from runtime URLs. Bundle required configurations locally or pin remote config to versioned, integrity-verified endpoints.

Likely FP if the URL in the match is a documentation link or example URL (e.g., example.com) rather than an actual runtime-fetched configuration endpoint.