Actual attack this time: A new type of supply-chain attack with serious consequences is flourishing: New dependency confusion attacks take aim at Microsoft, Amazon, Slack, Lyft, and Zillow by Dan G (Mar 6, 2021) ...
The goal of these attacks is to execute unauthorized code inside a target’s internal software build system. The technique works by uploading malicious packages to public code repositories and giving them a name that’s identical to a package stored in the target developer’s internal repository.
Developers’ software management apps often favor external code libraries over internal ones, so they download and use the malicious package rather than the trusted one. Alex Birsan [...] dubbed the new type of supply chain attack dependency confusion or namespace confusion because it relies of software dependencies with misleading names.
| [reply] [Watch: Dir/Any] |
Thanks interesting read!
Some thoughts from a Perl perspective (which wasn't mentioned)
- companies could restrict their proprietary modules to the same top-namespace like Apple::
- build systems could refuse to install from such private namespaces
- examples like My:: or Our:: come into mind as private by default
- CPAN could deny releases into "private namespaces" or similar
- another option for privacy could be leading underscores package _CompanyModule;
Disclaimer: I didn't thoroughly check if any of this is already done. But I found at least one module released under My::Object
| [reply] [Watch: Dir/Any] [d/l] [select] |
The simple approach is to run your own CPAN mirror and only import modules there that you have previously vetted.
Randomly pulling down packages from the internet is not a good strategy, no matter what assurances CPAN provides.
| [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |