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 a este y protegerlo de modificaciones.

Algunas técnicas comunes de código fuente seguro incluyen las siguientes:

• Análisis con lint: El análisis con lint es el proceso de verificar el código fuente para detectar errores y problemas de estilo. Se realiza con una herramienta de lint, que es un programa que analiza el código fuente y detecta posibles problemas. Las herramientas de lint se pueden usar para verificar una variedad de errores, incluidos los de sintaxis, semánticos, de estilo y las vulnerabilidades de seguridad.
• Pruebas estáticas de seguridad para aplicaciones (SAST): 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 los términos 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 análisis con lint se puede usar para identificar errores en las primeras etapas del proceso de desarrollo, 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 los términos de las licencias.

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

Qué aprenderás

Este lab se centrará en las herramientas y técnicas para proteger el código fuente del software.

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

Todas las herramientas y los comandos que se usan en este lab se realizará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 usa el mismo 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 del proyecto es único a nivel global y no lo puede usar nadie más después de que lo hayas seleccionado. 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 el proyecto completo. 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 Cloud Shell. Para acceder al editor,

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 un 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 ventana de terminal nueva.

Configuración del entorno

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

export GOPATH=$HOME/gopath

Crea un directorio para guardar 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 análisis con lint se usa para verificar errores comunes basados en el estilo o defectos relacionados con la sintaxis. El análisis con lint ayuda a la seguridad, ya que proporciona un patrón de sintaxis común en varios equipos que conduce a revisiones de código más rápidas, al uso compartido de conocimientos y a la claridad del código.

Además, el análisis con lint identifica errores de sintaxis comunes que pueden generar vulnerabilidades comunes, como el uso inadecuado 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 linter de Go (staticcheck) en el directorio raíz del proyecto.

 staticcheck

Revisa el resultado.

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

Recibes 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 que está debajo de LINTING - Step 1 dentro del método main(). Para ello, agrega barras diagonales iniciales(//).
• Quita los marcadores de comentario de las dos líneas que están directamente debajo de LINTING - Step 2 dentro del método main(). Para ello, quita las barras diagonales iniciales.

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 estáticas de seguridad para aplicaciones

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

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 problema potencial: Potential hardcoded credentials.

5. Análisis de licencias

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

Instala 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 licencia con el archivo de política actual que no permite licencias "BSD-3-Clause".

golicense policies/license-policy.hcl hello-world

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

 🚫 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: Esto debería tener éxito con un resultado similar al siguiente:

    ✅ 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 que segmentan el código fuente) deben incorporarse en 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