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
- A CRA, o FedRAMP, o NIS 2 e o PCI DSS fazem as mesmas duas perguntas sobre seus componentes de código aberto: o que você distribui e o que acontece quando uma vulnerabilidade é identificada.
- Elas diferem quanto ao prazo (o PCI DSS conta a partir do lançamento da correção, o FedRAMP a partir da avaliação, enquanto o CRA e o NIS 2 não estabelecem nenhum prazo específico), quanto a quem analisa o registro e quanto ao tempo de retenção (apenas o CRA especifica um prazo: pelo menos 10 anos).
- Nenhuma delas explica como determinar a origem de um componente, nem quem fornecerá a correção caso seus mantenedores deixem de fazê-lo.
- O SecureChain atende a ambos os requisitos: os pacotes são analisados, recompilados a partir do código-fonte, atualizados com patches sob um SLA e entregues com proveniência, uma SBOM e declarações VEX.
A Lei de Resiliência Cibernética (CRA), o Programa Federal de Gestão de Riscos e Autorizações (FedRAMP), a NIS 2 e a Norma de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS) abrangem, cada uma, muito mais do que apenas evidências de conformidade da cadeia de suprimentos de software, e cada uma delas levanta questões que podem se estender aos pacotes de código aberto presentes em seu produto. Uma dessas exigências já tem uma data definida: a PCI DSS exige um inventário de componentes de terceiros a partir de 31 de março de 2025.
Considere uma empresa hipotética que vende na União Europeia, fornece serviços a uma entidade NIS 2, opera um serviço de nuvem federal e lida com dados de titulares de cartões. Um pacote de código aberto poderia suscitar questionamentos por parte de uma autoridade de fiscalização de mercado, do cliente NIS 2, de uma agência federal e de um avaliador de pagamentos. De onde ele veio e quem aplicará as correções quando seus mantenedores deixarem de fazê-lo?
Os quatro documentos apresentam sobreposições no conteúdo e diferem quanto a quem exibe o quê, para quem e por quanto tempo. O registro mencionado no título é o SecureChain da TuxCare, que disponibiliza pacotes de código aberto por meio de um repositório com conteúdo selecionado.
A quem se destina cada documento
Cada documento possui seu próprio termo para designar a parte a quem se dirige, e esses termos não são transferíveis. A CRA se dirige ao fabricante, que o Artigo 3(13) define como uma pessoa que desenvolve ou fabrica produtos com elementos digitais, ou os manda fabricar, e os comercializa sob seu próprio nome ou marca registrada. O Manual do FedRAMP atribui a responsabilidade primária pelos controles de segurança ao provedor de serviços em nuvem, e as regras de 2026 referem-se a “provedor”. O Manual descreve o processo da Rev. 5; o FedRAMP o mantém em seu site antigo para referência enquanto faz a transição para as regras de 2026. A NIS 2 abrange entidades essenciais e importantes, que os Artigos 2 e 3 definem principalmente por setor e tamanho. A PCI DSS se aplica a entidades que armazenam, processam ou transmitem dados de titulares de cartões ou que possam afetar sua segurança. Isso inclui prestadores de serviços, que são entidades diferentes das marcas de pagamento que processam, armazenam ou transmitem dados de titulares de cartões em nome de outra entidade, ou prestam serviços que possam afetar a segurança do ambiente de dados dos titulares de cartões.
| Documento | Natureza jurídica | Chamado de | Situação em 28 de outubro de 2026 | Base |
|---|---|---|---|---|
| CRA, Regulamento (UE) 2024/2847 | Regulamento, vinculativo em sua totalidade e diretamente aplicável | Fabricante (Art. 3, n.º 13) | Válido a partir de 11 de dezembro de 2027. O artigo 14º entra em vigor a partir de 11 de setembro de 2026. | Texto de encadernação |
| Manual de Monitoramento Contínuo do FedRAMP v1.0 (17 de novembro de 2025) e Regras Consolidadas para 2026 | Orientações do programa (Manual) e regras do programa | Provedor de serviços em nuvem (Playbook), provedor (regras de 2026) | Conjuntos de regras de Detecção e Resposta a Vulnerabilidades (VDR) e Avaliação e Relatórios de Vulnerabilidades (VER): certificação inicial e contínua a partir de 7 de dezembro de 2026. O período de carência termina em 7 de março de 2027. | Orientações (Manual). Regras marcadas como obrigatórias. |
| NIS 2, Diretiva (UE) 2022/2555 | Diretiva, transposta para a legislação nacional de cada Estado-Membro | Entidades essenciais e importantes (Art. 2º, 3º) | As medidas dos Estados-Membros deveriam ser adotadas até 17 de outubro de 2024 e entram em vigor a partir de 18 de outubro de 2024 (Art. 41, § 1). | Vinculatividade para os Estados-Membros |
| PCI DSS v4.0.1 (junho de 2024) | Padrão do setor | Entidades que armazenam, processam ou transmitem dados de titulares de cartões (Seção 2) | Versão 4.0.1, junho de 2024. O requisito 6.3.2 é obrigatório desde 31 de março de 2025. | Padrão do setor |
Uma empresa pode desempenhar mais de uma dessas funções ao mesmo tempo, como fabricante no âmbito da CRA e provedora de serviços em nuvem no âmbito do FedRAMP; portanto, sua função determina quais perguntas do documento se aplicam a ela. O que você deve apresentar como evidência de conformidade da cadeia de suprimentos de software tem um nome diferente em cada documento. A CRA solicita documentação técnica; o Manual do FedRAMP exige entregas e evidências de apoio; a NIS 2 exige evidências de implementação; e a PCI DSS exige que um avaliador examine a documentação.
Observação: A norma PCI DSS v4.0.1 deixa a cargo das marcas de pagamento, das adquirentes e de outras organizações que administram programas de conformidade a decisão sobre quem deve cumprir a norma ou validar a conformidade (Seção 2).
O que cada um pergunta sobre componentes de terceiros
O que está contido no seu software é referido por um nome diferente em cada documento. A CRA identifica diretamente os componentes de código aberto. A NIS 2 se refere a fornecedores diretos e prestadores de serviços. O Manual do FedRAMP, que não menciona código aberto nem listas de materiais de software, aborda o inventário e as vulnerabilidades, enquanto a PCI DSS identifica componentes de terceiros em softwares desenvolvidos sob medida e personalizados.
| Documento (natureza) | O que é solicitado em relação aos componentes | O que você mostra e para quem | Taxa de retenção declarada | Base |
|---|---|---|---|---|
| CRA (regulamentação) | Realizar a devida diligência em relação a componentes de terceiros (Art. 13, § 5). Comunicar as vulnerabilidades dos componentes ao mantenedor e corrigi-las (Art. 13, § 6). Identificar e documentar os componentes, por meio de uma lista de materiais de software que abranja, no mínimo, as dependências de nível superior (Anexo I, Parte II, § 1). | Documentação técnica (Anexo VII), mantida à disposição das autoridades de fiscalização de mercado (Art. 13, § 13). Lista de componentes de software, mediante solicitação fundamentada da autoridade (Anexo VII, ponto 8). | Documentação técnica: pelo menos 10 anos após a colocação do produto no mercado, ou pelo período de suporte, se este for mais longo (Art. 13, § 13) | Texto de encadernação |
| FedRAMP (orientações e regras do programa) | Realizar inventário pelo menos uma vez por mês (Manual, Seção 2). Cada vulnerabilidade específica é acompanhada como um item próprio do plano de ação e marcos (POA&M) (Seção 3). O monitoramento da cadeia de suprimentos é listado como uma técnica de detecção (VDR-CSO-DET). | Envio mensal do POA&M e do inventário ao repositório seguro para análise pela agência (Playbook). Relatório mensal de atividades relacionadas a vulnerabilidades para todas as partes envolvidas (VER-TFR-MHR). | Não há nenhuma menção no Manual de Jogo nem no conjunto de regras do VER | Orientações (Manual). As regras marcadas como obrigatórias. |
| NIS 2 (diretiva) | Segurança da cadeia de suprimentos, incluindo as relações com fornecedores diretos (Art. 21, § 2, alínea d)). Tratamento e divulgação de vulnerabilidades (Art. 21, § 2, alínea e)). Avaliar as vulnerabilidades, a qualidade dos produtos e as práticas de segurança cibernética de cada fornecedor direto, incluindo procedimentos de desenvolvimento seguro (Art. 21, § 3). | Mediante solicitação, comprovação da implementação das políticas de segurança cibernética à autoridade competente (Art. 32, § 2, alínea g), para entidades essenciais; Art. 33, § 2, alínea f), para entidades importantes). | Não há disposições nos artigos 21, 32 ou 33 | Vinculatividade para os Estados-Membros |
| PCI DSS v4.0.1 (padrão do setor) | Inventário de softwares desenvolvidos sob medida e personalizados e de seus componentes de terceiros (6.3.2). As correções para vulnerabilidades críticas são instaladas no prazo de um mês após o lançamento (6.3.3). Inventário dos componentes do sistema abrangidos pela norma (12.5.1). | Documentação e entrevistas analisadas por um avaliador (6.3.2.a, 6.3.2.b). | Não há indicação nas seções 6.3.2, 6.3.3 ou 12.5.1 | Padrão do setor |
Observação: O Artigo 13, parágrafo 5, aplica o dever de diligência devida aos componentes de código aberto e de uso livre, mesmo quando estes não tenham sido disponibilizados no âmbito de uma atividade comercial.
Onde as evidências de conformidade da cadeia de suprimentos de software se sobrepõem e onde não se sobrepõem
A sobreposição está no conteúdo das duas perguntas. Uma delas diz respeito aos componentes que você fornece. A CRA, o Playbook e a PCI DSS exigem, cada um à sua maneira, algum tipo de inventário. A NIS 2 inclui a gestão de ativos entre as medidas do Artigo 21(2)(i) e faz perguntas sobre fornecedores, enquanto o Artigo 21 não menciona nenhuma lista de componentes. A outra questão é o que acontece quando uma vulnerabilidade é detectada, e todos os quatro documentos abordam esse tema. De acordo com a CRA, a correção deve ser realizada sem demora (Anexo I, Parte II(2)). A NIS 2 menciona o tratamento e a divulgação de vulnerabilidades (Artigo 21(2)(e)). O PCI DSS estabelece um prazo de um mês a partir da divulgação para a disponibilização de patches para vulnerabilidades críticas (6.3.3), e as regras de 2026 do FedRAMP atribuem o rótulo de vulnerabilidade aceita a qualquer item que ainda esteja pendente 192 dias após a avaliação (VER-TFR-MAV).
As diferenças começam pelos prazos. O PCI DSS conta a partir do lançamento de uma correção; o FedRAMP, a partir da avaliação; já o CRA e o NIS 2 não especificam prazos nas disposições citadas aqui. Eles também diferem quanto a quando e a quem se deve apresentar a documentação. Uma autoridade de fiscalização de mercado tem à sua disposição a documentação técnica da CRA; as agências analisam os relatórios mensais do FedRAMP; uma autoridade competente pode solicitar evidências de uma entidade NIS 2; e um avaliador do PCI DSS verifica a documentação da entidade. Não se deve presumir que um registro elaborado com base no prazo e no leitor de um documento seja adequado para outro.
O que os documentos deixam a seu critério
Todos os quatro documentos levantam a questão e deixam grande parte da metodologia em aberto. A CRA exige que os fabricantes documentem os aspectos de segurança cibernética do produto de maneira proporcional ao risco (Artigo 13(7)), e a NIS 2 exige medidas adequadas e proporcionais (Artigo 21(1)). A PCI DSS deixa o prazo para a aplicação de outros patches aplicáveis — aqueles que não se destinam a vulnerabilidades críticas — a cargo da própria avaliação de risco da entidade (6.3.3), e a regra de detecção do FedRAMP exige técnicas adequadas (VDR-CSO-DET).
Duas questões permanecem em aberto nas disposições citadas até o momento. A primeira diz respeito à origem de um componente. O Artigo 13(5) da CRA exige a devida diligência para que componentes de terceiros não comprometam o produto, e o Artigo 21(3) da NIS 2 exige que as entidades avaliem os procedimentos de desenvolvimento seguro dos fornecedores. O Considerando 85 da NIS 2, que não é vinculativo, descreve como invasores comprometem entidades ao explorar vulnerabilidades em produtos e serviços de terceiros. Nenhum dos artigos explica como verificar se um componente corresponde à fonte da qual alega provir ou se não contém código malicioso.
O segundo ponto diz respeito à origem da correção. A norma PCI DSS 6.3.3 considera um prazo de um mês a partir do lançamento de um patch, o que pressupõe que alguém já tenha lançado um. A CRA atribui ao fabricante a responsabilidade de fornecer atualizações de segurança (Anexo I, Parte II(2)), e o Artigo 13(8) mantém as vulnerabilidades nos componentes de um produto dentro do escopo durante todo o período de suporte da CRA. No ciclo de monitoramento contínuo da Rev. 5 do FedRAMP, uma constatação sem correção na fonte permanece no POA&M mensal como uma dependência do fornecedor. Para provedores com mais de um cliente de órgão governamental, o Manual orienta que a reunião colaborativa mensal se concentre em itens em atraso e dependências de fornecedores (Seção 7). Nenhuma dessas disposições especifica de onde vem a correção propriamente dita, uma vez que os mantenedores tenham deixado de lançá-las.
O papel do SecureChain para software de código aberto
O SecureChain, da TuxCare, analisa o código-fonte de pacotes de código aberto em busca de malware oculto e os recompila em um ambiente isolado a partir desse código analisado. Os pacotes que não passam na inspeção são bloqueados antes de chegarem ao ambiente do cliente, e os demais são disponibilizados por meio de um repositório selecionado.
Cada pacote é fornecido com informações de proveniência (um registro assinado de como foi compilado, de acordo com o Nível 3 da SLSA), uma SBOM, declarações VEX e registros de origem e status de correção exigidos pelos documentos acima.
O SecureChain aplica correções aos componentes ativos sob um acordo de nível de serviço e, para versões que não recebem mais manutenção do desenvolvedor original, o Endless Lifecycle Support (ELS) adapta correções para vulnerabilidades de risco crítico, alto, médio e baixo às versões em uso, seguindo um cronograma definido. O SecureChain abrange pacotes de código aberto em JavaScript, Python, Java, Go e PHP.
Se você ainda não consegue identificar a origem de um componente, ou quem o atualiza quando o desenvolvimento no upstream é interrompido, veja como o SecureChain para Software de Código Aberto aborda ambas as questões.
Perguntas frequentes
Como a CRA, o FedRAMP, o NIS 2 e o PCI DSS utilizam o termo “evidência”?
Todos os quatro utilizam esse termo, em sentidos diferentes. O Anexo VII da Lei de Resiliência Cibernética lista a comprovação da existência de um endereço de contato para notificação de vulnerabilidades na documentação técnica. Os artigos 32 e 33 da NIS 2 permitem que as autoridades solicitem comprovantes de implementação. O Manual do Programa Federal de Gestão de Riscos e Autorizações menciona comprovantes de apoio, e a Norma de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS) determina que os avaliadores examinem a documentação e entrevistem o pessoal (6.3.2.a, 6.3.2.b).
Por quanto tempo a documentação técnica da CRA deve ser mantida?
De acordo com o Artigo 13(13) da Lei de Resiliência Cibernética (CRA), os fabricantes são obrigados a manter a documentação técnica à disposição das autoridades de fiscalização de mercado por pelo menos 10 anos após a colocação do produto no mercado, ou durante o período de suporte, caso este seja mais longo. O Anexo VII enumera o conteúdo, incluindo uma lista de componentes de software, quando aplicável.
Quais são as multas previstas pela CRA e pela NIS 2?
O Artigo 64(2) da Lei de Resiliência Cibernética prevê multas de até 15.000.000 de euros ou 2,5% do faturamento anual total mundial do exercício financeiro anterior, em caso de violações do Anexo I e dos Artigos 13 e 14. O artigo 34 da NIS 2 exige que os Estados-Membros estabeleçam limites máximos de, no mínimo, 10.000.000 de euros ou 2% do faturamento para entidades essenciais, e de 7.000.000 de euros ou 1,4% do faturamento para entidades importantes. Em todos os casos, aplica-se o valor mais alto.
Como a NIS 2 entra em contato com um fornecedor de software?
A NIS 2 atribui suas obrigações a entidades essenciais e importantes; portanto, geralmente se chega a um fornecedor por meio de um cliente. O Artigo 21, parágrafo 2, alínea d), e o Artigo 21, parágrafo 3, exigem que a entidade avalie as vulnerabilidades de cada fornecedor direto e garanta procedimentos de desenvolvimento seguros. Um fornecedor que seja, por si só, uma entidade essencial ou importante está sujeito à diretiva por direito próprio, por meio da legislação dos Estados-Membros.
Em que casos a norma PCI DSS exige um inventário de componentes de terceiros?
O requisito 6.3.2 da Norma de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS) v4.0.1, um padrão do setor, abrange componentes de terceiros incorporados a softwares desenvolvidos sob medida e personalizados. Até 31 de março de 2025, tratava-se de uma prática recomendada; a partir dessa data, passa a ser obrigatória. A decisão sobre se uma entidade deve realizar a validação cabe às marcas de pagamento, às adquirentes e a outras organizações que administram programas de conformidade.
