Even if you did review it, a motivated attacker is not going to have an exfiltrate_user_data(). The xz backdoor exploit was incredibly sophisticated, and one key of the design was sneaking a "." into a single line of a build test script.
A cursory audit of primary dependencies has almost zero chance of catching anything but a brazen exploit.
Yeah. Realistically I think the best course of action is just assume you’re already using a library that can exfiltrate data.
This requires allowlisting egress traffic and possibly even architecting things to prevent any one library from seeing too many things. This approach can be a big pain though and could be difficult to implement practically.
Comments
I haven’t looked at the source code of a single npm package I’ve installed in the past 5 years.
“It takes a few minutes”
Dude my web dev projects have like 1,000s of dependencies. I’m not going to check the source code of every package tailwind requires.
Even if you did review it, a motivated attacker is not going to have an exfiltrate_user_data(). The xz backdoor exploit was incredibly sophisticated, and one key of the design was sneaking a "." into a single line of a build test script.
A cursory audit of primary dependencies has almost zero chance of catching anything but a brazen exploit.
Yeah. Realistically I think the best course of action is just assume you’re already using a library that can exfiltrate data.
This requires allowlisting egress traffic and possibly even architecting things to prevent any one library from seeing too many things. This approach can be a big pain though and could be difficult to implement practically.