A Beginner’s Guide to Using Software Bill of Materials with Singularity Container Services

By Staff

Jul 25, 2023 | How To Guides

Singularity Container Services (SCS) is a free offering from Sylabs that assists you with:

  • Keystore: This function allows you to store keys for signing images, proving your ownership over any image you sign.
  • Container Library: This is a full OCI compliant registry, enabling you to share your images with your partners and collaborators.
  • Remote Builder: This function lets you build an image in a safe, isolated environment using SingularityCE or SingularityPRO. It also allows you to get a Software Bill of Materials (SBOM) that’s embedded in the resulting SIF file.
In this guide, we’ll demonstrate how you can use an SBOM and how it’s included in your SIF file. This tutorial assumes that you have already installed the latest version of SingularityCE or SingularityPRO.
Step 1: Set Up an SCS Account

Go to Sylabs Cloud and click on the “Sign Up” button. Choose one of the four approved login providers, and voila! Your account is ready.

Step 2: Create an Access Token

After logging in to SCS, navigate to your profile menu on the right side and select “Access Tokens”. This will direct you to the keystore where you can generate your access token. This token enables interaction between SingularityCE or SingularityPRO and Singularity Container Services.

Step 3: Name Your Token

Type any name you wish for your token, and then click on the “Create Access Token” button. This will generate a token, which is a string of random characters and numbers. Remember to save this token somewhere safe, as it won’t be visible again. It will be valid for 30 days and will then be removed.

Step 4: Login to Singularity

Use the following command to login to SingularityCE or SingularityPRO:

singularity remote login
You’ll be prompted to paste the access token you generated earlier. After verification, the token will be stored in a file named remote.yaml in your home directory.
Generate an access token at https://cloud.sylabs.io/auth/tokens, and paste it here.
Token entered will be hidden for security.
Access Token: 
INFO:    Access Token Verified!
INFO:    Token stored in /home/USERNAME/.singularity/remote.yaml
Step 5: Define Your Container

We’ll use the example of containerizing RStudio. To do this, you need to create a definition file, RStudio.def, with the following content:

Bootstrap: library
From: ubuntu:22.04

%environment
    LANG=en_US.UTF-8    
    LC_ALL="en_US.UTF-8"
    export LANG
    export LC_ALL

%post
    export DEBIAN_FRONTEND=noninteractive
    export TZ=Etc/UTC
    apt update -qq
    apt install -y --no-install-recommends software-properties-common dirmngr wget locales
    wget -qO- \
         https://cloud.r-project.org/bin/linux/ubuntu/marutter_pubkey.asc | \
         tee -a /etc/apt/trusted.gpg.d/cran_ubuntu_key.asc
    add-apt-repository -y "deb https://cloud.r-project.org/bin/linux/ubuntu $(lsb_release -cs)-cran40/"
    apt install -y --no-install-recommends r-base r-base-dev
    wget -O /rstudio-2023.03.0-386-amd64.deb \
      https://download1.rstudio.org/electron/jammy/amd64/rstudio-2023.03.0-386-amd64.deb
    apt -y install /rstudio-2023.03.0-386-amd64.deb
    wget -O /rstudio-server-2023.03.0-386-amd64.deb \
     https://download2.rstudio.org/server/jammy/amd64/rstudio-server-2023.03.0-386-amd64.deb 
    apt install -y gdebi-core
    gdebi -n /rstudio-server-2023.03.0-386-amd64.deb
    # Log to stderr
    echo "[*]\nlog-level=error\nlogger-type=stderr\n" > /etc/rstudio/logging.conf
    # Setup the "general" CRAN repo
    echo 'local({
 r <- getOption("repos")
 r["CRAN"] = "https://cran.us.r-project.org"
 options(repos = r)
})' >> /etc/R/Rprofile.site

    # Prepare system to use UTF-8
    sed -i '/en_US.UTF-8/s/^# //g' /etc/locale.gen && locale-gen && update-locale
    # Remove unneeded source packages
    rm -f /rstudio*.deb

%runscript
    /usr/bin/rstudio "$@"

%startscript
    /usr/lib/rstudio-server/bin/rserver --server-user=$(whoami)"$@"
Step 6: Submit a Remote Build

With the definition file ready, you can submit a remote build as follows:

$ singularity build --remote RStudio.sif RStudio.def
SingularityCE and SingularityPRO will submit the definition file. If you want to modify this example and include your own files, ensure they are listed in the %files section of your definition file.

Building the image may take some time, so feel free to take a short break.

Once the image building process has finished, you can check if the SBOM was included:

$ singularity sif list RStudio.sif
The output is similar to this:
------------------------------------------------------------------------------
ID   |GROUP   |LINK    |SIF POSITION (start-end)  |TYPE
------------------------------------------------------------------------------
1    |1       |NONE    |32176-33818               |Def.FILE
2    |1       |NONE    |33818-36473               |JSON.Generic
3    |1       |NONE    |36473-36565               |JSON.Generic
4    |1       |NONE    |36864-633966592           |FS (Squashfs/*System/amd64)
5    |1       |NONE    |633966592-635124892       |SBOM (cyclonedx-json)
Step 7: Scan for Vulnerabilities

You can scan the built image for vulnerabilities using grype:

grype RStudio.sif 
The output will list any vulnerabilities found and their severity level (full list and detail of vulnerable packages are trimmed out for readability.)
✔ Vulnerability DB                [updated]  
 ✔ Parsed image                                sha256:2fbc391f50c2eaf639d056e13c06c0c460c854c843e3af038c77bb7102fc3358
 ✔ Cataloged packages              [428 packages]  
 ✔ Scanned for vulnerabilities     [249 vulnerabilities]  
   ├── 0 critical, 7 high, 103 medium, 109 low, 30 negligible
   └── 33 fixed
Understanding Vulnerability Severity

  • Critical: The highest level. Exploitation may compromise your software systems or infrastructure devices at the administration level.
  • High: These vulnerabilities could result in data loss, downtime, or elevated access to a system, although they’re typically difficult to exploit.
  • Medium: These vulnerabilities may require an attacker to persuade individuals (social engineering) or have local network access or limited user privileges.
  • Low: These vulnerabilities have minimal impact on the organization and often require local or physical access to the system.
The inclusion of an SBOM within the Remote Builder capabilities of Singularity Container Services and Singularity Enterprise can help researchers and developers build more secure HPC workflows. Enjoy safer computing!

Join Our Mailing List

Related Posts

SingularityCE Now Available in EPEL

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