A CERT-In (Equipa Indiana de Resposta a Emergências Informáticas), sob a alçada do MeitY (Ministério da Eletrónica e das Tecnologias da Informação), tem vindo a alargar progressivamente o seu papel de autoridade nacional em matéria de cibersegurança desde a sua designação ao abrigo da Lei de Alteração das Tecnologias da Informação de 2008.
Em 2024, o CERT-In emitiu as suas primeiras diretrizes específicas sobre SBOMSoftware Bill of Materials), definindo elementos mínimos, formatos e requisitos de implementação.
Apenas um ano depois, em julho de 2025, a versão 2.0 ampliou significativamente o escopo, estendendo a cobertura para SBOM, QBOM, CBOM, AIBOM e HBOM, estabelecendo ainda mais cadeias de suprimentos de software seguras como uma estratégia de resiliência nacional central.
Para os CIOs e CISOs, estas diretrizes têm consequências operacionais, financeiras e regulamentares. As organizações devem estar prontas para demonstrar práticas de SBOM prontas para auditoria, alinhar fornecedores e parceiros com os requisitos de conformidade e adotar a automação para gerenciar SBOMs em escala.
Este artigo fornece um roteiro passo-a-passo para alcançar a conformidade com as diretrizes CERT-In SBOM, abrangendo o âmbito, as normas técnicas, a seleção de fornecedores e as melhores práticas para empresas indianas e organizações globais com operações na Índia.
- Orientações CERT-In SBOM: Âmbito, aplicabilidade e principais requisitos
- Como é que OPSWAT SBOM ajuda com os requisitos CERT-In
- Alinhamento de componentes Software com a conformidade CERT-In SBOM
- Formatos SBOM e normas técnicas aceites no âmbito da CERT-In
- Como avaliar e selecionar fornecedores de conformidade SBOM
- Melhores práticas para uma implementação perfeita do SBOM
- Automatizar, Cumprir e Proteger: A Abordagem OPSWAT à Gestão de SBOM
- Cadeia de FornecimentoSoftware MetaDefender
- FAQs
- Considerações específicas do sector: Instituições financeiras, Supply Chain e infra-estruturas críticas
- O que vem a seguir? É essencial preparar-se para as diretrizes Cert-In SBOM
Orientações CERT-In SBOM: Âmbito, aplicabilidade e principais requisitos
O que é o CERT-In e porque é que emitiu diretrizes SBOM?
A CERT-In é a agência nacional de cibersegurança da Índia. As suas diretrizes SBOM visam reforçar a segurança da cadeia de fornecimento, melhorar a visibilidade dos componentes de software e garantir respostas mais rápidas e normalizadas às vulnerabilidades.
O que é o CERT-In e porque é que emitiu diretrizes SBOM?
A conformidade aplica-se à administração pública, ao sector público, aos serviços essenciais e aos exportadores de software, bem como aos criadores, integradores e revendedores em todo o ciclo de vida do software.
Elementos Core de uma SBOM de acordo com as diretrizes CERT-In
De acordo com as diretrizes, os OMB devem incluir dados como
- Nome do componente, versão, fornecedor e licença
- Dependências e origem
- Vulnerabilidades e estado das correcções
- Datas de fim de vida útil, restrições de utilização e importância crítica
- Identificadores únicos, somas de controlo e informações sobre o autor
Ao exigir estes elementos mínimos, a CERT-In garante que os SBOM são acionáveis, legíveis por máquina e prontos para auditoria.
Como é que OPSWAT SBOM ajuda com os requisitos CERT-In
OPSWAT SBOM ajuda na automatização e recolha de campos de dados CERT-In SBOM, para proporcionar visibilidade e transparência nas principais áreas, desde detalhes de componentes de software, transparência e riscos, e licenciamento e utilização.
Detalhes do componente de Software
- Nome do componente: Nome do componente de software ou da biblioteca.
- Versão do componente: Número da versão ou identificador do componente.
- Fornecedor de componentes: Entidade que fornece o componente (fornecedor, terceiro ou fonte aberta).
- Origem do componente: Fonte do componente (proprietária, de código aberto ou de terceiros).
- Identificador único: Código distinto para rastrear o componente através de versões e propriedade.
- Autor dos dados SBOM: Entidade responsável pela criação da entrada SBOM.
- Carimbo de data/hora: Data e hora em que a entrada SBOM foi registada.
Transparência e riscos Software
- Dependências de componentes: Outros componentes ou bibliotecas dos quais este componente depende.
- Vulnerabilidades: Problemas de segurança conhecidos relacionados com o componente, com gravidade e referências CVE.
- Estado do patch: Atual atualização ou disponibilidade de correção para vulnerabilidades.
- Checksums ou Hashes: Valores criptográficos para verificar a integridade do ficheiro.
- Propriedade Executável: Se o componente pode ser executado.
- Propriedade de arquivo: Se o componente é empacotado como um ficheiro de arquivo.
- Data de lançamento: Data em que o componente foi lançado pela primeira vez.
Licenciamento e utilização
- Licença do componente: Tipo de licença e termos que regem a utilização do componente.
- Restrições de utilização: Limitações legais ou regulamentares à utilização de componentes.
Alinhamento de componentes Software com a conformidade CERT-In SBOM
Alcançar a conformidade com o CERT-In é um percurso faseado que requer coordenação entre as equipas de desenvolvimento, segurança, operações e conformidade. Cada parte interessada desempenha um papel na criação, manutenção e partilha de SBOMs em diferentes pontos do ciclo de vida do software.
A tabela abaixo, que contém conteúdos e exemplos das Diretrizes Técnicas CERT-In, ilustra a forma como as responsabilidades SBOM se alinham com os componentes de software comuns:
| Software | Exemplo | Nível SBOM | SBOM Autor | Porquê? |
|---|---|---|---|---|
| Aplicação principal | Uma aplicação de análise de dados | SBOM a nível da aplicação | Criado pela equipa de desenvolvimento do produto | SBOM completo entregue com a aplicação ao cliente ou regulador |
| Componente-chave de Software [base de dados, quadro] | PostgreSQL | SBOM de nível superior | Desenvolvido internamente se o fornecedor não forneceu um SBOM | Assegura a rastreabilidade dos componentes críticos |
| Plataforma/Middleware [por exemplo, servidor Web, ambiente de tempo de execução] | Server Apache Tomcat | Entrega SBOM | Fornecido pela plataforma/fornecedor | Partilhado após a aquisição; integra componentes fornecidos pelo fornecedor |
| Bibliotecas/SDKs de terceiros | Postfix e Twilio SDK | SBOM transitivo | Criado pelo fornecedor a montante ou internamente, se não estiver disponível | Abrange as dependências indirectas e os serviços externos |
Com as funções e responsabilidades definidas, as organizações podem avançar para as etapas práticas da conformidade. Um roteiro faseado ajuda a criar maturidade entre pessoas, processos e tecnologia.
1. Efetuar uma avaliação do grau de preparação e uma análise das lacunas
Identificar as práticas atuais para inventário de software, rastreamento de vulnerabilidades e SBOMs fornecidos pelo fornecedor. Compare-as com os campos e formatos de dados exigidos pelo CERT-In.
2. Criar uma política interna de SBOM e uma estrutura de governação
Definir funções claras para os programadores, operações de TI, aprovisionamento, segurança e equipas de conformidade. A governação garante que os SBOMs são criados, mantidos e partilhados de forma consistente em toda a empresa.
3. Selecionar e implementar ferramentas de geração de SBOM
A automatização é crucial. As ferramentas devem:
- Gerar SBOMs para cada nova versão, patch ou atualização
- Integrar com pipelines de DevOps, repositórios de fontes e registos de contentores
- Saída nos formatos CycloneDX e SPDX para alinhamento regulamentar
4. Integrar os fluxos de trabalho SBOM no SDLC e nas aquisições
Incorporar a geração de SBOM em todas as fases do SDLC:
- Conceção SBOM: componentes planeados
- Fonte SBOM: dependências de desenvolvimento
- Construir SBOM: durante a compilação
- SBOM analisado: inspeção pós-construção
- SBOM implantado: ambiente instalado
- SBOM em tempo de execução: monitorização de componentes activos
Os contratos de aquisição devem obrigar todos os fornecedores a entregarem o SBOM.
5. Manter a conformidade contínua e a prontidão para auditorias
Estabeleça actualizações contínuas do SBOM, integre-o com avisos de vulnerabilidade como o VEX (Vulnerability Exploitability eXchange) e o CSAF e garanta o armazenamento e a partilha seguros através de encriptação, HTTPS e assinaturas digitais.
Quer saber como tirar partido do SBOM para a sua estratégia de segurança?
Formatos SBOM e normas técnicas aceites no âmbito da CERT-In
CycloneDX e SPDX: Os padrões aceites
O CERT-In reconhece o CycloneDX e o SPDX como os principais formatos legíveis por máquina para a automatização do SBOM.
- CycloneDX: Leve, centrado na segurança, optimizado para a gestão de vulnerabilidades
- SPDX: centrado na licença, amplamente adotado para documentação de conformidade
Como avaliar e selecionar fornecedores ou soluções de conformidade CERT-In SBOM
A seleção do fornecedor ou da solução correta é fundamental para a conformidade e a eficiência operacional.
Critérios-chave para avaliar fornecedores de conformidade CERT-In SBOM
- Suporte para SPDX e CycloneDX
- Integração com pipelines DevOps e fluxos de trabalho CI/CD
- Capacidade de gerar vários níveis de SBOM (conceção, construção, implantação, tempo de execução)
- Relatórios prontos para auditoria e mecanismos de partilha seguros
Perguntas a fazer a potenciais fornecedores sobre o alinhamento CERT-In
Selecionar os parceiros certos é tão importante como criar processos SBOM internos. Os CIOs e líderes de compras devem incluir o alinhamento com o CERT-In como parte de suas listas de verificação de RFP e due diligence. As principais perguntas a serem feitas incluem:
- Fornecem SBOMs em formatos aprovados pelo CERT-In (SPDX, CycloneDX)?
- Com que frequência os seus SBOMs são actualizados - apenas no lançamento ou continuamente?
- Que automatização oferecem para a criação, validação e partilha segura de SBOM?
- Como é que impõe a distribuição segura do SBOM (por exemplo, encriptação, RBAC, assinaturas digitais)?
- A sua solução integra-se com pipelines DevOps, bases de dados de vulnerabilidades e avisos CERT-In?
- Como é que apoia as auditorias de conformidade e os relatórios regulamentares em curso?
Fazer essas perguntas antecipadamente ajuda a garantir que os fornecedores não estejam apenas em conformidade no papel, mas que sejam capazes de sustentar práticas de SBOM alinhadas com as diretrizes em evolução do CERT-In.
Lista de verificação para seleção e integração de fornecedores
- Suporta os campos e formatos de dados exigidos pelo CERT-In
- Automatiza a criação, o acompanhamento e as actualizações
- Fornece controlos de acesso baseados em funções e partilha segura
- Adoção comprovada em sectores regulamentados
Melhores práticas para uma implementação perfeita do SBOM
Estratégias comprovadas para grandes empresas
- Comece com fluxos de trabalho básicos e aumente a maturidade ao longo do tempo
- Obrigar a entrega de SBOM em todos os contratos públicos
- Adotar uma abordagem shift-left, integrando a geração de SBOM no início do SDLC
- Formar o pessoal em matéria de sensibilização para a SBOM e para os requisitos regulamentares
Erros comuns e como evitá-los
Mesmo as iniciativas SBOM bem-intencionadas podem falhar se as organizações as abordarem superficialmente. O CERT-In enfatiza que os SBOMs devem ser precisos, abrangentes e continuamente atualizados. Aqui estão algumas das armadilhas mais comuns e como evitá-las:
| Erro comum | Explicação | Como evitá-lo |
|---|---|---|
| Tratamento do SBOM como um relatório estático | Muitas organizações geram um SBOM no lançamento e nunca o actualizam. Isto deixa-as cegas para as vulnerabilidades introduzidas por patches, actualizações ou novas dependências. | Trate o SBOM como um inventário vivo. Automatize as atualizações por meio do pipeline de CI/CD para que cada nova compilação ou versão atualize os dados do SBOM. |
| Não inclusão de dependências transitivas | A não consideração de componentes indirectos, como bibliotecas de código aberto obtidas através de outras dependências, cria pontos cegos perigosos que os atacantes exploram. | Utilize ferramentas automatizadas de geração de SBOM que mapeiam recursivamente todas as dependências diretas e transitivas, assegurando uma cobertura total da sua cadeia de fornecimento de software. |
| Confiar na criação manual sem automatização | A compilação manual de SBOM é demorada, propensa a erros e insustentável à escala empresarial. Além disso, aumenta o risco de formatos inconsistentes. | Integrar automação e padronização. Adotar ferramentas que geram SBOMs em formatos aprovados pelo CERT-In, como SPDX e CycloneDX, e impor a validação antes do lançamento. |
Ao evitar estes erros e incorporar as práticas SBOM nos fluxos de trabalho de desenvolvimento diários, as organizações podem transformar a conformidade numa vantagem estratégica, reduzindo o risco e cumprindo os requisitos CERT-In.
Preparação para auditorias
Manter repositórios SBOM completos, documentar práticas de governação e alinhar-se com os modelos de auditoria CERT-In.
Preparar o futuro para as alterações regulamentares
O roteiro do CERT-In já sugere requisitos de BOM mais amplos (hardware, IA e nuvem). As empresas que adotarem ferramentas escaláveis e flexíveis estarão melhor posicionadas para se adaptarem.
Automatizar, Cumprir e Proteger: A Abordagem OPSWAT à Gestão de SBOM
OPSWAT SBOM
OPSWAT SBOM capacita os programadores ao fornecer um inventário preciso dos componentes de software no código-fonte e nos contentores. Mantenha-se à frente dos atacantes, descubra ameaças e detecte vulnerabilidades sem afetar a velocidade de desenvolvimento.
SBOM para pacotes e artefactos Software
Permite que as equipas de desenvolvimento de software identifiquem, priorizem e resolvam as vulnerabilidades de segurança e as questões de licenciamento das dependências de código aberto.
SBOM para pacotes e artefactos Software
Permite que as equipas de desenvolvimento de software identifiquem, priorizem e resolvam as vulnerabilidades de segurança e as questões de licenciamento das dependências de código aberto.
SBOM para imagens Container
Analisar imagens de contentores e gerar SBOM para o nome do pacote, informações da versão e potenciais vulnerabilidades.
MetaDefender Software Supply Chain™
Vá além da conformidade com o SBOM e aborde os ataques avançados e em evolução da cadeia de fornecimento de software.
OPSWAT MetaDefender Software Supply Chain fornece uma visibilidade alargada e uma defesa robusta contra os riscos da cadeia de fornecimento. Com as nossas tecnologias de deteção e prevenção de ameaças de confiança zero, o seu ciclo de vida de desenvolvimento de software (SDLC) está protegido contra malware e vulnerabilidades, reforçando a segurança das aplicações e a adesão à conformidade.
Detetar malware no código
A combinação de mais de 30 motores antivírus aumenta as taxas de deteção e impede eficazmente que o malware infecte estações de trabalho, contentores ou código-fonte.
Identificar segredos codificados
O Proactive DLPTM identifica credenciais como senhas, segredos, tokens, chaves API ou outras informações confidenciais deixadas no código-fonte.
Contentores Secure contra ataques Supply Chain
Avaliar e analisar qualquer malware, vulnerabilidades ou outros riscos potenciais existentes sob cada camada de uma imagem de contentor.
Integrações simplificadas
Quer a sua equipa utilize repositórios de código-fonte, registos de contentores, serviços binários ou uma combinação de ferramentas,Supply Chain Software MetaDefender fornece integrações nativas com plataformas populares para proteger todo o seu SDLC.
FAQs
Que sanções se aplicam em caso de incumprimento das orientações da CERT-In SBOM?
Auditorias regulamentares e possíveis restrições em contratos com o governo e serviços essenciais. A não conformidade com as diretrizes CERT-In SBOM pode deixar as organizações vulneráveis a violações de dados, o que pode levar a multas pesadas.
Com que frequência devem ser actualizados os SBOM?
Em cada nova versão, atualização, correção ou mudança de fornecedor.
Podem ser incluídos componentes de código aberto e de terceiros?
Sim. É obrigatória a visibilidade total de todas as dependências - diretas e transitivas.
As empresas mais pequenas estão isentas?
As empresas em fase de arranque fora dos sectores regulamentados podem ter uma ajuda limitada, mas a adoção é fortemente encorajada.
Como é que o CERT-In se alinha com as normas globais?
A abordagem da Índia reflecte quadros internacionais como o NIST e o Cyber Resilience Act da UE, assegurando a compatibilidade transfronteiriça.
Como devem ser tratadas as divulgações de vulnerabilidades?
Através de avisos VEX e CSAF, integrados com alertas CERT-In e sistemas SBOM internos.
Que papel desempenha a automatização?
A automatização permite uma conformidade contínua, reduz os erros humanos e garante a escalabilidade em ambientes de TI híbridos.
Considerações específicas do sector: Instituições financeiras, Supply Chain e infra-estruturas críticas
Sector financeiro
Os bancos e as NBFC devem alinhar as práticas SBOM com os mandatos de cibersegurança do RBI, com requisitos de auditoria mais rigorosos para o tratamento de dados sensíveis.
Supply Chain
Os fornecedores devem entregar SBOMs como parte dos contratos. As organizações devem manter inventários internos e externos de SBOM para transparência e gestão de riscos.
Infra-estruturas críticas
Sectores como as telecomunicações, a defesa e a energia enfrentam sobreposições regulamentares. As práticas de SBOM devem integrar-se em quadros mais alargados de resiliência do sistema e segurança nacional.
O que vem a seguir? É essencial preparar-se para as diretrizes Cert-In SBOM
As diretrizes CERT-In SBOM marcam um ponto de viragem para as empresas indianas. O que começou como um foco restrito nos SBOMs expandiu-se agora para uma estrutura abrangente para a visibilidade da cadeia de fornecimento de software e gestão de riscos.
A tecnologia SBOM OPSWAT vai além da conformidade, incorporando a visibilidade da cadeia de fornecimento em todo o SDLC e integrando a segurança em várias camadas com repositórios de código, registos de contentores e pipelines DevOps.
Descubra como OPSWAT pode ajudar a sua empresa a simplificar a conformidade com o CERT-In SBOM e a proteger a sua cadeia de fornecimento de software.
