Anexo · Aerodry contra o Anexo I do CRA, requisito a requisito

Este é o relatório que serve de base à entrada 002. É o formato que entregamos a clientes: cada requisito essencial do Anexo I, o estado no protótipo, a evidência concreta que sustenta esse estado, e a natureza da correção. A última coluna costuma ser a que surpreende, porque mostra quantos requisitos não se resolvem mexendo no código.

Estado: ✗ não cumpre · ◑ cumpre em parte · ✓ cumpre · N/A não se aplica.

Parte I, propriedades de segurança do produto

#	Requisito (Anexo I, Parte I)	Estado	Evidência no protótipo	Natureza da correção
1	Sem vulnerabilidades exploráveis conhecidas ao ser colocado no mercado	◑	Dependências congeladas, sem processo de triagem de CVE	Processo e SBOM
2	Configuração segura por definição	✗	Palavra-passe de acesso fixa e partilhada; serviços em claro por definição	Firmware e fabrico
3	Correção de vulnerabilidades por atualização	◑	Mecanismo OTA existe, mas sem canal seguro	Firmware e infraestrutura
4	Proteção contra acessos não autorizados	✗	Endereço de atualização e servidor sem autenticação	Firmware e infraestrutura
5	Confidencialidade dos dados, incluindo cifra em repouso e em trânsito	✗	HTTP em claro; Wi-Fi da casa guardado sem cifra	Firmware
6	Integridade de dados, comandos, configuração e firmware	✗	Firmware sem assinatura; comandos sem verificação	Firmware e infraestrutura
7	Recolher apenas os dados necessários	✓	Só temperatura, humidade e estado do relé	Manter no desenho
8	Disponibilidade das funções essenciais	◑	Cortes de segurança existem; sem proteção de rede contra negação de serviço	Firmware
9	Não prejudicar outros aparelhos nem a rede	✓	Superfície reduzida, sem efeito de amplificação	Manter no desenho
10	Minimizar a superfície de ataque	◑	Poucos serviços, mas o OTA em HTTP está sempre ativo	Firmware
11	Reduzir o impacto de um incidente	✗	Sem separação entre a função de controlo e a interface de rede	Firmware
12	Registar a atividade relevante para a segurança	✗	Há registos operacionais, mas não de eventos de segurança	Firmware
13	Permitir apagar dados e definições no fim de vida	✗	Sem reposição segura; as credenciais persistem na revenda	Firmware e documentação

Parte II, tratamento de vulnerabilidades

#	Requisito (Anexo I, Parte II)	Estado	Evidência no protótipo	Natureza da correção
1	Inventário de componentes (SBOM legível por máquina)	✗	Dependências copiadas para o repositório, sem SBOM	Documentação e build
2	Corrigir vulnerabilidades sem demora	◑	O mecanismo existe; o processo de resposta não	Firmware e processo
3	Testes de segurança regulares	✗	Sem ciclo de teste definido	Processo
4	Divulgar as vulnerabilidades corrigidas	✗	Sem canal nem histórico de segurança do produto	Processo e organização
5	Política de divulgação coordenada	◑	O security.txt do site é um embrião; falta PGP e política do produto	Organização
6	Facilitar o reporte de vulnerabilidades	◑	Há contacto genérico; falta contacto de segurança dedicado	Organização
7	Distribuir atualizações de forma segura	✗	OTA sem assinatura e sem canal cifrado	Firmware e infraestrutura
8	Atualizações de segurança disponíveis sem demora e gratuitas	◑	Tecnicamente possível; sem período de suporte assumido	Processo e infraestrutura

Contagem

São 21 requisitos aplicáveis, 13 na Parte I e 8 na Parte II. Cumprem-se 2, cumprem-se em parte 8, e falham 11.

A entrada 002 descreve nove falhas: são as que têm consequência direta para quem usa o produto, e repartem-se pelas duas partes. Este anexo mostra o quadro completo, incluindo o que a entrada não desenvolve, como as lacunas de processo da Parte II, menos visíveis mas igualmente exigidas.

A leitura por natureza da correção

Se olharmos para as correções pela sua natureza, em vez de requisito a requisito, o firmware aparece em cerca de onze requisitos, mas quase nunca sozinho. A infraestrutura aparece em cerca de seis, o processo em cerca de sete, a documentação em cerca de quatro, e a organização em cerca de quatro. O fabrico aparece só num, o da palavra-passe por unidade, mas é de correção obrigatória e não se resolve em código.

A soma passa dos 21 porque a maioria dos requisitos precisa de mais do que uma natureza de correção ao mesmo tempo. É essa sobreposição que torna a sequência do trabalho, o tema da entrada 003, o verdadeiro valor do serviço, e não a lista em si.