Installing a Python package can execute code before the package is imported. A source distribution may need a build backend to create a wheel, and that backend can run build-time dependency code. pip's build isolation is designed to put those dependencies in a temporary environment. The setting changes which packages and files are available during the build, so it belongs in the security review of a dependency pipeline.
The default behavior is useful. pip creates a temporary build environment, installs the build requirements declared by the project, and makes that environment available to the build command. It does not mean the package is safe or that the resulting wheel has been reviewed. It defines a boundary around the build process and limits accidental reliance on packages already installed in the caller's environment.
Know when isolation is being disabled
pip allows --no-build-isolation. When that flag is used, the caller is responsible for managing build dependencies. Those dependencies may come from a developer virtual environment, a shared build image, or packages installed earlier in the same job. A package can then import a build helper that is present in the job but absent from its declared build requirements. The build may succeed while the actual environment is not reproducible.
Use build isolation by default for untrusted or third-party source distributions. If a package cannot build under isolation because it depends on a system compiler or a documented local tool, make the exception explicit. Pin the image, list the build requirements, and verify that the package's build configuration does not silently import unrelated packages. Review the exception whenever the package version changes.
Build dependencies are not covered by an application's runtime requirements file simply because the final wheel is pinned. A source distribution can request a different build backend or build requirement in its metadata. The dependency policy must cover those build inputs. If the environment has a private index, mirror, or proxy, configure it explicitly and check that the resolver cannot retrieve an unexpected package from a public index.
Use hashes and index policy together
Hash-checking mode verifies that downloaded requirements match expected hashes. When at least one requirement has a hash, pip requires hashes for the other requirements in that installation, which prevents a partially hashed set from being treated as complete. Generate hashes from reviewed artifacts and keep the requirements file under version control.
Hashes do not choose which index is trusted, and they do not prove that the package has no malicious code. They bind an installation to specific bytes. Pair them with a controlled index, package review, and a policy that rejects unexpected URLs. A package can be downloaded from a different index and fail the hash check, which is a useful failure. A build dependency that is not in the hashed requirements can still be fetched by the resolver, so include build inputs in the lock or use a wheelhouse that mirrors the reviewed set.
--only-binary :all: can avoid executing a source build when all required wheels are available. It is a useful policy for environments that should not run build backends. It does not make the package trusted, and it may be impossible for platforms where only source distributions exist. When source builds are necessary, isolate them from production credentials and use a disposable worker with a restricted network.
Observe the build process
Record the package name, version, source index, download URL, hash, build backend, build requirements, and wheel hash. The final wheel hash is often more useful for downstream deployment than the source hash alone, because the build can embed timestamps or platform-specific content. Keep both records when the build is not reproducible.
Run builds in a container or virtual environment with no access to production secrets. Mount only the source and the approved input cache. Restrict outbound network access to the package index and the compiler dependencies the project actually needs. Do not let a build step inherit cloud credentials through environment variables, metadata endpoints, or a Docker socket.
Test a package that requests an unexpected build dependency and confirm that the request is blocked or reviewed. Test a hash mismatch, a missing hash, and a lock file that points to a public package name while the internal index has a different package. These tests exercise the policy more directly than checking whether a normal package installs.
Build isolation is a small setting with a large influence on which code runs. The safer pipeline combines isolation, hash checking, explicit index policy, and a worker with minimal authority. Those controls do not guarantee that a dependency is benign, but they make the build inputs visible and keep a package's build script away from credentials it never needed.