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 él y protegerlo de modificaciones.

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

  • Linting: El linting es el proceso de verificar el código fuente en busca de errores y problemas de estilo. Para ello, se usa 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 vulnerabilidades de seguridad.
  • Pruebas de seguridad de aplicaciones estáticas (SAST): Las SAST son un tipo de pruebas de seguridad que analizan 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 análisis de código puede usarse para identificar errores en las primeras etapas del proceso de desarrollo, el SAST puede usarse para encontrar vulnerabilidades antes de que se compile o implemente el código, y el análisis de licencias puede usarse para garantizar que la aplicación cumpla con las condiciones de las licencias.

Usar estas técnicas puede ayudar a mejorar la seguridad del código fuente y a 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 de aplicaciones estáticas
  • Análisis de licencias

Todas las herramientas y los comandos que se usan 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 consola de Google Cloud 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.

b35bf95b8bf3d5d8.pnga99b7ace416376c4.pngbd84a6d3004737c5.png

  • 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 usará 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.
  1. 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.

8560cc8d45e8c112.png

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

9e504cb98a6a8005.png

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

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 almacenar nuestro trabajo

mkdir -p workspace
cd workspace

Clona el repo 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 de código se usa para verificar errores o defectos comunes relacionados con la sintaxis. El análisis estático 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 intercambio de conocimientos y a la claridad del código.

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

Instala la herramienta de vinculación de staticcheck

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

Ejecuta el verificador 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, dado que 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 se encuentra debajo de LINTING - Step 1 dentro del método main() agregando barras diagonales iniciales(//).
  • Quita los marcadores de comentario de las dos líneas que se encuentran 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 devolver ningún resultado (es decir, una línea vacía).

Inspecciona el estado de salida del comando.

  echo $?

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

4. Pruebas de seguridad de aplicaciones estáticas

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

Instala la herramienta de 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. Análisis de licencias

Las licencias son importantes para la seguridad porque pueden exigirte legalmente que expongas el 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 las licencias "BSD-3-Clause".

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: Esta operación debería completarse 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

6. Felicitaciones

¡Felicitaciones! Completaste el codelab.

Qué aprendiste

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

—

Última actualización: 23/3/23