DEV Community: Rodriguez Patrick

Detectar vulnerabilidades en Go con gosec

Rodriguez Patrick — Sun, 04 Oct 2026 01:44:36 +0000

En los laboratorios analizamos el código de una aplicación con SonarCloud,
Snyk y Semgrep. En este ejercicio el punto de mira es el mismo código fuente,
pero con una herramienta que no usamos en los labs: gosec, el analizador
estático estándar del ecosistema de Go, que publica reglas mapeadas a CWE de
la OWASP.

Para demostrar que la herramienta funciona de verdad, la aplicamos a una
aplicación escrita a propósito con los fallos más comunes. El resultado son
17 hallazgos, cinco de ellos de severidad alta.

La idea detrás de gosec

gosec analiza el código buscando patrones que se sabe que son peligrosos:

credenciales o claves privadas escritas en el fuente
comandos del sistema construidos con variables
rutas de archivo tomadas de entrada externa
algoritmos de hash débiles
consultas SQL por concatenación de cadenas
redirecciones y plantillas construidas con datos del usuario

Cada regla tiene un identificador (G###), una severidad y un CWE asociado,
así que el resultado se puede mapear a lo que exige la norma y no quedarse en
un "algo está mal aquí".

curl -sSfL https://raw.githubusercontent.com/securego/gosec/master/install.sh | sh
gosec -no-fail -fmt=json -out=informe.json ./...

Un detalle que puede arruinar el resultado: gosec necesita el compilador de Go
instalado. Sin él termina sin errores y reporta Files: 0, lo que parece un
escaneo limpio cuando en realidad no analysó nada.

La aplicación de prueba

Es un servidor web pequeño, en un solo archivo, con seis rutas. Cada una contiene
un fallo deliberado:

Ruta	Fallo introducido
`/saludo`	plantilla HTML sin escapar y redirección con datos del usuario
`/descarga`	escritura en ruta construida sin restringir
`/archivo`	lectura de archivo con ruta de la petición
`/token`	secreto concatenado sin validar
`/tipo`	comando del sistema con valor del usuario
`/hash`	MD5 y SHA1 para derivar contraseñas

No está publicada en ningún servicio y no debe usarse con datos reales. Es un
caso de estudio, no una aplicación de producción.

Los 17 hallazgos

Resultado real de gosec -no-fail -fmt=json:

Severidad	Regla	Línea	Hallazgo
HIGH	G101	30	Credencial escrita en el código
HIGH	G101	33-35	Clave privada RSA embebida
HIGH	G702	39	Inyección de comandos por análisis de taint
HIGH	G703	45	Recorrido de rutas por análisis de taint
HIGH	G703	51	Recorrido de rutas por análisis de taint
MEDIUM	G112	138-143	Slowloris: falta `ReadHeaderTimeout`
MEDIUM	G202	56	Concatenación de cadenas en SQL
MEDIUM	G204	39	Subproceso lanzado con variable
MEDIUM	G304	45	Inclusión de archivo vía variable
MEDIUM	G401	70-71	Primitiva criptográfica débil
MEDIUM	G401	70	Primitiva criptográfica débil
MEDIUM	G501	14	Import bloqueado `crypto/md5`
MEDIUM	G505	15	Import bloqueado `crypto/sha1`
MEDIUM	G705	117	XSS por análisis de taint
MEDIUM	G705	122	XSS por análisis de taint
MEDIUM	G710	77	Redirección abierta por análisis de taint
LOW	G104	117	Errores sin manejar

Resumen: 5 HIGH, 11 MEDIUM, 1 LOW. 17 en total.

Lo que las reglas de taint aportan

Cuatro de los hallazgos (G702, G703, G705, G710) no vienen de buscar una palabra
clave: gosec sigue el valor desde que entra en la función hasta donde se usa.

En /tipo, el valor de mime llega de r.URL.Query().Get("mime") y acaba como
argumento de exec.Command. G204 lo marca como "subproceso con variable", que es
correcto pero genérico. G702 lo marca como inyección de comandos, porque
sabe que ese valor no se ha validado. La misma línea, dos reglas, y la segunda
es la que dice qué hacer.

Lo mismo con G703: G304 dice "inclusión de archivo vía variable", y G703 dice
recorrido de rutas, siguiendo que ruta viene de la petición sin comprobar.

Es la diferencia entre un filtro por patrón y un análisis de flujo de datos.

Integrarlo en la automatización

- name: gosec
  run: |
    gosec -no-fail -fmt=json -out=gosec.json ./...

-no-fail deja que el escaneo termine y muestre el informe completo. Para que
el pipeline falle:

gosec ./... -severity=HIGH           # falla si hay hallazgos altos
gosec -no-fail ./... -severity=HIGH  # solo informa

Para un error justificado hay una directiva en la misma línea:

ruta := validarComoInterno(ruta) // #nosec G304 -- ya sanitizada arriba

La convención es no abusar de ella: cada #nosec es una excepción que alguien
tiene que leer y justificar.

Sobre los falsos negativos

gosec analiza el flujo de información dentro del archivo y entre archivos del
mismo paquete. Hay casos que se le escapan:

Lógica de negocio incorrecta sin ningún patrón peligroso.
Vulnerabilidades en dependencias, que es otro problema: para eso está OWASP Dependency-Check.
Código generado automáticamente, que normalmente no se revisa.
Otro lenguaje: gosec solo analiza Go.

El informe incluye el CWE de cada hallazgo, que permite priorizar por lo que la
norma exige y no por la severidad que le asigne la herramienta.

Conclusión

El ejercicio deja un resultado concreto: 17 hallazgos correctamente
clasificados, cinco de ellos de severidad alta, sobre una aplicación escrita
para contenerlos.

Lo que demuestra el análisis de taint es lo más aprovechable. Una herramienta
que dice "aquí hay un exec.Command con variable" obliga a revisar; una que
dice "el valor llega desde la petición sin validar" dice cuál es el problema.

Ningún análisis estático sustituye a revisar el diseño, y un resultado limpio
no significa que el código sea correcto: significa que esta herramienta no
encontró nada. La diferencia entre las dos afirmaciones es la que hace que un
informe sirva para algo.

Enlaces

Repositorio con el código y el informe: https://github.com/UPT-FAING-EPIS/si784-2026-ii-si784-2026-ii-examen-u1-dejameingresar
gosec: https://github.com/securego/gosec
CWE de la OWASP: https://cwe.mitre.org/

Auditar dependencias con OWASP Dependency-Check

Rodriguez Patrick — Sun, 04 Oct 2026 01:43:35 +0000

En los laboratorios anteriores revisamos el código con SonarCloud, Snyk y
Semgrep. Pero ese código se apoya en cientos de librerías de terceros que nadie
del equipo escribió ni revisó. Esta vez cambiamos el punto de mira: en lugar del
código propio, analizamos las dependencias.

La herramienta es OWASP Dependency-Check,
del OWASP Foundation, y su criterio es la base de datos de avisos que la propia
fundación mantiene.

El problema

Cuando escribes dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL, lo
que llega a tu proyecto son decenas de paquetes transitivos. Cada uno es código
de otra persona que se ejecuta con los privilegios de tu aplicación.

Una dependencia vulnerable no se ve leyendo tu repositorio. Se ve consultando
qué versiones publicadas tienen avisos de seguridad asociados.

Qué revisamos

El proyecto de ejemplo es una API en ASP.NET Core 8 con PostgreSQL. Su grafo de
dependencias tiene 20 paquetes transitivos:

Microsoft.EntityFrameworkCore                8.0.10
Npgsql.EntityFrameworkCore.PostgreSQL        8.0.10
Microsoft.AspNetCore.Authentication.JwtBearer 8.0.10
Swashbuckle.AspNetCore                       6.9.0
Microsoft.IdentityModel.Tokens               7.1.2
Npgsql                                       8.0.5
System.Collections.Immutable                 6.0.0
... (14 más)

La herramienta de NuGet consulta esa misma base de vulnerabilidades:

dotnet list TaskFlow.Api/TaskFlow.Api.csproj package \
                 --include-transitive --vulnerable

Resultado:

The given project `TaskFlow.Api` has no vulnerable packages
given the current sources.

Cero vulnerabilidades conocidas en el grafo completo, incluidas las
dependencias transitivas.

La herramienta de la OWASP

Dependency-Check hace lo mismo pero con su propia base de datos, que es la
Daily CVE Project de la OWASP:

dependency-check --project "TaskFlow API" \
                 --scan TaskFlow.Api \
                 --out informes/dependencias \
                 --format HTML --format SARIF \
                 --failOnCVSS 7

Dos diferencias con la herramienta de NuGet:

La base es de la OWASP, no de NuGet. NuGet solo conoce los paquetes que él
publica; Dependency-Check también cubre registros privados y otras fuentes.

Puede generar SARIF, que GitHub interpreta y muestra anotado en el pull
request. Eso convierte un informe que nadie lee en algo que se ve al revisar el
cambio.

Una nota sobre el tiempo de la primera ejecución

La base de avisos de la NVD contiene, a la fecha, más de 400.000 registros.
Sin una API key de la NVD, la descarga inicial tarda varias horas. Con una key
—gratuita— baja a minutos:

https://nvd.nist.gov/developers/request-an-api-key

Las ejecuciones siguientes usan la copia en caché. Por eso el escaneo va
programado en el pipeline y no como un paso manual.

Cómo se integra en la automatización

- name: OWASP Dependency-Check
  run: |
    dependency-check \
      --project "TaskFlow API" \
      --scan TaskFlow.Api \
      --out ./informes/dependencias \
      --format HTML \
      --format SARIF \
      --data ~/.gradle/caches \
      --failOnCVSS 7

Tres decisiones:

--failOnCVSS 7. El escenario falla solo ante vulnerabilidades altas o
críticas. Un aviso medio en una dependencia transitiva no debe bloquear un
push; uno crítico sí.

--format SARIF. El resultado se sube a GitHub Security y aparece anotado
en el diff del pull request.

Ejecución semanal. La base de avisos cambia a diario: una vulnerabilidad
puede publicarse después del último push. El workflow tiene un cron semanal
además del disparo por push.

Limitación honesta

Un escaneo de dependencias solo ve lo que la base de datos conoce. Tres casos se
le escapan:

Paquetes sin CVE. Una vulnerabilidad nueva o todavía sin CVE publicado no aparece. Queda una ventana de días o semanas entre la publicación del fallo y su registro.
Vulnerabilidades de lógica. Que un paquete no tenga CVE no significa que su uso sea correcto. Un ORM con inyección SQL es un paquete limpio usado mal.
Resolución distinta a la esperada. Si el paquete se instala desde un registro privado o un mirror, la resolución puede diferir de lo que el análisis asume.

Por eso el escaneo de dependencias no reemplaza al análisis de código. Cubren
cosas distintas y ambos hacen falta.

Conclusión

Cero vulnerabilidades conocidas en 20 paquetes transitivos no significa que el
proyecto esté libre de ellas. Lo que sí sabemos es concreto: se consultó la base
de avisos y no encontró nada, y eso se puede volver a comprobar en cada push.

El valor de la automatización no está en el primer resultado, sino en que el
mismo control se repite sin que nadie tenga que acordarse de ejecutarlo.

Enlaces

Repositorio: https://github.com/UPT-FAING-EPIS/si784-2026-ii-si784-2026-ii-examen-u1-dejameingresar
OWASP Dependency-Check: https://owasp.org/www-project-dependency-check/
Base de datos OWASP: https://github.com/dependency-check/DependencyCheck

Seis estrategias de respaldo para bases de datos NoSQL, y qué falla de verdad

Rodriguez Patrick — Sun, 04 Oct 2026 01:03:50 +0000

Seis estrategias de respaldo para bases de datos NoSQL, y qué falla de verdad

No uso MS SQL Server: el enunciado lo excluye y, además, el problema que quiero
estudiar es el de los motores NoSQL, donde cada familia de motor tiene una forma
distinta de persistir y, sobre todo, una forma distinta de romperse.

Lo que hice fue construir una aplicación que ejecuta seis estrategias de respaldo
sobre tres motores reales, restaura cada una y cuenta lo que vuelve. No me
conformé con que el comando terminara con código cero: varias veces terminó en
cero sin haber restaurado nada.

Enlaces del proyecto

Repositorio público con el código y la documentación: https://github.com/dejameingresar/dataforge-backup-nosql
Aplicación desplegada en la nube (Render): https://dataforge-backup-si783.onrender.com
Video de construcción y demostración: (pendiente de publicar)

Los tres motores

Motor	Versión	Modelo de datos	Rol en el proyecto
MongoDB	7.0.14	documentos en colecciones	base documental con índices
Redis	7.0.15	pares clave-valor en memoria	claves de cinco tipos distintos
Neo4j	5.24.0	grafos (nodos y relaciones)	grafo con tres tipos de arista

Las seis estrategias, con las cifras medidas

Cada número de esta tabla salió de una corrida real: se genera el respaldo, se
calcula su SHA-256, se destruyen los datos, se restaura y se cuenta lo que volvió.

Motor	Estrategia	Artefacto	Tamaño	Duración	Round-trip
MongoDB	`logico_mongodump`	`*.bson.gz`	30.8 KiB	343 ms	1400 → 1400 docs
MongoDB	`fisico_wiredtiger`	`snapshot_wiredtiger.tar.gz`	1.11 MiB	2.44 s	1400 → 1400 docs
Redis	`rdb_dump`	`dump.rdb`	11.3 KiB	154 ms	240 → 240 claves
Redis	`aof_append`	`appendonlydir/`	11.4 KiB	2.15 s	240 → 240 claves
Neo4j	`dump_binario`	`neo4j.dump`	509.1 KiB	3.48 s	200/594 → 200/594
Neo4j	`exportacion_cypher`	JSON Lines	104.0 KiB	420 ms	200/594 → 200/594

6 de 6 restauraron exactamente lo que había. Ese "exactamente" es lo que
importa: varias veces costó llegar ahí.

1. MongoDB, `mongodump`: el lógico

Exporta cada colección a BSON comprimido. Habla el protocolo de red, así que
funciona con el servidor encendido.

mongodump --uri mongodb://127.0.0.1:27017/dataforge_backup --out DIR --gzip
mongorestore --uri mongodb://127.0.0.1:27017 --gzip DIR/dataforge_backup/clientes.bson.gz

Protege los documentos y los índices. No protege los usuarios, los roles, el
oplog ni el estado interno de WiredTiger: eso va aparte.

2. MongoDB, copia en frío de WiredTiger

Con el motor detenido, se copia el dbpath entero: los .wt, el catálogo,
WiredTiger.turtle, sizeStorer y el journal. Es una foto del almacenamiento.

Aquí está la primera limitación que vale la pena entender: el archivo es del
motor completo, no de una base. Al probarlo, el dbpath tenía tres bases y el
respaldo se llevó las tres. Si lo que quieres es respaldar una base, esta
estrategia no sirve, y esa es exactamente la razón por la que existe
mongodump.

3. Redis, volcado RDB

redis-cli -p 6379 --rdb dump.rdb

Un punto de control binario de toda la base. Redis 7 usa copy-on-write:
mientras se copia, las páginas modificadas se duplican, así que el archivo es
consistente aunque el servidor siga recibiendo escrituras.

No protege los comandos ejecutados entre puntos de control: la ventana de pérdida
es de segundos.

4. Redis, copia del AOF

El AOF es un registro de órdenes de escritura, no de estado. Su ventana de
pérdida es mucho menor que la del RDB.

redis-cli -p 6379 BGREWRITEAOF
# esperar a que termine:
redis-cli -p 6379 INFO persistence   # aof_rewrite_in_progress == 0

Con Redis 7 el AOF ya no es un archivo suelto: es un directorio con un
manifiesto y varios .base.rdb e .incr.aof. Copiar solo el .aof deja fuera
los incrementales y se pierde lo escrito después.

5. Neo4j, dump binario

neo4j-admin database dump neo4j --to-path=DESTINO
neo4j-admin database load neo4j --from-path=DESTINO --overwrite-destination

Empaqueta todo en un .dump. En la edición Community exige que la base esté
detenida para el dump y para la carga: es una ventana sin servicio, y la
ficha de la estrategia lo declara en vez de esconderlo.

6. Neo4j, exportación a JSON Lines

Nodos y aristas como texto, con los identificadores internos reemplazados por
claves de negocio. Es la única que corre en caliente y la única que se puede
revisar a mano, versionar en un repositorio o comparar entre versiones.

Lo que falló de verdad

Esta es la parte que más aporta, porque no aparece en los manuales.

Un respaldo que "tiene éxito" y no restaura nada

mongorestore no acepta un directorio. Si se le pasa la carpeta del dump
devuelve código de salida 0 y restaura cero documentos, con un mensaje
apodable: don't know what to do with file ... skipping. Hay que pasarle cada
.bson.gz individual.

Lo detecté porque conté los documentos después de restaurar. Si hubiera confiado
en el código de salida, habría publicado un respaldo que no restauraba nada.

Redis 7 ya no permite elegir dónde guardar el RDB

CONFIG SET dir falla con can't set protected config. La salida es usar
redis-cli --rdb DESTINO, que además no detiene el servidor: usa replicación
en modo rdb-only.

Neo4j: las etiquetas no se pueden añadir después

Neo4j 5 rechaza SET n:Etiqueta con un error de sintaxis: eso exige el plugin
APOC, que no viene instalado. La forma sin plugins es crear el nodo con sus
etiquetas desde el CREATE (CREATE (n:Uno:Dos {...})), lo que obliga a agrupar
las filas por su conjunto exacto de etiquetas.

Neo4j: `MERGE` colapsa las aristas repetidas

En un grafo puede haber varias aristas del mismo tipo entre el mismo par de
nodos, con propiedades distintas. MERGE las funde en una sola. Al medir el
round-trip me faltaban 4 relaciones: 590 de 594. Parecía "casi bien", y por eso
lo investigué en vez de anotarlo como una pérdida menor. Con CREATE se
conservan todas.

La tentación era relajar la comparación para que el número cuadrara. Eso habría
convertido un defecto real en un falso positivo.

Una ventana sin servicio

Las dos estrategias físicas (fisico_wiredtiger y dump_binario) exigen el
motor detenido. En un sistema en producción eso no es un detalle de
implementación: es una decisión de arquitectura. Para la misma base, la
exportación lógica de Neo4j corría en caliente en 420 ms, frente a los 3.48 s del
dump con el servidor parado.

Integración continua

Cada push a main ejecuta la suite. Los casos que necesitan motores reales no
pueden correr en el runner de GitHub Actions, así que fallan de forma
explícita en vez de devolver un resultado inventado; la verificación completa se
hace contra los motores locales. El despliegue en Render es un render.yaml con
autoDeploy por commit y el health check en /api/salud.

La aplicación usa solo la biblioteca estándar de Python: sin requirements.txt,
sin instalación, sin cadena de dependencias. En la nube los motores aparecen como
n/d, porque un servicio público no expone puertos de base de datos; en local
responden de verdad.

Conclusiones

Un respaldo no es un archivo: es una cadena. Backup, verificación por hash, restauración y conteo. Saltaba un eslabón, el resultado no servía.
El código de salida no es evidencia. Dos de los fallos más caros de este proyecto salían con 0. Contar lo que volvió sí lo es.
Cada familia de motor tiene su propia restricción, y la operación más cara no siempre es la que parece: la física es más rápida de escribir pero te quita el servicio.
El respaldo físico es del motor; el lógico, de la base. Esa diferencia decide qué estrategia sirve y cuál no.
Documentar lo que no protege es más útil que documentar lo que sí. Una ficha de estrategia que solo enumera ventajas no sirve para decidir.

Código

El repositorio incluye los tres adaptadores, la batería de 27 pruebas con el
ciclo completo contra un motor real, el smoke test en navegador y el
render.yaml del despliegue.

DEV Community: Rodriguez Patrick

Detectar vulnerabilidades en Go con gosec

La idea detrás de gosec

La aplicación de prueba

Los 17 hallazgos

Lo que las reglas de taint aportan

Integrarlo en la automatización

Sobre los falsos negativos

Conclusión

Enlaces

Auditar dependencias con OWASP Dependency-Check

El problema

Qué revisamos

La herramienta de la OWASP

Una nota sobre el tiempo de la primera ejecución

Cómo se integra en la automatización

Limitación honesta

Conclusión

Enlaces

Seis estrategias de respaldo para bases de datos NoSQL, y qué falla de verdad

Seis estrategias de respaldo para bases de datos NoSQL, y qué falla de verdad

Enlaces del proyecto

Los tres motores

Las seis estrategias, con las cifras medidas

1. MongoDB, mongodump: el lógico

2. MongoDB, copia en frío de WiredTiger

3. Redis, volcado RDB

4. Redis, copia del AOF

5. Neo4j, dump binario

6. Neo4j, exportación a JSON Lines

Lo que falló de verdad

Un respaldo que "tiene éxito" y no restaura nada

Redis 7 ya no permite elegir dónde guardar el RDB

Neo4j: las etiquetas no se pueden añadir después

Neo4j: MERGE colapsa las aristas repetidas

Una ventana sin servicio

Integración continua

Conclusiones

Código

1. MongoDB, `mongodump`: el lógico

Neo4j: `MERGE` colapsa las aristas repetidas