# data[].attributes.body
Hernández, M. (2020). Ciclo de vida de desarrollo ágil de software seguro (pp. 39-102). Fundación Universitaria Los Libertadores

Microsoft. (2022, agosto 25). Microsoft Threat Modeling Tool – STRIDE model. Microsoft Learn. https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats

OWASP. (2021). Threat Modeling. OWASP Foundation. https://owasp.org/www-community/Threat_Modeling

OWASP. (2023). Secure Software Development Lifecycle Project. OWASP Foundation. https://owasp.org/www-project-secure-software-development-lifecycle/

TryHackMe. (2023). Microsoft STRIDE Framework Explained | Threat Modeling [Video]. YouTube. https://www.youtube.com/watch?v=tKqcry-ntWk

SonarCloud. (2024). Continuous inspection of code quality and security. SonarSource. https://sonarcloud.io

# data[].attributes.body
A lo largo del desarrollo de la aplicación de agenda de amigos, se evidenció que es posible construir software seguro incluso en proyectos pequeños, siempre que se apliquen prácticas adecuadas desde las primeras etapas del ciclo de vida del desarrollo.

El uso del modelo de amenazas STRIDE permitió anticipar riesgos y tomar decisiones técnicas orientadas a la prevención de vulnerabilidades, como la sanitización de entradas, la validación de datos y el cifrado de información sensible. Estas acciones, aunque simples, son fundamentales para evitar suplantaciones, manipulaciones o fugas de información.

Se integró la herramienta SonarCloud para realizar un análisis automatizado del código, lo cual permitió verificar la calidad, mantener un control de versiones seguro y detectar posibles errores estructurales antes de su despliegue.

El enfoque estandarizado, apoyado en buenas prácticas de validación, componentes seguros y control visual, permitió garantizar que la aplicación sea confiable, clara para el usuario y resistente ante posibles fallos.

En conclusión, el desarrollo seguro no depende del tamaño del proyecto, sino del compromiso por aplicar metodologías, modelos y herramientas adecuadas. Este ejercicio práctico demuestra que la seguridad no debe verse como un paso adicional, sino como un componente esencial y transversal del proceso de desarrollo de software.

# data[].attributes.headline
Análisis de seguridad del código con SonarCloud

# data[].attributes.subject
Análisis de seguridad del código con SonarCloud

# data[].attributes.body
Para fortalecer la seguridad de la aplicación de agenda, se integró la herramienta SonarCloud, una plataforma en la nube que permite analizar automáticamente el código fuente para detectar errores, vulnerabilidades, duplicación y malas prácticas de programación.

El análisis se realizó utilizando GitHub Actions, lo que permite que cada vez que el código se actualiza, se ejecute automáticamente una revisión completa sin intervención manual. Este proceso automatizado es parte de las buenas prácticas del ciclo de vida del desarrollo de software seguro (SSDLC).

Resultados del análisis:

No se encontraron vulnerabilidades ni problemas críticos.

Se verificó la mantenibilidad del código y la correcta estructura lógica.

El análisis arrojó una calificación satisfactoria en los ejes de seguridad, fiabilidad y limpieza del código.

La integración de SonarCloud no solo permitió validar la calidad del desarrollo, sino que dejó una evidencia clara y objetiva de que se siguieron estándares de codificación seguros.

# data[].attributes.body
Esta amenaza se da cuando un usuario accede a funcionalidades que no debería tener disponibles. Aunque la app actual no gestiona roles ni permisos, se diseñó con principios de mínimo privilegio.

Medidas previstas:

Se evalúa una arquitectura futura donde cada usuario tenga un rol (ej. invitado, editor, administrador), y los permisos se asignen de acuerdo al rol.

Se implementarán restricciones para que solo usuarios autorizados puedan editar o eliminar contactos.

# data[].attributes.body
Esta amenaza se refiere a la posibilidad de que un atacante intente saturar la aplicación enviando datos masivos, repetitivos o malformados que hagan que el sistema deje de responder.

Medidas aplicadas:

Se controla la longitud de los campos de entrada (por ejemplo, máximo 50 caracteres en el nombre).

Se evita el ingreso masivo mediante validaciones sincronizadas y mensajes claros al usuario.

Se bloquea la posibilidad de añadir registros sin pasar por todas las validaciones, evitando automatización simple desde consola.

# data[].attributes.body
Una de las amenazas más relevantes para esta aplicación. La exposición no autorizada de datos personales, como el número de teléfono o correo electrónico, podría tener consecuencias reales para los usuarios.

Medidas aplicadas:

El número de celular se cifra utilizando la librería cryptography, evitando que se almacene en texto plano.

En la interfaz gráfica, el dato cifrado no se muestra directamente; se presenta un mensaje genérico como “[Teléfono cifrado]”.

Se proyecta el uso de cifrado completo de datos en almacenamiento persistente en versiones futuras, especialmente si se guarda información en bases de datos o archivos.

# data[].attributes.body
El repudio sucede cuando un usuario niega haber realizado una acción y no existe forma técnica de probar lo contrario. En la app de agenda, aunque no se gestionan cuentas de usuario ni registros de actividad por ahora, se considera esta amenaza en el diseño futuro.

Medidas consideradas:

Se plantea incluir un sistema de auditoría que registre cada acción (crear, editar o eliminar un contacto) junto con fecha, hora y usuario responsable.

Se evalúa incorporar logs firmados digitalmente para garantizar la trazabilidad.

# data[].attributes.body
Esta amenaza se relaciona con la modificación maliciosa de datos, ya sea desde el cliente (frontend) o en el sistema de almacenamiento. En esta app, aunque los datos no se envían a un servidor, se aplicaron prácticas para evitar la manipulación desde el navegador o el código.

Medidas aplicadas:

Se implementó una función de sanitización de las entradas, eliminando caracteres especiales que podrían usarse para inyectar código (como <, >, ', ").

Se establecieron límites de longitud para cada campo, evitando entradas excesivas que puedan alterar el comportamiento del sistema o generar errores intencionales.

Se rechazan campos numéricos o de formato incorrecto, como correos sin arroba o celulares con letras.

# data[].attributes.headline
🛡️ E – Elevation of Privilege (Elevación de privilegios)

# data[].attributes.subject
🛡️ E – Elevation of Privilege (Elevación de privilegios)

# data[].attributes.body
Cuando un usuario logra acceder a funciones o datos que no debería.

Ejemplo real: Un usuario sin autorización logra modificar datos internos o acceder a funciones de administrador.

# data[].attributes.headline
❌ D – Denial of Service (Denegación de servicio)

# data[].attributes.subject
❌ D – Denial of Service (Denegación de servicio)

# data[].attributes.body
Cuando un atacante sobrecarga el sistema para que los usuarios legítimos no puedan usarlo.

Ejemplo real: Enviar miles de registros con datos excesivos para ralentizar o bloquear la app.

# data[].attributes.headline
🔓 I – Information Disclosure (Divulgación de información)

# data[].attributes.subject
🔓 I – Information Disclosure (Divulgación de información)

# data[].attributes.body
Acceso no autorizado a datos sensibles.

Ejemplo real: Almacenar y mostrar números de teléfono sin protección podría permitir que alguien acceda a información personal.

# data[].attributes.body
Es cuando un usuario niega haber realizado una acción y no existen pruebas suficientes para demostrarlo.

Ejemplo real: Un usuario niega haber agregado un contacto, pero no hay registros que lo confirmen.

# data[].attributes.headline
✏️ T – Tampering (Manipulación de datos)

# data[].attributes.subject
✏️ T – Tampering (Manipulación de datos)

# data[].attributes.body
Modificar datos sin autorización, ya sea al enviarlos o almacenarlos.

Ejemplo real: Si alguien manipula los datos del formulario para inyectar scripts (XSS) o comandos peligrosos.

# data[].attributes.headline
🔒 S – Spoofing (Suplantación de identidad)

# data[].attributes.subject
🔒 S – Spoofing (Suplantación de identidad)

# data[].attributes.body
Cuando un atacante finge ser otra persona o sistema para obtener acceso o manipular información.

Ejemplo real: Cuando alguien intenta registrarse usando el nombre o correo de otra persona para hacerse pasar por ella.

# data[].attributes.body
Esta amenaza ocurre cuando un usuario intenta hacerse pasar por otro para acceder a información o funcionalidades que no le corresponden. Aunque la aplicación no incluye un sistema de autenticación aún, se establecieron controles para reducir el riesgo de suplantación desde las entradas de datos.

Medidas aplicadas:

Se validan todos los campos del formulario para evitar entradas vacías o manipuladas.

Se impide el registro de contactos con datos repetidos, especialmente correos electrónicos.

Se prevé que en futuras versiones se implemente autenticación con contraseña para usuarios y control de sesiones.

# data[].attributes.body
Como parte del proceso de aprendizaje sobre desarrollo de software seguro, se implementó un caso práctico: una aplicación de agenda de amigos desarrollada en Python con Flet, en la que se integraron principios de seguridad desde las fases iniciales del proyecto.

El objetivo fue demostrar cómo se puede construir una aplicación sencilla aplicando técnicas estandarizadas de protección y validación, sin necesidad de un sistema complejo. Para ello, se utilizaron herramientas como el modelo de amenazas STRIDE, validaciones robustas en los formularios, cifrado de datos sensibles y análisis automático del código fuente.

El desarrollo de esta aplicación permitió comprender que la seguridad no debe ser un añadido al final del proceso, sino una práctica constante durante la planificación, codificación y validación. A través de este mural, se evidencian las decisiones tomadas para garantizar la integridad, confidencialidad y confiabilidad del software construido.

# data[].attributes.attachment_link.title
Microsoft STRIDE Framework Explained | Threat Modeling | TryHackMe

# data[].attributes.body
El modelo STRIDE es una metodología desarrollada por Microsoft que permite identificar amenazas de seguridad en aplicaciones desde la etapa de diseño. Cada letra de STRIDE representa una categoría distinta de riesgo.

STRIDE no es una lista estática, sino una guía activa para hacer preguntas durante el diseño: ¿qué pasaría si alguien se hiciera pasar por otro usuario?, ¿si modificara los datos?, ¿si accediera a información que no le corresponde? Al responder estas preguntas y aplicar medidas concretas, el equipo de desarrollo puede crear sistemas mucho más resistentes y confiables.

El video “Microsoft STRIDE Framework Explained” ofrece una introducción clara al modelo STRIDE, utilizado para anticipar amenazas en el diseño de software. En apenas pocos minutos se explican las seis categorías de riesgo (suplantación, manipulación, repudio, divulgación, denegación y elevación de privilegios), y cómo este enfoque ayuda a fortalecer la arquitectura desde el inicio.

# data[].attributes.headline
 Introducción: ¿Por qué desarrollar software seguro?

# data[].attributes.subject
 Introducción: ¿Por qué desarrollar software seguro?

# data[].attributes.body
Desarrollar software seguro de forma estandarizada es una necesidad actual. La seguridad no debe ser un añadido al final, sino parte de todo el proceso de desarrollo.

Cuando se omiten buenas prácticas, las aplicaciones pueden ser vulnerables a ataques, filtraciones o daños.

En este mural se muestra cómo implementar un software seguro desde la planeación hasta la ejecución, aplicando el modelo de amenazas STRIDE y técnicas reales de validación, análisis y cifrado, usando como ejemplo una aplicación de agenda de amigos.