Mais do que Segurança: Por Que Controlar as Dependências é Crucial

64K+ Alcance em 30 dias Positive Technologies 4,21 Avaliação do empregador 324,48 Classificação 118 771 Assinantes Assinar 6a6legum 21 minutos atrás Mais do que Segurança: Por Que Controlar as Dependências é Crucial 11 min 851 Blog da empresa Positive Technologies Segurança da Informação * Software Infraestrutura de TI * DevOps * Opinião Olá, Habr! Meu nome é Artyom Berdashkevich e lidero a área de DevSecOps na Positive Technologies. Hoje, quero discutir um tópico que se torna cada vez mais relevante a cada ano: o controle de dependências e por que as abordagens tradicionais não são mais suficientes. O desenvolvimento moderno há muito se transformou em uma montagem de componentes prontos, onde quase não escrevemos código do zero, mas combinamos frameworks, bibliotecas e módulos de código aberto. Essa abordagem acelera radicalmente a entrada de produtos no mercado, mas a velocidade tem um preço: a transparência. A equipe geralmente não sabe a composição exata de seu aplicativo até a compilação final. Por que isso se tornou um grande problema e o que fazer a respeito - leia neste artigo. Conteúdo Transparência, licenças e ordem como as três dores de cabeça eternas do desenvolvimento 8 milhões de razões para começar a controlar agora mesmo Três estágios de maturidade do SCA: do scanner manual à arquitetura Estágio um: varredura ad-hoc Estágio dois: varredura em pipeline Estágio três: arquitetura de um processo maduro Como funciona o controle de dependências maduro Firewall de dependências e seis camadas de verificação SBOM e sua evolução: de um JSON a um sistema de conhecimento Recursos de implementação fora de Python, Go e Java Arquivos binários e arquivos prontos Imagens Docker e o problema de External Refs Compromisso em vez de ideal Chefe final: três problemas não resolvidos do DevSecOps A maldição do legado Restrições funcionais Dependências transitivas: o dilema arquitetônico O que se segue Transparência, licenças e ordem como as três dores de cabeça eternas do desenvolvimento A falta de transparência na cadeia de suprimentos de código não é novidade. As equipes enfrentam as mesmas dificuldades há anos: Encontrar vulnerabilidades potenciais. Bibliotecas com CVEs conhecidos podem estar na base de código, e a equipe pode nem estar ciente disso até que um incidente ocorra. Manter a conformidade de licença. Um componente adicionado acidentalmente com uma licença viral pode criar riscos legais para todo o produto. Colocar ordem no desenvolvimento. Quando há dezenas e centenas de dependências, sem contabilidade sistemática, começa o caos, no qual é impossível entender o que veio de onde e se é necessário atualizar. A indústria criou uma classe separada de ferramentas - Software Composition Analysis (SCA) - para responder a esses desafios, para analisar a composição do software. O SCA compara as versões das bibliotecas com as bases de dados CVE, controla as licenças e ajuda a transformar o caos das dependências em um registro gerenciado. Isso soa como uma solução pronta, mas o diabo está nos detalhes. Para entendê-los, vamos começar com a escala do problema. Oito milhões de razões para começar a controlar agora mesmo A imagem real é fácil de subestimar até que você olhe para os números. Para ilustração, vamos imaginar que temos um fornecedor com um portfólio de 25 produtos. Cada produto existe em cinquenta versões, e cada versão tem 25 componentes. Um componente arrasta consigo cinquenta dependências diretas, e cada uma delas cresce com mais cinco transitivas - aquelas que são necessárias para o funcionamento das próprias bibliotecas. A aritmética simples produz quase 8 milhões de entidades que exigem controle. Agora, vamos supor que uma vulnerabilidade de alta classificação ou a chamada backdoor, ou seja, código malicioso adicionado intencionalmente, seja encontrada em uma das bibliotecas populares. A equipe enfrenta a tarefa de: encontrar todos os produtos e versões afetados, determinar como o código vulnerável chegou lá e entender o que atualizar especificamente. Sem um sistema SCA construído, o caos começa neste momento. Os desenvolvedores revisam manualmente os commits antigos no GitLab, tentando restaurar a imagem, e o ciclo de lançamento para. Dias ou até semanas são gastos na busca, e isso, como regra, não adiciona clareza. É por isso que o SCA há muito ultrapassou o modesto papel de utilitário para o departamento de segurança da informação. Hoje, é a base para um desenvolvimento gerenciado e previsível. Por que você precisa de SCA A necessidade interna de ordem recebeu apoio externo com o tempo: reguladores através da GOST R 56939, ordens da FSTEC e leis federais sobre a segurança da KII metodicamente transformam o SCA de uma prática útil em um requisito obrigatório para todos cujo código funciona em segmentos sensíveis da infraestrutura. No entanto, apenas os requisitos formais não são suficientes, porque para entender como abordar a tarefa na prática, é útil primeiro avaliar o nível de sua maturidade. Como regra, as empresas passam por três estágios naturais, e em cada um deles as ferramentas e o pensamento da equipe mudam. Três estágios de maturidade do SCA: do scanner manual à arquitetura A implementação do controle de dependências quase nunca ocorre de uma só vez. As empresas passam por estágios naturais de evolução. Estágio um: varredura ad-hoc A maneira mais fácil e natural de começar é pegar um scanner pronto e executá-lo localmente. O engenheiro pega o Trivy ou uma ferramenta semelhante, executa uma imagem ou repositório através dele e recebe um artefato com os resultados, e então esse relatório voa para algum lugar no correio ou bate-papo para os responsáveis. O método é semi-manual, requer disciplina e atenção constante, mas é suficiente para projetos piloto e um pequeno número de componentes. Os problemas começam com o aumento do número de serviços e a frequência das compilações, quando a execução manual se torna um gargalo. Estágio dois: varredura em pipeline O próximo passo é integrar o scanner ao CI/CD. Neste estágio, um estágio separado é alocado, no qual cada contêiner Docker ou artefato montado é executado através de uma ferramenta de análise de dependências. Parece progressivo, mas na prática muitas vezes se transforma em um cemitério gigante de arquivos. Quando você tem mil e quinhentos a dois mil pipelines e um JSON com um relatório Trivy anexado a cada um, o desenvolvedor é fisicamente incapaz de visualizá-los todos. Como resultado, a maior parte da equipe simplesmente ignora esses artefatos até que os seguranças venham com outra auditoria. Estágio três: arquitetura de um processo maduro As empresas que passaram pelos dois primeiros estágios chegam à compreensão de uma verdade simples. SCA não é um utilitário ou um estágio no pipeline, mas uma arquitetura distribuída de vários componentes interconectados. Cada um deles resolve sua tarefa clara e passa os dados para o próximo. De onde o controle de dependências começou e em que ele "amadurece" Tal sistema permite não apenas encontrar problemas, mas também evitar seu aparecimento, investigar incidentes e dar respostas rápidas às perguntas de reguladores e clientes. Como funciona o controle de dependências maduro Como resultado de passar por todos esses estágios de ferramentas dispersas, você deve obter uma única arquitetura: o firewall filtra a entrada, o SBOM corrige a composição, o enriquecimento adiciona contexto, a árvore conecta componentes a produtos e o security gate não permite código duvidoso no lançamento. De toda essa estrutura, analisaremos os dois elementos mais importantes: o firewall de dependências e o processo de trabalho com o SBOM. Firewall de dependências e seis camadas de verificação O repositório moderado, também conhecido como firewall de dependências, funciona com uma lógica simples e rígida. Tudo o que o desenvolvedor quer trazer do mundo exterior primeiro entra na zona de quarentena, passa por uma série de verificações e só depois acaba no repositório interno da empresa. Quais verificações faz sentido incorporar a este pipeline? O conjunto cresce à medida que o processo amadurece, mas a configuração minimamente viável é assim. A primeira e mais óbvia barreira é a verificação de vulnerabilidades conhecidas. O mecanismo extrai o nome do pacote com a versão e os compara com a base de dados CVE. A segunda camada é a análise dinâmica em uma sandbox. O pacote ou imagem é implantado em uma máquina virtual, onde é verificado por antivírus e analisadores comportamentais. A terceira etapa é cada vez mais o PoliticSearcher - uma análise recursiva de pacotes e arquivos para menção de slogans políticos. A lógica é simples: se alguma agitação política for encontrada dentro da biblioteca, então, com alta probabilidade, também haverá uma backdoor maliciosa. A quarta verificação é a análise estática de todos os componentes dependentes. A maioria das equipes não precisa desta etapa, mas os desenvolvedores de ferramentas de proteção de informações são obrigados a executar SAST em todos os componentes do produto, incluindo o mesmo PostgreSQL em sua composição. O requisito é rígido e acarreta um cluster separado para moer o código-fonte. O quinto item diz respeito à conformidade de licença. Ao entrar no mercado internacional, o risco de ações judiciais por violação dos termos da licença aumenta significativamente. Portanto, é importante evitar que bibliotecas com uma licença duvidosa entrem no produto, mesmo no estágio de um repositório moderado. A sexta, a camada final, é a verificação usando modelos de ML. O aprendizado de máquina funciona como o terceiro nível de busca de backdoors após a "areia" e o PoliticSearcher. SBOM e sua evolução: de um JSON a um sistema de conhecimento Suponha que o firewall esteja configurado e funcionando perfeitamente, o que significa que tudo está limpo na entrada. Mas o que acontece com os componentes mais tarde, quando eles já estão dentro do produto? Aqui, o Software Bill of Materials (SBOM) entra em cena - um documento que descreve de quais componentes e dependências seu aplicativo consiste. Inicialmente, o SBOM foi concebido como um formato universal para uma lista estruturada de dependências. Independentemente de onde seu componente está localizado - em uma imagem Docker, em requirements.txt para Python ou em package-lock.json - o SBOM traz tudo para um único JSON com sintaxe clara e campos idênticos. A ideia é simples: todas as ferramentas trocam informações em uma linguagem. O mercado percebeu rapidamente que o potencial do formato é muito maior. O SBOM pode ser transferido para o regulador para que ele verifique a composição do produto sem acesso ao código-fonte. Ele também pode ser reutilizado dentro da empresa para não escanear os mesmos componentes com ferramentas diferentes pela segunda vez. E também se transformou em um padrão de interação entre os participantes da cadeia de suprimentos - na verdade, uma linguagem universal para troca de dados sobre dependências. Em seguida, surgiram requisitos adicionais: A coisa mais simples é encontrar vulnerabilidades conhecidas. Diferentes mecanismos com diferentes bases de dados CVE resolvem essa tarefa de forma aproximadamente semelhante: eles pegam a lista de componentes do SBOM e destacam as versões problemáticas. A segunda camada é o enriquecimento com metainformações. Um bom SBOM responde não apenas à pergunta "o que está dentro", mas também às perguntas "de onde veio" e "quem o construiu". A terceira função são as external references. É importante para o regulador entender se você está construindo o componente sozinho ou pegando um binário pronto de terceiros. Assim, sem eles, o OpenSSL "forkado" e o original parecem idênticos, embora o nível de confiança neles seja fundamentalmente diferente. O quarto mecanismo é a divisão em "seu" e "estrangeiro". Quando há cento e cinquenta dependências no produto, sem uma marca especial, não está claro o que é desenvolvido dentro da empresa e o que veio de fora. O regulador exige análise estática de tudo o que você compilou, e sem essa divisão você nem formará um plano de verificação correto. O quinto e mais procurado elemento na prática é a busca por componentes. Ele resolve exatamente o problema dos oito milhões de dependências de que falamos no início. Quando chega a notícia de uma backdoor em uma biblioteca específica, a busca mostra em segundos todos os produtos e versões afetados. Esta é a aparência de nossa própria ferramenta para trabalhar com SBOM - aqui você pode ver a árvore e vários componentes com metainformações sobre a compilação Todos os cinco elementos juntos criam um sistema no qual o SBOM desempenha o papel de uma base de conhecimento "viva" sobre o produto. Em seguida, veremos como essa teoria colide com a realidade da pilha de tecnologia, onde, além de Python e Go, existem arquivos binários, arquivos e imagens Docker com suas próprias características. Recursos de implementação fora de Python, Go e Java Com as linguagens modernas - Python, Go, JavaScript - tudo funciona de forma previsível. Os gerenciadores de pacotes e os arquivos familiares a todos dão uma imagem completa das dependências, a compilação do SBOM é automatizada e a execução através do firewall para esses projetos não causa dúvidas. No entanto, fora dessa pilha, há cenários mais complexos. Arquivos binários e arquivos prontos O mecanismo de um repositório moderado é otimizado para gerenciadores de pacotes, e aqui as abordagens tradicionais estão emperrando. Como executar um binário compilado através da quarentena? De acordo com qual princípio dividir as dependências dentro do arquivo com dezenas de componentes? E você precisa dividi-lo em partes ou pode verificar com um bloco monolítico? A indústria ainda não deu uma resposta definitiva, e cada equipe está inventando sua própria abordagem. Imagens Docker e o problema de External Refs As coisas são ainda mais interessantes com as imagens Docker. Digamos que executemos a imagem através do firewall e encontremos Bash dentro dela. Agora você precisa decidir o que especificar no SBOM como a fonte: um link para o repositório da própria imagem, o código-fonte do Bash ou um arquivo binário específico. Essa escolha determina em grande parte o quão transparente a cadeia de suprimentos será no futuro. É curioso que a própria bifurcação aqui não seja tanto técnica quanto metodológica. Se você deseja controlar a integridade do contêiner montado, anexa a external ref ao repositório da imagem. Se for mais importante rastrear vulnerabilidades em componentes independentemente da embalagem, você desce para o nível do código-fonte ou arquivos binários dentro do contêiner. Compromisso em vez de ideal Os recursos de arquivos binários e imagens Docker levam a um pensamento simples: perseguir a cobertura de cem por cento de toda a pilha de tecnologia com um esquema ideal - significa desperdiçar recursos. A prática mostra que é muito mais útil definir honestamente os limites do que você realmente cobre e corrigir explicitamente as exceções. Em qualquer base de código séria, haverá scripts escritos internamente que baixam binários por máscara do repositório interno e que nenhum scanner padrão como o Trivy saberá. A equipe deve estar ciente de tais casos separadamente e processá-los com seu próprio processo. A corrida pela automação completa geralmente desvia a atenção de problemas muito mais fundamentais. Chefe final: três problemas não resolvidos do DevSecOps Depois de construir um firewall de dependências, configurar a compilação do SBOM e enriquecer os artefatos com metainformações, chega um momento sóbrio. Acontece que algumas das perguntas ainda não têm respostas estabelecidas, mesmo entre os líderes da indústria. Esses problemas devem ser discutidos abertamente, porque silenciá-los cria uma falsa sensação de que você é o único a enfrentá-los. Destacamos três desafios principais. A maldição do legado O primeiro e mais doloroso problema é o legado. Em qualquer produto maduro, existem componentes, arquivos binários e imagens Docker que surgiram muito antes da introdução do SCA. O firewall está configurado, o SBOM para o novo código é compilado corretamente, mas a camada antiga permanece descoberta, e é quase impossível separar "seu" e "estrangeiro" para código sem referências externas e metainformações. O mercado ainda não ofereceu uma abordagem universal, e cada equipe está inventando sua própria arquitetura. As mesmas caixas de seleção em nossa ferramenta Por exemplo, criamos uma interface que sistematiza tudo o que passou pela moderação do firewall e marca os componentes com caixas de seleção. Sem uma "caixa de seleção" - vamos descobrir manualmente. Mas este método cobre apenas uma pequena parte do legado, e uma solução completa ainda está por vir. Restrições funcionais O segundo bloco de problemas está relacionado a restrições que ninguém realmente calibrou. Adicionando cada vez mais verificações a repositórios moderados e ao processo de enriquecimento do SBOM, atingimos três perguntas sem respostas prontas - elas só são obtidas empiricamente até agora. A primeira pergunta é a largura de banda. O desenvolvedor quer atualizar cento e cinquenta pequenos pacotes JavaScript de uma vez, mas não se sabe de antemão se o firewall é capaz de processar esse volume sem degradação. A segunda diz respeito ao tempo de verificação permitido. A abordagem idealista de "gastar o tempo necessário" quebra a realidade: se uma dependência for verificada por um dia, o desenvolvimento simplesmente para. A terceira é o consumo de recursos. A "areia", que executa todos os componentes em uma linha, é capaz de consumir uma parte perceptível da capacidade do data center, e em que momento os custos deixam de ser justificados, cada equipe calcula por conta própria. Dependências transitivas: o dilema arquitetônico O terceiro problema é quase de natureza filosófica. Os desenvolvedores costumam puxar uma dependência de nível superior, sem se interessar pelo seu conteúdo. O firewall verifica o framework em todos os critérios - CVE, licenças, sandbox, PoliticSearcher - e o permite. No entanto, dentro do framework, há uma dependência transitiva que não passa em nenhum desses critérios. O que fazer? Você pode, por exemplo, ignorar as dependências transitivas e verificar apenas o que conectamos diretamente. Mas então o código malicioso penetra com segurança no circuito. A segunda opção é executar todas as dependências transitivas em listas separadas e bloqueá-las em caso de não conformidade com as políticas. Os desenvolvedores não gostam dessa abordagem, porque a simples adição de uma biblioteca se transforma em uma coordenação de várias horas. A situação fica ainda mais confusa quando a mesma dependência na composição de diferentes frameworks se comporta de forma diferente: em algum lugar ela passa nas verificações e em outro não. O que se segue O controle de dependências começa com a conscientização da escala do problema e, com uma abordagem sistemática, cresce em uma arquitetura completa de um firewall, SBOM e camadas de verificação. No artigo, examinamos como esses mecanismos funcionam, quais recursos as equipes enfrentam ao trabalhar com arquivos binários e imagens Docker e quais perguntas ainda não foram respondidas. De tudo isso, uma imagem simples se forma: SCA não é um produto que pode ser implementado e esquecido uma vez, mas um processo vivo. Ele requer configuração para uma pilha de tecnologia específica, revisão regular de políticas e atenção aos detalhes que não são descritos em nenhum GOST. Ao mesmo tempo, mesmo as equipes mais avançadas continuam a procurar respostas para algumas perguntas - e isso é normal, porque a indústria ainda está em movimento. Todos os três problemas têm algo em comum - eles não são resolvidos por uma ferramenta ou outra versão do scanner. Estes são desafios arquiteturais e metodológicos que exigem esforços conjuntos de toda a comunidade profissional. Portanto, se você já os encontrou em seu trabalho e encontrou alguma solução - conte nos comentários! Tags: cybersecurity devsecops sca legacy dependências cve desenvolvimento seguro docker sandbox appsec Hubs: Blog da empresa Positive Technologies Segurança da Informação Software Infraestrutura de TI DevOps +1 1 1 64K+ Alcance em 30 dias Positive Technologies Telegram VKontakte 1 Karma Berdashkevich Artyom @6a6legum DevSecOps TeamLead Assinar O fluxo de Segurança da Informação está disponível 24 horas por dia, 7 dias por semana, graças ao apoio dos amigos do Habr Habr Cursos para todos PUBLICIDADE Praticum, Hexlet, SkyPro, cursos do autor - reunimos todos e pedimos descontos. Resta escolher! Ir Ir para o fluxo de Segurança da Informação Comentários 1 Melhor do dia Semelhante