Malicious Packages - they're gonna get ya!

The talk covers malicious dependencies, which are built to cause harm and often act the first time they run, unlike vulnerable ones. They live in public registries such as npm and PyPI and often target developer machines, where credentials and API keys sit in environment variables. Attackers hide code through encoding, obfuscation, blending into useful code, or nesting it as a subdependency. Vendor counts show rapid growth, though that vendor sells a product in this space.

Attacks are grouped by when they strike. Typosquatting is the most common tactic when adding a dependency, and slopsquatting exploits package names that AI assistants invent. For packages already in use, dependency confusion can substitute a public package for an internal one, and hijacking happens through expired domains or stolen credentials. Phishing also works: a popular linter was compromised after a maintainer took a phishing bait, and a Linux compression utility was backdoored after an attacker pressured its sole maintainer over three years.

Defenses include developer awareness, package name and history checks, and code scanning, though each has gaps. Software composition analysis tools mainly flag known vulnerabilities, often run too late to stop a malicious install, and may skip development dependencies. Endpoint detection can catch known behavior, private registries offer control if configured carefully, and newer services block packages flagged as malicious. The main takeaway is that no single control is enough, so teams should layer several defenses.