¿Qué cuenta como experiencia en ciberseguridad? Tres pruebas que sí podés mostrar
Un laboratorio, una contribución y un informe breve pueden mostrar cómo trabajás en ciberseguridad. Qué documentar, qué límites aclarar y cómo no confundir práctica con empleo.
En este artículo
Te piden experiencia para entrar en ciberseguridad. Abrís el CV y pensás: «Si todavía no tuve un puesto de seguridad, ¿qué pongo?».
La respuesta no es inflar un laboratorio hasta hacerlo pasar por trabajo profesional. Tampoco juntar certificados y esperar que hablen solos. Para mí, la pregunta más útil es otra: ¿qué tarea hiciste, qué decisión tomaste y qué puede revisar otra persona para entenderlo?
TRES FORMAS DE MOSTRAR TU TRABAJO
01 / PRÁCTICA
Una prueba que se puede repetir
Entorno, hipótesis, pasos y resultado. Otra persona puede comprobar lo que hiciste.
Límite: un lab no es empleo ni demuestra que toda la API sea segura.
El marco NICE de NIST describe el trabajo de ciberseguridad a través de tareas, conocimientos y habilidades. Esa idea sirve para ordenar un portfolio: elegí una tarea cercana al rol que buscás y dejá evidencia de cómo la resolviste.
No hace falta construir diez proyectos. Estas tres pruebas pueden salir de uno solo.
1. Un laboratorio con resultado y límite #
«Hice un lab de seguridad web» dice poco. Probaste algo, pero no sé cuál era la hipótesis ni qué pasó cuando la pusiste a prueba.
Imaginá una API de práctica con dos usuarios y documentos privados. Iniciás sesión como Ana, pedís su documento y recibís un 200. Cambiás el ID por el de Bruno; la API también responde 200. El token de Ana es válido, pero el servidor nunca comprobó si podía leer ese documento.
La evidencia no es una captura con la palabra vulnerable en rojo. Es una secuencia que otra persona puede repetir:
- Objetivo: comprobar que cada usuario solo pueda leer sus documentos.
- Entorno: API local y datos ficticios; nada de cuentas o sistemas ajenos.
- Prueba: dos usuarios, dos documentos y la respuesta obtenida con cada uno.
- Cambio: agregar la comprobación de acceso al documento solicitado.
- Nueva prueba: la solicitud propia sigue funcionando y la ajena se rechaza.
- Límite: probaste lectura en ese endpoint; no demostraste que toda la API esté protegida.
Ahí se ve más que el resultado. Se ve cómo aislaste el problema, cómo lo corregiste y qué parte todavía no podés afirmar. El código, los datos de ejemplo y los pasos para ejecutarlo pueden quedar en un README corto.
Un laboratorio así es práctica demostrable. Si no ocurrió en un trabajo, etiquetalo como laboratorio. Esa precisión le da más valor, no menos.
2. Un arreglo o una contribución que se pueda seguir #
Una contribución pública deja un rastro: problema, propuesta, cambios, pruebas y revisión. No tiene que ser una gran vulnerabilidad ni un proyecto propio desde cero.
Por ejemplo, este issue de Podman pedía reintentos para podman manifest push. Mi pull request agregó las opciones, las conectó con la API y sumó pruebas. Se puede leer qué problema resolvía, qué cambió durante la revisión y que finalmente se integró.
Eso muestra trabajo real sobre infraestructura y colaboración con mantenedores. No lo vendería como experiencia de pentesting: no lo es. Para un rol de seguridad de plataformas o DevSecOps, en cambio, ayuda a mostrar que puedo entender una herramienta, cambiar su comportamiento y sostener el cambio con pruebas.
Si todavía no tenés un PR aceptado, podés documentar una reproducción de bug, una mejora de documentación técnica o una propuesta que recibió revisión. Lo importante es que el enlace permita seguir tu razonamiento. «Contribuí a open source» sin explicar qué hiciste vuelve a dejar la parte valiosa afuera.
3. Un informe corto que explique una decisión #
En seguridad no alcanza con encontrar algo raro. Hay que poder contar qué observaste, por qué importa y qué harías después. La guía de pruebas web de OWASP recomienda que los hallazgos incluyan evidencia, impacto, pasos reproducibles y una corrección útil para quien va a implementarla.
El informe no necesita veinte páginas. Para el laboratorio de la API, podría ocupar una sola:
| Campo | Ejemplo |
|---|---|
| Hallazgo | Un usuario autenticado puede leer el documento de otro cambiando el ID. |
| Evidencia | Solicitudes con dos cuentas de prueba y sus respuestas, sin datos reales. |
| Alcance | Endpoint de lectura en un entorno local. |
| Decisión | Comprobar el permiso sobre el documento en cada solicitud. |
| Verificación | El acceso propio funciona; el cruzado se rechaza. |
| Límite | No se evaluaron edición, borrado ni otros endpoints. |
Ese último campo importa. «No encontré otro problema» y «no probé el resto» son cosas muy distintas.
Podés aplicar el mismo formato a un análisis de logs, una regla de detección o una revisión de permisos cloud. El informe muestra que no solo ejecutaste comandos: entendiste el alcance y dejaste una decisión que alguien más puede usar.
Elegí la prueba según el trabajo que buscás #
No existe «experiencia en ciberseguridad» como una sola tarea.
NO HAY UN PORTFOLIO UNIVERSAL
La prueba cambia con el trabajo
En el CV o portfolio, separá empleo, contribuciones y laboratorios. En cada entrada poné el problema, tu acción, el resultado y un enlace a la evidencia pública. Si el trabajo fue para una empresa o un cliente, contá solo lo que puedas compartir sin exponer sistemas, datos ni incidentes privados.
Un certificado puede mostrar qué estudiaste. Un laboratorio, una contribución y un informe bien hechos permiten ver cómo trabajás. No garantizan una contratación ni reemplazan los años en producción. Pero sí le dan a la otra persona algo concreto para discutir con vos.
Lo próximo llega también por mail. Cada dos semanas, en Apuntes.
Comentarios
Pasan por moderación antes de aparecer.