A Malicious Package != A Vulnerability! Served as a public service. A common misconception I often encounter is the treatment of a malicious package as if it were a vulnerability. This assumption is flawed for several reasons: 1️⃣ A malicious package does not necessarily indicate the presence of a vulnerability. 2️⃣ Unlike a vulnerability, which may arise from carelessness, lack of knowledge, or a logical flaw in the implementation, a malicious package requires malicious intent! 3️⃣ A malicious package usually contains a malicious payload, in a sense making it more akin to malware than a vulnerability. Therefore, if a malicious package is identified in your environment, you should assume compromise and initiate incident response protocols. Simply removing the malicious package after a compromise does not "fix" the problem! 4️⃣ It’s crucial to recognize that a malicious package is often just a symptom. The real threat is the malicious actor behind it. As an industry, our goal should be to stop these actors. Also note that there are different types of malicious packages: 💥 Packages originally created with malicious intent. Attackers may use techniques like typosquatting or spoofing reputation to deceive users into deploying these packages. 💥 Benign packages that become compromised at some point in their lifecycle, possibly by a "malicious" maintainer injecting harmful behavior into the source code or by an adversary compromising the software delivery lifecycle. A recent example is the latest xz attack. Lastly, be aware that there is currently a significant gap in the documentation and tracking of malicious packages. While CWE includes a category for Embedded Malicious Code (CWE-506), it is seldom used (only about 50 such cases are recorded in the NVD). Only a small fraction of malicious packages are assigned CVE IDs which means standard vulnerability scanners will fail to identify them. While IMO tracking these packages is essential, since we established that a malicious package differs fundamentally from a vulnerability, a CVE assignment isn't necessarily the answer (I'll expand on that in a different post). While last year alone over 250K malicious packages were identified, currently the most comprehensive data source for malicious packages is the OSV ‘-MAL’ index, which contains approximately 18,300 entries. #SoftwareSupplyChain #VulnerabilityManagement #RiskManagement #CyberSecurity
Abhisek Datta
8mo
OSV integration with package analysis malware data used to be a bit unpredictable. For example, OSV associates (correctly) vulnerabilities with a package version. However if I remember correctly, malware classification was on a package. This was a problem during the connect-kit malware incident. OSV data initially classified all versions of the package as malware and then removed the classification when the incident was contained since it’s a valid package. Tools, such as vet, which depend on OSV data for malware detection became unreliable. Not sure if there is any better source of reliable malware metadata for OSS packages
Love this. And it's a very important detail that we forget. There are good reasons that they have been treated as separate, but (since we are already doing some rethinking about vuln infrastructure) it might be worthwhile working through use cases where we would want them in the same bucket, and when we need them in separate buckets.
Luke Hinds
8mo
I would much rather take my chances with a vulnerability then a malicious package. Obviously there is some nuances involved, but a vuln is typically a bug introduced unwittingly by a developer, a malicious package is crafted with the intent to cause abuse. A vuln requires reachability and has to traverse boundaries, a malicious package just needs to be run.
Tony Turner
8mo
Just like a vulnerability is not an attack (unless it is intentionally inserted or exploited). We tend to confuse these things at times. Vulns are bad. Malware is really bad because it implies adversary action.
Tzachi Zornstain
8mo
This is what most CISO gets immediately Patch mangment isn’t the same process as Endpoint protection. And vulnerability isn’t the same as malware. You can’t update a breach .
Andrew Hendela
8mo
1000% this. There has been a huge focus on vulnerability analysis, and with very good reason. But a vulnerability is something that might be used by an attacker, a malicious behavior is already a problem once you run the software.
Great details. I love how you educate, guide and provide resources in one awesome “package”. 😄 There are many people that will benefit of your knowledge and willingness to share insights. Please keep it up!
Hayden Smith
8mo
Best meme I’ve seen in a minute
Idan Wiener
8mo
Amen! Yotam Perkal
CEO DecryptedTech LLC | Editor-in-Chief DecryptedTech.com Fractional CISO at Kavaliro Cybersecurity Consultant God Emperor of Dune
8moThe meme is funny I will grant that. However, (you knew there was going to be a however), malicious packages are often the result of a vulnerability or exposure in the repo and get used due to bad processes and lack of validation (also a vulnerability/exposure, just in process). In this context they become a component of the general supply chain vulnerability and exposure problem. We do not need to deconstruct everything. Context and attribution matters when talking about this kind of thing.