Edição de 18/09: prometer suporte exige uma cadeia de manutenção

Preparação, não obrigação antecipada

Esta edição recuperada pergunta se o responsável de produto consegue sustentar a promessa de manutenção com uma cadeia executável. Destina-se a fabricantes, engenharia e compras técnicas. É análise de preparação publicada em outubro: não anuncia uma nova obrigação de suporte surgida em 18 de setembro.

O artigo 71.º distingue a aplicação geral, em 11 de dezembro de 2027, da aplicação do artigo 14.º, em 11 de setembro de 2026. Os requisitos de suporte aqui tratados não devem ser apresentados como um mandato geral já aplicável em setembro. A antecipação proposta pela Velqory é uma decisão operacional, não uma mudança da data legal.

Suporte e disponibilidade não são o mesmo relógio

O artigo 13.º relaciona o período de suporte com a utilização esperada; estabelece pelo menos cinco anos, salvo quando essa utilização é inferior, caso em que o período corresponde à utilização esperada. O mesmo artigo determina que atualizações de segurança emitidas durante o suporte permaneçam disponíveis pelo menos dez anos após emissão ou pelo período de suporte restante, consoante o mais longo.

Proposta Velqory: manter dois campos independentes na ficha da versão. O primeiro explica até quando existe manutenção de segurança; o segundo acompanha a disponibilidade de cada atualização emitida. Um pacote conservado num arquivo não demonstra, só por existir, que continuarão a ser produzidas correções.

A dependência pode interromper a promessa

O anexo I, parte II, inclui identificação e documentação de vulnerabilidades e componentes, com SBOM legível por máquina que cubra pelo menos dependências de nível superior. Não converta este mínimo numa alegação de que o texto exige enumerar todas as transitivas. O artigo 13.º também prevê diligência sobre componentes de terceiros.

O NCSC recomenda identificar produtos obsoletos e conhecer versões e responsáveis. Como adaptação proposta, peça ao mantenedor de cada componente a política de versões, canal de avisos e alternativa se o suporte terminar antes do produto. Não presuma que uma licença aberta garante disponibilidade de uma equipa para corrigir.

Um ensaio de mesa para a versão vendida

A matriz é original, não testada e não certifica conformidade. O ensaio proposto usa uma versão hipotética ainda distribuída, com uma dependência cujo mantenedor anuncia fim de suporte. Compras não aceita a continuidade apenas por receber uma declaração comercial; engenharia deve mostrar que resposta consegue preparar.

O canal corrige apenas a versão nova

Cenário hipotético: a equipa prepara uma atualização para a versão mais recente, mas os clientes de uma versão anterior continuam dentro do período declarado. O exercício deve perguntar quem conhece esses destinatários e qual o percurso compatível de atualização. Não é necessário inventar uma CVE para revelar a lacuna de distribuição.

A Velqory propõe guardar uma demonstração controlada de seleção da versão destinatária, validação do pacote e comunicação de incompatibilidades. Se a resposta for «o cliente devia ter migrado», peça o fundamento da promessa original antes de encerrar. Uma correção criada e uma correção utilizável são resultados distintos.

Transformar a promessa numa decisão de produto

A página de orientação da Comissão identifica períodos de suporte e avaliação de risco entre os temas de preparação e salienta o caráter não vinculativo. A obrigação vem do regulamento; a matriz e o ensaio deste artigo são propostas da Velqory, sem resultados demonstrados.

A saída útil é decidir se a promessa é sustentável, precisa de recursos ou exige revisão da estratégia comercial com análise jurídica. Guarde limites, dependências e condições de reavaliação. Evite vender um período apenas porque o número parece simples: o compromisso precisa de alguém que consiga receber, preparar e entregar uma resposta de segurança.