A quick introduction to SBOM

A software bill of materials is a list of all building blocks comprising an application – both the open source and commercial libraries. For each component, an SBOM provides all required details such as software version, author, and license type. This facilitates better governance and risk assessment of the application.

A year ago, the US government released an executive order (EO), making an SBOM a standard requirement for any organization doing business with it. Since then, SBOM has been getting increased attention, becoming a procurement process requirement.

SBOM for modern application governance

SBOM is especially useful when it comes to distributed cloud-native applications. It enables governing the application to make sure its usage is in accordance with relevant software licenses. 

Modern applications are usually based on microservices—distributed components, developed by disparate teams using various programming languages in multiple time zones and geographies. Each team, and sometimes each developer, has their preferred set of open source libraries. This makes application structure even more complex and difficult to manage. Having an up-to-date, automatically updated bill of materials allows such governance.

SBOM for application security

Today application security teams face constant challenges. Development pace is getting faster, the amount of code being pushed is much higher, and teams are working independently. Moreover, the definition of an “application” is becoming vague, as it’s no longer a single block of code running on a server, but rather a combination of cloud microservices. 

The first step to securing modern applications is to gain full visibility across all of their bits. 

This is where having a detailed SBOM for each application comes into play. It enables security teams to have a baseline and scope. It provides a clear definition of where the application starts and ends. Such an SBOM—which includes in-house components, dependencies, and third-party libraries—creates a definitive picture of the building blocks and their potential risk, thus permitting more efficient governance of an application security posture.

Oxeye inventory and SBOM security

Oxeye released the ‘Oxeye Inventory’ at the latest KubeCon conference. It provides a detailed runtime service inventory per each protected application. Based on Oxeye’s contextual risk assessment, this inventory includes a list of microservices and ancillary services within the application, the technology stack, its internet accessibility status, and the services’ calculated risk. Created by the Oxeye platform, such visibility joins the inner-connectivity mapping and flow tracing between application components, . A full SBOM is provided for each service that includes all details, e.g., author, supplier, version, license, known CVEs.

The Oxeye Inventory feature is superior to other SBOM-related tools by way of its following capabilities:

• Simple to use – No need to connect to your code repository; Oxeye performs its SBOM inventory directly on the deployed application
• The most trustworthy and accurate SBOM – It doesn’t merely report what should be in the application based on code repository access. Instead, Oxeye’s runtime inventory provides the most accurate and up-to-date SBOM, including any components created or added as part of your building and deployment process
• Contextual SBOM – Unlike other SBOM tools that generate long component lists without any context, Oxeye uses its deep knowledge of application structure and data flows to present your SBOM in its true context. Among other things, this makes your risk assessment more accurate and realistic. In addition, Oxeye flags internet-accessible services, thereby enabling smarter prioritization
• Application map – Oxeye provides a unique graphical representation of the SBOM through its application map. This lets users get a deep, unparalleled understanding of all of your application components and their function