Diretrizes de Segurança para Desenvolvimento e Suporte

1. Introdução

1.1. Propósito

Esta Política de Diretrizes de Segurança para Desenvolvimento e Suporte (“Política”) define os requisitos mínimos para o desenvolvimento seguro de sistemas, manutenção, suporte técnico, tratamento de vulnerabilidades e gestão do ciclo de vida de aplicações da Openbanx, incluindo APIs e integrações regulatórias do Open Finance Brasil.

O objetivo é garantir que todas as soluções tecnológicas sejam projetadas, desenvolvidas, testadas e mantidas observando princípios de privacidade, segurança e conformidade regulatória, conforme:

• ISO/IEC 27001:2022 (A.8 e A.14 – Desenvolvimento Seguro e Suporte);
• ISO/IEC 27701:2025 (controles de privacidade aplicáveis ao ciclo de vida);
• LGPD – princípios de privacy by design e by default;
• Open Finance Brasil – padrões técnicos e requisitos de segurança;
• Resolução CMN nº 4.893/21 – segurança cibernética;
• OWASP ASVS, OWASP Top 10, NIST Secure SDLC.

1.2. Escopo

Esta Política se aplica a:

• equipes de Desenvolvimento, Engenharia, Arquitetura e Suporte Técnico;
• equipes de Segurança da Informação (AppSec, DevSecOps e SecOps);
• terceiros, fornecedores e prestadores de serviço que atuem no desenvolvimento, manutenção ou suporte de sistemas da Openbanx;
• todos os sistemas, APIs, microsserviços, aplicações, mecanismos de integração, pipelines DevOps e ferramentas que armazenem, processem ou transmitam dados pessoais, dados sensíveis ou dados financeiros via Open Finance.

1.3. Princípios fundamentais

As diretrizes de segurança seguem os seguintes princípios:

1. Segurança por Design: segurança incorporada desde o início do desenvolvimento.
2. Privacidade por Design: minimização de dados e proteção de dados pessoais no ciclo completo.
3. Princípio do Menor Privilégio: mínimo acesso necessário ao ambiente.
4. Ambientes Segregados: desenvolvimento/teste, homologação e produção totalmente separados.
5. Ciclo Seguro (SDLC): segurança aplicada em todas as fases do desenvolvimento.
6. Auditoria e Rastreabilidade: logs completos e auditáveis para todos os ambientes.
7. Correção Ágil: tratamento imediato de vulnerabilidades críticas e altas.

2. Papéis e responsabilidades

2.1. Equipe de Desenvolvimento

• Implementar controles de segurança nos códigos e arquiteturas.
• Utilizar boas práticas OWASP e padrões de codificação segura.
• Registrar mudanças no versionamento e garantir rastreabilidade.

2.2. Equipe de Segurança da Informação (AppSec / DevSecOps)

• Realizar análises de código (SAST), testes dinâmicos (DAST) e validações contínuas.
• Definir padrões de segurança obrigatórios para arquiteturas e APIs.
• Validar dependências, bibliotecas e componentes de software (SCA).

2.3. Equipe de Suporte Técnico

• Executar suporte com acesso controlado, criptografado e monitorado.
• Tratar requisições de correção seguindo procedimentos autorizados.
• Garantir que alterações emergenciais sejam registradas e revisadas.

2.4. Gestor de Mudanças

• Aprovar liberações, releases, patches e correções críticas.
• Garantir que o processo siga o fluxo formal de Gestão de Mudanças (ITIL/ISO).

2.5. Fornecedores e terceiros

• Cumprir integralmente esta Política.
• Utilizar ambientes seguros, segregados e compatíveis com padrões ISO e OWASP.

3. Diretrizes de desenvolvimento seguro

3.1. Ambiente e arquitetura

1. Os ambientes de desenvolvimento, homologação e produção devem ser segregados.
2. Nenhum dado pessoal real pode ser utilizado em ambientes não produtivos.
3. Os logs devem ser coletados, criptografados, analisados e mantidos conforme o Bacen.
4. O acesso à produção deve seguir o princípio do menor privilégio.

3.2. Codificação segura

1. O código deve seguir as boas práticas OWASP ASVS e OWASP Top 10.
2. Devem ser implementados controles contra:
   • SQL Injection, XSS, CSRF, SSRF;
   • quebra de autenticação;
   • exposição de dados sensíveis;
   • uso de componentes vulneráveis.
3. Dados pessoais e dados financeiros devem ser protegidos com:
   • criptografia;
   • pseudonimização;
   • minimização de dados;
   • controles de acesso robustos.

3.3. Gestão de dependências

1. Todas as dependências devem ser analisadas via SCA (Software Composition Analysis).
2. Componentes desatualizados devem ser bloqueados em pipelines CI/CD.
3. CVEs críticas devem ser corrigidas em até 24 horas.

3.4. Revisão de código

1. Todo código deve passar por revisão (pull request) por desenvolvedor independente.
2. Códigos relacionados a segurança e dados sensíveis exigem dupla revisão.
3. O AppSec deve atuar em mudanças de alto risco.

4. Diretrizes de suporte técnico

4.1. Acesso de suporte

1. O acesso a máquinas de produção só pode ocorrer via conexão segura e auditável.
2. Credenciais temporárias devem ser utilizadas.
3. Todas as sessões de suporte devem gerar logs centralizados.

4.2. Intervenções em produção

1. Toda alteração em produção deve estar registrada em:
   • sistema de gestão de mudanças;
   • chamado formal;
   • pipeline de auditoria.
2. Alterações emergenciais devem ser regularizadas em até 24 horas.

4.3. Atendimento a incidentes

1. O suporte técnico deve atuar seguindo o Plano de Resposta a Incidentes.
2. Incidentes que envolvam dados pessoais devem ser imediatamente reportados ao DPO.
3. Incidentes que envolvam APIs do Open Finance devem seguir os requisitos do Bacen.

5. Testes de segurança e validação

5.1. Testes de segurança obrigatórios

1. Análise Estática (SAST).
2. Análise Dinâmica (DAST).
3. Pentests periódicos.
4. Testes de segurança em APIs Open Finance.
5. Verificação de bibliotecas (SCA).
6. Testes de regressão após cada release.

5.2. Testes antes de ir para produção

Nenhum componente será promovido a produção sem:

• aprovação de segurança;
• revisão de código;
• validação de vulnerabilidades;
• testes funcionais e de integridade.

6. Gestão de vulnerabilidades

1. Vulnerabilidades críticas: correção imediata (≤ 24h).
2. Vulnerabilidades altas: correção em até 3 dias úteis.
3. Vulnerabilidades médias: até 10 dias úteis.
4. Vulnerabilidades baixas: em ciclos normais de release.
5. O AppSec deve confirmar a mitigação antes do fechamento do ticket.
6. Dependências com CVEs não resolvidas não podem ser publicadas.

7. Revisão e vigência

Esta Política será revisada pelo Comitê de Segurança e Privacidade:

• anualmente; ou
• sempre que houver mudanças significativas nos sistemas, arquiteturas, regulamentações ou requisitos técnicos do Open Finance.

8. Referências

Esta Política baseia-se nos seguintes normativos, padrões e guias:

1. ISO/IEC 27001:2022 – A.8, A.14 (Desenvolvimento seguro e suporte).
2. ISO/IEC 27701:2025 – Requisitos de privacidade no ciclo de vida.
3. LGPD – arts. 46 a 50 (Segurança, boas práticas e governança).
4. Resolução CMN nº 4.893/2021 – Segurança cibernética.
5. Open Finance Brasil – Padrões técnicos e de segurança (versões vigentes).
6. OWASP ASVS, OWASP Top 10, OWASP SAMM.
7. NIST Secure SDLC – Secure Software Development Framework (SSDF).