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.

Trust should be earned, yet, too often, we place our trust blindly. Software is one such example. Attacks like SolarWinds, and the vulnerability discovered in the Log4j open source library should serve as the wake-up call for developers that the software supply chain is vulnerable. There are too many players in the open source supply chain, which has become increasingly interconnected and complex, and attackers are scarily good at finding openings in the nooks and crannies. Zero trust says no more.

Finding and fixing software vulnerabilities is one thing. Finding and fixing software vulnerabilities that actually pose a real threat to your organization and others is something else entirely. Not all vulnerabilities are equal in terms of potential impact on an organization. And the difference between addressing all bugs discovered verse only the genuinely risky ones is the amount of time, money and other resources security teams are spending in their vulnerability management endeavors.