Software Bill-Of-Material, popularly known as SBOM, is becoming a prominent concept in the DevSecOps space, to ensure proper management of the components that make an application. The purpose of the SBOM is to document all the components involved in the creation of a given application, at the time of a build or during the packaging phase. It aims to comprehensively list all the artifacts, owned by the application itself or provided by an external application or a third-party entity.
Although the idea of having a full inventory of the artifacts of an application is not new, it gained more visibility after the discovery of the log4j vulnerability in 2021, which led to law enforcement offices caring about cybersecurity from different countries (starting with the United States and the United Kingdom).
Distributed applications already benefit from this capability, which more and more companies are now looking to implement for z/OS applications.
Leveraging the build information provided by IBM Dependency-Based Build (DBB)
IBM DBB can manage the build of z/OS applications with the help of the zAppBuild framework and can be easily integrated in a CI/CD pipeline. It can track the source files that were built, and more importantly, the dependencies that were pulled in for the build to succeed.
For each task performed, DBB produces a Build Report that contains all this information through specific records, thoroughly documented in the official DBB's documentation. Each build operation will provide the source files that were used, their original location in the z/OS system (could it be a zFS file or a member of a PDS), and the Git hash of the source file and its dependencies when they were pulled from a Git repository. Additional properties are also documented to ensure traceability. This information is leveraged in the packaging phase to extract the list of artifacts to be packaged for deployment.
Generating the SBOM file through the CI/CD pipeline
The PackageBuildOutputs.groovy script, available in the DBB GitHub repository, has been enhanced to support the generation of SBOM files. It will use the information collected from the Build Report, compute the necessary relationships between the documented artifacts, and create the SBOM file.
The created SBOM is based on the CycloneDX standard and specification. CycloneDX offers a comprehensive representation of the components and their dependencies, with associated metadata to describe how and when the package was created. To facilitate the generation of the SBOM, the PackageBuildOutputs script uses the CycloneDX Java library, which provides handy Java classes to forge and manipulate SBOM definitions.
This generation feature is enabled by passing the -s,--sbomGeneration flag when the PackageBuildOutputs script is invoked. Most of the processing is then performed by the sbomUtilities.groovy script, which contains methods called behind the scene by the PackageBuildOutputs script. An additional parameter -sa,--sbomAuthor is used to specify the author of the SBOM file. For traceability purposes, it is highly recommended to provide that information, even when the SBOM is generated as part of the pipeline processing. For instance, it could be the Release Manager or the Application Owner, that is specified for this field.
The core processing of this feature searches for the "deployable" artifacts, collects the list of source files that were used to build the artifacts, and documents these components and the relationships between each component. The end result is an SBOM file created in the temporary folder used for packaging all the deployable artifacts. This SBOM file is then packaged in a unique archive, ensuring the process is complete, the archive has not been tampered and its content is consistent with the SBOM definitions.
With the generation of the SBOM file, you can now extend best security practices to z/OS applications while building them through modern CI/CD pipelines. The composition of mainframe applications can now be tracked and audited with a toolset and practices common to all platforms!
Suman Gopinath, Senthil Nathan and Mathieu Dalbin