A proteção da sua cadeia de suprimentos de software começa com a descoberta e governança da sua "fábrica de software"
No ambiente de desenvolvimento de software atual, as equipes lidam com ativos descentralizados, como repositórios de código, pipelines de construção e imagens de contêiner. Embora esse modelo distribuído ofereça flexibilidade e acelere a produção, ele também fragmenta ativos e complica a governança e a supervisão de segurança, especialmente à medida que os aplicativos nativos da nuvem se tornam mais difundidos.
Como resultado, as equipes de segurança frequentemente perdem um tempo valioso rastreando proprietários de código para cargas de trabalho de produção órfãs quando surgem problemas de segurança ou quando artefatos de software não sancionados chegam à produção. A cadeia de suprimentos de software se tornou uma superfície de ataque crítica, e é essencial reunir sinais de segurança cedo — do desenvolvimento até os estágios de construção — para evitar pontos cegos e garantir que todos os ativos no Ciclo de Vida de Desenvolvimento de Software (SDLC) sejam monitorados.
As equipes de DevSecOps normalmente não têm ferramentas automatizadas para mapear continuamente esse cenário de desenvolvimento em constante mudança, onde novos caminhos de código e ferramentas são frequentemente introduzidos. As informações geralmente permanecem isoladas em várias plataformas, dificultando o acesso para fins de segurança. As plataformas e ferramentas de desenvolvimento geralmente variam entre o desenvolvimento, a integração e a implantação, à medida que o software é promovido pelos estágios.
Embora os fornecedores de Application Security Posture Management (ASPM) e observabilidade agreguem verificações de segurança, eles geralmente falham em fornecer uma visão completa que conecte os caminhos do código à produção.
A presença de ativos desatualizados agrava o problema. Identificar quais repositórios ainda estão ativos na produção pode ser exaustivo, especialmente para grandes organizações. Fusões e aquisições complicam ainda mais isso ao adicionar diversas plataformas e padrões de desenvolvimento.
As equipes de DevSecOps geralmente recorrem a processos manuais, como preencher manifestos ou etiquetar contêineres, que são tediosos, propensos a erros e muitas vezes deixados de lado em favor de prioridades mais urgentes.
Pense nisso como defender um campo de batalha em constante mudança, onde as equipes de segurança precisam de um mapa preciso para proteger seus ativos. Esses ativos estão sempre se movendo em desenvolvimento, e novos alvos devem ser identificados e protegidos. Para lidar com isso, um mecanismo de descoberta contínua é necessário para mapear as mudanças conforme elas acontecem.
As melhores práticas e estruturas apoiam esta abordagem. Por exemplo, o Agência de Segurança Cibernética e Infraestrutura (CISA) exige que as organizações verifiquem a procedência dos componentes de software e mantenham um inventário abrangente como parte de sua processo de autocertificação. Da mesma forma, Estrutura de desenvolvimento de software seguro do NIST (SSDF) e os votos de Modelo de maturidade OWASP DevSecOps (DSOMM) enfatizar a importância da descoberta e visibilidade contínuas.
No restante desta postagem, descreveremos um plano para abordar esses desafios e explorar como o Scribe Security ajuda as organizações a implementar esses recursos de forma eficaz.
Projeto do Scribe para descoberta eficaz
O Discovery gera um mapa modelado em um gráfico, fornecendo uma visão de ativos, relacionamentos e a postura de segurança da sua fábrica. Isso permite:
- Visibilidade completa e controle de propriedade.
- Recursos de consulta aprimorados.
- Monitoramento de KPIs e métricas de maturidade de segurança.
- Identificação e priorização mais rápidas de fatores de risco.
- Varredura Inicial
A varredura inicial visa criar um mapa de alto nível de ativos, focando na identificação daqueles que exigem análise mais aprofundada. Uma varredura profunda completa pode ser demorada, e muitos ativos, como aqueles não vinculados à produção ou obsoletos, podem ser irrelevantes. Essa varredura inicial normalmente reúne detalhes básicos como nomes de repositórios, IDs e estatísticas de atividade, mas não inclui uma lista completa de confirmações ou contribuidores.
Um método é escanear da “direita para a esquerda”. Ao acessar ambientes de produção (por exemplo, por meio da API do cluster K8s), o scanner pode identificar imagens de contêiner em execução — ativos críticos que refletem o valor comercial. A partir daí, o escaneamento retorna ao registro do contêiner e aos repositórios relevantes. O escaneamento normalmente para aqui, pois geralmente não há conexão direta entre o registro e o pipeline SDLC anterior.
Varreduras complementares podem ser executadas “da esquerda para a direita”, identificando repositórios de código, pipelines de construção e registros em diferentes estágios do SDLC (por exemplo, desenvolvimento, integração, teste).
O resultado é uma lista priorizada de ativos em todas as plataformas, pronta para varredura profunda para rastrear a linhagem do código à produção e avaliar a postura de segurança do SDLC. A priorização é baseada em fatores como relevância para a produção, nível de atividade e atualidade. Às vezes, o conhecimento institucional da significância do ativo ajuda a orientar esse processo.
A varredura inicial pode ser programada periodicamente ou acionada por eventos como pushes de código. Varreduras subsequentes podem aplicar critérios de seleção automática, como usar globs para varredura profunda de ativos recém-descobertos.
- Varredura profunda
Depois que os ativos relevantes são priorizados, a varredura profunda coleta atributos detalhados que estabelecem relacionamentos entre os ativos, como IDs de branch, IDs de commit e committer e IDs de execução de pipeline. A duração dessa varredura pode variar dependendo do escopo dos ativos e dos limites de taxa da API.
Ao final deste estágio, um gráfico de relacionamento de ativos começa a tomar forma, com clusters de ativos conectados em torno de repositórios de código (contendo informações de build) e ambientes de tempo de execução (com ativos de registro). No entanto, uma linhagem completa ainda está incompleta, pois os registros normalmente não armazenam informações sobre os pipelines que enviaram os artefatos de build.
- Conectando os Clusters
Uma vez que o inventário é estabelecido, a linhagem pode ser concluída instrumentando uma ferramenta CLI no pipeline para capturar detalhes de procedência da construção ou processando logs de CI. A instrumentação é o método mais confiável, registrando atributos-chave como IDs de repositório de código, IDs de pipeline e execução e IDs de imagem. Ela vincula clusters previamente isolados de forma eficaz e cria uma linhagem completa de ponta a ponta do código à produção.
Uma abordagem complementar é o processamento de log de CI, que recupera atributos relevantes, mas requer mais recursos e depende do log existente. Embora esse método ofereça uma implementação mais rápida, a combinação de ambas as abordagens produz os melhores resultados — instrumentando pipelines críticos e usando análise de log para os recém-descobertos, que podem então ser avaliados para instrumentação adicional.
Essa abordagem de clustering também considera agregar linhagens separadas em uma estrutura unificada para produtos complexos, como aplicativos web compostos de vários componentes, como microsserviços.
- Lista de materiais de software (SBOM)
Até este ponto, o foco tem sido conectar ativos de desenvolvimento entre plataformas, estabelecendo uma linhagem clara do código para a produção para ativos relevantes. Agora, a atenção muda para a composição dos próprios artefatos de software. Nesta etapa, um SBOM é gerado a partir desses artefatos e seus repositórios de código associados, adicionando-os ao inventário existente.
Ao sintetizar um repositório de código e SBOMs de artefatos em um único SBOM, com lógica para correlacionar dependências e excluir as irrelevantes, como bibliotecas de desenvolvimento e teste, o resultado é um SBOM mais preciso e abrangente do que qualquer fonte poderia fornecer sozinha.
- Postura de segurança e KPIs DevSecOPs
Mapear continuamente o inventário de ativos e seus relacionamentos oferece a melhor oportunidade de avaliar a postura de segurança desses ativos. Os principais fatores incluem permissões de acesso para identidades humanas e não humanas, verificação de assinatura de código, dependências arriscadas ou vulneráveis e configurações de segurança em várias plataformas e contas.
Esses dados podem ser agregados em diferentes dimensões para medir KPIs para lançamentos de produtos, tempos de implantação para produção e maturidade do DevSecOps. Especificamente, ele permite que as equipes avaliem a adoção de controles de segurança, como assinatura de código e adesão às configurações de segurança, ajudando a rastrear o progresso e garantir práticas de segurança robustas.
- Visualização e consulta do SDLC e do gráfico da cadeia de suprimentos de software
Um benefício fundamental do processo de descoberta é a capacidade de visualizar o SDLC e a cadeia de suprimentos de software como um gráfico dinâmico ou “mapa de batalha”. Essa visualização oferece uma visão abrangente de todo o ciclo de vida do desenvolvimento, facilitando o rastreamento de ativos e seus relacionamentos.
O verdadeiro poder vem da capacidade de consultar o gráfico, permitindo que as equipes façam perguntas críticas, como:
- “Qual componente falhou em uma verificação de segurança durante sua construção ou implantação?”
- “Quais cargas de trabalho na produção são órfãs?”
- “Quem cometeu a alteração que introduziu uma vulnerabilidade?”
- “Quem é o dono do ativo que precisa ser corrigido?”
Consultar a linhagem ajuda as equipes a identificar a causa raiz dos problemas, o que é uma vantagem clara sobre a documentação manual. Mapeamentos de propriedade mantidos manualmente rapidamente se tornam desatualizados, muitas vezes levando as equipes de DevSecOps a buscas ineficientes pelos stakeholders certos. Em contraste, um gráfico consultável garante que a propriedade e a responsabilidade estejam sempre atualizadas, reduzindo o tempo desperdiçado rastreando a responsabilidade pelo código ou infraestrutura.
- Opções de implantação para ferramentas de descoberta
As organizações têm necessidades variadas para implantar ferramentas de descoberta, e oferecer opções de implantação flexíveis é essencial para atender a diferentes requisitos de segurança. Algumas equipes preferem acesso remoto por meio de uma plataforma SaaS, simplificando o gerenciamento e o dimensionamento. Por outro lado, equipes com protocolos de segurança mais rigorosos podem escolher a implantação do scanner local para manter um controle mais rígido sobre credenciais confidenciais, como tokens de API da plataforma de desenvolvimento. A escolha entre SaaS e implantação local depende de fatores como a postura de segurança da organização, necessidades de conformidade e controle sobre os dados.
Conclusão
Proteger sua cadeia de suprimentos de software é uma batalha contínua; nenhuma organização deve entrar nela sem um mapa claro. Ao implementar um processo de descoberta robusto, você obtém visibilidade abrangente em seu SDLC e cadeia de suprimentos, garantindo que cada ativo seja contabilizado, do desenvolvimento à produção. Com ferramentas como o blueprint da Scribe Security, você pode construir uma linhagem conectada, gerar SBOMs precisos, avaliar sua postura de segurança e visualizar relacionamentos críticos dentro de seu ecossistema de desenvolvimento. Esse nível de insight capacita as equipes de DevSecOps a identificar vulnerabilidades rapidamente, rastrear suas origens e manter um entendimento atualizado de seu cenário de software — essencial para se manter à frente no ambiente de desenvolvimento complexo e acelerado de hoje.
Escriba oferece uma solução abrangente para descoberta e governança como um facilitador crítico para proteger sua cadeia de suprimentos de software:
- Varreduras iniciais e profundas – Identifica e prioriza ativos como repositórios de código, pipelines e imagens de contêiner em ambientes, criando um inventário de componentes relevantes.
- Linhagem de ponta a ponta – Conecta clusters de ativos isolados usando ferramentas CLI e logs de CI, formando uma linhagem completa do código à produção.
- Lista de materiais de software (SBOM) – Gera SBOMs precisos sintetizando dados de artefatos e repositórios, excluindo dependências irrelevantes.
- Avaliação da postura de segurança – Avalia continuamente controles de acesso, assinaturas de código e dependências vulneráveis para medir KPIs de segurança.
- Visualização e Consulta – Visualiza todo o SDLC e permite consultas para rastrear vulnerabilidades, cargas de trabalho órfãs e propriedade de ativos.
- Implantação flexível – Suporta implantações SaaS e locais para atender a diversas necessidades de segurança e controle sobre dados confidenciais.
Este conteúdo é oferecido a você pela Scribe Security, um fornecedor líder de soluções de segurança de cadeia de suprimentos de software ponta a ponta – fornecendo segurança de última geração para artefatos de código e processos de desenvolvimento e entrega de código em todas as cadeias de suprimentos de software. Saiba mais.
Artigos Relacionados
