Uso de Valint para aplicar políticas a su SDLC

Valint es la principal herramienta de Scribe para crear, gestionar, firmar y verificar pruebas. en un Publicación anterior, cubrimos la teoría del uso de evidencia de firma y verificación como herramienta principal para validar la seguridad de su canal de CI/CD. Como breve recordatorio, el modelo propuesto por Scribe incluye varios bloques de construcción que se pueden mezclar y apilar de cualquier forma que se adapte a sus necesidades. Los bloques de construcción incluyen la evidencia recopilada (SBOM, SLSA procedencia, cualquier resultado de prueba de terceros que desee incluir), el contexto ambiental de la evidencia recopilada (quién la creó, dónde, cuándo, etc.) y la política que desea aplicar a esa evidencia.

Como las políticas que desea aplicar a su evidencia son un factor clave en este modelo, pensamos en dedicar una publicación de blog a explorar el potencial del motor de políticas que ofrecemos con más detalle.

En este artículo, repasaremos la política más básica que ideamos (firmar y verificar información). Cubriremos cómo se ve la plantilla para una política más compleja y daremos algunos ejemplos estándar para políticas, como cómo verificar que un usuario específico fue el que creó la última rama "principal" o cómo verificar que su canalización se ejecute. incluye una prueba de herramienta de terceros que debe incluirse.

Comience aquí: firma y verificación de pruebas

valent es una herramienta muy versátil, pero para simplificar este artículo usaremos principalmente la interfaz CLI de Valint como ejemplo.

El primer paso sería descargar Valint:

curl -sSfL https://get.scribesecurity.com/install.sh | sh -s -- -t valint

El comando para crear un SBOM desde un repositorio o una imagen es 'bom'. Así, por ejemplo, si quieres bom la imagen de busybox:latest el comando se verá así:

$HOME/.scribe/bin/valint bom busybox:latest -o attest -f

Tenga en cuenta que attest es un alias para attest-cyclonedx-json.

De forma predeterminada, Valint está usando tienda de firmas flujo interactivo como motor detrás del mecanismo de firma integrado en la biblioteca Cocosign de Scribe. Esta biblioteca se ocupa de firmas digitales para firma y verificación. Una vez que aplique el comando, primero deberá aprobar que desea firmar la evidencia con una opción Y/[N]:

También puede utilizar PKI estándar para firmar (admitimos certificados x509). Existen múltiples opciones para almacenar la clave de firma, por ejemplo, KMS, almacén secreto de GitHub, y puede configurar fácilmente Valint para usar cualquier mecanismo de firma que desee.

Suponiendo que apruebe la firma, se le dirigirá a Sigstore en su navegador, donde deberá iniciar sesión utilizando su cuenta de GitHub, su cuenta de Google o su cuenta de Microsoft:

Una vez que haya iniciado sesión, verá que el inicio de sesión fue exitoso:

momento en el que puede cerrar el navegador y regresar a su shell donde podrá ver que la evidencia se creó correctamente.

La atestación se escribe de forma predeterminada en la caché local cuya ubicación la proporciona el --output-directory bandera en el archivo de configuración bandera. También puedes utilizar el -archivo de salida bandera para proporcionar una ruta personalizada para la atestación.

Ahora que hemos creado una declaración firmada, intentemos verificar que exista y esté firmada. El comando para verificar la evidencia es verify. La forma de utilizarlo es casi idéntica a la bom comando excepto que usaremos la bandera -ique es la abreviatura de --input-format y el valor predeterminado es, como en bom, attest-cyclonedx-json. El comando de verificación primero buscará la evidencia que necesita en la ubicación predeterminada utilizada por Valint. Puede especificar una ubicación diferente si desea guardar la evidencia y buscarla más tarde.

Entonces, si queremos verificar el busybox:latest atestación de imagen que hemos generado y firmado en el ejemplo anterior, el comando se verá así:

$HOME/.scribe/bin/valint verify busybox:latest -i attest

Suponiendo que hiciste todo bien, el resultado debería verse así:

Puede ver la lista de correos electrónicos que incluye el correo electrónico del firmante en la certificación original y también puede ver el tipo de certificación que se verificó, en este caso, cyclonedx-json. 

Parece bastante sencillo, ¿verdad? Vamos a darle un paso más.

Plantillas de políticas

A política consta de un conjunto de módulos. La política se verifica si se evalúan y verifican todos los módulos que incluye. Se verifica un módulo si se encuentra CUALQUIER evidencia que cumpla con la configuración y configuración del módulo.  

Las políticas se configuran como parte del archivo de configuración de Valint, en la sección de políticas. Este es un ejemplo de parte de un archivo de configuración de Valint, la parte que contiene políticas potenciales. 

Recuerde que no es necesario incluir un archivo de configuración en su proyecto: Valint puede funcionar bien solo con las opciones predeterminadas habilitadas. Además, dado que todo lo que contiene este archivo es opcional, es perfectamente válido tener un archivo que incluya SÓLO sus políticas. 

El archivo de configuración, llamado por defecto .valint.yaml, debe incluirse en la raíz de su repositorio. Según las políticas que incluya en este archivo, cuando ejecute el comando valint verify ejecutará cualquier política y módulo habilitado. Debido a que la política básica de 'verificar' es la predeterminada, no es necesario configurar nada para la verify comando para funcionar correctamente incluso sin un archivo .valint.yaml.

Cualquier política que agregue al archivo de configuración depende de tener evidencia que buscar. De forma predeterminada, cuando ejecuta el comando 'bom' en su canalización, la evidencia resultante se cargará en el almacén de evidencia de Scribe. De manera similar, cuando ejecute el comando 'verificar', buscará la evidencia en el almacén de evidencia de Scribe. Puede cambiar este valor predeterminado y usar un OCI o un caché como almacén de evidencia, pero para este artículo, asumiremos que se usa el valor predeterminado y que toda la evidencia se carga y extrae del almacén de evidencia de Scribe.

Entonces, basándonos en este ejemplo, veamos los componentes de una política. El política admite los siguientes campos:

• nombre , el nombre de la política (obligatorio).
• habilitar, habilite el módulo (el valor predeterminado es falso).
• módulos, lista de configuraciones del módulo de políticas.  

 

El sistema módulo Las secciones admiten los siguientes campos:

• nombre , el nombre del módulo de política (obligatorio).
• habilitar, habilite el módulo (el valor predeterminado es falso).
• tipo, tipo de módulo que actualmente soporta verificar-artefacto y propietario de git.
• partido, relacionar la evidencia con un contexto específico.
• Las opciones de entrada, configuración específica del módulo.

Una política puede tener varios módulos y todos los módulos habilitados se ejecutarán una vez que ejecute el comando 'verificar'. 

Como sé que una lista seca de campos no es muy informativa, profundicemos en la siguiente sección, políticas de muestra.

Políticas de muestra

Política de verificación de imágenes

Comencemos con la política más simple, una que expresa el flujo de verificación de signos de Valint. 

attest: cocosign: políticas: - nombre: verificar_policy habilitar: verdadero módulos: - nombre: firmado_sbom tipo: verificar-artifact habilitar: verdadero entrada: firmado: verdadero formato: attest-cyclonedx-json identidad: correos electrónicos: - barak@scribesecurity.com

Nuevamente, esta política debe incluirse en el archivo .valint.yaml en la raíz de su repositorio. Para que funcione necesitarás haber creado un SBOM firmado previamente ejecutando el valint bom dominio. Una vez que esté listo para verificarlo, deberá ejecutar el valint verify mando.

Al observar este ejemplo, podemos ver que la política está habilitada y que tiene un módulo de tipo habilitado ‘verify-artifact‘. El módulo comprueba que la entrada esté firmada, tenga formato ‘attest-cyclonedx-json’, y que estaba firmado por la identidad representada por el correo electrónico ‘barak@scribesecurity.com’.

Para ejecutar esta política necesitaremos ejecutar el verifycomando en nuestra canalización de esta manera:

valint verify busybox:latest

Puesto que el verify El comando ahora se basa en la política que proporcionamos y buscará una busybox:latest pieza de evidencia en su almacén de evidencia Scribe. Buscará un SBOM de formato firmado `cyclonedx-json` y verificaría que la identidad que firmó el SBOM utilice el correo electrónico prescrito en la política `barak@scribesecurity.com`.

Se podría decir que podría haber varias imágenes como esa en ese almacén de pruebas y estaría en lo cierto. Aquí es donde entra en juego el contexto. Por defecto, verify El comando buscará la coincidencia más cercana disponible. Sin embargo, puede especificar que el comando deberá coincidir con el contexto del ID de ejecución de la canalización o el sistema de compilación en el que se creó el artefacto. Para hacerlo, deberá utilizar el campo match: con el tipo de contexto apropiado. Por ejemplo:

            coincidencia: tipo_contexto: github git_url: github.com/my_org/myimage.git rama: principal

En este caso, la evidencia tuvo que haber sido generada por Github, por el repositorio nombrado por el git_url y por el main rama de ese repositorio. Es importante utilizar el contexto correcto cuando sea necesario para asegurarse de que sus políticas verifiquen exactamente lo que usted desea que verifiquen. 

Política de verificación binaria

Examinemos otro ejemplo. Esta política tiene como objetivo verificar que un archivo exe que estamos verificando provenga de un repositorio específico y esté firmado por una de varias personas conocidas. 

attest: cocosign: políticas: - nombre: verificar_policy habilitar: verdadero módulos: - nombre: binario_módulo tipo: verificar-artifact habilitar: verdadero entrada: firmado: verdadero formato: attest-cyclonedx-json identidad: correos electrónicos: - barak@scribesecurity.com - mikey@scribesecurity.com - adam@scribesecurity.com coincidencia: target_type: file context_type: azure git_url: https://dev.azure.com/mycompany/somerepo # URL de Git del entorno. nombre_entrada: my_binary.exe

Al observar este ejemplo, podemos ver que la política está habilitada y que tiene un módulo de tipo habilitado ‘verify-artifact‘ El módulo comprueba que la entrada esté firmada, que esté en formato ‘attest-cyclonedx-json’, y que fue firmado por 1 de 3 correos electrónicos permitidos enumerados en el módulo. Además, comprueba que el verify El comando recibe una entrada para verificar que la entrada se llama ‘my_binary.exe’, que la entrada es un archivo creado en Azure y que proviene de una URL de git específica: https://dev.azure.com/mycompany/somerepo.

Como puede ver, hay muchos más requisitos en este ejemplo para que se verifique la política.

Para ejecutar esta política necesitaremos ejecutar el verify comando en nuestra canalización de esta manera:

valint verify file:my_binary.exe

Para asegurarse de que su almacén de evidencia de Scribe tenga una versión firmada de este binario, primero debe crear la evidencia de esta manera:

valint bom file:my_binary.exe -o attest

Política de verificación de evidencia de terceros

En nuestro ejemplo final, veamos cómo podemos verificar que una herramienta de terceros que utilizamos se haya ejecutado correctamente en nuestra canalización y haya creado el resultado que esperamos en forma de un archivo JSON. 

attest: cocosign: políticas: - nombre: verificar_política habilitar: verdadero módulos: - nombre: tipo de regla de terceros: verificar-artefacto habilitar: verdadero entrada: firmado: falso formato: attest-identidad genérica: correos electrónicos: - bob@scribesecurity. coincidencia com: tipo_destino: tipo_contexto genérico: azure git_url: https://dev.azure.com/mycompany/somerepo git_branch: nombre_entrada principal: 3rd-party-scan.json

En este ejemplo, imaginamos que en algún momento del proceso, ejecutamos una herramienta de terceros que creó, como resultado, el archivo `3rd-party-scan.json`. Para cumplir con la política, ese archivo debería haberse originado en Azure DevOps, activado por el comando `https://dev.azure.com/mycompany/somerepo`repositorio y firmado por`bob@scribesecurity.com`. 

Para generar la evidencia que estamos buscando, justo después de ejecutar la herramienta de terceros, necesitamos capturar el archivo resultante y convertirlo en evidencia usando Valint:

valint bom 3rd-party-scan.json -o attest-generic --predicate-type https://scanner.com/scan_format

¿Qué prueba la evidencia? 

Hemos visto que podemos usar Valine para verificar varias cosas en nuestro proceso. ¿Para qué se puede utilizar realmente esta habilidad?

Imaginemos que nuestro oleoducto ha sido violado y que algunos tipos malos han comenzado a hacer cosas en él y en él que no queremos que hagan. Al verificar que los diferentes pasos del proceso se llevaron a cabo según lo esperado, produjeron los resultados esperados y fueron firmados por el personal aprobado, hacemos mucho más difícil que los malos nos engañen.

Un ataque potencial es reemplazar el archivo binario al final del proceso para que la versión que obtengan sus clientes sea maliciosa en lugar de la original. Al firmar su versión y pedir a sus clientes que la verifiquen con esa copia maestra, puede asegurarse de que todos usen el mismo archivo que usted produjo y no una falsificación inteligente.

Este modelo de crear evidencia y luego verificarla apenas está comenzando. Trabajamos constantemente para agregar capacidades adicionales a Valint para hacerlo aún más robusto y versátil. Mientras tanto, te animo a que consultes nuestro documentación para obtener más información sobre lo que Scribe tiene para ofrecer y qué más puede hacer con Valint. Valint se puede descargar y utilizar de forma gratuita, por lo que nada debería impedirte probar esta herramienta hoy.