Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- O artigo 21 da NIS2 estabelece a segurança da cadeia de suprimentos como uma medida mínima e exige que as entidades avaliem as vulnerabilidades de cada fornecedor direto.
- A ENISA, agência de segurança cibernética da União Europeia, afirma em suas diretrizes não vinculativas para compras hospitalares que os mantenedores de software de código aberto podem não ser considerados fornecedores diretos.
- O código-fonte aberto adicionado pelo desenvolvedor pode não ter um fornecedor a quem recorrer, portanto, cabe à sua equipe verificar se está tudo em ordem.
- Os órgãos de gestão aprovam as medidas previstas no Artigo 21 e podem ser responsabilizados; portanto, verifique se essas medidas abrangem o código-fonte aberto adicionado pelos desenvolvedores.
Um cadastro de fornecedores elaborado com base em contratos pode parecer completo e, mesmo assim, deixar de incluir o código-fonte aberto presente em seu software. A medida de segurança da cadeia de suprimentos prevista na segunda Diretiva sobre Segurança de Redes e Informações (NIS2) destaca seus fornecedores diretos. O código-fonte aberto adicionado por seus próprios desenvolvedores, no entanto, pode não ter um fornecedor específico ao qual enviar um questionário.
Então, quem é considerado seu fornecedor quando o código é de código aberto? A resposta determina quais perguntas você pode fazer a um fornecedor e quais verificações devem ficar a cargo da sua equipe.
Seja qual for a resposta, comprar de um fornecedor não transfere suas obrigações previstas na NIS2 para esse fornecedor. A diretiva exige que as organizações abrangidas gerenciem o risco de fornecedores por meio de suas próprias medidas, e a Agência da União Europeia para a Cibersegurança (ENISA) afirma, em suas Orientações Técnicas de Implementação não vinculativas, que terceirizar um risco não isenta você de sua responsabilidade por ele.
O que a medida de segurança da cadeia de suprimentos da NIS2 exige de você
A medida se aplica a entidades essenciais e importantes — as duas categorias definidas pela NIS2 — com base na criticidade de um setor ou serviço e no porte da organização. Na prática, isso geralmente significa organizações de médio e grande porte nos setores listados, além de algumas menores; portanto, nem todas as empresas estão abrangidas.
O Artigo 21, parágrafo 2, enumera dez medidas que uma entidade deve adotar, no mínimo. A medida prevista na alínea (d) é a segurança da cadeia de suprimentos. Ela abrange o aspecto de segurança das relações de cada entidade com seus fornecedores diretos ou prestadores de serviços. O Artigo 21, parágrafo 3, especifica então o que deve ser levado em consideração para essa medida: as vulnerabilidades específicas de cada fornecedor direto e prestador de serviços; a qualidade geral dos produtos e as práticas de segurança cibernética dos fornecedores, incluindo seus procedimentos de desenvolvimento seguro; e os resultados de quaisquer avaliações de risco coordenadas em nível da União relativas a cadeias de suprimentos críticas.
Esses são os requisitos de segurança da cadeia de suprimentos estabelecidos na diretiva. Uma diretiva vincula os Estados-Membros, e não as empresas; portanto, essas regras se aplicam às entidades por meio da legislação nacional de cada país. O Artigo 21, parágrafo 1, também exige medidas que sejam adequadas e proporcionais aos riscos, o que deixa parte da definição a cargo de vocês.
Um considerando da NIS2 e vários outros textos da UE também mencionam os fornecedores. O único documento vinculativo é um regulamento adotado pela Comissão Europeia, uma vez que a NIS2 assim o exigia: o Regulamento de Execução (UE) 2024/2690. Ele estabelece regras detalhadas relativas ao Artigo 21, incluindo uma política de fornecedores, para determinados provedores digitais, como provedores de serviços em nuvem e de serviços gerenciados.
| Documento | O que está escrito sobre os fornecedores | A quem se destina | Vinculativo? | Base |
|---|---|---|---|---|
| NIS2 (Diretiva (UE) 2022/2555), Artigo 21, parágrafo 2, alínea d), e parágrafo 3 | Segurança da cadeia de suprimentos, incluindo as relações com fornecedores diretos; vulnerabilidades dos fornecedores diretos; qualidade dos produtos dos fornecedores, práticas de segurança cibernética e procedimentos de desenvolvimento seguro | Entidades essenciais e importantes | Sim, por meio da legislação nacional | diretiva da UE |
| NIS2, considerando 85 | Indica empresas de software; incentiva a inclusão de cláusulas contratuais com fornecedores diretos; outros níveis de fornecedores poderiam ser considerados | Entidades essenciais e importantes | Não | Considerando, um auxílio à interpretação |
| Regulamento de Execução (UE) 2024/2690 da Comissão, de 17 de outubro de 2024 | Política de segurança da cadeia de suprimentos para fornecedores diretos, com critérios de seleção | Tipos de entidades digitais listadas, como provedores de serviços em nuvem e de serviços gerenciados | Sim, para esses tipos | Ato de execução |
| Orientação Técnica de Implementação da ENISA, versão 1.0, junho de 2025 | Orientações práticas e exemplos de comprovação para o Regulamento de Execução | Tipos de entidades digitais listados; podem servir de referência para outros | Não | Orientações da ENISA |
| Caixa de Ferramentas da UE para a Segurança da Cadeia de Suprimentos de TIC, fevereiro de 2026 | Abordagem comum para avaliar e mitigar os riscos da cadeia de suprimentos de TIC | Estados-Membros e atores públicos e privados | Não, voluntário | Orientações do Grupo de Cooperação do NIS |
Os mantenedores de código aberto podem não ser considerados fornecedores diretos
O considerando 85 da NIS2 cita os editores de software entre os fornecedores cujos riscos são relevantes e considera que as entidades poderiam levar em conta outros fornecedores além dos diretos. No entanto, os considerandos, por si só, não criam obrigações, e as relações com fornecedores mencionadas no artigo 21º referem-se às relações com fornecedores diretos.
As diretrizes de compras da ENISA, de julho de 2026, relativas à segurança cibernética de hospitais e prestadores de serviços de saúde, abordam a questão de saber se um mantenedor de código aberto é considerado um fornecedor direto, pelo menos no setor da saúde.
Segundo a ENISA: “No caso do software livre e de código aberto (OSS), as entidades que mantêm e distribuem o software abertamente podem não ser consideradas prestadoras diretas de serviços.”
Isso se aplica, acrescentam as diretrizes, quando não há relação contratual com o projeto além de uma licença padrão de direitos autorais, ou quando o contrato é com um administrador de software de código aberto. Esse termo é definido em uma lei diferente, a Lei de Resiliência Cibernética, e significa uma pessoa jurídica, que não seja um fabricante, que apoia o desenvolvimento de determinados produtos de código aberto de forma contínua.
As diretrizes não são vinculativas e foram elaboradas para compras no setor da saúde; portanto, não determinam como uma autoridade nacional deve interpretar o Artigo 21. Elas estão em consonância com o texto da Diretiva, que em nenhum momento exige expressamente que uma entidade avalie os mantenedores de um projeto de código aberto. O risco inerente ao próprio código ainda se enquadra nas medidas previstas no Artigo 21, embora não necessariamente na medida de segurança da cadeia de suprimentos.
Um fornecedor pode incluir código aberto em um produto, um prestador de serviços pode fornecê-lo como parte de um serviço, ou seus próprios desenvolvedores podem adicioná-lo ao software que vocês criam. O fornecedor ou prestador de serviços é normalmente seu fornecedor direto; portanto, os fatores previstos no Artigo 21(3), incluindo o desenvolvimento seguro, se aplicam a ele. Quando seus próprios desenvolvedores adicionam código aberto, pode não haver um fornecedor no sentido contratual. O Artigo 21, parágrafo 2, alínea e), sobre segurança na aquisição, desenvolvimento e manutenção de sistemas de rede e de informação, incluindo o tratamento de vulnerabilidades, se aplica melhor a esse código do que a medida de segurança da cadeia de suprimentos.
Se você vende software, pode ser o fornecedor direto sobre o qual seus clientes perguntam. A NIS2 abrange organizações por setor e tamanho; portanto, o fato de ser fornecedor de alguém não significa, por si só, que você esteja dentro do escopo da norma. Você terá obrigações próprias se sua empresa for, por si só, uma entidade essencial ou importante. Seja qual for a sua situação, as próprias medidas dos clientes podem levá-los a perguntar como você desenvolve e mantém o que fornece.
Onde os questionários terminam e suas próprias verificações começam
A NIS2 não estabelece verificações específicas para pacotes de código aberto. As verificações a seguir são medidas práticas que se enquadram no Artigo 21, parágrafo 2, alínea e), e no tratamento de vulnerabilidades previsto nesse artigo.
A avaliação de um fornecedor funciona porque você pode solicitar. Você envia um questionário, mantém um contrato, e o fornecedor tem um motivo para responder. Quando seus próprios desenvolvedores incorporam código aberto, pouco disso se aplica ao mantenedor, que publicou o código sob uma licença e talvez nunca tenha ouvido falar de você. Um questionário por si só não consegue verificar se o pacote que você executa corresponde ao código publicado por seus mantenedores e, sem um fornecedor a quem enviá-lo, geralmente não há ninguém responsável por analisá-lo antes que ele chegue até você. Um mantenedor que tenha parado de publicar correções também pode não responder a uma pergunta de segurança.
Isso nos leva às verificações do próprio pacote. Ele corresponde ao código-fonte publicado? Poderia haver algum elemento malicioso nele? Ainda há alguém fazendo correções na versão que você utiliza? Sua equipe precisa garantir que essas verificações sejam realizadas, seja por conta própria ou por meio de um serviço especializado.
Você também vai precisar de um registro do que está presente no seu software e de onde cada componente veio, pois não é possível responder a perguntas do tipo “fornecedor” sobre componentes que você não consegue listar. Os registros habituais são uma lista de materiais de software (SBOM) e dados de proveniência que mostram de onde um artefato veio e como foi construído. Uma declaração do Vulnerability Exploitability eXchange (VEX) acrescenta o status das vulnerabilidades conhecidas em um produto. A confiabilidade de cada um desses registros depende de quem o produziu; portanto, verifique quem está por trás dele e quando foi atualizado pela última vez.
Órgãos de administração aprovam as medidas previstas no artigo 21 e podem ser responsabilizados
Nos termos do Artigo 20, parágrafo 1, os Estados-Membros devem assegurar que os órgãos de gestão de entidades essenciais e importantes aprovem as medidas previstas no Artigo 21, supervisionem sua implementação e possam ser responsabilizados pelas infrações cometidas pela entidade ao Artigo 21. A disposição não especifica se os membros individuais são pessoalmente responsáveis. A regra explícita para pessoas físicas consta do Artigo 32, parágrafo 6. Os Estados-Membros devem possibilitar que sejam responsabilizadas as pessoas com autoridade para representar, tomar decisões em nome de ou controlar uma entidade essencial quando violarem seu dever de garantir o cumprimento das normas, e o artigo 33, parágrafo 5, estende essa disposição às entidades importantes.
A capacitação também é importante: nos termos do Artigo 20, parágrafo 2, os membros dos órgãos de administração devem passar por capacitação para identificar riscos e avaliar as práticas de gestão de riscos de segurança cibernética e seu impacto nos serviços da entidade.
Um órgão de gestão que aprova medidas elaboradas exclusivamente para fornecedores contratados aprovou exatamente esse escopo. A Diretiva ainda abrange o risco decorrente do código aberto que seus desenvolvedores incorporam. O problema é que, no momento da elaboração das medidas, esse risco pode acabar não sendo atribuído nem à medida de segurança da cadeia de suprimentos nem à medida de desenvolvimento prevista na alínea (e), e um órgão de gestão que analise o cadastro de fornecedores pode nunca perceber isso. Pergunte a quem redigir as medidas qual delas abrange as verificações desse código e quem as realiza.
Reduzindo a discrepância entre as avaliações dos fornecedores e suas produções
Para códigos-fonte abertos que não vêm acompanhados de contrato com fornecedor, o SecureChain da TuxCare realiza essas três verificações diretamente no próprio pacote. Ele analisa o código-fonte aberto em busca de malware oculto, recompila os pacotes de código-fonte a partir desse código analisado em ambientes fortificados e isolados e bloqueia qualquer elemento que falhe antes que ele chegue ao seu ambiente. Os pacotes ativos recebem patches de acordo com um acordo de nível de serviço (SLA) e, assim que a manutenção do desenvolvedor original (upstream) termina, o Suporte de Ciclo de Vida Infinito (ELS) garante que as correções continuem sendo fornecidas. A cobertura abrange JavaScript, Python, Java, Go e PHP, e as compilações vêm com proveniência de Nível 3 do SLSA (Supply-chain Levels for Software Artifacts), SBOMs e registros VEX.
Se você não souber dizer o que foi incluído em uma compilação, ou se forem encontradas vulnerabilidades em pacotes que ninguém mais mantém, veja como o SecureChain registra cada compilação e aplica correções nesses pacotes.
Perguntas frequentes
Como a NIS2 aborda a segurança da cadeia de suprimentos?
A NIS2, a diretiva da UE sobre segurança cibernética, inclui a segurança da cadeia de suprimentos como uma das dez medidas mínimas previstas no Artigo 21. Essa medida abrange o aspecto de segurança das relações de uma entidade com seus fornecedores diretos ou prestadores de serviços. O Artigo 21, parágrafo 3, exige que as entidades avaliem as vulnerabilidades de cada fornecedor direto, bem como a qualidade dos produtos e os procedimentos de desenvolvimento seguro do fornecedor.
Quem deve cumprir as medidas da NIS2 relativas à cadeia de suprimentos?
Entidades essenciais e importantes. A NIS2, a diretiva da União Europeia sobre segurança cibernética, classifica as organizações em duas categorias com base na importância do seu setor ou serviço e no porte da organização. Em geral, ela abrange organizações de médio e grande porte nos setores que enumera, bem como algumas organizações menores que atendam a critérios específicos.
A NIS2 impõe obrigações aos fornecedores?
Não diretamente. Em suas diretrizes de julho de 2026 para compras em hospitais, a ENISA, agência de segurança cibernética da UE, afirma que a NIS2 não impõe requisitos diretamente aos fornecedores de tecnologia da informação e comunicação (TIC). Os clientes abrangidos pela NIS2 ainda podem solicitar garantias aos fornecedores como parte de suas próprias medidas.
As orientações da ENISA sobre a segurança da cadeia de suprimentos no âmbito da NIS2 são vinculativas?
Não. A ENISA, agência de segurança cibernética da UE, considera que seu Guia Técnico de Implementação de junho de 2025 não é vinculativo. Ele complementa o Regulamento de Execução (UE) 2024/2690 da Comissão, que abrange os tipos de entidades digitais listados, como provedores de serviços em nuvem e de serviços gerenciados. As diretrizes da ENISA de julho de 2026 para aquisições hospitalares também são recomendações.
Qual pode ser o valor máximo das multas previstas no NIS2 por violação das medidas do Artigo 21?
De acordo com o Artigo 34 da NIS2, a diretiva da UE sobre segurança cibernética, os Estados-Membros devem estabelecer multas máximas de, no mínimo, 10 milhões de euros ou 2% do faturamento anual global total para entidades essenciais, e de, no mínimo, 7 milhões de euros ou 1,4% para entidades importantes, o que for maior. Por “faturamento” entende-se o valor do exercício financeiro anterior referente a toda a empresa à qual a entidade pertence. As multas se aplicam a infrações ao artigo 21 ou às regras de notificação de incidentes do artigo 23, e as leis nacionais estabelecem os valores concretos.
O NIS2 se aplica da mesma forma em todos os países da UE?
Não. As obrigações se aplicam às entidades por meio da legislação nacional de cada Estado-Membro, portanto, os detalhes variam. Muitos Estados-Membros já têm leis em vigor, embora a maioria não tenha cumprido o prazo de outubro de 2024 para sua adoção. Em julho de 2026, a Comissão Europeia levou a Irlanda, a Espanha, a França e os Países Baixos ao Tribunal de Justiça da União Europeia por não terem notificado a transposição completa da legislação. Verifique a legislação de cada país em que você atua.
