Por que o ASPM pede uma abordagem independente: o papel do ASPM vs CNAPP

Por Jimmy Xu, Field CTO na Cycode

O crescimento exponencial do código, uma superfície de ataque ingerenciável como resultado de nuvem + DevOps, ciclos de desenvolvimento acelerados e a proliferação de ferramentas sobrecarregaram as equipes de desenvolvimento e de segurança. Isso tornou impossível identificar e remediar com eficácia os problemas mais críticos e de maior impacto, com o tempo e os recursos limitados que as organizações têm.

A segurança de aplicação continua evoluindo, porque práticas modernas de desenvolvimento e a adoção cloud-native (como conteinerização, Infrastructure-as-Code (IaC) e GitOps) borraram a linha entre aplicação e infraestrutura. Como resultado, a segurança de aplicação continua convergindo com a segurança de nuvem.

Soluções pontuais que só entregam capacidades parciais, como varrer código customizado e bibliotecas open source, já não bastam para identificar e analisar o risco de forma holística no ciclo de vida de desenvolvimento de software (SDLC), e deixam lacunas críticas na cobertura de segurança. Ter várias soluções pontuais, muitas vezes de equipes diferentes, também leva à duplicação de esforços e faz quem desenvolve se afogar na confusão sobre o que corrigir e em quem confiar.

Está claro que uma solução de plataforma é necessária para cobrir todas as camadas do ciclo de vida de uma aplicação e dar um contexto agregado de risco em todos os achados, conforme eles atravessam o SDLC até o destino final. Essa solução de plataforma deve identificar e reunir todo o contexto de risco de várias capacidades ao longo do SDLC e gerar orientação de remediação acionável. A solução de plataforma também deve unir stakeholders de desenvolvimento, operações e segurança, que muitas vezes operam em silos.

É aqui que entra o Application Security Posture Management (ASPM).

Inclusivo e transformador, o ASPM foi desenhado para unificar soluções pontuais e proteger tudo o que acontece no desenvolvimento. Isso, por sua vez, ajuda quem desenvolve a levar ideias para produção com segurança.

Isso é parecido com o que as Cloud Native Application Protection Platforms (CNAPP) foram desenhadas para fazer: unificar soluções pontuais para proteger tudo o que acontece na nuvem.

Neste post, vamos ver o que é ASPM, como evoluiu ao longo do tempo (também conhecido como as três ondas), as diferenças-chave entre ASPM e CNAPP, por que o ASPM deve continuar independente e o que buscar numa plataforma de ASPM independente e completa.

As definições de ASPM vs CNAPP¶

O que é ASPM?¶

ASPM é uma abordagem unificada para identificar e gerir riscos de forma holística, com visibilidade, priorização e capacidade de remediação em todo o SDLC. O ASPM foi desenhado para dar às equipes de segurança cobertura completa e permitir que descubram problemas no desenvolvimento com rapidez e precisão. Também ajuda quem desenvolve, sob pressão constante para entregar código mais rápido, a priorizar riscos com contexto completo e a tomar as ações certas.

Na Cycode, definimos ASPM como uma solução completa que oferece cobertura total para descobrir e identificar riscos de forma holística em todo o SDLC. A solução deve cobrir todos os artefatos de código nas diferentes etapas do SDLC, venham de dentro ou de uma cadeia de suprimentos de terceiros, os sistemas de pipeline de build e implantação conforme o código atravessa o processo do SDLC e, por fim, a própria implantação, onde o software empacotado roda, seja qual for o destino: nuvem, on-prem ou infraestruturas híbridas.

Ao contrário de soluções pontuais que focam só em capacidades específicas, como segredos, cadeia de suprimentos ou teste de segurança de aplicação (SAST, DAST, SCA), uma plataforma de ASPM completa integra todas essas capacidades, ampliadas e enriquecidas pelas suas próprias capacidades nativas. Ela é ampliada e enriquecida pelas suas próprias capacidades nativas, numa interface única e unificada que agrega, contextualiza e prioriza riscos facilmente acionáveis por quem desenvolve.

É importante notar que o mercado de ASPM ainda é inicial, e nem todo ASPM é igual.

Algumas soluções são incompletas e não têm a qualidade ou a cobertura necessárias para dar visibilidade total, contexto de risco e capacidade de remediação. Para explorar isso, precisamos revisar a evolução do ASPM, com foco nas diferentes ondas de soluções que surgiram nos últimos anos.

A evolução do ASPM: as 3 ondas¶

Os tipos de ASPM podem ser divididos em três ondas distintas, cada uma representando um nível diferente de maturidade no mercado geral de ASPM.

ASPMs autônomos (ASOC legado)¶

Essas primeiras soluções de ASPM, também chamadas de Application Security Orchestration and Correlation (ASOC), focavam sobretudo em consolidar dados de ferramentas de segurança de terceiros numa única plataforma, para melhorar visibilidade e gestão. Eram um subconjunto especializado de Risk-Based Vulnerability Management (RBVM), focado na camada de aplicação.

Úteis, sim, mas essas ferramentas só agregavam dados de scanners diferentes, com alguma capacidade de deduplicação. E, ao contrário da infraestrutura, vulnerabilidades na stack moderna de aplicação são altamente complexas. Isso significa que, sem contexto, tudo vira ruído.

O ponto central: os primeiros fornecedores de ASOC não tinham capacidades críticas para enriquecer os dados com contexto de risco e priorizar direito, e o resultado era agregar mais ruído entre ferramentas, com achados ainda menos acionáveis para remediação.

ASPMs de cadeia de suprimentos¶

Com a alta de ataques à cadeia de suprimentos de software, alguns fornecedores de segurança de cadeia de suprimentos começaram a se reposicionar como ASPMs, apesar de lacunas relevantes na oferta.

Essas soluções não tinham varredura nativa, priorização nem ferramentas de remediação automatizada. Sem esses recursos, as equipes de segurança ainda separavam vulnerabilidades na mão, o que tornava a remediação demorada e ineficiente.

ASPM completo¶

Agora chegou a terceira e mais avançada onda: o ASPM completo.

Uma plataforma de ASPM completo de verdade, como a Cycode, oferece segurança ponta a ponta em todo o SDLC. Ela cobre teste de segurança de aplicação para artefatos de código de aplicação e de infraestrutura (de origem interna ou de cadeia de suprimentos de terceiros), configurações e segredos do sistema de pipeline de implantação, e ferramentas avançadas de priorização e remediação, também enriquecidas por segurança de infraestrutura de produção e contexto de segurança em runtime.

A plataforma da Cycode também inclui o ConnectorX, que se integra sem atrito a aplicações cloud-native, e o Risk Intelligence Graph (RIG), que revela de forma dinâmica caminhos de ataque a partir de infraestrutura, pipeline, workloads ou artefatos de código e os mapeia até o código-fonte e os donos do projeto, o que permite uma remediação mais rápida e eficiente.

Esse nível de visibilidade e controle é crucial para as organizações protegerem ambientes de nuvem e on-prem e, ao mesmo tempo, manterem alta a velocidade de desenvolvimento.

A evolução do CNAPP¶

Os CNAPPs oferecem uma abordagem unificada para proteger aplicações cloud-native que rodam na nuvem, combinando várias funções críticas de segurança numa plataforma abrangente. No início, o CNAPP deveria reunir duas capacidades fundacionais de segurança de nuvem que operavam em silos: Cloud Security Posture Management (CSPM) e Cloud Workload Protection Platform (CWPP).

O CSPM focava em identificar configurações incorretas da camada de nuvem em vários serviços cloud-native, contra um conjunto de padrões de conformidade. O CWPP focava na camada de workloads de nuvem, com visibilidade mais profunda em workloads de IaaS (Infrastructure-as-a-Service), PaaS (Platform-as-a-Service) e, às vezes, Function-as-a-Service (FaaS), em máquinas virtuais, contêineres, camada de orquestração de contêineres e funções serverless (código). O CWPP pode ser considerado uma extensão de Endpoint Security desenhada para a nuvem.

A versão original dos fornecedores de CNAPP era simplesmente um acrônimo que descrevia quem tinha capacidades de CSPM e de CWPP numa única plataforma, desenvolvida de forma orgânica ou via aquisição. Não havia correlação contextual nem priorização entre as duas, parecido com a era ASOC do ASPM.

Depois, a segunda geração de fornecedores de CNAPP avançou a correlação contextual entre CSPM e CWPP, com uma abordagem inovadora sem agente: tirar e analisar snapshots de workloads de nuvem e correlacioná-los a configurações de nuvem via banco de dados em grafo. Com um contexto de risco mais holístico, essas soluções podiam priorizar a combinação mais tóxica de problemas, a de maior impacto, em vez de um relatório não acionável de cada achado fora de conformidade.

A segunda geração de soluções de CNAPP também usa agentes mais leves, com técnicas como eBPF, para extrair contexto em tempo real e enriquecer os achados.

Mas isso bastava? Conforme mais organizações investiram em CNAPP e tentaram operacionalizá-lo em escala, em várias nuvens, ficou evidente que ainda havia lacunas.

Por exemplo, o CNAPP só oferecia configurações incorretas de identidade em nível superficial, como checar se o MFA está habilitado ou não, ou determinar serviços ou workloads com privilégio demais. O CNAPP não conseguia inventariar identidades dormentes nem validar o raio de impacto, nem monitorar assunção de papéis, encadeamento de permissões ou detectar ataques de escalação de privilégio entre contas. Como resultado, surgiram soluções de Cloud Identity and Entitlement Management (CIEM) para se especializar em segurança de identidade na nuvem, ampliando o CNAPP.

Da mesma forma, o CNAPP podia identificar combinações tóxicas de configurações incorretas de nuvem e de workload, incluindo data stores e workloads de banco de dados. Porém, o CNAPP não tem visibilidade sobre quais dados sensíveis residem nesses data stores, quem tem acesso a eles ou quais operações essas identidades poderiam executar sobre esses dados. Como resultado, o Data Security Posture Management (DSPM) surgiu como uma categoria separada para tratar a segurança de dados na nuvem de forma holística, ampliando o CNAPP.

Conforme a segurança de nuvem continuou evoluindo, a consolidação de fornecedores acelerou. Os grandes fornecedores de CNAPP começaram a adquirir soluções de CIEM e de DSPM. Isso é um reconhecimento de que a fundação do CNAPP não foi desenhada para ir fundo num domínio específico, como identidade e dados.

À medida que essas aquisições continuaram, muitos analistas de pesquisa do setor passaram a refinar a definição de CNAPP, essencialmente acrescentando essas capacidades extras com base em aquisições de fornecedores, não por categorização lógica. Se aplicarmos a mesma abordagem a soluções de segurança on-premise, então segurança de rede, segurança de endpoint, segurança de dados e IAM colapsariam todas em segurança de infraestrutura.

Curiosamente, em alguns relatórios de analistas, CNAPP, DSPM e CISM permaneceram como categorias separadas, junto com ASPM e AST, também como categorias separadas. Para de fato alcançar uma segurança abrangente e abraçar o conceito de defense-in-depth, precisamos de várias categorias de soluções que se complementem.

O CNAPP não pode ser a solução única que vai fundo e largo em toda a stack de TI.

As lacunas e os desafios de expandir o CNAPP para cobrir segurança de aplicação¶

O desenvolvimento moderno e a adoção de conteinerização, IaC e GitOps exigem tratar componentes de infraestrutura programável do mesmo jeito que um pedaço de software, conforme atravessam o processo de desenvolvimento e implantação. Portanto, esses componentes precisam ser protegidos do mesmo jeito que o software, e os problemas precisam ser tratados o mais cedo possível no desenvolvimento.

Como resultado, soluções de segurança de contêiner que checam Dockerfile cru e soluções de segurança de IaC que varrem tanto templates de IaC quanto arquivos de manifesto de orquestração de contêiner, com integração estreita com desenvolvimento e nuvem, começaram a ganhar popularidade. Tanto plataformas de AST quanto CNAPPs começaram a incorporar essas capacidades. Porém, nenhum dos dois tinha o contexto completo.

As soluções dos fornecedores de AST não tinham o contexto de nuvem e de runtime, enquanto a versão dos fornecedores de CNAPP não tinha o contexto de quem desenvolve nem o contexto mais amplo do SDLC. Enquanto os dois lados tentavam fechar a lacuna, os fornecedores de CNAPP fizeram várias aquisições na área, como Bridgecrew, Cider Security, Soluble, Apolicy e outras. Isso de novo demonstrou a lacuna fundacional dentro do CNAPP.

O CNAPP foi desenhado para proteger tudo na nuvem, não tudo o que acontece durante o desenvolvimento. É aqui que o ASPM entra. Embora ASPM e CNAPP sejam cruciais para a postura de segurança de uma organização, eles servem a propósitos diferentes e precisam operar de forma independente para maximizar a eficácia.

Aqui vão algumas das lacunas entre os CNAPPs e o alcance deles na segurança de aplicação:

1. DNA diferente:

Os fornecedores de CNAPP não têm uma fundação que possa ser usada para construir scanners de código de aplicação de qualidade, que se integrem às cadeias de ferramentas de desenvolvimento e foquem na experiência de quem desenvolve. A fundação central do CNAPP foi construída em torno de configurações de nuvem (CSPM) e workloads de nuvem (CWPP).

Mesmo com os aprimoramentos tardios de identidade na nuvem (CIEM) e dados na nuvem (DSPM), o DNA central do CNAPP ainda é muito construído para proteger tudo o que acontece na nuvem, com alguns laços com fluxos de DevOps e de SecOps. O ASPM, por outro lado, é construído com um DNA central para proteger tudo no desenvolvimento, os artefatos de código e o processo da fábrica de software que transforma artefatos de código orgânicos e de terceiros em aplicações em execução em produção, em QUALQUER ambiente: nuvem, on-prem ou híbrido.

O ASPM pode puxar contexto do CNAPP sobre workloads em execução ou configurações de nuvem para enriquecer ainda mais problemas achados no desenvolvimento, mas não foi desenhado para cruzar a fronteira e substituir o CNAPP.

1. Contexto de segurança de quem desenvolve:

Dada a linha borrada entre aplicação e infraestrutura na era cloud-native, embora haja sobreposições em fluxos de desenvolvimento em que capacidades de segurança de contêiner e de infrastructure-as-code atravessam desenvolvimento e nuvem, o CNAPP não tem contexto de camada de aplicação do jeito que o ASPM tem. Por exemplo, fornecedores de CNAPP podem ter capacidades de Software Composition Analysis (SCA) como extensão da segurança de contêiner, que detectam pacotes de biblioteca de aplicação numa imagem de contêiner, mas não conseguem inspecionar arquivos de manifesto de pacote nem construir uma árvore de dependências que mostre dependências diretas e transitivas. Scanners de SCA do CNAPP também não conseguem se correlacionar com scanners de SAST para identificar quais bibliotecas de aplicação têm um caminho explorável a partir de uma chamada de função customizada no código-fonte. No contexto de gestão de risco da cadeia de suprimentos de software, bibliotecas open source podem ser modificadas e injetadas com malware durante o processo do SDLC, e só uma ferramenta de ASPM com contexto de cadeia de suprimentos de software e de pipeline poderia detectar essa mudança.

3. Experiência de quem desenvolve:

Soluções modernas de segurança de aplicação devem focar na experiência de quem desenvolve. Isso significa que a solução precisa se integrar ao longo do SDLC (IDE, IDP, repositórios de código-fonte, checagens de pull request, sistema de tickets, ChatOps, durante o processo de build e quaisquer repositórios da fábrica de software) para encontrar quem desenvolve onde essa pessoa está, e ainda permanecer flexível para opcionalidades de fluxo.

O ASPM foi desenhado para a experiência ponta a ponta de quem desenvolve, com todas as integrações comuns do SDLC, enquanto o CNAPP não foi.

Além disso, descoberta e inventário no desenvolvimento são muito diferentes dos da nuvem. A função de descoberta e inventário do CNAPP foi desenhada para descobrir e gerir todos os ativos de nuvem e agrupá-los sob contas e assinaturas de nuvem. Descoberta e inventário no desenvolvimento são mais nuançados e exigem agrupamento cuidadoso e mapeamento de CMDB para atribuir artefatos de código a repositórios, projetos, branches, equipes de desenvolvimento e desenvolvedores. O ASPM foi desenhado para descoberta e inventário no desenvolvimento, enquanto o CNAPP não foi.

O ASPM deve permanecer independente do CNAPP¶

Para o CNAPP cobrir capacidades completas de segurança de aplicação em todo o SDLC, num nível comparável a um ASPM completo, vão se passar anos para construir uma fundação nova do zero, acrescentando e integrando cada capacidade individual à plataforma mais ampla e otimizando para escala enterprise.

Enquanto os fornecedores de CNAPP continuam fazendo aquisições para ampliar os portfólios, também vai levar tempo integrar por completo essas aquisições às plataformas-mãe. Isso ficou evidente nos últimos anos, conforme a plataforma de CNAPP evoluiu.

Além disso, depender de um único fornecedor para a segurança de desenvolvimento e a de nuvem é arriscado.

No caso de uma queda ou falha do fornecedor, não seria crítico na nuvem, onde o lado sem agente da solução de CNAPP simplesmente deixaria de detectar riscos novos. Porém, poderia causar problemas graves se uma varredura de segurança via pull request expirasse, impedindo que o código fosse mesclado e promovido para a etapa seguinte. Esse é o jeito mais fácil de a equipe de segurança perder a confiança.

Por ora, ASPM e CNAPP devem permanecer separados. Na verdade, eles se complementam muito bem. Na parte dois deste blog, vamos aprofundar como ASPM e CNAPP podem se ampliar e reforçar as capacidades um do outro.

Conheça o autor¶

Jimmy Xu, Field CTO na Cycode

Líder de pensamento em cibersegurança experiente, inovador e voltado para o futuro, com mais de 20 anos de sucesso comprovado orientando e capacitando clientes a acelerar o crescimento do negócio e a transformação digital, ao mesmo tempo em que mitigam riscos cibernéticos atuais e emergentes. Começou como desenvolvedor e trabalhou em todas as áreas de TI, incluindo engenharia de sistemas, redes e segurança. Conhece todas as áreas de segurança da informação, com especialização em segurança de aplicação, segurança de nuvem e DevSecOps.