Confía en sus habilidades de desarrollo, lo suficiente como para saber que las aplicaciones que ha creado no están completamente libres de fallos de seguridad y configuración. También ha investigado el profundo ecosistema de herramientas de análisis disponibles y quizás se haya sentido abrumado por la gran cantidad de opciones. ¿Cuál es la "cartera" adecuada de herramientas de seguridad de aplicaciones de código abierto para identificar vulnerabilidades en sus dependencias, configuraciones de Infraestructura como Código (IaC), contenedores, etc.?
Para ponerte en el buen camino, 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 ayuda ese escaneado a la seguridad de tu aplicación.
- Qué proyecto de código abierto puedes instalar y cómo ejecutarlo.
- Algunas alternativas (cuando estén disponibles) entre las que puede elegir.
De este modo, dispondrá de un método sencillo para analizar sus 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 color de rosa, pero ya hablaremos de eso más adelante.
Lo que necesitas
Sólo tiene que traer su estación de trabajo local, ya sea un ordenador de sobremesa o un portátil; no importa si utiliza macOS, Windows o Linux.
Un entorno de desarrollador es opcional pero recomendable. Para ejecutar este conjunto de herramientas de exploración de código abierto, tendrá que instalar una gran cantidad de software que puede que no desee en su sistema operativo base, lo que requerirá mayores actualizaciones, contaminará su autocompletado y le obligará a utilizar herramientas específicas que pueden no funcionar en todos sus proyectos. Un entorno de desarrollo contiene y aísla, hasta cierto punto, todas las herramientas específicas de desarrollo del resto del sistema operativo.
Por suerte, puedes elegir entre varias herramientas de código abierto:
- Con Dockerpuede crear un nuevo contenedor llamado
devenv-01así:docker run --name devenv-01 -it ubuntu:24.04 sh - Con Daytonaque viene con muchas "pilas incluidas" para los flujos de trabajo de desarrollo:
daytona crear --código - O con Distrobox, que incrusta cualquier distribución de Linux dentro de su terminal, permitiéndole instalar software
Lo bueno de un entorno para desarrolladores es que, una vez que hayas terminado con una "pila" concreta, puedes eliminar el contenedor de forma segura sin que ello afecte a 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 de nube. Al supervisar continuamente sus aplicaciones y sus servicios ascendentes con respecto a las mejores prácticas del sector y sus políticas internas, las herramientas de CSPM evalúan los problemas, los priorizan en función de su criticidad y ofrecen recomendaciones para solucionarlos. Con CSPM, usted se responsabiliza más de las líneas de base y las barandillas que impiden que usted u otros promuevan aplicaciones vulnerables a la producción, a la vez que se erradican las configuraciones erróneas y los roles de usuario excesivamente permisivos.
Instale y ejecute su proyecto OSS CSPM: 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, debe configurar CloudSploit con permisos de lectura a su cuenta en la nube, con soporte para AWS, Azure, GCPy Oracle. Siga las instrucciones de su proveedor de nube, utilizando el repositorio de config_example.js archivo como plantilla, para crear un config.js con todos los detalles que necesitará para ejecutar su primer diagnóstico completo y obtener resultados en JSON.
./index.js --collection=archivo.json config.js
#2: Análisis de composición de software (SCA) de dependencias de código abierto
¿Cómo ayuda SCA a la seguridad de las aplicaciones?
Sus aplicaciones tienen inevitablemente un gran árbol de dependencias de código abierto en las que ahora confía, desde su marco de interfaz de usuario hasta las bibliotecas de ayuda que utiliza en una sola LOC, como un validador de direcciones de correo electrónico. SCA es como una comprobación de los antecedentes de la extensa familia de su código, que identifica los problemas de vulnerabilidad de la seguridad y de licencias no una vez, sino continuamente. Dado que sus herramientas de SCA le informan sobre nuevas vulnerabilidades y soluciones, 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 OSS SCA: Syft + Grype
Para ejecutar SCA localmente, necesitará Syft para crear una lista de materiales de software (SBOM) y Grype para analizar dicha SBOM en busca de vulnerabilidades conocidas. Dado que Syft y Grype son fabricados por el mismo equipo, admiten muchos métodos de instalación, pero recomiendan sus respectivas líneas únicas:
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, sustituyendo a <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
Acabarás con un sbom.syft.json en tu directorio de trabajo, que luego puedes introducir en Grype.
grype sbom:path/to/syft.json -o json
A continuación, Grype imprime un resumen de vulnerabilidades en el formato que se muestra a continuación, incluidos los detalles de gravedad e información sobre las correcciones conocidas, que puede utilizar para orientar su proceso de priorización y corrección.
{
"vulnerability": {
...
},
"relatedVulnerabilities": [
...
],
"matchDetails": [
...
],
"artifact": {
...
}
}
Alternativas y advertencias
Trivy es una sólida alternativa OSS para SCA, no ofrecerá paridad de características 1:1 en todos los ámbitos, 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 tu código y configuraciones en busca de credenciales que no quieras exponer públicamente. Estos secretos pueden incluir claves de API, tokens de acceso a proveedores externos, contraseñas de bases de datos ascendentes, certificados, claves de cifrado y mucho más, y una vez que se publican en un repositorio público, tendrás que pasar por un doloroso proceso para eliminarlos de tu historial de Git.
Instala y ejecuta tu proyecto de detección de secretos OSS: Gitleaks
Gitleaks escanea tus repositorios en busca de la presencia de secretos codificados, pasados o presentes, analizando los registros de Git. Su detectar identifica los secretos que ya se han cometido, mientras que el comportamiento proteger escanea los cambios no comprometidos para evitar que cometas errores en primer lugar.
Para obtener el máximo control, 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 referencia para obtener resultados sólo de la exposición a nuevos secretos.
gitleaks detect --report-path gitleaks-report.json
En las invocaciones posteriores, debe hacer referencia a su gitleaks-informe.json para escanear los registros Git sólo para los secretos añadidos desde que creó su informe de línea de base.
gitleaks detect --baseline-path gitleaks-report.json --report-path findings.json
Su resultados.json contendrá detalles sobre el hash de la confirmación y el autor de cada posible filtración, lo que le ayudará a centrarse en las correcciones.
Alternativas y advertencias
Por desgracia, no hay muchas opciones más allá de Gitleaks. Otros proyectos de detección de secretos de código abierto han pasado años desde la última confirmación, lo que no inspira precisamente confianza para proteger las aplicaciones en las que estás trabajando hoy. Si eres un proveedor de servicios, puedes registrarte en el programa de socios de escaneo de secretos de GitHub, que identifica cuando tus usuarios envían accidentalmente tus formatos de token secreto a uno de sus repositorios.
#4: Pruebas estáticas de seguridad de las aplicaciones (SAST)
¿Cómo ayuda el SAST?
SAST es el peine de púas finas de las herramientas de seguridad de aplicaciones, ya que analiza tu código base línea por línea para comprobar si hay errores de sintaxis, estructura o lógica que podrían dejar vulnerable tu aplicación. Piense en ataques de inyección SQL, oportunidades de secuencias de comandos en sitios cruzados (XSS), desbordamientos de búfer y mucho más. Mediante la comprobación de bases de datos populares de CVE conocidas, una herramienta SAST sólida le dará la confianza de que no está dejando grandes fallos de seguridad sobre la mesa, y algunas incluso ofrecen sugerencias de autocorrección para una solución rápida.
Instale y ejecute su proyecto OSS SAST: Semgrep
Semgrep escanea tu código, encuentra errores y aplica los estándares de código establecidos con cada invocación, con soporte para más de 30 lenguajes. En aras de la simplicidad, nos centramos en Semgrep CLI, que es sólo una parte de un complejo ecosistema de productos.
La forma más universal de instalar el Semgrep CLI es con Python/pip.
python3 -m pip install semgrep
Ejecute su primer análisis 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 advertencias
El mundo de SAST rebosa de oportunidades: si Semgrep no funciona para ti, echa un vistazo a algunas alternativas específicas de lenguaje como Bandit (Python), Gosec (Go) o Brakeman (Ruby on Rails) para empezar.
#5: Pruebas dinámicas de seguridad de las aplicaciones (DAST)
¿Cómo ayuda DAST a la seguridad de las aplicaciones?
A diferencia de SAST, DAST simula vulnerabilidades comúnmente explotadas contra su aplicación en un entorno real. Se trata menos de la sintaxis y la estructura del código que usted escribió y mucho más de replicar los enfoques que un atacante podría adoptar contra su despliegue de producción. Las herramientas DAST volverán a comprobar las CVE conocidas en los marcos de trabajo y las bibliotecas que utilice y comprobarán si los usuarios registrados pueden acceder a datos confidenciales debido a permisos rotos o a "combinaciones tóxicas" de múltiples vulnerabilidades que exponen su aplicación a consecuencias mucho peores.
Instale y ejecute su proyecto OSS DAST: Núcleos
Nuclei es un escáner de vulnerabilidades impulsado por la comunidad que utiliza plantillas para enviar peticiones a la aplicación que desea proteger ejecutándose en un entorno local. Puedes escribir plantillas personalizadas usando YAML, pero la comunidad de Nuclei también tiene una amplia biblioteca de plantillas preconfiguradas para probar tu 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 desarrollador- y aprovechando la biblioteca de plantillas, que Nuclei activa por defecto.
nuclei -u localhost:5678 -je nuclei-report.json
Alternativas y advertencias
Zed Attack Proxy (ZAP) es un fantástico escáner mantenido activamente por un equipo global de expertos en seguridad y desarrolladores. Sin embargo, a diferencia de otros de esta lista, ZAP es una aplicación gráfica por defecto. Hay opciones para usar tu terminal, pero no son exactamente las más amigables para los desarrolladores en comparación con otros procesos que has seguido hasta aquí.
#6: Escaneado de la infraestructura como código (IaC)
¿Cómo ayuda el escaneado IaC a la seguridad de las aplicaciones?
Hoy en día, la mayoría de los equipos utilizan herramientas de IaC como Terraform, CloudFormation y los diagramas "base" de Kubernetes Helm para aprovisionar servicios en la nube de forma declarativa, controlada por versiones y repetible. Los escáneres de IaC identifican vulnerabilidades en estos planos JSON o YAML para evitar que se despliegue un estado inseguro en producción.
Instale y ejecute su proyecto de escaneado OSS IaC: Checkov
Checkov analiza muchos tipos de código IaC (configuraciones de Terraform, gráficos de Helm, archivos Docker, etc.) en busca de errores de configuración comunes y posibles vulnerabilidades de seguridad. Con más de 1.000 comprobaciones de políticas integradas para AWS, GCP y Azure, la herramienta le ayuda rápidamente a comprender los riesgos y oportunidades actuales de sus 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
A continuación, puede ejecutar Checkov contra su directorio de trabajo (u otro directorio donde haya almacenado archivos IaC) y obtener un archivo JSON como salida.
checkov --directorio . -o json
#7: Escaneado de imágenes de contenedores
¿Cómo ayuda el escaneado de imágenes de contenedores a la seguridad de las aplicaciones?
Nos encantan los contenedores porque abstraen mucha complejidad, pero cuando se crea una imagen de contenedor, ésta puede heredar vulnerabilidades de su imagen base o de las dependencias de paquetes. Los escáneres de imágenes de contenedores descubren vulnerabilidades en tus imágenes base y Dockerfiles, por muy profundo que sea el árbol de dependencias, para evitar que despliegues involuntariamente una aplicación explotable.
Y así es también como nacieron las vulnerabilidades de las imágenes de contenedores.
Instale y ejecute su proyecto de escaneo de imágenes de contenedores OSS: Trivy
Trivy es un escáner de seguridad versátil capaz de analizar sus imágenes de contenedores en busca de vulnerabilidades conocidas con CVE, problemas de IaC y configuraciones erróneas, la presencia de secretos y mucho 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 sintonía con los otros mecanismos de instalación recomendados hasta ahora, se recomienda utilizar 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, errores de configuración y secretos contra cualquier imagen de contenedor que usted especifique, con resultados en formato JSON estándar.
trivy image --format json --output trivy-result.json <YOUR-IMAGE>
Alternativas y advertencias
Si has estado siguiendo a lo largo, ya tiene Grype instalado en su estación de trabajo local de 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 ser útil para "dos pájaros de un tiro".
Amazon Inspector también es una opción, pero con dos grandes advertencias: en primer lugar, sólo funciona con despliegues de AWS y, en segundo lugar, no es software de código abierto como el resto de nuestras recomendaciones, lo que significa que conlleva nuevos costes mensuales.
#8: Escaneado de licencias de código abierto
¿Cómo ayuda el escaneado de licencias de código abierto a la seguridad de las aplicaciones?
La legalidad del uso de software de código abierto en sus productos comerciales no es algo que se comprueba una vez con los equipos legales o de cumplimiento y se olvida. Los proyectos de OSS cambian las licencias con más frecuencia de lo que se cree, lo que obliga a pagar por una versión empresarial, buscar una alternativa o abrir parte del código privado. Los escáneres de licencias identifican los cambios y le ayudan a superar las auditorías de seguridad con una lista de materiales de software (SBOM) lista para usar.
Instale y ejecute su proyecto de escaneado de licencias OSS: Syft
Al igual que con Grype en el último paso, ya tiene Syft instalado en su estación de trabajo local e incluso podría tener un SBOM existente desde la configuración de su integración SCA con Grype. Si aún no lo tiene, puede crear rápidamente uno nuevo haciendo referencia a una imagen de contenedor de un registro configurado o a una ruta en su 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 su imagen y de la profundidad de las dependencias, puede obtener un archivo SBOM de varios miles de líneas. Dentro de todo lo que la salida JSON, que está buscando dentro de la artefactos para el licencias de cada paquete y dependencia de su 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á analizar sus obligaciones de licencia en busca de cambios que pueda necesitar realizar o migraciones para las que deba empezar a prepararse. También dispondrá de un recurso al que recurrir en la próxima auditoría de seguridad a la que se vea sometido.
Alternativas y advertencias
Trivy, mencionado por primera vez en la sección anterior, tiene una función de escaneo de licencias que le presenta resultados con opiniones sobre el riesgo asociado con los proyectos en su á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 le ayudan a identificar una amenaza que ha despegado en los últimos años: el malware inyectado en paquetes de dependencias por los atacantes. El reciente intento de zx backdoor 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 usted fusione su código, para evitar que tenga que realizar correcciones costosas y urgentes una vez que la CVE se haga pública.
Instale y ejecute su proyecto OSS de detección de malware: Filo
La herramienta CLI de Phylumte permite enviar tus archivos de bloqueo a su API para el análisis de dependencias, que difiere ligeramente de las otras herramientas de código abierto que recomendamos aquí: el análisis no se realiza en tu estación de trabajo local. En su lugar, es necesario registrar una cuenta con Phylum para la autenticación con su servicio.
Comience instalando Phylum localmente.
curl https://sh.phylum.io | sh
A continuación, registre su cuenta y ejecute su primer análisis: Phylum debería identificar el archivo de bloqueo que está utilizando.
phylum auth register
phylum auth login
phylum init
phylum analyze --json
El análisis de Phylum ofrece un resultado exhaustivo, empezando por un verdadero o falso resultado basado en si su proyecto pasa la comprobación de malware de Phylum. Bajo la matriz de rechazos de cada dependencia, encontrarás una descripción detallada de la vulnerabilidad y consejos de corrección de la comunidad OSS. Esto le permite agregar los resultados de sus pruebas SAST, DAST y SCA, permitiéndole comprender qué vulnerabilidades se deben a sus dependencias y cuáles están incrustadas directamente en el código que usted escribió.
{
"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 del final de la vida útil (EOL)
¿Cómo ayuda la detección del tiempo de ejecución EOL a la seguridad de las aplicaciones?
Cuantos más frameworks, librerías y tiempos de ejecución incluyas en tu aplicación, más oportunidades tendrás de que te aprovechen peligrosamente versiones obsoletas o dependencias no mantenidas. Esto es especialmente crítico para los tiempos de ejecución expuestos directamente a la Internet pública. Los detectores de tiempos de ejecución EOL leen tu árbol de dependencias a través de archivos de bloqueo, incluso los que están en contenedores, para alertarte con antelación y que puedas prepararte para actualizaciones o migraciones.
Instale y ejecute su proyecto OSS: endoflife.date
endoflife.date es una base de datos con información sobre el fin del ciclo de vida de más de 300 herramientas y plataformas, muchas de las cuales son esenciales para el funcionamiento y la seguridad de tu aplicación. En lugar de tener que explorar oscuros sitios de documentación o rastrear listas de correo para descubrir cuándo una versión específica de tu dependencia deja de mantenerse, puedes poner rápidamente fechas a las actualizaciones necesarias para priorizar tus esfuerzos de cara al futuro.
La forma más fácil de descubrir datos EOL es explorar el sitio, prestando especial atención a sus lenguajes de programación, bases de datos, marcos, herramientas de despliegue y CLI para servicios en la nube.
Como desarrollador, es posible que desee un enfoque más centrado en la CLI para explorar los datos EOL para sus principales tiempos de ejecución y bibliotecas-endoflife.date tiene una API simple que produce datos JSON, que también se pueden anexar a un archivo local para referencia futura.
curl --request GET \
--url https://endoflife.date/api/nginx.json \
--header 'Accept: application/json' \
>> eol.json
Un nuevo problema: gestionar todos los datos de escaneado de códigos y seguridad de las aplicaciones
Si has seguido hasta aquí, habrás construido un práctico conjunto de herramientas de código abierto y herramientas de escaneo de configuración. Estás listo para empezar a ejecutarlas en tus proyectos y ramas almacenados localmente para obtener mejores garantías de seguridad pre-commit. Toma eso, ¡desplázate a la izquierda!
Su futuro, sin embargo, no es instantáneamente impecable. Este nuevo conjunto de herramientas viene con una gran advertencia: tus herramientas no hablan juntas, y solo en torno a tu aplicación.
Usted todavía está en el gancho para:
- Configura individualmente cada herramienta. Tomemos una opción simple, como una lista permitida de ciertos directorios o dependencias que no quieres molestarte en escanear, ya que no son relevantes para la seguridad de tu entorno de producción. Tendrás que aprenderte los argumentos de cada herramienta CLI leyendo documentación y haciendo pruebas, lo que te roba un tiempo valioso para lo que realmente quieres hacer: implementar correcciones.
- Ejecute cada escáner contra cada repositorio y rama. Incluso si tienes un único repositorio y dos ramas...
principalydev-lo que supone casi 20 operaciones para buscar vulnerabilidades. Lo ideal es que ejecutes estos escáneres antes de realizar cambios en un sistema remoto, lo que implica muchas operaciones repetidas a lo largo del día.
Hay algunas maneras 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 Git pre-commit. Eso le ahorra tiempo de terminal, pero sólo genera una salida JSON más rápida - usted todavía está en el gancho para entender quéy si todavía puede enviar sus cambios y (finalmente) crear su pull request. - Recorrer matrices JSON masivas en busca de información. Estas herramientas suelen producir 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, con la esperanza de entender cada uno lo suficientemente bien como para comprender su gravedad?
Con el tiempo, necesitará una forma más intuitiva de leer los resultados que las líneas sin formato de JSON, como la importación a Google Sheets o la creación de una aplicación sencilla para ver los resultados. - Entender qué ha cambiado entre una ejecución y otra. El análisis de seguridad tiene dos objetivos. En primer lugar, ayudarle a identificar los problemas existentes en su código y configuración. Segundo, evitar que introduzcas nuevas vulnerabilidades a medida que construyes. Si no puede saber rápidamente si ha corregido una determinada vulnerabilidad o si no se le notifica la introducción de una nueva en su código, todo este esfuerzo es una pérdida de tiempo.
Una opción es incrementar o marcar con fecha y hora los archivos JSON de salida y, a continuación, utilizar herramientas CLI para compararlos.diff archivo1.json archivo2.jsones una gran herramienta independiente, o puede probargit diff --no-index archivo1.json archivo2.jsonpara archivos no confirmados en su repositorio Git. - Agregue, almacene y comparta datos para análisis a largo plazo. Como hemos dicho antes, la exploración de la seguridad es una operación continua, no un elemento puntual de su lista de cosas por hacer. Además, los resultados de sus esfuerzos de escaneo no deben ser encerrados en su estación de trabajo local - sus compañeros querrán saber acerca de las vulnerabilidades más relevantes para lo que han construido, incluso si no tienen un conjunto de herramientas similares en ejecución en el momento.
Usted tendrá que explorar las plataformas de datos que ponen toda esta información en un solo lugar - otra pieza de infraestructura para auto-alojar o pagar. - Cree tickets en Jira o GitHub. Tú o un compañero debéis escalar cada vulnerabilidad identificada a un ticket relevante que contenga todo el contexto necesario y las posibles soluciones. Es la única forma de garantizar la transparencia de la seguridad, conseguir que tus compañeros colaboren y crear el registro de auditoría que podrían exigir tus normas de cumplimiento. Ninguna de estas herramientas admite 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, que examinar.
- Priorice los tickets en función de su gravedad. Inundar los repositorios de tickets es una pesadilla para la gestión de proyectos. Es una versión diferente pero igualmente dolorosa de la fatiga por alertas: ¿Cómo se sabe en cuál centrarse primero? Si sus herramientas de OSS no pueden ayudarle con la gravedad, tendrá que dedicar tiempo a hacer esas determinaciones usted mismo, lo que podría implicar años de conocimientos de seguridad que simplemente no puede atajar.
- Gestione el ciclo de vida de cada herramienta de OSS. Tanto si se trata de mantener las herramientas actualizadas, como de intentar crear automatizaciones o incluir ejecuciones y resultados en su canalización CI/CD, ahora es usted el 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é coste para su postura en el mundo real?
- Preocuparse y preguntarse qué pasa si el proyecto pierde a su mantenedor. Si sus dependencias y tiempos de ejecución pueden llegar a EOL y crear problemas, también pueden hacerlo las herramientas y plataformas de las que depende su entorno de desarrollo local. Por desgracia, los proyectos de código abierto se basan a menudo en modelos de financiación y mantenimiento que no son sostenibles a largo plazo. Puedes seguir utilizando proyectos estancados o abandonados en tu CLI, pero cuando intentes mejorar la seguridad de tu aplicación, no te ayudarán a descubrir nuevas vulnerabilidades o métodos de ataque.
El debate actual sobre 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 se integre, se utilice, se aprecie y se defienda. Y seamos sinceros: la DX de este conjunto de herramientas de escaneado de OSS de gestión local no es especialmente buena. Usted es el dueño absoluto de su proceso y sus datos, pero con unos costes y un compromiso de tiempo excepcionales. ¿Cuánto está dispuesto a pagar por la seguridad avanzada de las aplicaciones?
Las herramientas de seguridad de código abierto son increíbles -incluso hemos construido un cortafuegos 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 manera. Tal vez incluso una que se construya sobre esta fantástica base OSS.
Una nueva solución de seguridad para aplicaciones: Aikido
Aikido integra todos esos proyectos de código abierto y muchos más.
En lugar de ejecutar más de 10 herramientas cada vez que te preparas para confirmar tus últimos cambios, solo tienes que añadir tus repositorios, imágenes Docker y proveedores de nube a Aikido una vez para un escaneo completo. Aikido se ejecuta automáticamente en segundo plano para el escaneo continuo o en su tubería CI/CD para recomendaciones específicas con cada solicitud de extracción, protegiéndole de nuevas vulnerabilidades mientras señala las existentes que han estado al acecho en su código base durante meses o años.
Y lo que es aún mejor, todos los resultados, el contexto y las posibles soluciones se agregan y almacenan en un único lugar, el panel de control de Aikido, para que nunca tenga que preocuparse de analizar JSON, fusionar varias fuentes de datos o pagar 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 pretriaged y priorizados. Con todo el contexto, la documentación y las correcciones automáticas sugeridas, cualquier miembro de tu equipo puede hacerse cargo del problema y solucionarlo 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 que las herramientas para desarrolladores funcionen en tu estación de trabajo local, dentro de tu terminal, significa que son infinitamente flexibles e intrínsecamente aisladas. El meme "funcionó en mi máquina" todavía se aplica aquí, sólo con diferente verborrea:
Si estás buscando 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 darle una oportunidad a Aikido de forma gratuita.
Si eliges la ruta OSS, tienes nuestro apoyo y respeto... pero mientras estás incorporando nuevas herramientas y dependencias en tus flujos de trabajo, realmente deberías dejar que el Web Application Firewall de Aikido proteja de forma autónoma y continua tus aplicaciones Node.js incluso de las vulnerabilidades más viciosas. El mejor DX, después de todo, es cuando la herramienta realmente hace todo el trabajo duro por ti.
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)