Red Hat OpenShift is an enterprise Kubernetes container platform. It lets you build Docker images and use them to deploy your applications on a cloud-like environment (even if it’s not really on the cloud, rather a simulated cloud environment). Images built in OpenShift can be easily pushed into JFrog Artifactory – JFrog’s leading universal repository manager.
The JFrog Security Research team continuously monitors popular open-source software (OSS) repositories with our automated tooling, and reports any vulnerabilities or malicious packages discovered to repository maintainers and the wider community.
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.
Welcome to the second post in our series on Malicious Software Packages. This post focuses on the infection methods attackers use to spread malicious packages, and how the JFrog Security research team unveiled them.
Welcome to the first post of the malicious software packages series for the DevOps and DevSecOps community. Each Monday, this technical series will focus on various malicious packages and their effects on the software supply chain, all published over the next four weeks. We’ll dive deeper into malicious packages in each post, including Here we go. Let’s discuss malicious software packages in your software supply chain.
