Código fuente seguro

1. Descripción general

Las técnicas de código fuente seguro son un conjunto de prácticas que pueden usarse 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 proteger el código fuente contra su modificación.

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

• Análisis con lint: Es el proceso de comprobar el código fuente en busca de errores o problemas de estilo. Para ello, se usa una herramienta lint, que es un programa que analiza el código fuente e identifica posibles problemas. Las herramientas de Lint se pueden usar para detectar una variedad de errores, incluidos errores de sintaxis, errores semánticos, errores de estilo y vulnerabilidades de seguridad.
• Pruebas de seguridad para aplicaciones estáticas (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 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 pueden usarse para mejorar la seguridad del código fuente en todas las etapas del ciclo de vida de desarrollo de software. El análisis con lint se puede usar para identificar errores de forma temprana en el proceso de desarrollo, SAST se puede usar para encontrar vulnerabilidades antes de que se compile o implemente el código, y se puede usar el análisis de licencias para garantizar que la aplicación cumpla con los términos de las licencias.

Usar 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

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

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

Todos los comandos y herramientas que se usarán 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 te importa qué es. En la mayoría de los codelabs, deberás hacer referencia al ID del proyecto (por lo general, se identifica como PROJECT_ID). Si no te gusta el ID generado, puedes generar otro aleatorio. También puedes probar el tuyo propio y ver si está disponible. No se puede cambiar después de este paso y se mantendrá mientras dure el proyecto.
• Para tu información, 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 ninguna otra persona puede usarlo después de seleccionarlo. Eres el único usuario de ese ID. Incluso si se borra un proyecto, el ID no se puede volver a usar.

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 te facture 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,

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

Configuración del entorno

Configura GOPATH en un solo directorio para simplificar los comandos utilizados en este lab.

export GOPATH=$HOME/gopath

Crea un directorio para guardar nuestro trabajo

mkdir -p workspace
cd workspace

Clona el repositorio del 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 o defectos comunes basados en el estilo 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 acelera las revisiones de código, el intercambio de conocimientos y la claridad del código.

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

Instala la herramienta de vinculación de staticcheck

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

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

 staticcheck

Revisa el resultado

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

El error se produce 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, dado que el comando dio como resultado un error, el estado de salida será 1 o superior. Este es un método que puede usarse 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(). Para ello, agrega barras diagonales iniciales(//).
• Quita el comentario de las dos líneas que están justo debajo de LINTING - Step 2 dentro del método main(). Para ello, quita las barras diagonales.

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

staticcheck

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

Revisa el estado de salida del comando.

  echo $?

En este caso, dado que el comando no dio como resultado un error, el estado de salida será cero.

4. Pruebas de seguridad para aplicaciones estáticas

Pruebas de seguridad AST/estáticas: Proporcionan 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íticas 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. Análisis de licencias

Las licencias son importantes para la seguridad porque pueden exigir legalmente que expongas código fuente que quizás no quieras exponer. El concepto se llama " copyleft" licencias 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 licencia con el archivo de política actual que no permite la "Cláusula BSD-3". licencias

golicense policies/license-policy.hcl hello-world

NOTA: Esto debería fallar y obtener 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 la "Cláusula BSD-3" 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 generarse correctamente 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 su uso en producción, estos comandos (y otras herramientas que se orientan al 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 de marzo de 2023