Código fuente seguro

1. Descripción general

Las técnicas de código fuente seguro son un conjunto de prácticas que se pueden usar para mejorar la seguridad del código fuente. Estas técnicas pueden ayudar a identificar y corregir vulnerabilidades en el código fuente, evitar el acceso no autorizado al código fuente y protegerlo de modificaciones.

Estas son algunas técnicas comunes de código fuente seguro:

• Linting: Es el proceso de verificar si hay errores y problemas estilísticos en el código fuente. Para ello, se usa una herramienta de lint, que es un programa que analiza el código fuente y, luego, identifica posibles problemas. Las herramientas de lint se pueden usar para verificar una variedad de errores, incluidos errores de sintaxis, errores semánticos, errores de estilo y vulnerabilidades de seguridad.
• Pruebas de seguridad de aplicaciones estáticas (SAST): La SAST es un tipo de prueba de seguridad que analiza el código fuente, el código binario o el código de bytes para identificar vulnerabilidades de seguridad. Las herramientas de SAST se pueden usar para encontrar vulnerabilidades en una variedad de lenguajes de programación, incluidos Go, Java, Python, C++ y C#.
• Análisis de licencias: El análisis de licencias es el proceso de identificar las licencias de los componentes de software de terceros que se usan en una aplicación de software. Esto es importante porque ayuda a garantizar que la aplicación cumpla con las condiciones de las licencias, lo que puede ayudar a evitar problemas legales.

Estas técnicas se pueden usar para mejorar la seguridad del código fuente en todas las etapas del ciclo de vida del desarrollo de software. El linting se puede usar para identificar errores en las primeras etapas del proceso de desarrollo, la SAST se puede usar para encontrar vulnerabilidades antes de que se compile o implemente el código, y el análisis de licencias se puede usar para garantizar que la aplicación cumpla con las condiciones de las licencias.

El uso de estas técnicas puede ayudar a mejorar la seguridad del código fuente y reducir el riesgo de violaciones de la seguridad.

Qué aprenderás

En este lab, se enfocará en las herramientas y técnicas para proteger el código fuente de software.

• Análisis con lint
• Pruebas de seguridad de aplicaciones estáticas
• Escaneo de licencias

Todas las herramientas y los comandos que se usen en este lab se ejecutarán en Cloud Shell.

2. Configuración y requisitos

Cómo configurar el entorno a tu propio ritmo

1. Accede a Google Cloud Console y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.

• El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una cadena de caracteres que no se utiliza en las APIs de Google. Puedes actualizarla en cualquier momento.
• El ID del proyecto es único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). La consola de Cloud genera automáticamente una cadena única. Por lo general, no importa cuál sea. En la mayoría de los codelabs, deberás hacer referencia al ID del proyecto (suele identificarse como PROJECT_ID). Si no te gusta el ID que se generó, podrías generar otro aleatorio. También puedes probar uno propio y ver si está disponible. No se puede cambiar después de este paso y se mantendrá durante todo el proyecto.
• Recuerda que hay un tercer valor, un número de proyecto, que usan algunas APIs. Obtén más información sobre estos tres valores en la documentación.

Precaución: El ID de un proyecto es único a nivel global y no lo puede usar nadie más después de seleccionarlo. Eres el único usuario de ese ID. Incluso si se borra un proyecto, no se puede volver a usar el ID.

Nota: Si usas una cuenta de Gmail, puedes configurar la ubicación predeterminada como Sin organización. Si usas una cuenta de Google Workspace, elige una ubicación adecuada para tu organización.

2. A continuación, deberás habilitar la facturación en la consola de Cloud para usar las APIs o los recursos de Cloud. Ejecutar este codelab no debería costar mucho, tal vez nada. Para cerrar recursos y evitar que se generen cobros más allá de este instructivo, puedes borrar los recursos que creaste o borrar todo el proyecto. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de USD 300.

Inicia el editor de Cloud Shell

Este lab se diseñó y probó para usarse con el editor de Google Cloud Shell. Para acceder al editor, haz lo siguiente:

1. Accede a tu proyecto de Google en https://console.cloud.google.com.
2. En la esquina superior derecha, haz clic en el ícono del editor de Cloud Shell.

3. Se abrirá un panel nuevo en la parte inferior de la ventana.
4. Haz clic en el botón Abrir editor.

5. El editor se abrirá con un explorador a la derecha y el editor en el área central.
6. También debería haber un panel de terminal disponible en la parte inferior de la pantalla.
7. Si la terminal NO está abierta, usa la combinación de teclas "Ctrl + " para abrir una nueva ventana de terminal.

Configuración del entorno

Establece GOPATH en un solo directorio para simplificar los comandos que se usan en este lab.

export GOPATH=$HOME/gopath

Crea un directorio para contener nuestro trabajo

mkdir -p workspace
cd workspace

Clona el repositorio de código fuente

git clone https://gitlab.com/gcp-solutions-public/shift-left-security-workshop/source-code-lab.git
cd source-code-lab
export WORKDIR=$(pwd)

3. Análisis con lint

El lint se usa para verificar errores o defectos comunes basados en el estilo relacionados con la sintaxis. El linting ayuda a la seguridad, ya que proporciona un patrón de sintaxis común para varios equipos, lo que lleva a revisiones de código más rápidas, a compartir conocimiento y a la claridad del código.

Además, Linting identifica errores comunes de sintaxis que pueden generar vulnerabilidades comunes, como el uso incorrecto o menos eficiente de bibliotecas o APIs principales.

Instala la herramienta de vinculación staticcheck

 go get honnef.co/go/tools/cmd/staticcheck@latest

Ejecuta el lint de Go (staticcheck) en el directorio raíz del proyecto.

 staticcheck

Revisa el resultado

main.go:42:29: unnecessary use of fmt.Sprintf (S1039)

Se produce el error porque http.ListenAndServe() acepta una cadena, y el código actual usa Sprintf sin pasar variables a la cadena.

Revisa el estado de salida del comando.

echo $?

En este caso, como el comando generó un error, el estado de salida será 1 o superior. Este es un método que se puede usar en una canalización de CI/CD para determinar el éxito o el fracaso de la herramienta.

Edita el archivo main.go y corrige el código:

• Marca como comentario la línea debajo de LINTING - Step 1 dentro del método main() agregando barras diagonales iniciales(//).
• Quita las barras iniciales de las dos líneas que se encuentran debajo de LINTING - Step 2 dentro del método main() y, luego, quita los comentarios.

Vuelve a ejecutar staticcheck en el directorio raíz del proyecto.

staticcheck

El comando no debería mostrar ningún resultado (es decir, una línea vacía).

Inspecciona el estado de salida del comando.

  echo $?

En este caso, como el comando no generó un error, el estado de salida será cero.

4. Pruebas de seguridad de aplicaciones estáticas

AST/Pruebas de seguridad estáticas: Proporcionan un análisis de código estático en busca de debilidades y exposiciones comunes ( CWEs).

Instala la herramienta AST (gosec)

    export GOSEC_VERSION="2.15.0"
    curl -sfL https://raw.githubusercontent.com/securego/gosec/master/install.sh | \
          sh -s -- -b $(go env GOPATH)/bin v${GOSEC_VERSION}

Ejecuta gosec con el archivo de política en el código fuente

gosec -conf policies/gosec-policy.json -fmt=json ./...

El resultado debería ser similar al siguiente:

{
    "Golang errors": {},
    "Issues": [
        {
            "severity": "HIGH",
            "confidence": "LOW",
            "cwe": {
                "ID": "798",
                "URL": "https://cwe.mitre.org/data/definitions/798.html"
            },
            "rule_id": "G101",
            "details": "Potential hardcoded credentials",
            "file": "/home/random-user-here/shift-left-security-workshop/labs/source-code-lab/main.go",
            "code": "31: \t// STEP 2: Change this and the reference below to something different (ie, not \"pawsword\" or \"password\")\n32: \tvar pawsword = \"im-a-cute-puppy\"\n33: \tfmt.Println(\"Something a puppy would use: \", username, pawsword)\n",
            "line": "32",
            "column": "6"
        }
    ],
    "Stats": {
        "files": 1,
        "lines": 89,
        "nosec": 0,
        "found": 1
    }
}

La herramienta identificó un posible problema: Potential hardcoded credentials

5. Escaneo de licencias

Las licencias son importantes para la seguridad porque pueden exigirte legalmente que expongas código fuente que tal vez no quieras exponer. El concepto se denomina "licencias de copyleft", que requieren que expongas el código fuente si usas dependencias con esas licencias.

Instalar golicense

mkdir -p /tmp/golicense
wget -O /tmp/golicense/golicense.tar.gz https://github.com/mitchellh/golicense/releases/download/v0.2.0/golicense_0.2.0_linux_x86_64.tar.gz
pushd /tmp/golicense
tar -xzf golicense.tar.gz
chmod +x golicense
mv golicense $(go env GOPATH)/bin/golicense
popd

Compila el archivo binario

go build

Ejecuta la verificación de licencias con el archivo de política actual que no permite licencias "BSD de 3 cláusulas".

golicense policies/license-policy.hcl hello-world

NOTA: Esto debería fallar con un resultado similar:

 🚫 rsc.io/sampler    BSD 3-Clause "New" or "Revised" License
 🚫 rsc.io/quote      BSD 3-Clause "New" or "Revised" License
 🚫 golang.org/x/text BSD 3-Clause "New" or "Revised" License

Modifica el archivo de política policies/license-policy.hcl para mover "BSD-3-Clause" de la lista deny a la lista allow.

Vuelve a ejecutar la verificación de licencia

golicense policies/license-policy.hcl hello-world

NOTA: Se debería realizar correctamente con un resultado similar:

    ✅ rsc.io/quote      BSD 3-Clause "New" or "Revised" License
    ✅ rsc.io/sampler    BSD 3-Clause "New" or "Revised" License
    ✅ golang.org/x/text BSD 3-Clause "New" or "Revised" License

Para el uso en producción, estos comandos (y otras herramientas orientadas al código fuente) deben incorporarse a una canalización de CI/CD.

6. Felicitaciones

¡Felicitaciones! Completaste el codelab.

Qué aprendiste

• Herramientas y técnicas para proteger el código fuente

—

Última actualización: 23/3/23