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
Atualizado

Nota de atualização (23 out 2026). Corrigimos a regra de disponibilidade das atualizações de segurança, cujos dez anos se contam a partir da emissão de cada uma, acrescentámos a data a partir da qual o artigo 13.º se aplica e o exemplo dos runtimes corrigidos em outubro de 2026, e passámos a citar as orientações da Comissão de 27 jul 2026, publicadas depois da primeira versão deste texto.

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. No texto oficial português, o termo é «período de apoio» (art. 3.º, ponto 20, e art. 13.º, n.º 8); aqui usamos o termo mais corrente.

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. As orientações da Comissão de 27 jul 2026, C(2026) 5252, lembram que os cinco anos são uma salvaguarda mínima: um produto que se espera usar durante mais tempo deve ter um período de suporte mais longo.

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 emissão de cada uma, ou durante o resto do período de suporte, consoante o que for mais longo. A contagem faz-se por atualização: uma correção emitida no quarto ano fica disponível, pelo menos, até ao décimo quarto. 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 após a colocação no mercado ou durante 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 logo no primeiro mês do projeto:

  • 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 fica sem caminho técnico de correção para os anos que faltam. 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; uma atualização emitida no quarto ano fica disponível dez anos a partir da emissão, até ao décimo quarto; um SoC com fim de vida aos três anos fura o compromisso, um OS embebido com quatro também.
Cada barra que acaba antes dos cinco anos é uma lacuna a fechar componente a componente: substituição planeada, suporte alargado contratado ao fornecedor ou mitigação própria documentada.

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.

Uma ressalva de calendário: o artigo 13.º, incluindo o período de suporte, só se aplica a partir de 11 de dezembro de 2027. Os produtos colocados no mercado antes dessa data só ficam sujeitos se sofrerem uma modificação substancial depois dela (art. 69.º, n.º 2). Mas a colocação no mercado conta-se unidade a unidade: as unidades de um modelo atual colocadas no mercado a partir de 11 de dezembro de 2027 têm de cumprir, com período de suporte declarado. O reporte do artigo 14.º, esse, aplica-se desde 11 de setembro de 2026 a todos os produtos, incluindo os já colocados no mercado (art. 69.º, n.º 3), e continua depois de o período de suporte terminar.

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

Os runtimes e as bibliotecas de software também são componentes da SBOM, com fim de vida tão concreto como o de um SoC, e as correções de 21 out 2026 ao PHP e ao Node.js mostraram-no bem. O PHP 8.1, fora de suporte desde 31 dez 2025, não teve versão corrigida, apenas backports mínimos em código-fonte, sem número de versão novo. O Node 20, fora de suporte desde 30 abr 2026, ficou sem correção. O PHP 8.2 recebeu-a, mas o projeto deixa de o suportar a 31 dez 2026. Nenhuma linha destes dois runtimes tem cinco anos de suporte do projeto, por isso cumprir o período declarado obriga a uma das três vias: migrações de versão major planeadas de antemão, suporte alargado contratado a uma distribuição ou a um fornecedor LTS, ou correções próprias, que o art. 13.º, n.º 6, manda partilhar com quem mantém o componente. O caso está desenvolvido no artigo 09. O kernel Linux e o Python têm também fins de vida marcados por ramo, tratados no artigo 10.

Fontes