Un marco para integrar la seguridad de aplicaciones en la ingeniería de software (FIASSE) mediante el modelo de ingeniería de software asegurable (SSEM).
# Un marco para integrar la seguridad de aplicaciones en la ingeniería de software (FIASSE) [](https://creativecommons.org/licenses/by-sa/4.0/) **Nota:** Este repositorio es un trabajo en curso. ¡Las contribuciones son bienvenidas! ## Descripción general TL;DR: por favor, lea el [DOC](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md). Explore el [sitio web de FIASSE](https://fiasse.org). Visite [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) para contribuir. Este repositorio contiene recursos y materiales para el Marco de OWASP para Integrar la Seguridad de Aplicaciones en la Ingeniería de Software (FIASSE). FIASSE (pronunciado /feiz/ como 'phase') es un marco independiente de proveedores que promueve un **enfoque basado en principios y centrado en el desarrollador** para construir software **asegurable**. Reconoce que la seguridad es un proceso dinámico y continuo, al igual que el desarrollo. Introduce el Modelo de Ingeniería de Software Asegurable (SSEM) como un **lenguaje de diseño común** que utiliza términos consolidados de la ingeniería de software para integrar la seguridad en la arquitectura, el diseño y la ingeniería del software, incorporando la seguridad en los principios que dan forma al propio código. El marco permite a los equipos de desarrollo añadir valor computacional de forma resiliente mientras reducen la probabilidad de impacto material por eventos cibernéticos a lo largo de la vida útil del código. FIASSE es un marco de creación. Aborda cómo se implementa la seguridad en el software, conectando las decisiones de ingeniería directamente con resultados asegurables. No es un marco de aseguramiento, un modelo de madurez ni un reemplazo de catálogos de controles o métricas de vulnerabilidades. Complementa esos enfoques y alivia la presión posterior sobre el aseguramiento y el cumplimiento. ## Propósito Proporcionar directrices prácticas que **capaciten a los desarrolladores** para crear software asegurable sin requerir una profunda experiencia en seguridad, y guiar a los profesionales de la seguridad para integrar eficazmente su experiencia en seguridad dentro de la ingeniería de software. FIASSE lo logra a través de una **perspectiva de ingeniería de software**, reduciendo la carga cognitiva y fomentando la colaboración entre los equipos de desarrollo y de seguridad. ## ¿En qué se diferencia? Mientras que los proyectos centrados en el aseguramiento, como el OWASP Top 10, destacan qué evitar (una lista de bloqueo), OWASP FIASSE proporciona un conjunto de atributos y prácticas positivas a seguir (una lista de permitidos). Este enfoque aprovecha las habilidades existentes de ingeniería de software para construir software asegurable, en lugar de exigir a los desarrolladores que aprendan técnicas de explotación o adopten una mentalidad centrada en las vulnerabilidades. El énfasis está en habilitar una codificación segura y práctica mediante principios de ingeniería familiares. Al definir claramente el rol práctico de la seguridad dentro del proceso de desarrollo, este marco garantiza que el valor de negocio se capture de manera efectiva. Establecer expectativas de seguridad explícitas antes de escribir el código reduce la probabilidad de que se descubran fallos de seguridad y necesiten remediación posteriormente. Una adopción efectiva debería mejorar las métricas de aseguramiento existentes, reducir la rotación de hallazgos, producir correcciones más duraderas y acortar el tiempo de remediación. ## Valores fundamentales FIASSE se orienta por cuatro valores fundamentales. Cada uno expresa una preferencia relativa: ambos lados tienen valor, pero cuando hay que tomar decisiones, FIASSE favorece el de la izquierda. - **Atributos asegurables sobre controles de seguridad**: preferir las cualidades de ingeniería que permiten construir y mantener defendible un sistema, por encima de los controles de seguridad añadidos a posteriori para compensar debilidades. - **Participación sobre evaluación**: preferir la interacción estructurada entre seguridad y desarrollo a lo largo del ciclo de vida, por encima de la evaluación realizada una vez terminado el trabajo. - **Primeros principios de ingeniería sobre jerga de seguridad**: preferir fundamentarse en los primeros principios consolidados de la ingeniería de software, por encima de la jerga específica de seguridad o las heurísticas adversariales. - **Valor de negocio sobre actividad de seguridad**: preferir una seguridad que sostenga la creación de valor de la organización, por encima de una seguridad perseguida como un fin en sí misma. ## Principios clave - **El paradigma asegurable**: No existe un estado estático de "seguro". Un sistema declarado seguro hoy puede ser vulnerable mañana. FIASSE redirige el objetivo de la ingeniería de "¿es seguro?" a "¿está construido de modo que la seguridad pueda mantenerse?" mediante la resiliencia adaptativa, la seguridad evolutiva y la mejora continua. - **Añadir valor computacional de forma resiliente**: La directiva principal de la ingeniería de software en un contexto empresarial. El software debe cumplir los requisitos funcionales mientras sostiene las cualidades asegurables que le permiten resistir el cambio, la tensión y los ataques que siguen a cada cambio. - **Misión de seguridad: reducir el impacto material**: La misión de la seguridad es reducir la probabilidad de impacto material de un ciberevento. La eliminación completa de las brechas no es un objetivo empresarial práctico, por lo que las estrategias de seguridad deben alinearse con los objetivos empresariales y el apetito de riesgo. - **La relación calidad-seguridad**: La seguridad no puede superar la calidad del software. Las cualidades que hacen que el software sea fácil de entender, cambiar, probar y observar son las mismas cualidades que hacen posible asegurarlo. La inversión en calidad de ingeniería es una inversión en seguridad. - **Seguridad centrada en el desarrollador**: Capacitar a los ingenieros de software para construir sistemas asegurables utilizando principios de ingeniería de software familiares, en lugar de exigirles que adopten la mentalidad de un pentester. - **SSEM como lenguaje de diseño común**: Utilizar términos consolidados de la ingeniería de software (p. ej., Analizabilidad, Modificabilidad, Testabilidad) para definir y discutir los atributos de seguridad. Esto hace que la seguridad sea accesible para los desarrolladores y proporciona a los profesionales de la seguridad una base compartida para la evaluación. - **Alinear la seguridad con los objetivos de desarrollo y de negocio**: La seguridad y el desarrollo son complementarios, no antagónicos. AppSec participa tempranamente en el SDLC, particularmente durante la recopilación de requisitos y la planificación de funcionalidades, de modo que las expectativas sean explícitas antes de escribir el código. - **El principio de transparencia**: Los sistemas se diseñan de modo que las partes autorizadas puedan comprender el estado interno y el comportamiento. El registro estructurado, la instrumentación y las pistas de auditoría se incorporan en el código en lugar de ser proporcionados únicamente por herramientas externas. - **El principio de la mínima sorpresa**: Los sistemas se comportan de maneras intuitivas y predecibles para los usuarios, desarrolladores y administradores. La previsibilidad facilita el análisis, reduce la carga cognitiva y hace claros los límites de confianza. - **Los requisitos como ciudadano de primera clase en AppSec**: Las Características de Seguridad, los Escenarios de Amenaza y los Criterios de Aceptación de Seguridad se entregan a través del proceso de requisitos. Las vulnerabilidades suelen remontarse a una expectativa que nunca se especificó, por lo que esa brecha pertenece al proceso de requisitos. ## Principios de ingeniería La sección 4 del marco proporciona a los desarrolladores principios que se aplican directamente a nivel de código: - **El principio de control de límites**: La flexibilidad dentro del interior de un sistema es un activo de ingeniería que debe preservarse. El control en cada límite de confianza es un requisito de seguridad que debe aplicarse. - **Manejo canónico de la entrada**: Canonicalizar, validar y sanear la entrada en el punto de entrada. El **principio de análisis canónico** analiza la entrada externa en un tipo interno canónico en el límite y falla de forma segura cuando el análisis no tiene éxito. - **El principio de integridad aislada**: Los valores críticos para la integridad, como precios, roles y estado de los objetos, se derivan de fuentes autoritativas del lado del servidor. Nunca se aceptan directamente de un cliente. - **Codificación resiliente**: Las prácticas de codificación defensiva imponen una ejecución predecible. Estas incluyen tipado fuerte, validación de entrada en los límites de confianza, codificación de salida, manejo integral de errores, gestión segura de recursos, fallo controlado y seguro, y mínimo privilegio a nivel de código. - **Administración de dependencias**: Aplicar los atributos SSEM al seleccionar, integrar, monitorear y mantener las dependencias durante toda la vida de la relación. ## El modelo de ingeniería de software asegurable (SSEM) SSEM define los atributos que hacen que el software sea asegurable. Los equipos establecen objetivos para cada atributo, evalúan los sistemas con respecto a ellos y mejoran de forma incremental. Los atributos se organizan en tres categorías: | **Mantenibilidad** | **Confiabilidad** | **Fiabilidad** | |:--------------------|:-------------------:|----------------:| | Analizabilidad | Confidencialidad | Disponibilidad | | Modificabilidad | Responsabilidad | Integridad | | Testabilidad | Autenticidad | Resiliencia | | Observabilidad | | | SSEM no tiene un atributo de Autorización por diseño. La autorización es una característica de seguridad que se recopila como requisito y se implementa según criterios de aceptación. Los atributos anteriores son los que hacen que dicha característica sea asegurable. El Apéndice A del marco describe enfoques para medir cada atributo. ## Contenido del repositorio - [docs/securable_framework.md](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md): el marco FIASSE completo y la especificación SSEM como un único documento. - [docs/framework/](https://github.com/owasp/fiasse/blob/main/docs/framework): el marco dividido en un archivo por sección. Estos archivos de sección son la fuente de verdad del marco. El [índice de código](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md) separa las secciones que se aplican directamente al código de las secciones de proceso, rol y adopción. [llms.txt](https://github.com/owasp/fiasse/blob/main/docs/framework/llms.txt) proporciona un índice para modelos de lenguaje. - [skills/](https://github.com/owasp/fiasse/blob/main/skills): FIASSE y SSEM empaquetados como skills para agentes de codificación con IA (ver más abajo). - TODO: Guías de implementación para la metodología FIASSE - Los ejemplos se han trasladado a [Securability-Engineering/securable-framework-supplement](https://github.com/Securability-Engineering/securable-framework-supplement) ## Primeros pasos 1. Revise la documentación en el directorio [docs](https://github.com/owasp/fiasse/blob/main/docs). Comience con el [marco completo](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md), o utilice el [índice de código](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md) para encontrar las secciones que se aplican al código en cuestión. 2. Discuta los conceptos y principios con sus equipos y en las [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) 3. Comience a aplicar los principios en sus prácticas de ingeniería de software, como la recopilación de requisitos, las revisiones de merge y la ingeniería de prompts. 4. Siga los pasos de adopción de la Sección 8 del marco: evalúe las prácticas actuales, integre la terminología SSEM, identifique a las personas influyentes clave, eduque y capacite a los equipos, adopte herramientas agenticas de AppSec como alivio de capacidad, fomente la colaboración y supervise y mejore de forma continua. - Extra: Instale el plugin que coincida con su IDE o agente de línea de comandos impulsado por IA de su elección (por ejemplo, GitHub Copilot, Claude Code, OpenCode, etc.) y utilice los prompts proporcionados para generar código asegurable. Busque "Securability Engineering" o "FIASSE" en la biblioteca de prompts. - FIASSE también se incluye como parte del [OWASP Secure Agent Playbook](https://github.com/OWASP/secure-agent-playbook). ## Skills para agentes de codificación con IA El directorio [`skills/`](https://github.com/owasp/fiasse/blob/main/skills) empaqueta FIASSE/SSEM como skills listos para usar para agentes de codificación con IA que admiten el formato [Agent Skills](https://code.claude.com/docs/en/skills) (por ejemplo, Claude Code). Copie el directorio de skills que necesite en la ruta de skills de su agente. - **[`securability`](https://github.com/owasp/fiasse/blob/main/skills/securability/SKILL.md)**: Una referencia compacta y totalmente autocontenida que cubre los diez atributos SSEM y los principios fundamentales (No Static State of Secure, Isolated Integrity, Canonical Input Handling, Boundary Control, Least Astonishment). Pensada como la opción predeterminada para la generación y revisión de código cotidianas. - **[`securable-code`](https://github.com/owasp/fiasse/blob/main/skills/securable-code/SKILL.md)**: Una skill de análisis profundo para trabajo con gran cantidad de contexto y arquitectónicamente complejo, como el diseño de límites de confianza, sistemas de autenticación, flujos de datos multiservicio o arquitectura de dependencias. Dirige a la sección específica del marco incluida (en `skills/securable-code/framework/`) relevante para el código en cuestión, intercambiando contexto adicional por el razonamiento completo del marco de origen. Use `securability` por defecto; recurre a `securable-code` cuando las decisiones de diseño no sean tan obvias como para justificar la lectura del propio framework. ## Resumen Este repositorio define el software asegurable como software construido para mantenerse defendible: estructurado de modo que pueda entenderse, modificarse, probarse y endurecerse a medida que el mundo que lo rodea cambia. Enfatiza que la seguridad es un proceso continuo, no un logro estático. Introduce el Modelo de Ingeniería de Software Asegurable (SSEM), que enmarca la seguridad como un conjunto inherente de cualidades del software bien diseñado. Para ello, presenta las categorías de atributos de Mantenibilidad, Confiabilidad y Fiabilidad (que incluye la Resiliencia). FIASSE aboga por integrar las prácticas de seguridad en el flujo de trabajo de desarrollo donde tienen mayor impacto. Esto supone un cambio de un enfoque de "seguridad como ocurrencia tardía" o de "desplazamiento a la izquierda" hacia un modelo proactivo y colaborativo. Los propietarios de producto, los desarrolladores y los profesionales de seguridad trabajan juntos desde las etapas más tempranas del diseño, en particular mediante la definición de requisitos de seguridad, el modelado colaborativo de amenazas y los criterios de aceptación de seguridad. Esto establece expectativas claras para las actividades de código y las pruebas. Las revisiones de fusión actúan como barandillas, no como puertas. Cada fusión produce un Informe de Asegurabilidad de carácter consultivo, y el bloqueo es una decisión de política con una vía de anulación. Los hallazgos de la validación y de producción se tratan como inteligencia empírica que señala aguas arriba la etapa que podría haberlos prevenido. A los ingenieros de software se les brinda orientación sobre cómo equilibrar flexibilidad y control. También se les proporciona un modelo definitivo para tomar decisiones de seguridad. En última instancia, esto capacita a todas las partes interesadas para contribuir a la construcción de sistemas más robustos, fiables e inherentemente asegurables. FIASSE se diferencia de los enfoques existentes al no exigir que los desarrolladores se conviertan en expertos en seguridad ni que adopten una mentalidad adversarial. Nombra anti-patrones comunes de AppSec, como "Shoveling Left" (arrojar a la izquierda la salida cruda de las herramientas sobre los desarrolladores) y la formación centrada primero en el exploit, y los reemplaza con el Principio de Inteligencia de Seguridad Accionable. Este enfoque tiene como objetivo reducir la carga cognitiva de los desarrolladores mientras garantiza que los profesionales de seguridad puedan tener la confianza de que sus preocupaciones se abordan mediante atributos específicos del código y de los procesos de ingeniería de software. FIASSE pretende ser abierto, accesible y colaborativo. ## Hoja de ruta Hitos iniciales del proyecto FIASSE: - **Fundación del proyecto** - Establecimiento de la gobernanza del proyecto, las directrices de contribución y los canales de comunicación. - **Especificaciones principales** - Publicación formal del framework FIASSE y de la especificación SSEM, detallando los atributos centrales y las estrategias de integración. - **Recursos de adopción y educativos** - Una introducción al SSEM para presentar el modelo y su aplicación. - Una colección de casos de uso iniciales y patrones de adopción para ilustrar los beneficios prácticos. - Desarrollo continuo de guías de implementación, ejemplos y otros materiales educativos. Se desarrollarán más hitos con el equipo del proyecto. Se invita a la comunidad a aportar a través de [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions). ## Recursos complementarios Este repositorio complementa el [sitio web de FIASSE](https://fiasse.org). El proyecto [OWASP FIASSE](https://owasp.org/www-project-fiasse/) forma parte de la [OWASP Foundation](https://owasp.org/), una organización sin ánimo de lucro centrada en la misión de eliminar el software inseguro. La OWASP Foundation proporciona una gran cantidad de recursos y frameworks que se alinean con los principios de FIASSE. Este framework se centra en la Ingeniería de Software Asegurable y se complementa con otros proyectos de OWASP: - Verificación de características de seguridad y una biblioteca de requisitos de seguridad lista para usar: [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) - Madurez de aseguramiento: [OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/) - Cumplimiento de seguridad de productos: [OWASP Product Security Capability Framework (PSCF)](https://owasp.org/www-project-product-security-capability-framework/) OWASP también alberga numerosos proyectos que documentan requisitos y características de seguridad, como [OWASP Mobile Application Security](https://mas.owasp.org/). La [OWASP Developer Guide](https://owasp.org/www-project-developer-guide/) es un recurso integral para otros recursos de OWASP. Otro gran recurso de referencia para requisitos y prácticas de aseguramiento es [OpenCRE](https://opencre.org/), que recopila y mapea diversos marcos de seguridad. Los catálogos de controles como NIST SP 800-53, ISO/IEC 27001 Anexo A y PCI DSS respaldan la gestión de riesgos, el aseguramiento y la evaluación externa. FIASSE no los reemplaza. Los trata como insumos para la recopilación de requisitos, donde un control de catálogo se traduce en un requisito de seguridad con criterios de aceptación antes de que el desarrollo lo implemente. El [Secure Software Development Framework (SSDF)](https://csrc.nist.gov/publications/detail/sp/800-218/final) de NIST define un conjunto central de prácticas de desarrollo de software seguro organizadas en cuatro grupos. FIASSE no define tal conjunto de prácticas. Se alinea con el SSDF al enfatizar la integración de la seguridad en el ciclo de vida del desarrollo de software. El [Software Security Code of Practice](https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance) del NCSC define resultados deseados y algunas estrategias clave. FIASSE se centra en principios y estrategias de seguimiento de primer nivel para lograr resultados asegurables, destinados a que los equipos de Desarrollo y Aseguramiento se alineen con las estrategias de negocio. SSEM especifica los atributos que se utilizan para producir los resultados deseados, y la metodología FIASSE proporciona orientación práctica para implementar estos atributos en las prácticas de ingeniería de software. Los Estándares de Codificación Segura de [CERT](https://www.cert.org/) de la Universidad Carnegie Mellon son un conjunto de reglas a nivel de lenguaje que proporcionan tanto ejemplos de "qué no hacer", mostrando patrones de código vulnerables, como ejemplos de "qué hacer". FIASSE complementa estas reglas proporcionando un enfoque basado en principios que ayuda a los programadores a comprender el "¿por qué?" detrás del código asegurable. Software Factory Security Framework ([SF2](https://sf2framework.com/)) "proporciona a los líderes de seguridad un enfoque estratégico para escalar las capacidades de seguridad mientras mejoran los resultados del negocio". Es un marco a nivel organizacional que complementa el enfoque de FIASSE en las prácticas de ingeniería de software. ## Contribuir Las contribuciones para mejorar la documentación y los ejemplos son bienvenidas. Consulte nuestras [pautas de contribución](https://github.com/owasp/fiasse/blob/main/CONTRIBUTING.md) para más detalles. ## Licencia Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) - consulte el archivo [LICENSE](https://github.com/owasp/fiasse/blob/main/licence.txt) para más detalles. ## Agradecimientos Este proyecto es un esfuerzo colaborativo de la comunidad OWASP. Agradecemos a todos los contribuyentes por sus valiosos aportes y su dedicación a mejorar la seguridad del software. Existe una [lista de contribuyentes](https://github.com/owasp/fiasse/blob/main/CONTRIBUTORS.md) que han participado en este proyecto. Algunos contribuyentes tempranos ayudaron a dar forma a los conceptos iniciales y a hacer red team sobre las ideas.
