In the development world, continuous integration is where members of a team integrate all their work frequently, for example, think of a team all working on the same code base, they are fixing bugs, implementing new features, so to prevent conflicts, all the code is merged together with automation.
For this use case, a free Singularity Container Services
account would be helpful, one click and you are done, and you get 11 GB for your images and 500 build time minutes. For more information, please see part 1 of the Singularity Container Workflow
. Upcoming releases will include a SBOM (Software Bill of Materials), this is an important contribution to security.
If you are not familiar with SBOM
, let me put it in simple words, it is a list of dependencies: modules, libraries and components required to either run or build a piece of software. Like the ingredients you read on a can of food, if you are allergic to some specific ingredient and you may want to stay away, the same happens with an SBOM, you will probably want to stay away from a flagged or vulnerable component. Some questions may arise, How is this collection built? Does it have a specific format? What kind and type of information contains?
There are many SBOM specifications, the most widely used today are SPDX
, CycloneDX being the format selected by default. And now, what can we do with an SBOM?, we can audit the components.
The tool of choice is Grype
, it is a vulnerability scanner for container images and filesystems, is very easy to use, has an extensive vulnerability database for many major linux operating systems including CentOS, Debian, Oracle Linux, Red Hat (RHEL), Ubuntu, and others, and also supports SIF images out of the box.
Build a SIF image and ensure security by documenting and analyzing packages and dependencies, for this, the following requirements are:
- GitHub public repository.
- A free Singularity Container Services account.
We will create a simple Hello World program in Go. Remember, this is a demonstration on how to build a Singularity image, generate a Software Bill of Materials (SBOM), and check to see if any of the software in our image has known vulnerabilities.
The structure of our source code is as follows: