Maintaining Open Source Singularity Since 2017

SCS Login

Software Supply Chain Security with Singularity Cloud Services

By Staff

Nov 15, 2022 | Blog, How To Guides

Bills of materials or BOMs are nothing new, but they are new in the software industry. They have been part of many supply chains for decades. When you purchase a car or a pharmaceutical device, the manufacturer of those products maintains a list of materials/ingredients and their respective suppliers. With this information the manufacturers have better control of product quality, and are able to respond to defects that might impact public safety. And this is how it applies to securing software supply chains. Advantages of including SBOM are numerous, to mention some:
  • Container producers can use SBOMs to document the contents of their work, and leverage automation to address the security, licensing and operational concerns connected with the use of open source software.
  • Consumers further down the supply chain can leverage SBOMs to gain insight into the software containers they rely on to proactively identify vulnerabilities and drive risk management processes.
  • Both producers and consumers can ensure compliance with emerging software supply chain guidelines, for example the May 2021 Executive Order on Improving the Nation’s Cybersecurity.
In a previous post, we detailed how Anchore and Sylabs collaborated to bring SBOM support to the Singularity Image Format (SIF). In particular, Anchore’s Syft and Grype tools were extended to have native support for SIF. With this work, Singularity users are able to generate SBOMs from SIF images, and start the process of improving the security of their HPC software supply chains. Now, Sylabs has made it easier than ever for HPC users to utilize SBOMs to improve the security of their workflows. The Remote Builder in Singularity Cloud Services (SCS) now automatically generates an SBOM and embeds it within the SIF image build artifacts created by the service. All of this is done without affecting container functionality. No changes are required to your definition files to have an SBOM automatically built by Remote Builder. Let’s build a SIF image using the updated Remote Builder in SCS and validate the SBOM contained within. The steps below assume you already have a free SCS account and have configured the access token in Singularity to allow remote builds. First, create a very simple definition file in which we add 2 common software components.
$ cat alpine-sbom.def 
bootstrap: docker
from: alpine:latest
 
%post
  apk update
  apk upgrade
  apk add curl vim

The build request can then be either submitted through the Singularity command-line or using the SCS web interface at https://cloud.sylabs.io.

Submit the remote build request using Singularity command-line:

$ singularity build --remote alpine-sbom.sif alpine-sbom.def
INFO:    Access Token Verified!
INFO:    Token stored in ...
INFO:    Remote "cloud.sylabs.io" now in use.
INFO:    Starting build...
Getting image source signatures
Copying blob sha256:213ec9aee27d8be...
Copying config sha256:29f453b10b9d6...
Writing manifest to image destination
Storing signatures
2022/11/10 20:42:37  info unpack layer: sha256:213ec9aee...
INFO:    Creating SIF file...
INFO:    Build complete: /tmp/image-286563138
INFO:    Performing post-build operations
INFO:    Generating SBOM for /tmp/image-286563138
INFO:    Adding SBOM to SIF
INFO:    Calculating SIF image checksum
INFO:    Uploading image to library...
WARNING: Skipping container verification
INFO:    Uploading 2801462 bytes
INFO:    Image uploaded successfully.
INFO:    Build complete: alpine-sbom.sif
List the headers of the SIF file:
$ singularity sif list alpine-sbom.sif 
---------------------------------------------------------------------
ID   |GROUP   |LINK    |SIF POSITION (start-end)  |TYPE
---------------------------------------------------------------------
1    |1       |NONE    |32176-32215               |Def.FILE
2    |1       |NONE    |32215-34126               |JSON.Generic
3    |1       |NONE    |34126-34221               |JSON.Generic
4    |1       |NONE    |36864-2764800             |FS (Squashfs/*Syste...
5    |1       |NONE    |2764800-2801462           |SBOM
Talking about security, questions arise:
  • Are there any known vulnerabilities in the image?
  • If there are known vulnerabilities, how severe are they?
  • What actions should I take (if any) to improve the security of my image?
Ideally, a container image is free of vulnerabilities the moment it is built, but we must also consider the lifespan of that container. Will it be kept for future scientific endeavors, who will run it, and how may this affect the security of their environment? As new vulnerabilities are discovered, how can we check for them in our container image? SBOMs allow users to continuously scan for known vulnerabilities in their containers, and take action when appropriate. Anchore’s grype is the perfect tool for directly scanning SIF images, here is an example on how to do that:
$ singularity sif dump 5 alpine-sbom.sif | grype
NAME  INSTALLED    FIXED-IN  TYPE  VULNERABILITY  SEVERITY 
vim   8.2.5000-r0            apk   CVE-2022-2816  High      
vim   8.2.5000-r0            apk   CVE-2022-2980  Medium    
vim   8.2.5000-r0            apk   CVE-2022-2522  High      
vim   8.2.5000-r0            apk   CVE-2022-2862  High      
...
vim   8.2.5000-r0            apk   CVE-2022-2000  High      
vim   8.2.5000-r0            apk   CVE-2022-2207  Critical  
vim   8.2.5000-r0            apk   CVE-2022-2819  High       
vim   8.2.5000-r0            apk   CVE-2022-2571  High           
xxd   8.2.5000-r0            apk   CVE-2022-2304  High      
xxd   8.2.5000-r0            apk   CVE-2022-2849  High      
...    
xxd   8.2.5000-r0            apk   CVE-2022-3153  Medium    
xxd   8.2.5000-r0            apk   CVE-2022-3235  High
Now the questions can be answered:
  • Are there any known vulnerabilities in the image?
    • Yes, there is at least one critical vulnerability.
  • If there are known vulnerabilities, how severe are they?
    • There are vulnerabilities on 2 packages classified in a range from medium to critical.
  • What actions should I take (if any) to improve the security of my image?
    • There are many options to choose from, it is more of a strategy answer rather than a technical one. Perhaps we don’t actually require the vulnerable component(s), and can simply remove them from our image. Perhaps we can update them to a patched version, or substitute with an alternative. Or perhaps, the risk is acceptable, given our use case.

Conclusion

The automatic inclusion of an SBOM within the Remote Build capabilities of Singularity Container Services helps researchers and developers build more secure HPC workflows. We’re excited to bring this functionality to Singularity Enterprise customers in the near future. With this new functionality, Sylabs continues to make progress towards making the deployment of performance intensive workloads simple, and more secure.

Join Our Mailing List

Categories

Related Posts

An Introduction to Singularity Containers

Mar 30, 2023 |

Enabling Portable and Secure Computing Environments for High-Performance Workloads.As part of their ongoing efforts to streamline workflows, enhance productivity, and save time, engineers, and developers in enterprises and high performance computing (HPC) focused...

read more

SingularityCE Now Available in EPEL

Dec 16, 2022 | ,

EPEL (Extra Packages for Enterprise Linux) is a repository of additional packages for Enterprise Linux, including Red Hat Enterprise Linux, AlmaLinux, Oracle Linux, Rocky Linux and others. By integrating SingularityCE with EPEL, starting with release 3.10.4, users may...

read more