A análise de composição de software, Software Composition Analysis (SCA, pela sigla em inglês) é uma técnica de testes de segurança que inventaria os componentes de terceiros e de código aberto dos quais uma aplicação depende, diretos e transitivos, e confere cada versão específica contra inteligência de vulnerabilidades e de malware. A documentação da Fluid Attacks a define como uma técnica que "automatically identifies the third-party dependencies or libraries that an application uses". A unidade sobre a qual ela trabalha é a versão, não o nome do pacote.
Só no dia 4 de novembro de 2026, o banco de dados da Fluid Attacks publicou 67 avisos de malware: 62 de npm, três de PyPI e dois de RubyGems. Nenhum deles tinha um CVE. Uma SCA que apenas compara componentes contra fontes de CVE teria reportado como limpo todo projeto que os usasse.
Esta página cobre o que a SCA inventaria, o que detecta e o que não detecta, como as dependências diretas e indiretas são resolvidas, como a alcançabilidade e os dados de exploração mudam quais achados importam, e onde a nossa própria SCA para. Ela trata a cadeia de suprimentos de software como um problema operacional, não como uma caixinha de conformidade.
O que é SCA?
SCA é a prática de construir um inventário preciso de dependências do código que a sua aplicação usa mas que o seu time não escreveu, e depois avaliar o risco que cada entrada carrega. Ela lê os arquivos onde as dependências de código aberto são declaradas, resolve o que essas dependências por sua vez puxam e confere a lista resultante de pares componente-versão contra inteligência de segurança.
A saída são duas coisas: o inventário em si, normalmente exportável como lista de materiais de software (SBOM), e um conjunto de achados atrelados a versões específicas em arquivos específicos.
O que a SCA não é
A SCA não lê o seu próprio código em busca de padrões inseguros. Isso é teste de segurança de aplicações estático. Ela não testa uma aplicação em execução. Isso é teste de segurança de aplicações dinâmico. E a SCA não é sinônimo de gerar uma lista de materiais: esse documento é uma saída, enquanto a análise é o trabalho de decidir quais das suas entradas são perigosas e por quê.
A distinção importa porque os times que tratam a SCA como geração de documentos acabam com uma lista precisa de componentes e sem ideia de qual das suas centenas de entradas atender primeiro.
O que a SCA detecta e o que não detecta
A SCA como categoria cobre mais terreno do que qualquer produto implementa sozinho. O guia Component Analysis da OWASP lista quinze fatores de risco de um componente de terceiros, entre eles a idade do componente, a confiança no repositório, a procedência, o pedigree, a licença, o risco herdado e a saúde do projeto. Uma vulnerabilidade conhecida é um dos quinze, não o quadro completo. A OWASP também aponta que componentes "end-of-life (EOL) or end-of-support (EOS) also impact risk", algo que nenhuma fonte de CVE vai lhe dizer.
Os produtos dividem esse terreno de formas diferentes, então a resposta honesta para "o que isso detecta?" depende de qual ferramenta se fala. A nossa é deliberadamente estreita:
Capacidade | SCA como categoria | SCA da Fluid Attacks |
|---|---|---|
Inventário de componentes diretos e transitivos | Sim | Sim |
Vulnerabilidades divulgadas por versão (CVE e avisos) | Sim | Sim |
Pacotes maliciosos e comprometidos | Depende do produto | Sim, com identificadores de aviso próprios |
Alcançabilidade da função vulnerável | Só onde está implementada | Sim, determinística, em 14 linguagens |
Exportação de SBOM | Sim | Sim, CycloneDX e SPDX |
Componentes desatualizados e sem manutenção | Sim | Reportados como parte da avaliação de segurança |
Conformidade de licenças | Incluída com frequência | Não. Fora do escopo |
Qualidade do código dos componentes | Às vezes incluída | Não. Fora do escopo |
Nossa documentação enuncia o limite sem rodeios: "Fluid Attacks SCA is for application security only and detects only security issues", e "does not detect other types of issues, for example software quality or legal issues". Se a conformidade de licenças de código aberto é um requisito da sua organização, uma ferramenta construída para segurança não vai cobri-la, e a nossa diz isso em vez de insinuar o contrário.
A SCA na Fluid Attacks
Nossa SCA roda como parte de uma avaliação contínua dos repositórios que você conecta, não como uma varredura que você dispara. Eis o que ela inventaria, onde vai além de comparar uma lista de pacotes contra o NVD e onde ela para.
O que inventariamos, e a partir de quê
Fazemos SCA sobre os arquivos onde você declara as suas dependências: os manifestos e os lock files dos gerenciadores de pacotes que suportamos nos ecossistemas de JavaScript, Python, Java, Go, Ruby, PHP, C# e Swift. O código copiado de um terceiro e colado no seu repositório é reportado à parte, como dependência não atualizável, porque não há versão a subir.
Cada entrada do inventário de pacotes carrega o repositório e os arquivos onde aparece, os avisos que afetam aquela versão e a etapa em que é usada: build, quando o arquivo depende do componente "only in the software development stage", ou run, quando depende dele "in the live production environment". Esse último campo é o que separa um arcabouço de testes vulnerável de um componente vulnerável que chega à produção.
Avisos de malware, não só correspondências de CVE
Um pacote pode ser malicioso sem nunca receber um CVE. Nosso banco de dados trata isso como uma classe de fraqueza própria, a 448, "Use of software with malware": "One or more dependencies used in the project contains code or components suspected of being compromised by malware or malicious behavior". Ela mapeia para três dos nossos requisitos de segurança, entre eles "Verify third-party components".
Essa classe é alimentada por inteligência que uma fonte de CVE não carrega. Das 18 fontes de dados por trás do nosso catálogo, uma é a OpenSSF Malicious Packages, um fluxo de publicações maliciosas confirmadas e não de falhas divulgadas. O resultado é público e contínuo: aqueles avisos de 4 de novembro, para pacotes como nminer no npm e extera-runtime no PyPI, levam identificadores nossos em vez de CVE, porque nenhum CVE existe.
Avisos de malware publicados em 4 de novembro de 2026. Nenhum deles leva um CVE.
Alcançabilidade determinística, não probabilística
Saber que há uma versão vulnerável presente não é o mesmo que saber que a sua aplicação consegue disparar. Nossa análise de alcançabilidade resolve se o elemento vulnerável é de fato invocado, e faz isso de forma determinística, seguindo o caminho de chamada, em vez de estimar probabilidade.
Nossa documentação de comparação registra como isso fica diante de outros dois fornecedores, conforme a atualização de outubro de 2026 das tabelas:
Atributo | Fluid Attacks | Snyk | Black Duck |
|---|---|---|---|
Alcançabilidade | 14 linguagens | 5 linguagens | Não oferece |
Tipo de alcançabilidade | Determinística | Probabilística | — |
Detecção de malware | Sim | Sim | Não |
Fontes de vulnerabilidades | 18 | 9 | 5 |
Distribuições de contêiner | 4 | 15 | Sem especificar |
Fonte: comparações da Fluid Attacks com a Snyk e com a Black Duck.
Os limites
A última linha daquela tabela não nos favorece, e é a primeira coisa a conferir antes de adotar qualquer SCA. Cobrimos quatro distribuições de contêiner. Um time cujo risco se concentre dentro das imagens base, e não nos manifestos da aplicação, vai encontrar cobertura mais ampla em outro lugar.
Mais dois limites que vale enunciar. Não aplicamos correções às suas dependências de forma automática em todos os casos: o scanner recomenda a versão segura e, em projetos de JavaScript e Python, nossa extensão de IDE pode aplicar essa mudança ao manifesto por você, e avisa se a atualização do lock file falhar. E, como dito acima, os achados de licença e de qualidade estão fora do escopo. Uma SCA que reivindica os quinze fatores de risco da OWASP costuma estar reivindicando um roadmap.
Revise o diff, não só o repositório
As dependências entram num pull request. Nosso Peer Reviewer Assistant "reviews the code changes of a pull request or a merge request (PR/MR)" e roda três scanners sobre elas, incluída a SCA, que reporta "vulnerabilities in the dependencies that the change affects". Funciona sobre repositórios hospedados na nuvem no GitHub, GitLab e Azure DevOps.
É aí que aparece a diferença mensurável. No State of Attacks 2026 da Fluid Attacks, que cobre 1.119.396 vulnerabilidades reportadas entre 1º de janeiro e 31 de dezembro de 2025, as organizações que usaram nosso CI Gate remediaram 72,2 % das suas vulnerabilidades reportadas, contra 58 % das que não usaram.
Ela roda junto com SAST, DAST e Pentesting as a Service (PTaaS), de modo que um achado de dependência é triado ao lado do que o pentest encontrou na mesma aplicação.
Aprofunde: a análise de alcançabilidade explica como o caminho de chamada é resolvido e o que um veredicto de não alcançável prova e não prova.
Como a SCA resolve dependências diretas e transitivas
Uma dependência direta é a que o seu projeto declara. Uma dependência transitiva é a que as suas dependências diretas puxam, muitas vezes várias camadas abaixo, e resolvê-la corretamente é a coisa mais difícil que uma SCA faz, porque é ali que vive a maior parte do inventário.
Nossa SCA etiqueta cada importação de cada arquivo com um de três estados:
Etiqueta | Significado | O que você faz com ela |
|---|---|---|
D — Direta | "The file in your project explicitly imports and uses the third-party dependency" | Subir a versão declarada |
T — Transitiva | "The third-party dependency is required by your direct dependencies", sem que o arquivo a importe | Seguir o caminho até o pai direto, ou fixar um override |
U — Indeterminável | "It is impossible to determine whether the dependency is direct or transitive" para aquele arquivo | Tratá-la como presente até resolver à mão |
Para as entradas transitivas, a plataforma traça o caminho. No exemplo documentado, a dependência direta grunt-if leva à dependência transitiva vulnerável y18n, e o caminho mostra cada salto entre as duas. Sem esse caminho, um achado de SCA chega ao desenvolvedor como um alerta sobre um pacote que não aparece em lugar nenhum do seu manifesto.
A plataforma traça o caminho da dependência direta grunt-if até a dependência transitiva vulnerável y18n.
Log4Shell é o caso que tornou isso inevitável: milhares de organizações rodavam uma biblioteca de registro vulnerável que nunca haviam declarado, herdada por meio de frameworks e plugins, e responder sequer à pergunta exigia ter a árvore resolvida que uma SCA produz. Os reguladores chegaram à mesma conclusão. O documento 2026 Minimum Elements for a Software Bill of Materials, publicado em 29 de julho de 2026 pela CISA junto com a NSA, o FBI e quinze agências parceiras internacionais, diz que uma SBOM deve cobrir todos os componentes "including transitive dependencies. There is no minimum depth.". A linha de base de 2021 que ele substitui pedia apenas as dependências de primeiro nível.
Por que a SCA importa: quatro riscos que um scanner tem que separar
Jogar todo problema da cadeia de suprimentos de software numa única fila de alertas é o que torna inútil a saída da SCA. Estes quatro riscos se comportam de forma diferente e pedem respostas diferentes.
Vulnerabilidades conhecidas em uma versão específica
O mesmo pacote pode estar seguro e vulnerável ao mesmo tempo, dependendo da versão fixada. Nosso catálogo de componentes, que tinha mais de 233.000 componentes de código aberto quando consultado em 5 de novembro de 2026, registra o estado por versão: lodash, por exemplo, tem 116 versões monitoradas no npm, algumas marcadas como seguras e outras com vários avisos cada uma.
A versão, não o nome do pacote, é o que decide se uma dependência é vulnerável.
Pacotes comprometidos e maliciosos
Em setembro de 2025, um e-mail de phishing vindo de um domínio lookalike tomou a conta de um mantenedor proeminente do npm e publicou versões maliciosas de 18 pacotes muito usados com cerca de 2,6 bilhões de downloads semanais combinados; nossa análise daquela campanha rastreou malware que reescrevia endereços de carteiras de criptomoedas no navegador. Seis dias depois, o Shai-Hulud usou tokens roubados do npm para publicar versões maliciosas de outros pacotes de cada mantenedor que alcançava, propagando-se sozinho. E em março de 2025, uma GitHub Action comprometida usada por mais de 23.000 repositórios imprimiu segredos de CI/CD nos registros dos fluxos de trabalho.
O NCSC do Reino Unido chegou à mesma conclusão em junho de 2026, ao alertar que "malicious code introduced into a single package can spread rapidly across many organisations and services before detection" e nomear como técnicas recorrentes o comprometimento da conta do mantenedor, a tomada de pacotes abandonados, o typosquatting e a autopropagação.
Componentes sem manutenção e saúde do projeto
Um componente sem falhas conhecidas ainda pode ser um passivo se ninguém o mantém. Nossos textos sobre a infraestrutura digital com pouco suporte e a piada de Nebraska do xkcd #2347 sustentam que projetos críticos muitas vezes são mantidos vivos por um punhado de pessoas sem remuneração. A retirada de left-pad do npm em 2016 quebrou compilações em todo o ecossistema, e não foi ataque nenhum: o risco de dependências inclui disponibilidade, não só comprometimento.
Ao escrever sobre SCA em 2018, Rafael Ballestas, analista de segurança da Fluid Attacks, colocou a responsabilidade de escolher bem os componentes onde ela cabe:
"It is not FOSS's fault if applications use it with known vulnerabilities but rather that of the apps' owners".
(Não é culpa do FOSS se os aplicativos o utilizam com vulnerabilidades conhecidas, mas sim dos donos dos aplicativos).
Dependências que seguem mudando depois do build
Uma vulnerabilidade pode ser divulgada na semana seguinte ao seu deploy, sem que nada no seu código tenha mudado. Uma auditoria pontual de um repositório é uma fotografia, e por isso o inventário de dependências precisa ser monitorado em busca de atualizações, avisos de segurança e vulnerabilidades alcançáveis, em vez de ser exportado uma vez e arquivado.
Isso é também o que torna a SCA diferente na prática dos outros scanners de um pipeline de CI/CD: um achado de SAST aparece porque alguém escreveu uma linha de código, enquanto um achado de SCA pode aparecer num branch que ninguém toca há meses.
Como priorizar os achados da SCA
A severidade sozinha é uma fila ruim, e é a principal razão pela qual a saída da SCA é ignorada. Um único registro de vulnerabilidade do nosso banco de dados carrega os sinais que de fato decidem a ordem, e com frequência eles discordam entre si:
Sinal | O que responde |
|---|---|
CVSS, original e ajustado | Quão grave é no abstrato, e neste contexto |
EPSS com percentil | Quão provável é a exploração nos próximos 30 dias |
CISA KEV | Está sendo explorada agora mesmo? |
Evidência de exploit e de PoC | Existe código de ataque funcional? |
Capacidade de alcançabilidade | Seu código consegue de fato chegar à falha? |
Transitividade | Cabe a você corrigir, ou à sua dependência? |
Etapa de uso | Só no build, ou rodando em produção? |
Qualquer SCA emite a primeira linha. O resto separa uma fila trabalhável de uma lista que você arquiva.
A discordância é o ponto. Um registro que publicamos carrega uma pontuação CVSS v3.1 original de 8,1 Alta e uma pontuação CVSS v4.0 ajustada de 5,2 Média, com um EPSS de 2,81 % e sem evidência de KEV. Tratá-lo como Alta porque o primeiro número diz isso desloca trabalho para longe de algo que de fato está sendo explorado.
Um registro carrega dados de exploração, estado KEV, capacidade de alcançabilidade e uma pontuação de severidade ajustada.
SCA, SAST e SBOM não são alternativas
Esses três são usados de forma intercambiável e respondem perguntas diferentes.
SCA | Análise estática | Lista de materiais | |
|---|---|---|---|
O que examina | Dependências declaradas e suas versões | Seu próprio código-fonte | Nada. É um documento |
O que produz | Achados atrelados a uma versão de componente | Achados atrelados a uma linha de código | Um inventário de componentes |
Que pergunta responde | Estou usando algo perigoso? | Escrevi algo perigoso? | O que estou usando, afinal? |
Os dois primeiros são complementares, não concorrentes, e combiná-los é o que torna a alcançabilidade possível: você precisa da lista de componentes para saber o que está presente e da análise de código para saber se é chamado. A lista de materiais é o artefato que a SCA emite, e tem a sua própria página.
Como implementar a SCA
Comece por onde as dependências entram. Rodar a SCA apenas no branch principal significa que todo pacote vulnerável já está mesclado quando alguém o vê, então escaneie os pull requests e quebre o build com o que violar a política.
Defina a política antes da primeira varredura, em termos sobre os quais o seu time possa agir: quais severidades bloqueiam um merge, como os dados de exploração e a alcançabilidade modificam isso, e de quem é um achado transitivo que precisa de uma correção rio acima. A gestão de vulnerabilidades decide o que acontece depois do alerta; o scanner só decide o que o alerta diz.
Julgue qualquer SCA contra o seu próprio stack, não contra uma lista de funcionalidades. As perguntas que separam esses produtos são estreitas: quais gerenciadores de pacotes ela resolve, se detecta publicações maliciosas ou só falhas divulgadas, se traça caminhos transitivos ou só lista nomes, se a alcançabilidade é determinística ou estimada, e o que ela cobre dentro dos contêineres.
Conclusões
A SCA ganha o seu lugar quando responde a uma pergunta mais difícil do que "este pacote está numa lista?". Os ataques que comprometeram o npm em 2025 e 2026 não produziram CVE no dia em que importavam, e uma SCA limitada a falhas divulgadas reporta esses projetos como limpos. Julgue uma SCA pela sua inteligência de malware, por traçar ou não caminhos transitivos, por conseguir ou não dizer que a função vulnerável é alcançável, e por ser honesta sobre onde ela para.
Perguntas frequentes
A SCA consegue detectar pacotes maliciosos que não têm CVE?
Só se ingerir inteligência de malware, e não apenas fontes de vulnerabilidades. Um pacote malicioso costuma ser um projeto legítimo cuja conta de mantenedor foi comprometida, e nenhum CVE chega a ser atribuído. A Fluid Attacks os publica como classe de aviso própria: só em 4 de novembro de 2026 apareceram 67 avisos de malware no nosso banco de dados — 62 de npm, três de PyPI e dois de RubyGems — e nenhum deles levava um CVE.
A SCA escaneia dependências transitivas?
Uma boa escaneia, e é ali que vive a maior parte do inventário. Nossa plataforma etiqueta cada importação como direta, transitiva ou indeterminável, e para os achados transitivos traça o caminho de volta até a dependência direta que os introduziu. Desde julho de 2026, os elementos mínimos da CISA exigem essa cobertura sem profundidade mínima, então uma ferramenta que para no primeiro nível já não cumpre a linha de base.
Qual é a diferença entre SCA e SBOM?
Uma SBOM é um documento que lista os componentes de uma peça de software. A análise é o que produz esse documento e depois avalia o que há nele. Você pode ter uma SBOM completa e em conformidade com o padrão e ainda assim não saber qual das suas entradas é explorável.
Como a análise de alcançabilidade muda os resultados da SCA?
Ela separa presença de exposição. Uma versão vulnerável na sua árvore de dependências só é explorável se o seu código chegar ao elemento vulnerável. A Fluid Attacks resolve isso de forma determinística em 14 linguagens. Um veredicto de não alcançável baixa a prioridade; não prova que o componente é seguro, porque uma mudança posterior de código pode torná-lo alcançável.
A SCA da Fluid Attacks detecta problemas de licença ou de qualidade de software?
Não. Nossa documentação afirma que a nossa SCA "is for application security only and detects only security issues" e "does not detect other types of issues, for example software quality or legal issues". Ela inventaria as suas dependências de código aberto, exporta SBOM em CycloneDX e SPDX, e reporta achados de segurança. A conformidade de licenças precisa de uma ferramenta à parte.
Saiba o que você está publicando
Nosso Software Composition Analysis inventaria cada dependência que a sua aplicação puxa e diz quais versões são perigosas, quais são alcançáveis e quais carregam malware. Teste gratuito · Fale conosco.
Comece agora com a solução SSCS da Fluid Attacks
