By now, it should be crystal clear that having a vulnerability management strategy is key to keeping your network safe from exploitations and ensuring it is compliant with regulatory requirements. In today’s fast-paced, IT-dependent business world, a strong vulnerability management program will detect, identify, rank, improve and remediate vulnerabilities found in software and networks. But not all programs are created equal.

The software development process is one with strict deadlines. The pace of innovation does not slow down. Because of this, developers often find themselves frustration as they try to ensure that the product they’re producing delivers on customer expectations, while also limiting vulnerabilities. The balancing act between product security and meeting the needs of a time crunch can lead to a product being rushed to the market, leaving it vulnerable to unpatched exploits.

A software bill of materials – or SBOM – plays an important role in providing much-needed visibility into the details of software components and the supply chain. As an SBOM is developed, it should adhere to a format or standard that defines a unified structure for how it will be generated and shared with customers.

In software development, workflow encompasses all the various steps that teams take throughout the development lifecycle—everything from planning and design to development, testing and release. From the standpoint of security teams, workflow means ensuring that security controls are built into code in order to keep the software secure. Workflow is what enables processes to run and what makes it possible for teams to complete their tasks and deliver products.

Dirty Cred are (now) two `use-after-free` privilege escalation vulnerabilities (CVE-2021-4154 and CVE-2022-2588) in the Linux kernel which can also be utilized for container escape. The CVE-2021-4154 exploitation was first presented at the Black Hat USA 2022 conference. The researchers demonstrated how the exploit can be used to escalate privileges from unprivileged user to privileged one (root) on Centos 8 and Ubuntu 20.04 machines.

The software supply chain is under attack, and never has it been more critical to secure it. In doing so, organizations will lessen the risk of a hacker’s ability to gain unauthorized access to development environments and infrastructure. This can include version control systems, artifact registries, open-source repositories, continuous integration pipelines, build servers, or application servers.

The software supply chain encompasses anything needed to develop and deliver a product, such as all the components, images, open source libraries, processes, and tools — so securing the supply chain must become a priority. Unfortunately, software supply chain attacks are one of the most pervasive threats that organizations face and they increased more than 300% in 2021, according to a study from Argon Security, part of Aqua Security.

The software bill of materials (SBOM) is becoming an increasingly important element in the software development lifecycle (SDLC). In fact, given the rising threats based on software vulnerabilities and the growing use of applications to run or support all kinds of business processes, any organization that’s not using SBOMs is putting itself at real risk. An SBOM is an extensive list of all the components contained in a given software product.

We are excited and proud to announce the release of Am I Exploitable? (MI-X), a tool that allows researchers and developers to know if their containers and hosts are impacted by specific, high-profile vulnerabilities. MI-X, developed by Rezilion’s vulnerability research team, made its debut this week at Black Hat Arsenal, and is now officially available as an open-source project.

While cybercriminals’ fashion taste (at least according to popular media), remains loyal to the good-old hoodie, their taste for vintage vulnerabilities is no different. Rezilion’s vulnerability research team explored the current attack surface for vulnerabilities discovered between 2010 to 2020, all appearing on the CISA Known Exploited Vulnerabilities list, and discovered that these known vulnerabilities, even ones dating back more than a decade to the past, are still extremely common.