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

Autoria: Compilado do Código Fonte TV [OFICIAL] · 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: português

Vídeo original: PHP ganha reforço para lidar com a nova onda de reports gerados por IA · Canal: Compilado do Código Fonte TV [OFICIAL] · 06:53 · Assistir no YouTube

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

Resumo

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.

Pontos-chave

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.

Capítulos

Início	Capítulo	Resumo
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.

Citações

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

Conceitos e entidades

PHP Foundation (empresa): Fundação que anunciou o reforço temporário para ajudar a lidar com contribuições e questões de segurança no ecossistema PHP.
Daniel Teaser (pessoa): Contribuidor do PHP que entrou temporariamente no Ecosystem Security Team e atua como release manager do PHP 8.5.
Ecosystem Security Team (conceito): Equipe apoiada pela Alpha Omega que trabalha para melhorar a segurança em diferentes partes do ecossistema PHP.
Alpha Omega (empresa): Organização mencionada como apoiadora da criação do Ecosystem Security Team.
PHP (ferramenta): Linguagem cujo ecossistema está recebendo mais reports e contribuições associados ao uso de IA.
reflection (ferramenta): Extensão do PHP mantida por Daniel Teaser.
Open Cloud 2.0 (ferramenta): Projeto citado na conversa como exemplo de uma versão formada por 16.000 pull requests.
Zig (ferramenta): Linguagem cujo criador é citado como exemplo de uma postura que rejeita o uso de IA no projeto.

Tradução completa (pt-BR)

00:02 E o PHP ganha reforço para lidar com a nova onda de relatórios gerados por quem? Pela inteligência artificial. >> A PHP Foundation anunciou a chegada de Daniel Teaser ao ecossistema. 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 o apoio do Alpha Omega e tem como missão melhorar a segurança em diferentes partes do ecossistema, não apenas 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 relatórios 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 pontos frágeis e reduzem as chances de novos relatórios repetidos no futuro. É um trabalho 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 com esse 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. Começou no open source contribuindo com o próprio PHP. Atualmente, mantém a extensão reflection, atua como gerente de release no PHP 8.5 e será um gerente de release veterano 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 o endurecimento, a qualidade e a segurança como partes contínuas da evolução do PHP. >> Mais um projeto com problemas. >> Brigando, lutando contra a enxurrada, talvez? >> Enxurrada de issues e PRs. Então, isso está acontecendo em tudo o que a gente está vendo hoje. Mas por quê? Porque, quando as pessoas utilizam projetos open source, invariavelmente, seja o core da linguagem, sejam bibliotecas, elas acabam tendo algum tipo de limitação. Tipo assim: “Putz, em vez de baixar aqui uma biblioteca e ela ter uma funcionalidade, eu falo: ‘Putz, vou ter que implementar essa funcionalidade porque ela não existe e meu projeto precisa dela’”. Aí, qual era o caminho? Ou a pessoa personaliza — dependendo da biblioteca, dá para fazer isso, né? Você personaliza em casa, cria uma camada extra ali e, toda vez que atualiza, tem uma camada compatível. Ou você envia uma PR ou

02:07 uma issue para o projeto. Mas, muitas vezes, aquele tipo de funcionalidade que você está criando, que você estendeu ali, não faz sentido para o projeto.

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

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

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

04:14 semanas, né? Porque não faz tanto tempo assim desde o lançamento. É difícil. >> Você acha que todas essas PRs tiveram revisão humana? Dificilmente, né? Então, o pessoal está criando CI/CD até para aprovar PRs usando IA. Eu temo, sabe? Não que os humanos não cometam erros de código, mas acho que o fato de não ter mais nenhum humano olhando o código para revisá-lo é cavar problemas para o futuro, tá? Não estou dizendo que todos os projetos vão dar errado ou

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

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

05:47 “Aqui não entra IA, de forma nenhuma.” Por quê? Porque eles… Aí é outro lado: ele entende que IA nunca gera código que seja aproveitável, e esse não é o caso, tá? Então, não dá para ser nem oito nem oitenta com esse tipo de coisa. Não dá para abrir as pernas e dizer: “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 ponto de não ter mais adesão suficiente, porque às vezes não está evoluindo na velocidade em que tem que evoluir.

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

06:53 [música]

Transcrição original

[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]