Saltar al contenido
Open Security

Portafolio técnico

Construí evidencia, no una lista de herramientas.

Un buen portafolio no dice "sé ciberseguridad" o "sé backend". Muestra repos, writeups, diagramas, tests, logs y decisiones técnicas. Estos proyectos están pensados para demostrar criterio sin tocar datos reales ni sistemas de terceros.

portfolio.manifest

briefs7
hechos0/7
evidenciarepo/writeup/logs
scopelocal/ficticio

Elegí uno, hacelo chico, documentá los límites y dejá algo que se pueda revisar sin una reunión de media hora.

BRIEF_01/Ciberseguridad

Threat model de una app chica

Elegí una app simple y documentá activos, trust boundaries, amenazas, impacto y mitigaciones realistas.

Intermedio1 semana

Por qué sirve

Muestra criterio defensivo. No es tirar herramientas: es entender qué puede fallar, cuánto importa y qué control baja el riesgo.

Cómo contarlo en 30 segundos

“Modelé amenazas de una app chica: qué puede fallar, cuánto importa y qué mitigación aplicaría primero. Diagrama, tabla priorizada y tradeoffs documentados.”

Qué construir

  1. 01Definí una app de juguete: usuarios, sesiones, panel admin, API y base de datos falsa.
  2. 02Dibujá un DFD simple con usuarios, backend, storage, servicios externos y trust boundaries.
  3. 03Aplicá STRIDE o una matriz propia: amenaza, escenario, impacto, probabilidad y mitigación.
  4. 04Elegí 3 riesgos y escribí cómo los detectarías en logs o métricas.

Evidencia

  • Diagrama del sistema y trust boundaries.
  • Tabla de amenazas priorizada.
  • Writeup con mitigaciones y tradeoffs.
  • Checklist de logs que mirarías durante un incidente.

Entregables

  • README.md con contexto, alcance y supuestos.
  • docs/threat-model.md con tabla de amenazas.
  • docs/diagram.md o PNG/SVG del diagrama.

Labs que te preparan

Threat modeling de una app chicaXSS local defensivo: source, sink y output encodingJWT no es autorización

Evitá

  • No uses datos reales ni nombres de empresas reales.
  • No vendas esto como pentest profesional.
  • No agregues exploits listos contra servicios públicos.
CiberseguridadBackend
BRIEF_02/Backend seguro

API con permisos reales

Construí una API chica donde autenticación, autorización, validación y errores estén pensados desde el diseño.

Intermedio1-2 semanas

Por qué sirve

Para backend, seguridad se ve en decisiones concretas: endpoints, permisos, tests, logs y fallos bien contenidos.

Cómo contarlo en 30 segundos

“Construí una API donde autorización, validación y errores están diseñados y testeados: los tests demuestran que un usuario no puede tocar recursos de otro.”

Qué construir

  1. 01Creá una API de tareas, tickets o notas con roles user/admin y datos ficticios.
  2. 02Separá authn de authz: estar logueado no implica poder tocar cualquier recurso.
  3. 03Agregá tests que prueben IDOR, permisos cruzados, input inválido y errores esperados.
  4. 04Documentá decisiones: por qué esos roles, qué queda fuera de alcance y cómo se audita.

Evidencia

  • Repo ejecutable en local con datos seed falsos.
  • Tests de permisos pasando.
  • README con matriz de endpoints y roles.
  • Ejemplos de logs sin secretos ni datos sensibles.

Entregables

  • src/ con API mínima y tests.
  • docs/permissions-matrix.md.
  • docs/failure-modes.md con errores esperados.

Labs que te preparan

API HTTP base: método, recurso, status y content-typeIDOR: el ataque de cambiar un númeroJWT no es autorizaciónSQL injection defensiva: queries parametrizadas

Evitá

  • No guardes tokens reales en .env ni en screenshots.
  • No uses permisos admin como solución rápida.
  • No ocultes errores con catch genéricos sin observabilidad.
BackendCiberseguridad
BRIEF_03/Cloud / producción

Arquitectura cloud mínima con evidencia

Diseñá una arquitectura AWS pequeña con IAM mínimo, storage privado, logs, diagrama y costo estimado.

Intermedio1 semana

Por qué sirve

Sirve para mostrar criterio de producción sin necesitar una infraestructura grande ni gastar plata de más.

Cómo contarlo en 30 segundos

“Diseñé una arquitectura AWS mínima con IAM de mínimo privilegio, logs que confirman cada acción importante y una estimación de costos con plan de cleanup.”

Qué construir

  1. 01Diseñá el sistema antes de desplegar: usuarios, permisos, red, storage, logs y blast radius.
  2. 02Escribí políticas IAM mínimas con recursos ficticios o ejemplos claramente redactados.
  3. 03Incluí CloudTrail/CloudWatch en el diseño y explicá qué evento confirma cada acción importante.
  4. 04Estimá costos y marcá qué apagarías primero si esto fuera un lab temporal.

Evidencia

  • Diagrama de arquitectura.
  • Políticas IAM de ejemplo sin account IDs reales.
  • Tabla de eventos/logs esperados.
  • Cost estimate y cleanup plan.

Entregables

  • docs/architecture.md.
  • docs/iam-policy-example.json con placeholders.
  • docs/cost-and-cleanup.md.

Labs que te preparan

AWS desde cero: región, ARN, CLI y credenciales falsasIAM: leer una policy antes de que te muerdaVPC y Security Groups: quién puede hablar con quiénCloudTrail: quién hizo qué en AWS

Evitá

  • No publiques ARNs, account IDs, buckets reales ni screenshots de consola con datos privados.
  • No dejes recursos vivos sin cleanup.
  • No uses credenciales root ni access keys hardcodeadas.
CloudRedes
BRIEF_04/Linux / infra

Hardening y auditoría de un servidor Linux

Armá una VM local, revisá usuarios, permisos, servicios, firewall, logs y dejá un checklist reproducible.

Inicial2-4 tardes

Por qué sirve

Es un proyecto simple pero potente: demuestra que entendés el sistema operativo y podés explicar cada control.

Cómo contarlo en 30 segundos

“Hice hardening de un servidor Linux descartable y dejé un script de auditoría read-only que explica cada control, con evidencia before/after.”

Qué construir

  1. 01Levantá una VM o contenedor local descartable con usuarios y servicios de juguete.
  2. 02Inventariá procesos, puertos abiertos, permisos inseguros y logs relevantes.
  3. 03Aplicá hardening básico: usuarios, sudo, SSH local, firewall y permisos de archivos.
  4. 04Escribí un script de auditoría que no modifique nada y explique cada chequeo.

Evidencia

  • Checklist before/after.
  • Salida redactada de comandos como ss, id, journalctl y systemctl.
  • Script de auditoría read-only.
  • Notas de tradeoffs: seguridad vs operación.

Entregables

  • audit.sh o scripts/audit.sh.
  • docs/hardening-checklist.md.
  • docs/evidence.md con salidas sintéticas o de lab local.

Labs que te preparan

Permisos, usuarios y procesos: la base real de Linuxsystemd y journalctl: por qué un servicio no arrancaPor qué chmod 777 es un problema, no una solución

Evitá

  • No ejecutes comandos destructivos como parte del script.
  • No publiques logs reales de tu máquina principal.
  • No recomiendes chmod 777 ni permisos amplios como arreglo.
LinuxCiberseguridad
BRIEF_05/DevSecOps

Pipeline que bloquea errores comunes

Configurá CI con permisos mínimos, secret scanning, checks de formato/tests y una explicación de qué bloquea cada paso.

Intermedio1 semana

Por qué sirve

Muestra seguridad aplicada al flujo real de desarrollo: prevención, feedback temprano y límites de permisos.

Cómo contarlo en 30 segundos

“Armé un pipeline de CI con permisos mínimos que bloquea secretos y errores comunes antes del merge, con un reporte de qué bloquea cada paso y por qué.”

Qué construir

  1. 01Creá un repo de ejemplo con una app mínima o scripts de juguete.
  2. 02Agregá GitHub Actions con permisos explícitos y jobs separados por responsabilidad.
  3. 03Incluí secret scanning con secretos falsos de prueba y documentá el resultado esperado.
  4. 04Sumá un reporte simple: qué pasó, qué se bloqueó y qué falso positivo aceptarías.

Evidencia

  • Workflow YAML revisable.
  • Captura o log de un check bloqueando un secreto falso.
  • README explicando permisos del pipeline.
  • Lista de limitaciones y próximos controles.

Entregables

  • .github/workflows/security.yml.
  • docs/pipeline-controls.md.
  • docs/test-secret-example.md con credenciales claramente falsas.

Labs que te preparan

GitHub Actions: el secreto que terminó en los logsSecret scanning: el token que se te escapó al repoSBOM básico: inventario de dependencias que sí sirve

Evitá

  • No subas secretos reales para probar el scanner.
  • No le des permissions: write-all al workflow por comodidad.
  • No ocultes qué controles son preventivos y cuáles son solo informativos.
DevSecOpsBackend
BRIEF_06/Blue team / detección

Detección con logs locales (mini SOC)

Generá actividad sospechosa de juguete en un entorno descartable y escribí reglas de detección sobre logs reales del sistema, con casos de prueba.

Intermedio1 semana

Por qué sirve

Detección es la mitad del trabajo defensivo que casi nadie muestra: probás que entendés qué rastros deja cada acción y cómo separar señal de ruido.

Cómo contarlo en 30 segundos

“Escribí reglas de detección sobre logs del sistema con casos de prueba que disparan cada alerta, y documenté falsos positivos y puntos ciegos.”

Qué construir

  1. 01Levantá una VM o contenedor descartable y generá actividad normal más acciones sospechosas de juguete (sudo fallidos, procesos inesperados, descargas raras).
  2. 02Definí 4-6 reglas de detección sobre journalctl/auditd: patrón, por qué importa y qué falso positivo esperás.
  3. 03Automatizá las reglas en un script que lea logs y emita eventos con severidad y contexto.
  4. 04Escribí un caso de prueba reproducible por regla: el comando que dispara la alerta y la salida esperada.

Evidencia

  • Tabla de reglas: patrón, severidad, fuente del log y falsos positivos conocidos.
  • Script de detección con salida de ejemplo.
  • Transcripción de un caso de prueba disparando cada regla.
  • Writeup honesto: qué NO detecta y cómo lo mejorarías.

Entregables

  • scripts/detect.sh o scripts/detect.py.
  • docs/detection-rules.md.
  • docs/test-cases.md con comandos reproducibles.

Labs que te preparan

systemd y journalctl: por qué un servicio no arrancaCloudTrail: quién hizo qué en AWSGitHub Actions: el secreto que terminó en los logs

Evitá

  • No corras malware real: simulá los comportamientos con acciones inofensivas.
  • No uses logs de tu máquina personal ni de sistemas de terceros.
  • No prometas cero falsos positivos: documentarlos vale más que ocultarlos.
LinuxDevSecOps
BRIEF_07/Agentes / seguridad moderna

Agente con permisos acotados y approval gate

Diseñá un workflow donde un agente puede leer, proponer cambios y pedir aprobación antes de acciones riesgosas.

Avanzado1-2 semanas

Por qué sirve

Cada vez más equipos usan agentes. El diferencial es mostrar que pensás en permisos, auditoría y límites operativos.

Cómo contarlo en 30 segundos

“Diseñé un agente con permisos acotados y approval gate: puede leer y proponer, pero toda acción riesgosa pasa por aprobación humana y queda auditada.”

Qué construir

  1. 01Definí un caso seguro: agente que revisa archivos de ejemplo y propone un patch.
  2. 02Separá acciones read-only, write, network y deploy aunque el prototipo sea simple.
  3. 03Agregá un approval gate antes de escribir archivos o ejecutar comandos sensibles.
  4. 04Guardá un log auditable: instrucción, acción propuesta, aprobación y resultado.

Evidencia

  • Modelo de permisos por acción.
  • Demo con aprobación humana antes de una acción de riesgo.
  • Log de auditoría sintético.
  • README con amenazas y límites del agente.

Entregables

  • docs/agent-permissions.md.
  • docs/approval-flow.md.
  • examples/audit-log.json con datos ficticios.

Labs que te preparan

Un agente no debería tocar archivos a ciegasDocker image hardening: non-root, capabilities y filesystem

Evitá

  • No le des acceso libre al filesystem o a red sin justificarlo.
  • No ejecutes comandos arbitrarios sugeridos por input externo.
  • No presentes el agente como seguro sin explicar límites y supuestos.
DevSecOpsCiberseguridad

Presentación

Cómo hacer que el repo hable por vos

El objetivo no es que el proyecto sea enorme. Es que sea claro, verificable y honesto sobre sus límites.

01

README que se entiende

Contexto, objetivo, alcance, cómo correrlo, evidencia y decisiones. Si alguien entra al repo, no debería adivinar qué está mirando.

02

Evidencia reproducible

Comandos, screenshots, diagramas, tests o logs sintéticos. No alcanza con decir que funciona: dejá rastros claros.

03

Límites explícitos

Qué no cubre, qué datos son ficticios, qué harías distinto en producción y qué tradeoffs aceptaste.

$ practicar con los labsver tu progreso

Marcá los briefs que termines: el progreso queda en tu navegador, sin login.