Ayuda de Code Risk Analyzer

El mandato siguiente muestra la lista de mandatos de Code Risk Analyzer:

ibmcloud cra --help

Ayuda de mandatos de Code Risk Analyzer

El mandato siguiente muestra los detalles de los distintivos que se utilizan con un mandato. Utilice ibmcloud cra --help para visualizar los mandatos disponibles.

ibmcloud cra <command> --help

Requisitos de mandato de BOM

El mandato bom-generate depende de determinados mandatos externos:

• Si la vía de acceso contiene archivos Dockerfile, este mandato extrae imágenes base y crea imágenes para cada etapa de compilación en cada archivo Dockerfile. En este escenario, el mandato bom-generate requiere que los mandatos Docker cli y tar estén disponibles.
• Si la vía de acceso contiene archivos Maven, este mandato utiliza mvn para crear una lista de dependencias. En este escenario, el mandato bom-generate requiere que el mandato mvn esté disponible.
• Si la vía de acceso contiene archivos Gradle, este mandato utiliza gradle para crear una lista de dependencias. En este escenario, el mandato bom-generate requiere que el mandato gradle esté disponible.
• Si la vía de acceso contiene archivos Node.js package-json y este mandato se utiliza para generar un archivo package-lock.json correspondiente, el mandato bom-generate utiliza npm para crear el archivo package-lock.json. En este escenario, el mandato requiere que el mandato npm esté disponible.
• Si la ruta contiene los archivos Python requirements.txt o pyproject.toml, el comando utiliza pip para generar las dependencias del paquete. En este escenario, el comando bom-generate comando requiere que el comando pip esté disponible. Se da soporte a Python versión 2 y Python versión 3.

Si utiliza archivos Dockerfile, asegúrese de iniciar sesión en el registro de contenedor desde el que se extraerán las imágenes base.

Si el archivo Dockerfile requiere ARGS, establezca un ARG individual como una variable de entorno antes de ejecutar el mandato. Por ejemplo, si el archivo Dockerfile utiliza un ARG de IAM_USER, exporte una variable de entorno denominada IAM_USER: export IAM_USER='value'. La CLI pasa automáticamente estas variables de entorno al mandato docker build .

También puede especificar explícitamente el distintivo DOCKERBUILDFLAGS. Para exportar DOCKERBUILDFLAGS con el distintivo ARGS Docker, escriba el mandato siguiente:

export DOCKERBUILDFLAGS="--build-arg IAM_USER --build-arg API_KEY"

Opciones de mandato de BOM

La siguiente tabla enumera las opciones de comando que puede utilizar para generar una lista de materiales con el comando bom-generate.

Ignorar archivos

Si la vía de acceso contiene el archivo .cra/.fileignore, los archivos que se especifican en el archivo .fileignore no se exploran para las dependencias. El archivo .fileignore debe seguir las reglas de los archivos .gitignore. De forma similar a un archivo .gitignore, el archivo .fileignore puede incluir comentarios, directorios a ignorar, archivos a ignorar y otros patrones.

En el siguiente archivo .fileignore de ejemplo se muestra cómo excluir scripts bash, node_modules y Dockerfile.

# Ignore nested functional_tests directory
**/functional_tests

# Ignore bash scripts
**/*.sh

# This should allow this one file
!test/gatling_tests/loginTobx.sh

# Ignore node_modules
node_modules

# Exclude the dockerfile from scanning
Dockerfile

Configuración de múltiples contextos de construcción Docker

Cuando se trabaja con varios Dockerfiles dentro de un mismo proyecto, es posible que desee definir contextos de compilación independientes para cada Dockerfile. Esto puede lograrse utilizando un archivo .cra/.dockerbuildcontext, que es un archivo JSON que asigna rutas Dockerfile a sus correspondientes contextos de compilación.

Si existe un archivo .cra/.dockerbuildcontext en el directorio del proyecto, los comandos de compilación de CRA Docker utilizarán las rutas especificadas en este archivo como contextos de compilación para los archivos Docker asociados. Las claves del objeto JSON representan las rutas relativas a los archivos Docker, mientras que los valores especifican las rutas relativas a los respectivos contextos de compilación.

Este es un ejemplo de un archivo .dockerbuildcontext que define diferentes contextos de compilación para múltiples archivos Docker:

{
  "Dockerfile": "./",
  "path/to/different/Dockerfile": "./another/Path"
}

Ejemplo

Los siguientes fragmentos de código muestran cómo utilizar el mandato bom-generate:

ibmcloud cra bom-generate --path PATH --report REPORT [--asset-type ASSET-TYPE] [--dockerbuildcontext] [--dockerbuildflags DOCKERBUILDFLAGS] [--dockerfilepattern DOCKERFILEPATTERN] [--gradle.excludeconfigurations GRADLE.EXCLUDECONFIGURATIONS] [--maven.excludescopes MAVEN.EXCLUDESCOPES] [--nodejs.createpackagelock] [--prev-report PREV-REPORT] [--region REGION] [--toolchainid TOOLCHAINID] [--verbose]

ibmcloud cra bom --path . --report bomreport.json

Opciones de mandato de exploración de vulnerabilidades

La tabla siguiente lista las opciones para utilizar el mandato vulnerability-scan.

Ignorar vulnerabilidades

Si se especifica el parámetro -c o --cveignore, el mandato busca ese archivo y no informa de los CVE que se han especificado en el archivo. Puede configurar los CVE para omitirlos indefinidamente hasta que haya una remediación disponible, o hasta una fecha de caducidad especificada.

El ejemplo siguiente muestra un esquema JSON para el archivo .cveignore:

[
    {
        "cve": "string",
	    "alwaysOmit": "bool",
	    "untilRemediationAvailable": "bool",
	    "expiration": "string"
    }
]

Se da soporte a las siguientes propiedades para cada entrada del archivo .cveignore:

• cve - La vulnerabilidad que se va a omitir. El valor de esta propiedad es un ID de CVE.
• alwaysOmit - Si esta propiedad se establece en true, la vulnerabilidad se omite hasta que se cambia. Esta propiedad prevalece sobre otros valores de propiedad.
• untilRemediaciónDisponible - Si esta propiedad se establece en true, la vulnerabilidad se omite hasta que hay disponible una vía de remediación. Si hay disponible una corrección, la vulnerabilidad no se omite y se muestra un mensaje. Esta propiedad prevalece sobre el valor de propiedad de caducidad.
• Caducidad - Si esta propiedad se establece en true y no se alcanza la fecha de caducidad, se omite la vulnerabilidad. Si se alcanza la fecha de caducidad, la vulnerabilidad no se omite y se muestra un mensaje. Utilice el formato de hora RFC3339 (yyyy-MM-ddTHH:mm:ss[+-]Z) para definir esta propiedad.

Code Risk Analyzer solamente utiliza estas propiedades definidas. Puede añadir propiedades sin efecto en las funciones. Si no se omite una vulnerabilidad definida en .cveignore, se genera un registro que explica la razón. Si se omite una vulnerabilidad definida en el archivo .cveignore, no se visualiza ningún registro individual. Tras finalizar el informe, se registra la cantidad de omisiones y una lista de los ID de las vulnerabilidades, con el nombre del paquete, que se han omitido.

El siguiente fragmento de código muestra un archivo .cveignore de ejemplo:

[
    {
        "cve": "CVE-2021-27290",
        "alwaysOmit": true
    },
    {
        "cve": "CVE-2020-8244",
        "untilRemediationAvailable": true,
    }
]

Ejemplo

Los siguientes fragmentos de código muestran cómo utilizar el mandato vulnerability-scan:

ibmcloud cra vulnerability-scan --bom BOM [--cveignore CVEIGNORE] [--report REPORT] [--excludedev] [--include-nofix app,os,all,none] [--region REGION] [--strict] [--toolchainid TOOLCHAINID] [--output OUTPUTFILE]

ibmcloud cra cve --bom ./bom-file.json --cveignore ./cveignore-example.json --report ./output-vulnerability-report.json --excludedev --include-nofix all --strict

Opciones de mandato de despliegue

La tabla siguiente lista las opciones de mandato que puede utilizar para el mandato deployment-analyze.

Ejemplo

Los siguientes fragmentos de código muestran cómo utilizar el mandato deployment-analyze:

ibmcloud cra deployment-analyze --path PATH --report REPORT [--fileignore FILE_IGNORE] [--strict]

ibmcloud cra depl --path ./sampleDir --report deployment-report.json --strict

NetworkPolicy opciones del comando de análisis

La tabla siguiente lista las opciones de mandato que puede utilizar para el mandato netpol-analyze.

Ejemplo

Los siguientes fragmentos de código de ejemplo muestran cómo puede utilizar el comando netpol-analyze:

ibmcloud cra netpol-analyze --path PATH --report REPORT [--connectivity CONNFILE] [--lint LINTFILE] [--strict]

ibmcloud cra np --path ./sampleDir --report netpol-report.json --strict

Imagen del analizador de configuración de red

El comando netpol-analyze se ejecuta como parte de IBM 's Network Config Analyzer(NCA). Debido a que este comando ejecuta NCA como una imagen de Docker, debe instalar Docker en su ordenador.

La imagen URL para el analizador de políticas de red es icr.io/continuous-delivery/cra/nca.

Si la imagen del analizador aún no se encuentra en el registro local, el comando netpol-analyze extrae la última imagen del analizador (incluidas las correcciones de cualquier vulnerabilidad) de la página global IBM Cloud® Container Registry.

Scripts personalizados de ejemplo para DevSecOps

Si el archivo Dockerfile requiere ARGS, puede utilizar el parámetro cra-custom-script-path para establecer un ARG individual como una variable de entorno antes de ejecutar el mandato. La vía de acceso del script personalizado es la vía de acceso a un script que reside en el proyecto del usuario. Por ejemplo, si el archivo Dockerfile utiliza IAM_USER ARG, exporte una variable de entorno en el script denominado IAM_USER: export IAM_USER='value'. Si el ARG que necesita el archivo Dockerfile se establece como una propiedad de entorno en las cadenas de herramientas, puede utilizar get_env para obtener el valor. En esta instancia, puede exportar una variable de entorno dentro del script IAM_USER: export IAM_USER=$(get_env iam_user_environment_property_name). La tarea run-cra toma automáticamente estas variables de entorno y las pasa a los mandatos de compilación Docker.

El ejemplo siguiente muestra cómo utilizar cra-custom-script para exportar la variable ENV:

#!/usr/bin/env bash

if [[ "${PIPELINE_DEBUG:-0}" == 1 ]]; then
    trap env EXIT
    env | sort
    set -x
fi

export IAM_USER=$(get_env iam_user_environment_property_name)

También puede utilizar el parámetro cra-custom-script-path para escenarios en los que las versiones de la herramienta de imagen base de DevSecOps pueden estar obsoletas, basándose en el proyecto. Por ejemplo, puede actualizar mandatos como pip/pip3 para descubrir paquetes de Python que requieran una versión pip posterior.

El ejemplo siguiente muestra cómo utilizar cra-custom-script para actualizar la versión de pip:

#!/usr/bin/env bash

if [[ "${PIPELINE_DEBUG:-0}" == 1 ]]; then
    trap env EXIT
    env | sort
    set -x
fi

python3 -m pip install --upgrade pip

Si el archivo Dockerfile utiliza una imagen de un registro de Docker privado, puede utilizar el parámetro cra-custom-script-path para autenticarse en un registro de Docker privado antes de ejecutar Code Risk Analyzer y permitir que Code Risk Analyzer extraiga esta imagen para la exploración.

El ejemplo siguiente muestra cómo utilizar cra-custom-script para autenticarse en el registro de contenedor de ibmcloud:

#!/usr/bin/env bash

if [[ "${PIPELINE_DEBUG:-0}" == 1 ]]; then
    trap env EXIT
    env | sort
    set -x
fi

ibmcloud cr login

Depuración de Code Risk Analyzer en DevSecOps

Para ayudar con la depuración, puede ejecutar Code Risk Analyzer localmente como una interfaz de línea de mandatos (CLI) en su propia máquina local. Para obtener información sobre cómo ejecutar el comando ibmcloud cra bom-generate para generar una lista de materiales, consulte Lista de materiales(BOM). Después de generar la lista de materiales, utilice el comando ibmcloud cra cve para listar cualquier vulnerabilidad. Para obtener más información sobre la ejecución del mandato ibmcloud cra cve, consulte Exploración de vulnerabilidades.

Asegúrese de que la tarea run-cra no contenga ningún error. Si la tarea contiene errores, compruebe si la interconexión utiliza la versión actual de DevSecOps. Si el problema no se resuelve comprobando la versión de DevSecOps, los ejemplos siguientes proporcionan algunos errores comunes y soluciones propuestas.

FAILED
Error executing docker pull cmd: [docker pull us.icr.io/opentoolchain/ibmnode:14ubisecure]

Puede verificar que tiene acceso al registro privado. Si no tiene acceso, puede utilizar el parámetro cra-custom-script-path y especificar la vía de acceso a un script personalizado que se ejecuta antes de Code Risk Analyzer para autenticarse en el registro privado.

FAILED
Error executing docker build cmd for stage-0: exit status 1

Si el archivo Dockerfile requiere ARGS, el mandato docker build para las etapas de compilación no se puede compilar debido al ARGS que falta. cra-custom-script-path es necesario para configurar el ARGS como variables de entorno. Para obtener más información sobre cómo configurar el script personalizado, consulte Scripts personalizados de ejemplo para DevSecOps.

FAILED
Error executing docker build cmd for stage-0: exit status 1
...
COPY file-to-copy.js file-to-copy.js:
------
failed to compute cache key: "/file-to-copy.js" not found: not found

De forma predeterminada, el mandato bom-generate de Code Risk Analyzer crea los archivos Dockerfile desde el contexto de la ubicación del propio Dockerfile. Si desea crear los archivos Dockerfile desde el directorio del proyecto raíz, utilice el parámetro cra-docker-build-context para permitir que Code Risk Analyzer cree los archivos Dockerfile desde este contexto.

¿Cómo puedo determinar por qué ha fallado la CLI?

Antes de llamar a la CLI de Code Risk Analyzer, establezca la variable de entorno IBMCLOUD_TRACE en true para activar el registro de depuración.

export IBMCLOUD_TRACE=true

Observe las llamadas de API y las respuestas que se muestran en el registro para determinar la razón exacta del error.

¿Cómo puedo depurar un mandato de BOM que no puede extraer una imagen base de un registro privado?

Asegúrese de que se está autenticado con el registro en el que reside la imagen base utilizando el mandato ibmcloud cr login o el mandato docker login.

¿Cómo puedo depurar un mandato de BOM que no puede analizar un archivo Dockerfile?

• Verifique que el archivo Dockerfile no tenga problemas al ejecutar el mandato docker build y asegúrse de que lo pasa.
• Si el archivo Dockerfile requiere que se pase ARG, asegúrese de que el ARG esté establecido como una variable de entorno. También puede utilizar la variable de entorno DOCKERBUILDFLAG.
• Autentíquese con el registro que contiene las imágenes base.

Estoy viendo resultados falsos positivos inesperados. ¿Qué debo hacer?

Ejecute la canalización de implantación continua (CD) de DevSecOps para generar un SBOM actualizado en el armario de pruebas. Esto podría solucionar una posible causa de falsos positivos resultantes de la presencia de un SBOM más antiguo generado por el proceso de cumplimiento continuo (CC) de DevSecOps.

¿Por qué la gravedad del informe o problema es diferente de la del enlace de vulnerabilidad asociado?

Dado que nuestra fuente de información sobre vulnerabilidades ha cambiado recientemente, es posible que vea que la gravedad asociada a una vulnerabilidad concreta ha cambiado. Code Risk Analyzer determinará la gravedad óptima basándose en un cálculo de todas las fuentes de vulnerabilidades.