MASWE-0076: Dependências com Vulnerabilidades Conhecidas

Content in BETA

This content is in beta and still under active development, so it is subject to change any time (e.g. structure, IDs, content, URLs, etc.).

Send Feedback

Visão Geral

Aplicativos móveis frequentemente dependem de bibliotecas de terceiros, kits de desenvolvimento de software (SDKs) ou frameworks, sejam componentes de código aberto mantidos pela comunidade ou produtos de código fechado fornecidos por fornecedores comerciais, para implementar funcionalidades, agilizar o desenvolvimento ou integrar serviços de plataforma.

Quando essas dependências contêm vulnerabilidades, elas podem ser mais facilmente exploradas do que vulnerabilidades em código próprio, pois essas vulnerabilidades (e alguns exploits) costumam ser documentadas em bancos de dados públicos, como a lista CVE, ou acessíveis por meio de alertas de segurança.

O desenvolvedor é responsável por garantir que todas as dependências estejam seguras e atualizadas, pois elas fazem parte da base de código do aplicativo e, portanto, ampliam a superfície de ataque do app. O Google e a Apple enfatizam isso em suas melhores práticas de segurança:

Google Usando SDKs de forma segura

"Se você incluir um SDK em seu app, é responsável por garantir que o código de terceiros e as práticas estejam em conformidade com as Políticas do Programa para Desenvolvedores do Google Play e não façam com que seu app viole as políticas."

Apple Diretrizes de análise da App Store

"Você é responsável por garantir que tudo em seu app esteja em conformidade com estas diretrizes, incluindo redes de anúncios, serviços de analytics e SDKs de terceiros, portanto, analise-os e escolha-os com cuidado."

Em termos de privacidade, as dependências podem introduzir riscos se coletarem ou transmitirem dados do usuário sem consentimento adequado ou transparência. Tanto o Google quanto a Apple exigem que SDKs de terceiros usados em apps cumpram suas políticas e diretrizes de privacidade para garantir que os dados do usuário sejam tratados de forma segura e transparente. É responsabilidade do desenvolvedor garantir que quaisquer bibliotecas ou SDKs de terceiros usados no app adiram a esses requisitos, mesmo que as bibliotecas em si não estejam sob seu controle direto e mesmo que não usem o código específico que possa violar as políticas da plataforma.

Google Usando SDKs de forma segura

"Os desenvolvedores de apps são obrigados a tratar qualquer coleta de dados de dentro de seu app por um SDK como se tivessem coletado diretamente."

Apple Requisitos para SDKs de terceiros

"Ao usar um SDK de terceiros com seu app, você é responsável por todo o código que o SDK inclui em seu app e precisa estar ciente de suas práticas de coleta e uso de dados."

Para mais informações sobre declarações de privacidade e coleta de dados, consulte Declarações Inadequadas de Coleta de Dados.

Impacto

O uso de dependências com vulnerabilidades conhecidas em aplicativos móveis pode resultar em vários riscos de segurança, incluindo, mas não se limitando a:

• Exposição de Dados Sensíveis: Dependências vulneráveis podem ser exploradas para contornar controles de acesso ou proteções criptográficas, o que pode levar à exposição de dados sensíveis do usuário, incluindo credenciais, tokens de sessão e informações pessoalmente identificáveis (PII). Isso pode resultar em violações de dados, que podem ter consequências legais, financeiras e reputacionais.
• Execução de Código Não Autorizado ou Escalonamento de Privilégios: Vulnerabilidades exploráveis em dependências incorporadas podem permitir que atacantes executem código arbitrário no contexto do app (por exemplo, por meio de injeção de código), escalonem privilégios ou manipulem o comportamento do app. O impacto geral pode variar desde o comprometimento total de contas de usuário, abuso de serviços de backend ou acesso persistente a recursos protegidos. O impacto comercial pode ser severo, incluindo perda financeira, interrupção de serviço e danos à confiança do cliente.
• Não Conformidade Regulatória e com Políticas: Incluir dependências com CVEs publicamente conhecidos pode violar requisitos regulatórios (por exemplo, GDPR, HIPAA, PCI-DSS) ou políticas de segurança de plataforma (por exemplo, diretrizes do Google Play ou da App Store). A falha em atualizar ou remediar tais vulnerabilidades pode resultar em rejeição do app, multas ou divulgações obrigatórias.

Modos de Introdução

• Dependências Diretas: Dependências vulneráveis podem ser introduzidas no app manualmente (copiando e vinculando arquivos fonte ou binários) ou, mais comumente, por meio de gerenciadores de pacotes e ferramentas de build (por exemplo, Gradle, CocoaPods, Swift Package Manager). Isso inclui SDKs próprios e de terceiros e pode envolver bibliotecas vinculadas estaticamente e dinamicamente.
• Dependências Transitivas: Dependências podem ser incluídas indiretamente por meio de outras bibliotecas ou SDKs que o app utiliza. Isso significa que um app ainda pode ser afetado por uma biblioteca vulnerável se uma de suas dependências a incluir, mesmo que o app não inclua diretamente a biblioteca em si.
• Dependências Carregadas Dinamicamente: Algumas bibliotecas podem ser carregadas dinamicamente em tempo de execução, o que pode dificultar o rastreamento e o gerenciamento de dependências. Isso pode levar a situações em que uma versão vulnerável de uma biblioteca é usada sem o conhecimento do desenvolvedor.
• Componentes de Segurança de Plataforma Desatualizados: Aplicativos móveis podem depender de componentes de segurança fornecidos pela plataforma, como bibliotecas criptográficas ou implementações SSL/TLS. Se esses componentes estiverem desatualizados ou não receberem atualizações oportunas, podem introduzir vulnerabilidades conhecidas na aplicação. Por exemplo, no Android, o provedor de segurança do sistema responsável por comunicações de rede seguras deve ser explicitamente atualizado pelo desenvolvedor na inicialização do app.
• Uso de Frameworks de Terceiros: Aplicações podem ser construídas em um framework de aplicativo de terceiros, como Flutter ou React Native. O próprio framework, bem como quaisquer bindings específicos de plataforma, podem conter vulnerabilidades.

Mitigações

• Use uma Lista de Materiais de Software (SBOM): Produza e mantenha uma SBOM para rastrear todos os componentes e dependências transitivas, garantindo visibilidade e responsabilidade pelo código de terceiros. Consulte NIST SSDF (NIST SP 800-218) PS.3.2, NTIA Os Elementos Mínimos para uma Lista de Materiais de Software (SBOM), Documento de Tipos de SBOM da CISA para mais informações sobre SBOMs e sua importância no gerenciamento de dependências de software.
• Atualize Dependências de Forma Responsável: Como parte do gerenciamento seguro de dependências, monitore regularmente todas as dependências de terceiros usadas em busca de atualizações relacionadas à segurança (por exemplo, usando ferramentas de Análise de Composição de Software (SCA) e SBOMs em seus pipelines de CI/CD). Aplique atualizações quando elas corrigirem vulnerabilidades conhecidas e fixe versões explicitamente para evitar alterações inesperadas e reduzir o risco de ataques à cadeia de suprimentos.
• Remova Dependências Não Utilizadas ou Obsoletas: Revise e elimine periodicamente bibliotecas não utilizadas, legadas ou desnecessárias para reduzir a superfície de ataque do app e a carga de dependências.
• Use Fontes Confiáveis: Inclua apenas bibliotecas e SDKs de fontes confiáveis, como repositórios oficiais ou projetos de código aberto bem mantidos, para minimizar o risco de introduzir código malicioso ou vulnerável.

Tests

MASTG-TEST-0272: Identificar Dependências com Vulnerabilidades Conhecidas no Projeto Android MASTG-TEST-0274: Dependências com Vulnerabilidades Conhecidas no SBOM do Aplicativo MASTG-TEST-0275: Dependências com Vulnerabilidades Conhecidas no SBOM do Aplicativo MASTG-TEST-0273: Identificar Dependencies com Vulnerabilities conhecidas por meio da verificação de Dependency Managers Artifacts