Software bill-of-materials.
Developing and managing modern software is an increasingly complex task involving a multitude of tools, services, and dynamic supply chains. Lack of overall visibility into the composition of the software contributes to increased cybersecurity risks and costs for development and maintenance.
Transparency into the software composition and the SBOM (software bill-of-materials) is one first significant step to increase security and reduce risks and costs.
So, when and how do I create this SBOM?
a) When? Continuously for everything. SBOM-information should accompany all software you build, specifying the components, packages, libraries, etc. included in every unique version of the executable software.
b) How? Develop software that asks your build systems and creates reports with references to each build, respectively. Then, automate the process for consistency and correctness.
Ok, now I have an SBOM. What shall I do with it? Well, the SBOM is the necessary foundation for the following activities:
1) identify security issues regarding vulnerabilities and exploits.
2) verify license compliance.
3) check needs for updating & patching.
4) analyze the composition, do I have the right components, duplicates, unknown etc.
It is still a complex task: how can MAIA help?
MAIA is a software tool to enhance development flow, feedback, and control by cooperating with other existing tools. It is a database-backed web application accompanied by a number of components and services handling software integration, adaption, and communication.
The MAIA components, executing close to the Build systems, are searching for software dependencies and sending reports of all findings to the central MAIA service. The primary service is then creating an SBOM-report containing a list of all components and their current versions. The report is a part of the comprehensive build information page that is generated for all builds streaming through the system.
MAIA Example:
The list contains all external software found, each specified by a package url (type/namespace/name@version), i.e. example: pkg:npm/lodash/lodash@4.17.10. Each dependency also shows information about: software version status, discovered CVEs, licensing, usage and where it is used, i.e., a composite build may contain numerous sub-component builds. This list is the base for further investigation concerning vulnerabilities, compliance, and other potential problems like duplicates, packages in need for an update, suspicious software, etc.
