Este guia descreve as práticas recomendadas do Google para a aplicação de patches de segurança avaliados pelo Android Compatibility Test Suite (CTS). Destina-se a fabricantes de equipamentos OEM compatíveis com Android (Fabricantes) que serão suportados por mais de três (3) anos, como veículos, TVs, decodificadores, eletrodomésticos, etc. Este guia não se destina a usuários finais ( por exemplo, proprietários de veículos).
Agradecimentos e isenções de responsabilidade
Este guia não vincula legal ou contratualmente o Google ou outros fabricantes e não se destina a ser um conjunto de requisitos. Em vez disso, este guia é um auxílio instrucional que descreve as práticas recomendadas.
Comentários
Este guia não pretende ser abrangente; revisões adicionais estão planejadas. Envie comentários para fabricantes-guia-android@googlegroups.com.
Glossário
| Prazo | Definição |
|---|---|
| ACC | Compromisso de compatibilidade com Android. Anteriormente conhecido como Android Anti-Fragmentation Agreement (AFA). |
| AOSP | Projeto de código aberto Android |
| ASB | Boletim de segurança do Android |
| BSP | Pacote de Suporte da Diretoria |
| CDD | Documento de Definição de Compatibilidade |
| CTS | Conjunto de testes de compatibilidade |
| FOTA | Firmware pelo ar |
| GPS | Sistema de Posicionamento Global |
| MISRA | Associação de Confiabilidade de Software da Indústria Automobilística |
| NIST | Instituto Nacional de Padrões e Tecnologia |
| OBD | Diagnóstico a bordo ( OBD-II é uma melhoria em relação ao OBD-I em capacidade e padronização ) |
| OEM | Fabricante de Equipamento Original |
| SO | Sistema operacional |
| SEI | Instituto de Engenharia de Software |
| SOC | Sistema no chip |
| SOP | Início da Produção |
| SPL | Nível de patch de segurança |
| TPMS | Sistema de monitorização da pressão nos pneus |
Sobre o sistema operacional Android
O Android é uma pilha de software completa baseada em Linux, de código aberto, projetada para uma variedade de dispositivos e fatores de forma. Desde seu primeiro lançamento em 2008, o Android se tornou o sistema operacional mais popular ("SO"), alimentando mais de 1,4 bilhão de dispositivos em todo o mundo (2016). Aproximadamente 67% desses dispositivos usam o Android 5.0 (Lollipop) ou mais recente em março de 2017 (os números mais recentes estão disponíveis no Android Dashboard ). Enquanto a grande maioria dos dispositivos são telefones celulares e tablets, o Android está crescendo em smartwatches, TVs e dispositivos automotivos de infoentretenimento ("IVI").
O número de aplicativos Android disponíveis na Google Play Store atingiu mais de 2,2 milhões (2016). O desenvolvimento de aplicativos Android é apoiado pelo programa de Compatibilidade Android, que define um conjunto de requisitos por meio do Documento de Definição de Compatibilidade (CDD) e fornece ferramentas de teste por meio do Compatibility Test Suite (CTS) . Os programas de compatibilidade do Android garantem que qualquer aplicativo Android possa ser executado em qualquer dispositivo compatível com Android que suporte os recursos necessários para o aplicativo.
O Google lança regularmente novas versões do sistema operacional, atualizações de segurança do sistema operacional e informações sobre vulnerabilidades descobertas. O Boletim de segurança do Android deve ser revisado pelos fabricantes para verificar a aplicabilidade dessas atualizações aos produtos compatíveis com o sistema operacional Android. Para uma revisão da segurança, compatibilidade e sistemas de compilação do Android, consulte o seguinte:
- Proteja um dispositivo Android
- Atualizações e recursos de segurança
- Conjunto de testes de compatibilidade
- Codinomes, tags e números de compilação
Sobre veículos conectados (produto canônico de longa duração)
Os veículos começaram a ser conectados com a introdução do rádio AM na década de 1920. A partir daí, o número de conexões externas físicas e sem fio começou a crescer à medida que reguladores e montadoras se voltaram para a eletrônica para facilitar diagnósticos e serviços (por exemplo, porta OBD-II), melhorar a segurança (por exemplo, TPMS) e atender às metas de economia de combustível. . A próxima onda de conectividade introduziu recursos de conveniência para o motorista, como entrada remota sem chave, sistemas de telemática e recursos avançados de infoentretenimento, como Bluetooth, Wi-Fi e projeção de smartphone. Hoje, sensores integrados e conectividade (por exemplo, GPS) suportam sistemas de segurança e condução semi-autônoma.
À medida que o número de conexões de veículos aumenta, também aumenta a área da superfície potencial de ataque do veículo. As conexões trazem consigo uma coleção semelhante de preocupações de segurança cibernética quanto aos eletrônicos de consumo. No entanto, embora reinicializações, atualizações diárias de patches e comportamentos inexplicáveis sejam a norma para eletrônicos de consumo, eles são inconsistentes para produtos com sistemas críticos de segurança, como veículos.
Os fabricantes devem adotar uma abordagem proativa para garantir a segurança contínua e a postura de segurança de um produto em campo. Em resumo, os fabricantes devem estar cientes das vulnerabilidades de segurança conhecidas no produto e adotar uma abordagem baseada em risco para resolvê-las.
Garantindo a segurança a longo prazo
Um veículo conectado geralmente tem uma ou mais unidades de controle eletrônico ("ECUs") que incluem vários componentes de software, como SO, bibliotecas, utilitários etc. Os fabricantes devem rastrear esses componentes e identificar vulnerabilidades publicadas conhecidas com análise proativa, incluindo:
- Avaliar regularmente o produto em relação ao banco de dados de Vulnerabilidades e Exposições Comuns (CVE).
- Coleta de inteligência para falhas de segurança relacionadas ao produto.
- Testes de segurança.
- Analisando ativamente os boletins de segurança do Android.
Exemplo de atualizações de SO e patches de segurança (IVIs executando Android):
Figura 1. Exemplo de implementação de atualização de segurança e SO principal ao longo da vida útil do veículo.
| # | Etapa | Atividades |
|---|---|---|
① | Ramo de Desenvolvimento | O Fabricante seleciona uma versão do Android (Android X). Neste exemplo, o 'Android X' se torna a base do que será enviado no veículo dois anos antes do início da produção (SOP). |
| ② | Lançamento inicial | Alguns meses antes do Android X se tornar a primeira versão do sistema operacional fornecida no produto, as atualizações de segurança são extraídas dos boletins de segurança do Android (ASBs) e potencialmente de outras fontes consideradas valiosas pelo fabricante. y2 = o segundo boletim de segurança para a versão X do Android, aplicado (backported) pelo fabricante ao Android X. Esta atualização é fornecida no produto e o relógio de produção começa a contar no ano zero com o Android X.y2. Neste exemplo, o fabricante decidiu não enviar a versão anual mais recente do Android X+1. Os motivos para enviar a versão mais recente incluem adicionar novos recursos, abordar novas vulnerabilidades de segurança e/ou enviar serviços do Google ou de terceiros que exigem a versão mais recente do Android. Motivos contra o envio com o lançamento mais recente é a falta de tempo inerente ao processo de desenvolvimento e lançamento do veículo necessário para integrar, testar e validar as alterações, incluindo o cumprimento de todos os requisitos regulamentares e de certificação. |
| ③ | Atualização completa do SO | Após o SOP, o fabricante lança a atualização do sistema operacional Android X+2, que são duas versões do Android após a versão usada para o produto inicial (Android X0). As atualizações de segurança do ASB estão disponíveis para o nível de API (a partir da data de envio), portanto, a atualização sai como X+2.y0 aproximadamente 1,25 anos após o SOP. Esta atualização do SO pode ou não ser compatível com produtos em campo. Se for, um plano pode ser criado para atualizar os veículos implantados. A menos que outros acordos comerciais estejam em vigor, a decisão de fazer uma atualização completa do SO fica inteiramente a critério do Fabricante. |
| ④ | Atualização de segurança | Dois anos após o início da vida útil de produção do veículo, o fabricante corrige o sistema operacional Android X+2. Esta decisão é baseada na avaliação de risco do Fabricante. O Fabricante escolhe a terceira atualização de segurança ASB para a versão X+2 como base da atualização. Os produtos que recebem a atualização de segurança agora estão no (X+2.y3) OS + Android Security Patch Level. Embora os fabricantes possam selecionar patches de segurança individuais de qualquer ASB individual, eles devem corrigir todos os problemas necessários no boletim para usar o nível de patch de segurança do Android (SPL) associado ao boletim (por exemplo, 2017-02-05). É responsabilidade do Fabricante executar o backport e a liberação de segurança para o produto suportado. |
| ⑤ | Atualização completa do SO | Uma repetição da etapa 3 (Atualização completa do sistema operacional), a segunda atualização completa do sistema operacional leva o produto até o Android X+4, três anos após o início da vida útil de produção do veículo. O fabricante agora está equilibrando os requisitos de hardware mais recentes de uma versão recente do Android com o hardware do produto e o usuário se beneficia de um sistema operacional Android atualizado. O fabricante lança uma atualização sem atualizações de segurança, então o produto está agora no (X+4.y0) SO + Nível de patch de segurança Android. Neste exemplo, devido a limitações de hardware, o X+4 é a última versão principal do Android que será fornecida para este produto, embora mais de 6 anos de vida útil esperada para o veículo ainda exija suporte de segurança. |
| ⑥ | Atualização de segurança | Uma repetição da etapa 4 (Atualização de segurança). O fabricante tem a tarefa de obter atualizações de segurança ASB de uma versão muito posterior do Android (X+6) e portar algumas ou todas essas atualizações de volta para o Android X+4. É responsabilidade do Fabricante mesclar, integrar e realizar as atualizações (ou contratar um terceiro). Além disso, o fabricante deve estar ciente de que os problemas de segurança em versões do Android que não são mais compatíveis não serão abordados no ASB. |
| ⑦ | Atualização de segurança | Oito anos no ciclo de vida de produção do veículo, quatro versões do Android desde a última atualização do sistema operacional na Etapa 5 (Atualização completa do sistema operacional) e dez anos desde que o Android X foi especificado, o ônus da curadoria e backport de patches de segurança é totalmente do fabricante para aquelas versões com mais de três anos do lançamento público no nível da API. |
Práticas recomendadas de segurança
Para dificultar os comprometimentos de segurança, o Google recomenda e emprega o uso de práticas recomendadas comumente aceitas para segurança e engenharia de software, conforme descrito em Implementação da segurança .
Diretrizes de segurança
As práticas recomendadas para segurança incluem:
- Use as versões mais recentes de bibliotecas externas e componentes de código aberto.
- Não inclua a funcionalidade de depuração intrusiva nas versões de lançamento do SO.
- Remova a funcionalidade não utilizada (para reduzir a superfície de ataque desnecessária).
- Use o princípio de privilégio mínimo e outras práticas recomendadas de desenvolvimento de aplicativos Android .
Diretrizes de Desenvolvimento de Software
As práticas recomendadas para o desenvolvimento de software seguro para o ciclo de vida do sistema incluem:
- Realize a modelagem de ameaças para classificar e identificar ativos, ameaças e possíveis mitigações.
- Realizar revisão de arquitetura/design para garantir um design seguro e sólido.
- Realize revisões regulares de código para identificar antipadrões e bugs o mais rápido possível.
- Projete, implemente e execute testes de unidade de alta cobertura de código, incluindo:
- Testes funcionais (incluindo casos de teste negativos)
- Testes de regressão regulares (para garantir que os bugs corrigidos não ressurjam)
- Teste fuzz (como parte do conjunto de testes unitários)
- Use ferramentas estáticas de análise de código-fonte (scan-build, lint, etc.) para identificar possíveis problemas.
- Use ferramentas dinâmicas de análise de código-fonte, como AddressSanitizer, UndefinedBehaviorSanitizer e FORTIFY_SOURCE (para componentes nativos) para identificar e mitigar possíveis problemas durante o desenvolvimento do sistema.
- Tenha uma estratégia de gerenciamento de código-fonte de software e configuração/versão de lançamento.
- Tenha uma estratégia de gerenciamento de patches para geração e implantação de patches de software.
Política de backport de segurança
Atualmente, o Google fornece suporte ativo para backports de segurança de vulnerabilidades de segurança descobertas e relatadas por três (3) anos a partir do lançamento público no nível da API . O suporte ativo consiste no seguinte:
- Receba e investigue relatórios de vulnerabilidade.
- Crie, teste e lance atualizações de segurança.
- Forneça versões recorrentes de atualizações de segurança e detalhes do boletim de segurança.
- Realize a avaliação de gravidade de acordo com as diretrizes estabelecidas.
Após três anos a partir da data de lançamento público no nível da API, o Google recomenda as seguintes diretrizes:
- Use um terceiro (como fornecedor de SoC ou provedor de Kernel) para suporte de backport para atualizações de segurança do SO com mais de três anos do lançamento da API.
- Use um terceiro para realizar revisões de código usando os ASBs fornecidos publicamente. Embora os ASBs identifiquem vulnerabilidades para a versão atualmente suportada, um Fabricante pode usar as informações fornecidas para comparar as atualizações recém-lançadas com as versões anteriores. Esses dados podem ser usados para realizar análises de impacto e potencialmente gerar patches semelhantes para versões do SO com mais de três anos do lançamento da API.
- Quando apropriado, carregue atualizações de segurança para o Android Open Source Project (AOSP).
- O fabricante deve coordenar o tratamento das atualizações de segurança para o código específico do fornecedor (por exemplo, código proprietário específico do dispositivo).
- O fabricante deve participar do grupo de notificação do NDA Android Security Bulletin Partner Preview (requer a assinatura de acordos legais, como o NDA do desenvolvedor). Os boletins devem incluir:
- Anúncios
- Resumo dos problemas por nível de patch, incluindo CVE e gravidade
- Detalhes da vulnerabilidade quando apropriado
Referências adicionais
Para obter instruções sobre práticas seguras de codificação e desenvolvimento de software, consulte o seguinte:
- Motor Industry Software Reliability Association (MISRA) .
- Ferramentas e Métodos do Instituto de Engenharia de Software (SEI) .
- Instituto Nacional de Padrões e Tecnologia (NIST).
Práticas de produto recomendadas
O Google incentiva o uso das seguintes práticas recomendadas.
Diretrizes Gerais de Lançamento
Geralmente, é recomendado que qualquer produto conectado seja lançado com a versão mais recente do sistema operacional, e um fabricante deve tentar usar a versão mais recente do sistema operacional antes de iniciar o produto. Embora o bloqueio da versão seja necessário para impulsionar a estabilidade antes do teste e da validação, o fabricante deve equilibrar a estabilidade do produto obtida com as versões mais antigas do sistema operacional com as versões mais recentes do sistema operacional que têm menos vulnerabilidades de segurança conhecidas e proteções de segurança aprimoradas.
As diretrizes recomendadas incluem:
- Devido aos longos prazos de desenvolvimento inerentes ao processo de desenvolvimento do veículo, os fabricantes podem precisar lançar com a versão do SO n-2 ou anterior.
- Mantenha a conformidade com a compatibilidade do Android para cada versão lançada do sistema operacional Android por meio de uma campanha over-the-air (OTA).
- Implemente o produto Android Firmware-over-the-air (FOTA) compatível com atualizações rápidas e fáceis de usar. O FOTA deve ser feito usando as melhores práticas de segurança, como assinatura de código e conexão TLS entre o produto e o backoffice de TI.
- Envie vulnerabilidades de segurança do Android identificadas de forma independente para a equipe de segurança do Android.
Observação: o Google contemplou o tipo de dispositivo ou notificações específicas do setor nos boletins de segurança do Android. No entanto, como o Google não conhece o kernel, drivers ou chipsets de um determinado dispositivo (veículo, TV, wearable, telefone etc.), o Google não tem uma maneira determinística de rotular qualquer problema de segurança com um tipo de dispositivo.
Diretrizes do Ciclo do Produto
O Fabricante deve fazer todas as tentativas para usar a versão mais recente do SO ou atualizações de segurança para a versão em uso durante os aprimoramentos do ciclo do produto. As atualizações podem ser realizadas durante atualizações periódicas recorrentes do produto ou para hotfixes para resolver problemas de qualidade e/ou outros. As práticas recomendadas incluem:
- Crie um plano para endereçar atualizações de driver, kernel e protocolo.
- Utilize um método apropriado do setor para fornecer atualizações para veículos implantados.
Documento de Definição de Compatibilidade (CDD)
O Documento de Definição de Compatibilidade (CDD) descreve os requisitos para que um dispositivo seja considerado compatível com Android. O CDD é público e disponível para todos; você pode baixar as versões CDD do Android 1.6 para a versão mais recente em source.android.com .
Satisfazer esses requisitos para um produto envolve as seguintes etapas básicas:
- O parceiro assina o Compromisso de Compatibilidade do Android (ACC) com o Google. Um Consultor de Soluções Técnicas (TSC) é então designado como um guia.
- O parceiro conclui a análise do CDD para a versão do sistema operacional Android do produto.
- O parceiro executa e envia os resultados do CTS (descritos abaixo) até que os resultados sejam aceitáveis para compatibilidade com Android.
Conjunto de testes de compatibilidade (CTS)
A ferramenta de teste Compatibility Test Suite (CTS) verifica se a implementação de um produto é compatível com Android e se os patches de segurança mais recentes estão incluídos. O CTS é público, de código aberto e disponível para todos; você pode baixar as versões CTS do Android 1.6 para a versão mais recente em source.android.com .
Cada versão do software Android lançada ao público (imagens de instalação de fábrica e de atualização de campo) deve comprovar a compatibilidade do Android por meio dos resultados do CTS. Por exemplo, se o dispositivo executa o Android 7.1, a versão correspondente mais recente do CDD 7.1 e CTS 7.1 deve ser referenciada quando uma imagem de compilação de intenção de lançamento é criada e testada. Os fabricantes são fortemente encorajados a usar o CTS com antecedência e frequência para identificar e corrigir problemas.
Fluxo de trabalho CTS
O fluxo de trabalho do CTS envolve configurar o ambiente de teste, executar testes, interpretar resultados e entender o código-fonte do CTS. As diretrizes a seguir destinam-se a ajudar os usuários do CTS (por exemplo, desenvolvedores, fabricantes) a usar o CTS de maneira eficaz e eficiente.
- Execute testes com freqüência . O CTS foi projetado como uma ferramenta automatizada que se integra ao seu sistema de compilação. A execução frequente do CTS pode ajudá-lo a encontrar defeitos de forma rápida e precoce quando ocorrem degradação ou regressões do software.
- Baixe e examine o código fonte do CTS . O código-fonte completo do CTS é um software de código aberto que qualquer pessoa pode baixar e usar (o código-fonte baixado é totalmente edificável e executável). Quando um teste falha no dispositivo, examinar a seção relevante do código-fonte pode ajudá-lo a identificar o motivo.
- Obtenha o CTS mais recente . Novas versões do Android podem atualizar o CTS com correções de bugs, melhorias e novos testes. Verifique os Downloads CTS com frequência e atualize seu programa CTS conforme necessário. O fabricante e o Google devem concordar com a versão do CTS a ser aprovada para o lançamento do produto, pois o produto deve ser congelado em algum momento enquanto o CTS continua a ser atualizado.
Passando no CTS
Para um produto compatível com Android, o Google garante que o CTS do dispositivo e os resultados do teste de relatórios do CTS Verifier sejam aceitáveis. Em princípio, todos os testes devem passar. No entanto, um teste que falhe por outros motivos além do dispositivo não estar em conformidade com os requisitos de compatibilidade do Android está sujeito à análise do Google. Durante este processo:
- O fabricante fornece ao Google os patches CTS propostos, validações de patches e justificativas para provar o argumento.
- O Google examina o material enviado e, se aceito, atualiza os testes CTS relevantes para que o dispositivo passe na próxima revisão do CTS.
Se um teste CTS falhar repentinamente após a aplicação de um patch de segurança, o fabricante deve modificar o patch para que não interrompa a compatibilidade OU mostrar que o teste está errado e fornecer uma correção para o teste (conforme descrito acima).
O CTS permanece aberto para revisões de correções de teste. Por exemplo, o Android 4.4 continua aceitando correções (consulte https://android-review.googlesource.com/#/c/273371/ ).
Perguntas frequentes (FAQ)
P: Quem é responsável por aplicar atualizações de segurança a uma implementação específica do Android?
R: O Fabricante que fornece diretamente o dispositivo é responsável. Essa entidade não é o Google, que publica atualizações de segurança no AOSP e não para um dispositivo específico (como um veículo).
P: Como o Google lida com problemas de segurança no Android?
R: O Google investiga continuamente os problemas e desenvolve possíveis correções, que o Google disponibiliza para todos os níveis de API compatíveis como parte do processo regular de atualização de segurança. Desde agosto de 2015, o Google mantém uma cadência regular de publicação de boletins e links para atualizações em source.android.com ; O Google também publica atualizações de segurança como parte dos principais lançamentos do sistema operacional. Consulte também a política de backport de segurança .
P: Se um fabricante integrou todos os patches AOSP de um ASB, mas não integrou patches do fornecedor BSP mencionado no mesmo boletim, ele ainda pode aumentar o nível de segurança (por exemplo, aplicar o patch correspondente à plataforma/compilação) ?
R: Para declarar um nível de patch de segurança do Android (SPL), um fabricante deve resolver todos os problemas obrigatórios publicados no Boletim de segurança do Android ( incluindo boletins anteriores ) e mapeados para uma SPL específica do Android. Por exemplo, um fabricante que usa o Boletim de segurança de março de 2017 (2017-03-01 SPL) abordou todos os problemas necessários documentados no boletim de março de 2017 para esse SPL e todas as atualizações anteriores, incluindo atualizações específicas do dispositivo para todos os boletins de segurança do Android anteriores, incluindo as atualizações específicas do dispositivo associadas à SPL 2017-02-05.
P: O que acontece quando o fabricante não concorda com as atualizações de segurança fornecidas pelo fornecedor BSP OU quando as atualizações de segurança exigidas por um ASB não são fornecidas pelos fornecedores?
R: Um ASB descreve vulnerabilidades de segurança (enumeradas por uma lista de CVEs) e geralmente fornece testes de segurança correspondentes. O objetivo é garantir que as vulnerabilidades listadas não possam mais ser reproduzidas em um dispositivo e que o dispositivo possa passar nos testes de segurança associados. Dessa forma, a questão não é obter uma atualização de segurança fornecida pelo Google ou um fornecedor terceirizado, mas sim o Fabricante atestar que o dispositivo não é vulnerável à lista de CVEs no ASB. O Fabricante é livre para usar as atualizações de segurança fornecidas ou, se tiver uma alteração mais apropriada para seu dispositivo, use essa alteração.
Por exemplo, considere um caso em que o Google aborda uma vulnerabilidade de segurança AOSP usando uma alteração de código que permite que o componente permaneça totalmente funcional e em conformidade com o CDD. Se o fabricante determinar que o componente não é necessário no dispositivo ou não é obrigatório pelo CDD (ou teste de certificação relacionado), o fabricante pode remover o componente para reduzir as necessidades futuras de manutenção e reduzir a superfície de ataque. Embora o fabricante não tenha usado a atualização de segurança fornecida, ele garantiu que o dispositivo não seja vulnerável ao CVE documentado no boletim de segurança. No entanto, ao desviar-se da atualização de segurança recomendada, o fabricante corre o risco de resolver o problema incorretamente, introduzindo novas vulnerabilidades de segurança ou reduzindo a funcionalidade da versão final.
Embora trabalhemos com todos os parceiros de SoC para garantir que existam correções para todos os problemas em um ASB, recomendamos que os fabricantes garantam um contrato de manutenção com seus fornecedores de SoC para o ciclo de vida de um dispositivo. Os SoCs podem parar de atender um chipset antes do desejado, portanto, estabelecer acordos antes da seleção do chipset do dispositivo é uma parte importante do processo de inicialização do dispositivo.
Por fim, nos casos em que é impossível adquirir diretamente ou criar independentemente uma correção para um problema documentado em um ASB, um fabricante pode manter a SPL anterior do Android e ainda adicionar as novas correções disponíveis à compilação. No entanto, essa prática acabará levando a problemas com a certificação de compilação (já que o Android garante que o nível de patch de segurança mais recente esteja disponível em dispositivos certificados). O Google recomenda trabalhar com seu SoC com antecedência para evitar essa prática.
P: Se o fabricante determinar que um item ASB não é aplicável ao produto, o item ainda precisa ser aplicado ou corrigido para atender aos outros requisitos do Google ou para ser aprovado no CTS?
R: Não exigimos que sejam feitos patches para declarar um nível de patch de segurança do Android (SPL); exigimos que o Fabricante ateste que sua construção não é vulnerável ao problema.
Um exemplo é quando um componente que está sendo corrigido não existe no sistema do Fabricante ou um componente é removido do sistema do Fabricante para resolver um problema. Nesse caso, o sistema pode estar em conformidade sem exigir que o fabricante faça um patch.
Isso é fundamentalmente diferente de um fabricante que deseja, por exemplo, corrigir apenas patches críticos, sem usar outros patches aplicáveis que causariam a falha de um teste de segurança. Nesse caso, assume-se que o SPL não foi atendido.