Guía práctica: 'Construir vs. comprar' tu conjunto de herramientas de escaneo de código OSS y seguridad de aplicaciones

Confía en sus habilidades de desarrollo —lo suficientemente como para saber que las aplicaciones que ha construido no están completamente libres de fallos de seguridad y configuración. También ha investigado el vasto ecosistema de herramientas de escaneo disponibles y quizás se sintió abrumado por la gran cantidad de opciones. ¿Cuál es el "portfolio" adecuado de herramientas de seguridad de aplicaciones de código abierto para identificar vulnerabilidades en sus dependencias, configuraciones de Infraestructura como Código (IaC), contenedores y más?

Para orientarte, cubriremos 10 categorías esenciales de escaneo de código y herramientas de seguridad, y recomendaremos 9 proyectos OSS, con la información esencial que necesitas para empezar:

• Cómo ese escaneo ayuda a la seguridad de tu aplicación.
• Qué proyecto de código abierto puede instalar y cómo ejecutarlo.
• Algunas alternativas (cuando estén disponibles) entre las que puedes elegir.

De esa manera, tendrás una vía directa y sin rodeos para escanear tus aplicaciones en busca de problemas de seguridad críticos en el código y en las configuraciones de la nube. ¿Qué más se puede pedir?

Bueno, la parte de configuración y gestión no es todo un camino de rosas, pero a eso llegaremos más tarde.

Lo que necesitarás

Solo tienes que traer tu estación de trabajo local, ya sea un ordenador de sobremesa o portátil, sin importar si utilizas macOS, Windows o Linux.

Un entorno de desarrollo es opcional pero recomendado. Para ejecutar este conjunto de herramientas de escaneo de código abierto, necesitarás instalar mucho software que quizás no quieras en tu sistema operativo base, lo que requeriría actualizaciones más grandes, contaminaría tu autocompletado y te ataría a herramientas específicas que podrían no funcionar en todos tus proyectos. Un entorno de desarrollo 'containeriza' y aísla, hasta cierto punto, todas tus herramientas específicas de desarrollo del resto de tu sistema operativo.

Afortunadamente, tienes algunas excelentes herramientas de código abierto para elegir:

1. Con Docker, puedes iniciar un nuevo contenedor básico llamado devenv-01 así: docker run --name devenv-01 -it ubuntu:24.04 sh
2. Con Daytona, que viene con muchas funcionalidades integradas para flujos de trabajo de desarrollo: daytona create --code
3. O con Distrobox, que incrusta cualquier distribución de Linux dentro de tu terminal, permitiéndote instalar software

Lo bueno de un entorno de desarrollo es que, una vez que has terminado con un 'stack' en particular, puedes eliminar el contenedor de forma segura sin afectar tu estación de trabajo.

#1: Gestión de la postura de seguridad en la nube (CSPM)

¿Cómo ayuda el CSPM a la seguridad de las aplicaciones?

CSPM le ayuda a mejorar la seguridad y el cumplimiento de sus entornos en la nube. Al monitorizar continuamente sus aplicaciones y sus servicios ascendentes frente a las mejores prácticas de la industria y sus políticas internas, las herramientas CSPM evalúan los problemas, los priorizan según su criticidad y ofrecen recomendaciones para su remediación. Con CSPM, usted asume una mayor responsabilidad sobre las líneas base y las salvaguardas que le impiden a usted o a otros promover aplicaciones vulnerables a producción, al tiempo que elimina configuraciones erróneas y roles de usuario excesivamente permisivos.

Instale y ejecute su proyecto CSPM de código abierto: CloudSploit

Para instalar CloudSploit, primero necesitarás Node.js para descargar sus dependencias y ejecutar el motor.

git clone https://github.com/aquasecurity/cloudsploit.git
cd cloudsploit
npm install

A continuación, debes configurar CloudSploit con permisos de lectura para tu cuenta en la nube, con soporte para AWS, Azure, GCP, y Oracle. Sigue las instrucciones de tu proveedor de la nube, utilizando el del repo config_example.js archivo como tu plantilla, para crear un config.js archivo con todos los detalles que necesitará para ejecutar su primer diagnóstico completo y obtener resultados en JSON.

./index.js --collection=file.json config.js

#2: Análisis de composición de software (SCA) de dependencias de código abierto

¿Cómo ayuda el SCA a la seguridad de las aplicaciones?

Sus aplicaciones inevitablemente tienen un gran árbol de dependencias de código abierto de las que ahora depende, desde su framework de UI hasta las librerías de ayuda que utiliza en una sola línea de código, como un validador de direcciones de correo electrónico. SCA es como una verificación de antecedentes de la familia extendida de su código, identificando problemas de vulnerabilidad de seguridad y licencias no una vez, sino de forma continua. Dado que sus herramientas SCA le notifican sobre nuevas vulnerabilidades y remediaciones, tendrá la confianza de que su cadena de suministro de código abierto sigue siendo una ayuda, no un obstáculo, para la productividad.

Instale y ejecute sus proyectos SCA de código abierto: Syft + Grype

Para el SCA de ejecución local, necesitará Syft para crear una lista de materiales de software (SBOM) y Grype para analizar dicho SBOM en busca de vulnerabilidades conocidas. Dado que el mismo equipo desarrolla Syft y Grype, soportan muchos métodos de instalación, pero recomiendan sus respectivos comandos de una línea:

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

Con Syft instalado en su estación de trabajo local, puede crear un SBOM para su contenedor, reemplazando <YOUR-IMAGE> con una imagen en un registro de contenedores configurado o en un directorio local.

syft <YOUR-IMAGE> -o syft-json=sbom.syft.json

Terminará con un/una sbom.syft.json en su directorio de trabajo, que luego puede introducir en Grype.

grype sbom:path/to/syft.json -o json

Grype luego imprime un resumen de vulnerabilidades en el formato siguiente, incluyendo detalles de severidad e información sobre soluciones conocidas, que puede utilizar para guiar su proceso de priorización y remediación.

{
"vulnerability": {
   ...
 },
"relatedVulnerabilities": [
   ...
 ],
"matchDetails": [
   ...
 ],
"artifact": {
   ...
 }
}

Alternativas y consideraciones

Trivy es una sólida alternativa de código abierto para SCA; no ofrecerá una paridad de características 1:1 en todos los aspectos, pero será más que suficiente para empezar.

#3: Detección de secretos

¿Cómo ayuda la detección de secretos a la seguridad de las aplicaciones?

Una herramienta de detección de secretos escanea su código y configuraciones en busca de credenciales que no desea exponer públicamente. Estos secretos pueden incluir claves de API, tokens de acceso a proveedores de terceros, contraseñas de bases de datos ascendentes, certificados, claves de cifrado y más, y una vez que se suben a un repositorio público, tendrá que pasar por un proceso doloroso para eliminarlos de su historial de Git; es mejor detectarlos a tiempo y tomar medidas antes de hacer commit.

Instale y ejecute su proyecto de detección de secretos de código abierto: Gitleaks

Gitleaks escanea tus repositorios en busca de la presencia de secretos codificados, pasados o presentes, analizando los registros de Git. detectar el comportamiento identifica secretos que ya han sido comprometidos, mientras que el proteger comportamiento escanea los cambios no confirmados para evitar que cometas errores desde el principio.

Para un control máximo, recomendamos instalar Gitleaks desde el código fuente.

git clone https://github.com/gitleaks/gitleaks.git
cd gitleaks
make build

La primera vez que ejecutes Gitleaks, puedes crear un informe de línea base para obtener resultados solo para la exposición de nuevos secretos.

gitleaks detect --report-path gitleaks-report.json

En invocaciones posteriores, debe hacer referencia a su gitleaks-report.json archivo para escanear los registros de Git en busca únicamente de secretos añadidos desde que creó su informe de línea base.

gitleaks detect --baseline-path gitleaks-report.json --report-path findings.json

Tu findings.json archivo contendrá detalles sobre el hash de commit y el autor de cada posible fuga, ayudándole a centrarse en las correcciones.

Alternativas y consideraciones

Desafortunadamente, no hay muchas opciones más allá de Gitleaks. Otros proyectos de detección de secretos de código abierto llevan años sin un último commit, lo que no es precisamente inspirador de confianza para proteger las aplicaciones en las que trabaja hoy. Si es un proveedor de servicios, puede registrarse en el programa de socios de escaneo de secretos de GitHub, que identifica cuándo sus usuarios suben accidentalmente sus formatos de tokens secretos a uno de sus repositorios.

#4: Pruebas de seguridad de aplicaciones estáticas (SAST)

¿Cómo ayuda SAST?

SAST es el peine de dientes finos de las herramientas de seguridad de aplicaciones, analizando tu código línea por línea para detectar sintaxis, estructura o lógica defectuosas que podrían dejar tu aplicación vulnerable. Piensa en ataques de inyección SQL, oportunidades de cross-site scripting (XSS), desbordamientos de búfer y más. Al verificar contra bases de datos populares de CVEs conocidos, una herramienta SAST robusta te dará la confianza de que no estás dejando grandes fallos de seguridad sin abordar, y algunas incluso ofrecen sugerencias de corrección para una remediación rápida.

Instala y ejecuta tu proyecto SAST de código abierto: Semgrep

Semgrep escanea tu código, encuentra errores y aplica estándares de código establecidos en cada invocación, con soporte para más de 30 lenguajes. Por simplicidad, nos centramos en Semgrep CLI, que es solo una parte de un complejo ecosistema de productos.

La forma más universal de instalar Semgrep CLI es con Python/pip.

python3 -m pip install semgrep

Realiza tu primer escaneo para crear un informe de fallos y vulnerabilidades a nivel de código como un archivo JSON.

semgrep scan --json --json-output=semgrep.json

Alternativas y consideraciones

El mundo SAST está repleto de oportunidades: si Semgrep no te funciona, echa un vistazo a algunas alternativas específicas de lenguaje como Bandit (Python), Gosec (Go) o Brakeman (Ruby on Rails) para empezar.

#5: Pruebas de seguridad de aplicaciones dinámicas (DAST)

¿Cómo ayuda DAST a la seguridad de las aplicaciones?

A diferencia de SAST, DAST simula vulnerabilidades comúnmente explotadas contra tu aplicación en un entorno en vivo. Se trata menos de la sintaxis y estructura del código que escribiste y mucho más de replicar los enfoques que un atacante podría emplear contra tu despliegue en producción. Las herramientas DAST verificarán CVEs conocidos en los frameworks y librerías que utilizas y probarán si los usuarios autenticados pueden acceder a datos sensibles debido a permisos rotos o a "combinaciones tóxicas" de múltiples vulnerabilidades que exponen tu aplicación a consecuencias mucho peores.

Instala y ejecuta tu proyecto DAST de código abierto: Nuclei

Nuclei es un escáner de vulnerabilidades impulsado por la comunidad que utiliza plantillas para enviar solicitudes a la aplicación que desea proteger, ejecutándose en un entorno local. Puede escribir plantillas personalizadas utilizando YAML, pero la comunidad de Nuclei también cuenta con una extensa biblioteca de plantillas preconfiguradas para probar su aplicación.

Necesita Go en su estación de trabajo local para instalar Nuclei.

go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

A partir de ahí, la forma más sencilla de ejecutar Nuclei es especificando un único objetivo —su aplicación ejecutándose localmente en un entorno de desarrollo— y aprovechando la biblioteca de plantillas, que Nuclei activa por defecto.

nuclei -u localhost:5678 -je nuclei-report.json

Alternativas y consideraciones

El Zed Attack Proxy (ZAP) es un escáner fantástico mantenido activamente por un equipo global de expertos en seguridad y desarrolladores. Sin embargo, a diferencia de otros en esta lista, ZAP es una aplicación gráfica por defecto. Existen opciones para usar tu terminal, pero no son precisamente las más amigables para desarrolladores en comparación con otros procesos que has seguido hasta ahora.

#6: Escaneo de infraestructura como código (IaC)

¿Cómo ayuda el escaneo IaC a la seguridad de las aplicaciones?

Tu código es solo la mitad de la ecuación para llegar a producción; hoy en día, la mayoría de los equipos utilizan herramientas IaC como Terraform, CloudFormation y los Helm charts "base" de Kubernetes para aprovisionar servicios en la nube de forma declarativa, controlada por versiones y repetible. Los escáneres IaC identifican vulnerabilidades en estos planos JSON o YAML para evitar que implementes un estado inseguro en producción.

Instala y ejecuta tu proyecto de escaneo IaC de código abierto: Checkov

Checkov escanea muchos tipos de código IaC —configuraciones de Terraform, gráficos de Helm, Dockerfiles y más— en busca de configuraciones erróneas comunes y posibles vulnerabilidades de seguridad. Con más de 1.000 comprobaciones de políticas integradas para AWS, GCP y Azure, la herramienta te ayuda rápidamente a comprender los riesgos y oportunidades actuales de tus despliegues en la nube en pocos minutos.

El equipo recomienda instalar Checkov localmente a través del gestor de paquetes de Python.

python -m pip install checkov

Entonces puede ejecutar Checkov en su directorio de trabajo (o en otro directorio donde haya almacenado archivos IaC) y obtener un archivo JSON como salida.

checkov --directory . -o json

#7: Escaneo de imágenes de contenedores

¿Cómo ayuda el escaneo de imágenes de contenedores a la seguridad de las aplicaciones?

Nos encantan los contenedores porque abstraen mucha complejidad, pero cada vez que construyes una imagen de contenedor, esta puede heredar vulnerabilidades de su imagen base o de las dependencias de paquetes. Los escáneres de imágenes de contenedor descubren vulnerabilidades en tus imágenes base y Dockerfiles, sin importar la profundidad del árbol de dependencias, para evitar que despliegues inadvertidamente una aplicación explotable.

Y así es también como nacieron las vulnerabilidades de las imágenes de contenedor.

Instala y ejecuta tu proyecto de escaneo de imágenes de contenedores de código abierto: Trivy

Trivy es un escáner de seguridad versátil capaz de analizar tus imágenes de contenedores en busca de vulnerabilidades conocidas con CVEs, problemas y configuraciones erróneas de IaC, la presencia de secretos y más. El equipo de Aqua Security, que está detrás del proyecto de código abierto Trivy, mantiene una base de datos pública de información sobre vulnerabilidades, recopilada de más de una docena de fuentes de datos.

En línea con los otros mecanismos de instalación recomendados hasta ahora, sugerimos usar el script de Trivy para instalar directamente desde la última versión de GitHub.

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.51.1

Por defecto, Trivy escanea imágenes de contenedores en busca de vulnerabilidades, configuraciones erróneas y secretos contra cualquier imagen de contenedor que especifiques, con resultados en formato JSON estándar.

trivy image --format json --output trivy-result.json <YOUR-IMAGE>

Alternativas y consideraciones

Si has estado siguiendo la guía, ya tienes Grype instalado en tu estación de trabajo local desde la sección anterior sobre SCA, y funciona muy bien para escanear imágenes de contenedores con un SBOM creado por Syft. Si estás en AWS, este es otro lugar donde Amazon Inspector puede resultar útil, matando dos pájaros de un tiro.

Amazon Inspector también es una opción, pero con dos grandes advertencias: primero, solo funciona con despliegues de AWS, y segundo, no es software de código abierto como el resto de nuestras recomendaciones, lo que significa que conlleva nuevos costes mensuales.

#8: Escaneo de licencias de código abierto

¿Cómo ayuda el escaneo de licencias de código abierto a la seguridad de las aplicaciones?

La legalidad del uso de software de código abierto en tus productos comerciales no es algo que revises una vez con los equipos legales o de cumplimiento y luego olvides. Los proyectos OSS cambian sus licencias con más frecuencia de lo que podrías imaginar, lo que te obliga a pagar por una versión empresarial, buscar una alternativa o liberar parte de tu código privado. Los escáneres de licencias identifican los cambios y te ayudan a superar las auditorías de seguridad con una lista de materiales de software (SBOM) lista para usar.

Instale y ejecute su proyecto OSS de escaneo de licencias: Syft

Al igual que con Grype en el paso anterior, ya tienes Syft instalado en tu estación de trabajo local e incluso podrías tener un SBOM existente de la configuración de tu integración SCA con Grype. Si aún no lo tienes, puedes crear rápidamente uno nuevo haciendo referencia a una imagen de contenedor desde un registro configurado o a una ruta en tu estación de trabajo local.

syft <YOUR-IMAGE> -o syft-json=sbom.syft.json
syft /path/to/image -o syft-json=sbom.syft.json

Dependiendo de la complejidad de tu imagen y la profundidad de las dependencias, podrías obtener un archivo SBOM de varios miles de líneas. Dentro de toda esa salida JSON, buscarás en el artefactos array para el licencias valores de cada paquete y dependencia de los que depende tu imagen de contenedor.

{
"artifacts":[
   {
"id":"cdd2655fffa41c69",
"name":"alpine-baselayout",
"version":"3.4.3-r2",
"type":"apk",
"foundBy":"apk-db-cataloger",
"locations":[
       …
     ],
"licenses":[
       {
"value":"GPL-2.0-only",
"spdxExpression":"GPL-2.0-only",
"Type":"declared",
         …

Con estos detalles en un único SBOM, podrás escanear tus obligaciones de licencia en busca de cambios que debas realizar en fases posteriores o migraciones para las que debas empezar a prepararte. También tendrás un recurso de referencia para la próxima auditoría de seguridad a la que te sometas.

Alternativas y consideraciones

Trivy, mencionado por primera vez en la sección anterior, tiene una funcionalidad de escaneo de licencias que te presenta resultados con criterio sobre el riesgo asociado a los proyectos en tu árbol de dependencias de código abierto.

#9: Detección de malware

¿Cómo ayuda la detección de malware a la seguridad de las aplicaciones?

Los escáneres de malware te ayudan a identificar una amenaza que ha cobrado fuerza en los últimos años: el malware inyectado en paquetes de dependencias por atacantes. El reciente intento de backdoor zx es un ejemplo fantástico —y aterrador—. Los escáneres de malware detectan estos ataques a la cadena de suministro de software incluso antes de que fusiones tu código para evitar que tengas que realizar correcciones urgentes y costosas una vez que la CVE se haga pública.

Instale y ejecute su proyecto OSS de detección de malware: Phylum

Las herramientas CLI de Phylum le permiten enviar sus archivos lockfile a su API para el análisis de dependencias, lo que difiere ligeramente de las otras herramientas de código abierto que recomendamos aquí: el análisis no se realiza en su estación de trabajo local. En su lugar, debe registrar una cuenta con Phylum para la autenticación con su servicio.

Empiece por instalar Phylum localmente.

curl https://sh.phylum.io | sh

Luego, registra tu cuenta y ejecuta tu primer análisis; Phylum debería identificar el lockfile que estás utilizando.

phylum auth register
phylum auth login
phylum init
phylum analyze --json

El análisis de Phylum proporciona un resultado exhaustivo, comenzando con un true o falso resultado basado en si tu proyecto pasa la verificación de malware de Phylum. En el array de rechazos para cada dependencia, encontrarás una descripción detallada de la vulnerabilidad y consejos de remediación de la comunidad OSS. Esto te permite agregar resultados de tus pruebas SAST, DAST y SCA, lo que te permite comprender qué vulnerabilidades se deben a tus dependencias y cuáles están incrustadas directamente en el código que escribiste.

{
"is_failure": true,
"incomplete_packages_count": 2,
"help": "...",
"dependencies": [
   {
"purl": "pkg:npm/next@13.5.6",
"registry": "npm",
"name": "next",
"version": "13.5.6",
"rejections": [
       {
"title": "next@13.5.6 is vulnerable to Next.js Server-Side Request Forgery",
"source": {
"type": "Issue",
"tag": "HV00003FBE",
"domain": "vulnerability",
"severity": "high",
         ...

#10: Detección de tiempo de ejecución de fin de vida útil (EOL)

¿Cómo ayuda la detección de tiempo de ejecución EOL a la seguridad de las aplicaciones?

Cuantos más frameworks, librerías y runtimes incluya en su aplicación, más oportunidades habrá de que se utilicen peligrosamente contra versiones obsoletas o dependencias sin mantenimiento. Esto es especialmente crítico para los runtimes directamente expuestos a internet público. Los detectores de runtimes EOL leen su árbol de dependencias a través de los lockfiles —incluso los de los contenedores— para alertarle con suficiente antelación y que pueda prepararse para actualizaciones o migraciones.

Instale y ejecute su proyecto OSS: endoflife.date

endoflife.date es una base de datos de información EOL sobre más de 300 herramientas y plataformas, muchas de las cuales son integrales para el funcionamiento y la seguridad de su aplicación. En lugar de tener que explorar sitios de documentación oscuros o rastrear listas de correo para descubrir cuándo una versión específica de su dependencia deja de recibir mantenimiento, puede establecer rápidamente fechas para las actualizaciones necesarias y priorizar sus esfuerzos futuros.

La forma más sencilla de descubrir datos de EOL es explorar el sitio, prestando especial atención a sus lenguajes de programación, bases de datos, frameworks, herramientas de despliegue y CLIs para servicios en la nube.

Como desarrollador, quizás desee un enfoque más centrado en la CLI para explorar datos de EOL de sus principales runtimes y librerías: endoflife.date dispone de una API sencilla que genera datos JSON, los cuales también puede añadir a un archivo local para futuras referencias.

curl --request GET \
 --url https://endoflife.date/api/nginx.json \
 --header 'Accept: application/json' \
>> eol.json

Un nuevo problema: Gestionar todos tus datos de escaneo de código y seguridad de aplicaciones

Si has seguido hasta aquí, has construido un práctico conjunto de herramientas de código abierto para el escaneo de código y configuraciones. Estás listo para ejecutarlas contra tus proyectos y ramas almacenados localmente para obtener garantías de seguridad pre-commit mucho mejores. ¡Toma eso, "shift left"!

Tu futuro, sin embargo, no es instantáneamente impecable. Este nuevo conjunto de herramientas viene con una gran advertencia: Tus herramientas no se comunican entre sí, y solo alrededor de tu aplicación.

Todavía tiene la obligación de:

1. Configure cada herramienta individualmente. Tomemos una opción sencilla, como una lista de permitidos (allowlist) de ciertos directorios o dependencias que no desea escanear, ya que no son relevantes para la seguridad de su entorno de producción. Deberá aprender los argumentos de cada herramienta CLI leyendo la documentación y realizando pruebas, lo que le roba un tiempo valioso de lo que realmente quiere hacer: implementar correcciones.
   
2. Ejecuta cada escáner en cada repositorio y rama. Incluso si tienes un único repo y dos ramas—principal y Desarrollo —eso son casi 20 operaciones para escanear en busca de vulnerabilidades. Idealmente, ejecutas estos escáneres antes de enviar cambios a un repositorio remoto, lo que significa muchas operaciones repetidas a lo largo del día.
   
   Hay algunas formas de simplificar esto, por supuesto. Puedes escribir un script para encadenar estos escáneres de código abierto y ejecutarlos manualmente o como un hook pre-commit de Git. Eso te ahorra tiempo en la terminal, pero solo genera la salida JSON más rápido; aún tienes la tarea de comprender ¿Qué?ha cambiado y si aún puedes subir tus cambios y (finalmente) crear tu pull request.
   
3. Examinar enormes arrays JSON en busca de información. Estas herramientas a menudo producen resultados de miles de líneas. La exhaustividad es buena, pero ¿quién tiene tiempo para explorar docenas o cientos de posibles problemas de seguridad, esperando comprender cada uno lo suficientemente bien como para entender su gravedad?
   
   Con el tiempo, necesitará una forma más intuitiva de leer los resultados que las líneas de JSON sin formato, como importarlos a Google Sheets o crear una aplicación sencilla para ver los resultados.
   
4. Comprende qué ha cambiado entre ejecuciones. El escaneo de seguridad tiene dos propósitos. Primero, ayudarte a identificar problemas existentes en tu código y configuración. Segundo, evitar que introduzcas nuevas vulnerabilidades a medida que desarrollas. Si no puedes entender rápidamente si has corregido una vulnerabilidad determinada o no se te notifica cuando una nueva se cuela en tu código, todo este esfuerzo es una pérdida de tiempo.
   
   Una opción es incrementar o marcar con fecha y hora sus archivos JSON de salida, y luego usar herramientas CLI para compararlos. diff file1.json file2.json es una excelente herramienta independiente, o puedes probar git diff --no-index file1.json file2.json para archivos no confirmados en tu repositorio Git.
   
5. Agregue, almacene y comparta datos para un análisis a largo plazo. Como hemos dicho antes, el escaneo de seguridad es una operación continua, no un elemento puntual en su lista de tareas pendientes. Además, los resultados de sus esfuerzos de escaneo no deberían quedarse encerrados en su estación de trabajo local; sus compañeros querrán conocer las vulnerabilidades más relevantes para lo que han construido, incluso si no tienen un conjunto de herramientas similar en funcionamiento en este momento.
   
   Tendrá que explorar plataformas de datos que reúnan toda esta información en un solo lugar, otra pieza de infraestructura para autoalojar o pagar.
   
6. Crear tickets en Jira o GitHub. Usted o un compañero debe escalar cada vulnerabilidad identificada a un ticket relevante que contenga todo el contexto necesario y posibles remediaciones. Esa es la única forma de garantizar la transparencia de la seguridad, lograr que sus compañeros colaboren y crear el registro de auditoría que sus estándares de cumplimiento puedan requerir. Ninguna de estas herramientas es compatible con la integración con su plataforma de tickets, por lo que tendrá que crear estos tickets manualmente, y podría haber docenas, si no cientos, por revisar.
   
7. Prioriza dichos tickets según la gravedad. Inundar tus repositorios con tickets es una pesadilla para la gestión de proyectos. Es una versión diferente, pero igualmente dolorosa, de la fatiga de alertas: ¿Cómo sabe alguien en qué centrarse primero? Si tus herramientas OSS no pueden ayudarte con la gravedad, tendrás que dedicar tiempo a hacer esas determinaciones tú mismo, lo que podría implicar años de conocimientos de seguridad que simplemente no puedes atajar.
   
8. Gestionar el ciclo de vida de cada herramienta OSS. Ya sea manteniendo sus herramientas actualizadas, intentando construir automatización o integrando ejecuciones y resultados en su pipeline de CI/CD, usted es ahora responsable de la eficacia a largo plazo de su conjunto de herramientas. Puede que tenga una postura de seguridad mejor que nunca, pero ¿a qué costo para su postura en el mundo real?
   
9. Preocúpese y pregúntese qué sucede si el proyecto pierde a su mantenedor. Si sus dependencias y entornos de ejecución pueden llegar al fin de su vida útil (EOL) y generar problemas, también pueden hacerlo las herramientas y plataformas de las que depende su entorno de desarrollo local. Desafortunadamente, los proyectos de código abierto a menudo se basan en modelos de financiación y mantenimiento que no son sostenibles a largo plazo. Todavía puede usar proyectos estancados o abandonados en su CLI, pero al intentar mejorar la seguridad de su aplicación, no le ayudarán a descubrir nuevas vulnerabilidades o métodos de ataque.

La conversación actual en las herramientas para desarrolladores gira en torno a un único concepto: la experiencia del desarrollador (DX). Cuanto mejor sea la DX, más probable será que una herramienta sea integrada, utilizada, valorada y defendida. Y seamos honestos: la DX de este kit de herramientas de escaneo OSS ejecutado localmente no es particularmente buena. Usted es el propietario total de su proceso y sus datos, pero con costes y una dedicación de tiempo excepcionales. ¿Cuánto está dispuesto a pagar por una seguridad de aplicaciones avanzada?

Las herramientas de seguridad de código abierto son increíbles —incluso hemos creado un firewall de aplicaciones web para proteger de forma autónoma las aplicaciones Node.js contra ataques comunes y críticos—, pero para el escaneo de seguridad continuo y la remediación de vulnerabilidades, tiene que haber otra forma. Quizás incluso una que se construya sobre esta fantástica base OSS.

Una nueva solución de seguridad de aplicaciones: Aikido

Aikido reemplaza todas esas soluciones puntuales de código abierto con una plataforma de seguridad integral.

En lugar de ejecutar más de 10 herramientas cada vez que te preparas para confirmar tus últimos cambios, solo necesitas añadir tus repositorios, imágenes Docker y proveedores de la nube a Aikido una sola vez para un escaneo completo. Aikido se ejecuta automáticamente en segundo plano para un escaneo continuo o en tu pipeline de CI/CD para recomendaciones específicas con cada pull request, protegiéndote de nuevas vulnerabilidades mientras señala las existentes que han estado latentes en tu base de código durante meses o años.

Mejor aún, todos los resultados, el contexto y las posibles remediaciones se agregan y almacenan en un único lugar —el dashboard de Aikido— para que nunca tengas que preocuparte por analizar JSON, fusionar múltiples fuentes de datos o gastar en una costosa plataforma de gestión de datos para crear una fuente de verdad. Incluso hemos creado reglas personalizadas y un 'pegamento' especial entre estos proyectos de código abierto para desenterrar correlaciones y resultados que de otro modo requerirían un investigador de seguridad especializado interno.

Aikido también se integra con tus plataformas de gestión de tareas y mensajería, como GitHub y Slack, para crear tickets pre-triados y pre-priorizados. Con todo el contexto, la documentación y los autofixes sugeridos, cualquier miembro de tu equipo puede abordar el problema y llevarlo a cabo hasta su remediación de forma rápida y exhaustiva.

La seguridad de las aplicaciones estaría en una situación mucho peor si no fuera por estas herramientas de código abierto y muchas otras. Eso es indiscutible. Pero el simple hecho de cómo operan las herramientas de desarrollo —en su estación de trabajo local, dentro de su terminal— significa que son infinitamente flexibles e inherentemente aisladas. El meme de «funcionó en mi máquina» sigue siendo aplicable aquí, solo que con una terminología diferente:

Si buscas otra forma, que reemplace toda la carga de construir este conjunto de herramientas de código abierto con una plataforma que ya está construida sobre los mismos proyectos, considera probar Aikido de forma gratuita.

Si eliges la ruta OSS, tienes nuestro reconocimiento y respeto… pero mientras incorporas nuevas herramientas y dependencias en tus flujos de trabajo, realmente deberías dejar que el firewall de aplicaciones web de Aikido proteja de forma autónoma y continua tus aplicaciones Node.js de las vulnerabilidades más peligrosas. La mejor DX, después de todo, es cuando la herramienta realmente hace todo el trabajo duro por ti.