Rezilion’s Dynamic SBOM is a first-of-its-kind technology that consolidates Windows and Linux software risk together in one UI. The Rezilion Windows SBOM helps teams efficiently manage software vulnerabilities and meet new regulatory standards for the 56% of software today that’s built for Windows OS.

Linux and Windows are a study in contrasts—the former operating system is open and users can easily copy and modify the code at will, while the latter is closed and proprietary. However, Windows is no longer the only game in town; increasingly, both are used in enterprises, which makes securing them a tall task. While many tools exist for organizations to manage vulnerabilities in their software, they tend to be OS-specific.

For many development organizations, Microsoft Windows remains the dominant operating platform. Therefore, ensuring the security of these systems needs to be a high priority for security leaders and teams and a Windows security guide can help. This is particularly true with the growing use of DevSecOps, a model in which security is accounted for at every stage of the software development lifecycle (SDLC).

Because Microsoft Windows is such a key component of so many enterprise and development environments, securing the platform is vital for ensuring efficient and secure software delivery. This can be a challenging process for many organizations. While many tools exist for organizations to manage vulnerabilities in their software, the vast majority of these were initially built for use with Linux OS, resulting in gaps in functionality when they’re used for Windows.

Today we’re excited to share that we’re expanding our Dynamic Software Bill of Materials (Dynamic SBOM) service to support Windows environments. In May of 2021, President Biden issued an Executive Order on Improving the Nation’s Cybersecurity. The objective of the order is to enhance the US government’s defenses in the wake of several high-profile breaches, including those that impacted SolarWinds and Kaseya.

When it comes to tools for generating a software bill of materials (SBOM), organizations basically have three options: use a software composition analysis (SCA) product, deploy an open source command-line interface (CLI) tool, or embrace new technology to find an altogether new solution. Whichever option an organization chooses can have a significant impact for its software security.

There has been a lot of tension building up since the announcement made by the OpenSSL project team last week (October 25th) regarding a security fix for a CRITICAL vulnerability in OpenSSL versions 3.x until today (November), when the information regarding the vulnerability has been made public. In the official security advisory released today by the OpenSSL project team, two different vulnerabilities were announced, none of which is critical: CVE-2022-3602 and CVE-2022-3786.