Saltar para o conteúdo
folhas.io
secure by design para produtos ligados· Diário de bordo

Diário de bordo· entrada 003

003 · Do protótipo ao produto: o plano, a sequência e o que custa

A auditoria da entrada 002 transformada em plano de trabalho. Quatro fases, o que entra em cada uma, e onde é que o dinheiro se gasta. Boa parte não é código.

Publicado
Atualizado

Nota de atualização (23 out 2026). Corrigimos a frase sobre quem lê a documentação técnica: num produto da categoria por omissão, como o Aerodry na nossa classificação de trabalho, a avaliação pode fazer-se por controlo interno, sem organismo notificado, e quem pode pedir a documentação é a autoridade de fiscalização do mercado.

A entrada 002 acabou com uma lista de falhas e uma promessa: transformá-la num plano. Esta é a parte que os fabricantes raramente veem antes de nos contratarem, porque de costume só existe depois de assinado o contrato. Publicamo-la porque é o trabalho que vendemos, e mostrar como pensamos é a melhor forma de o descrever.

A ordem vale mais do que a lista

A lista de requisitos do CRA está no regulamento, e qualquer pessoa a consegue copiar. O que distingue o trabalho é a sequência: decidir o que tem de ficar resolvido primeiro para que o resto não tenha de ser refeito. Fazer as coisas fora de ordem costuma custar o dobro, porque se acaba a repetir trabalho já feito.

Um exemplo concreto do Aerodry. Não vale a pena montar o TLS na comunicação antes de decidir como é que os aparelhos têm identidade, porque é a identidade que determina como se emitem e se renovam os certificados. E não vale a pena desenhar a identidade antes de decidir se o primeiro arranque gera um segredo próprio para cada unidade, porque é aí que a identidade de cada aparelho nasce. São três das falhas da entrada 002 e, feitas por esta ordem, formam um só trabalho encadeado; noutra ordem, cada uma obriga a refazer parte das outras.

As quatro fases

Fase 0, o enquadramento. Antes de tocar em código, é preciso decidir e escrever a classificação do produto no CRA, fixar o que o produto faz e sobretudo o que não faz (porque uma função nova pode mudar a categoria de risco), e definir o período de suporte como uma restrição que condiciona o desenho. Sem isto, todas as decisões técnicas que vêm a seguir ficam sem critério para se avaliarem. É a fase mais barata de todas e a que mais poupa adiante.

Fase 1, as fundações de segurança. A identidade dos aparelhos e a autoridade de chaves que a sustenta, o primeiro arranque com segredo próprio por unidade, o arranque verificado. É tudo aquilo que a fase seguinte vai assumir como já resolvido. É a fase que o cliente menos vê e a que carrega o maior risco técnico, e é por isso que vem cedo, quando ainda é barato enganar-se e corrigir.

Fase 2, a superfície e os dados. A atualização OTA assinada e verificada, a comunicação cifrada e autenticada, o registo de eventos de segurança, a eliminação de dados no fim de vida. São as correções diretas da lista da entrada 002. Só aparecem agora porque cada uma delas depende de uma decisão tomada na Fase 1.

Fase 3, o processo e a prova. A SBOM gerada no build e arquivada com cada versão, a documentação técnica do Anexo VII, a política de divulgação de vulnerabilidades com canal e chave PGP públicos, o processo de resposta já ensaiado, e a avaliação de conformidade com a declaração que a acompanha. O objetivo desta fase é tornar demonstrável que o produto cumpre. E sem ela um produto pode estar seguro e mesmo assim não poder ser vendido, porque falta a prova.

As quatro fases em sequência (enquadramento, fundações, superfície e dados, processo e prova) e, por baixo, uma barra de esforço dividida ao meio: metade código, metade fabrico, infraestrutura, documentação e organização.
A sequência e o esforço: cada fase assume as decisões da anterior, e cerca de metade do trabalho não é firmware.

Onde é que o dinheiro se gasta

Vale a pena insistir na descoberta da auditoria, porque é contra a intuição de quase toda a gente: boa parte do esforço não é firmware.

A palavra-passe única por unidade não se resolve numa linha de código, resolve-se na linha de montagem, com geração e impressão de segredos. É logística de produção. A autoridade de chaves que assina o firmware tem de existir e de ser mantida durante todo o período de suporte, e o mais difícil é mantê-la a funcionar cinco anos seguidos. A documentação, que inclui a SBOM, o processo técnico e as instruções de segurança para o utilizador, é trabalho a sério, e é precisamente o que sustenta a nossa declaração de conformidade e o que a autoridade de fiscalização do mercado nos poderá pedir durante pelo menos dez anos. E o canal de divulgação e o processo de resposta são pessoas e procedimentos, que têm de estar montados antes de aparecer a primeira vulnerabilidade.

Só a outra metade é aquilo que a maioria das pessoas imagina quando ouve “conformidade de cibersegurança”, que é mexer no código.

O que isto significa para quem nos lê

Se está a construir um produto ligado para o mercado europeu, a lição prática da nossa própria experiência é esta: a conformidade sai barata quando começa na Fase 0. Uma fase que se salta acaba por ser feita mais tarde, com custo maior, num produto já desenhado que ninguém quer voltar a abrir. A Fase 0 do Aerodry devia ter sido feita antes do primeiro protótipo. Não foi, e estamos a fazê-la agora.

A entrada 004 desce à primeira decisão técnica a sério: como fazer a atualização OTA de forma segura quando a ligação à internet é rural e intermitente, que é o nosso caso. Foi uma das três perguntas que a entrada 001 admitiu não saber responder. Vamos tentar responder.


Este plano é a versão pública e genérica do que fazemos por produto. A sequência concreta, as estimativas de esforço e a análise requisito a requisito dependem sempre do produto específico.