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=~/devcluster/kube_config_cluster.yml

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

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.

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.

  - 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.
```
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
```
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 4 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.
Ahora vamos a analizar otro proyecto, pero utilizando python , para poder validar que sbom es un estandar para el cual se nos proveen herramientas para todos los lenguajes de programacion.

Primeramente vamos a crear otro proyecto como se hizo anteriormente , cambiando el nombre y de igual manera tomando el ID para subir el bom.

Luego en nuestro bastion vamos a clonar el repositorio.
```
git clone https://github.com/tiangolo/fastapi.git
cd fastapi
```

Vamos a crear un entorno virtual de python y vamos a instalar las dependencias de este proyecto.

virtualenv -p python3 .venv
source .venv/bin/activate
pip3 install cyclonedx-bom
pip3 install .

Con esto primeramente hemos instalado la herramienta de cyclonedx-bom para poder crear sboms y hemos instalado el proyecto, para poder analizarlo, lo cual haremos con el siguiente comando.
```
python3 -m cyclonedx_py requirements requirements.txt -o sbom-new.json
```

Ahora podemos subir este nuevo sbom al nuevo proyecto que se creo anteriormente.

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=@sbom-new.json" -k

Al ver el proyecto nos vamos a dar cuenta que tiene mas vulnerabilidades al ser un proyecto mas grande y que ademas tiene vulnerabilidades críticas, cuando el primer proyecto no tenía de esta misma índole.

Limpiamos el ambiente:

cd ~; rm-rf dtrack
helm uninstall dependency-track -n dependency-track