Saltar para o conteúdo
folhas.io
secure by design para produtos ligados· Artigos

Artigos

Período de suporte: a promessa mais cara que o CRA obriga a fazer

O CRA obriga cada fabricante a declarar por quanto tempo suporta o produto: no mínimo, em regra, cinco anos. É uma decisão de engenharia, de contratos e de fornecedores disfarçada de campo num formulário.

Publicado

De todos os requisitos do CRA, o período de suporte é o que parece mais administrativo e é o que mais compromete. O artigo 13.º obriga o fabricante a determinar um período durante o qual assegura a gestão eficaz de vulnerabilidades do produto, e a declará-lo, porque o utilizador tem de saber, no momento da compra, até quando pode contar com atualizações de segurança.

A regra

O período de suporte reflete o tempo de utilização expectável do produto, e não pode ser inferior a cinco anos, salvo se o produto se destinar a ser usado por menos tempo, caso em que cobre esse tempo de utilização. Na determinação entram, entre outros fatores, a expectativa razoável do utilizador, a natureza do produto e o período de suporte de produtos comparáveis no mercado. A data de fim de suporte indica-se de forma clara, incluindo, no mínimo, mês e ano.

Duas obrigações acessórias que passam despercebidas:

  • As atualizações de segurança disponibilizadas durante o suporte devem permanecer disponíveis durante pelo menos dez anos após a colocação do produto no mercado, ou durante o resto do período de suporte, consoante o que for mais longo. Um patch publicado não pode desaparecer do servidor dois anos depois.
  • A documentação técnica, incluindo a fundamentação da duração escolhida, conserva-se por, no mínimo, dez anos ou o período de suporte, o que for mais longo, e as autoridades de fiscalização podem pedir os dados que fundamentaram a decisão.

Porque é que isto é uma decisão de engenharia

Prometer cinco anos de gestão de vulnerabilidades não é prometer boa vontade; é prometer que, daqui a cinco anos, ainda existe um caminho técnico para corrigir e entregar. Isso puxa por decisões que se tomam no primeiro mês do projeto, não no último:

  • Alinhamento com os fornecedores. Se o SoC escolhido tem fim de vida anunciado para daqui a três anos, ou o BSP do fornecedor deixa de receber patches, a promessa de cinco anos assenta em areia. O período de suporte do produto tem de ser reconciliado com o ciclo de vida de cada componente crítico da SBOM e, nos contratos de fornecimento, com cláusulas de suporte correspondentes.
  • Capacidade de atualização durável. O mecanismo de atualização (OTA ou local) tem de continuar a funcionar durante todo o período: chaves de assinatura geridas e rotáveis, espaço de flash reservado para imagens futuras maiores, infraestrutura de distribuição orçamentada como custo recorrente.
  • Compatibilidade de build a cinco anos. Reconstruir o firmware em 2031 com a toolchain de 2026 exige builds reprodutíveis e ambientes arquivados. Sem isso, o primeiro CVE sério num componente antigo transforma-se num projeto de arqueologia.
Gráfico de barras temporais: o compromisso CRA do produto dura pelo menos cinco anos e as atualizações publicadas ficam disponíveis dez; um SoC com fim de vida aos três anos fura o compromisso, um OS embebido com quatro também.
A promessa e o que a sustém: qualquer componente que morra antes do compromisso transforma a promessa em areia.

E uma decisão de contratos

O período declarado entra na informação ao utilizador e, na prática, nos contratos com clientes B2B, que frequentemente pedirão mais do que o mínimo. Vale a pena separar duas coisas que os contratos tendem a fundir: o período de suporte CRA (gestão de vulnerabilidades e atualizações de segurança, obrigação legal) e o suporte comercial (novas funcionalidades, SLA, assistência), que é negociável. Vender a distinção ao cliente evita que uma obrigação legal de cinco anos se transforme, por arrasto contratual, numa promessa de roadmap de cinco anos.

O que isto significa para quem fabrica

No nosso próprio produto, a decisão que tomámos foi tratar o período de suporte como restrição de design de primeira ordem, ao nível do custo unitário: nenhum componente entra na BOM sem data de fim de vida conhecida e compatível com o período-alvo, e o orçamento do produto inclui o custo anual da infraestrutura de atualização durante todo o período. É mais fácil desenhar para cinco anos do que remendar para eles.

Para quem já tem produto no mercado, o exercício inverso: listar os componentes cujo fim de vida cai dentro do período de suporte declarado e decidir, para cada um, entre substituição planeada, suporte alargado contratado ao fornecedor, ou mitigação própria documentada.

Fontes