Um Framework para Integrar Segurança de Aplicações na Engenharia de Software (FIASSE) usando o Modelo de Engenharia de Software Segurável (SSEM)
# Um Framework para Integrar a Segurança de Aplicações na Engenharia de Software (FIASSE) [](https://creativecommons.org/licenses/by-sa/4.0/) **Nota:** Este repositório é um trabalho em andamento. Contribuições são bem-vindas! ## Visão Geral TL;DR: por favor, leia a [DOC](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md). Explore o [site do FIASSE](https://fiasse.org). Visite as [Discussões no GitHub](https://github.com/OWASP/FIASSE/discussions) para contribuir. Este repositório contém recursos e materiais para o Framework da OWASP para Integrar a Segurança de Aplicações na Engenharia de Software (FIASSE). FIASSE (pronunciado /feiz/, como 'phase') é um framework independente de fornecedor que promove uma **abordagem centrada no desenvolvedor e baseada em princípios** para construir software **securable** (segurável). Ele reconhece que a segurança é um processo dinâmico e contínuo, assim como o desenvolvimento. Ele introduz o Modelo de Engenharia de Software Segurável (SSEM) como uma **linguagem de design comum** que utiliza termos consagrados da engenharia de software para integrar a segurança à arquitetura, ao design e à engenharia de software, incorporando a segurança nos princípios que moldam o próprio código. O framework permite que as equipes de desenvolvimento agreguem valor computacional de forma resiliente, reduzindo a probabilidade de impacto material decorrente de eventos cibernéticos ao longo do ciclo de vida do código. FIASSE é um framework criacional. Ele aborda como a segurança é implementada no software, conectando decisões de engenharia diretamente a resultados seguráveis. Não é um framework de garantia (assurance), um modelo de maturidade, nem um substituto para catálogos de controles ou métricas de vulnerabilidade. Ele complementa essas abordagens e alivia a pressão a jusante sobre garantia e conformidade. ## Propósito Fornecer diretrizes práticas que **capacitem os desenvolvedores** a criar software segurável sem exigir profundo conhecimento em segurança, e orientar os profissionais de segurança a integrar efetivamente sua experiência em segurança à engenharia de software. O FIASSE alcança isso por meio de uma **lente de Engenharia de Software**, reduzindo a carga cognitiva e promovendo a colaboração entre as equipes de desenvolvimento e de segurança. ## Como é Diferente? Enquanto projetos focados em garantia, como o OWASP Top 10, destacam o que evitar (uma lista de bloqueio), o OWASP FIASSE fornece um conjunto de atributos e práticas positivas a serem seguidas (uma lista de permissões). Essa abordagem aproveita as habilidades existentes de engenharia de software para construir software segurável, em vez de exigir que os desenvolvedores aprendam técnicas de exploração ou adotem uma mentalidade focada em vulnerabilidades. A ênfase está em possibilitar a codificação segura e prática por meio de princípios de engenharia familiares. Ao definir claramente o papel prático da segurança dentro do processo de desenvolvimento, este framework garante que o valor de negócio seja capturado de forma eficaz. Estabelecer expectativas explícitas de segurança antes que o código seja escrito reduz a probabilidade de que falhas de segurança sejam descobertas e precisem de remediação posteriormente. A adoção eficaz deve melhorar as métricas de garantia existentes, reduzir a rotatividade de achados, produzir correções mais duradouras e encurtar o tempo de remediação. ## Valores Fundamentais O FIASSE é orientado por quatro valores fundamentais. Cada um expressa uma preferência relativa: ambos os lados têm valor, mas quando escolhas precisam ser feitas, o FIASSE favorece o lado esquerdo. - **Atributos Seguráveis em vez de Controles de Segurança**: preferir as qualidades de engenharia que permitem que um sistema seja construído e mantido defensável em vez de controles de segurança adicionados posteriormente para compensar fraquezas. - **Participação em vez de Avaliação**: preferir o engajamento estruturado entre segurança e desenvolvimento ao longo de todo o ciclo de vida em vez da avaliação realizada após o trabalho estar concluído. - **Primeiros Princípios de Engenharia em vez de Jargão de Segurança**: preferir o embasamento nos primeiros princípios consagrados da engenharia de software em vez de jargão específico de segurança ou heurísticas adversariais. - **Valor de Negócio em vez de Atividade de Segurança**: preferir a segurança que sustenta a criação de valor da organização em vez da segurança buscada como um fim em si mesma. ## Princípios-Chave - **O Paradigma Securável**: Não existe um estado estático de "seguro". Um sistema declarado seguro hoje pode estar vulnerável amanhã. O FIASSE redireciona o objetivo de engenharia de "ele é seguro?" para "ele foi construído de modo que a segurança possa ser mantida?" por meio de resiliência adaptativa, segurança evolutiva e melhoria contínua. - **Agregar Valor Computacional de Forma Resiliente**: A diretriz primária da engenharia de software em um contexto de negócios. O software deve atender aos requisitos funcionais enquanto sustenta as qualidades securáveis que lhe permitem resistir à mudança, ao estresse e ao ataque que se seguem a cada mudança. - **Missão de Segurança: Reduzir o Impacto Material**: A missão da segurança é reduzir a probabilidade de impacto material de um evento cibernético. A eliminação completa de violações não é um objetivo de negócios prático, portanto as estratégias de segurança devem estar alinhadas com os objetivos de negócios e o apetite ao risco. - **A Relação Qualidade-Segurança**: A segurança não pode exceder a qualidade do software. As qualidades que tornam o software fácil de entender, alterar, testar e observar são as mesmas qualidades que tornam possível protegê-lo. O investimento em qualidade de engenharia é um investimento em segurança. - **Segurança Centrada no Desenvolvedor**: Capacitar os engenheiros de software a construir sistemas securáveis usando princípios familiares de engenharia de software, em vez de exigir que adotem a mentalidade de um testador de penetração. - **SSEM como Linguagem Comum de Design**: Utilizar termos consagrados de engenharia de software (por exemplo, Analisabilidade, Modificabilidade, Testabilidade) para definir e discutir atributos de segurança. Isso torna a segurança acessível aos desenvolvedores e dá aos profissionais de segurança uma base compartilhada para avaliação. - **Alinhar a Segurança com os Objetivos de Desenvolvimento e de Negócios**: Segurança e desenvolvimento são complementares, não adversariais. O AppSec participa precocemente do SDLC, particularmente durante o levantamento de requisitos e o planejamento de funcionalidades, para que as expectativas sejam explícitas antes de o código ser escrito. - **O Princípio da Transparência**: Os sistemas são projetados para que partes autorizadas possam compreender o estado interno e o comportamento. Logging estruturado, instrumentação e trilhas de auditoria são incorporados ao código em vez de serem fornecidos apenas por ferramentas externas. - **O Princípio da Menor Surpresa**: Os sistemas se comportam de maneiras intuitivas e previsíveis para usuários, desenvolvedores e administradores. A previsibilidade auxilia a análise, reduz a carga cognitiva e torna as fronteiras de confiança claras. - **Requisitos como Cidadão de Primeira Classe no AppSec**: Recursos de Segurança, Cenários de Ameaça e Critérios de Aceitação de Segurança são entregues por meio do processo de requisitos. As vulnerabilidades comumente remontam a uma expectativa que nunca foi especificada, portanto essa lacuna pertence ao processo de requisitos. ## Princípios de Engenharia A Seção 4 do framework fornece aos desenvolvedores princípios que se aplicam diretamente no nível do código: - **O Princípio do Controle de Fronteira**: A flexibilidade no interior de um sistema é um ativo de engenharia a ser preservado. O controle em cada fronteira de confiança é um requisito de segurança a ser imposto. - **Tratamento Canônico de Entrada**: Canonicalize, valide e sanitize a entrada no ponto de entrada. O **Princípio da Análise Canônica** analisa a entrada externa em um tipo interno canônico na fronteira e falha de forma segura quando a análise não é bem-sucedida. - **O Princípio da Integridade Isolada**: Valores críticos para a integridade, como preços, funções e estado de objetos, são derivados de fontes autoritativas do lado do servidor. Eles nunca são aceitos diretamente de um cliente. - **Codificação Resiliente**: Práticas de codificação defensiva impõem execução previsível. Isso inclui tipagem forte, validação de entrada nas fronteiras de confiança, codificação de saída, tratamento abrangente de erros, gerenciamento seguro de recursos, falha graciosa e segura, e privilégio mínimo no nível do código. - **Gestão de Dependências**: Aplique os atributos SSEM ao selecionar, integrar, monitorar e manter dependências durante toda a vida do relacionamento. ## O Modelo de Engenharia de Software Securável (SSEM) O SSEM define os atributos que tornam o software securizável. As equipes definem metas para cada atributo, avaliam os sistemas em relação a elas e melhoram de forma incremental. Os atributos estão organizados em três categorias: | **Manutenibilidade** | **Confiabilidade** | **Resiliência** | |:--------------------|:-------------------:|----------------:| | Analisabilidade | Confidencialidade | Disponibilidade | | Modificabilidade | Responsabilização | Integridade | | Testabilidade | Autenticidade | Resiliência | | Observabilidade | | | O SSEM não possui um atributo de Autorização por design. A autorização é um recurso de segurança que é coletado como requisito e implementado com base em critérios de aceitação. Os atributos acima são o que torna tal recurso securizável. O Apêndice A do framework descreve abordagens para medir cada atributo. ## Conteúdo do Repositório - [docs/securable_framework.md](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md): o framework FIASSE completo e a especificação SSEM como um único documento. - [docs/framework/](https://github.com/owasp/fiasse/blob/main/docs/framework): o framework dividido em um arquivo por seção. Esses arquivos de seção são a fonte da verdade para o framework. O [índice de código](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md) separa as seções que se aplicam diretamente ao código das seções de processo, papel e adoção. O [llms.txt](https://github.com/owasp/fiasse/blob/main/docs/framework/llms.txt) fornece um índice para modelos de linguagem. - [skills/](https://github.com/owasp/fiasse/blob/main/skills): FIASSE e SSEM empacotados como skills para agentes de codificação de IA (veja abaixo). - TODO: Guias de implementação para a metodologia FIASSE - Os exemplos foram movidos para [Securability-Engineering/securable-framework-supplement](https://github.com/Securability-Engineering/securable-framework-supplement) ## Primeiros Passos 1. Revise a documentação no diretório [docs](https://github.com/owasp/fiasse/blob/main/docs). Comece pelo [framework completo](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md), ou use o [índice de código](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md) para encontrar as seções que se aplicam ao código em questão. 2. Discuta os conceitos e princípios com suas equipes e nas [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) 3. Comece a aplicar os princípios em suas práticas de engenharia de software, como levantamento de requisitos, revisões de merge e engenharia de prompts. 4. Siga as etapas de adoção na Seção 8 do framework: avalie as práticas atuais, integre a terminologia SSEM, identifique influenciadores-chave, eduque e treine as equipes, adote ferramentas agenticas de AppSec como alívio de capacidade, fomente a colaboração e monitore e melhore continuamente. - Bônus: Instale o plugin correspondente à sua IDE ou agente de linha de comando com IA de sua escolha (por exemplo, GitHub Copilot, Claude Code, OpenCode, etc.) e use os prompts fornecidos para gerar código securizável. Procure por "Securability Engineering" ou "FIASSE" na biblioteca de prompts. - O FIASSE também está incluído como parte do [OWASP Secure Agent Playbook](https://github.com/OWASP/secure-agent-playbook). ## Skills para Agentes de Codificação de IA O diretório [`skills/`](https://github.com/owasp/fiasse/blob/main/skills) empacota o FIASSE/SSEM como skills prontas para uso para agentes de codificação de IA que suportam o formato [Agent Skills](https://code.claude.com/docs/en/skills) (por exemplo, Claude Code). Copie o diretório de skill que você precisa para o caminho de skills do seu agente. - **[`securability`](https://github.com/owasp/fiasse/blob/main/skills/securability/SKILL.md)**: Uma referência compacta e totalmente autossuficiente que cobre todos os dez atributos do SSEM e os princípios fundamentais (No Static State of Secure, Isolated Integrity, Canonical Input Handling, Boundary Control, Least Astonishment). Destinada a ser o padrão para geração e revisão de código do dia a dia. - **[`securable-code`](https://github.com/owasp/fiasse/blob/main/skills/securable-code/SKILL.md)**: Uma skill aprofundada para trabalhos com muito contexto e arquiteturalmente complexos, como design de limites de confiança, sistemas de autenticação, fluxos de dados multi-serviço ou arquitetura de dependências. Ela direciona para a seção específica do framework empacotada (em `skills/securable-code/framework/`) relevante ao código em questão, trocando contexto extra pelo raciocínio completo do framework de origem. Use `securability` por padrão; recorra a `securable-code` quando as decisões de design forem suficientemente não óbvias para justificar a leitura do próprio framework. ## Resumo Este repositório define software securável como software construído para permanecer defensável: estruturado de modo que possa ser compreendido, alterado, testado e endurecido à medida que o mundo ao seu redor muda. Ele enfatiza que a segurança é um processo contínuo, não uma conquista estática. Introduz o Securable Software Engineering Model (SSEM), que enquadra a segurança como um conjunto inerente de qualidades de software bem projetado. Para isso, apresenta as categorias de atributos de Maintainability, Trustworthiness e Reliability (que inclui Resilience). O FIASSE defende a integração de práticas de segurança no fluxo de trabalho de desenvolvimento onde elas têm maior impacto. Isso representa uma mudança de uma abordagem de "segurança como reflexão tardia" ou de "shift left" para um modelo proativo e colaborativo. Product owners, desenvolvedores e profissionais de segurança trabalham juntos desde as etapas mais iniciais do design, particularmente por meio da definição de requisitos de segurança, da modelagem colaborativa de ameaças e dos critérios de aceitação de segurança. Isso estabelece expectativas claras para as atividades de código e testes. As revisões de merge atuam como guardrails, não como gates. Cada merge produz um Securability Report consultivo, e o gating é uma decisão de política com um caminho de override. Achados provenientes da validação e da produção são tratados como inteligência empírica que aponta upstream para a etapa que poderia tê-los evitado. Engenheiros de software recebem orientação sobre como equilibrar flexibilidade e controle. Também recebem um modelo definitivo para tomar decisões de segurança. Em última análise, isso capacita todas as partes interessadas a contribuir para a construção de sistemas mais robustos, confiáveis e inerentemente securáveis. O FIASSE difere das abordagens existentes por não exigir que os desenvolvedores se tornem especialistas em segurança ou adotem uma mentalidade adversarial. Ele nomeia anti-padrões comuns de AppSec, como "Shoveling Left" (despejar a saída bruta de ferramentas sobre os desenvolvedores) e treinamento com foco em exploit-first, e os substitui pelo Actionable Security Intelligence Principle. Essa abordagem visa reduzir a carga cognitiva sobre os desenvolvedores, ao mesmo tempo que garante que os profissionais de segurança possam ter confiança de que suas preocupações são tratadas por meio de atributos específicos do código e dos processos de engenharia de software. O FIASSE pretende ser aberto, acessível e colaborativo. ## Roadmap Marcos iniciais do projeto FIASSE: - **Fundação do Projeto** - Estabelecimento da governança do projeto, diretrizes de contribuição e canais de comunicação. - **Especificações Centrais** - Publicação formal do framework FIASSE e da especificação SSEM, detalhando os atributos centrais e as estratégias de integração. - **Recursos de Adoção e Educacionais** - Um SSEM Primer para apresentar o modelo e sua aplicação. - Uma coleção de casos de uso iniciais e padrões de adoção para ilustrar os benefícios práticos. - Desenvolvimento contínuo de guias de implementação, exemplos e outros materiais educacionais. Marcos adicionais serão desenvolvidos com a equipe do projeto. Contribuições da comunidade são bem-vindas via [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions). ## Recursos Complementares Este repositório complementa o [site do FIASSE](https://fiasse.org). O projeto [OWASP FIASSE](https://owasp.org/www-project-fiasse/) faz parte da [OWASP Foundation](https://owasp.org/), uma organização sem fins lucrativos focada na missão de eliminar o software inseguro. A OWASP Foundation oferece uma vasta gama de recursos e frameworks que se alinham aos princípios do FIASSE. Este framework é focado em Securable Software Engineering e é complementado por outros projetos da OWASP: - Verificação de recursos de segurança e uma biblioteca pronta de requisitos de segurança: [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) - Maturidade de garantia: [OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/) - Conformidade de segurança de produto: [OWASP Product Security Capability Framework (PSCF)](https://owasp.org/www-project-product-security-capability-framework/) A OWASP também hospeda diversos projetos que documentam requisitos e recursos de segurança, como o [OWASP Mobile Application Security](https://mas.owasp.org/). O [OWASP Developer Guide](https://owasp.org/www-project-developer-guide/) é um recurso abrangente para diversos outros recursos da OWASP. Outro ótimo recurso para requisitos de referência e práticas de garantia é o [OpenCRE](https://opencre.org/), que reúne e mapeia diversos frameworks de segurança. Catálogos de controles como NIST SP 800-53, ISO/IEC 27001 Anexo A e PCI DSS dão suporte à gestão de riscos, garantia e avaliação externa. O FIASSE não os substitui. Ele os trata como insumo para o levantamento de requisitos, no qual um controle de catálogo é traduzido em um requisito de segurança com critérios de aceitação antes que o desenvolvimento o implemente. O [Secure Software Development Framework (SSDF)](https://csrc.nist.gov/publications/detail/sp/800-218/final) do NIST define um conjunto central de práticas de desenvolvimento seguro de software organizadas em quatro grupos. O FIASSE não define tal conjunto de práticas. Ele se alinha ao SSDF ao enfatizar a integração da segurança no ciclo de vida de desenvolvimento de software. O [Software Security Code of Practice](https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance) do NCSC define resultados desejados e algumas estratégias-chave. O FIASSE concentra-se em princípios e estratégias de acompanhamento de primeiro nível para alcançar resultados securizáveis, destinados às equipes de Desenvolvimento e Garantia para se alinharem às estratégias de negócio. O SSEM especifica os atributos usados para produzir os resultados desejados, e a metodologia FIASSE fornece orientação prática para implementar esses atributos nas práticas de engenharia de software. Os Padrões de Codificação Segura do [CERT](https://www.cert.org/) da Carnegie Mellon University são um conjunto de regras em nível de linguagem que fornecem tanto exemplos de "o que não fazer", mostrando padrões de código vulneráveis, quanto exemplos de "o que fazer". O FIASSE complementa essas regras ao fornecer uma abordagem baseada em princípios que ajuda os programadores a entender o "porquê?" por trás do código securizável. O Software Factory Security Framework ([SF2](https://sf2framework.com/)) "fornece aos líderes de segurança uma abordagem estratégica para escalar capacidades de segurança enquanto melhora os resultados de negócio." É um framework em nível organizacional que complementa o foco do FIASSE nas práticas de engenharia de software. ## Contribuindo Contribuições para melhorar a documentação e os exemplos são bem-vindas. Consulte nossas [diretrizes de contribuição](https://github.com/owasp/fiasse/blob/main/CONTRIBUTING.md) para mais detalhes. ## Licença Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) - consulte o arquivo [LICENSE](https://github.com/owasp/fiasse/blob/main/licence.txt) para mais detalhes. ## Agradecimentos Este projeto é um esforço colaborativo da comunidade OWASP. Agradecemos a todos os contribuidores por sua valiosa contribuição e dedicação para melhorar a segurança de software. Há uma [lista de contribuidores](https://github.com/owasp/fiasse/blob/main/CONTRIBUTORS.md) que participaram deste projeto. Alguns contribuidores iniciais ajudaram a moldar os conceitos iniciais e a fazer red team das ideias.
