Pela equipa de Quality Engineering da MTP International · Outubro 2026
Quando uma instituição financeira ou uma organização de saúde sofre uma falha de segurança, o regulador não pergunta que ferramenta de proteção tinha instalada. Pergunta que vulnerabilidades existiam nas aplicações, se tinham sido identificadas com antecedência e que evidências existem de que a equipa de desenvolvimento tomou ações para as remediar. Essa sequência transforma a segurança do software num assunto de conformidade formal, não apenas de risco técnico.
Os setores regulados são o objetivo mais frequente e o mais afetado. O setor financeiro registou em 2024 uma média de 1.510 incidentes de cibersegurança por empresa por semana, um aumento de 30% em relação ao ano anterior (Check Point Software Security Report 2025). 60% dos hospitais sofreram falhas de dados durante o mesmo período. Essa pressão não é aleatória: é consequência direta do valor dos dados que estes setores processam e da superfície de ataque que a digitalização acelerada gerou sem validação de segurança proporcional.
Porque é que os setores regulados concentram o maior risco?
A combinação de três fatores específicos explica porque é que a banca, fintech, saúde e telecomunicações concentram o maior volume de incidentes de segurança em aplicações:
Os dados que processam têm valor direto e monetizável: credenciais bancárias, números de cartão, históricos clínicos, dados de identidade. Um atacante que compromete uma aplicação de saúde ou finanças obtém ativos que pode vender, usar para fraude ou usar como alavanca num ataque de ransomware.
A pressão regulatória cria um paradoxo de documentação: as organizações sob CNBV, PCI-DSS, LFPDPPP ou NOM-151 têm a obrigação de demonstrar que os seus sistemas são seguros, mas a velocidade de lançamento de software que o mercado exige compete diretamente com o tempo necessário para validar essa segurança.
A interconectividade com terceiros amplia a superfície de ataque para além do código próprio. As APIs que conectam bancos com fintechs, os módulos de pagamento de terceiros em plataformas de retalho, os sistemas de fornecedores em hospitais: cada integração é um vetor potencial que nem sempre está sob o controlo da equipa de segurança interna.
As seis vulnerabilidades mais críticas em setores regulados
1. Controlo de acesso quebrado
É a vulnerabilidade mais prevalente do OWASP Top 10 2025, encontrada em 94% das aplicações testadas. Em setores regulados, o seu impacto é especialmente grave porque as aplicações gerem perfis com níveis de privilégio radicalmente distintos: um cliente, um consultor, um administrador regional e um auditor não devem poder aceder aos mesmos recursos, mas em muitas implementações basta modificar um parâmetro de URL para escalar privilégios ou aceder a registos de outros utilizadores.
Para a CNBV e para o PCI-DSS, a ausência de controlos de acesso corretamente implementados não é uma descoberta técnica menor: é um incumprimento que pode resultar em auditorias formais.
2. Falhas criptográficas
No OWASP 2025 ocupam o quarto lugar, mas em setores que processam dados financeiros ou de saúde são um risco de primeira ordem. Os modos de falha mais comuns incluem o uso de algoritmos de cifragem obsoletos ou fracos, a transmissão de dados sensíveis sem cifragem em canais internos que se assumem seguros, e o armazenamento de credenciais ou tokens sem hash correto.
O PCI-DSS exige cifragem específica para os dados de cartão em trânsito e em repouso. A LFPDPPP obriga a proteger os dados pessoais com controlos técnicos proporcionais à sua sensibilidade. Uma falha criptográfica em qualquer uma dessas camadas não é apenas um risco técnico: é um incumprimento normativo com consequências legais.
3. Injeções e scripting entre sites (XSS)
As injeções SQL, NoSQL e de comandos mantêm a sua posição entre os três vetores de ataque mais explorados em aplicações financeiras. As aplicações de banca digital e os portais de saúde são alvo frequente porque concentram dados de alto valor e costumam ter formulários de entrada que recebem dados do utilizador sem validação suficiente.
O XSS permite a um atacante injetar código malicioso no navegador de outro utilizador, o que em plataformas bancárias pode resultar em roubo de sessão, captura de credenciais ou execução de transações não autorizadas. Ambas as categorias são detetáveis com análise estática (SAST) e dinâmica (DAST) antes de chegarem à produção.
4. Vulnerabilidades na cadeia de fornecimento de software
Esta categoria é nova no OWASP Top 10 2025 e reflete o impacto de incidentes como SolarWinds e Log4Shell: vulnerabilidades introduzidas não no código próprio, mas nas dependências de terceiros que a aplicação utiliza.
Os dados do setor financeiro são contundentes: 82% da dívida de segurança crítica em organizações bancárias, de serviços financeiros e de seguros provém de vulnerabilidades em componentes de código aberto com CVEs não corrigidos (Veracode, State of Software Security 2025). Além disso, 63% das empresas de serviços financeiros têm dívida de segurança crítica ativa — falhas de alta gravidade não remediadas por mais de um ano —, uma taxa 13 pontos percentuais superior à média geral.
5. Falhas de autenticação e gestão de sessões
O credential stuffing — o uso automatizado de credenciais roubadas noutras falhas para tentar acesso em novas plataformas — é um dos ataques mais ativos contra a banca digital. 48% das empresas fintech foram alvo de ransomware, frequentemente iniciado pelo compromisso de uma conta com credenciais fracas ou sessões sem expiração correta.
Os controlos que mitigam este risco — autenticação multifator, limites de tentativas de login, expiração de sessões inativas, deteção de acesso a partir de localizações anómalas — devem ser validados não só na sua configuração, mas sob condições de ataque simulado. Um controlo que existe no papel, mas que não funciona sob pressão real, é equivalente a não o ter.
6. APIs sem proteção adequada
O OWASP API Security Top 10 documenta as vulnerabilidades específicas das interfaces de programação: autorização ao nível do objeto defeituosa (BOLA), atribuição massiva de propriedades, ausência de limites de taxa de pedidos e falsificação de pedidos do lado do servidor (SSRF). Para fintechs e bancos digitais cujo produto vive inteiramente em APIs, estas vulnerabilidades são o vetor de ataque mais direto e o mais frequentemente subvalorizado.
A interconectividade entre instituições financeiras, agregadores de dados e plataformas de pagamento através de APIs abertas amplia o perímetro de segurança para sistemas que a organização não controla diretamente. Cada integração é um ponto de entrada que deve estar no âmbito do programa de testes de segurança.
O padrão de dívida de segurança em finanças e saúde
O que distingue os setores regulados não é apenas o tipo de vulnerabilidades que têm, mas a velocidade a que a dívida de segurança se acumula sem ser remediada. 63% das empresas financeiras têm falhas de alta gravidade não corrigidas por mais de um ano. Isso significa que as vulnerabilidades são conhecidas, mas não priorizadas, frequentemente porque a equipa de desenvolvimento não tem um processo estruturado para converter descobertas de segurança em tarefas de sprint com critérios de aceitação claros.
A remediação sem processo produz o mesmo ciclo: o pentest identifica descobertas, a equipa de segurança produz um relatório, o relatório vai para uma fila de trabalho onde compete com o backlog de novas funcionalidades, e as descobertas de alta gravidade permanecem abertas durante meses enquanto o próximo ciclo de auditoria se aproxima.
A perspetiva da MTP
Na MTP, integramos a validação de segurança como uma camada contínua do pipeline de QE, não como um exercício pontual antes da auditoria. Com o Omniatest®, a nossa metodologia proprietária — a MTP é a primeira empresa certificada TMMi Nível 5 no mundo —, os quality gates de segurança bloqueiam o avanço do pipeline quando são detetadas descobertas de criticidade alta, e cada descoberta produz evidências auditáveis que o regulador pode rever.
O trabalho com organizações financeiras e de saúde no México mostrou-nos que a pergunta relevante não é se existem vulnerabilidades: elas sempre existem. A pergunta é se existe o processo para as encontrar antes do atacante, remediá-las com a prioridade correta e documentar as evidências que o regulador vai pedir.
Perguntas frequentes
- O OWASP Top 10 é suficiente como quadro de segurança para uma organização regulada no México? O OWASP Top 10 é um ponto de partida sólido e amplamente reconhecido: quadros normativos como ISO 27001, SOC 2 e PCI-DSS citam-no explicitamente como padrão de codificação segura. No México, a CNBV e a LFPDPPP não o mencionam pelo nome nas suas circulares, mas a cobertura das suas categorias é evidência aceite de práticas de desenvolvimento seguro durante auditorias. Dito isto, o OWASP Top 10 cobre vulnerabilidades em aplicações web; uma organização regulada também precisa de cobrir APIs (OWASP API Top 10), móvel (OWASP Mobile Top 10) e infraestrutura cloud, dependendo do seu stack.
- Qual é a diferença entre dívida de segurança e vulnerabilidade ativa? Uma vulnerabilidade ativa é uma falha de segurança confirmada que existe no sistema e que um atacante pode explorar. A dívida de segurança é o conjunto de vulnerabilidades conhecidas que a equipa decidiu não remediar de imediato — por prioridade, por recursos ou por custo de correção — e que permanecem abertas. O problema da dívida de segurança é que acumula risco de forma silenciosa: uma falha de alta gravidade aberta por mais de um ano não é apenas um risco técnico, é um incumprimento regulatório em qualquer organização sob PCI-DSS ou supervisão da CNBV.
- Com que frequência devem ser executados os testes de segurança em aplicações de banca ou saúde? Em organizações com ciclos de lançamento frequentes — semanal ou quinzenal — a análise estática (SAST) deve ser executada em cada ciclo de integração como quality gate automático. A análise dinâmica (DAST) deve ser executada sobre ambientes de staging em cada release significativo. O pentesting manual, que simula um ataque real executado por um especialista, deve ser realizado pelo menos uma vez por ano como validação completa da postura de segurança, e sempre antes de mudanças arquitetónicas de alto impacto: migração cloud, incorporação de novas APIs, lançamento de um novo canal digital.
A sua organização sabe que vulnerabilidades tem ativas nas suas aplicações hoje?
O Quick Assessment de Segurança da MTP identifica os vetores de exposição mais críticos em cinco dias úteis, com evidências prontas para o regulador.