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
- Desde 13 de julho de 2026, as licitações do setor de defesa podem exigir apenas autoavaliações de Nível 1 ou Nível 2, enquanto a Fase 2 permanece suspensa.
- Nenhum dos 110 requisitos do Nível 2 menciona código aberto, mas o software é um ativo; portanto, os pacotes de código aberto nos sistemas abrangidos pela norma são tratados da mesma forma que os demais.
- São quatro requisitos que se aplicam a eles: inventário, software instalado pelo usuário, verificação de vulnerabilidades e correção de falhas.
- Três desses são requisitos de cinco pontos; portanto, qualquer falha em qualquer um deles não pode ser adiada por meio de um plano de ação e marcos.
Os requisitos de conformidade da Certificação do Modelo de Maturidade em Cibersegurança (CMMC) não impõem nenhuma exigência específica em relação ao seu código-fonte aberto. No entanto, os 110 requisitos que o CMMC estabelece para contratados que lidam com Informações Controladas Não Classificadas (CUI) ainda se aplicam aos pacotes de código aberto em sua compilação. Isso permanece válido mesmo após o Pentágono ter suspendido a Fase 2 do programa CMMC em 13 de julho de 2026, etapa que teria tornado a avaliação por terceiros uma condição para a adjudicação dos contratos aplicáveis. Esses mesmos 110 requisitos continuam sendo a base para as autoavaliações.
O que abrangem os requisitos de conformidade do CMMC
O CMMC possui três níveis. O nível aplicável a você depende das informações envolvidas e dos requisitos estabelecidos em seu contrato ou edital.
| Nível | Informações | Requisitos | Quem avalia |
|---|---|---|---|
| Nível 1 | Informações sobre Contratos Federais (FCI) | 15 requisitos básicos do Regulamento Federal de Aquisições | Você, por meio de uma autoavaliação anual |
| Nível 2 | CUI | 110 requisitos da norma SP 800-171, Revisão 2, do Instituto Nacional de Padrões e Tecnologia (NIST) | Você ou uma Organização de Avaliação de Terceiros do CMMC (C3PAO), quando a licitação assim o exigir (suspenso por enquanto) |
| Nível 3 | CUI em programas selecionados | 24 requisitos selecionados da norma NIST SP 800-172, além do Nível 2 | Agência de Gestão de Contratos de Defesa (DCMA) |
Os 110 requisitos do Nível 2 abrangem 14 categorias, desde o controle de acesso até a integridade do sistema e da informação.
A situação atual dos requisitos de conformidade com o CMMC em 2026
A norma do Suplemento ao Regulamento Federal de Aquisições do Departamento de Defesa (DFARS) que incorpora o CMMC aos contratos entrou em vigor em 10 de novembro de 2025, marcando o início da Fase 1. Na Fase 1, o Departamento de Defesa (DoD) inclui, quando aplicável, a exigência de uma autoavaliação de Nível 1 ou Nível 2 como condição para a adjudicação do contrato.
A Fase 2, com prazo previsto para 10 de novembro de 2026, teria incluído avaliações de Nível 2 realizadas pelas C3PAOs como condição para a adjudicação. Em 13 de julho de 2026, o diretor de informática do Departamento de Defesa (DoD) suspendeu essa exigência. Os gerentes de programa agora podem exigir apenas autoavaliações de Nível 1 ou Nível 2, e os contratos que já prevejam uma avaliação realizada por um C3PAO ou liderada pelo governo deverão ser alterados no próximo período de opção ou alteração administrativa.
O regulamento do programa em si não foi reescrito desde que a suspensão foi comunicada por meio de memorandos; portanto, ele ainda descreve as quatro fases originais. As alterações são publicadas na página do CMMC do diretor de informática do Departamento de Defesa.
Por enquanto, os 110 requisitos constituem o ponto de convergência, e o código aberto se insere por meio deles.
O que a norma diz sobre componentes de código aberto
Os 110 requisitos do Nível 2 são os requisitos da Norma NIST SP 800-171, Revisão 2, e a regra do programa estabelece que eles são idênticos. Desde então, o NIST substituiu a Revisão 2 pela Revisão 3, mas o CMMC ainda utiliza a Revisão 2, assim como o guia de avaliação do Departamento de Defesa (DoD). Na prática, isso significa que a versão dos requisitos aplicável aos seus pacotes de código aberto é o texto da Revisão 2, e não o da Revisão 3.
Cada um dos 110 requisitos é acompanhado por dois elementos nos documentos do NIST e do Departamento de Defesa (DoD): um conjunto de objetivos de avaliação (uma lista de verificação das condições que devem ser atendidas para que o requisito seja considerado cumprido) e uma explicação (texto explicativo que descreve a intenção, mas que não constitui, por si só, um requisito).
O guia de avaliação do Nível 2 solicita que os autoavaliadores utilizem os mesmos critérios que um avaliador independente utilizaria e que não considerem o que os funcionários dizem nas entrevistas como prova do que o sistema realmente faz. A seção de pontuação da regra define o padrão de evidência: rascunhos, documentos de trabalho e políticas não aprovadas não são considerados. No caso do código aberto, isso significa que um rascunho de inventário ou uma política de digitalização que ninguém tenha aprovado não conta como evidência.
Nenhuma das 110 declarações de requisitos cita código aberto nem menciona listas de materiais de software (SBOMs), proveniência ou cadeia de suprimentos. O software é abordado por meio das definições. No CMMC, o software é considerado um ativo; portanto, os pacotes de código aberto em um sistema dentro do escopo da sua avaliação estão sujeitos aos mesmos requisitos que o restante do software desse sistema. O que coloca um sistema no escopo é o que ele faz com as CUI: os ativos que as processam, armazenam ou transmitem são avaliados em relação a todos os requisitos do Nível 2. O escopo também inclui ativos que protegem esses sistemas, como firewalls e serviços de identidade. Um servidor de compilação ou uma estação de trabalho de desenvolvedor que nunca tenha contato com CUI pode ficar fora do escopo, e é essa decisão de escopo que o requisito de software instalado pelo usuário determinará posteriormente. O guia de escopo do Departamento de Defesa (DoD) apresenta a descrição completa.
O risco da cadeia de suprimentos é mencionado em dois requisitos do Nível 3, mas o Nível 3 é um nível distinto, com sua própria avaliação conduzida pelo governo; portanto, nenhum desses requisitos se aplica ao Nível 2.
Quatro práticas que abrangem sua árvore de dependências
Mantenha um inventário do que está no sistema (CM.L2-3.4.1). É necessário manter uma lista do hardware e do software que compõem cada sistema abrangido, incluindo os números de versão, e mantê-la atualizada à medida que o sistema sofre alterações. O código aberto entra em cena aqui porque os pacotes em seu aplicativo, incluindo aqueles incorporados indiretamente por outros pacotes, são softwares com números de versão. Se eles não estiverem na lista, a lista está incompleta.
Controle o que os usuários instalam (CM.L2-3.4.9). É necessário ter uma política que defina quais softwares os usuários podem instalar, uma forma de fazer com que ela seja cumprida e uma maneira de verificar o que foi instalado. O texto explicativo do NIST afirma que a política pode proibir softwares “de origem desconhecida ou suspeita”, o que é o mais próximo que o Nível 2 chega de perguntar de onde o software veio. Essa menção à “origem” é apenas uma orientação, portanto, por si só, não pode ser considerada uma falha. O requisito em si — uma política sobre o que pode ser instalado, sua aplicação e um registro do que foi instalado — não é opcional; e, se o seu ambiente de compilação estiver dentro do escopo da avaliação, os pacotes que os desenvolvedores adicionarem a ele podem ser considerados instalações como qualquer outro.
Realize varreduras em busca de vulnerabilidades de acordo com um cronograma (RA.L2-3.11.2). É necessário fazer varreduras nos sistemas e aplicativos com a frequência que você definir e executar varreduras adicionais quando novas vulnerabilidades forem divulgadas. Os pacotes de código aberto presentes em seus aplicativos fazem parte do que é verificado.
Em conjunto, os requisitos relativos ao inventário, ao software instalado pelo usuário e à verificação de vulnerabilidades abrangem o que está presente na sua compilação, o que é permitido nela e quais vulnerabilidades conhecidas ela apresenta. O quarto requisito, que trata da correção oportuna de falhas (SI.L2-3.14.1), aborda o que ocorre assim que uma vulnerabilidade é identificada.
Por que a correção oportuna de falhas precisa de um número definido por você
A norma SI.L2-3.14.1 determina que se identifiquem, relatem e corrijam falhas do sistema em tempo hábil, mas nada no requisito, no texto explicativo do NIST ou no guia de avaliação do Departamento de Defesa (DoD) especifica quanto tempo significa “em tempo hábil”. Todos os três deixam a cargo de você definir um prazo, e o próprio exemplo do guia é um número definido de dias com base na gravidade da falha. O que você precisa demonstrar é que definiu um prazo e que o cumpriu.
Um prazo que você costuma deixar de cumprir deixa um registro dessa lacuna e, sem um prazo definido, a lista de verificação da avaliação não pode ser preenchida.
O caso mais complicado é aquele em que um componente já não recebe manutenção, pois não há correções vindas do upstream. O guia considera patches aplicados, alterações de configuração e soluções alternativas ou medidas de mitigação como formas de corrigir uma falha; portanto, você tem mais de uma opção. Você pode substituir o componente, migrar para uma série de versões mais recente, implementar uma solução alternativa ou aplicar uma correção à versão que você utiliza, e cada uma dessas opções deixa rastros diferentes. Substituir ou migrar pressupõe que exista um substituto ou uma série mais recente e que seu código possa aceitar a mudança; é por isso que a atualização nem sempre é uma opção, especialmente quando o componente está localizado em um nível profundo da árvore de dependências.
O que um POA&M pode e não pode cobrir
Uma avaliação resulta em um dos três resultados para cada requisito (ATENDIDO, NÃO ATENDIDO ou não aplicável) e em um status geral. O status final significa que todos os requisitos foram atendidos. O status condicional significa que ainda existem algumas lacunas e que você se comprometeu a saná-las.
A metodologia de pontuação da regra atribui 1, 3 ou 5 pontos a cada requisito, com base no dano potencial que uma falha poderia causar. Você começa com 110 pontos e perde pontos por cada requisito não atendido. Dos quatro requisitos que se aplicam aos seus pacotes de código aberto, três (inventário, varredura de vulnerabilidades e correção de falhas) valem cinco pontos cada, enquanto o software instalado pelo usuário vale um ponto.
Um plano de ação e marcos (POA&M) permite que você adie a correção de algumas lacunas para depois da avaliação, e a seção 170.21 do regulamento do programa impõe restrições rigorosas a isso. Você só obtém o status “Condicional” — aquele que permite um POA&M — com uma pontuação de pelo menos 88 em 110.
Apenas os requisitos que valem um ponto podem ser incluídos no plano, exceto o requisito de criptografia, que normalmente vale cinco pontos, mas pode ser incluído quando recebe uma pontuação de três, pois a criptografia utilizada não é validada de acordo com as Normas Federais de Processamento de Informações (FIPS). A regra também exclui seis requisitos específicos do plano, independentemente da pontuação: o requisito do plano de segurança do sistema, dois que abrangem conexões externas e informações públicas e três requisitos de acesso físico.
Incluir uma lacuna no plano não altera sua conclusão, que permanece como “NÃO ATENDIDA” até que seja sanada.
Qualquer item incluído no plano deve ser concluído e confirmado no prazo de 180 dias; caso contrário, o status “Condicional” expirará. Esse prazo de 180 dias para conclusão se aplica tanto à autoavaliação de Nível 2 quanto à avaliação realizada por terceiros.
Inventário, varredura de vulnerabilidades e correção de falhas são requisitos de cinco pontos; portanto, nenhum deles pode ser incluído no plano: ou você os cumpre no momento da avaliação ou não recebe o status “Condicional”. O software instalado pelo usuário é um requisito de um ponto; portanto, uma lacuna nessa área pode ser incluída no plano, desde que sua pontuação geral ainda seja de pelo menos 88. Ela ainda é considerada como “NÃO CUMPRIDA” e deve ser sanada em até 180 dias.
Observação: O plano de ação operacional previsto na norma CA.L2-3.12.2 é um documento separado. A norma o define como um registro das vulnerabilidades e deficiências temporárias e de como elas serão corrigidas, sem prazo definido, e não se confunde com um POA&M de avaliação. O prazo de 180 dias refere-se ao POA&M.
Requisitos de conformidade com o CMMC para prestadores de serviços e pequenas empresas
A regra do programa se aplica aos adjudicados de contratos e subcontratos do Departamento de Defesa (DoD) que processam, armazenam ou transmitem FCI ou CUI no decorrer de seu trabalho, e se estende aos subcontratados que realizam as mesmas atividades. Os gerentes de programa do DoD determinam o nível CMMC para cada aquisição com base nas informações envolvidas e na criticidade do programa; portanto, duas empresas do mesmo porte podem acabar recebendo níveis diferentes. Dentro do Nível 2, os 110 requisitos constituem uma lista única para todos.
A questão do porte das empresas transparece no próprio raciocínio do Departamento de Defesa. O comunicado de 13 de julho, que suspendeu a Fase 2, afirmou que a revisão do departamento visa reduzir as barreiras para pequenas empresas e empresas não tradicionais. Até que essa revisão resulte em mudanças, o regime de autoavaliação é a medida de alívio disponível.
Onde o SecureChain se encaixa
O SecureChain da TuxCare oferece pacotes de código aberto que são verificados antes de chegarem até você e recebem correções enquanto você depender deles. Ele funciona como uma fonte única para JavaScript, Python, Java, Go, Rust e PHP.
Cada pacote é recompilado a partir do código-fonte em ambientes isolados e verificado quanto à presença de malware e códigos suspeitos; qualquer item que não passe na inspeção é bloqueado antes de chegar ao seu ambiente. Os componentes ativos recebem correções de acordo com um acordo de nível de serviço. Quando a manutenção do desenvolvedor original é encerrada, o Suporte de Ciclo de Vida Ilimitado (ELS) continua a fornecer correções para componentes que não recebem mais manutenção.
Além disso, gera registros sobre o que entrega, incluindo a proveniência no Nível 3 do SLSA (Supply-chain Levels for Software Artifacts), uma SBOM e dados do VEX (Vulnerability Exploitability eXchange).
O que você deverá apresentar
Nada no CMMC menciona as palavras “código aberto”. Mas, ao avaliar seu inventário de sistemas, seus resultados de varredura e seu registro do que foi corrigido e quando, todos os pacotes de código aberto presentes em seus aplicativos devem constar em cada um desses itens. Se você não conseguir apresentar esses três elementos para um pacote hoje, essa é a lacuna que deve ser sanada em primeiro lugar.
Perguntas frequentes
Quais são os requisitos de conformidade do CMMC?
O programa de Certificação do Modelo de Maturidade em Cibersegurança (CMMC) estabelece requisitos de segurança para empresas contratadas pelo setor de defesa que lidam com Informações de Contratos Federais (FCI) ou Informações Não Classificadas Controladas (CUI). O Nível 1 abrange 15 requisitos básicos; o Nível 2 abrange os 110 requisitos da norma SP 800-171, Revisão 2, do Instituto Nacional de Padrões e Tecnologia (NIST); e o Nível 3 acrescenta 24 requisitos selecionados da norma SP 800-172.
Quando a conformidade com o CMMC será obrigatória em 2026?
Isso depende do contrato. Desde 10 de novembro de 2025, novas licitações do Departamento de Defesa podem exigir autoavaliações de Nível 1 ou Nível 2 como condição para a adjudicação no âmbito do programa de Certificação do Modelo de Maturidade em Cibersegurança (CMMC). A Fase 2, que teria introduzido avaliações de Nível 2 realizadas por terceiros em 10 de novembro de 2026, está suspensa desde 13 de julho de 2026.
Quais são os requisitos de conformidade com o CMMC para pequenas empresas?
As pequenas empresas enfrentam os mesmos requisitos que outros contratados do mesmo nível. As regras do programa estabelecem requisitos de acordo com o tipo de informação tratada, e o Nível 2 consiste em uma lista única de 110 requisitos aplicáveis a todos. O anúncio do Departamento de Defesa, de julho de 2026, que suspendeu parte do programa, afirmou que sua revisão visa reduzir as barreiras para pequenas empresas e empresas não tradicionais.
O Nível 2 do CMMC exige registros de proveniência de código aberto?
Não. No programa de Certificação do Modelo de Maturidade em Cibersegurança (CMMC), nenhum dos 110 requisitos do Nível 2 menciona código aberto ou proveniência. A seção relativa ao software instalado pelo usuário, CM.L2-3.4.9, afirma que as instalações proibidas podem incluir software com proveniência desconhecida ou suspeita, mas trata-se apenas de um texto explicativo. O risco da cadeia de suprimentos é mencionado em dois requisitos do Nível 3.
Um plano de ação e marcos podem abranger a correção de falhas?
Não é possível. Um plano de ação e seus marcos podem conter apenas requisitos de um ponto, com exceção de uma regra de criptografia, e a correção de falhas (SI.L2-3.14.1) recebe uma pontuação de cinco pontos de acordo com a regra do programa. Além disso, o plano precisa atingir uma pontuação mínima de 88 em 110 e deve ser concluído em até 180 dias; caso contrário, o status “Condicional” expira.
Como manter a conformidade com o CMMC após uma avaliação?
No âmbito do programa de Certificação do Modelo de Maturidade em Cibersegurança (CMMC), um responsável pela certificação — a pessoa com autoridade para atestar a conformidade da empresa — deve confirmar a conformidade contínua a cada ano. O status de Nível 2 tem validade de três anos antes de ser necessária uma nova avaliação, e as autoavaliações do Nível 1 são realizadas anualmente.
