Segurança do Software

1. Visão Geral

A área de Segurança do Software atua como um pilar fundamental que permeia todo o processo de CI/CD na Fábrica, garantindo que a qualidade do código e do design não se restrinja apenas à funcionalidade, mas também à sua resiliência contra ameaças. O propósito central desta área é incorporar a segurança em todas as etapas do ciclo de vida do desenvolvimento, promovendo uma cultura de Security by Design.

Em linhas gerais, "a segurança está relacionada ao grau/nível que um produto ou sistema consegue proteger dados e informações, de tal forma que as pessoas, produtos/sistemas tenham apenas acesso adequado às informações específicas, conforme seu tipo e nível de autorização" [1].

Diferente de uma abordagem reativa, onde vulnerabilidades são corrigidas após a detecção em produção, o foco é na prevenção de vulnerabilidades desde a fase de concepção. Isso se traduz diretamente na redução de risco operacional para a Fábrica, minimizando a superfície de ataque e os custos associados a incidentes de segurança. A atuação contínua assegura a garantia de conformidade com padrões de mercado (como o OWASP Top 10) e a validação contínua dos artefatos de software.

2. Fundamentos Teóricos

A Engenharia de Segurança do Software na Fábrica é alicerçada em consonância com padrões globais e práticas internas consolidadas, garantindo uma abordagem técnica e abrangente.

2.1. Da Visão SWEBOK v4

O Guide to the Software Engineering Body of Knowledge (SWEBOK v4) [1] estabelece a segurança como uma Área de Conhecimento (KA) crítica e integrada ao ciclo de vida. Os fundamentos adotados pela Fábrica, com base nos Capítulos 13, 3 e 4 do SWEBOK, incluem:

Fundamentos de Segurança do Software segundo SWEBOK v4

Fundamento	Área de Conhecimento (KA)	Descrição e Aplicação
Segurança como disciplina de engenharia	Software Security (Cap. 13)	Tratar a segurança não como um recurso opcional, mas como um requisito não-funcional essencial, integrado ao planejamento e execução.
Segurança orientada a requisitos	Software Security (Cap. 13)	Definição clara de requisitos de segurança (ex: autenticação, autorização, auditoria) na fase de Engenharia de Requisitos.
Padrões de design seguro	Software Design (Cap. 3)	Aplicação de padrões arquiteturais que minimizem riscos, como o princípio do menor privilégio e a segregação de responsabilidades. Inclui a tolerância a falhas e o tratamento de erros de forma segura.
Construction for Security	Software Construction (Cap. 4)	Uso de técnicas de Defensive Programming e tratamento robusto de exceções (Exception Handling) para evitar estados inseguros do sistema.
Testes de segurança	Software Security (Cap. 13)	Incorporação de testes estáticos (SAST), dinâmicos (DAST) e testes de penetração (Pen-testing) como parte da Garantia da Qualidade.
Gerenciamento de Vulnerabilidade	Software Security (Cap. 13)	Processo contínuo de identificação, classificação, priorização e remediação de vulnerabilidades.

2.2. OWASP Top 10 (2021)

O OWASP Top 10 (2021) [2] é o padrão global de conscientização sobre os riscos de segurança mais críticos para aplicações web. A Fábrica utiliza este guia para direcionar a mitigação de riscos e a educação dos times:

OWASP Top 10 (2021) e Práticas de Mitigação Internas

Categoria OWASP (2021)	Resumo do Risco	Prática Interna de Mitigação
A01: Quebra de Controle de Acesso	Falhas na restrição do que usuários autenticados podem acessar ou fazer.	Implementação rigorosa de políticas de autorização em todas as camadas (API e UI).
A02: Falhas Criptográficas	Falhas relacionadas à criptografia de dados sensíveis em trânsito e em repouso.	Uso obrigatório de protocolos seguros (TLS/HTTPS) e algoritmos de criptografia fortes e validados.
A03: Injeção	Dados não confiáveis enviados ao interpretador como parte de um comando ou consulta.	Uso de Prepared Statements (consultas parametrizadas) e ORMs para blindagem contra SQL Injection.
A04: Design Inseguro	Falhas de segurança que resultam de um design ausente ou ineficaz.	Aplicação de Threat Modeling na fase de design e revisão arquitetural mínima.
A05: Configuração Incorreta de Segurança	Configurações padrão inseguras, recursos desnecessários habilitados ou erros de configuração de nuvem.	Uso de imagens base seguras e padronizadas para deploy e automação de validação de configuração.
A06: Componentes Vulneráveis e Desatualizados	Uso de bibliotecas, frameworks ou outros módulos de software com vulnerabilidades conhecidas.	Revisão automatizada de dependências (SAST/SCA) e atualização proativa de pacotes.
A07: Falhas de Identificação e Autenticação	Falhas que permitem que atacantes comprometam senhas, chaves ou tokens de sessão.	Uso de mecanismos de autenticação centralizados e fortes (MFA obrigatório).
A08: Falhas de Integridade de Software e Dados	Falhas na integridade de dados e pipelines de atualização.	Validação de integridade de uploads e uso de assinaturas digitais em atualizações críticas.
A09: Falhas de Log e Monitoramento	Falhas que impedem a detecção, escalonamento ou resposta a um ataque.	Implementação de Logs Estruturados (JSON) com níveis padronizados e alertas configurados.
A10: Falsificação de Solicitação do Lado do Servidor	O aplicativo busca um recurso remoto sem validar a URL fornecida pelo usuário.	Validação rigorosa de todas as URLs externas e uso de whitelists para recursos permitidos.

2.3. Práticas de Implementação (Codificação Segura)

A codificação segura é a aplicação prática dos princípios de Construction for Security (SWEBOK Cap. 4) e das diretrizes do Guia de Melhores Práticas de Implementação [3]. Para ir além do essencial, a Fábrica adota uma postura de defesa em profundidade no nível do código:

• Gerenciamento de Segredos e Credenciais: A prática de não armazenar credenciais em código-fonte é expandida pelo princípio de Rotação e Menor Privilégio. Segredos devem ser injetados no ambiente de execução via Vaults (como HashiCorp Vault, AWS Secrets Manager) e não apenas via variáveis de ambiente. Além disso, cada componente de software deve operar com o menor conjunto de permissões estritamente necessário para sua função (Princípio do Menor Privilégio).
• Blindagem contra Injeção (Input Validation e Output Encoding): A mitigação de Injeção (A03 do OWASP) vai além do uso de Prepared Statements para SQL. É mandatório o uso de Validação de Entrada (Input Validation) para garantir que os dados recebidos estejam no formato esperado e o Codificação de Saída (Output Encoding) para neutralizar dados antes de serem renderizados no navegador, prevenindo ataques como Cross-Site Scripting (XSS).
• Redução de Vazamento de Informações e Logs Seguros: O tratamento de exceções deve ser padronizado para evitar a exposição de detalhes técnicos em produção. Em adição, a prática de Logs Seguros exige a sanitização de dados sensíveis (PII - Personally Identifiable Information, senhas, tokens) antes do registro, garantindo que a observabilidade não comprometa a privacidade e a segurança dos dados.
• Gestão Proativa de Dependências Vulneráveis: A Análise de Composição de Software (SCA) deve ser integrada ao pipeline de CI/CD para bloquear automaticamente builds que contenham dependências com vulnerabilidades críticas (CVSS > 7.0). A atualização deve ser proativa e automatizada sempre que possível, como parte da manutenção regular do código, e não apenas em resposta a alertas de segurança.

2.4. As 10 Melhores Práticas de Segurança do CERT/CC

O Computer Emergency Response Team (CERT/CC) [4] publica diretrizes de segurança que abrangem todo o ciclo de vida do desenvolvimento. Estas 10 práticas são consideradas essenciais para a construção de software seguro:

1. Validar a entrada (Validate input)

Nunca confie em dados provenientes de fontes externas (usuários, APIs, arquivos). Valide o formato, o tipo, o tamanho e o conteúdo de toda entrada para garantir que esteja dentro dos limites esperados.

2. Prestar atenção aos avisos do compilador (Heed compiler warnings)

Avisos de compilador (warnings) frequentemente indicam código que pode levar a comportamento indefinido ou vulnerabilidades de segurança (como estouro de buffer). Trate os avisos como erros.

3. Arquitetar e projetar para políticas de segurança (Architect and design for security policies)

A segurança deve ser um requisito de design. Inclua a modelagem de ameaças (Threat Modeling) e defina políticas de segurança claras na fase de arquitetura.

4. Manter a simplicidade (Keep it simple)

A complexidade é inimiga da segurança. Mantenha o design e o código o mais simples possível para reduzir a superfície de ataque e facilitar a auditoria.

5. Negação por padrão (Default deny)

Por padrão, todo acesso, permissão ou funcionalidade deve ser negado. Conceda apenas o que for estritamente necessário (o oposto de "permitir tudo, exceto o que é proibido").

6. Aderir ao princípio do menor privilégio (Adhere to the principle of least privilege)

Cada usuário, processo ou componente deve ter apenas as permissões mínimas necessárias para executar sua função. Isso limita o dano em caso de comprometimento.

7. Sanitizar dados enviados a outro software (Sanitize data sent to other software)

Antes de enviar dados para outro componente (como um banco de dados, sistema operacional ou navegador), sanitize-os para remover ou neutralizar qualquer conteúdo malicioso.

8. Praticar defesa em profundidade (Practice defense in depth)

Implemente múltiplas camadas de segurança independentes. Se uma falhar, a próxima camada deve ser capaz de impedir o ataque.

9. Usar técnicas eficazes de garantia de qualidade (Use effective quality assurance techniques)

Utilize testes de segurança (SAST, DAST, fuzzing) e revisões de código rigorosas para identificar e corrigir vulnerabilidades antes da produção.

10. Adotar um padrão de codificação segura (Adopt a secure coding standard)

Utilize e siga um conjunto de regras de codificação segura (como os padrões CERT C/C++ ou Java) para evitar erros comuns de programação que levam a vulnerabilidades.

3. Principais Responsabilidades

O responsável pela Segurança do Software atua como um consultor técnico e auditor, garantindo que os princípios de segurança sejam aplicados em todas as fases do desenvolvimento de software.

3.1. Na Fase de Definição e Design

Esta fase é crítica para o Security by Design, onde o custo de correção de uma falha de segurança é o mais baixo.

• Security Requirements: Colaborar com a Engenharia de Requisitos (Leonardo) para definir requisitos não-funcionais de segurança claros e mensuráveis (ex: "O sistema deve suportar autenticação de dois fatores").
• Ameaças (Threat Modeling): Conduzir a modelagem de ameaças para identificar potenciais vetores de ataque e vulnerabilidades no design antes que o código seja escrito.
• Regras arquiteturais mínimas: Definir padrões de segurança para a arquitetura (ex: segmentação de rede, uso de firewalls de aplicação - WAF, e padrões de criptografia).
• Revisão de riscos: Avaliar o risco de segurança de novas funcionalidades ou integrações e definir a prioridade de mitigação.

3.2. Durante Implementação

Apoiar a Implementação (Gabriel) na aplicação das práticas de codificação segura.

• Codificação Segura: Garantir que as práticas detalhadas no Guia de Implementação (Seção 7) sejam seguidas, incluindo sanitização de inputs, uso de logs seguros (sem dados sensíveis) e tratamento adequado de exceções.
• Análise Estática de Código (SAST): Configurar e monitorar ferramentas de SAST nos pipelines de CI/CD para identificar automaticamente padrões de código inseguros.

3.3. Durante Testes e Entrega

Garantir que o produto final esteja em conformidade com os padrões de segurança antes da liberação.

• Segurança em APIs: Revisão de segurança de APIs, garantindo que a autenticação e autorização sejam aplicadas corretamente em todos os endpoints.
• Testes de intrusão: Coordenar e validar os resultados de testes de intrusão (Pen-tests) realizados por Q&A (Giovana) ou terceiros.
• Revisão de dependências: Auditoria final de todas as dependências de terceiros para garantir que não haja vulnerabilidades críticas conhecidas.
• Conformidade com OWASP: Certificar que o software não apresente nenhuma das vulnerabilidades listadas no OWASP Top 10.

4. Integração com o Time

A segurança é uma responsabilidade compartilhada. O responsável pela Segurança do Software atua em parceria com todos os times da Fábrica:

Integração da Segurança do Software com os Times da Fábrica

Time	Responsável	Apoio da Segurança do Software
Engenharia de Requisitos	Leonardo	Definição de requisitos não-funcionais de segurança (autenticação, auditoria, resiliência). Inclusão de casos de uso de abuso (Abuse Cases).
Projeto de Software / Modelagem	Luis Henrique / Davi	Condução de Threat Modeling e revisão de design para garantir que a arquitetura seja segura por padrão.
Implementação	Gabriel	Treinamento em codificação segura e apoio na implementação de blindagens (ex: sanitização de inputs, logs seguros, gestão de segredos).
Q&A / Garantia da Entrega	Giovana / João Gabriel	Definição de escopo para testes de segurança, incluindo fuzzing, testes de regressão de segurança e validação de mitigação de vulnerabilidades.
Operação	Samuel	Gestão de segredos em produção (Vaults), hardening de ambientes e monitoramento de logs de segurança para detecção de anomalias.
Integrações	Paula	Definição de padrões de comunicação segura (ex: OAuth 2.0, mTLS) e validação de segurança de APIs de terceiros.

5. Glossário de Segurança

C

CVSS

Padrão internacional usado para medir a gravidade de vulnerabilidades de segurança em software, hardware ou sistemas. Ele produz uma nota numérica de 0.0 a 10.0, indicando o quão crítica é a falha.

D

DAST (Dynamic Application Security Testing)

Análise de segurança de uma aplicação em execução, simulando ataques externos para identificar vulnerabilidades em tempo de execução, como falhas de autenticação ou configuração incorreta.

Defensive Programming

Abordagem de desenvolvimento de software em que você escreve o código assumindo que coisas vão dar errado, seja por erro humano, entradas inválidas, falhas externas, uso incorreto da API ou comportamentos inesperados do ambiente, com a ideia de proteger o sistema de falhas evitáveis, tornando o software mais robusto, previsível e seguro.

F

Firewall

Sistema de segurança que controla o tráfego de rede que entra e sai de um dispositivo ou servidor. Ele funciona aplicando regras para permitir ou bloquear conexões com base em IP, portas e protocolos. Serve como uma barreira entre redes confiáveis e não confiáveis. Protege contra acessos não autorizados e ataques básicos de rede. É focado na camada de rede (camadas 3 e 4 do modelo OSI).

Fuzzing

Técnica de teste de software que injeta dados semi-aleatórios ou inválidos (fuzz) em uma aplicação para tentar causar falhas, como crashes ou estouros de buffer, que podem indicar vulnerabilidades.

H

Hardening (Fortificação)

Processo de configuração de um sistema (servidor, aplicação) para torná-lo mais seguro, removendo serviços e funcionalidades desnecessárias e aplicando o princípio da negação por padrão.

O

ORM

ORM (Object-Relational Mapping) é uma forma de acessar o banco usando objetos em vez de escrever SQL direto. Ele converte operações de código em comandos SQL automaticamente. Para evitar SQL Injection, o ORM usa queries parametrizadas, onde os dados vão separados da instrução SQL. Assim, mesmo que o usuário envie algo malicioso, isso é tratado como texto e não como comando. Por isso ORMs são mais seguros do que montar SQL na mão com concatenação de strings.

P

Pentest (Teste de Intrusão)

Ataque simulado e autorizado contra um sistema para avaliar sua segurança e encontrar vulnerabilidades que um atacante real poderia explorar.

Princípio do Menor Privilégio

Conceito de segurança que exige que um usuário, processo ou programa tenha apenas as permissões mínimas necessárias para executar sua função, limitando o potencial de dano em caso de comprometimento.

S

SAST (Static Application Security Testing)

Análise de segurança de código-fonte sem executá-lo. Identifica padrões de código inseguros, como injeções SQL ou XSS, em tempo de desenvolvimento.

Security by Design

Abordagem na qual a segurança é incorporada desde o início do processo de desenvolvimento de um sistema, produto ou software.

SQL Injection

SQL Injection é um tipo de ataque onde o invasor insere comandos SQL maliciosos em entradas da aplicação para manipular o banco de dados. Isso acontece quando o sistema monta SQL por concatenação de strings, sem validar ou separar os dados do usuário. Com isso, o indivíduo de má índole pode burlar login, ler dados confidenciais, apagar tabelas, alterar informações ou até tomar controle do servidor, dependendo do caso.

T

Threat Modeling (Modelagem de Ameaças)

Processo estruturado para identificar, comunicar e entender as ameaças e vulnerabilidades potenciais em um sistema, geralmente realizado na fase de design.

W

WAF – Web Application Firewall

Um WAF é um firewall especializado para proteger aplicações web (HTTP/HTTPS). Ele analisa o conteúdo das requisições, como URLs, parâmetros, cookies e payloads. Bloqueia ataques como SQL Injection, XSS, e outras falhas do OWASP Top 10. Fica entre o cliente e o servidor, filtrando tráfego malicioso antes de chegar na aplicação. É focado na camada de aplicação (camada 7 do modelo OSI).

Whitelists

Listas de itens explicitamente permitidos em um sistema.

Referências e Leitura Recomendada

• [1] SWEBOK v4: Guide to the Software Engineering Body of Knowledge. IEEE Computer Society. (Capítulo 13 e correlatos).
• [2] OWASP Top 10: The Ten Most Critical Web Application Security Risks (Versão 2021).
• [3] Documentação Interna.
• [4] R.C. Seacord, The CERT C Secure Coding Standard, Addison-Wesley Professional, 2008.

• Documentação Interna:

1. Engenharia de Requisitos - Leonardo
2. Implementação - Gabriel
3. Q&A - Giovana
4. Operação - Samuel
5. Padrões de Trabalho - Carlos Ernani (Junin)