Dependency intake is the point where a package is selected and admitted into a project, manifest, or build workflow. It is the trust boundary for third-party software: once a dependency is accepted, it can be pulled into CI/CD, cached in build systems, and inherited by downstream services. Security problems often start here, not during compilation, because a bad choice at intake becomes part of the software supply chain.
This stage matters because attackers can abuse it with typosquatted packages, malicious lookalikes, or unvetted versions, and AI tools can accelerate the mistake by suggesting package names or install commands that are copied without review. Defenders reduce risk by enforcing allowlists, approved registries, provenance and signature checks, internal package catalogs, and approval workflows before a dependency is allowed into the environment. The goal is to decide early what software is trusted, rather than trying to fix trust after the build has already consumed it.