According to their recent announcement, the Open SSL project will release a new version of OpenSSL (version 3.0.7) on Tuesday, November 1, which will include a patch for a new, critical CVE.

Launching a vulnerability management program requires a few methodical steps When President Biden’s executive order shone a light on the need to modernize and strengthen cybersecurity at the federal level, that arguably lit a fire under private sector organizations to execute a vulnerability management program. No one denies the importance of a vulnerability management program to establish processes and controls to identify and remediate known vulnerabilities before they are exploited.

In a software-driven world, the number of newly discovered software vulnerabilities is constantly on the rise globally. Organizations rely on vulnerability scanners and Software Composition Analysis (SCA) tools to detect vulnerabilities in their software. But new research from Rezilion finds that relying on vulnerability scanners does not guarantee reliable results. In fact, our tests found mediocre accuracy in today’s most popular commercial and open-source scanning technologies.

The software supply chain has been in the news of late, and not for good reasons. Security incidents that have made headlines and led to costly damages have brought a lot of attention to this area. Perhaps the most noteworthy recent example of a vulnerability in the supply chain was the flaw with Apache Log4j discovered in late 2021. Logj4 is a Java package that’s located in the Java logging systems and is essentially a Java library for logging error messages in applications.

The CVE-2022-42889 that was dubbed as Text4Shell or ACT4Shell created a lot of noise on social media when it was published (on October 13th), mainly because of the comparison to Log4Shell. For those who are not familiar with Log4Shell and Spring4Shell you are welcome to visit our previous blog posts.

Organizations are facing significant challenges with vulnerabilities throughout the software development lifecycle (SDLC). Many still spend a lot of time to detect and prioritize one vulnerability in both development and production, indicating there is room for improvement in vulnerability management, according to a new survey from Ponemon Institute on behalf of Rezilion.

At the heart of having a successful vulnerability management program is alignment between development, security, and operations teams (dubbed DevSecOps) in being able to achieve both innovation and security when delivering products—the ultimate end game. This requires having a common set of goals. Without them, or if teams don’t communication well or collaborate, any DevSecOps initiative will all be for naught.

For many organizations, the process of managing software vulnerabilities is not working, and it’s failing to enable security teams to address the software flaws that can lead to major security attacks. A new study by independent research and education firm Ponemon Institute, based on a survey of 634 IT and security leaders, found that organizations are losing thousands of hours in time and productivity as they deal with a huge backlog of vulnerabilities.

Before diving into ProxyNotShell, we will start by giving some context regarding the original ProxyShell vulnerabilities. On BlackHat USA 2021, Orange Tsai (a 0-day researcher focusing on web/application security) revealed the three CVEs affecting Microsoft Exchange that chained together can result in arbitrary code execution on the server. They dubbed these vulnerabilities ProxyShell.

It’s that time of year again—Cybersecurity Awareness Month—when organizations around the country are reminded about what they should and should not be doing to better protect their data, applications and other IT resources against the latest attacks. In truth, no one should need a reminder of the need to provide robust cybersecurity.

The idea of using software bill of materials (SBOM) is catching on with organizations, according to a new survey from Ponemon Institute and Rezilion. But deploying an SBOM in and of itself does not guarantee success. Organizations need to move toward Dynamic SBOMs that use automated features in order to provide much greater value. An SBOM is a list of all the components in a given piece of software.

In the last decade, there has been an increasing focus on compliance and security. As a result, regulatory bodies have established severe penalties for non-compliance. Consequently, organizations put together compliance frameworks that are pertinent to their industry. To support such frameworks, security tool vendors have developed solutions to help these organizations easily automate security compliance.