Segurança no Android: patch instalado, publicado e disponível não são iguais

As bibliotecas AndroidX Security State e Security State Provider oferecem uma avaliação de correções por componente, distinguindo sistema operacional, módulos atualizados pelo Google Play e kernel.[6] O desenho separa o patch presente no aparelho, o mais recente oficialmente publicado e aquele efetivamente disponível para instalação.[6]

Para quem desenvolve aplicativos sensíveis, a utilidade está nessa separação. Antes de transformar uma data em regra de bloqueio, é preciso saber o que ela representa. Um diagnóstico sem essa distinção pode exigir do usuário uma atualização que ele ainda não consegue instalar.

O que muda para quem desenvolve

Device SPL informa o nível de correção presente no dispositivo e pode ser consultado diretamente, sem rede.[6] Published SPL representa o nível mais recente oficialmente publicado pelo Google para um componente.[6] Available SPL representa a correção disponível para download e instalação naquele aparelho.[6]

A biblioteca também permite consultar atualizações pendentes e verificar se CVEs específicas já foram corrigidas.[6] A Security State Provider é voltada aos fabricantes e padroniza o anúncio de correções disponíveis pelos clientes de atualização.[6]

Minha leitura de arquitetura é que o aplicativo deve representar esses sinais separadamente. Reduzi-los a um booleano chamado “seguro” elimina justamente a informação que torna a decisão explicável. Prefira um diagnóstico ligado à operação: qual componente importa, qual correção está instalada e qual ação o usuário pode realizar.

Também separe observação de política. Uma biblioteca fornece informação sobre correções. A decisão de permitir, limitar ou negar uma função deve ser uma regra explícita do produto, revisada conforme o risco daquela função.

Como aplicar

Comece com uma operação específica, não com o bloqueio de todo o aplicativo. Defina quais falhas justificariam restringi-la e qual orientação aparecerá para o usuário. Mantenha um estado de informação desconhecida, em vez de converter qualquer erro de consulta em “aparelho seguro” ou “aparelho vulnerável”.

Como experimento, teste a política com entradas controladas antes de integrar aparelhos reais:

1. Correção instalada e requisito atendido. A operação segue normalmente.
2. Correção ausente, mas disponível. O aplicativo explica a atualização necessária.
3. Correção publicada, porém ainda indisponível para o aparelho. A política aplica a restrição prevista e oferece uma alternativa quando possível.
4. Informação insuficiente. O aplicativo declara a incerteza e usa o tratamento definido para aquele risco.

Depois, confronte essas expectativas com dispositivos de fabricantes e idades diferentes. Observe o diagnóstico e a experiência de atendimento, não apenas se uma chamada retornou sucesso. Não invente compatibilidade a partir de um único aparelho de desenvolvimento.

Cuidados e limites

Estar atualizado em relação a todos os patches disponíveis não equivale a estar livre de qualquer vulnerabilidade.[6] A existência de uma correção publicada também não garante que o fabricante já a ofereça para todo modelo.[6]

A reportagem não apresenta uma matriz completa de disponibilidade por fabricante nem números de eficácia.[6] Essas lacunas precisam entrar no piloto. O trade-off é entre proteção e acesso: uma política rígida pode restringir usuários sem solução imediata, enquanto uma política permissiva precisa tornar o risco visível. A biblioteca melhora a informação da decisão; não decide sozinha qual risco o produto deve aceitar.

Fonte

[6] Fonte: InfoQ