A Lei do Conselho de Estado nº 834 foi Implementada: Segurança da Cadeia de Suprimentos de Software, o que as Empresas Realmente Precisam Não São Ferramentas, mas Sim Estas Três Coisas

A Lei do Conselho de Estado nº 834 foi Implementada: Segurança da Cadeia de Suprimentos de Software, o que as Empresas Realmente Precisam Não São Ferramentas, mas Sim Estas Três Coisas

I. A Regulamentação Chegou, e a Janela de Oportunidade é Curta

Em 31 de março de 2026, o Conselho de Estado divulgou as "Disposições sobre a Segurança da Cadeia de Indústria e Suprimentos" (Ordem do Conselho de Estado nº 834), que entrou em vigor imediatamente.

O Artigo 12 afirma diretamente:

Empresas, instituições de pesquisa e outras entidades devem aprimorar seus sistemas de prevenção de riscos para alcançar a segurança e controlabilidade das tecnologias centrais e sistemas de informação e dados relacionados.

O Artigo 9 exige o estabelecimento de um "sistema de alerta precoce para monitoramento de riscos de segurança da cadeia de indústria e suprimentos em áreas-chave". As empresas que descobrirem riscos de segurança devem relatar às autoridades competentes. Esta não é uma norma da indústria, mas um regulamento administrativo com efeito em todos os setores.

Antes disso, o padrão nacional GB/T 43698—2024 "Requisitos de Segurança da Cadeia de Suprimentos de Software para Tecnologia de Segurança Cibernética" foi implementado em 1º de novembro de 2024, atualizando as obrigações de segurança da cadeia de suprimentos das empresas de "recomendado" para "deve". O padrão exige que os compradores e usuários de software (ou seja, a grande maioria das empresas) façam o seguinte:

• Verificação de integridade completa + detecção de segurança abrangente antes de obter software, garantindo que nenhuma vulnerabilidade pública não seja corrigida (§7.2.3)
• Obter pacotes de instalação/atualização de canais seguros e controláveis durante a operação e manutenção, e implantá-los somente após a verificação de integridade (§7.2.4(d))
• Descobrir vulnerabilidades, tomar medidas corretivas imediatas e relatar às autoridades competentes de acordo com os regulamentos (§7.2.4(i))
• Construir e manter um mapa de segurança da cadeia de suprimentos de software (incluindo SBOM), cenários de negócios importantes devem conter informações de vulnerabilidade de componentes, atualizados pelo menos anualmente (§6.2)
• Verificação de integridade, detecção de segurança e análise de dependência antes do uso de componentes de código aberto/terceiros, estabelecer uma biblioteca de componentes e rotular quatro níveis: preferencial/opcional/limitado/proibido (§8.2.2(g))

Duas camadas de regulamentos, uma acima e outra abaixo, estão convergindo. A segurança da cadeia de suprimentos de software passou de "algo que a equipe de segurança se preocupa" para "uma obrigação de conformidade corporativa".

II. Desvios Cognitivos da Maioria das Empresas

Ao se comunicar com as equipes de segurança de diferentes empresas, frequentemente ouvimos coisas como:

• "Temos Nexus, todos os pacotes passam por um repositório privado."
• "Temos ferramentas de varredura SCA, executamos regularmente."
• "Sabemos imediatamente se algo acontece."

Essas três frases representam a estrutura cognitiva mais típica que as empresas têm atualmente sobre a segurança da cadeia de suprimentos de software:

• Equiparando "ter ferramentas" com "ter capacidade" e "varredura regular" com "proteção contínua".

Onde está o problema?

• Nexus é apenas uma esteira transportadora, não um portão de segurança. Sua principal função é o cache e a distribuição, não a revisão de segurança. Uma conta de desenvolvedor comprometida pode empurrar qualquer versão de um pacote interno para o Nexus; vários nós de construção compartilham o diretório de cache, e um pacote contaminado pode se espalhar silenciosamente para todas as tarefas de construção subsequentes. O Nexus em si não tem consciência desses riscos.
• A varredura SCA é um instantâneo, não uma proteção em tempo real. A essência da varredura regular é a "auditoria posterior" - o ataque já ocorreu, as dependências já foram introduzidas, e você só sabe da existência do problema. No final de março de 2026, o evento de envenenamento Axios, a versão maliciosa levou menos de 4 horas para ser enviada e removida oficialmente. Os desenvolvedores ou pipelines de CI que executaram npm install dentro dessa janela de 4 horas não foram salvos pela varredura regular.
• "Saber" e "ser capaz de parar" são duas coisas completamente diferentes. A inteligência informa que este pacote é malicioso, mas se o ambiente de trabalho do desenvolvedor pode acessar a Internet diretamente via pip install, se o pipeline de CI pode contornar o repositório privado e se conectar diretamente ao PyPI - então o valor da inteligência se resume a "atribuição posterior".

O Artigo 7.2.4(d) do GB/T 43698—2024 exige "obter pacotes de instalação/atualização de canais seguros e controláveis", o que não significa apenas "usar o Nexus", mas sim que toda a cadeia deve ser controlável - incluindo quem pode enviar quais versões de pacotes, se o ambiente de construção tem atalhos e se os pacotes internos foram adulterados.

III. A Verdadeira Forma da Superfície de Ataque da Cadeia de Suprimentos: Expansão Simultânea em Três Direções

Para entender por que "ter ferramentas" não é suficiente, você precisa primeiro entender a estrutura da superfície de ataque que as empresas enfrentam atualmente.

• Direção 1: Envenenamento de Pacotes de Código Aberto Externos - Maduro e em Contínua Atualização

PyPI, npm e Maven têm novos pacotes maliciosos sendo lançados todos os dias. As táticas de ataque evoluíram da imitação de nomes originais para o sequestro de contas de mantenedores - no final de março de 2026, os invasores usaram três semanas para engenharia social do principal mantenedor da biblioteca npm com o maior número de downloads globais, obtiveram a conta e, em poucas horas, enviaram versões com backdoors para milhões de pipelines de CI em execução em todo o mundo, e se auto-excluíram e destruíram evidências forenses após a execução do código.

• Direção 2: Ataques à Cadeia de Ferramentas de IA - Emergente, Crescimento Mais Rápido

Ao usar assistentes de programação de IA como Claude Code e Cursor, os desenvolvedores instalarão vários arquivos Skill para aprimorar suas capacidades. Os invasores já estão lançando em massa Skills maliciosos em plataformas como ClawHub e Anthropic Marketplace - aparentemente "conjuntos de ferramentas Python", mas na verdade eles guiam os assistentes de IA para ler ~/.aws/credentials, chaves SSH privadas ou implantar silenciosamente a lógica de backdoor ao gerar código. Esse tipo de ataque contorna completamente o escopo de detecção das ferramentas SAST/DAST tradicionais, e os sistemas de varredura de segurança existentes quase não têm cobertura.

• Direção 3: Repositórios de Artefatos Internos - Mais Ocultos, Mais Ignorados

Esta é a direção menos discutida e a mais difícil de avaliar em termos de dano real. Nos próprios repositórios Nexus da empresa, há um grande número de componentes compartilhados desenvolvidos internamente - módulos de pagamento, bibliotecas de autenticação, pacotes de ferramentas básicas. Uma vez que uma conta de publicação é comprometida, o invasor só precisa enviar uma "versão atualizada" com um backdoor para o Nexus, e todos os serviços que dependem desse componente serão infectados silenciosamente na próxima construção. Esse tipo de ataque é completamente invisível para os bancos de inteligência externos - os bancos de inteligência monitoram apenas os repositórios de pacotes públicos e não têm consciência dos pacotes internos.

As três direções juntas constituem o contorno completo da superfície de ataque da cadeia de suprimentos de software da empresa hoje. Sem um conjunto de metodologias sistemáticas que cubram essas três direções, qualquer ferramenta de ponto único é apenas uma redução limitada de riscos em uma determinada direção.

IV. Metodologia de Proteção de Segurança da Cadeia de Suprimentos: Um Sistema de Circuito Fechado de Quatro Camadas "Percepção - Interceptação - Inventário - Governança"

A proteção de segurança da cadeia de suprimentos verdadeiramente eficaz é um sistema de circuito fechado de quatro camadas que cobre "percepção - interceptação - inventário - governança", cada camada resolvendo um problema central diferente.

• Primeira Camada: Percepção de Inteligência de Ameaças em Tempo Real

O valor da inteligência reside na precisão e pontualidade. Deve ser preciso ao nível do nome do pacote + número da versão - não "axios tem um risco", mas sim "axios@1.14.1 é malicioso, axios@1.14.0 é limpo". As lógicas de tratamento das duas versões são completamente diferentes, e a inteligência granular é inútil na batalha real.

As fontes de inteligência precisam cobrir três tipos de artefatos:

• Repositórios de pacotes tradicionais (npm / PyPI / Maven / Go / NuGet / Docker Hub, etc.): agregação de múltiplas fontes + análise aprofundada auto-desenvolvida, cobrindo código ofuscado, ganchos de postinstall, carregamento dinâmico de módulos e outras tecnologias de combate.
• Plataformas de Skills de IA (ClawHub / Anthropic Marketplace / skills.sh / GitHub/skills, etc.): Esta é a atual lacuna de proteção da maioria das empresas, que requer cobertura de inteligência especial.
• Alterações anormais em pacotes internos: monitorar eventos ADD/UPDATE do repositório de artefatos e realizar varredura paralela nas alterações de pacotes internos - esta é uma área cega que os bancos de inteligência externos não podem cobrir.

A pontualidade determina a largura da janela de proteção. No final de março de 2026, no evento Axios, a inteligência avançada de ameaças persistentes da SaiXun concluiu a coleta e a rotulagem de ameaças cerca de 41 minutos antes da remoção oficial do pacote malicioso do npm. Esses 41 minutos são a janela crítica que decide entre "protegido" e "infectado".

• Segunda Camada: Interceptação do Nó de Download de Artefatos

O valor da inteligência não está em "ser informado", mas em "ser protegido". Isso requer interceptação no nó físico de download de dependências, em vez de notificação em e-mails de alerta.

Três pontos de interceptação que devem ser cobertos:

• Ponto de Interceptação ① - Proxy do repositório de artefatos: implantar um proxy reverso transparente a montante do Nexus / JFrog Artifactory, os desenvolvedores executam npm install normalmente, todas as solicitações passam pelo mecanismo de decisão de inteligência, se encontrar algo malicioso conhecido, ele será bloqueado, e o código malicioso nunca será executado.
• Ponto de Interceptação ② - Proxy do mercado de plugins VSCode: as solicitações de instalação de plugins VSCode passam pela verificação de inteligência. Há muitos casos reais de plugins maliciosos, mas quase nenhuma empresa tem qualquer proteção neste ponto.
• Ponto de Interceptação ③ - Proxy de Skills de IA / MCP: as solicitações de instalação de Skills de ferramentas de programação de IA passam pela verificação de inteligência. Esta é a superfície de ataque mais recente e difícil de cobrir, e também a direção de risco de crescimento mais rápido.

Para a envenenamento de pacotes internos, a varredura deve ser acionada monitorando eventos do Nexus:

• Novo pacote (ADD) → varredura completa

• Pacote atualizado (UPDATE) → apenas varredura de diferenças de alterações (varredura Diff), reduzindo o consumo de recursos e, ao mesmo tempo, melhorando a pontualidade

• Risco alto detectado: bloquear a publicação + vincular a portões de qualidade CI/CD + reverter automaticamente para a versão anterior

• Terceira Camada: Inventário de Riscos de Ativos Existentes (SBOM)

Ao lidar com eventos repentinos de envenenamento, a primeira dificuldade que muitas empresas enfrentam é:

• Eu simplesmente não sei quais projetos dependem do pacote afetado, qual é a versão.

Esta não é uma falha do sistema de informação, mas o resultado inevitável de não estabelecer um SBOM (Lista de Materiais de Software). O Artigo 6.2 do GB/T 43698—2024 já estabeleceu a construção e manutenção do SBOM como uma obrigação corporativa - cenários de negócios importantes devem conter informações de vulnerabilidade de componentes, atualizadas pelo menos anualmente.

O sistema SBOM precisa suportar a importação de dois formatos padrão SPDX / CycloneDX, e após a importação, ele é automaticamente comparado com o banco de inteligência, produzindo quais projetos têm dependências afetadas, distribuição de versões de risco e cruzando com alertas de interceptação em tempo real.

Com o SBOM, a avaliação do impacto de eventos repentinos de envenenamento pode ser encurtada da verificação manual em horas para a consulta do sistema em minutos.

• Quarta Camada: Governança do Comportamento de P&D - A Mais Difícil e Também a Mais Fundamental

Esta é a camada mais fácil de ser ignorada e também a mais fundamental.

Por mais bem-feitas que sejam as três primeiras camadas, desde que a "via" não seja controlada, elas podem ser facilmente contornadas.

Este não é um cenário hipotético:

• O desenvolvedor executa uma linha npm config set registry https://registry.npmjs.org, contornando completamente o repositório privado da empresa e o gateway.
• A configuração do pipeline CI/CD é negligente, não passando pelo proxy do repositório privado, conectando-se diretamente à rede pública durante a construção.
• A conta de desenvolvimento vaza, e o invasor envia diretamente um pacote interno com um backdoor para o Nexus.

A camada de governança precisa fazer cinco coisas específicas:

• ① Permissões de conta estritamente em camadas (a primeira barreira contra envenenamento interno)

  • Tipo de conta | Escopo de permissão | Significado de segurança
    • dev | Conta de desenvolvimento | Só pode fazer upload de snapshot (versão de teste/desenvolvimento) | Os desenvolvedores não podem enviar release separadamente para produção
    • ci | Conta de construção | Somente leitura, não pode publicar nenhuma versão | A invasão da conta CI não afeta a biblioteca de artefatos
    • deploy | Conta de publicação | A única conta que pode publicar release | Estritamente controlada, isolada do sistema de contas de P&D

• ② Fluxo de tráfego forçado a ser fechado (bloqueando a possibilidade de "contornar")

  • A camada de rede (ZTNA / firewall) bloqueia todos os nomes de domínio originais das fontes de pacotes públicos - os endereços originais npm / Maven / PyPI / Docker Hub são todos interceptados, sem exceção.
  • mirrorOf=* do Maven settings.xml força todas as solicitações a passar pelo Nexus
  • Resultado da não implementação: uma linha de comando de configuração, todas as defesas falham

• ③ Isolamento do ambiente de construção CI/CD (evitando a propagação horizontal do cache)

  • Cada tarefa de construção usa um diretório de cache independente (Maven: -Dmaven.repo.local=/build/.m2/repository; npm: npm config set cache /build/.npm)
  • Proibir que vários nós de construção compartilhem os diretórios ~/.m2 / ~/.npm
  • Resultado da não implementação: um pacote contaminado se espalha horizontalmente para todas as tarefas de construção subsequentes por meio do cache compartilhado, tornando difícil localizar a fonte

• ④ Registro de integridade de artefatos internos (descobrindo "adulteração no quintal")

  • Registro para cada publicação: impressão digital SHA256 + pessoa que publica + IP de origem + ID do Pipeline de construção + carimbo de data/hora
  • Recalcular periodicamente o valor hash dos pacotes armazenados no Nexus e comparar com a linha de base
  • Proibir a entrada de versões de snapshot na produção: detecção automática na fase CI, a construção de violação falha diretamente
  • Resultado da não implementação: o pacote interno é substituído silenciosamente, sem alertas, sem registros, sem rastreamento

• ⑤ Governança da fonte de Skills da cadeia de ferramentas de IA (a mais recente superfície de ataque)

  • Incluir a fonte de Skills de ferramentas de programação de IA (Claude Code / Cursor, etc.) no mesmo nível de sistema de verificação de inteligência que os pacotes de código
  • Controlar de forma unificada por meio de um gateway proxy, sem deixar nenhuma via de exceção

V. Faça um Exame Físico Primeiro: Avalie Rapidamente a Conclusão Atual

Combinado com os requisitos do GB/T 43698—2024, cinco perguntas podem determinar rapidamente o status atual:

• Item de Verificação | Base Correspondente | Concluído?
  • Você construiu um SBOM, sabe o que você usou e quais versões cada projeto depende? | GB/T 43698—2024 §6.2 |
  • Você pode concluir uma avaliação completa do impacto dentro de 1 hora após a divulgação pública de um pacote malicioso? | Ordem do Conselho de Estado nº 834 Artigo 9 |
  • A conta de publicação do repositório privado é estritamente separada da conta de desenvolvimento, e a conta CI é somente leitura? | GB/T 43698—2024 §7.1.3(b) |
  • Os endereços de origem dos pacotes públicos foram bloqueados na camada de rede, e o lado de P&D não pode contornar o repositório privado? | GB/T 43698—2024 §7.2.4(d) |
  • Cada publicação de pacote interno tem um registro de impressão digital SHA256 e rastreamento completo da fonte? | GB/T 43698—2024 §7.2.4(c) |

Esses cinco itens não são "funções avançadas", mas sim os requisitos básicos do GB/T 43698—2024 para as empresas. Na pesquisa real, não há muitas empresas que possam concluir todas as cinco ao mesmo tempo.

VI. Inteligência é o Olho, SOP é o Esqueleto

Há uma analogia que pode resumir o ponto principal deste artigo:

• Inteligência é o olho, controle é a mão, governança é o esqueleto.

O olho diz onde está a ameaça, a mão permite que você a bloqueie, mas o esqueleto determina se todo o sistema de defesa pode ficar de pé - se pode realmente ser implementado.

Sem um esqueleto, por mais bom que seja o olho e por mais rápida que seja a mão, você está construindo um arranha-céu na areia. Um Nexus sem camadas de permissão, um pipeline de CI sem fechamento de fluxo, uma estação de trabalho de desenvolvimento que pode se conectar diretamente à rede pública à vontade, tudo isso pode transformar todos os investimentos anteriores em esforços inúteis.

O GB/T 43698—2024 e a Ordem do Conselho de Estado nº 834, de forma compatível, exigem que as empresas construam esse "esqueleto" - o que na verdade é uma coisa boa. O esqueleto não pode ser construído por um único produto de segurança, ele requer que os departamentos de TI, as equipes de P&D e as equipes de segurança trabalhem juntos para promovê-lo, requer o apoio da gerência e requer a implementação institucionalizada.

A regulamentação já definiu a direção, e a única questão restante é:

• Por onde você começa?

Referência a Regulamentos e Padrões

• Documento | Eficácia | Data de Implementação
  • Ordem do Conselho de Estado da República Popular da China nº 834 "Disposições sobre a Segurança da Cadeia de Indústria e Suprimentos" | Regulamentos Administrativos | 2026-03-31
  • GB/T 43698—2024 "Requisitos de Segurança da Cadeia de Suprimentos de Software para Tecnologia de Segurança Cibernética" | Padrão Nacional | 2024-11-01
  • GB/T 36637—2018 "Tecnologia de Segurança da Informação Diretrizes de Gerenciamento de Riscos de Segurança da Cadeia de Suprimentos de TIC" | Padrão Nacional (citado normativamente pelo anterior) | 2019-05-01

Siga a conta pública: SaiXun Security Verification, responda "regulamentos" para obter os arquivos originais dos regulamentos e padrões acima.

Este artigo é traduzido de [link do artigo original]. Se você deseja republicá-lo, indique a fonte.

Parcerias de negócios e publicação de artigos, entre em contato com anquanke@360.cn

Este artigo é publicado originalmente por SaiXun Technology

Para republicação, consulte a [Declaração de republicação], indique a fonte: [URL do artigo original]

Segurança KER - Nova mídia de segurança com pensamento

Compartilhar para:

• Lei de Segurança Cibernética
• Segurança da Cadeia de Suprimentos
• Prevenção e Controle de Riscos
• Governança de Conformidade
• Lista de Materiais de Software (SBOM)

+1 0 Curtidas Colecionar SaiXun Technology

Compartilhar para:

Deixe um comentário

Você ainda não fez login, faça login primeiro.

Login SaiXun Technology SaiXun Technology | Construindo um sistema de resiliência de negócios digitais inteligente para empresas

Artigos 1 Fãs 0 Artigos de TA A Lei do Conselho de Estado nº 834 foi Implementada: Segurança da Cadeia de Suprimentos de Software, o que as Empresas Realmente Precisam Não São Ferramentas, mas Sim Estas Três Coisas 2026-05-20 17:22:05

Artigos Relacionados A Nova Lei de Segurança Cibernética está prestes a ser implementada. Quais são as mudanças e os pontos-chave? Como as empresas devem fazer uma boa proteção de segurança de dados? 2025-11-26 16:58:57

Boas notícias | A segurança de Xuanjing ganhou o projeto de aquisição de ferramentas de análise de componentes de software SCA da Haitong Securities 2024-12-12 11:28:11

Governança ética e prevenção e controle de riscos de inteligência artificial generativa - um novo caminho para quebrar o dilema de Kolingridge 2024-08-06 23:48:02

Descobriu-se um ataque à cadeia de suprimentos direcionado a usuários do Telegram, AWS e Alibaba Cloud 2023-10-18 11:22:29

O evento de vazamento de dados da Nissan Motors novamente, ou devido à configuração incorreta do provedor de serviços de terceiros 2023-01-19 11:30:01

Segurança cibernética O código de código aberto que você cita pode conter vulnerabilidades 2022-11-07 17:30:35

A primeira revisão da "Lei de Segurança Cibernética" intensifica a supervisão e aumenta a atratividade da indústria de segurança digital 2022-09-22 10:30:36

Recomendado

Índice do artigo

• I. A Regulamentação Chegou, e a Janela de Oportunidade é Curta
• II. Desvios Cognitivos da Maioria das Empresas
• III. A Verdadeira Forma da Superfície de Ataque da Cadeia de Suprimentos: Expansão Simultânea em Três Direções
• IV. Metodologia de Proteção de Segurança da Cadeia de Suprimentos: Um Sistema de Circuito Fechado de Quatro Camadas "Percepção - Interceptação - Inventário - Governança"
  • Primeira Camada: Percepção de Inteligência de Ameaças em Tempo Real
  • Segunda Camada: Interceptação do Nó de Download de Artefatos
  • Terceira Camada: Inventário de Riscos de Ativos Existentes (SBOM)
  • Quarta Camada: Governança do Comportamento de P&D - A Mais Difícil e Também a Mais Fundamental
• V. Faça um Exame Físico Primeiro: Avalie Rapidamente a Conclusão Atual
• VI. Inteligência é o Olho, SOP é o Esqueleto

Referência a Regulamentos e Padrões

Segurança KER

Sobre nós

Entre em contato conosco

Acordo do usuário

Acordo de privacidade

Parcerias de negócios

Conteúdo de cooperação

Informações de contato

Links

Precisa saber o conteúdo

Instruções de envio

Instruções de republicação

Grupo QQ oficial: 568681302

Unidades de cooperação

Copyright © Beijing Qihu Technology Co., Ltd. 360 Digital Security Technology Group Co., Ltd. Segurança KER Todos os direitos reservados

Jing ICP preparado para 08010314 número-66

Código QR do WeChat X