Política de Ciclo de Vida Seguro de Desarrollo (SSDLC)

Política operativa interna. Integra la seguridad en cada fase del ciclo de vida del software de Lawra, S.R.L., desde el diseño hasta el retiro. Adaptada para plataformas que integran Modelos de Lenguaje de Gran Escala (LLM). Aprobada por la Asamblea en [__]. Versión: 1.0.

---

1. Propósito y Alcance

1.1. Esta política establece los controles de seguridad que deben aplicarse durante el diseño, desarrollo, prueba, despliegue y mantenimiento del software de Lawra, S.R.L., con el objetivo de identificar y mitigar vulnerabilidades antes de que lleguen a producción.

1.2. Soporta los controles SOC 2 CC7.1 (Design and Implementation of Security Controls) y CC8.1 (Changes to Infrastructure, Data, and Software).

1.3. — Aplica a:

• Todo el código fuente del sitio web y componentes de IA (Astro, Svelte, TypeScript, Firebase).
• Configuraciones de infraestructura (Firebase, Firestore rules, GitHub Actions).
• Integraciones con APIs externas (Gemini AI, Google Cloud).
• Scripts, herramientas internas y código de automatización.

1.4. — Referencia de amenazas: Esta política se alinea con:

• OWASP Top 10 (2021) para aplicaciones web generales.
• OWASP LLM Top 10 (2025) para los componentes de IA generativa (Ask Lawra, Trial Simulator, Council of Jurists, Practice Tools).

---

2. Fases del SSDLC y Controles por Fase

2.1. Fase de Diseño y Planificación

2.1.1. — Threat Modeling (Modelado de Amenazas): Toda funcionalidad nueva que procese datos de clientes, exponga un nuevo endpoint de API, integre una nueva capacidad de LLM, o modifique el modelo de control de acceso debe pasar por un ejercicio de modelado de amenazas antes de comenzar el desarrollo. El CTO lidera el ejercicio; el autor de la feature participa.

El modelado de amenazas debe seguir el método STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) y producir:

• Diagrama de flujo de datos (DFD) básico.
• Lista de amenazas identificadas.
• Controles propuestos para cada amenaza.
• Riesgos aceptados (con justificación documentada).

El resultado se documenta en la PR o en el Issue de diseño correspondiente.

2.1.2. — Threat Modeling específico para LLM: Funcionalidades basadas en LLM adicionalmente deben evaluar:

• Prompt Injection (OWASP LLM01): ¿Puede un usuario manipular el prompt del sistema vía inputs de usuario?
• Insecure Output Handling (OWASP LLM02): ¿Se renderiza la salida del LLM de forma insegura (XSS, path traversal)?
• Training Data Poisoning (OWASP LLM03): ¿Se usa RAG o fine-tuning? ¿Qué datos entran al modelo?
• Sensitive Information Disclosure (OWASP LLM06): ¿Puede el LLM exponer datos de otros usuarios o de la configuración del sistema?
• Excessive Agency (OWASP LLM08): ¿Tiene el LLM acceso a herramientas que podrían causar daño si son mal invocadas?
• Overreliance (OWASP LLM09): ¿Se proveen disclaimers adecuados al usuario sobre las limitaciones del LLM?

2.2. Fase de Desarrollo

2.2.1. — Estándares de codificación segura: Todo el código de Lawra debe seguir las siguientes prácticas mínimas:

• Validación de inputs: Toda entrada del usuario es tratada como no confiable. Se valida en el servidor (Firestore Security Rules) y en el cliente (TypeScript types, Zod o equivalente donde aplique). No se acepta nunca un input de usuario como parte de una consulta a Firestore sin validación previa.
• Output encoding: Las salidas del LLM y de la base de datos que se insertan en el DOM se encodean apropiadamente. Se prohíbe innerHTML con contenido dinámico no sanitizado.
• No secrets en código: Ninguna clave de API, token, contraseña o secret puede existir hardcodeado en el código fuente. Ver sección 4 de esta política.
• Error handling: Los errores no deben exponer stack traces, rutas internas, o información sensible al usuario final.
• Logging seguro: No se loggean datos personales de usuarios (emails, nombres) ni contenido de conversaciones en logs de acceso general.
• Dependencias: Se prefieren librerías con mantenimiento activo, auditorías de seguridad conocidas, y licencias compatibles con el modelo de negocio.

2.2.2. — Seguridad en Firestore: Las reglas de Firestore (firestore.rules) son la última línea de defensa del lado del servidor. Deben:

• Denegar por defecto todo acceso no explícitamente permitido.
• Validar el tipo y formato de los datos escritos (no solo autenticación).
• Separar colecciones por nivel de sensibilidad.
• Ser revisadas por el CTO en todo cambio que las afecte.

2.2.3. — Seguridad en prompts del sistema LLM: Los prompts del sistema de Lawra (personas, simuladores, herramientas de práctica) son activos confidenciales. No se exponen al usuario final. Se almacenan en el código fuente (repositorio privado). Las referencias a datos de usuario en los prompts se hacen mediante interpolación controlada, no concatenación libre.

2.3. Fase de Revisión de Código

Ver change-management-policy para el proceso completo de PR review. El checklist de seguridad del revisor incluye:

• ¿Hay inputs de usuario usados sin validar en consultas, prompts o renderizado?
• ¿Hay secrets, PII o tokens hardcodeados o en logs?
• ¿Las reglas de Firestore cubren correctamente el nuevo acceso requerido?
• ¿El manejo de errores es apropiado (no expone información interna)?
• ¿El cambio introduce nuevas dependencias? ¿Fueron auditadas?
• ¿El cambio modifica la superficie de ataque del LLM (prompts, acceso a herramientas)?
• ¿Se aplican disclaimers adecuados en outputs de IA?

2.4. Fase de Testing

2.4.1. — Static Application Security Testing (SAST): Herramientas de SAST integradas en el pipeline de CI:

• GitHub Secret Scanning: Activo en todos los repositorios. Bloquea commits con patrones de secrets conocidos.
• npm audit: Ejecutado en cada CI run. Falla el build si hay vulnerabilidades de severidad high o critical.
• Dependabot: Configurado para abrir PRs automáticas de actualización de dependencias con vulnerabilidades conocidas. Revisión obligatoria en máximo 7 días para severidad alta/crítica.

2.4.2. — Dynamic Application Security Testing (DAST):

• Prueba manual de DAST al menos semestralmente, ejecutada por el CTO o un tercero designado, sobre el ambiente de staging o producción.
• Herramienta recomendada: OWASP ZAP (gratuita) o Burp Suite Community Edition.
• Resultados documentados y hallazgos incorporados al backlog de seguridad.

2.4.3. — Escaneo de secretos en repositorio:

• GitGuardian o herramienta equivalente configurada para escanear el historial completo del repositorio.
• Ante cualquier detección de secret en historial: rotar inmediatamente el secret afectado; evaluar si hubo exposición; remediar el historial de Git mediante git filter-repo si el secret es de alta sensibilidad.

2.5. Fase de Despliegue

Ver change-management-policy para el proceso de aprobación y despliegue. Adicionalmente:

• Las variables de entorno se gestionan mediante las variables cifradas de GitHub Actions (no en archivos .env en el repositorio).
• Los secretos de Firebase (API keys públicas del SDK cliente) se revisan periódicamente para asegurar que las restricciones de dominio y API están configuradas correctamente en Google Cloud Console.
• El despliegue de cambios a reglas de Firestore requiere revisión explícita del CTO.

2.6. Fase de Operación y Mantenimiento

2.6.1. — Gestión de vulnerabilidades en producción:

Severidad	SLA de remediación
Crítica (CVSS 9.0–10.0)	24 horas
Alta (CVSS 7.0–8.9)	72 horas
Media (CVSS 4.0–6.9)	30 días
Baja (CVSS < 4.0)	90 días o próximo sprint

2.6.2. — Monitoreo de dependencias: Dependabot activo. Revisión mensual del tablero de seguridad de GitHub por el CTO.

2.6.3. — Retiro de código: Funcionalidades retiradas deben eliminar las colecciones de Firestore correspondientes (con migración de datos si hay datos de cliente), revocar API keys asociadas, y actualizar la documentación de la arquitectura.

---

3. Penetration Testing

3.1. — Cadencia: Lawra realiza un penetration test externo anual realizado por un tercero independiente (no miembro del equipo de desarrollo). El scope incluye la aplicación web, los endpoints de API expuestos públicamente, y las reglas de Firestore.

3.2. — Scope mínimo:

• Autenticación y sesiones (Firebase Auth).
• Reglas de autorización de Firestore (prueba de acceso entre usuarios, escalada de privilegios).
• Prompt injection y manipulación de LLM en las herramientas de IA.
• XSS y CSP en la renderización de outputs del LLM.
• Exposición de información en respuestas de API.

3.3. — Gestión de hallazgos: Los hallazgos del pentest se clasifican por severidad y se integran al backlog de seguridad. Los hallazgos Críticos y Altos se remedian antes del siguiente pentest o en un plazo máximo de 90 días.

3.4. — Reporte: El reporte de pentest se almacena en la carpeta de cumplimiento SOC 2 con acceso restringido a socios y auditores autorizados.

---

4. Gestión de Secretos y Credenciales en Desarrollo

4.1. Ningún secret, API key, token, contraseña o credential puede existir en el código fuente del repositorio, incluyendo archivos .env comiteados.

4.2. — Variables de entorno en CI/CD: Las variables de entorno de producción se almacenan como GitHub Actions Secrets (cifradas en reposo por GitHub). Solo los workflows autorizados tienen acceso a ellas.

4.3. — Desarrollo local: Los desarrolladores usan un archivo .env.local (explícitamente excluido en .gitignore) para credenciales de desarrollo. El .gitignore del repositorio debe incluir siempre: .env, .env.*, *.secret, *.key.

4.4. Las Firebase API keys del SDK cliente son por diseño semi-públicas (restrictas por dominio y reglas de Firestore), pero deben tener las restricciones de dominio correctamente configuradas en Google Cloud Console.

4.5. Ante un secret expuesto accidentalmente en el repositorio: rotar inmediatamente el secret afectado (antes de intentar limpiar el historial), notificar al CTO, evaluar si el secret fue usado de forma maliciosa revisando los logs del servicio correspondiente.

---

5. Capacitación en Seguridad para Desarrolladores

5.1. — Onboarding: Todo nuevo miembro del equipo técnico completa antes de recibir acceso a los repositorios de producción:

• Lectura y firma de esta política y la infosec-policy.
• Revisión del checklist de seguridad de código de Lawra.
• Módulo introductorio de OWASP Top 10 (recurso gratuito en owasp.org) o equivalente.

5.2. — Refresher anual: Todo el equipo técnico completa anualmente:

• Actualización sobre OWASP Top 10 y OWASP LLM Top 10 (relevante dado el perfil de producto de Lawra).
• Revisión de incidentes de seguridad del año y lecciones aprendidas.
• Al menos 1 hora de formación en seguridad de aplicaciones (curso online, webinar, o sesión interna).

5.3. — Conocimiento LLM: Dado que Lawra es una plataforma LLM-intensiva, el equipo técnico debe estar familiarizado con los vectores de ataque específicos de IA generativa (OWASP LLM Top 10) y aplicarlos en el diseño y revisión de features.

---

6. Referencias Normativas y Técnicas

• SOC 2 Trust Services Criteria: CC7.1 (Design and Implementation of Security Controls), CC8.1 (Changes to Infrastructure)
• OWASP Top 10 (2021) — owasp.org/www-project-top-ten
• OWASP LLM Top 10 (2025) — owasp.org/www-project-top-10-for-large-language-model-applications
• NIST SP 800-64 — Security Considerations in the System Development Life Cycle
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
• ISO/IEC 27001:2022 — Anexo A, Controles 8.25–8.34 (Secure Development)
• Ley No. 53-07 (R.D.) — Crímenes y Delitos de Alta Tecnología
• change-management-policy — Política de Gestión de Cambios de Lawra
• access-control-policy — Política de Control de Acceso de Lawra
• incident-response-plan — Plan de Respuesta a Incidentes de Lawra

---

7. Revisión y Modificación

Esta política se revisa anualmente o ante cambios materiales en la arquitectura técnica, el stack de desarrollo, o la aparición de nuevas amenazas relevantes para plataformas LLM. Modificaciones requieren aprobación del CTO; modificaciones materiales requieren aprobación de la Asamblea.

Próxima revisión: [fecha de adopción + 12 meses].

---

Adoptada por la Asamblea General de Socios de LAWRA, S.R.L. en fecha [__], conforme consta en el Libro de Actas.

---

Por LAWRA, S.R.L. — Gerente