Security engineer

Skill Crypt0xDev/adaptive-ai-engineering-system/skills/security-engineer

Seguridad obligatoria y proporcional al riesgo. Usar en codigo con autenticacion, datos sensibles, APIs publicas o antes de lanzar.From its SKILL.md

Install

npx -y skills add Crypt0xDev/adaptive-ai-engineering-system --skill security-engineer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.5 KB, as published. Nobody here has run it

🔐 Security Engineer

Propósito

Garantizar la seguridad mínima obligatoria en todo código y la proporcional al riesgo del proyecto.

Cuándo se usa

Todo código que toque autenticación, autorización o datos sensibles.
Antes de cada lanzamiento (junto a playbooks/checklists/security-review.md).
Diseño de APIs públicas o integraciones con terceros.
Manejo de pagos o datos personales.

Cuándo NO se usa

Para bloquear un MVP con requisitos de seguridad de banca: la seguridad es proporcional al riesgo (los mínimos siempre; lo demás según contexto).
Auditorías de cumplimiento formal (SOC2, ISO): requieren especialistas humanos certificados; esta skill prepara, no certifica.

Entradas esperadas

El código o diseño a evaluar.
Tipo de datos que maneja el sistema (públicos, personales, de pago).
Superficie expuesta (API pública, multiusuario, interno).

Salida esperada

Lista de riesgos clasificados (crítico / alto / medio) + mitigación concreta para cada uno.

Reglas internas

Mínimos no negociables (toda etapa — ver `core/code-quality.md`)

Secretos en variables de entorno, nunca en el código.
HTTPS en todo.
Contraseñas hasheadas con bcrypt / argon2 (nunca texto plano, MD5, SHA1).
Validación de entradas en el límite del sistema; salidas escapadas según contexto.
Queries parametrizadas (prohibido concatenar SQL).
Sesiones con expiración, cookies HttpOnly/Secure/SameSite, regenerar al login, invalidar al logout.
Mínimo privilegio en BD, API keys y rutas admin.
Errores sin exponer información sensible (genérico al usuario, detalle al log).

Proporcional al riesgo

Datos personales o de pago → cifrado en reposo, auditoría, cumplimiento (GDPR / PCI).
API pública → rate limiting, auth robusta (OAuth2 / JWT con expiración).
Multiusuario → autorización por recurso en cada operación, no solo "está logueado".

Ejemplos de uso

Ejemplo 1: Endpoint GET /invoices/:id en app multiusuario. → Riesgo crítico: IDOR — cualquier usuario logueado puede leer facturas ajenas. → Mitigación: verificar que invoice.user_id == session.user_id en el servidor.

Ejemplo 2: MVP interno sin datos sensibles pide "pentest completo". → Evaluación: riesgo bajo, etapa temprana. → Salida: aplicar solo los mínimos no negociables; el pentest formal se justifica al exponer la API públicamente.