The npm CLI has a very convenient and well-known security feature – when installing an npm package, the CLI checks the package and all of its dependencies for well-known vulnerabilities – The check is triggered on package installation (when running npm install) but can also be triggered manually by running npm audit. This is an important security measure that warns developers against using packages with known vulnerabilities.
Similarly to our previous research on “Secrets Detection,” during the development and testing of JFrog Xray’s new “Contextual Analysis” feature, we wanted to test our detection in a large-scale real-world use case, both for eliminating bugs and testing the real-world viability of our current solution.
In this third post in our series on Malicious Software Packages, we’ll focus on the aftermath of a successful attack and how the attacker executes payloads to serve their needs through various real-life scenarios. Before we start, let’s review a few highlights from the second post you might’ve missed: Now, let’s get to blog three in the series.
Note: This report was previously published in InfoWorld When developing the recently announced JFrog Advanced Security, our Research team decided to try out its new “Secrets Detection” feature. Our goal was to test our vulnerability detection on as much real world data as possible, to make sure we eliminate false positives and catch any bugs in our code.
I was super excited to be at Kubecon+CloudNativeCon this year. Kubecon has managed to build a great community that goes beyond Kubernetes and has been a good catalyst in bringing together people passionate about OpenSource. Kubecon also has attracted a lot of interest due to the quality of sessions, the number of co-located events, and the opportunity to connect with peers, partners and friends.
On October 25th, The OpenSSL team announced that OpenSSL 3.0.7 will contain a fix for a critical severity vulnerability that affects OpenSSL 3.x. The full details about the vulnerability were held in an embargo until November 1st. Due to the rarity of an OpenSSL critical-severity issue and the overwhelming popularity of OpenSSL, social media was flooded with messages about this issue, expecting a “Log4Shell”-level event.
