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 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.
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 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: