Introducción a SBOM (Software Bill Of Materials)

Desarrollo del tema

A continuación se aborda la definicion y uso de SBOM a nivel general y como validarlo en un cluster de Kubernetes.

Que es SBOM

SBOM es una abreviacion de Software Bill of Materials, y en resumidos terminos se puede ver como una descripcion detallada de todos los componentes, modulos y dependencias de un software, visto desde un punto de vista cloud native, SBOM es una descripcion de los paquetes y dependencias que forman una imagen de contenedor.

Es un inventario que nos sirve para saber como esta conformada una aplicacion y como funciona. SBOM es utilizado principalmente para detectar vulnerabilidades a nivel de seguridad, si una vulnerabilidad es descubierta, se puede utilizar el SBOM para determinar que componentes han sido afectados.

Un SBOM nos ayuda a monitorear lo siguiente:

Codigo.
Imagenes de contenedor.
Binarios.
Paquetes.
Dependencias y dependencias transitorias.

Dependency Track

Dependency-Track es un una plataforma de analisis inteligente que permite analyzar, identificar y reducir riesgos en la cadena de suministro de software. Dependency-track puede ser desplegado de una infinidad de formas y en nuestro caso la desplegaremos en nuestro cluster de kubernetes.

Laboratorio: Introducción a SBOM (Software Bill Of Materials)

Descripción

La presente guía aborda la definicion y uso de SBOM a nivel general y como validarlo en un cluster de kubernetes.

Objetivos

Definir y entender a que se refiere cuando se habla de SBOM.
Conocer las diferentes herramientas para validar un SBOM.
Utilizar un aplicativo para validar un SBOM y como se debe de ver.

Antes de comenzar

Contar con el acceso al ambiente del laboratorio.

Conexión hacia cluster

Ingrese al cluster asignado con las credenciales proporcionadas.

Configure la variable KUBECONFIG.

export KUBECONFIG=~/rke2_conn/aio/aio_kubeconfig.yaml

Verifique el acceso mediante comandos.
```
kubectl get namespaces
```

Definir la variable para el wildcard de su ambiente, se encuentra en su inventario

CLUSTER_WILDCARD=apps.lab-0.k8s-seg-ar-190526.ws.itmlabs.io
#Ejemplo, cambiar por el suyo

Inicio de laboratorio

Como pasos previos vamos a instalar tanto java como maven.
```
sudo yum -y install maven java python3-pip
```

Agregue el repositorio a nivel del helm con el siguiente comando.

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
helm repo add evryfs-oss https://evryfs.github.io/helm-charts/

Instale dependency-track con el siguiente comando, asegurandose de cambiar el ingress por su wildcard correcto.

helm install dependency-track evryfs-oss/dependency-track   --namespace dependency-track   --create-namespace   --set ingress.enabled=true   --set ingress.tls.enabled=true   --set ingress.host=dtrack.$CLUSTER_WILDCARD --set  postgresql.enabled=false

Acto seguido vamos a editar el deployment de dependency track con el comando.

kubectl edit deployment dependency-track-apiserver -n dependency-track

Y vamos a editar el volumen de data quedando de la siguiente manera.

  volumes:
  - emptyDir: {}
    name: tmp
  - emptyDir: {}
    name: data

Probar el acceso a la consola web de dependency track ingresando al ingress creado. Una vez comprobado el acceso, se deben loguear con las credenciales por defecto.
```
kubectl get ingress -n dependency-track
```

Las credenciales a usar son

admin/admin

Luego de esto se les pedira cambiar la clave a una nueva.

Una vez logueados, vamos a crear un nuevo proyecto, colocarse en la parte de proyectos y crear uno nuevo de la siguiente manera.
Obtener el identificador a nivel de proyecto, entrando al proyecto y dandole click a la parte de view details, guardar este dato debido a que nos será de utilidad después.
En el menu del lado izquierdo, colocarse en la parte de administracion y luego en access management y teams. Crear un nuevo team llamado SBOM Uploader de la siguiente manera.

Tomar nota del API KEY.

Ahora crear una nueva carpeta llamada dtrack y colocarse en ella, en esta carpeta vamos a clonar el repositorio de dependency-track para analizarlo.

git clone https://github.com/DependencyTrack/dependency-track.git
cd dependency-track

Antes de crear el sbom hay que editar el archivo pom.xml y cambiar la version de rg.cyclonedx a 1.4

<plugin>
    <groupId>org.cyclonedx</groupId>
    <artifactId>cyclonedx-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>cyclonedx-aggregate</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>makeAggregateBom</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <projectType>application</projectType>
        <schemaVersion>1.4</schemaVersion>

Vamos a analizar nuestro repositorio y crear un archivo sbom a partir de este.
```
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom -DexcludeTestProject -DoutputFormat=xml
```
Este comando genera el bom en la carpeta target.

A este punto tenemos nuestro archivo bom, lo que haremos es mandarlo a nuestro dependency track para evaluarlo, lo haremos con el siguiente comando.

curl -X POST https://dtrack.$CLUSTER_WILDCARD/api/v1/bom   -H "Content-Type: multipart/form-data"   -H "X-API-Key: API-KEY"   -F "project=PROJECT_ID"   -F "bom=@target/bom.json" -k

Luego vamos a poder visualizarlo en dependency-track de la siguiente manera.
Podemos ver en el apartado de vulnerabilidades que tenemos vulnerabilidades, su severidad, CVE y mas detalles, con esto podemos darnos una idea de que es lo que utiliza nuestro proyecto, tanto directa como indirectamente, y de esta manera buscar una forma de minimizar estas vulnerabilidades.