PHP ganha reforço para lidar com a nova onda de reports gerados por IA

Author: Compilado do Código Fonte TV [OFICIAL] · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: Portuguese

Original video: PHP ganha reforço para lidar com a nova onda de reports gerados por IA · Channel: Compilado do Código Fonte TV [OFICIAL] · 06:53 · Watch on YouTube

Topics: Cybersecurity and software security, Software engineering with AI, Open source and software ecosystems

Summary

A PHP Foundation incorporou temporariamente Daniel Teaser ao Ecosystem Security Team para ajudar a lidar com o aumento de reports de segurança e PRs relacionados ao PHP, muitos deles gerados com ferramentas de IA. Nem toda contribuição enviada corresponde a uma vulnerabilidade formal, mas algumas ajudam a tornar o código mais robusto. A conversa aborda a dificuldade de manter projetos open source diante do aumento de contribuições e questiona os riscos de aprovar código sem revisão humana. O debate conclui que projetos precisam encontrar um equilíbrio no uso de IA, sem aceitá-la indiscriminadamente nem rejeitá-la por completo.

Key points

A PHP Foundation anunciou a entrada temporária de Daniel Teaser no Ecosystem Security Team.
O aumento do uso de ferramentas de IA contribuiu para o crescimento de reports de segurança e PRs enviados ao PHP.
Nem todos os reports recebidos se enquadram na definição formal de vulnerabilidade adotada pelo PHP.
Daniel Teaser já contribui com PHP, mantém a extensão reflection e atua como release manager do PHP 8.5.
Contribuições feitas para atender a uma necessidade específica nem sempre são adequadas para o projeto como um todo.
A geração de bugs e funcionalidades com IA pode ampliar o volume de trabalho para quem mantém projetos.
A aprovação de PRs sem revisão humana pode criar problemas futuros de código, gestão e governança.
O uso de IA deve ser avaliado de forma equilibrada, considerando os riscos tanto da adoção irrestrita quanto da rejeição total.

Chapters

Start	Chapter	Summary
00:02	PHP reforça a segurança do ecossistema	A PHP Foundation anuncia a chegada temporária de Daniel Teaser à equipe de segurança para lidar com o aumento de reports e contribuições.
01:35	O desafio de contribuir para projetos open source	A conversa explica como necessidades específicas geram issues e PRs que nem sempre são adequadas para o projeto como um todo.
03:41	IA, volume de contribuições e revisão de código	O aumento de código produzido com IA levanta preocupações sobre a capacidade de revisão humana e a governança dos projetos.
05:16	Encontrar equilíbrio no uso de IA	Os participantes comparam diferentes posturas diante da IA e defendem evitar tanto a adoção irrestrita quanto a rejeição total.

Quotes

Nem tudo o que chega ali se encaixa na definição formal de vulnerabilidade de segurança adotada pelo PHP. — 00:32

O problema é que isso escala de uma forma que fica difícil para quem está mantendo. — 03:41

O fato de não ter mais nenhum humano olhando o código pra poder revisar, eu acho que a gente tá cavando problemas pro futuro. — 04:14

Não é 8 nem 80. — 05:16

Concepts and entities

PHP Foundation, Daniel Teaser, Ecosystem Security Team, Alpha Omega, PHP, reflection, Open Cloud 2.0, Zig

Full transcript (original language)

00:02 E PHP ganha reforço para lidar com nova onda de reports gerados por quem? Pela inteligência artificial. >> PHP Foundation anunciou a chegada de Daniel Teaser ao ecossistema aí, ele entrou no Ecosystem Security Security Team. Em uma movimentação importante para quem acompanha a evolução e a segurança do ecossistema PHP. O time foi criado com apoio do Alpha Omega e tem como missão melhorar a segurança em diferentes partes do ecossistema. Não apenas aí no core da linguagem. Segundo a fundação, o crescimento do uso de

00:32 ferramentas de IA, assim como em outros ecossistemas também, né? Aumentou o volume de reports de segurança e PRs enviados pela comunidade ao PHP Sources, ou seja, ao core, né? Só que nem tudo o que chega ali se encaixa na definição formal de vulnerabilidade de segurança adotada pelo PHP. Mesmo assim, muitas dessas contribuições ajudam a deixar o código mais robusto, corrigem aí pontos frágeis e reduzem as chances de novos reports repetidos no futuro. É um trabalho aí de bastidor, mas bem valioso. É muito trabalho, né? Mas bem

01:03 valioso para manter a plataforma saudável. >> Daniel entra no time em caráter temporário para ajudar justamente nesse acúmulo de issues que fortalecem o PHP, mas não necessariamente viram alertas de segurança tradicionais. Ele não chega como um nome aleatório. Ele começou no open source contribuindo com o próprio PHP. Atualmente mantém a extensão reflection, atua como release manager no PHP 8.5 e será um veteran release manager do PHP 8.6. Ou seja, é alguém

01:35 que já conhece bem os processos, o código e as dores de manter uma linguagem usada em produção por milhões de aplicações. Esse é um esforço mais organizado para tratar harden, qualidade e segurança como partes contínuas da evolução do PHP. >> Mais um um projeto com problemas. >> Brigando, lutando contra a enxurrada, talvez? >> Enxurrada de issues e PRs. Então isso está acontecendo em tudo que a gente está vendo hoje. Mas por quê? Porque quando as pessoas que utilizam projetos open source, invariavelmente, pode ser a

02:07 própria o core da linguagem, quanto é bibliotecas, eles acabam tendo algum tipo de limitação. Tipo assim, putz, ao invés de eu de eu baixar aqui uma biblioteca e ela ter uma funcionalidade, eu falo assim, putz, eu vou ter que implementar essa funcionalidade porque ela ela não existe e isso meu projeto requer. Aí qual era o caminho? Ou a pessoa personaliza, dependendo da biblioteca dá para fazer isso, né? Você personaliza em casa, é você cria uma camada ali extra e aí toda vez que você atualiza, você tem uma camada ali que está compatível. Ou você envia uma PR ou

02:39 uma issue para o para o projeto. Mas muitas vezes aquele tipo de funcionalidade que você está criando, que você estendeu ali, ela não faz sentido para o projeto. >> Às vezes é específica demais para sua necessidade e não para o projeto num todo, né? >> E aí muitas vezes você abre uma issue, abre uma PR, aí passa aí alguns dias, aí ele você você faz todo um um trabalho de documentação, de mostrar, mas ou seja, e tem muita gente que faz isso simplesmente para mostrar que está contribuindo também e aí é negado. Não estou dizendo que acontece no no caso do PHP, mas em muitos outros

03:11 é muito difícil às vezes você poder conseguir contribuir. E aí a pessoa fica meio assim, cara, sacanagem, né? Tanto trabalho e eu não eu não vou conseguir ali nem um reconhecimentozinho, nem algo ali. E aí é obviamente para quem trabalha com isso profissionalmente e precisa manter um projeto com personalizações, né? Aí você vai ter que criar uma outra camada e aí que você vai ter que estender essa biblioteca ou ou ou essa funcionalidade para conseguir ter o que você espera. E aí muita gente já está usando

03:41 inteligência artificial, tanto para corrigir bugs, mas para criar novas funcionalidades. O problema é que isso escala de uma forma que fica difícil de >> para quem está mantendo, né? >> Para quem mantendo. Então, tem coisas que e aí realmente, quando você vai falando de segurança de PHP, ó, nós temos essas diretrizes aqui. Tudo que vier fora dessas diretrizes não tem que aceitar. Você lembra aí na semana passada ou retrasada, a gente falou do Open Cloud 2.0, pra formar ali a versão 2.0 foram 16.000 pull requests. >> Como controlar isso tudo em poucas

04:14 semanas, né? Porque não faz tanto tempo assim do lançamento. É, difícil. >> Você você acha que teve revisão humana de todas essas PRs? Dificilmente, né? Então, o pessoal tá criando CI/CD até pra pra aprovação de PR usando IA. Eu temo assim, sabe, sabe? Não que os humanos não cometam erros de código, mas o fato de não ter mais nenhum humano olhando o código pra poder revisar, eu acho que a gente tá tá cavando problemas pro futuro, tá? Não tô dizendo que todos os projetos vão dar errado ou

04:46 tudo vai caminhar pra um buraco onde a gente vai ter que aprender novamente a usar o assembly, sabe? Porque não não vai dar mais pra >> Não é pra tanto. >> Não é isso, mas vários projetos vão ter problemas seríssimos ali daqui a pouco, até de gestão, de governança. >> Quando você pega um projeto como PHP, igual nós falamos aqui na reportagem, né? Poxa, são milhões de pessoas utilizando, milhões de projetos utilizando. Então, realmente tem que ter esse cuidado muito mais restrito ali nas aprovações e no que você vai trazer ali

05:16 pra linguagem. É um trabalho difícil mesmo. Perfeito, né? >> É, não é 8 nem 80, né? É, semana passada a gente mostrou aí o Linus que usou inteligência artificial, mas ele usou de uma forma controlada pra tentar identificar um problema e aí sim foi identificado o problema, a IA ela identificou o problema, ele viu exatamente o que que era, que era uma linha de código, era mudança de uma função e aí sim ele foi e deixou os créditos. Agora, isso é diferente do que o o próprio autor lá, o criador do Zig, da linguagem Zig, diz, ele falou assim:

05:47 “Aqui não entra IA, de forma nenhuma”. Por quê? Porque eles Aí é um outro lado, ele ele ele entende que IA nunca gera código que seja aproveitável e não é o caso, tá? Então, não dá para ser nem 8 nem 80 com esse tipo de coisa. Não dá para abrir as pernas e ir assim: “Vem”. Entendeu? E também não dá para falar assim: “Não, vou me fechar”. E aí ele acaba tendo problemas também por ficar com o projeto engessado, sabe? Engessado a a ponto de não ter mais adesão suficiente porque às vezes não não tá

06:19 evoluindo na velocidade que tem que evoluir. >> E esse aqui é um corte de uma notícia do compilado do Código Fonte TV. >> Onde toda semana tem episódio novo falando de programação, tecnologia, inteligência artificial e cibersegurança. >> Então, já se inscreve aqui no canal do compilado e acompanhe os episódios completos. >> [música] [música]

06:53 [música]