SonarQube + OpenAI: desenvolvimento agentic — Killian Carlsen-Phelan, Sonar

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

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: SonarQube + OpenAI: Agentic Development — Killian Carlsen-Phelan, Sonar · Canal: AI Engineer · 41:54 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Engenharia de software com IA

Resumo

A palestra apresenta práticas para desenvolver com agentes de IA sem tratar o código gerado como confiável por padrão. O fluxo proposto combina orientação com contexto do projeto, análise de segurança e qualidade, correção de problemas e verificação contínua dentro do ciclo de desenvolvimento. Em uma demonstração com Codex e SonarQube, o palestrante bloqueia o acesso a um segredo, identifica uma injeção de SQL e verifica uma correção. A mensagem central é que a conclusão de uma tarefa precisa vir acompanhada de evidências, e que contenção não equivale a correção.

Pontos-chave

• Uma tarefa só deve ser considerada concluída quando há evidências verificáveis, como alterações revisáveis e resultados de ferramentas.
• A contenção limita o que um agente pode fazer, mas não prova que o resultado produzido está correto ou seguro.
• A especificação e a verificação tornam-se gargalos importantes à medida que agentes aceleram a geração de código.
• O ciclo agentic apresentado reúne as etapas de gerar, orientar, verificar e corrigir.
• A orientação do agente com regras e arquitetura do projeto pode fornecer contexto relevante antes da geração de código.
• Verificar alterações no ciclo interno, dentro do IDE, pode reduzir a espera por falhas encontradas apenas no CI.
• A demonstração mostra a detecção de um segredo exposto e de uma injeção de SQL por meio de análise de fluxo de dados.
• Hooks e análise após alterações podem verificar correções e sinalizar novos problemas introduzidos.

Capítulos

Início	Capítulo	Resumo
00:13	Evidências, limites e verificação no trabalho com agentes	A introdução define o que significa concluir uma tarefa e apresenta contenção, correção e feedback como temas centrais.
05:40	O ciclo de desenvolvimento agentic da Sonar	Killian apresenta o problema de confiança no código gerado por IA e descreve as etapas de orientar, verificar e corrigir.
11:04	Preparação da demonstração e configuração do projeto	O palestrante explica as ferramentas que serão usadas e inicia a configuração de um projeto Python com vulnerabilidades intencionais.
15:55	Análise do projeto e vulnerabilidades detectadas	A demonstração mostra a detecção de uma chave de API exposta e de uma injeção de SQL rastreada por análise de fluxo de dados.
20:09	Integração do SonarQube com Codex	Killian instala o plugin, configura a autenticação e conecta os recursos do SonarQube ao Codex.
25:45	Bloqueio de segredos e conexão com o MCP	A demonstração apresenta hooks para evitar que segredos cheguem ao contexto do agente e configura o acesso às ferramentas via MCP.
31:14	Consulta de problemas e análise no fluxo de trabalho	O palestrante explica como o MCP e as skills podem consultar problemas do projeto, apesar de dificuldades de conexão durante a apresentação.
34:35	Correção e verificação de uma injeção de SQL	Codex corrige uma consulta vulnerável e a análise após a alteração verifica que a correção não introduziu novos problemas.
38:28	Orientação e verificação de uma nova funcionalidade	Uma nova função é implementada com contexto do projeto e submetida à análise automática dentro do mesmo fluxo.
41:15	Encerramento	Killian agradece ao público e convida os participantes a conversar com a equipe da Sonar.

Citações

Concluído significa que a tarefa foi feita e que há evidências. — 01:19

Não dá para determinar se uma tarefa foi concluída sem olhar para as duas partes. — 02:25

Nenhum oráculo é uma prova. — 03:32

O gargalo mudou da geração de código para a verificação de código. — 07:50

Conceitos e entidades

• SonarQube (ferramenta): Plataforma usada na demonstração para detectar problemas de segurança, qualidade e manutenção no código.
• Codex (ferramenta): Ferramenta de codificação com IA usada para gerar e corrigir código na demonstração.
• Sonar (empresa): Empresa representada por Killian Carlsen-Phelan e responsável pelas ferramentas Sonar apresentadas.
• Killian Carlsen-Phelan (pessoa): Engenheiro de conteúdo para desenvolvedores na Sonar que conduz a demonstração.
• OpenAI (empresa): Empresa mencionada no título e na apresentação do evento.
• ciclo de desenvolvimento agentic (conceito): Processo que combina geração de código com orientação, verificação e correção assistidas por ferramentas.
• análise de taint (conceito): Técnica usada para rastrear o fluxo de dados potencialmente não confiáveis até operações sensíveis.
• injeção de SQL (conceito): Vulnerabilidade demonstrada em que uma entrada controlada pelo usuário é incorporada diretamente a uma consulta SQL.
• context augmentation (ferramenta): Recurso demonstrado que fornece ao agente regras, arquitetura e contexto relevante do projeto.
• agentic analysis (ferramenta): Recurso que executa análise do código após alterações feitas pelo agente para verificar possíveis problemas.
• MCP (ferramenta): Componente usado para conectar o Codex às ferramentas e informações do SonarQube Cloud.

Tradução completa (pt-BR)

00:13 Legal. Estou aqui da equipe de engenharia de deploy do Codex e quero dizer rapidamente algumas coisas para apresentar o pessoal incrível da Sonar, assim como Killian. Vou pular alguns conceitos básicos de agent que costumo abordar, porque tenho a impressão de que este público sabe o que está fazendo nesse aspecto. Vamos direto às perguntas mais difíceis, como: o que significa um agent ter concluído uma tarefa? O que são limites de confiança? E também temos três afirmações meio provocativas que queremos apresentar. A primeira é que “concluído” significa que uma tarefa foi finalizada com evidências. A segunda é que

00:47 contenção não é correção. E a terceira é que o contrato de feedback pertence ao loop. Quando temos um loop de agent, ele tende a seguir alguns padrões previsíveis. Costumamos ter uma ação do modelo e uma execução governada pelo modelo. Observamos as mudanças, sejam elas logs, resultados, saída ou qualquer outra coisa, e continuamos atualizando o plano. Esse é, mais ou menos, o loop geral de agent que seguimos. E, em cada tarefa individual, temos um resultado, temos invariantes, temos um escopo geralmente

01:19 definido para aquilo em que estamos trabalhando. E, claro, também temos critérios de aceitação. Para nós, a definição de concluído costuma ser um diff que possa ser revisado, algumas evidências de ferramentas, esse tipo de coisa. Não basta dizer “corrigido”. É preciso dizer “corrigido” e fornecer as evidências que sustentam essa afirmação. Implementações mais baratas tendem a deslocar o gargalo para a especificação e a verificação, e não é isso que queremos fazer. Também existe a ideia de falha correlacionada e

01:50 há alguns modos de falha comuns em que agents de programação costumam cair. Eles tendem a voltar a um contexto incompleto. Ou talvez haja uma correção local que viole alguma invariante global que temos. Ou, melhor ainda, o teste gerado que fazemos para verificar os resultados acaba propagando os mesmos problemas. A autocrítica é útil, mas não é um oráculo independente, e muitas vezes constatamos que alguns resultados do agent e do verificador são ortogonais entre si. Você

02:25 não consegue determinar se uma tarefa foi concluída sem analisar as duas partes. Em geral, você quase quer buscar evidências que refutem a conclusão de que a tarefa foi concluída. Foi concluída segundo o compilador? Foi concluída segundo os testes, a análise e assim por diante? E não dá para substituir a revisão humana em todo o ciclo. O próximo ponto que eu queria abordar rapidamente é que contenção não é o mesmo que correção. Temos a camada de execução, que normalmente define o que um agent pode fazer, certo? A quais

02:57 ferramentas ele tem acesso? Qual é o escopo? Que aprovações ele precisa obter para agir? E, junto com essa camada de execução, temos a camada de artefatos. É nela que os resultados são avaliados: o resultado é aceitável? Que testes foram produzidos? Que análises? Que políticas? Até mesmo qual é a intenção? Então, um sandbox pode conter uma escrita, mas não pode provar que uma consulta é segura. O que estou tentando dizer é que nenhum

03:32 oráculo é uma prova, e que é preciso aplicar controles em camadas com limites diferentes. É uma espécie de defesa em profundidade, essas várias camadas de proteções. Essa é, mais ou menos, a ideia geral. E a grande vantagem disso é que você, como pessoa, fica responsável pela intenção, pelas exceções e, claro, pela decisão de fazer deploy ou não. Só mais uma coisa. Também costumamos recomendar um contrato de feedback. Em geral, ele vem acompanhado de skills, que, claro, são procedimentos para

04:05 realizar uma tarefa específica. MCPs contêm ferramentas e contexto estruturados e, claro, podemos fornecer verificações do ciclo de vida com hooks, que são muito bons para detectar se há segredos codificados diretamente no código ou algo do tipo. Com isso, você quer criar um processo completo de CI e revisão humana, que, em última análise, deve ser o núcleo do papel da pessoa nesse processo. Enfim, então, o que você quer avaliar ao criar esse

04:35 tipo de processo agentic são algumas coisas. Qual é o limite, por exemplo? Você consegue interceptar segredos antes da entrada no modelo? Como o projeto é fundamentado? Há regras concretas, locais ou caminhos de vulnerabilidade que você consegue fornecer? Qual é o escopo? Os parâmetros estão vinculados sem alterar o comportamento? Essas são coisas a verificar e, claro, você precisa executar suas verificações novamente o tempo todo. Assegure-se de que os agents

05:07 não sejam o estado terminal. Enfim, já falei bastante da minha parte. Se vocês levarem três pontos do que eu disse, que sejam estes: “concluído” significa que uma tarefa foi finalizada com evidências. O segundo é que contenção não é correção. E o terceiro é que o contrato de feedback pertence ao loop, para que vocês possam aproveitar plenamente os recursos dos agents, como o Codex. Killian, vamos completar esse loop, que tal? É só isso da minha parte. Então

05:40 muito obrigado por me dar a oportunidade de fazer esta introdução. >> Obrigado. Se puder dar uma olhada nisto, analisar e acompanhar, será muito útil. Há alguns pré-requisitos. Mais uma vez, sou Killian. Sou engenheiro de conteúdo para desenvolvedores na Sonar. Muito obrigado novamente à OpenAI e ao Tony por nos dar uma pequena introdução a tudo isso.

06:11 O Codex é uma ferramenta muito poderosa. Uso o tempo todo e acho muito útil. Tem uma CLI rápida, um sistema de sandbox bem inteligente e um sistema de hooks que também se integra muito bem a ferramentas como o SonarQube, que é o assunto que quero abordar hoje. Então, como preparar sua equipe para o desenvolvimento agentic com SonarQube e OpenAI? A pergunta que quero propor hoje é

06:42 como garantir que o código e os resultados gerados por agents como o Codex sejam verificados e seguros? Na Sonar, temos essa ideia de ciclo de desenvolvimento centrado em agents. Fizemos algumas pesquisas no último ano, mais ou menos, e entrevistamos mais de mil desenvolvedores. Descobrimos que 42% do código enviado é gerado ou auxiliado por IA, mas 96% dos desenvolvedores não confiam plenamente nele. Certo? Então, a grande maioria

07:17 das pessoas não pensa simplesmente: “Ei, isso é seguro logo de cara”. Menos da metade afirma verificar completamente o código antes de enviá-lo e fazer merge na base de código. Há certa tensão aí. Ninguém confia nele. Uma grande quantidade de código não confiável está entrando na base de código. A razão é que o gargalo costumava ser a geração de código, certo? Como podemos criar aquilo que estamos tentando fazer para alcançar o resultado desejado? Como, de fato, escrevemos o código de uma aplicação que estamos tentando desenvolver?

07:50 Com agents de IA, isso, em grande parte, já foi resolvido, seja porque eles fazem isso sozinhos, seja com a ajuda de agents de IA. Então, o gargalo deixou de ser apenas a geração de código e passou a ser a verificação de código. Certo? Temos uma quantidade enorme de código sendo gerada, mas agora cabe às limitações humanas responder: como posso garantir que isso é seguro? Que ajuda e que ferramentas posso obter para verificar se isso não vai destruir minha base de código nem prejudicar meus clientes, causando todo tipo de problema? Temos quatro

08:26 etapas no AC/DC, o ciclo de desenvolvimento centrado em agents. Uma delas não é necessariamente da Sonar: a etapa de geração, feita por qualquer ferramenta de programação que você use, Codex ou qualquer outra. Mas a Sonar é responsável por orientar, verificar e resolver. Orientar significa injetar contexto adequado no agent, incluindo as diretrizes do projeto, quaisquer regras e uma arquitetura específica, para garantir que ele tenha contexto de alta qualidade antes mesmo de começar a construir

08:57 qualquer coisa. Descobrimos que isso reduz o custo total com tokens e, em escala empresarial, isso significa economizar muito dinheiro a longo prazo. Verificar: assim que terminar de criar qualquer tarefa atribuída a um código gerado, queremos garantir que nenhum problema seja introduzido. Ou seja, nenhum problema de segurança, de qualidade do código, de manutenibilidade, nada disso. Nada disso deve chegar ao código em produção. E então resolver: tudo bem, detectamos um problema, certo? Existe algum tipo de vulnerabilidade de injeção ou

09:31 qualquer outra coisa acontecendo. Precisamos corrigir isso rapidamente e da maneira mais eficiente possível, para termos esse sistema iterativo de programação. E o último slide que vou mostrar antes de passarmos para a atividade em si é o conceito do ciclo interno e do ciclo externo de verificação. O ciclo externo é o sistema tradicional de CI que vocês configuraram, certo? Então, vocês escrevem o código, enviam para o GitHub, GitLab ou o que quer que usem,

10:01 o pipeline é executado e alguma coisa pode falhar, certo? Um teste, uma verificação ou o SonarQube pode falhar, e aí vocês voltam para a IDE, tentam corrigir, enviam de novo e falha outra vez. Isso tem sido o tormento da minha existência e da existência de muitos desenvolvedores. Então, queremos economizar tempo deslocando a verificação para a esquerda, para o ciclo interno, que é a IDE. Ou seja, assim que terminarmos de gerar o código, queremos verificar se ele está correto dentro da IDE

10:33 sem precisar enviá-lo. Isso economiza muito tempo. Quer dizer, especialmente por ser possível verificar tudo isso automaticamente. Tempo é dinheiro nas empresas, e seus engenheiros também economizam muito com sessões de terapia, evitando essa frustração. Tudo bem, esse é o último slide em que realmente quero me concentrar antes de irmos para o terminal. Algumas coisas rápidas que quero mencionar

11:04 antes disso: vocês vão ver duas ferramentas sobre as quais vou falar. Nossa ferramenta de contexto, chamada Context Augmentation, é a que vamos usar na etapa de orientação; e nossa ferramenta de análise agentic, vocês vão ver na etapa de verificação. Vamos voltar a elas mais tarde. E a principal conclusão que também quero que todos tenham em mente é que esse gargalo mudou da geração de código para a verificação de código. Antes de começarmos também, todos

11:35 devem estar com o Docker em execução no computador, se for possível. E só para ter uma ideia de quem conseguiu acompanhar os pré-requisitos até aqui, mostrem o polegar para cima se conseguiram executar o Docker e estão mais ou menos prontos para começar, entrar no terminal e acompanhar. Ótimo. Algumas pessoas. Perfeito. Obrigado. Se não conseguiram, mais uma vez, este repo está disponível. Vocês podem acompanhar por conta própria, quando quiserem. Terão todas essas informações. Então, vou sair daqui rapidinho. Só tenho uma visualização limitada.

12:09 A parte superior da minha tela está cortada, mas deve dar para prosseguir. Tudo bem. A primeira coisa que vamos fazer é executar este script chamado apply sonar. Esse é apenas o repo que clonei localmente. Isso vai exigir um terminal Bash. Então, se vocês estiverem no Windows, podem usar o Git Bash ou algo do tipo. Vou digitar isso agora. É apply sonar. Certo. E isso vai fazer algumas

12:40 coisas. Esta é uma ferramenta pessoal que criei. Não é um produto oficial da Sonar. É apenas um atalho, para não passarmos 10 minutos clicando em uma interface ou algo assim. Vou conferir se meu Wi-Fi está funcionando bem. Certo. Meu computador está um pouco lento aqui. Mas isso vai criar um projeto no SonarQube Cloud para vocês. Também vai executar a primeira verificação.

13:12 Certo, UE, e vai me autenticar. Então, vamos abrir o navegador. Isso vai instalar algumas ferramentas relacionadas ao SonarQube, como nossa CLI e tudo mais de que vamos precisar para executar nosso plugin com o Codex. Certo, tenham paciência enquanto tento lidar com um pouco de lentidão no Wi-Fi daqui, mas não deve ser um grande

13:43 problema. Então, isso foi concluído com sucesso. Vocês vão querer inserir a organização desejada. Ou seja, a organização que foi criada para vocês quando fizeram uma conta. E isso vai ser executado. Só para falar deste projeto: é um projeto minúsculo em Python. Nada complicado. Tem uns quatro arquivos,

14:16 menos de 200 linhas no total. E plantei quatro vulnerabilidades nele. Três são vulnerabilidades de segurança e uma é um code smell. Quando esse script terminar de executar, vamos abrir o dashboard e verificar se conseguimos ver as informações lá. Certo. Normalmente, acho que tem muita gente tentando acessar este Wi-Fi. Nunca vi isso levar mais de um minuto usando meu próprio Wi-Fi. Então, se estiverem acompanhando de casa, não

14:50 pensem que vão ter que ficar esperando assim por um tempo. Opa. Então, sabe de uma coisa? Talvez eu tenha esquecido de exportar meu token, que é uma etapa descrita no repo. Isso deveria estar no shell de vocês. Vou me desconectar rapidinho por um segundo para não expor meu token do Sonar para uma sala cheia de gente. Aí eu volto

15:20 logo em seguida. Deve haver algumas etapas no repositório. Vocês vão navegar pelo dashboard. Acho que fica em Administração, no SonarQube Cloud. Certo. Espelhar novamente.

15:55 Certo. Isso vai ser executado. Também quero comentar algumas coisas. Vamos ver um problema de injeção de SQL aparecer. Certo, ótimo. Parece que está funcionando agora. Vai prosseguir e criar tudo automaticamente para mim no dashboard. A classificação de segurança que vai aparecer será E. É a mais baixa possível. Incluímos alguns problemas de segurança, e o SonarQube os detecta imediatamente e diz: “Isso não está nada bom.” A próxima coisa que vou abordar, assim que isso carregar, é passar por alguns problemas. Um deles é uma chave de API da OpenAI exposta. Muito relevante para quem estiver usando o Codex. Eu já fiz isso. Está bem aqui na base de código. Opa, alguém esqueceu de usar um arquivo de ambiente ou de passar isso como variável. Isso acontece o tempo todo. E muitas vezes

16:26 o que acontece é que as pessoas acabam enviando isso acidentalmente para o código em produção. Atualmente, o tempo médio para corrigir um segredo exposto em um repositório público é de 90 dias. Isso é absurdo. Seu token fica exposto para o mundo inteiro ver, para todos os bots coletarem, durante 90 dias. Queremos evitar isso o máximo possível, e temos algumas ferramentas para isso aqui. Outro problema que vou destacar para vocês daqui a pouco é

16:57 uma vulnerabilidade de injeção de SQL. Se alguém que estava apenas dando uma olhada neste código entende muito de segurança, talvez tenha notado, mas bem aqui neste arquivo database.py, estou passando uma consulta daqui diretamente para uma f-string que é executada pelo cursor. Então, o argumento vai direto para a string. Isso é uma péssima notícia,

17:27 especialmente porque essa função search_task recebe um argumento de sys.argv. Isso significa que qualquer pessoa que controle sys.argv pode controlar seu banco de dados, certo? Isso é muito ruim. O SonarQube consegue detectar isso e vai avisar: “Este é o fluxo de dados que estamos detectando.” Ele usa execução simbólica e análise de taint para identificar o fluxo de dados e rastreá-lo à medida que percorre a aplicação.

17:58 uma vulnerabilidade de injeção de SQL. E, se alguém que estava apenas dando uma olhada neste código entende muito de segurança, talvez tenha notado, mas bem aqui neste arquivo database.py, estou passando uma consulta daqui diretamente para uma f-string que é executada pelo cursor. Então, o argumento vai direto para a string. Isso é uma péssima notícia,

18:33 Há algumas coisas que vamos fazer assim que isso estiver configurado. Uma delas é instalar o marketplace do SonarQube para Codex. Outra é conectá-lo ao seu projeto. E a terceira é garantir que tudo esteja conectado no plugin. Está quase pronto aqui. Desculpem pela breve espera, pessoal. E, se vocês estiverem…

19:03 fazendo isso por conta própria, espero que já tenha terminado ou esteja quase concluído. Vai terminar daqui a pouco. Mas as três ferramentas em que vou me concentrar hoje são o hook de detecção de secrets que oferecemos. Também temos uma ferramenta para listar issues pelo Codex, que permite ver no terminal qualquer issue do SonarQube. E a terceira permite encontrar e corrigir issues a partir da lista de issues que importamos no próprio plugin.

19:35 Alguém tem alguma pergunta até agora? A propósito, se tiverem perguntas ou se a configuração não estiver funcionando, temos ali a nossa ótima equipe da Sonar. Eles vão acenar para vocês rapidinho. Se levantarem a mão e encontrarem algum problema, eles terão o maior prazer em vir conversar e ajudar vocês com tudo. Certo, a análise foi concluída, e posso abrir o meu painel.

20:09 Vou abri-lo. Como eu disse, este é o painel do SonarQube Cloud, que mostra todos os problemas detectados no seu projeto. E, se vocês tiveram problemas com o Wi-Fi ou para instalar algum dos pré-requisitos, sem problema. Basta recarregar o repo cujo código QR vocês escanearam. Esse repo ficará disponível para vocês.

20:41 Certo. Aqui está o painel, e não vou gastar muito tempo nele. Mas podemos ver que a classificação de segurança é E. Há aqueles três problemas de segurança. São quatro no total.

21:13 Se eu clicar aqui, podemos ver a chave de API da OpenAI que foi detectada. Ela está em texto simples no código-fonte. E, se eu voltar, o outro problema em que quero me concentrar é esta vulnerabilidade de injeção de SQL aqui. É aquela que mencionei a vocês, relacionada à issue da CIS.org. Esta é uma análise de fluxo de dados contaminados, que rastreia os dados desde a origem aqui, passando por diferentes arquivos e funções, até chegar ao destino aqui. Muito, muito útil.

21:47 Certo, voltando ao terminal. Deixe-me abrir minha prática área de transferência de comandos. Vou executar codex plugin marketplace add. Isso vai adicionar o SonarQube Marketplace aqui. Assim que estiver adicionado, vamos abrir o próprio Codex e…

22:20 veremos o plugin do SonarQube disponível e poderemos selecioná-lo. Esperem alguns segundos. Agradeço a todos por terem paciência enquanto resolvo essa pequena lentidão de conexão. Nos workflows agênticos normais, tenho certeza de que tudo vai andar muito mais rápido. Perfeito. Vou abrir o Codex. Ótimo. E vou digitar /plugins.

22:53 e depois pesquisar SonarQube e instalá-lo. Então, é só adicionar o marketplace, executar o comando /plugins, pesquisar SonarQube e pronto, está instalado. Certo. Vou sair daqui para que ele possa recarregar e para eu executar mais alguns comandos. Vou digitar sonar…

23:24 auth login. Isso vai autenticar a CLI, o que nos permitirá usar muitos dos recursos em que o plugin se baseia. Depois, finalmente chegaremos à última etapa de integração: basta executar Sonar integrate codex assim que isso terminar. Sim, permita. Perfeito.

24:01 Isso deve levar, espero, não muito mais tempo. Alguns segundos. Vamos atualizar isso e então executar o comando integrate codex aqui. Ah, parece que está encontrando mais alguns problemas…

24:32 Vou tentar de novo. Parece que, por algum motivo, o token do Sonar que foi exportado está se perdendo. Vou voltar para vocês rapidinho. Vamos ver se conseguem ver minha tela de novo.

25:07 Perfeito. Vou à área de transferência e trazer isso de volta. Certo. O que isso vai fazer são algumas coisas diferentes. Vai configurar o hook de detecção de secrets. Vai adicionar a diretiva AGENTS.md para usar todas as skills do SonarQube, além de outras skills e da configuração do MCP.

25:45 Perfeito. Isso só vai demorar mais um pouco e, depois, tudo estará totalmente integrado para usar o plugin do SonarQube para Codex. Conferindo o horário. Certo, estamos bem. No meu caso, isso vai instalar mais duas coisas que alguns de vocês que usam a conta gratuita talvez não vejam: o aumento de contexto e a análise agêntica. A análise agêntica é um hook que é acionado…

26:18 imediatamente após qualquer edição feita pelo agent. Então, se você pedir que ele crie ou modifique um arquivo, ele será executado automaticamente e fará uma análise do código no servidor, do código que acabou de ser escrito. O aumento de contexto detecta quando o Codex está prestes a realizar uma tarefa e fornece as diretrizes, a arquitetura relevante e outras informações desse tipo. Certo, finalmente estamos…

26:49 a todo vapor, pessoal. Algumas coisas foram adicionadas, especificamente alguns hooks. Também há algumas skills nos bastidores. Vou copiar isto rapidinho. Vou abrir o Codex. Confiar em todos esses hooks. Obrigado, sandbox. E o servidor MCP está sendo iniciado com o SonarQube. Vou pedir: “Ei, você pode fazer um commit usando meu token?”

27:20 Este é um secret falso que o plugin sugere que vocês testem imediatamente. Vou dizer que sim. Como podem ver, isso foi bloqueado na hora. Nenhum secret vazou para o contexto L1. Nada está sendo armazenado em logs nem nada do tipo. Além disso, se você pedir para ele ler um arquivo que contém um secret, ele não fará isso. O acesso será bloqueado. O Codex nunca consegue ver nenhum dos seus secrets ou qualquer coisa…

27:53 que esteja vazando para o seu contexto. Isso é muito importante. As pessoas fazem isso o tempo todo. Todos nós sabemos o que fazer. Sim. >> Escreva um script para ler o arquivo. >> Então, >> isso é possível. Isso funciona principalmente no uso de ferramentas, certo? É um hook acionado ao enviar o prompt do usuário para a ferramenta. Então, se isso for contornado…

28:26 é possível que esse hook não seja acionado. Mas, no uso básico do Codex e das ferramentas dele, ao enviar prompts e coisas do tipo, se você colocar algum secret no prompt ou houver alguma outra coisa, ele vai detectar. Parece que estamos com um pouco de problema de conexão com a internet aqui. Vou iniciar o servidor MCP de novo rapidinho.

29:00 O servidor MCP vai nos permitir usar as skills para interagir entre o Codex e o painel do SonarQube Cloud que vimos antes. Por exemplo, se dissermos: “Ei, liste todas as issues do meu projeto”, ele consegue buscá-las e retornar as informações para nós. Vou sair daqui rapidinho e abrir de novo…

29:34 para iniciar novamente o servidor MCP do SonarQube. >> Sim. Desculpe, estou com dificuldade para ouvir. Você poderia chegar mais perto ou…

30:05 falar um pouco mais alto? Mais alto. >> Sim. Executar isso por conta própria. O script apply sonar, que configura tudo para mim, nunca leva mais de um minuto quando executo sozinho.

30:39 Tudo o mais sobre o MCP leva mais ou menos o mesmo tempo que qualquer outro MCP, supondo uma conexão normal. Estou fazendo o possível para lidar com a conexão daqui, mas, fora isso, eu diria que nenhum deles gera custos adicionais nem acrescenta nada ao workflow normal de um desenvolvedor. Então, vou confirmar rapidinho se esse MCP está funcionando.

31:14 E, como eu disse, o MCP dá acesso a todas as ferramentas. Assim, sempre que você pedir algo relacionado ao Sonar, como consultar os problemas no seu projeto, ele detecta automaticamente o que está acontecendo e invoca as skills relevantes. Uma dessas skills é o enriquecimento de contexto, que reconhece: tudo bem, temos as ferramentas do SonarQube, mas parece que nossa rede não está disponibilizando nada disso para o MCP.

31:48 Vamos ver. Vamos ver se funciona mesmo assim. Vou pedir: liste os problemas no meu projeto. Mais alguma pergunta até agora? Já que estamos esperando, posso responder a algumas. Sim. >> Sim. Então, a CLI na verdade só configura tudo. O MCP é executado no Docker. Então, às vezes, ele passa pelo MCP quando está

32:23 usando alguma das skills disponíveis nele. Mas, na maior parte do tempo, esse plug-in e todo o resto só configuram tudo e depois invocam as skills por ali. >> A CLI ajuda a provisionar e configurar o MCP e tudo mais. E há comandos que você pode invocar pelo MCP com a CLI. Quero esclarecer a diferença. Existe uma CLI sobre a qual esse plug-in funciona. Então, há certas coisas em que você pode dizer: “Ei,

32:53 execute esta tarefa para mim”, e ela pode encaminhá-la por uma skill do MCP ou por um comando da CLI. Certo, parece que o MCP está funcionando, só está muito lento por causa da rede, mas conseguiu detectar isso para nós. Então, além da nossa skill de listagem de problemas, também podemos ver essa skill de enriquecimento de contexto. E, ao examinar as skills, ele também está executando a

33:26 verificação de segredos para garantir que não haja chaves de API nem nada parecido vazando, inclusive quando examina qualquer um dos arquivos, incluindo os próprios arquivos de skill. Certo, está tudo válido. Ele está examinando tudo isso e, mais uma vez, estamos enfrentando problemas de conexão com a rede. Isso deveria acontecer muito mais rápido em um workflow normal com agents. [fungada] Mais alguma pergunta que eu possa responder enquanto

33:58 esperamos isso iniciar? >> Enterprise Server. Sim, com certeza. Isso está disponível em todos os níveis de uso do SonarQube: Cloud, Server, Enterprise e também no plano gratuito. Todos deveriam ter acesso. A limitação é que não oferecemos enriquecimento de contexto nem análise agentic no plano gratuito. Mas, se

34:35 sua organização tiver essas permissões, você poderá usar essas ferramentas. Certo. Conseguimos ver que os mesmos problemas que vimos no dashboard também estão disponíveis agora na CLI. Imaginem que isso levou 15 segundos e que o engenheiro tem uma conexão Wi-Fi estável. Ele terá isso disponível bem rapidamente no IDE. Aqui está o

35:09 problema de severidade bloqueadora relacionado a segredo que mencionei antes. Mas o que quero destacar e corrigir hoje é este S8702. Essa é uma regra que criamos especificamente para workflows agentic com IA. Não queremos que agentes de programação com IA escrevam código que outros agents possam explorar. Esse é o fluxo cy.orgv que descrevi um pouco antes. Mais uma vez, qualquer pessoa com acesso a cy.orgv poderá controlar seu

35:42 banco de dados. Queremos evitar isso. Então, vou pedir ao Codex: “Ei, corrija s2”. Ele vai executar. E, mais uma vez, você pode puxar todos esses problemas diretamente para o terminal e pedir ao Codex que os corrija. Uma diferença entre a minha máquina e a de qualquer pessoa que esteja acompanhando é que, assim que o código for editado e alterado aqui, o hook post tool use da

36:16 análise agentic será executado. O que ele faz é verificar no lado do servidor, com o SonarQube, se a correção introduziu novas vulnerabilidades. Se você não tiver análise agentic, tudo bem: pode analisar seu código no próximo push para a CI ou algo assim. De qualquer forma, a análise agentic vai verificar tudo; ela fecha esse ciclo e dá feedback automático para você saber que não introduziu mais nenhum problema.

36:50 Não sei vocês, mas às vezes, em sessões de programação, eu digo: “Ei, corrija este problema”, e aí aparecem mais três. Tento corrigir esses também, e é como tentar derrotar uma hidra: os problemas vão se multiplicando. Isso verifica automaticamente que você não está introduzindo novas vulnerabilidades. Ótimo. Conseguimos corrigir isso. Temos uma consulta parametrizada. Excelente. E esse hook post tool

37:21 use termina. Ele informa que há um problema no arquivo, mas que já existia antes. Esse era um dos problemas que eu já tinha deixado de propósito no código. Então, ele não vai tentar resolver todo o resto do arquivo para você. Ele é inteligente e percebe que vai analisar o código que alteramos para garantir que ele não introduziu novos problemas. Muito bem.

37:53 Ele reanalisou o código em tempo real e confirmou que passou. E não estamos mais reportando o S8702. Então, conseguimos encontrar e corrigir problemas e verificar automaticamente o código novo à medida que ele chega ao nosso workspace. Certo. Quero reservar um pouco de tempo para perguntas no final. Então, vou passar para esta última parte. E aqui temos

38:28 a adição de uma nova função, certo? Excluir uma tarefa pelo ID em database.py. Quando pedimos que ele crie código novo, ele vai usar o enriquecimento de contexto. Como mencionei antes, isso busca no projeto contexto, regras e arquitetura relevantes e os fornece ao agent. Não faço ideia de quanto tempo isso pode levar. Imagino que menos de alguns minutos. Normalmente, leva segundos. Mas

39:01 o que também quero que vocês percebam é que, usando isso, fazemos o ciclo completo no terminal enquanto orientamos o agent. Olha, terminou muito rápido. Muito bem. Conseguimos o contexto relevante. Fazemos com que isso seja corrigido ou implementado, neste caso, quando pedimos que implemente um novo recurso. A correção é verificada pelo hook de análise agentic

39:33 e, se houver algum problema, ele será sinalizado e o Codex continuará iterando até que seja corrigido. É assim que aplicamos aqui a metodologia de orientar, verificar e resolver. Certo, não vou passar mais tempo no terminal. Isso está disponível para vocês explorarem quando quiserem. Há mais algumas coisas que podem fazer, como investigar alguns dos problemas restantes. Se a sua organização tiver permissão para usar enriquecimento de contexto e

40:07 análise agentic, experimentem um pouco. Conseguimos ver que os segredos são bloqueados, certo? Podemos encontrar e corrigir problemas existentes. E as novas tarefas que pedimos para ele executar passam por uma camada de verificação bem mais rigorosa. Muito obrigado por esperarem apesar dos problemas de conexão com a rede. Quero dizer que temos um estande da Sonar lá embaixo. Adoraria

40:40 venham conversar com qualquer um de vocês. Adoraria bater um papo sobre programação relacionada à IA ou qualquer outra coisa. Sintam-se totalmente à vontade para vir falar com a gente. Temos brindes, temos Guitar Hero, estamos dando uma festa ali embaixo. Nossa comunidade, a comunidade Sonar — acredito que seja a comunidade —, é um ótimo recurso se vocês ficarem com alguma dificuldade enquanto trabalham no repo por conta própria. É lá que nossos engenheiros, que desenvolvem o produto, podem responder a perguntas e ajudar as pessoas

41:15 que enfrentam problemas. Mas muito obrigado por ouvirem e trabalharem junto comigo. E, se tiverem alguma pergunta, sintam-se à vontade para vir até aqui ou levantar a mão, e podemos resolver juntos. Bem, mais uma vez, muito obrigado por terem vindo. Meu nome é Killian, sou da Sonar, e espero ver vocês no estande. Agradeço. [aplausos]

41:54 [música]

Transcrição original

[00:13] Cool. Uh so I’m here from uh Codex’s deployment engineering team and I want to quickly say a few things to introduce the amazing folks at Sonar as well as Killian. Uh, so I’m gonna skip some of the agent basics I typically talk about because I get the feeling that this audience knows what they’re doing when it comes into that. We’re gonna dive right into the harder questions like what does it mean for an agent to have completed a task? What are trust boundaries? And we have three kind of spicy claims that we want to present as well. Uh, one is done means a task is completed with evidence. two is that

[00:47] containment is not correctness and three is that the feedback contract belongs inside the loop. So when we have an agent loop that tends to follow a few predictable patterns. We tend to have this model action uh we have the execution that is governed by the model. We observe the changes whether that be logs, results, output or otherwise and we continue updating the plan. That’s sort of like the overarching agent loop that we follow. And then with each individual task, we have uh an outcome, we have invariance, we have a generally

[01:19] defined scope for what we’re working on. And of course, we also have acceptance criteria as well. Uh so the definition of done for us typically it’s a reviewable diff, some tool evidence, that type of thing. It doesn’t mean just saying fixed. It actually means saying fixed and providing the evidence supporting this fact. Uh so cheaper implementations tend to shift the bottleneck to specification and verification and that’s really not what we’re wanting to do. Um there’s this idea of correlated failure as well and

[01:50] there’s typically a couple of common failure modes that coding agents uh tend to fall into. it tends to fall back to incomplete context. Uh where or maybe there’s a local fix that violates some global invariance that we have. Uh or better yet the the generated test that we actually do to verify results in the same issues just being propagated through. Uh so selfcritique is useful but it’s not an independent oracle and we often tend to find that some of the results of the agent and the verifier tend to be orthogonal to each other. You

[02:25] can’t uh determine whether a task is done without looking at both parts of it. Uh so you you typically want to almost seek out disconfirming evidence of a task being completed uh according to the compiler is it done according to the tests analysis so on and so forth is it done and it’s you can’t really replace human review in the entire cycle as well. Um the the next point I wanted to quickly hit on is uh containment doesn’t equal correctness. Uh we have the execution layer which typically defines what an agent can do right what

[02:57] tools does it have access to uh what scope does it have uh per view over what approvals does it need to act and then we have the uh with this execution layer we have the artifact layer uh and this is really where the results are evaluated uh is the result acceptable uh what tests were produced what analyses what policy even what intent is there Uh so a sandbox can contain a right but it can’t prove that a query is safe. Uh so what I’m trying to get at is that no

[03:32] oracle is proof and that you want to layer controls with different boundaries. Sort of this defense and depth uh these multi-layers of guardrails. That’s sort of the overall idea. And the great part about that is that you as a [snorts] human, you own the intent, you own the exceptions, and of course you own the decision whether to ship it or not. Uh so this is one last thing. Uh there’s a feedback contract that we tend to advise as well. Uh typically those come with skills um which of course are procedures as to how

[04:05] to accomplish a particular task. uh MCPs contain structured tools and context and of course we are able to provide life cycle checks with hooks really good for finding out if you have hard-coded secrets or that kind of thing as well. Uh so with this you want to create this full CI and human review process that should ultimately be the core of what the human’s role is within this. Uh and that sort of so anyways um what you want to evaluate when you are creating this

[04:35] sort of agentic process is a few things. Uh what’s the boundary for example uh are you able to uh intercept secrets before model input for example? Uh how is the project grounded? Uh do you have any concrete rules or locations or vulnerability paths that you are able to provide? Uh what is the scope? Are parameters binding while preserving behavior. These are things to check for and of course you have to constantly run your rechecks. Uh assert that the agents

[05:07] are not the terminal state. Uh so anyways uh enough yapping from my end of things. Uh if there’s a three points that you take away from me, it’s that done means a task is complete with evidence. Two is that containment is not correctness. And three is that the feedback contract belongs inside the loop so you can fully take advantage of the capabilities that your agents such as codeex provide. [sighs] Uh so Killian, let’s uh let’s make that loop uh complete, why don’t we? That’s about all for mind of things. So

[05:40] thank you so much for uh giving me the opportunity to give this introduction. >> Thank you. If you can take a look at this then um and and scan it and follow through it’ll be very helpful. There are a few prerequisites. Um again I am Killian. I am a developer content engineer at Sonar. Um, so thank you very much again, um, OpenAI and Tony for giving us a little intro into all of this. Um,

[06:11] Codeex is a very powerful tool. I use it all the time. I found it very helpful. It’s has a fast CLI. It has a, uh, pretty smart sandbox system and the hook system that it has as well integrates really well with tools like Sonic Cube like I’d like to hop into today. So, wiring your team for agentic development with sonar cube and open AI. Um, the question I want to pose today is

[06:42] how do we make sure that the code and the output generated by agents like codeex is verified that it’s safe. At Soner, we have this idea of the agent centric development cycle. We did um some some research in the past year or so and we surveyed over a thousand developers and we found that uh 42% of committed code is either AI generated or AI assisted but 96% of developers do not fully trust it. Right? So the vast majority of

[07:17] people do not just think hey this is safe right off the bat. Less than half of them say that they fully verify the code before they push and merge it into the codebase. There’s a bit of tension there. No one trusts it. A bunch of untr untrusted code is getting into the codebase. Um the reason being is that the bottleneck used to be code generation, right? How can we create what we’re what we’re trying to do to achieve the desired outcome? How do we actually write the code for an application that we’re trying to build?

[07:50] um with AI agents that has for the most part part been solved with them either doing it themselves or with the assistance of of AI agents. So the bottleneck has shifted now from just code generation to code verification. Right? We have a massive amount of code being generated but now it is up to the human limitation of hey how do I make sure that this is safe? what help and what tools can I get to verify that this is not going to nuke my codebase or nuke my customers and create all sorts of bad uh issues going on. So we have uh four

[08:26] steps in the AC/DC the agentcentric development cycle. One of them is not necessarily from sonar that is generate that is whatever coding tool you’re using codeex anything else um that is the generate step but sonar owns guide verify and solve. What guide is is we inject the agent with proper context and that includes your project guidelines, any rules, any specific architecture to make sure that it has high quality context before it even starts building

[08:57] anything. We found that this reduces token cost overall and at enterprise scale that I mean saves a lot of money in the long term. verify is as soon as it’s done creating uh whatever task you’ve assigned to a generated code, we want to make sure that no issues are being introduced. So no security issues, code quality issues, maintainability, anything like that. None of that needs to be pushed out to production code. And then solve is okay, we have detected there’s an issue, right? There’s some sort of injection vulnerability or

[09:31] whatever that’s going on. we need to remediate that quickly um and as efficiently as possible so that we can kind of have this iterative coding system right there. And the last slide I’m going to show before we hop into the actual activity is uh the concept of the inner loop and the outer loop of verification. Outer loop is your traditional CI system that you have set up, right? So you write code, you push it to GitHub, GitLab, whatever you use,

[10:01] the pipeline runs and something may fail, right? Your test or a scan or sonar cube may fail and then you go back to the IDE and then you try and fix it and then you push it and then it fails again. This has been the bane of my existence, the bane of many developers existences. So we want to save time by shifting left to the interloop and that’s the IDE. So that’s as soon as we are done generating code, we want to verify that it is correct within the IDE

[10:33] without having to push it out. Um, this saves a lot of time. Uh, I mean, especially, you know, being able to automatically verify all this stuff. Time is money at at enterprises and your engineers save a lot of money on therapy bills as well without that frustration. Um all right that is the last slide I really want to focus on uh before hopping into the terminal. [snorts] Uh a few quick things I want to touch base on

[11:04] before that you’re going to see two uh two tools that I’m going to talk about our tool for context our tool called context augmentation is what we’re going to use for the guide stage and our tool for agentic analysis you’re going to see in the verify stage. We’ll come back to those later. [snorts] Um, and the the big takeaway as well that I want everyone to keep focusing on is this bottleneck has shifted from code generation to code verification. Um, before we hop in as well, everyone

[11:35] should have Docker running if you’re able to on your computer. And just quick show of thumbs just so I have an idea of people who have been able to follow along with the prerequisites so far. Thumbs up if you got Docker running and are kind of primed, ready to go. hop into the terminal and follow along. Awesome. A few. Perfect. Thank you. Um if not, again, this repo is available. You can follow through with this on your own time. Um you will have all of this information. So, let me pop out of this real quick. I only have limited view.

[12:09] Cutting the top part of my screen off, but should be good to go. All right. So the first thing that we are going to do is we are going to run this script called apply sonar. Um this is just the the repo that I clone locally. [snorts] This is going to require a bash terminal. So if you’re on Windows you can use git bash or something like that. Um so I’m going to go ahead and type that in. That is apply sonar. All right. And this is going to do a few

[12:40] things. This is a personal tool that I built. It is not an official Sonar product. Um, it is just a shortcut. So, we’re not spending 10 minutes clicking through a UI or anything like that. Make sure my Wi-Fi is doing all right. Okay. Running through a little bit of computer slowness up here. Um, but it’ll this will create a Sonar Cube cloud project for you. Um, runs the first scan for you.

[13:12] Okay, EU and it will off me in. So, we’ll just pop open the browser. Um, this will install a few related Sonar Cube tools for you like our CLI and anything else that we’re going to need to run our plugin with Codeex on top of. All right, bear with me as it looks like I’m bumping into just a little bit of Wi-Fi slowness in here, but shouldn’t be a big

[13:43] issue. So, that has been successful. Um, you’re going to want to put in um the org that you want. So, the org that you were created that was uh created for you when you made an account. [snorts] and that’ll run. Um, this right here, just to talk about the project, this is a tiny Python project. Nothing complicated. There’s like four files,

[14:16] less than 200 lines total. And I have planted four vulnerabilities in there. Three of them are security vulnerabilities and one of them is a code smell. And um when this script gets done running, then we’re going to hop into the dashboard and make sure that uh we can see stuff up there. All right. Normally, uh I think there’s a lot of people trying to access this Wi-Fi. Uh I’ve not seen this take longer than a minute on my own personal Wi-Fi. So, if you’re following along at home, don’t

[14:50] think you’ll have to be sitting around like this um for a little while. Whoops. So, I am You know what? I may have actually forgot to export my token, which is a step in the repo real quick. So, um this should be in your shell. I’m going to pull out my disconnect real quick just for a second so I don’t expose my sonar token to a room full of a bunch of people. And then I’ll pop

[15:20] right back in. Uh so there should be some steps in the the repository. You will navigate through the dashboard. I think it’s under administration within sonarcube cloud. All right. re mirror.

[15:55] All right. So, this will run. Um, a few things I want to talk about as well. So, we are going to see a uh SQL injection issue that pops in. Okay, awesome. This looks like it’s working now. Um, so it’ll go through and it’ll automatically create um everything for me in the dashboard. The security rating that it will come up with is going to be E. This is the very lowest. We have uh baked in some security issues and uh Sonar Cube

[16:26] immediately detects these and says, “Hey, this is no good.” The next thing that I’m going to dig into as soon as this gets loaded is just walk through a couple issues. One of them is going to be an open AP uh open AI API key. Very relevant if people are using codecs. I have done this. It’s actually right here in the codebase. Oops, someone forgot to use an env file or pass this in as a variable. Um, this happens all the time. And what a lot of

[16:57] times what happens is people accidentally push these into production code. Um, and the average remediation time for a secret in a public repository is 90 days right now. That is crazy. that is your your token is just sitting out there for all the world to see, all the bots to scrape for 90 days. We want to prevent this as much as possible and we have a couple tools for that here. Um, another issue that I’m going to highlight for y’all here in a second is

[17:27] there is a SQL injection vulnerability. Um, and if anyone who was just perusing through this code is a security wiz, you may have noticed it, but um, right here in this database.py file, I am passing in um, a query from here directly into an fstring that is being uh, cursor executed. So the argument is going straight into the string. That is bad

[17:58] news bears especially because this um function search task is being uh given an argument from cy.orgv that means that anybody who controls cy.orgv RV gets to control your database, right? This is really bad. Sonar Cube is able to detect this and will let you know, hey, here is the data flow that we’re detecting. It’s using symbolic execution and taint analysis to identify the data flow and and trace it as it moves through your application.

[18:33] Um, there’s going to be a few things that we do as soon as this is set up. One of them is um installing the the sonar cube codeex marketplace. Another one is wiring that to your project. And then another one is um making sure that everything is is connected in the plugin. So this is almost done here. Apologize for that short wait, folks. Um, and if you are

[19:03] running this yourself, hopefully it is um either finished so far or or almost done. This will be done momentarily. But the three tools that I’m going to focus on today are [snorts] the um the secrets detection hook that we offer. We also have a uh list issues tool through codecs and that allows you to see any of the issues from sonar cube within the terminal. And then the third one is being able to find and fix issues from

[19:35] those listed issues that we pull in in in the plugin itself. [snorts] Any questions so far from anyone? If you have questions, by the way, if your setup’s not working, we have our lovely team from Sonar over there. They’re going to wave hi real quick. Um, if you raise your hand and bump into anything, they are more than happy to come over and talk to you and and help you through everything. All right, analysis complete and I can go ahead and

[20:09] click into my dashboard. Open that up. Like I said, this is going to be our Sonar Cube cloud dashboard that shows you all of the issues that it’s detected um within your project. And if you’ve had any issues with Wi-Fi or or being able to install any of the prerequisites, um again, no problem. This repo that you scanned uh the QR

[20:41] code for, just reload that. That repo is going to be up for you. All right. So, here’s the dashboard and I’m not going to spend too much time here. Um, but we can see here that this security rating is E. There are those three security issues. There are four total.

[21:13] If I click on this, we can see here is that OpenAI API key that was able to detect uh that that’s here. Um just plain text in the source code. And if I go back, the other one I want to focus on is this SQL injection vulnerability right here. This is the one I talked to uh y’all with the the CIS.orgv issue. And this is taint analysis tracing the data flow from the source here all the way through different files and functions into the sync right here. Very

[21:47] very helpful. All right, popping back over to the terminal. Um, let me hop over to my handy dandy uh command clipboard that I have here. I’m going to do codeex uh plugin marketplace add. And what that’s going to do is that’s just going to add the Sonar Cube Marketplace here. And um this as soon as that’s in, we’re going to hop into a codeex itself, we

[22:20] will see the Sonar Cube uh plugin available and we’ll be able to select that. So give that a few seconds. Uh, appreciate all of you all folks being able to bear with me as I bump into just minor connectivity slowness. Again, in your normal agentic workflows, I’m sure things will be moving much faster for you. Perfect. I’m going to pop open codeex. Sweet. And I’m going to do slashplugins

[22:53] and then just search for sonar cube and install it. So that is get the marketplace run it slashplugins uh invocation and then type in sonar cube and that is installed. Right. I’m going to exit out of this so that it can reload and so I can just run a couple more commands. Um, I’m going to uh say sonar

[23:24] off login. That’s just going to authenticate the CLI um which uh will allow us to use a lot of the capabilities that the plug-in is built off of. After that, uh, we’re going to get to finally the the final wiring step, which is just Sonar integrate codecs as soon as this gets off for us. Yep. Allow that. Perfect.

[24:01] So, that will take hopefully not too too much longer. Uh, a couple seconds. get that updated and then we’ll write um do this integrate codeex command here. Oh, looks like it’s running into some more. Um

[24:32] try that. Look like for some reason the the Sonor token which is exported is getting lost. Pop back in for youall real quick. See if you can’t see my screen again.

[25:07] Perfect. I’m going to go to the clipboard and pull this back over. All right. So, uh, what this is going to do is a few different things. This is going to get you your secrets detection hook. This is going to get you your agents uh MD directive to use all the solder cube skills and this is going to give you um other skills and uh the MCP config as well.

[25:45] It’s perfect. This is just going to go on a little bit longer and then everything will be fully wired up to use the Sonar Cube codeex plugin. Quick time check. Okay, we should be good. So for me, this is going to install uh two extra things that some of you who are using the free account may not see. That is context augmentation and that is agentic analysis. Uh agentic analysis is a hook that fires

[26:18] instantly after any edit that the agent does. So if you tell it to write a file or modify any file, it will automatically execute and that runs serverside analysis on the code that was just written. What context augmentation does is it detects hey when it’s about to do something when Codex is about to perform a task then it will feed it with the the guidelines and uh relevant architecture and other information like that. Okay, we are we are finally

[26:49] rocking and rolling here folks. We have a few things that were added. Um, specifically some hooks in here. There are some skills under the hood as well. And I’m going to copy this real quick. So, I’m going to pop open codeex. Trust all of these hooks. Thank you, sandbox. And the uh the MCP server is getting booted up with sonar cube. I’m going to do is I’m going to say, hey, can you push a commit using my token?

[27:20] This is a a fake secret that um the the plug-in suggests that you try with immediately. Say sure. So you can see instantly this was blocked. No secrets were leaked into the L1 context. Nothing is being stored in any logs or anything like that. As well if you ask it to read a file with a secret in it, it will not do it. It will be blocked. Codex never gets to look at any of your uh secrets or anything like

[27:53] that that are that are being leaked into your context. This is super important. People do it all the time. We all know what to do. Yes. >> Write a script to read the file. >> So, >> that’s possible. Um, this mainly works on the tool use, right? It’s it’s a hook that’s invoked on on the the user prompt submit tool. So, if that is bypassed,

[28:26] then it is possible that that hook may not be invoked. But for basic usage of um codecs and its tools and and and prompting it and things like that, if you leak any um secrets into the prompt or if there’s anything, it will detect that. Uh, looks like we’re having a little bit of internet connectivity right here. Uh, I’m going to reaunch up that MCP server real quick.

[29:00] And so what the MCP server is going to allow us to do is to use the skills that allow us to interact uh with between codecs and and the Sonar Cube cloud uh dashboard that we saw earlier. For instance, if we were to say, hey, list all of the issues in my project, it’s able to fetch that and uh and return information to us. I’m just going to go ahead and exit out of this real quick and open it back up

[29:34] and get that Sonar Cube MCP server booted right back up. >> Yes. I am very sorry it’s hard for me to hear. Would you mind walking up or

[30:05] speaking a little louder? Louder. >> Yes. running this on my own. The apply sonar script that get gets us all provisioned for me never takes longer than a minute if I’m running it on my own. Um

[30:39] everything else the MCP is is about as long as any other MCP that it takes assuming normal connectivity. Um, I’m doing my best to work with the connectivity here, but um, outside of that, I would say there’s no extra, uh, overhead that any of these really apply for or any of these add to a normal, um, developer workflow. So, I’m going to double check that that MCP is uh, up and running real quick.

[31:14] And um like I said, what what the MCP does is allows you to have access to all of the tools to where anytime you ask it to do something related to uh Sonar, like the issues in your project, it automatically detects what’s going on um and and will invoke any of those relevant skills. One of those skills is context augmentation, which is knowing that okay, we have the sonar cube tools, but our network does not seem to be populating uh the MCP with any of that.

[31:48] Let me see. Let me see if it’ll work with us regardless. Let me say list the issues in my project. Um, any other questions so far? Figure I might as well take a few while we’re waiting. Yes. >> Yes. So, the the the CLI um actually only sets up the configuration. The MCP runs within Docker. So, it will sometimes go through the MCP if it’s

[32:23] using any of the skills um that it has there. But for the most part, this plugin and everything just sets up the configuration and then invokes um skills through there. >> The the the CLI helps you provision and set up the MCP and everything like that. And then there are commands that you’re able to to invoke through the MCP with the CLI. And I want to clarify the difference. There’s a CLI that this plug-in lives on top of. So there are certain things where you can say hey

[32:53] execute um you know this this task for me and it may route through route it through an MCP skill or through a CLI command. Okay so looks like we have the MCP it’s just running very slow because of network because it was able to detect that for us. So in our list issue skill as well as this context augmentation skill we can also see that hey even when it’s looking at its skills we are running the

[33:26] secret scan and making sure that there are no uh API keys nothing like that uh leaked in uh when it when it takes a look at at any of its files including its own skill files. Okay, we’re valid. It’s looking through all of these and again um running into network connectivity here. This should all happen in a normal uh agentic workflow. Uh much quicker than that. [snorts] Any other questions I can take while we

[33:58] wait for this to to to boot up a little bit? >> Uh enterprise server. Yeah, absolutely. This is available across any levels of of Sonar Cube use. Be that cloud, be that server, be that enterprise, be that the free tier. Um, everybody should have access to this. Now, uh, the limitation there is uh, context augmentation and agentic analysis are two tools that we do not offer on the free tier. Um, but if you

[34:35] have those entitlements in your org, then you’ll be able to use those tools. All right. So, we were able to see that we can get those same issues that we saw in the dashboard now available in the CLI. Imagine that this took 15 seconds and that the uh that the engineer has a fully connected Wi-Fi connection. Um they will have this available very quickly within their IDE. Here is the uh

[35:09] uh secret blocked uh blocker severity that I mentioned earlier. But the one that I want to highlight and get fixed today is this S8702. This is a rule that we wrote specifically for AI agentic workflows. We do not want AI coding agents to write code that other agents are able to exploit. That is the cy.orgv flow that I described a little bit earlier. Again, anybody who has access to cy.orgv will be able to have control over your

[35:42] database. We want to prevent this. So, I’m just going to tell uh codeex say, hey, fix s2. That’s going to run. And again, all of these issues, you can instantly pull them to your terminal and ask codeex to fix it. There was going to be something that is different on my machine versus anybody following along is that is you’ll see as soon as code is edited and changed here. The post tool use hook for

[36:16] agentic analysis will run. What that does is if there were any new vulnerabilities introduced in the fix sonar cube will scan it server side. If you do not have agentic analysis that is totally fine. you can just scan your code uh during your next uh CI push or anything like that. But um regardless it will get verified using a gentic analysis just closes that loop and gives you automatic feedback to know that hey I have not introduced any more issues.

[36:50] Um, I don’t know about y’all, but I have been in uh coding sessions sometimes where I’m like, “Hey, fix this issue.” And then three more kind of pop up and I’m trying to fix those and it’s like trying to conquer a hydra where these just kind of propagate out. Using this automatically verifies that you’re not causing any new uh vulnerabilities to come about. Awesome. So, we were we were able to fix this. We get a parameterized query. Wonderful. Um, and this post tool

[37:21] use hook completes. What it lets you know is is it lets you know there is an issue in the file. However, that existed beforehand. That was one of the issues that I had already pre-baked in here. So, it’s not going to try and solve everything else in your file for you. it is smart and it just realizes that hey whatever was in the code that we changed we’re going to uh analyze that and make sure that there are no new issues introduced from that code. So wonderful.

[37:53] Um it reanalyzed that code in line and verified that it passed. Um and we no longer report uh S8702. So we are able to find and fix and automatically verify um new code uh as it comes into our workspace. All right. So I want to leave a little bit of time for questions at the end. So I’m just going to um move through to this last piece here. And this is

[38:28] um adding a new function, right? delete a task by ID to database.py. And this when asking it to come up with uh new code, it will use context augmentation. As I mentioned earlier, this fetches relevant context rules architecture from your project and feeds that into the agent. Now, I have no idea how long this may take to work. I imagine within less than a few uh minutes. Normally, it’s seconds. Um

[39:01] however what I want you to realize as well is that using this is the full cycle all within the terminal as we are guiding the agent. Oh look it finishes very quickly. Very well done. um is we we um get relevant context. Um we you we get this to be fixed or implemented in this case when we’re asking it to implement a new uh feature. It gets verified from the uh agentic analysis

[39:33] hook and if there were any issues in there uh they would be flagged and Codex would continue to iterate until it is remediated. So that’s how we’re getting that guide, verify, and solve uh methodology in here. All right, I’m not going to spend any more time in the terminal. Um this again is available for you to work on uh at your own leisure. Uh there’s a couple more things in there that you can do like um go ahead and track down some of the remaining issues. Um if your org has entitlement for context augmentation and

[40:07] energetic analysis uh using that a little bit um but we are able to see that secrets get blocked right we can do find and fix on issues that exist and then new tasks that we’re having it do uh have a much stricter verification layer wrapped around it and thank you very much for waiting through some of the network connectivity issues with this um I want to say that we at Sonar have a booth downstairs. I would love uh to

[40:40] come and talk to any of you guys. Would love to chat about either AI related coding or anything outside of that. Uh feel more than free to come out and say hi to us. We have swag, we have guitar hero, we are we are um having a party down there. Um, our uh community that we have, our sonar community, I believe it’s community. Is a great resource if you get stuck working through the repo at all in your own time. Um, that is where our engineers who build the product are able to answer questions and and help people

[41:15] along um who who run into issues. But thank you very much for uh listening and working along with me. And if you guys have any questions, uh, feel free to come up or raise your hand and we can work through that. Well, again, thank you very much for coming. My name is Killian, uh, with Sonar and, uh, I hope to see you down at the booth. Appreciate it. [applause]

[41:54] >> [music]