SBOM for Test

Подробнее о видео

The beauty of an SBOM is it captures the history of the code in a given module, so the buyer can find out which components came together to create the product. This will help find dependencies and particularly help protect against supply chain attacks. But there’s more that an SBOM can do. In particular, the SBOM could collect the test cases and maintenance history of a module so its subsequent owners or contributors can regression test the code, protecting against a future change breaking an already-resolved problem. Additionally, an SBOM could describe the environment in which the code was developed, the target operating environments in which it was validated, and any relevant documentation beyond what is already in the code itself to help future users or modifiers understand the original purpose and intent of the program.
This article suggests useful extensions to an SBOM to improve quality and ease of maintenance. During part of my time at IBM’s Poughkeepsie Programming Center, I ran the build and test team for the MVS operating system and key components. For each line of code we shipped, we created and archived four lines of test cases. The meant, for the MVS (now z/OS) the 1.5MLOC operating system brought along 6 million lines of test cases. Whenever a component was updated, we re-ran the entire regression test bucket to verify that stable functions were preserved. Because of automation, we staffed one tester for each five developers (a healthy ratio) and that gave us tremendous flexibility to cross-train productive engineers for backup and coverage.