Open Source Friday: protegendo projetos JavaScript com o CVE Lite CLI

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Open Source Friday: Securing JavaScript Projects with CVE Lite CLI · Canal: GitHub · 1:04:00 · Assistir no YouTube

Tópicos: Cibersegurança e segurança de software, Open source e ecossistemas de software

Resumo

Andrea Griffiths conversa com Sonu Kapoor, criador do CVE Lite CLI, uma ferramenta gratuita e de código aberto para identificar vulnerabilidades em dependências de projetos JavaScript e TypeScript. O scanner funciona localmente e, além de apontar problemas, recomenda versões seguras e comandos de atualização, inclusive para dependências transitivas. A demonstração mostra os modos compacto e detalhado no terminal e um relatório HTML compartilhável, que também pode ser guardado para auditorias. Sonu explica como o projeto se diferencia de ferramentas como npm audit e comenta a integração com GitHub e o uso de skills para orientar agents sem usar IA no próprio scanner.

Pontos-chave

O CVE Lite CLI foi criado para tornar os resultados de uma verificação de segurança mais acionáveis, em vez de apenas listar vulnerabilidades.
A ferramenta analisa projetos JavaScript e TypeScript localmente, sem exigir conta ou API key, e oferece suporte a npm, pnpm, Yarn e Bun.
O scanner distingue dependências diretas e transitivas e procura uma versão segura, inclusive quando é necessário atualizar uma dependência direta para corrigir problemas transitivos.
A priorização combina severidade com EPSS, uma estimativa da probabilidade de exploração, para destacar problemas que podem exigir atenção imediata.
Os modos de terminal apresentam comandos de correção e explicam quando uma atualização pode introduzir uma breaking change.
O relatório HTML reúne recomendações, detalhes das dependências e caminhos da árvore de dependências; pode ser compartilhado como arquivo independente e arquivado no GitHub para auditoria.
O projeto evita aplicar overrides automaticamente e inclui uma função para verificar se overrides existentes ainda são necessários.
O scanner não usa IA; o projeto também oferece skills e saída JSON que podem ajudar um agent a aplicar correções com base nas recomendações da ferramenta.
O criador incentiva contribuições por meio de issues e etiquetas como good first issue e first-timers only.
Uma das prioridades futuras é integrar as recomendações diretamente ao fluxo de pull requests no GitHub.

Capítulos

Início	Capítulo	Resumo
00:15	Abertura e boas-vindas	Andrea Griffiths dá as boas-vindas ao público e apresenta o programa.
04:21	Avisos e eventos da comunidade	A apresentadora divulga a We Are Developers Congress e o sorteio de ingressos para o GitHub Universe.
09:35	Apresentação do CVE Lite CLI	Andrea apresenta Sonu Kapoor e o scanner de vulnerabilidades para projetos JavaScript e TypeScript.
11:11	Origem e trajetória do projeto	Sonu explica que criou a ferramenta por frustração com os processos existentes e descreve sua entrada no OWASP.
13:17	O problema das dependências vulneráveis	Sonu explica por que listas de vulnerabilidades não bastam e como dependências transitivas dificultam as correções.
17:31	Correção de vulnerabilidades transitivas	A conversa detalha como a ferramenta procura uma versão segura dentro da faixa permitida e alerta sobre breaking changes.
20:44	Comparação com npm audit	Sonu compara o suporte a gerenciadores de pacotes e a busca por versões seguras com as opções oferecidas por npm audit.
22:21	Demonstração no terminal	A demonstração mostra uma análise de projeto, a divisão entre dependências diretas e transitivas e a priorização com EPSS.
30:12	Saída detalhada e recomendações	O modo detalhado mostra comandos de correção e verifica versões sucessivas antes de recomendar uma atualização.
37:02	Overrides e análise dos caminhos	Sonu comenta as limitações de outras ferramentas e mostra como o CVE Lite CLI identifica dependências que introduzem vulnerabilidades.
43:19	Relatório HTML e uso em auditorias	O relatório apresenta planos de correção, caminhos de dependências e um arquivo independente que pode ser compartilhado ou arquivado.
51:17	Contribuições e integração com GitHub	A conversa aborda as etiquetas para novos contribuidores e os planos para levar recomendações diretamente aos pull requests.
57:34	IA, agents e habilidades do projeto	Sonu esclarece que o scanner não usa IA, mas oferece skills e saída JSON para orientar agents na aplicação de correções.
1:00:11	Como participar e encerramento	Sonu recomenda abrir issues reproduzíveis ou contribuir com correções, e Andrea encerra o episódio.

Citações

Quero trazer a verificação de segurança para o fluxo de trabalho dos desenvolvedores. — 14:22

É uma ordem de triagem, não apenas uma lista. — 27:34

A ferramenta se recusa a prometer mais do que consegue comprovar. — 46:58

O próprio CVE Lite não usa IA. — 58:06

Conceitos e entidades

CVE Lite CLI (ferramenta): Scanner de vulnerabilidades em dependências para projetos JavaScript e TypeScript, com recomendações de correção.
OWASP (empresa): Organização mencionada como responsável pelo OWASP Top 10 e que incorporou o projeto ao seu programa.
OWASP Top 10 (conceito): Lista de referência de riscos de segurança em aplicações web mencionada na conversa.
npm audit (ferramenta): Comando do ecossistema npm usado como ponto de comparação para a detecção e a correção de vulnerabilidades.
EPSS (conceito): Sistema que estima a probabilidade de uma vulnerabilidade ser explorada nos próximos 30 dias.
OSV (ferramenta): Fonte de recomendações de segurança consultada pelo CVE Lite CLI durante a busca por versões seguras.
OWASP Juice Shop (repo): Aplicação citada como exemplo conhecido para testar práticas de segurança.
Sonu Kapoor (pessoa): Criador do CVE Lite CLI e principal responsável pelo projeto.
Andrea Griffiths (pessoa): Apresentadora do Open Source Friday que conduz a conversa e a demonstração.
Software Bill of Materials (conceito): Inventário de componentes de software mencionado na comparação com outras ferramentas.

Tradução completa (pt-BR)

00:15 [música] [música] [música] [música]

00:49 [música] Calor. Calor. [música] Calor. Calor.

01:34 Calor. Calor. [música] >> [música] [música] [música]

02:07 >> Calor. Calor. [música] >> [música] [música] >> Calor. Calor. [música] [música] Calor

02:47 [música] [música] aqui em cima. >> [música] [música]

03:18 [música] >> Ninguém está mais animado com essa animação do que >> [risos] [suspiros] >> Olá, pessoal. Boas-vindas ao Open Source Friday. Boas-vindas à sexta-feira. Vocês conseguiram. Conseguiram. Eba! Muito obrigada por participarem. Sei que temos pessoas chegando de todos os lugares. E, claro, adoraria saber de onde vocês estão acompanhando

03:48 o programa. Então, para quem está aqui pela primeira vez, boas-vindas. Sou Andrea Griffiths, uma desenvolvedora colombiana em todos os lugares, e é um prazer estar com vocês hoje. Então, boas-vindas, Abas, boas-vindas, MD, boas-vindas, Amy. Amy, você é uma grande amiga do programa. Obrigada por sempre vir e nos apoiar. Nós percebemos. Obrigada. Agradecemos muito. Boas-vindas, Ankush. Boas-vindas, Abbas. Boas-vindas, Daniel. Adoro essa animação. Acho que

04:21 nossa equipe de design fez um trabalho incrível. Eles são realmente muito bons no que fazem. Bem, de novo, sou Andrea e é um prazer estar com vocês hoje. Hoje vou apresentar um projeto muito empolgante e interessante. Mas, antes de chegarmos ao nosso convidado do dia, tenho alguns avisos rápidos. Começando pelo fato de que, na semana que vem, eu e, meu Deus, vários membros da minha equipe — isso está virando uma espécie de mini encontro fora do escritório para nós — vamos

04:52 estar em San Jose, Califórnia, para a conferência We Are Developers. Ela se chama We Are Developers Congress. Se você nunca foi a nenhum evento da We Are Developers, recomendo que… Bem, tenho algumas recomendações para vocês. Ela começou como uma conferência europeia. Então, a primeira série de conferências foi em Berlim e sempre teve um clima bem descontraído. Já fui duas vezes à edição europeia, em Berlim.

05:23 Este ano, eles vão levar o evento para outros lugares. San Jose, Califórnia, será a primeira parada, na semana que vem, novamente em San Jose, de 23 a 25 de setembro, e depois eles vão para a Índia. Sei que temos bastante gente nos acompanhando da Índia, e convido todos vocês a conferirem o site. Vou deixar o link do site nas notas agora, para que vocês o tenham e possam aproveitar. Esse é o evento que vai acontecer

05:55 na semana que vem. Os ingressos custam cerca de US$ 1.400. Então, é um grande investimento em você mesmo. Mas também tenho um convite para vocês e para a comunidade do Open Source Friday. Graças à generosidade da comunidade do We Are Developers World Congress, tenho alguns passes para oferecer a vocês. Então, se você estiver em San Jose na semana que vem, se tiver um

06:27 jeito de chegar a San Jose na semana que vem, este é o cronograma que vocês estão vendo na tela. Nesse dia zero, a equipe do GitHub vai realizar vários workshops. Talvez a equipe de certificações venha também, não tenho certeza, mas vai acontecer muita coisa. Então, você vai querer estar lá. E depois teremos dois dias de palestras. Eu mesma vou falar na sexta-feira. Então, se você acha que poderia ir, mesmo que só consiga comparecer em um dos dias — sei que a maioria de nós não pode tirar a semana inteira para ir à conferência — eu adoraria que você me mandasse

06:59 uma mensagem privada para que eu possa fazer sua inscrição pelo ótimo preço de zero dólares [risos]. E, mais uma vez, muito obrigada à equipe organizadora do We Are Developer Congress. Agradeço por me permitir compartilhar essa oportunidade com tantas pessoas. Então, se você tem amigos da área de tecnologia em San Jose e está pensando: “O quê?”, ou em San Francisco — eles estão operando ônibus entre San Francisco e San Jose. Depois que você receber seu ingresso, vai receber todas

07:29 as informações e saber exatamente o que fazer. Mas há uma programação realmente muito interessante de palestras. Há muitos nomes importantes e elas acontecem em paralelo. Dá para ver que há várias palestras acontecendo ao mesmo tempo. Então, você tem a oportunidade de ir e aprender literalmente o que quiser. Me avise se quiser estar lá. Ficarei muito feliz em conseguir um ingresso para você. Esse foi o aviso número um e prometo ser rápida com o próximo. O sorteio de ingressos para o GitHub Universe ainda está aberto.

08:01 Ainda estamos sorteando um ingresso para o Gearhub Universe, que é nosso congresso, nossa grande conferência, que vai acontecer em São Francisco, nos dias 28 e 29 de outubro. Amigos, já falei uma vez e vou repetir: este é o Super Bowl dos nerds. Se você já foi ao GitHub Universe, conte no chat e me diga como foi sua experiência. É uma das minhas conferências favoritas. Acho que é uma conferência para a qual eu compraria um ingresso mesmo que não trabalhasse aqui. Ainda assim compraria um ingresso para ir

08:32 lá. Então, eu deveria ter vindo preparada com algum desconto ou algo assim. Não tenho nada agora, mas talvez até o fim do programa eu consiga. Enquanto isso, participem do sorteio, por favor. Acessem gh.io/in e basta preencher um formulário. Basicamente, só me digam que conseguem chegar a San Francisco, e ficarei feliz em conseguir um ingresso para vocês. E, se não forem tímidos e quiserem se encontrar pessoalmente, também posso providenciar isso. Certo, esses são meus avisos da semana. Agora,

09:04 vamos ao que interessa. Preciso resolver rapidinho uma situação com alguém que insiste em fazer spam no nosso chat. Pessoal, não façam spam no chat. Sejam bons membros do chat, por favor. Vamos ser bons membros do chat. Se quiserem fazer networking entre vocês, conversar uns com os outros, adoro isso. Troquem contatos. Isso é ótimo. Mas, se ficarem enviando um monte de coisas, vou silenciar vocês e provavelmente bloquear. Hoje estou pronta para brigar. Mas obrigada. Obrigada por estarem aqui. Certo. Nosso convidado de hoje… Bem, como vocês sabem, o Open

09:35 Source Friday é um programa feito para vocês e para o open source. E hoje vamos conhecer um projeto em particular chamado CVE Light CLI. Sou uma grande fã de projetos de CLI. Adoro isso. Acho que CLI facilitam nossas vidas, e um projeto voltado para segurança e CVEs sempre vai ser um dos meus favoritos também. Então, estou muito feliz de receber hoje Sonuku Kapoor, criador do CVE Light. Vou colocar aqui o link do projeto para que as pessoas possam dar uma olhada. Mas o CVE Light CLI é um scanner de vulnerabilidades em dependências para projetos de JavaScript e TypeScript. E, na verdade, faz parte do OWASP. Então, boas-vindas, Sonu. Obrigada por estar aqui. >> Oi, Andrea. Obrigado pelo convite. >> Estou muito animada para saber um pouco mais sobre o CVE Light CLI. Sonu, você vem desenvolvendo em público desde 2026. E você tem, o quê, cerca de 50 mil downloads no npm

10:08 em menos de quatro meses, o que é impressionante. >> E agora o projeto faz parte do laboratório da OWASP. Quando isso aconteceu? Quando ele passou a fazer parte da OWASP? Você pode explicar para quem não sabe o que é a OWASP? Seria um ótimo ponto de partida e depois podemos conversar. >> Sim, claro. Então, comecei esse projeto em abril, acho, porque estava frustrado com os processos existentes para corrigir CVEs

10:39 Então, o que aconteceu foi que, algumas semanas depois de começar o projeto, ele começou a ganhar força na comunidade. Jornalistas entraram em contato, repórteres entraram em contato, tudo ficou uma loucura. Depois me inscrevi na OWASP, e a OWASP era basicamente a autoridade que rege as práticas de segurança, certo? Todos conhecemos a…

11:11 processos que coloquei em prática para corrigir CVE. Então, o que aconteceu foi que, depois de algumas semanas do início do projeto, ele meio que decolou na comunidade. Jornalistas entraram em contato, repórteres entraram em contato, foi uma loucura. E então me candidatei à OS, e a OS era basicamente a autoridade de governança por trás das práticas de segurança, certo? Todos conhecemos o…

11:43 lista das 10 principais, certo? Por exemplo, grandes empresas e governos seguem as 10 principais para garantir que seus projetos sejam seguros. Então, entrar na OWASP foi muito importante porque, sabe, eles analisam seu projeto minuciosamente antes de poderem colocar o selo deles nele, certo? Então, em poucas semanas, eu já fazia parte da OWASP e, alguns meses

12:14 depois, o projeto passou a ser um projeto de laboratório. Primeiro, você começa com um projeto incubado; quando prova seu valor, passa para um projeto de laboratório, e acho que há outra etapa depois dessa, que é a final. Não lembro o nome nem o status, mas ela vem cerca de um ou dois anos depois. >> Que incrível. E, para quem talvez esteja pensando: “Ah, nunca usei isso”, ou mesmo para quem não trabalha com segurança e talvez não se concentre em vulnerabilidades,

12:46 isso afeta todos nós e provavelmente, em algum momento, talvez quando você estava começando, você usou o Juice Shop. Tenho a impressão de que todo mundo no mundo já usou o Juice Shop em algum momento para testar seu app e garantir que está realmente desenvolvendo com segurança. Então, é uma grande conquista poder ser incorporado ao que todos nós usamos. Isso é enorme. Parabéns por isso, Sunonny. Que incrível. Incrível. Então, o projeto é relativamente novo. Para alguém que está começando agora com o próprio projeto, você pode nos dizer, antes de tudo, o que ele

13:17 faz? Você mencionou antes que o criou por frustração com os CVEs. Pode nos contar um pouco sobre isso e, depois, explicar exatamente o que o projeto faz, em essência? >> Sim, claro. Vamos começar pelo momento frustrante. [risos] Então, você executa, por exemplo, uma verificação de segurança, e ela informa que há um certo número de vulnerabilidades. E aí, basicamente, para por aí. Ela disse que você tem um problema, mas a maioria dessas ferramentas não diz exatamente o que

13:50 fazer a respeito. Então, criei a ferramenta que eu gostaria de ter. A ideia é que o usuário não precise analisar um log enorme, ou se deparar com um relatório enorme gerado pelo scanner, com todos os diferentes IDs de CVE e coisas do tipo, porque, sinceramente, ninguém vai olhar esses IDs de CVE, certo? Vejo que tenho um problema e meu primeiro impulso, quando começo a pensar em como resolvê-lo, é

14:22 “certo, preciso corrigir isso agora”, porque, na maioria das vezes, os scanners são executados na integração contínua, e isso leva uma eternidade. Nas grandes empresas em que trabalhei, a integração contínua pode levar de alguns minutos a algumas horas, e a verificação de segurança acontece sempre no fim desse pipeline. Esse também é um dos motivos pelos quais criei a ferramenta. A ideia por trás dela é levar a verificação de segurança para o

14:54 workflow dos desenvolvedores. Certo. Quero que eles possam executar o scanner localmente, pelo terminal, antes de abrir um pull request, certo? Imagine que a integração contínua esteja sendo executada por algumas horas e, no fim, você veja que um pacote tem uma CVE. Isso não ajuda muito, porque você ficou ali por algumas horas e agora, além disso, precisa percorrer o log da integração contínua e descobrir o que está quebrado, certo? Então, não

15:25 só você perdeu muito tempo, como a experiência do desenvolvedor é péssima, certo? Foi por isso que criei este projeto. Então, o que é este projeto? É um scanner de vulnerabilidades em dependências para projetos JavaScript e TypeScript. Como mencionei, ele é executado localmente. É totalmente gratuito. Tem licença MIT, então não há conta nem chave de API. Você literalmente não precisa configurar nada. Basta baixá-lo do npm e está

15:57 pronto para usar. E, entrando um pouco mais nos detalhes do problema que ele resolve: quando você instala um pacote, por exemplo, na maioria das vezes não recebe apenas um pacote. Recebe esse pacote e tudo mais de que ele depende. E, depois, tudo de que esses pacotes dependem, certo? Um projeto pequeno pode facilmente ter milhares deles. Os que você escolhe são dependências diretas, e os que vêm junto são chamados de transitivos. E é também aí que, na verdade, se encontra a maioria das vulnerabilidades.

16:28 E, sinceramente, o mais complicado é que não dá para corrigir diretamente uma dependência transitiva, porque você não a instalou diretamente. Então, você pode — e não pode — atualizá-la. O que precisa fazer é descobrir qual foi a dependência que você instalou e que a trouxe junto, certo?

16:59 E então precisa atualizar essa dependência. Eu diria que é aí que a maioria das ferramentas deixa você por conta própria para descobrir o que fazer. E também é preciso bastante tempo e experiência para descobrir isso. >> Com certeza. Na verdade, temos uma pergunta exatamente sobre isso. E, para quem está acompanhando, você explicou muito bem o que é uma vulnerabilidade transitiva. É como se nem fossem pessoas que você convidou para a festa, mas alguém que apareceu junto com seu amigo, que chamou um conhecido.

17:31 Então, nem são as dependências que você instala diretamente. São as que vêm junto. E obrigado, Kumar, por esta pergunta sobre a correção que leva em conta a dependência pai. A pergunta é: como o CVE Lite lida com a correção considerando a dependência pai quando uma vulnerabilidade transitiva exige ultrapassar o intervalo de versões permitido pela dependência direta? >> Essa é uma ótima pergunta. Então, o funcionamento do CVE Lite é o seguinte:

18:04 primeiro, ele verifica os intervalos de versões permitidos definidos pela dependência pai para aquela dependência transitiva específica. Certo. Primeiro, ele verifica isso. Confere se algum dos pacotes nesse intervalo é seguro, ou seja, não tem vulnerabilidades CVE, e, se houver algum, ele o recomenda. Caso contrário, passa para a próxima versão principal e faz essa verificação.

18:35 E, quando encontra uma opção, ele a recomenda. Certo, mas o detalhe é que, como se trata de uma atualização para uma versão principal, a própria ferramenta não fará a atualização e avisará que pode haver uma alteração incompatível, certo? Então, o CVE Lite é muito transparente quanto a isso e informa que se trata de uma alteração incompatível e que você precisa ter cuidado ao fazer a atualização por conta própria.

19:07 Então, pelo que entendi, ele vai até uma camada mais profunda do que você mencionou antes. E, mais uma vez, muito obrigado pela pergunta. A maioria dos scanners de vulnerabilidade por aí vai simplesmente apresentar uma lista e dizer: “Certo, este é o problema”, mas nada realmente diz qual comando executar, e isso faz uma grande diferença para os desenvolvedores. Certo, você mencionou… Pode continuar, pode continuar, Sun. >> Desculpe, você mencionou que ele vai algumas camadas abaixo. Na verdade, ele vai muitas camadas abaixo, e vou mostrar isso na demonstração daqui a pouco. >> Sim. >> Ele faz muito mais do que os

19:41 scanners comuns. O que os scanners comuns fazem. >> Preciso perguntar: alguém entrou no chat e perguntou se o foco era JavaScript. E eu queria perguntar especificamente por que você escolheu essas duas linguagens, como as duas áreas em que queria se concentrar. >> Porque JavaScript e TypeScript são as linguagens dos projetos com que trabalho no dia a dia. Sou consultor, e a maior parte do meu trabalho é com projetos NodeJS ou

20:13 Angular. Também sou Google Developer Expert em Angular. Então, hoje, a maior parte do meu trabalho diário é em outros projetos. Tenho bastante visibilidade sobre o que está acontecendo nessa área. Foi por isso que escolhi essas linguagens. >> Certo, perfeito. E outra pergunta muito pertinente. Na verdade, ela me leva à nossa próxima pergunta: de onde vem o “Jordan CVE”, como se diz CVL?

20:44 Onde o CVE Lite se encaixa, eu acho, ao lado de outras ferramentas? Por exemplo, o npm audit ou até o pnpm? >> Sim. Então, primeiro, o npm audit é só para npm, certo? Ele não lê pnpm, não lê yarn, Bun, nada disso. O CVE Lite faz isso. Mas, além disso, o npm audit não diz qual atualização corrige a CVE que encontrou; ele só diz o que está vulnerável, em vez de

21:17 dizer qual atualização corrige a CVE que encontrou, certo? Além disso, o npm audit não faz verificações de CVE, certo? Por exemplo, se o pacote XYZ tiver uma CVE, essa CVE vai dizer que você precisa atualizar para o pacote Y. O problema é que o pacote Y ainda pode conter uma CVE, e

21:50 o npm audit não verifica isso. Certo? Então, como mencionei, minha ferramenta vai muito além disso. Ela verifica o que o OSV recomenda e continua fazendo isso até encontrar uma versão segura. >> Ótimo. Certo. Adoraria ver isso em ação. Se puder compartilhar uma demonstração conosco, acho que seria ótimo. >> Sim, parece bom. Vou fazer isso. >> Vou tirar isto daqui. E, pessoal,

22:21 obrigado. Obrigado novamente pela pergunta. [limpa a garganta] Berdenfolds. Deturpei completamente esse nome. Continuem enviando perguntas. Podem publicá-las no chat, e vou me certificar de trazê-las à tona depois da demonstração. Está pronto para eu compartilhar suas telas, filho? >> Uhum. Sim, por favor. >> Perfeito. Certo. Então, o que estamos vendo aqui? >> Certo. Vou falar sobre um pequeno serviço Express. Ele tem cinco dependências, todas fixadas de propósito em versões antigas.

22:52 É bem parecido com o aplicativo Juice Shop que você mencionou, mas em uma escala muito menor. Nada de exótico, só o tipo de coisa que você encontraria em um projeto que ninguém, sabe, que ninguém mexe há talvez um ou dois anos, certo? Então, aqui tenho o CVE Lite, o comando que já digitei, e estou mandando ele verificar a pasta atual. Certo, o que vemos aqui? A primeira coisa que quero mostrar

23:23 é que há 11 pacotes vulneráveis, como você pode ver aqui. Um crítico. Certo. E, então, cinco diretos e seis transitivos. Certo. Agora, veja a linha. Podemos ver aqui: verificação concluída, sete problemas urgentes encontrados, certo? Então, cinco desses são pacotes que escolhi e coloquei no meu packages.json. Sei os nomes deles. Sei tudo sobre eles. E, se um deles estiver

23:56 vulnerável, posso corrigir isso facilmente. É só atualizá-lo. É fácil, certo? Os outros seis, sabe, eu nunca pedi. Eles vieram porque instalei alguma coisa, e isso os trouxe junto. Não posso atualizá-los diretamente porque não são meus para atualizar. E, se eu tentar, o npm vai me ignorar ou acabar fixando algo no meu projeto que minha dependência direta não suporta ou nem precisa. E

24:26 essa proporção é normal, certo? Em um projeto real, geralmente é muito pior. Você instala, sei lá, umas 40 coisas e acaba com milhares, certo? Outra coisa que quero destacar é este selo “Corrija agora”. Isso não é simplesmente uma classificação de gravidade. A gravidade indica o quanto seria ruim se alguém explorasse a vulnerabilidade,

25:00 certo? Mas não diz se alguém está realmente tentando fazer isso. Então, são duas perguntas diferentes. E, se você simplesmente ordenar por gravidade, acaba tratando uma vulnerabilidade teoricamente crítica exatamente da mesma forma que uma que está sendo atacada agora. Certo? Então, isto usa algo chamado EPSS.

25:31 Você pode ver o EPSS aqui, certo? Isso significa Exploit Prediction Scoring System, e quero mencionar que não fui eu que inventei isso. É publicado pela FIRST, as mesmas pessoas por trás das pontuações de gravidade que todo mundo já usa, e eu combinei as duas coisas. Então, a ideia é bem simples. Para cada vulnerabilidade conhecida,

26:01 eles publicam um número: a probabilidade de que aquela vulnerabilidade específica seja explorada na prática nos próximos 30 dias, digamos. Então, é uma previsão, não uma pontuação de 0 a 10. A maioria das vulnerabilidades fica bem abaixo de 1%. E um número bem pequeno chega aos dois dígitos. Em geral, isso responde a uma pergunta diferente da gravidade. A gravidade diz, ou

26:32 pergunta: quão ruim seria isso? Já o EPSS pergunta: alguém está realmente fazendo isso? Então, o que você quer é uma combinação das duas coisas, certo? Porque uma CVE crítica que nunca foi explorada e uma vulnerabilidade média

27:02 que está sendo atacada hoje não devem ser consideradas iguais, certo? Se você tiver uma vulnerabilidade média em comparação com uma crítica, mas as chances de a média ser explorada nos próximos 30 dias forem maiores, talvez queira corrigir essa agora. Então, o selo combina as duas coisas, certo? Gravidade alta mais alta probabilidade de exploração recebe o selo “Corrija agora”, e gravidade alta sem ninguém tentando explorá-la recebe o selo

27:34 “Corrija em breve”. Basicamente, é uma ordem de triagem, não uma lista. Então, sim, essa é a resposta de triagem que eu queria mencionar aqui: 11 problemas. E aqui está o primeiro a resolver. A verificação levou cerca de quatro segundos, sem sair do terminal. Certo? Vale dizer que o que você vê aqui é o modo compacto. Essa

28:05 visão toda não mostra muita coisa, como você pode ver. Ela é chamada de modo compacto no CVE Lite e foi criada basicamente para responder a uma pergunta: tenho um problema agora, sim ou não? É como uma ferramenta de uso diário, certo? Você a executa antes de talvez abrir um PR ou antes de adicionar uma dependência, quando quer uma resposta em segundos e não quer ler um relatório inteiro,

28:37 mas ela também não mostra tudo, e isso é intencional. Então, você viu três itens aqui, embora sejam 11, e a contagem está bem ali no cabeçalho. Aqui. Certo. Uhum. E ela mostra alguns dos principais itens urgentes porque, quando você está prestes a lançar algo, precisa saber “sim, comece por aqui”, não ver a tabela inteira. Em um projeto real, porém, uma tabela completa pode ter

29:10 centenas de linhas, e nada disso ajuda você a decidir se quer fazer o deploy ou não. Mas, em um resumo, ele mostra o que está funcionando. Se uma ferramenta me diz para atualizar alguma coisa, quero saber por que ela acha isso ou por que acha que vai ajudar. E, sinceramente, você ou qualquer desenvolvedor deveria desconfiar de qualquer ferramenta de segurança

29:40 que simplesmente afirma coisas sem explicar, certo? Então, sim. Essa é uma das visualizações. Há mais duas que eu gostaria de mostrar: a detalhada, também no terminal, e a visualização em HTML, onde está o conteúdo de verdade. Mas vou fazer uma pausa aqui por um segundo, caso haja mais perguntas. >> Sim, por favor. E obrigado por mencionar isso e explicar. Publiquei no chat o site em que a FIRST explica o que é o EPSS, e

30:12 isso é muito interessante, porque você combina várias coisas para chegar a uma forma de pontuar o problema. Assim, quando você vê que ele é crítico, pode confiar que, sim, é algo de que preciso cuidar agora. Sei que priorizar o trabalho é um grande desafio para quem mantém projetos. Então, adorei isso. Mais tarde, vou ter que te chamar de canto e perguntar se você foi criticado por esse tipo de modelo seguro novo, Jev, porque parece que isso talvez seja um problema de classificação em que ele poderia ajudar. Mas temos uma pergunta

30:44 E obrigado por perguntar de novo, Kumar, sobre o CVE Lite oferecer suporte à verificação de arquivos de lock do bun, além de monorepos com npm e yarn. >> Sim, isso é totalmente compatível. Oferecemos suporte a bun, a yarn e, por enquanto, a PNPM. Então, tudo isso é compatível. Sim. >> Incrível. E obrigado, Elvis, por ajudar no chat. Acho que o ponto sobre ser apenas MPN era a limitação do MPM audit, como ele mencionou.

31:14 Ah, ele disse que não há MPM, mas essa é a limitação do MPM audit, e esta é uma ferramenta completamente diferente. Hum, certo, ótimo. Então vamos dar uma olhada em como é o BVOSE. >> Parece bom. Sim. Certo. Então, estou executando o comando CV light de novo, na mesma pasta, com as opções verbose e all. Certo. Hum, vou começar do início de novo. Aqui podemos ver que a saída é

31:44 diferente, certo? No início, temos as tabelas de comandos de correção. Então, primeiro vemos um resumo do que está acontecendo com o projeto inteiro. Vemos alguns dados aqui: quantos pacotes você tem, quantos problemas, quantos CVEs no total etc. E aqui vemos as tabelas de comandos de correção. Certo. As tabelas estão ordenadas por gravidade, de crítica a alta e média. Então, vemos as categorias crítica e alta, e não temos nenhuma média agora.

32:16 Hum, essa também é a parte em que eu gostaria que alguém avaliasse a ferramenta. Cada aviso vem com uma correção sugerida, como mencionei da última vez. Por exemplo, no caso de AX iOS, este aqui: tenho atualmente a versão 0.21.1 instalada, e a maioria das ferramentas pega esse número e o apresenta para você.

32:46 Elas dizem: “Use esta versão, instale-a e está tudo certo. Você deve estar seguro.” Mas nós, como eu disse, verificamos se essa versão é realmente segura antes de recomendá-la. E, se não for, passamos para a próxima versão publicada, depois para a seguinte, e assim por diante, até encontrar uma que realmente seja segura. Certo. E esta ferramenta mostra o que está fazendo. O aviso 0212

33:21 foi o que o OSV nos informou. Mas o alvo que podemos ver aqui é a versão 0.33.0. E é essa que recomendamos de fato. Então, ela verificou 23 pacotes ou versões, e eles ainda estão vulneráveis, certo? Desculpe, 22 ainda estão vulneráveis. No total, verificou 23. E, se tivéssemos simplesmente confiado no aviso, você teria atualizado para

33:54 basicamente zero, certo? A versão 21.2 parecia resolver o problema, mas ainda é uma versão. E esse é o modo de falha que me preocupa, porque é invisível, certo? Nada dá erro, o número diminui, mas você continua sem estar seguro, certo? E imagine ter que fazer esse trabalho por conta própria. Imagine atualizar da versão 21 para a 21.2 e executar o scanner que você estiver usando,

34:25 executar o scanner de novo e ele dizer que você ainda está vulnerável, certo? E talvez a versão 21.2 recomende a 21.3 e, depois, a 20.44, e assim por diante. Então, imagine fazer esse exercício manualmente 22 vezes. Imagine como isso é frustrante para quem desenvolve. E essas são as duas colunas aqui: verificadas e ainda vulneráveis, seguindo a mesma ideia

34:57 em cada linha. Então, temos o número de itens verificados e quantos deles ainda estavam vulneráveis. Podemos ver low dash aqui: três verificadas, e duas ainda com problemas. E o minimist: o que temos aqui para o minimist? Uma verificada e limpa logo de primeira. E, quando não consegue encontrar uma versão segura de jeito nenhum, a ferramenta informa isso, em vez de dizer que conseguimos corrigir o problema

35:29 ou encontramos uma versão. A ferramenta vai informar se não conseguirmos encontrar uma. Então, a melhor opção talvez seja descontinuar esse pacote ou migrar para outro. Certo. Vou fazer uma pausa aqui de novo para perguntas. >> Obrigado, Sono, e obrigado por acrescentar esse contexto. Estou olhando a tabela. Ela é bem detalhada. Imagino que a visualização HTML tenha ainda mais informações. Mas vamos ver

35:59 as perguntas do público. Acho que temos uma pergunta sobre como executar a ferramenta. John, espere só um pouco. Vamos chegar nisso no final, antes de falar sobre como contribuir com o PR. Claro que você pode executá-la localmente, mas vamos falar um pouco sobre isso. Talvez Sono possa explicar como fazer isso antes de falarmos sobre contribuições. Mas vamos à pergunta de Udith. Obrigado por perguntar: como o CVA light se diferencia de ferramentas padrão, como o MPN audit e o Snyk, em termos de velocidade na resolução do grafo de dependências e de correções práticas?

36:29 Acho que esta tabela conta um pouco dessa história, mas, se houver mais algum detalhe que você queira acrescentar… >> Sim, o Snyk obviamente faz muito mais, certo? É um produto comercial. Ele cobre muitas linguagens, não apenas JavaScript. Nós nos concentramos especificamente em JavaScript e TypeScript, desculpe. Queremos garantir que sejamos os melhores no que fazemos. É por isso que nos concentramos em uma única coisa. Eu diria que somos

37:02 melhores na correção de problemas. E, obviamente, somos gratuitos, certo? Para usar o Snyk, você teria que pagar. Por exemplo, executei a saída de SBOM que geramos contra a deles, no mesmo repo, e recentemente obtive o mesmo conjunto de pacotes. Mas a deles é apenas um inventário, sem dados de vulnerabilidade. Essa é basicamente a diferença. Sim. >> Certo. Ótimo. E, para quem não sabe o que é uma SBOM, é a lista de materiais do software. E você a tem aqui? Esse é um dos componentes do CV light. Uau, uau, uau. Certo. Vamos dar uma olhada rápida para ver se há outra pergunta. “npm install” — e obrigado mais uma vez por estar aqui. “O ber deck é uma instalação do npm que esconde uma dependência transitiva, por exemplo, lagger. Não sei quais ainda são necessárias.” >> Sim, isso é o que eu chamaria de

37:32 caixa-preta, ou magia negra, do npm. O npm esconde muitas coisas ou as ofusca, então você não consegue realmente vê-las. Então, nem mesmo do ponto de vista do npm audit é fácil saber o que é transitivo e o que não é, ou qual é o caminho exato da dependência transitiva até a raiz. Outro problema que vejo no próprio npm audit é que, em muitos casos, já vi o npm

38:05 audit até recomendar o uso de force ou a configuração de legal… legal… desculpe, legacy deps. Às vezes, também recomenda o uso de overrides. Nós não fazemos nada disso, porque nosso objetivo é tornar seu projeto o mais seguro possível. Usar overrides não vai ajudar. É apenas um paliativo, certo? Você adiciona overrides uma vez e, acredite, depois que eles estão lá, você nunca vai

38:36 corrigi-los. Na maioria das vezes, eles simplesmente ficam lá. É como código ruim, certo? [risos] >> Algumas dessas dependências ficam perseguindo você e, em algum momento, acabam vindo atrás. Certo, vamos fazer mais uma pergunta e depois passamos para a visualização HTML. Estou muito animado para ver isso. E, de novo, uma pergunta do Kumar, obrigado. Ao corrigir vulnerabilidades transitivas, como as do body-parser e do under express, o CV light injeta overrides de pacotes? Na verdade, estamos falando disso agora: usa resolutions ou tenta atualizar diretamente a dependência raiz?

39:09 >> Essa é uma ótima pergunta. Nós nunca usamos overrides; não queremos usar overrides. Na verdade, o TVL tem um recurso que permite verificar seus overrides. Se você executar d-check overrides, ele permitirá que você verifique seus overrides. Ele executará todo o algoritmo para garantir que seus overrides ainda estejam funcionando ou se são apenas entradas órfãs de que você nem precisa mais. Além disso, tentará aprimorar seus

39:39 >> Essa é uma pergunta muito boa. Nunca fazemos substituições; não queremos fazer substituições. Na verdade, o TVL tem um recurso que permite verificar suas substituições. Então, se você executar d-check overrides, poderá verificar suas substituições. Ele vai percorrer todo o algoritmo para garantir que elas ainda estejam funcionando ou se são apenas substituições órfãs de que você nem precisa mais. E, além disso, vai tentar melhorar seu

40:10 do projeto para que você possa realmente se livrar dessas substituições. Então, não fazemos nada disso. >> Ótimo. Certo. Vamos dar uma olhada nesta visualização HTML, por favor. >> Antes de irmos para o HTML, quero mostrar mais uma coisa aqui. >> Ah, claro. Uhum. Se não tiver problema, vou diminuir um pouco o tamanho, porque vejo que a tabela está se sobrepondo. Pronto. Certo, >> agora sim. Perfeito. >> Isso ficou muito perfeito. Quer dizer, ficou muito melhor. Quero mostrar aqui: dê uma olhada no pacote express,

40:43 certo? O Express, porque está fazendo algo diferente. O Express está mostrando aqui, por exemplo, o aviso 14192, e o alvo é 4223, que é superior ao que a validação sozinha teria escolhido. E aqui está o motivo. Se olharmos, podemos ver que, na verdade, aqui na tabela de baixo, há seis pacotes que são incluídos pelo express, ou dos quais ele depende.

41:14 Certo? Vemos aqui a raiz. Eu, pessoalmente, nunca digitei path-to-regexp, QS ou express, nem nenhum dos outros, certo? Eles simplesmente vieram junto com o express. Essa é a única razão de estarem na minha máquina. Então, a ferramenta não está me dizendo para instalar seis pacotes; está me dizendo para atualizar o express, certo? E essa é a pergunta que acabamos de responder. A única coisa que escolheu uma versão

41:45 nova o suficiente para deixar de incluir as cópias vulneráveis dos seis pacotes. Certo. Então, de novo, pensem nisso. A CLI examinou o Express, ou examinou as CVEs de todas as seis dependências transitivas do Express, e descobriu para qual versão do Express você precisa atualizar para corrigir todas essas

42:16 constatações. Certo. Só quero garantir que isso fique claro: a ferramenta não corrige apenas um pacote individual. Se um pacote tiver vários pacotes transitivos, o que é normal, e muitos desses pacotes transitivos tiverem vulnerabilidades, a ferramenta tentará corrigir todos eles, buscando uma versão que funcione para todos

42:47 eles. Espero que faça sentido. >> Não, isso é muito complicado. >> Não, isso é muito impressionante, e agradeço por garantir que tivéssemos uma visão completa da tabela, porque ela ilustra claramente esse ponto. >> Ótimo. Certo, vamos passar para o relatório HTML. >> Perfeito. Vou tirar sua tela enquanto você abre esse aplicativo. Sim, >> vou dar uma olhada rápida nos comentários. Obrigado, Rak, pelo comentário de que isso é importante para desenvolvedores de JavaScript e TypeScript.

43:19 Agradeço o foco, isso é ótimo. E acho que essa é uma diferença fundamental em relação à maioria das coisas que existem por aí, certo? Vocês realmente se mantêm na sua área. Obrigado também a Nurio por estar aqui, e a Misam. E agradeço a todos vocês por responderem no chat e explicarem o que é CVE. Muito obrigado. Sei que alguns de nós talvez não estejam familiarizados com esse assunto. Então, agradeço por ajudarem uns aos outros no chat.

43:50 Maravilha. Então, vamos compartilhar sua tela para podermos ver. Ah, que legal. Gostei. Explique essa visualização para mim. Eu adoro o terminal, mas não resisto a algo bem projetado. Vamos ver. >> Certo. Vamos lá. Certo. Basicamente, é a mesma verificação, mas para um público completamente diferente. Certo. >> Certo. >> A saída do terminal, todo mundo adora. Você adora. Eu adoro. É ótima para mim agora, para o que

44:22 estou fazendo, mas isto é para todo mundo. Quem é todo mundo? Sua equipe de segurança, sua liderança, o auditor que perguntou o que você está entregando, ou você mesmo daqui a três meses, quando tiver esquecido que adiou alguma coisa, certo? E já explico por que digo três meses. Basicamente, no topo, aparecem as mesmas contagens. Certo? Você vê tudo assim que chega aqui. Mas o mais importante é olhar

44:52 o que vem logo depois, porque essa é a parte que mais me importa. Antes de mostrar a lista de problemas, isto apresenta o plano. Certo. >> Ahá. >> Então, são cinco correções diretas. Agrupadas por gravidade, cada uma com um comando e um botão para copiar. Certo. Você clica aqui, copia o comando, executa no terminal e pronto: pode atualizar. O mesmo vale para este. E, aliás, os mesmos comandos estão

45:22 disponíveis no terminal. Esqueci de mencionar, mas eles estão lá no terminal, tanto no modo compacto quanto no modo detalhado. Então, estão sempre disponíveis. Essa também é uma das maiores diferenças, certo? Você executa a ferramenta, vê que há uma vulnerabilidade, recebe um comando de correção, copia e cola, executa npm install e pronto. Certo. Há dois comandos: um para as vulnerabilidades críticas — temos as críticas aqui, então todas ficam agrupadas no mesmo grupo — e outro para a vulnerabilidade alta

45:54 aqui. Certo. E, quando uma atualização envolver uma mudança incompatível, isso será informado antes de você executá-la. Por exemplo, JSON web token: da versão 8.51 para a 9.0.0. Mais uma vez, avisamos que é uma mudança incompatível. Então, confira seu código e verifique se nenhuma API foi afetada, porque provavelmente você não vai querer executar esse comando

46:26 numa tarde de sexta-feira como hoje, enviar as alterações e depois sair para o fim de semana, certo? Acho que o express aqui é interessante. Dá para ver que ele não apresenta apenas uma versão; indica uma correção específica para um caminho, certo? Isso significa que você deve executar o comando e fazer uma nova verificação, porque pode haver outros caminhos que ainda precisem de ajustes.

46:58 Então, basicamente, a ferramenta se recusa a prometer mais do que pode comprovar. Ela sabe que essa atualização corrige o caminho que consegue ver. Mas não vai dizer que o problema todo desapareceu quando não consegue verificar isso. Até aqui faz sentido? >> Faz muito sentido. E vocês estão recebendo muitos elogios pela formatação. >> Ótimo. Agora vamos olhar a tabela.

47:30 Certo. É nesta tabela que ficam os detalhes. A EPSS aparece como porcentagem, como você pode ver: a probabilidade de exploração, em vez de um rótulo. Ao lado, está o nível de prioridade. A coluna da raiz é a que eu mais gosto. Para uma constatação transitiva, ela informa qual das suas dependências a trouxe para o projeto. Deixe-me ver se consigo encontrar uma. Acho

48:03 que é esta. Certo. Esta é transitiva. A raiz é express. Agora posso expandi-la. Se eu expandir, vejam só: aparece o projeto express e, em seguida, QS. Mas lembram que dissemos que há outro caminho disponível, que é projeto, express, body-parser e QS? Dá para ver quantos níveis a ferramenta precisa percorrer para descobrir para qual versão deve atualizar. E

48:34 como eu disse, aqui aparece que você pode atualizar da versão 4.17.1 para a 4.22.3 para corrigir esse problema específico. Também temos aqui, mais uma vez, o selo de correção imediata e os comandos para você copiar e colar. >> Adorei. E isso me leva à próxima parte. E, por favor, me interrompa se eu estiver me adiantando. Estou só olhando o relógio, mas, sobre copiar e colar: você está executando isso localmente, certo? Isso está

49:04 sendo executado localmente agora? >> Sim. Você basicamente sempre executaria isso localmente. Também temos uma versão de CI, que faz a mesma coisa. >> E era isso que eu estava tentando dizer antes: talvez você precise disso daqui a três meses, mas talvez se pergunte como obter esse relatório daqui a três meses. A vantagem deste relatório é que ele é totalmente independente. Todos os dados, todos os estilos, tudo está dentro deste simples arquivo HTML. Certo?

49:38 Então, você poderia literalmente pegar este arquivo, enviá-lo para qualquer pessoa e, se ela clicar duas vezes nele, verá exatamente a mesma coisa. Nada quebrado, todos os mesmos dados, tudo está lá. Além disso, se você executar isso no CI, tem a opção de exportá-lo como parte da GitHub action, e ele será armazenado no próprio GitHub. Assim, você pode versionar todos os relatórios recebidos para fins de auditoria.

50:12 >> Isso é incrível. Certo. Então, você sempre tem o registro. >> É, >> você sempre tem o registro. Exatamente. E você consegue compartilhá-lo. Isso é, isso é, isso é fantástico. >> Certo, >> há mais alguns recursos que vocês podem ver aqui. Dá para filtrar pelo pacote. Esta tabela é pequena, mas, se você tiver um pacote grande — quer dizer, um projeto grande, desculpe — talvez queira pesquisar um pacote específico. Por exemplo, você pode pesquisar aqui pelo nome do pacote, e ele vai filtrá-lo para você. Também dá para filtrar por gravidade.

50:44 E também apenas dependências diretas ou transitivas. Certo. Então, é isso. Essa é a demonstração que eu tinha preparado. >> Isso é incrível. Isso é incrível. Certo. Então, se eu quiser instalar isso agora mesmo, tenho algumas opções. Posso executá-lo no CI, se quiser, ou posso executá-lo totalmente localmente, como no exemplo da demonstração que você nos mostrou. Você o executou localmente. Mas, claro, depois posso pegar os resultados, e esse mesmo HTML vai

51:17 conter tudo de que você precisa. Imagino que você poderia pegar esses resultados e enviá-los para um agent, como um prompt do tipo: “Vá corrigir isto”, ou “Dê uma olhada neste relatório e avalie como atualizar apenas as descobertas críticas, seguindo somente as recomendações do relatório”, porque essa é outra parte tão importante do projeto e, na minha opinião, o que o diferencia de muitos outros por aí: vocês fazem bastante pesquisa antes de essas recomendações aparecerem naquela tabela. Acho que isso faz uma grande diferença.

51:47 Sim. É uma ótima maneira de não desperdiçar tokens nem simplesmente mandar um agent numa busca infrutífera; você realmente sabe no que focar. >> E, no momento, o projeto está hospedado no GitHub, claro, e as pessoas podem cloná-lo e baixá-lo. Podemos falar um pouco sobre as contribuições que você recebeu? Sei que, neste momento, você é o único mantenedor principal do projeto, certo? >> Sim. Sou o único colaborador principal, mas já há várias pessoas contribuindo. >> Incrível. Não sei quantas pessoas temos,

52:18 provavelmente umas 40 ou 50. Então, se quiser contribuir, há issues marcadas como good first issue, e algumas são voltadas a pessoas que estão fazendo sua primeira contribuição open source. O que fazemos — e eu especificamente me certifico disso — é o seguinte: claro, quando você começa a contribuir com projetos open source, fica muito empolgado e quer fazer o máximo possível, certo? Então, há issues com o rótulo good first issue, mas também há issues exclusivas para quem está contribuindo pela primeira vez.

52:50 >> Gosto disso, é algo diferente no seu repo. >> Exatamente. Digamos que eu seja um colaborador de primeira viagem, mas já saiba o que está acontecendo neste repo e já tenha feito alguns PRs. Talvez eu não queira pegar uma issue exclusiva para quem está contribuindo pela primeira vez, porque a ideia é justamente essa: queremos que as pessoas comecem a contribuir cada vez mais e se sintam à vontade, certo? >> Adorei isso, e é uma ótima dica para mantenedores que estão tentando atrair

53:20 pessoas para participar dos projetos: criar esses rótulos que deixam muito claro qual é o caminho para contribuir, levando em conta que, sabe, talvez isso não seja para mim. Adorei isso. É incrível. Certo. Vamos ver as perguntas do chat. Vou dar uma olhada. Há algumas perguntas sobre os problemas, e convido você, Rak, a voltar ao começo, porque falamos sobre o que finalmente irritou Sonu o bastante para ele dizer: “Vou fazer isso para mim mesmo.” [risos] Convenhamos, isso não representa tipo 99% das histórias de origem da maioria dos nossos projetos? Em algum momento, ficamos frustrados o bastante com uma coisa e decidimos resolver por conta própria. Maravilha. Conte um pouco sobre o que vem por aí para o projeto. O que está no roteiro? O que você está esperando ansiosamente? >>

53:54 Sim, então a próxima coisa que estamos experimentando é dar mais visibilidade ao projeto dentro do GitHub, certo? Já estamos tentando descobrir como podemos torná-lo ainda melhor em um ambiente do GitHub.

54:27 Certo, sabemos que no terminal ele já é ótimo. Já tenho alguns usuários grandes adotando o projeto; alguns governos já estão usando, como o governo francês e a Colúmbia Britânica. Então, já há grandes nomes por trás do produto. >> Mas queremos que mais desenvolvedores usem o projeto. Queremos que você o use mesmo que seja para seu projeto de hobby, mas talvez você nem sempre tenha tempo para executá-lo no terminal. E muita coisa acontece no GitHub. Então, o que estamos tentando experimentar é,

54:57 dar a você os mesmos algoritmos e os mesmos recursos de correção dentro do próprio GitHub. Imagine que você abra um PR e ele tenha um problema. Não queremos que você faça como com outros scanners, tendo que acessar os logs do GitHub para descobrir o que precisa corrigir. Queremos criar um comando e dizer: “Ei, isto está vulnerável. Este é o comando. Execute-o e atualize o PR.”

55:29 >> Ahá. Isso é muito poderoso. Muito, muito poderoso. Então, você está trabalhando ativamente nisso, incorporando mais o projeto a todo o ciclo de vida de desenvolvimento de software. É assim que a segurança deveria funcionar. Mas, como a maioria de nós pode confirmar, só começamos a prestar atenção quando as coisas dão errado. Infelizmente, é assim. Certo. Deixe-me perguntar rapidinho, e vou conferir as outras perguntas para ver se há

56:00 algo que eu deva mencionar. Com certeza, conectem-se entre vocês, pessoal. É para isso que estamos aqui. Compartilhem os perfis do LinkedIn uns dos outros no chat. Vamos ver seus perfis do LinkedIn e conectar vocês. Façam networking. Esses eventos também servem para isso. Vamos ver. Perguntas rápidas: qual foi a última coisa que você enviou? E o que levou você a fazer isso? Hoje publiquei um tuíte engraçado sobre mensagens de commit, mas vamos falar do conteúdo da mudança. [risos] Qual foi a última

56:31 alteração que você enviou antes de vir para cá hoje? Essa é uma boa pergunta. Escolhi tantas coisas, para falar a verdade. >> Você está tipo: “Todas as coisas.” >> Sim. Mas, como eu disse, acho que o que mais estou priorizando agora é a integração com o GitHub. Acho que fiz algumas correções nela esta manhã para garantir que o comentário que publicamos no PR tenha todas as informações de que o desenvolvedor precisa para seguir em frente.

57:04 >> Incrível. Incrível. Certo. E então, já sabemos como contribuir. Vamos ao repositório. Primeiro, quero que todo mundo acesse o repositório agora mesmo e deixe uma estrela. Essa é a única coisa que você pode fazer agora para apoiar a gente e apoiar este programa. Deixem a estrela para que ele entre nos destaques e chegue a mais desenvolvedores que talvez tenham interesse em explorar esse caminho para contribuir ou que estejam simplesmente procurando exatamente essa solução. Estou animada. Estou pensando que, claro, vou dizer algo que provavelmente vai irritar as pessoas, mas

57:34 Acho que há possibilidades de expandir isso para workflows agentic automatizados, certo? Você recebe esse relatório maravilhoso com tudo de que precisa e, então, pode iniciar esse ciclo de autorreparo, em que o agent descobre o que precisa fazer. >> Sim. Uma coisa que quero mencionar é que você falou algumas vezes sobre IA e agents. >> Sim. Sim. Sim. >> O próprio CVE Lite não usa IA. Certo? Então, agora tudo gira em torno de IA e coisas do tipo, mas, pela minha experiência e pelos meus testes, já vi a IA muitas vezes recomendar a coisa errada quando se trata de…

58:06 >> Exatamente. Exatamente. >> E o CVE Lite, na verdade, inclui skills de IA. Certo? Então, se você executar as skills, pode pedir ao seu agent que execute uma verificação com o CVE Lite, e ele vai gerar um arquivo JSON que pode ser usado para corrigir todos esses problemas. Assim, você nem precisa fazer isso, certo? O agent deve conseguir identificar

58:38 o arquivo JSON e as instruções das skills e descobrir como corrigir tudo sem seguir na direção errada. >> Exatamente. E essa é a parte fundamental que falta na maioria dos produtos desse tipo. Sim, não dá para delegar tudo: ainda há muita instabilidade, e nove em cada dez recomendações estão erradas. [risos] Então, você ainda precisa do discernimento de uma ferramenta bem desenvolvida, que dê recomendações nas quais você possa realmente confiar. Isso é fantástico. Então, acho que essa é uma das

59:09 minhas coisas favoritas neste projeto. Certo. E agora, mais uma pergunta rápida para quem vai assistir, ao vivo ou depois: venham conhecer o projeto. Se vocês pensarem: “Adoro isso, e seria ótimo se também tivesse isto”, como podem propor isso a você? O que mais faria você considerar incluir algo no projeto, além de, é claro, a pessoa construir a funcionalidade e contribuir com ela por meio de um PR? Como você prefere que façam?

59:41 Sei que sua prioridade agora é integrá-lo profundamente ao GitHub, mas há mais alguma coisa que possa ajudar você a decidir em que se concentrar? >> Então, é mais uma questão de como as pessoas podem entrar em contato comigo, certo? >> Sim. Sim. >> Sim. As pessoas podem falar comigo pelo LinkedIn, pelo GitHub, pelo Twitter. Mas, se você tem interesse em implementar uma funcionalidade específica ou encontrou um bug ou

1:00:11 alguma coisa, eu realmente recomendo abrir um bug, uma issue no GitHub, com um package.json reproduzível e, de preferência, um relatório que você consiga gerar com o CVE Lite, para podermos investigar. E, obviamente, adoramos quando você propõe a issue e também a corrige, certo? Vamos ajudar você tanto quanto pudermos. >> Adorei. Ouvi alguém dizer… “Quem me falou isso esta semana?” É assim que os amigos executivos fazem. Tipo,

1:00:42 vocês não trazem só problemas; trazem soluções. [risos] >> Sim. >> Não para os executivos; não, os executivos não. Nós, os peões. Os trabalhadores. Os trabalhadores. Incrível. Isso foi muito informativo. Fico muito feliz por conhecer esse projeto agora. Quero testá-lo. Quero baixá-lo e passar alguns dos meus próprios projetos por ele. E que refrescante encontrar algo que não tem a IA como base. É uma skill e um complemento para IA, e não algo totalmente dominado pela IA como fundamento daquilo que foi criado. Então, agradeço o

1:01:14 cuidado que você teve ao desenvolver isso. Muito obrigada por estar aqui. Agradeço muito. >> Obrigado pelo convite. >> Certo. Então, pessoal, podem entrar em contato. Vou colocar seu LinkedIn no chat também, para as pessoas poderem clicar. E, para meus amigos no LinkedIn, só um instante. Leva um tempinho para eu ir até lá. Tenho que copiar e colar o link por conta própria. Pronto. Podem adicionar o Sonu. E sigam o Sonu no X também, se

1:01:45 quiserem. E mal posso esperar para ver todas essas estrelas chegando ao repositório hoje. Por favor! Sonu, mais uma vez, obrigado. Tenha um ótimo fim de semana. >> Obrigado. Você também. Certo, isso foi extremamente informativo e despertou minha curiosidade. Fico pensando em que outros projetos estão fazendo isso de um jeito mais nativo, realmente se concentrando nos fundamentos antes de colocar um agent para trabalhar. E que ótima maneira de começar a aprender sobre o universo dos CVEs: com uma ferramenta que se baseia nisso.

1:02:17 Então, agradeço a todos vocês por começarem a explorar o projeto agora. Sigam o Sonu nas redes sociais; encontrem e adicionem o Sonu no LinkedIn. E não se esqueçam de que, na semana que vem, estarei em San Jose para o WeAreDevelopers World Congress. Se quiserem ir comigo, mandem uma mensagem, uma DM. Vou colocar aqui o meu perfil que mais uso. [risos] Então, podem me mandar uma DM por lá e vou conseguir um ingresso para vocês. E

1:02:47 não se esqueçam de que o nosso sorteio da Universe ainda está acontecendo. Faltam cerca de duas semanas. Só precisam preencher um formulário curto e, depois, vamos usar uma ferramenta de sorteio para escolher um vencedor. E não, cada pessoa só pode enviar um formulário. Estou sendo muito rigorosa com a forma como fazemos o sorteio, para que todos tenham uma chance justa. Muito obrigada a todos. Tenham um ótimo resto de dia. Não trabalhem mais. Digam a eles que a Andrea disse que vocês já podem ir para casa. Obrigada por estarem aqui, apoiarem o open source e este

1:03:17 stream do Open Source Friday. Até a semana que vem. >> [música] >> Calor. Calor. Calor.

1:04:00 Calor.

Transcrição original

[00:15] [music] [music] [music] [music]

[00:49] [music] Heat. Heat. [music] Heat. Heat.

[01:34] Heat. Heat. [music] >> [music] [music] [music]

[02:07] >> Heat. Heat. [music] >> [music] [music] >> Heat. Heat. [music] [music] Heat

[02:47] [music] [music] up here. >> [music] [music]

[03:18] [music] >> No one is more excited about that animation than >> [laughter] [gasps] >> Hello friends. Welcome to OpenSource Friday. Welcome to Friday. You made it. You made it. Yay. Thank you so much for joining. I know we have folks joining from all over the place. And of course, I’d love to know where you’re tuning in

[03:48] for. So, for those of you who are here for the first time, welcome. I’m Andrea Griffiths, a Colombia dev in all the places, and it’s my pleasure to be with you today. So, welcome Abas, welcome MD, welcome Amy. Amy, you are such a great friend of the show. Thank you for always coming and supporting us. We notice. Thank you. You’re appreciate it. Welcome, Ankush. Welcome Abbas. Welcome, Daniel. I adore that animation. I think

[04:21] our design team did such an incredible job. They they truly are coded in what they do. Well, again, I’m Andrea and it’s my pleasure to be with you today. Today I’m bringing you a project that is very exciting, very interesting. But before we get to our guest of the day, I have a couple of housekeeping items. Starting with the fact that next week, myself and my goodness, several of my team members, this is turning into a bit of a mini summit offsite for us. We’ll

[04:52] be in San Jose, California for the We Are Developers Conference. It’s called We Are Developers Congress. If you have not been to any of the We Are Developers, uh I mean, I encourage you to Well, I got a couple of encouragements for you. This is it started as an European conference. So, the first conference series was in Berlin, and so it always had like a really kind of fun vibe to it. I’ve been to the European version in Berlin twice.

[05:23] This year, they’re taking the show in a row. San Jose, California will be the first stop which is happening next week in San Jose again September 23rd through the 25th and then they are actually going to India. So I know we have quite a few of you who are joining us from India and I welcome you all to go check out the website. I’m going to drop you the link to the site right now on the notes so that you have it so that you go you take advantage of it. That’s for the

[05:55] one that’s going to be happening next week. Um, the tickets are about $1,400. So, it’s a big investment that you get to make on yourself. But I also have an invitation for you and for the open source Friday uh community, I thanks to the generosity of the community of the we are developers world congress, I have some passes that I can give to you. So if you are in San Jose next week, if you have a

[06:27] way to get into San Jose next week, this is the schedule what you see on the screen. On this day zero, the GitHub team is running a variety of workshops. I might I’m not sure if we have the certifications team coming or not, but there’s going to be a lot happening. So you want to be there. And then we have two days of talks. I’m speaking myself on Friday. So, if you feel like you could come, even if you can only come to one of the days, I know most of us can just take like the whole week to go to the conference, I would love you to send

[06:59] me a DM so that I can get you registered um at the great price of no dollars for [laughter] you. So, and again, thank you so much to the We Are Developer Congress organizing team. I appreciate you uh for allowing me to be able to pass along this opportunity to so many of you. So, if you have tech friends in San Jose and you’re like, “What?” or San Francisco, they are running shuttles from San Francisco to San Jose. Um, if once you get your ticketed, then you’ll get all

[07:29] the information and you know exactly what to do. But there is quite a really really interesting schedule of talks that are going to be happening. Um, a lot of big names and they run it in concurrency. You see how there is like several talks happening at the same time. So you have an opportunity to literally go and learn whatever it is that you want to learn. So let me know if you want to be there. I will be so happy to facilitate a ticket for you. That is housekeeping item number one and I promise I’ll be quick with the next one. Our giveaway for GitHub Universe is

[08:01] still open. So we are giving away one ticket for Gearhub Universe which is our our congress our big conference happening in formation in San Francisco September September October 28th and 29 friends I’ve said it once I say it again this is ner super bowl if you have been to GitHub universe share in the chat let me know how was your experience it’s one of my favorite conferences I think it’s a conferences that I would buy a ticket to go to even like if I didn’t work here I would still buy a ticket to go to

[08:32] that. So, um I should have come here prepared with some discounts or something. I don’t have anything right now, but maybe by the end of the show I will. So, in the meanwhile, please enter the giveaway. You can go to gh.io/in and all you have to do is fill out a form. Basically, just tell me that you can find your way to San Francisco and I’ll be happy to facilitate a ticket for you. And if you’re not shy and want to meet in person, I’m also happy to make that happen. So, all right, those are my housekeeping items of the week. Now,

[09:04] let’s get to it. I got to quickly take care of somebody that’s insistent on spamming our chat. Friends, don’t spam the chat. Be a good citizen of the chat, please. Let’s be good citizens of the chat. If you want to network amongst yourselves, talk to one another. I love that. Send each other connections. That’s amazing. Uh, but if you’re just spanning a bunch of stuff, I’m going to mute you and probably block you. I come fighting today. But thank you. Thank you for being here. All right. Our guest today uh well, as you know, Open

[09:35] Source Friday is a show that is for you for open source. And we’re we’re we’re going to be learning about a project in specific today. Uh that is called CVE Light CLI. I am a big fan of CLI projects. I love that. I I think CLI make our lives easier. and a project that’s focused around security and CVS is always going to be a favorite of mine too. So I am thrilled today to be joined by Sonuku Kapoor who is the creator of CVE light. Um and I’ll go ahead and put

[10:08] the ripple link right here so people can go ahead and take a spin by it. But uh CV light CLI is a dependency vulnerability scanner for JavaScript and TypeScript projects. Uh and it’s actually part of the OASP. So, welcome Sonu. Thank you for being here. >> Hi, Andrea. Thank you for having me. >> So excited to learn a little bit more about uh CVE Light CLI. Sonu, you’ve been building in public since like 2026. Uh and you have what, like 50,000 mpm

[10:39] downloads in under four months, which is wild. >> And the project now is part of the OASP lab. When did that happen? When did it become part of OASP? Can you tell us for the people who don’t know what OAS is? That would be like a great starting point and then we can get to chatting. >> Yeah, for sure. So, I started this um project back in April I think um and and started it because you know out of frustration of uh you know the existing

[11:11] um processes that I in place to fix EVE. So um what happened is um after a few weeks starting the project it it kind of took off in the community um you know journalists reached out reporters reached out went crazy and then um I applied at OS and OS was basically the uh the governor authority behind security um practices right we all know the over

[11:43] top 10 list, right? For example, so >> uh major companies, governments follow the top 10 uh to make sure that their projects are safe. So getting into OAS was a huge deal because you know they um they they they thoroughly review the your project before >> Oh yeah. >> you know they can put their own stamp on it, right? So within a few weeks uh I was part of OASP um and a few months

[12:14] later the project had graduated to a lab project. So first you start with an incubator project um once you proof yourself you you uh go into the lab project and I think there’s another step after that which is the final one. I don’t remember the name or the the status but um that comes like a year or two years after. >> That’s amazing. And for those of you who might have might think like oh I’ve never used uh or even if you’re not in security and like maybe vulnerabilities is not something that you’re focused on

[12:46] for one this affect us all and you probably at some point or another maybe when you first started you use juice shop I feel like everybody in the world has used juice shop at one point or the other to test against your app to make sure that you’re actually building safely. So this is a big accomplishment to be able to be incorporated into all of us is huge. Congratulations on that, Sunonny. That’s amazing. Amazing. So, the the project is relatively new. Um, for somebody who’s just getting started uh with the project itself, can you tell us first of all, what is it that it

[13:17] does? Um, you mentioned earlier that you build it out of your frustration with CVS. Can you tell us a little bit about that and then exactly what is it that the project does in essence? >> Yeah, sure. Let’s start with the frustrating moment. [laughter] Um so now you you you run in um you run a security scan for example and it tells you that you have a certain number of vulnerabilities and then basically it stops right so it has told you that you have a problem but basically most of them do not uh exactly tell you what to

[13:50] do about it okay so I built the thing that I wanted right so um the idea is that the user doesn’t have to look at a huge log or comes to a hu log of the report that the scanner outputs with all the different CVE ids and so on because honestly nobody’s going to look at those CV ids right I see I have a problem um and my first um you know when I go into this solution mode my first instinct is

[14:22] okay I need to fix this now because most of the time scanners run in CI and that takes forever to run. So most enterprise companies that I have worked at CI can take anywhere from you know couple of minutes to couple of hours and the security scan is every time at the end of that pipeline. Um and that’s also one of the reason why I built this. Um the idea behind that is I want to bring the security scan into the developers

[14:54] workflow. Okay. I want them to be able to run the scanner locally from their terminal before they create a pull request, right? Um, so imagine if your CI running for couple of hours and at the end you see that a package has a CVE. That doesn’t really help you because you’re just sitting there for a couple of hours and now on top of that you have to go through the CI log and figure out what’s broken, right? So not

[15:25] only did you waste a lot of time, the developer experience is really bad there, right? So that’s why I built this project. Um, so what is this project? It’s a dependency vulnerability scanner for JavaScript and TypeScript projects. And as I mentioned, it runs locally. It’s fully free. Um, it’s MIT license and there so there’s no account, no API key. You literally do not need to set up anything at all. So you download it, you you download it from npm and you’re

[15:57] ready to go. And going a little bit further into the details, right? The problem it solves. So when you install one package for example, um most of the time you don’t get one package. You get that package plus everything else that it depends on. uh and and then again everything that those packages depend on, right? So small project easily has thousands of them. Um and the ones you choose are

[16:28] direct dependencies and the one that came along for the ride are called transitive. And that is also where most of the v vulnerabilities actually live. And the awkward part honestly is that you can’t actually fix um a transitive dependency directly because you didn’t install it directly. Um so you can and you can’t upgrade it. So what you have to do is you have to work out the thing that you did

[16:59] that installed it and dragged it along, right? And then you have to perform the upgrade on that. So that’s the part I would say most tools leave you or leave it at you to figure out. Um and it also takes a lot of time experience to figure that out. >> Oh for sure. Actually we have a question that is precisely that. And for folks who are like you explained it beautifully what a transitive uh vulnerability is. It’s like it’s not even people that you invited to the party. It’s the one that snuck in with

[17:31] the with the with your friend that told his buddy. So it’s not even the the dependencies that you are actually like that you’re installing yourself. It’s just what’s coming along. Uh and thank you Kumar for this question about the handling parent aware remediation. So the question is how does CVI handles parent aware remediation when a transitive vulnerability requires breaking a direct parents range requirement? >> That’s a really good question. Um so the way the CV CVL CV light works is that it

[18:04] first looks at the ranges that are allowed within the parents um defined range for that specific trans dependency. Okay. So it first looks at that. It checks if any of those packages within that range are safe uh are free for CVE vulnerabilities and if there’s any it recommends it. If not, it will actually go to the next uh major upgrade and check for that.

[18:35] And one once it finds it, it will recommend that. Okay, but the catch here is because it’s a a major um it’s a major upgrade, right? The tool itself will not do the upgrade itself and it will warn you that there is uh a breaking there could be a breaking change, right? So the tool, the CV light tool is very honest about it and tells you that this is a breaking change and you need to be careful when you do the upgrade yourself.

[19:07] So it goes it goes even a layer deeper I guess um what you mentioned earlier and thank you so much again for the question that like most most of the vulnerability scanning out there is just going to give you the list and tell you okay this is this is the problem right but nothing really tells you what to run or or and that makes a big difference for for developers okay you mentioned go ahead go ahead son >> sorry it you mentioned it goes a few levels down it actually goes many levels down and I’ll show in the demo after. >> Yes. >> Um it does a lot more than usual

[19:41] scanners. What usual scanners do. >> Uh I have to ask and somebody came in the chat actually and asked uh if this was focused on JavaScript script. Um, and I wanted to specifically ask why you why you picked those two as the the two what you wanted to sort of focus on >> this cuz JavaScript and Typescript are uh my day-to-day um projects that I am in right so on on and I’m a consultant I I most of my work is with NodeJS or

[20:13] Angular projects right I’m also a Google developer expert actually in Angular um so most of my day-to-day today work I spend in other projects. So I have um a good amount of visibility on what’s happening there. So that’s why I chose that. >> Okay, perfect. And then uh another question that’s very relevant. It brings me actually to our next question because where does the um we’re going to learn how to say the Jordan CVE like CVL?

[20:44] Where does CVL sit I guess uh alongside where does it fit alongside other tools like for example npm audit or even the pendot? >> Yeah. So npm audit um first it’s only for npm right it doesn’t read pnpm doesn’t read yarn bun any of that. So, CV light does that. Uh, but on top of that, npm audit does not tell you or it tells you only what’s broken rather than

[21:17] which upgrade clears the CV CV the CVE that it found, right? Um, on top of that, npm audit doesn’t do any CVE checks, right? For example, um if package XYZ has a CSV and that CSV will tell you um you need to upgrade to package Y. Um the problem there is that package Y can still be can still contain a CVE and

[21:50] npm audit does not check for that. Right? So our my my tool goes way beyond that like I mentioned, right? It it checks it checks what OSV has recommended, right? And it keeps doing that until it finds a safe version. >> Awesome. All right. Well, I’d love to see it in action. If you’re able to share a demo with us, I think that would be great. >> Yeah, that sounds good. Let me do that. >> Let me take this out. And friends, and

[22:21] thank you. Thank you again for the question. Um, [clears throat] Berdenfolds. I completely butchered that. And please keep the questions coming. Go ahead and post them on the chat and then I’ll I’ll I’ll be sure to bring them up after the demo. Are you ready for me to share your screens, son? >> Mhm. Yes, please. >> Perfect. All right. So, what are we looking at here? >> Okay. So, I’m going to be talking about a small uh express service. Um, you know, it has five dependencies all pinned to old versions on purpose.

[22:52] pretty similar to the juice shop application that you mentioned but a lot smaller scale um but nothing exotic just the kind of thing you would find in a project that nobody you know that nobody has touched maybe in a year or two right so here I have cve light the command I already typed out uh and I’m telling it to scan the current uh folder okay so what do we see here so the First thing I want to show here

[23:23] is that it has 11 vulnerability tech packages as you can see here. One critical. Okay. And then uh five direct and six transitive. Okay. Now look at the line. Um we can see that under here, right? Scan complete, seven urgent issues found, right? So five of these are packages I chose uh and put them in my packages. JSON. I know their names. I know everything about this. Um, and if one of them is

[23:56] vulnerable, I can easily fix that. I can just upgrade it. It’s easy, right? The other six that um, you know, I never asked for them. They came in because I did install um, something and then that brought them along and I can’t upgrade them directly because they’re not mine to upgrade. And if I try to uh if I try, npm will either ignore me or it will end up pinning something in my um it will

[24:26] pin something my actual dependency doesn’t support or even need. Um and this ratio is normal, right? On a real project, it’s usually much worse. So you install maybe I don’t know 40 things and you end up like thousands, right? So the other thing I want to flag is this fix now badge here. So that is just not a severity. Severity tells you how bad um it would be if someone exploited

[25:00] it, right? But it doesn’t tell you whether anyone [clears throat] is actually trying to do that. So those are two different questions. And if you only kind of sort by severity, uh you end up treating um a theoretically critical exactly the same as that’s one as that’s one being attacked right now. Right? So this uses something called EPSS.

[25:31] You can see see here the EPSS. Right? So the that that stands for the exploit prediction scoring system and I want to mention that this is is not something I invented right it’s published by first who are the same people behind uh the severity scores everybody already uses and um I combined them together. So the idea is really simple. For every known vulnerability,

[26:01] they publish a number. The probability that this specific one gets exploited in the wild uh you know in the next 30 days you can say. So it’s it’s a forecast rather than score uh out of 10. And most vulnerabilities sit well under um 1%. Um and a really small number are up in the double digits. Um and that’s generally different question from serity. So serity says or

[26:32] asks how bad would this be? But uh EPSS asks is actually somebody doing this. So you what you want is you want a combination of both, right? Because a critical that a a a critical CVE that has ever exploited that that nobody has ever exploited, right? And a medium one

[27:02] that is being attacked today should not be considered this the same, right? If you have a medium one compared to critical one, but the medium one the the chances are that the medium one is going to be exploited within the next 30 days, you may want to do the fix now on that. So the badge combines them, right? So high severity plus high exploitation um gets the fix now badge and high severity that nobody is touching gets a

[27:34] fix soon. And um it’s basically it’s a tri triage order rather than a list. Um so yeah so so that’s basically the triage answer uh I wanted to mention here uh 11 problems. Um and here’s the one to do first and got in about 4 seconds without leaving me the any terminal. Right? So one thing worth saying here is that what you see here is the compact mode. Right? So this this

[28:05] whole it’s not a lot you can see um this is called the compact mode in the in CV light and it’s built for basically one question and that is do I have a problem right now yes or no which is like the daily driver right so you run it before maybe you open a PR or before you add a dependency um when you want an answer in seconds um you know and and you don’t want to read a whole report,

[28:37] but it’s also not showing you everything and and that’s on purpose. So, you saw three things here and there 11 and the count is right there in the header. Right here. Right. Mhm. >> Um and and so it shows the top few urgent ones because when you’re about to ship the thing you need is yes and start here and not the full table. On a real project though um a full table can have

[29:10] like you know hundreds of rows and none of that help help you uh decide whether you want to deploy or not. But in a summary um the summary is showing this as working. So if a tool tells me to upgrade something I want to know why it thinks that >> or why it thinks it will help. And honestly like like you or any developer should be suspicious of any security

[29:40] tool um that just kind of asserts things to you, right? So yeah. So, so this is the one of the views. There are two more views that I would like to show which is the verbs um also in the terminal and the HTML view um that where the real content is but I’ll pause here for for a second if there’s any more questions. >> Yes, please. And thank you for bringing that up and setting out the explanation. I set out the log the website where first explains what EPSS is and it’s

[30:12] this is very interesting because you combine several things to come up with like the way to score the problem so that when you see it in the critical you actually can trust that yes this is something that I need to take care of right now. I know that’s a huge burden for maintainers to be able to prioritize the work. So, I love that. Later, I’m going to have to nurse snipe you and ask you if you’ve been blamed with that type um safe new model Jeb because this feels like it might be a classifier sort of problem that where where it would perhaps help. But we do have a question

[30:44] and thank you for asking again Kumar uh about CVL uh supporting LO file scanning for bun and alongside PMP and yarn monor repos. >> Yes, that is fully supported. So we support bun, we support yarn, uh we support PNPM for now. So all of that is supported. Yeah. >> Amazing. And thank you Elvis for uh the assisting the chat. I think like the part about it being MPN only was what the limitation with MPM audit is like he

[31:14] mentioned. Oh, he said no MPM, but this is the limitation of MPM audit and this is a whole a whole other tool. Um okay, beautiful. Let’s take a look at what BVOSE looks like then. >> Sounds good. Yeah. Okay. So here I’m running the command CV light again same folder the verbose and all flag. Okay. Um so I’ll start from top again. So here we can see the output is

[31:44] different right on the top we start with the fixed command tables right. So here first we see we see a summary of what’s happening right with the entire project. Uh we see some data here. how many packages you have, how many issues, how many overall CVEes etc. And then here we see the fixed command tables. Okay. Um so the tables are sorted by severity from critical to high to medium. Right. So here we see critical high and we don’t have any mediums right now.

[32:16] Um so this is also the part where um I would want somebody to judge the tool right. Every advisory that comes with a suggested fix like I mentioned last time is you know for example for AX iOS this one right so the I have currently 0.21.1 21.1 installed and most tools will take that number and hand it to you. You know,

[32:46] they will say use this, install it, and you’re good to go. Uh you should be safe. But we don’t we we like I said, we go and check whether that version is actually safe before recommending it. And like I said, if it isn’t, we move to the next published version and the next and next and keep going until we find one that genuinely is. Okay. And this is the tool showing its work. So advisory 0212

[33:21] that is what OSV told us. But the target we can see here is 0.33.0. And that’s what we actually recommend. So it scanned 23 um packages or versions and they’re still vulnerable, right? Sorry, 22 22 are still vulnerable. Uh in total it scanned 30 uh 23. And if we would have just trusted the advisory um you would have upgraded to

[33:54] zero basically, right? 21.2 two felt like you fixed it, but it’s still one number. And that is the failure mode I care about because it’s invisible, right? Nothing errors, the number goes down, you just you actually aren’t safe at all, right? And imagine having to do this work by yourself, right? Imagine you you upgrade from 21 to 21.2 two and you run whatever scanner you’re using,

[34:25] you run the scanner again and it will tell you uh you’re still uh vulnerable, right? And maybe 21.2 will recommend 21.3 and then 20.44 and so on. So imagine doing this exercise manually 22 times, right? Um imagine how frustrating that is for developer, right? Um and and those are the two columns here scanned L silver vulnerable with the same idea

[34:57] across every row. So scanned and how many of those were still vulnerable. We can see low dash here um checked three checked right and two still bad and minimist what’s minimist here minimist uh one checked and clean the first time right and when it can’t find a safe version at at all it says it rather than us pointing out that you know we can fix it

[35:29] or we found one um the tool is going to tell you that if we can’t find one we can find one. So the best option for you might be to either deprecate that package or move to a different package. Right. So pause here again uh for any questions. >> Thank you Sono and thank you for adding that context. I’m low in this table. Um it’s very detailed. I’m assuming probably the the HTML view is going to have even more. Uh but let’s see about

[35:59] the questions from the audience. And I think and we we do have a question about how to run it. John, hang on with me. We’ll get that in the end before we talk about how we can contribute to the PR. I feel like yes, of course, you can you can run it local, but we’ll we’ll talk a little bit about that. Uh maybe Sono can talk us through that before we talk about contributions. Uh but let’s get this question from Udith and thank you for asking. How does CVA light differentiate itself from standard tools like MPN audit and snick in terms of dependency graph resolution speed and

[36:29] actionable fixes? I think this table here kind of tells the story, but if there’s anything any other color you want to add to it. >> Yes, Snake does obviously a lot more, right? It’s a commercialized product. Um, it covers many languages, not just JavaScript specifically. We focus specifically on JavaScript and TypeScript, excuse me. So, we want to make sure that we are the best at what we do. That’s why we’re focusing only on one single thing. Um I would say we we

[37:02] are better at remediation. Um and obviously we are free right? So for snake you would have to pay. Um I ran our own for example sbomb output against theirs on the same repo uh and recently got the same package set right so theirs but theirs is inventory only though no vulnerability data in at all. So that’s basically the difference. Yeah. >> Okay. Great. And for folks who don’t know what a sbomb is as your software

[37:32] bill materials and so do you do you have it here. That’s one of the components of CV light. Wow. Wow. Wow. Okay. Uh let’s take a quick look and see if there’s another question. Um npm install and thank you again for being here. Ber deck is an npm stall hiding that is a transitive dependency for example lagger don’t know which ones are still needed >> yeah it that is the uh what I would call

[38:05] the black black box or black magic from npm right npm hides a lot of things or offiscates them that you can’t really see it um so it’s not easy from even from npm audit perspective I think to see what is transient and what is not or what is the exact path um that goes from the transit to the root. Right? Another problem I see with npm audit itself is that in many cases I have seen that npm

[38:36] audit even recommends using force or setting legal legal uh not legal sorry uh legacy deps right um it even recommends sometimes using overrides we don’t do any of that because our goal is to make your project safe as much as possible using overrides will not help you. It It is just a band-aid, right? You put overrides in once and believe me, once it’s there, you’re never going

[39:09] to fix it. It’s most of the time it just stays there. It’s like bad code, right? [laughter] >> Some of that depth that just hunts you down the at some point it comes after you. Okay, we’ll do one more question and then we’ll move on to the HTML view. I’m very excited to see that. And again from Kumar, thank you. When fixing transitive vulnerabilities like body parser and under express CV light CLA inject packages overrides actually we’re just talking about this resolutions or attempts to bump the root dependency directly

[39:39] >> that’s a very good question we never do overrides we don’t want to do overrides in fact TVL has a feature that allows you to check your overrides okay so if you do d-check overrides it will allow you you allow you to check your overrides it will run through the entire algorithm to make sure that your overrides are still working or if they’re just uh orphans that you don’t even need anymore. Um and on top of that, it will try to improve your

[40:10] project so that you can actually get rid of those overrides. So, we don’t do any of that. >> Awesome. All right. Let’s take a look at this HTML view, please. >> Uh before we move to the HTML, I want to show one more thing here. >> Oh, please do. Mhm. If it’s fine, I’m going to reduce the uh size a little bit because I see the table is overlapping. Here you go. Okay, >> there we go. So, perfect. >> So, this is much perfect. So, this is much better. So, I want to show here uh take a look at the express package here,

[40:43] right? Express because it’s doing something different. Um Express is showing here for example advisory uh 14192 and target is 4223 which is higher than the validation alone would have picked and here’s a reason why. So if we look at it, we can see that um actually here at the bottom table that the there’s six packages here that um pull in or that are dependent on

[41:14] express right we see here the root. So I have personally never typed path to reax or QS or express uh or any of the other ones, right? So these just came along with express. That’s the only reason uh they’re on my machine. So it’s not telling me to install six packages, telling me to upgrade express, right? And that is the question that we just answered. um the one thing that actually chose to version

[41:45] new enough to stop pulling in the vulnerability copies of all six. Okay. So so so again think about it. So we we the the the the CLI scanned Express or or scanned the CVEes of all the six transa dependencies from Express and figured out which Express version you need to upgrade to to fix all those

[42:16] findings. Okay. So I just want to make sure that that this sinks in that the tool is doing not only fixing a onetoone package but if one package has multiple transit packages which is normal and those transit packages many of them have vulnerabilities. The tool will try to fix all of them trying to come to a version that works for all

[42:47] of them. Hopefully that makes sense. >> No, that’s very complicated. >> No, that’s very impressive and thank you for making sure that we we had the complete view of the table because that clearly illustrates the point there. >> Awesome. Okay, if we Okay, we will move to the um HTML report. >> Okay, perfect. Let me remove your screen while you get that app on it. Yeah, >> and I’m going to take a quick spin through the comments and thank you Rak for the comment that yes, this is important for JavaScript and TypeScript

[43:19] developers. I appreciate the focus though. Like that’s great. Um, and I think that’s a key differentiator amongst like most of the things that are out there, right? That you’re you’re definitely like stay in your in your lanes. Um, thank you to Nurio for being here as well, Misam. Um, and uh I appreciate you all replying in the chat explaining what CVE is. Thank you so much. I know some of us like maybe this is in our world at all. So I appreciate you helping each other out on the chat.

[43:50] Wonderful. And then let’s go ahead and share your screen so that we can see. Oh, this is cool. I like it. Talk me through this view. I am I I love I love me in the terminal but I’m a sucker for this good welldesigned things. Let’s see. >> Okay. So let’s go here. Okay. So basically same scan but completely different audience. Okay. >> Okay. >> So the terminal output you know everybody loves it. You love it. I love it. It’s great for me right now. Uh what

[44:22] I’m working on and but this is for everyone else. Who is everyone else? your security team, your lead, the auditor who asked what you’re shipping or just in three months when you’ve forgotten when you deferred something, right? And why I say three months, I’ll come to that in a second. So, but basically this has on the top it has the same count. Okay? So, you you see everything uh right when you land here. Um but the most important thing is look

[44:52] at what comes right next after that because that is the bit I care most about because before it gives you the list of problems this gives you the plan. Okay. >> Aha. >> So five uh direct fixes. Okay. Group by severity each one command with one copy button. Okay. So you click on this you get this copy command you run it in in your terminal and you’re good to upgrade. Okay, the same for this one. And by the way, the same commands are

[45:22] available in the terminal. Uh forgot to mention it, but they’re there in the terminal um in compact mode and in verbose mode. So there they’re always there. That is also one of the biggest differentiator, right? You run the tool, you see there’s a vulnerability, you get a fix command, you copy paste it, you run npm install and you’re good to go. Okay. Um so two commands one for critical we have the critical here so they will all be grouped under the same um group and then you have the high one

[45:54] here. Okay. Um and when where when upgrade is going to word it says you know it says so before you run it. So for example JSON web token here right 8.51 to 9.0 0. Again, we say that this is a breaking change. So, please uh make sure you double check your code and make sure that none of the APIs are broken cuz you probably do not want to run this command

[46:26] um like on a Friday afternoon like today and then push it up and then leave for the weekend, right? So, express here is the interesting one I find. Uh you can see that here. So it doesn’t just give you a version, it says a path specific remediation, right? So that means uh run this and then do a rescan because there could be other paths that still that may still need some work, right?

[46:58] So that’s a tool refusing basically to promise uh more than it can prove. It knows that this upgrade fixes uh the route it can see. Um but it is not going to tell you the whole problem is gone when it can’t verify that. Does that make sense so far? >> It really does. It really does. And and you’re getting a lot of compliments about the formatting of this. Um >> awesome. So now let’s uh look at the table here.

[47:30] Right. So this table is where the details live. Okay. EPSS as a percentage as you can see. Uh the the exploitation probability rather than a label. The pri priority tier next to it. Uh the root column is the one I like the most. Right. Um for transit for transitive finding it tells you which of your dependencies dragged it in. So let me see if I can uh find one. I think

[48:03] this one. Okay. So this one is a transitive. The root is express. So now here I can expand it. If I expand it, look at this. It says your project express and then QS. But remember we said there is another path available right which is project express body part and QS. So you see how many levels it has to basically go go up to figure out which version it needs to upgrade. Um

[48:34] and like I said here it says you can upgrade from 4171 to 4223 to fix that specific issue. And we also have again the fix now badge here and the commands here for you to copy and paste. >> I love that. And this actually leads me into I guess the next part where we can and please stop me if if we’re I’m just taking a look at the clock but uh the copy and paste bit because you’re running this local correct this is right

[49:04] now running local okay >> yeah you would you would basically always run this locally I mean we we have a CI version as well which does which does the same thing >> and this is what I was trying to say earlier that you know maybe you would need it in 3 months You know, but then you might be wondering how do I get this report in 3 months. Now, the beauty of this report is is all it is is all self-contained. All the data, all the styles, everything is within this simple HTML file. Okay?

[49:38] So, you could literally take this file, send it to anybody, and if they doubleclick it, they would say the see the exact same thing. nothing broken, all the same data, everything is there. On top of that, if you run this in CI, you have the option to export this as part of the GitHub action and it will store it in GitHub itself. Um, so you can actually version all the reports that are coming in for audit purposes.

[50:12] >> That’s awesome. Okay. So, you always have the record. >> Um, >> you always have the record. Exactly. and you and you’re able to share it. That’s that’s that’s fantastic. >> Okay, >> there’s some more features you can see here. You know, you can filter by the package. Um this table is small, but if you have a large package, uh if you have a large project, sorry, you may want to search for specific uh package. So, you can for example search here for the package name, it will filter it out for you. Um you can also filter by severity.

[50:44] Um and uh also direct or transient only. Right. So yeah that’s uh that’s about it. That’s the demo I had prepared. Um >> this is awesome. This is awesome. Okay. So if I want to install this right now, so I have options. I can run it on CI if I want to or I can run it fully local which is the examples like what demonstration that you given us. That was you running it locally. Um, but then of course you can take the findings and that same HTML is going to

[51:17] contain everything that you need to do. I’m assuming you could take those findings and dump them into an agent as a uh it could be like a a prompt for you know go remediate this or like take a look at this report and the critical assess how to upgrade it the critical findings only following only the recommendations in the report because that’s the other piece of it that is so important why this project I think is so different than many out there because you do a lot of homework before those recommendations show up on that table. Um I think that makes a big difference.

[51:47] Yeah. So, what a great way to not like waste tokens and not just send an agent on a wild goose chase, but you actually know what to focus on. >> And right now the project is hosted of course in GitHub and people can clone it, can download it. Can we talk a little bit about the contributions that you’ve I know right now you’re are you the only core maintainer of the project? >> Mhm. I I am the only core contributor but there are already several in place. >> Amazing. don’t know how many we have

[52:18] probably 40 50 contributors. Um so if you want to contribute you know there are issues tagged with good first issue and some a some are aimed at people making even their first ever open contributions. So what we do is what I specifically make sure is you know everybody of course when you start open source uh contributing to open source you’re very eager you want to do as much as you can right so what I do is um there is good first issue labels but that’s also first timers only okay

[52:50] >> I like that that’s unique to your repo yeah >> exactly so say say I’m a first-time contributor but you know I’m already aware of what’s happening within this repo and I did a few PRs already then maybe I do not want to take the issue um that is only for first- timers because that is literally what it’s meant to do you know we want people to start contributing more and more um and make them comfortable right >> I love that and that is such a good tip for maintainers who are trying to get

[53:20] people to come and participate in their projects to like create those labels that make it so clear what the path to contribution is taking into consideration you know like yeah this might not be my rodeo. Uh that I love that. That’s that’s awesome. Okay. Um let’s see questions from the chat. I’m going to take a look at there’s a couple of questions about the the problems and I and I welcome you Rak to look at the beginning because we did cover what finally pissed off Sonu enough that he said I’m going to make this for myself. [laughter] Which listen isn’t that like 99% of the

[53:54] origin stories of most of of our projects really? like at some point we got frustrated enough with the one thing and we decided to go ahead and fix it ourselves. Wonderful. Tell me a little bit about what’s next for the project. What do you have on the road map? What are you looking forward to? >> Yeah, so the next thing we are experimenting is um more exposure within GitHub, right? So we are already kind of um uh trying to figure out how we can make this even better in in a GitHub

[54:27] environment right we we know on terminal is already great right I I have some really big adopters already you know some governments are already using like the French government is using it British Columbia is using it so there’s big >> big names behind the product already >> um but we want more more developers uh to to use the project you know even if it’s your your hobby project, we want you to use it, but you may not always have the time to run it in the terminal. And a lot of things happens in GitHub. So, what we’re trying to experiment is,

[54:57] you know, give you the same um give you the same algorithms and remedition remedes within GitHub itself. So say you open a PR, it has an issue. We don’t want you to like other scanners. We don’t want you to go into your GitHub logs to figure out what you need to fix. What we want to do is we want to create a command and say, “Hey, this is vulnerable. This is the command. Run it and update the PR.”

[55:29] >> Aha. That’s that’s very that’s very powerful. That’s very very powerful. And so you’re you’re actively working on that kind of like incorporating it more as part of like the entire software develop life cycle. That’s which is how security should be. But as most of us can attest, >> you know, only when things go wrong is when we start paying attention. So that’s an unfortunate thing. >> Okay. All right. Let me ask you quickly and I’m going to take a look at the other questions to see if there’s

[56:00] anything that I should bring up. Definitely connect amongst yourselves, Udy. That’s what we’re here for. Drop each other’s LinkedIn profiles on the chat. Let’s see your LinkedIn profiles and connect with one another. Uh get your networking on. That’s what these events are for as well. Uh let’s see. Rapid fire questions. What was the last thing that you pushed? Um and what prompted you to do that? I had a a funny tweet about commit messages today, but let’s make this about the substance of the change. [laughter] What was the last

[56:31] push before you came here today? Uh that’s a good question. I picked so many things [laughter] to be honest. >> You’re like all the things. >> Yeah. But like I said, I think the the the one I am really mostly focused on right now is the GitHub integration. I think I did a few fixes on that this morning to make sure that uh you know that the comment we put within the PR has all the information the developer needs to move on.

[57:04] >> Amazing. Amazing. Okay. And then uh we know how to contribute. We go to the repository. First of all, I need everyone to go to the repository right now and drop a star. That is the one thing you can do right now to support us and support this show. go ahead and leave the star so we can get it trending, get it in front of more developers who might be interested in exploring this as a path to contribution or who might just be looking for this very solution. I’m excited. I feel like I’m thinking, of course, I’m going to I’m going to say something that’s probably going to like piss people, but

[57:34] I think the possibilities of extending this into like automated agentic workflows, right? like you get this wonderful report that’s got everything that you need and then to get that self-healing loop going where the agent figures out what it needs to do. >> Yeah. One thing I want to mention is because you you mentioned AI and agents and a few times you know. >> Yeah. Yeah. Yeah. >> Um the CV light itself does not use AI at all. Right. So right now it’s all about AI and all that but >> in my experience and experiments I have

[58:06] seen AI many times recommend the wrong thing when it comes to >> Exactly. Exactly. >> And uh CV light actually has AI skills as part of it. Right. So if you run the skills um and you can you can then tell your agent UCV light uh to run a scan um and it will spit out a JSON file that can be used to fix all of those issues. So you don’t even have to do it, right? Um the agent should be able to pick up

[58:38] uh the JSON file and the skills uh instructions and figure out how to fix it without going in the wrong direction. >> Exactly. And that is the key that is the key part that misses in most most of this type of products. Yeah, you can’t delegate everything to the like there’s still too much volatility like the recommendations nine times out of 10 are wrong. [laughter] So you still need you still need the judgment of a tool that’s well built and it’s going to give you recommendations that you can actually trust. So that’s fantastic. So new I think that’s one of

[59:09] my favorite things about this project. Okay. And then let’s see another rapid fire question for the people that are going to watch this whether you’re watching it live or later. Come explore the project and you’re like, I love this and it would be great if it also had this like what how can folks propose this to you? What will sway you the most to actually consider incorporating into the project short of of course actually building the thing themselves and contributing it as a PR? Like where are

[59:41] you at? I know that where your priority right now is incorporating deeply into GitHub, but is there anything else that can assuage your your mind as to what to focus on? >> Um, so is it it’s more about um how do people reach me, right? >> Yeah. Yeah. >> Yeah. Yeah. So, so people can reach me over LinkedIn, um, GitHub, you know, uh, Twitter. But if you’re really interested in, you know, having a certain feature implemented or you found a bug or

[1:00:11] something, you know, I would really encourage you to open a bug, a GitHub issue um with a reproducible uh package JSON um and preferably a report that you can run with the CV light um so that we can investigate that and and obviously we love it when you can propose it, propose the issue and also fix it, right? and we’ll help you as much as we can. >> I love that. I heard somebody say, “Who said this to me this week?” That’s the way of the executive friends. Like you

[1:00:42] don’t just bring problems, you bring solution. [laughter] >> Yes. >> Not the to the executives, not the executives. Us the peons. The workers. The workers. Amazing. So, this has been so informative. I am thrilled to now know this project. I want to play with it. I want to download it and run some of my own projects through. and how refreshing to have something that is not rooted on AI. Like it’s a skill and an add-on to AI and not just all overwhelmed by that being the foundation of what is built. So I appreciate the

[1:01:14] diligence that you did on building this. Thank you so much for being here. I appreciate it. >> Thank you for having me. >> All right. Well, friends, go ahead and connect. I’m going to drop in your LinkedIn uh on the chat as well so people can click on it. And for my friends in LinkedIn, just give me a second. You know, it takes me a moment to actually go over there. I gotta like copy and paste it myself there. So, here we are. And go ahead and connect with Sonu. Connect with Sonu on X as well if

[1:01:45] you like. And I cannot wait to see all those many stars that are going to be landing in this repository today, please. Uh Sonu, thanks again. Have a great weekend. >> Thank you. Have a good one. Okay, that was extremely informative and it’s actually piqu my curiosity about I wonder what other projects are doing this more like native like really focusing on fundamentals before throwing an agent at it and what a great way for you to start learning about the world of CVS with a tool that’s rooted into that.

[1:02:17] So I appreciate all of you going and starting the project right now. Follow Sonu and social find collect with Sonu on LinkedIn and don’t forget that next week I will be in San Jose for we are developer congress and if you want to be there with me please send me a message uh send me a DM. I’m going to put my the hell that I live in the most. [laughter] So feel free to send me a DM there and I will hook you up with a ticket. And

[1:02:47] don’t forget that our universe giveaway is still live. It’s got about two weeks left. All you got to do is fill out a short form and then we’re going to ask a pilot to pick a winner. And no, you only submit one form. Uh I’m being very rigorous about the way we do the sweep stakes so that everyone has a fair chance. Thank you all so very much. Have a wonderful rest of your day. Don’t work anymore. Tell them Andrea said you could go home now. Thank you for being here and supporting open source and this

[1:03:17] stream of open source Friday. See you next week. >> [music] >> Heat. Heat. Heat.

[1:04:00] Heat.