Portfolio de ciberseguridad: proyectos y GitHub

¿Qué es un portfolio de ciberseguridad y para qué sirve? #

Un portfolio de ciberseguridad es una selección documentada de proyectos, investigaciones, laboratorios, automatizaciones o entregables que permite revisar qué problema abordaste, cómo trabajaste y qué resultado obtuviste. Puede alojarse en GitHub, un blog técnico o una web personal; la plataforma importa menos que la calidad de la evidencia.

Un buen proyecto no intenta demostrar que “sabes de todo”. Debe dejar visibles tu razonamiento, el alcance del laboratorio, las decisiones técnicas, las limitaciones y lo que harías de forma distinta en un entorno real.

¿Necesitas un portfolio para trabajar en ciberseguridad? #

No existe un requisito universal de portfolio para trabajar en ciberseguridad. Algunas vacantes valoran experiencia laboral, formación, certificaciones, entrevistas técnicas o pruebas prácticas de formas distintas. Si todavía no tienes experiencia profesional, un portfolio puede ser una señal adicional especialmente útil porque permite enseñar trabajo propio y conversar sobre decisiones concretas.

La idea no es “compensar” automáticamente la falta de experiencia, sino crear evidencia que complemente tu candidatura. Si estás en esa fase, consulta también la guía sobre cómo conseguir tu primer trabajo en ciberseguridad sin experiencia.

Formación explica lo que has estudiado → Portfolio muestra cómo aplicas parte de ello → Entrevista comprueba si puedes defender tus decisiones

El error más común: confundir evidencia con capturas #

Una captura de VirtualBox, una terminal con nmap -sV o un dashboard de SIEM puede formar parte de la evidencia, pero no explica por sí sola qué aprendiste ni qué problema resolviste. El valor aparece cuando conectas contexto, hipótesis, método, evidencias, resultado y límites.

Un proyecto sencillo bien razonado suele ser más fácil de evaluar que una colección grande de screenshots sin narrativa técnica.

Una estructura reutilizable para documentar proyectos #

La siguiente secuencia es un modelo pedagógico propio de Achirou para documentar laboratorios; no es un estándar oficial ni una plantilla obligatoria.

Marco pedagógico de 8 pasos

1. Problema: ¿Qué querías investigar, detectar, corregir o demostrar?
2. Alcance y entorno: Máquinas, SO, red, datos de prueba, autorizaciones y limitaciones.
3. Objetivo: Qué resultado observable esperabas obtener.
4. Método: Pasos, herramientas y decisiones, explicando por qué las elegiste.
5. Evidencia: Logs, consultas, reglas, código, capturas o artefactos necesarios para sostener el análisis.
6. Resultado: Qué observaste y qué parte de la hipótesis se confirmó o descartó.
7. Mitigación o mejora: Qué cambiarías para reducir el problema o mejorar la detección.
8. Límites y aprendizaje: Qué no demuestra el laboratorio y qué probarías después.

Proyectos de portfolio para Blue Team y analista SOC #

Si te interesa la defensa, utiliza el Blue Team roadmap para situar cada proyecto dentro de una ruta más amplia. Si tu objetivo concreto es SOC, la guía para convertirse en analista SOC profundiza en investigación, telemetría y triage.

Ideas de proyectos defensivos

P1: Laboratorio SIEM: ingesta de telemetría Windows/Linux, creación de una detección, validación con eventos controlados y análisis de falsos positivos.
P2: Detección de intentos repetidos de autenticación: define un criterio reproducible, genera actividad de prueba y documenta cuándo una alerta sería útil y cuándo produciría ruido. Si automatizas una respuesta, hazlo solo en un laboratorio aislado.
P3: Timeline con Sysmon: correlaciona Event ID 1 (Process Create) y Event ID 3 (Network Connect). Microsoft indica que el evento 3 está deshabilitado de forma predeterminada, por lo que debes habilitarlo y filtrarlo conscientemente.
P4: Mapeo MITRE ATT&CK: simula en un host de laboratorio una ejecución de PowerShell y documenta por qué corresponde a T1059.001 — PowerShell, qué telemetría lo evidencia y qué no puedes inferir solo con ese mapeo.
P5: Análisis de phishing con muestras seguras: examina cabeceras de mensaje conforme al formato actual de RFC 5322, autenticación de correo y artefactos sanitizados, sin publicar datos personales ni contenido sensible.

Proyectos de portfolio para Red Team y Pentesting #

En ofensiva, el portfolio debe demostrar alcance autorizado, metodología, evidencia y remediación, no solo que una explotación funcionó. Puedes profundizar con la ruta Red Team y la guía para ser pentester.

Ideas de proyectos ofensivos — solo entornos propios o autorizados

P1: Write-up metodológico de un laboratorio: alcance → reconocimiento → enumeración → validación → evidencia → remediación. Explica también qué pruebas decidiste no realizar y por qué.
P2: Auditoría de OWASP Juice Shop: utiliza esta aplicación deliberadamente insegura de OWASP para documentar una vulnerabilidad, su causa, evidencia controlada y una propuesta de corrección.
P3: Informe ejecutivo y técnico: separa hallazgo, impacto, evidencia y remediación. Si asignas severidad, identifica la versión: CVSS v4.0 es la versión oficial vigente de FIRST. CVSS expresa severidad técnica y no sustituye por sí solo una valoración completa del riesgo del negocio.
P4: Active Directory en laboratorio local: construye un dominio de prueba y documenta una técnica controlada, la telemetría que deja y las medidas defensivas asociadas. No uses infraestructura ajena ni credenciales reales.

Proyectos de portfolio para Application Security (AppSec) #

Si tienes base en programación aplicada a ciberseguridad, AppSec permite demostrar tanto análisis como capacidad de corregir código:

Vulnerabilidad + fix: crea o usa una aplicación de laboratorio, explica la causa raíz, añade una prueba reproducible y muestra el cambio que corrige el problema.
Threat modeling: documenta activos, límites de confianza, flujos de datos, amenazas y decisiones de diseño. STRIDE puede ser una técnica útil, pero no es la única posible.
Pipeline con controles de seguridad: integra una comprobación SAST y un análisis de dependencias. OWASP Dependency-Check es una herramienta SCA para identificar dependencias y vulnerabilidades públicas conocidas.

Proyectos de portfolio para Gobernanza, Riesgo y Cumplimiento (GRC) #

Un portfolio de GRC puede demostrar criterio sin depender de código. El objetivo no es afirmar que una organización ficticia “cumple” una norma, sino enseñar cómo estructuras riesgos, controles, evidencias, decisiones y límites.

Registro de riesgos ficticio: define contexto, activos, escenarios, criterios de valoración y tratamientos, indicando que la metodología elegida es un ejercicio de laboratorio.
Política y evidencias: redacta una política de control de acceso o trabajo remoto y acompáñala con ejemplos de evidencias que permitirían revisar su aplicación.
Gap analysis educativo: selecciona un marco o norma, cita las fuentes que realmente puedes consultar y diferencia requisito, estado observado, evidencia y acción pendiente. No presentes el ejercicio como auditoría oficial o certificación.

Proyectos prácticos de Python y automatización de seguridad #

Un proyecto de Python para ciberseguridad gana valor cuando automatiza una tarea concreta y deja claro qué entradas acepta, qué errores controla y qué resultado produce.

Parser de logs: procesa registros de prueba, aplica umbrales configurables y exporta resultados en JSON o CSV. Evita presentar un umbral arbitrario como regla universal de detección.
Enriquecedor de IoCs: consulta servicios autorizados respetando sus términos y límites de petición, maneja errores y conserva trazabilidad de la fuente.
Comprobador de cabeceras HTTP: identifica cabeceras observadas y explica su contexto; evita convertir la presencia o ausencia de una sola cabecera en una puntuación absoluta de “seguridad”.

Si tu especialidad es defensiva y quieres convertir automatización en un proyecto de portfolio, el curso de automatización de ciberseguridad con n8n e IA puede servir como complemento práctico; no es un prerrequisito para construir un buen portfolio.

Cómo transformar un CTF o reto en un proyecto útil #

Completar un reto no convierte automáticamente la solución en un proyecto. Un write-up útil explica la hipótesis inicial, las pistas relevantes, las decisiones que funcionaron, los callejones sin salida y el concepto técnico aprendido. Antes de publicar, comprueba también las reglas de la plataforma: algunos retos o competiciones limitan cuándo y cómo pueden difundirse soluciones.

Si quieres practicar con este formato, consulta qué es un CTF y cómo utilizarlo para aprender hacking ético.

Práctica ofensiva autorizada

Hacking Ético Avanzado: prácticas en Kali Linux y retos CTF

Úsalo como laboratorio para practicar y después documentar metodología, evidencias, límites y aprendizaje en proyectos propios.

GitHub para ciberseguridad: cómo escribir un README que se pueda evaluar #

GitHub recomienda crear un README para cada repositorio para facilitar que otras personas entiendan y naveguen el proyecto. No existe un “README perfecto”; utiliza una estructura que permita reproducir y revisar tu trabajo:

# Nombre del proyecto
## 1. Problema y objetivo
## 2. Alcance, autorización y arquitectura del laboratorio
## 3. Prerrequisitos y datos de prueba
## 4. Método y decisiones técnicas
## 5. Evidencias relevantes
## 6. Resultado y validación
## 7. Mitigación o mejora
## 8. Limitaciones y próximos pasos
## 9. Fuentes y referencias

Si incluyes código, añade instrucciones suficientes para ejecutarlo con datos de prueba. Si el proyecto depende de una versión concreta de una herramienta, documenta esa versión para que el resultado sea reproducible.

Qué no debes publicar en un portfolio público #

Checklist antes de hacer público un repositorio

1. Secretos y credenciales: no publiques API keys, contraseñas, claves privadas, tokens, cookies de sesión ni archivos .env con valores reales. .gitignore ayuda a prevenir commits accidentales, pero no elimina secretos que ya entraron en el historial.
2. Datos de terceros: no publiques logs corporativos, IP internas, datos personales, tickets, capturas o configuraciones que no estés autorizado a divulgar.
3. Evidencia ofensiva: limita las pruebas a sistemas propios, laboratorios y plataformas donde tengas autorización explícita.
4. Controles de GitHub: utiliza las funciones de seguridad disponibles. GitHub recomienda secret scanning, push protection, Dependabot y code scanning para repositorios públicos, según disponibilidad y configuración.
5. Si un secreto se filtró: no basta con borrar el archivo del último commit; rota o revoca la credencial y revisa el historial.

Cómo conectar el portfolio con tu CV y la entrevista #

El portfolio es evidencia; el CV y la entrevista son superficies distintas. En el CV, selecciona los proyectos más relevantes para la vacante y resume problema + acción + resultado + enlace. La guía de cómo hacer un CV de ciberseguridad sin experiencia desarrolla esa parte de la candidatura.

En entrevista, prepárate para defender decisiones: por qué escogiste esa fuente de logs, qué falsos positivos puede generar una regla, qué limitaciones tiene tu laboratorio y cómo validarías el resultado en un entorno distinto. Puedes practicar esa transición con la guía de preguntas técnicas para entrevistas de ciberseguridad junior.

Cómo transformar un tutorial en trabajo propio #

Seguir una guía es válido para aprender. Para convertirla en evidencia propia, añade una decisión que requiera criterio: cambia la fuente de datos, formula otra hipótesis, compara dos enfoques, mide falsos positivos, añade pruebas automatizadas o documenta por qué una solución falla en determinadas condiciones.

Lo importante es que puedas señalar qué parte reprodujiste y qué parte diseñaste, validaste o interpretaste tú. Esto evita presentar trabajo ajeno como propio y convierte el tutorial en punto de partida, no en producto final.

Fuentes técnicas verificadas #

GitHub Docs: best practices for repositories y push protection.
Microsoft Sysinternals: eventos Sysmon, incluidos Event ID 1 y Event ID 3.
MITRE ATT&CK: T1059.001 — PowerShell.
FIRST: CVSS v4.0 para severidad técnica de vulnerabilidades.
OWASP: Juice Shop como aplicación deliberadamente insegura para entrenamiento y Dependency-Check como herramienta SCA.
RFC Editor: RFC 5322 — Internet Message Format, que sustituyó a RFC 2822 y este a RFC 822.

Conclusión: construye evidencia que puedas defender #

No existe un número universal de proyectos que garantice empleo. Prioriza una selección pequeña y relevante que puedas explicar con profundidad antes que una lista larga de repositorios que apenas recuerdas.

Elige una especialidad → define un problema → trabaja en un entorno autorizado → documenta evidencia → explica límites → conecta el proyecto con tu candidatura

El objetivo del portfolio no es parecer experto en todo. Es permitir que otra persona revise una muestra de tu trabajo y pueda preguntarte sobre decisiones reales que tú mismo tomaste.

Portfolio de ciberseguridad: proyectos para demostrar lo que sabes