Como desenvolvedores protegem código gerado por IA: 5 boas práticas de segurança

Autoria: IBM Technology · 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: How Developers Secure AI-Generated Code: 5 Security Best Practices · Canal: IBM Technology · 11:02 · Assistir no YouTube

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

Resumo

O vídeo apresenta cinco princípios de segurança para o desenvolvimento assistido por IA: validar os resultados, integrar a segurança desde o início, examinar dependências, esclarecer a intenção e manter a validação continuamente. Código que compila e passa em testes ainda pode expor dados, ter permissões excessivas ou falhar de modo inseguro. A análise também deve considerar requisitos e regras de negócio, além do código e da cadeia de suprimentos de software. Como agentes podem executar tarefas em vários sistemas, eles precisam de limites, controle de acesso, monitoramento e supervisão humana.

Pontos-chave

Código gerado por IA não é automaticamente confiável: é preciso validar se o resultado é seguro em condições reais.
A segurança deve fazer parte do desenvolvimento desde o início, com análises e verificações automatizadas durante a criação do código.
Dependências geradas ou introduzidas pela IA também precisam ser avaliadas quanto a reputação, vulnerabilidades, licenças e integridade da origem.
Requisitos e intenção precisam estar claros para evitar soluções tecnicamente corretas que violem políticas ou exponham dados.
A validação de segurança deve continuar após o lançamento, acompanhando mudanças, dependências e vulnerabilidades.
Agentes que atuam em vários sistemas precisam de limites, identidades, controles de acesso, monitoramento e supervisão humana.
Velocidade não basta: o valor do desenvolvimento assistido por IA depende de confiança nos resultados.

Capítulos

Início	Capítulo	Resumo
00:00	Segurança desde o início do desenvolvimento	O vídeo explica por que práticas de segurança precisam acompanhar o desenvolvimento assistido por IA, em vez de serem adicionadas apenas no fim.
03:17	Validar código e dependências	O apresentador defende verificações de segurança durante o desenvolvimento e a análise das dependências introduzidas pela IA.
06:05	Intenção e validação contínua	O vídeo destaca a importância de explicitar requisitos e manter a segurança ativa ao longo de todo o ciclo de vida.
09:21	Proteção de agentes e confiança nos resultados	O trecho aborda controles e supervisão para agentes e conclui que é preciso validar continuamente os resultados em bases de código cada vez mais complexas.

Citações

Código gerado por IA não é o mesmo que código confiável. — 01:40

Quanto mais cedo você encontra um bug, mais barato é corrigi-lo. — 03:51

Não estamos mais apenas revisando a qualidade do código; estamos avaliando se a IA resolveu o problema certo da maneira certa. — 07:10

Só a velocidade não cria valor; a confiança, sim. — 10:27

O objetivo é verificar os resultados com confiança. — 11:02

Conceitos e entidades

shift-left security (conceito): Abordagem que incorpora verificações de segurança desde as etapas iniciais do desenvolvimento e ao longo de todo o ciclo de vida.
AI-generated code (conceito): Código produzido por IA, que ainda precisa ser verificado quanto à segurança e à adequação aos requisitos.
software supply chain (conceito): Conjunto de componentes e dependências de software cuja segurança também precisa ser avaliada.
dependency validation (conceito): Verificação de dependências quanto a reputação, vulnerabilidades, licenças, integridade da origem e padrões organizacionais.
human-in-the-loop oversight (conceito): Supervisão humana das ações de agentes para reduzir riscos e assegurar que operem dentro dos limites definidos.
zero-day vulnerability (conceito): Vulnerabilidade de segurança que, no exemplo citado, foi descoberta em um sistema operacional open source.
IBM Technology (empresa): Canal do YouTube que publicou o vídeo.

Tradução completa (pt-BR)

00:00 A IA está mudando o desenvolvimento de software mais rápido do que qualquer transformação tecnológica que vimos em décadas. Há 40 anos, quando eu escrevia código sem parar no início da minha carreira, o processo era incrivelmente complexo, demorado e sujeito a erros. Hoje, os desenvolvedores podem gerar código, testes, agents, tarefas de IA com várias etapas e até workflows com apenas um prompt. Em poucas palavras, a IA é uma revolução. Mas há um desafio. As práticas de segurança criadas para código escrito por humanos e ciclos de desenvolvimento mais lentos não se adaptam automaticamente ao desenvolvimento assistido por IA.

00:36 Se a segurança só entra em cena no fim do processo, como uma adaptação posterior, a qualidade sofre e todo o processo para de repente. A solução vem de uma fonte inesperada. Acontece que Beyoncé sabia do que estava falando quando cantou: “Para a esquerda, para a esquerda”. É, a segurança precisa mudar. Para a esquerda. A segurança começa nas primeiras etapas do desenvolvimento e continua ao longo de todo o ciclo de desenvolvimento de software, se estivermos fazendo isso direito.

01:07 Esses conceitos não são novos, embora, para ser sincero, nem sempre os tenhamos colocado em prática como deveríamos. Mas, na era da IA, deslocar a segurança para a esquerda significa mais do que apenas executar algumas ferramentas de segurança mais cedo no processo. Significa coisas como estas: o que vamos validar? Quando vamos validar? E como construímos confiança nas soluções geradas por IA? Vamos dar uma olhada em cinco princípios fundamentais de segurança desde o início para melhorar os resultados do desenvolvimento assistido por IA.

01:40 Código gerado por IA não é sinônimo de código confiável. Portanto, o primeiro princípio é simples: confie no resultado, não apenas na geração. Uma das coisas mais enganosas sobre o código gerado por IA é que muitas vezes ele parece correto. Ele compila, é executado e passa em todos os testes de segurança. Então pensamos que está tudo bem, mas ainda assim ele pode criar um risco de segurança oculto, que você não consegue ver. E essa é a parte da qual não temos consciência.

02:11 Só porque a implementação técnica parece ter sido bem-sucedida, não significa que a solução seja segura. Cada vez mais, os desenvolvedores precisam validar aspectos como as permissões e os vazamentos de dados. Se eles estão ocorrendo, e como estamos lidando com falhas. O sistema falha de maneira segura ou falha em um estado aberto e perigoso? Por exemplo, um serviço gerado por IA pode recuperar corretamente informações de clientes do banco de dados, mas será que deveria mesmo ter acesso a todas as informações armazenadas nele?

02:43 Há dados confidenciais sendo potencialmente exfiltrados da organização? O que acontece se a autenticação falhar? E o que acontece se dados malformados forem parar nesse banco de dados e o corromperem? Bem, essas são coisas que não são tão fáceis de perceber. É aqui que precisamos perguntar não apenas se o código funciona, mas se é seguro. Precisamos perguntar se o código fornece os resultados esperados e se comporta com segurança em condições reais.

03:17 Esse é o resultado que precisamos validar. O segundo princípio é que a segurança começa durante o desenvolvimento. Tradicionalmente, muitas organizações tratavam as revisões de segurança quase como uma consideração posterior. O que acontecia era o seguinte: os desenvolvedores terminavam de programar, depois os componentes eram compilados, as funções eram testadas, o código era registrado em um commit e, então, acontecia a revisão de segurança. Basicamente, era uma caixa para marcar no fim do processo. Esse modelo nunca funcionou muito bem e enfrenta ainda mais dificuldades em um ambiente de desenvolvimento assistido por IA.

03:51 Porque a história nos ensina que quanto mais cedo você encontra um bug, mais barato é corrigi-lo. Se você só o encontra depois que já chegou à produção, fica muito caro. Encontrá-lo no início do processo sai bem barato. E os bugs de segurança não são diferentes nesse aspecto. Quando a geração de código pode acontecer em segundos, esperar até o fim cria gargalos e aumenta o risco. Por isso, deslocar a segurança para a esquerda aprimora a validação dentro do próprio processo de desenvolvimento.

04:23 Isso significa executar automaticamente análise estática do código-fonte, testes dinâmicos de penetração, testes de penetração, buscar segredos embutidos, validar políticas, verificar a conformidade — tudo isso — enquanto o código está sendo criado. O objetivo é reduzir surpresas desagradáveis mais adiante no ciclo de vida, deslocando a segurança para a esquerda. Eis uma realidade importante do desenvolvimento com IA: a IA não cria apenas código. Ela também introduz dependências.

04:56 Então temos coisas como novos pacotes, novas bibliotecas, novos serviços e novas integrações. Cada dependência acrescenta funcionalidades, o que é bom, mas cada uma delas também acrescenta riscos, o que não é tão bom. Os desenvolvedores geralmente se concentram em revisar o código-fonte gerado e ignoram aquilo de que esse código depende. Tudo isso acontece nos bastidores, graças às maravilhas da IA. Então é como se estivesse fora da vista, fora da mente. Mas, em alguns casos, os incidentes de segurança têm origem na cadeia de suprimentos de software, e não apenas na lógica da própria aplicação.

05:32 Por isso, as dependências geradas também devem passar pelo mesmo nível de análise que o código gerado. Precisamos analisar aspectos como a reputação dos pacotes, vulnerabilidades, licenciamento, integridade da origem e padrões organizacionais. No desenvolvimento assistido por IA, validar dependências não é opcional. É parte da geração de código seguro. Esta pode ser a mudança mais importante de todas. Muitos problemas graves de segurança não são causados por práticas ruins de programação.

06:05 Eles são causados por suposições incorretas. Pense em perguntas como: quem realmente deveria ter acesso aos dados e quais ações são permitidas? Quais regras de negócio precisam ser aplicadas? E quais informações devem continuar protegidas? Um modelo de IA pode gerar código tecnicamente elegante e seguir as melhores práticas de desenvolvimento, mas, se os requisitos forem mal compreendidos, a solução ainda poderá violar as políticas de segurança. Veja o que quero dizer.

06:35 Um workflow gerado pode processar corretamente dados financeiros e, ao mesmo tempo, expor essas informações a usuários que nunca deveriam vê-las. Isso não é tanto um problema de programação quanto um problema de intenção. Então, temos de considerar a intenção. E, com a IA, é preciso ser especialmente claro quanto a essa intenção. Na mitologia grega, o rei Midas desejou que tudo o que tocasse se transformasse em ouro. Seu desejo foi atendido, e ele quase morreu de fome como resultado, porque acabou descobrindo que não dá para comer ouro.

07:10 À medida que a IA gera código cada vez mais sofisticado na velocidade das máquinas, os desenvolvedores passam a ter mais responsabilidade por validar o resultado. Ainda há trabalho para você fazer aqui. Em outras palavras, não estamos mais apenas revisando a qualidade do código; estamos avaliando se a IA resolveu o problema certo da maneira certa. O quinto princípio é que a segurança precisa se tornar uma prática contínua, e não apenas uma última verificação no fim. Como mencionei antes, historicamente, as organizações concentravam as atividades de segurança perto do lançamento.

07:43 Mas o desenvolvimento assistido por IA produz mudanças continuamente. O que também significa que a validação de segurança precisa acontecer — adivinhe só — continuamente. Isso quer dizer que ela continua mesmo depois do lançamento. Então, se pensarmos no processo, desenvolvemos, testamos, fazemos o deploy, monitoramos e aprimoramos; tudo isso precisa de segurança. A segurança está presente em cada um desses componentes do ciclo.

08:15 Como colocaríamos isso em prática? Precisamos de coisas como detecção de vulnerabilidades, usando também alguns dos melhores modelos de fronteira de IA, para que estejamos sempre atentos a todas as vulnerabilidades. Vamos monitorar dependências e aplicar patches. Também vamos verificar e impor políticas, além de validar mudanças. Então, a pergunta não é apenas se passou uma vez, mas se continua passando. Continua sendo seguro?

08:46 A questão é se a confiança se mantém ao longo do tempo. Por exemplo, recentemente, um modelo de fronteira de IA encontrou uma vulnerabilidade de dia zero em um sistema operacional open source que estava escondida à vista de todos havia 27 anos. A lição é que a segurança nunca está concluída. Ela precisa se tornar uma parte viva do processo, que evolui junto com o software. À medida que a IA se torna cada vez mais agentic, ela realizará cada vez mais trabalhos com várias etapas, envolvendo serviços, repositórios, pipelines e configurações.

09:21 Nesse ponto, revisar arquivos individuais deixa de ser suficiente. A segurança depende de entender todo o workflow. Os problemas de segurança mais difíceis não estão escondidos em uma única função. Eles surgem de consequências não intencionais em sistemas conectados. Isso significa que os agents precisam de limites de segurança que lhes digam o que podem e não podem fazer, o que é apropriado e o que não é. Eles precisam de identidades, para que possam ser responsabilizados e possamos ver quem fez algo e por quê. Também precisam de controles de acesso que limitem as capacidades de acesso que eles

09:57 têm, para que não possam alterar coisas que não pretendíamos, e precisam de monitoramento e supervisão humana integrada ao processo. Sem supervisão e aplicação adequadas, os agents podem agir sem controle e se tornar amplificadores de risco, em vez de ferramentas de produtividade. Esta é a nova realidade: precisamos proteger com rapidez e validar continuamente. A IA está acelerando o desenvolvimento de software. Isso significa que podemos gerar mais código em um minuto do que costumávamos conseguir gerar em um dia inteiro.

10:27 E isso significa que vamos gerar muito mais código. E isso significa que mais código significa mais funcionalidades. Também significa mais complexidade. E a complexidade é inimiga da segurança. Só velocidade não cria valor; confiança, sim. As organizações que tiverem sucesso serão aquelas que incorporarem a segurança diretamente aos workflows de desenvolvimento do dia a dia. Não como um exercício de conformidade, nem como uma barreira para o lançamento, mas como uma prática de validação contínua. Porque, na era do desenvolvimento assistido por IA, o objetivo já não é simplesmente revisar o código.

11:02 O objetivo é verificar os resultados com confiança em uma base de código que está sempre crescendo e se tornando cada vez mais complexa, e fazer isso mais rápido do que nunca. E lembre-se: para a esquerda, para a esquerda.

Transcrição original

[00:00] AI is changing software development faster than any technology shift we’ve seen in decades. 40 years ago, when I was banging out code in the early days of my career, the process was incredibly complex, time-consuming, and error-prone. Today, developers can generate code, tests, agents, multi-step AI tasks, and even workflows with just a prompt. Quite simply, AI is a game changer. But there’s a challenge. Security practices that were designed for human written code and slower development cycles don’t automatically scale to AI assisted development.

[00:36] If security only happens at the end of the process as a retrofit, the quality suffers and the whole process comes to a screeching halt. The solution comes from an unexpected source. It turns out that Beyonce knew what she was talking about when she sang to the left, to the lift. Yeah, security needs to shift. To the left. Security begins at the earliest stages of development and continues throughout the software development cycle if we’re doing it correctly.

[01:07] These concepts aren’t new, although to be honest, we haven’t always practiced them as we should, but in the AI era, shift left means more than just running a few security tools earlier in the process. It means things like this. What? Are we gonna validate? When do we validate it? And how do we build confidence in AI-generated solutions? Let’s take a look at five key principles of shift-left security to improve the results of AI-assisted development.

[01:40] AI-Generated code does not equal trusted code. So the first principle is simple. Trust the outcome, not just the generation. One of the most deceptive things about AI-generated code. Is that it often looks correct. It compiles, it runs, it passes all the security tests. So we think this is okay, but it can still create a security risk down below that you don’t see. And that’s the part that we’re not aware of.

[02:11] Just because the technical implementation appears successful doesn’t mean the solution is secure. Developers increasingly need to validate things like the permissions, the data leaks. If those are occurring, and how are we handling failures? Does the system fail safe or fail in an open dangerous condition? For example, an AI-generated service might correctly retrieve customer information from the database, but should it really have access to all of the information that’s in there?

[02:43] Is sensitive data potentially being exfiltrated from the organization? What happens if authentication fails? And also what happens if malformed data ends up into this database and corrupts it. Well, this is the stuff that’s not so easy to see. This is the part that has asked the question, not just does the code work, but is it secure? The question that does the cold provide expected results and behave securely under real world conditions is what we need to be asking.

[03:17] That’s the outcome we need validate. The second principle is security starts during development. Traditionally, many organizations treated security reviews almost as an afterthought. So what would happen is, we’ve got developers finish their coding, then the components are built, the functions are tested, the code gets committed, and then the security review happens. Basically, it’s a checkbox at the end of the process. That model never really worked well and struggles even more in an AI assisted development environment.

[03:51] Because history teaches us that the earlier you find a bug, the cheaper it is to fix. If you find it once it’s already gone into production, super expensive. Find it early in the process is pretty cheap. And security bugs are actually no different in that regard. And when code generation can happen in seconds, waiting until the end creates bottlenecks and increases risk. So shift left security improves validation into the development process itself.

[04:23] This means automatically running static source analysis, dynamic pin testing, penetration testing, scanning for embedded secrets, policy validation, compliance checks, all of that stuff, and doing this while the code is being created. The goal here is to reduce unpleasant surprises later in the life cycle by shifting left. Here’s an important reality of AI-generated development. AI doesn’t just create code. It also introduces dependencies.

[04:56] So we’ve got things like new packages, new libraries, new services, new integrations. Every dependency adds capability, which is good, but every one of those dependencies also adds risk, which isn’t so good. Developers often focus on reviewing generated source code while overlooking what that code depends on. It’s all happening under the covers through the miracles of AI. So it’s kind of out of sight, out of mind. But security incidents originate from the software supply chain rather than just the application logic itself in some cases.

[05:32] That’s why generated dependencies should also undergo the same level of scrutiny as the generated code. We need to review things like package reputation, vulnerabilities, licensing, source integrity. Organizational standards. In AI assisted development, dependency validation isn’t optional. It’s part of secure code generation. This may be the most important shift of all. Many serious security issues aren’t caused by poor coding practices.

[06:05] They’re caused by incorrect assumptions. Consider questions like who should actually access the data and what actions are allowed? What business rules need to be applied? And what information should remain protected. An AI model may generate code that is technically elegant and follows development best practices, but if the requirements are misunderstood, the solution can still violate security policies. Here’s what I mean.

[06:35] A generated workflow may correctly process financial data, yet at the same time, it may also expose that information to users who should never see it in the first place. That’s not as much a coding problem as it is an intent problem. So we have to consider the intent with this. And with AI, you have to be especially clear about that intent. In Greek mythology, King Midas wished that everything he touched would turn to gold. He got his wish and nearly starved as a result because it turns out you can’t eat gold.

[07:10] As AI generates increasingly sophisticated code at machine speed, developers become more responsible for validating the output. There’s still work for you to do here. In other words, we’re no longer just reviewing code quality, we’re reviewing whether the AI solved the right problem in the right way. The fifth principle is that security must become an ongoing practice, not just some final checkpoint at the end. As I mentioned previously, organizations have historically concentrated security activities near release at the ended.

[07:43] But AI assisted development produces change continuously. Which also means security validation must also happen, wait for it, continuously. That means it’s gonna continue even after release. So if you think about the process, we develop, test, deploy, monitor, and improve, and all of that stuff needs security. Security operates in every one of those components in the loop.

[08:15] So how would we realize that? Where we’ve got to have things like vulnerability detection, using some of the best AI frontier models as well so that we’re right on top of all the vulnerabilities. We’re going to do dependency monitoring and patching. We’re gonna also do policy verification and enforcement and change validation. So the question isn’t just did it pass once, but does it continue to pass? Does it continue be secure?

[08:46] The question is whether confidence is maintained over time. For instance, an AI frontier model recently found a zero day vulnerability in an open source operating system that had been hiding in plain sight for 27 years. Lesson from that, security is never done. It has to become a living part of the process that evolves alongside the software. As AI becomes more agentic, it will increasingly perform multi-step work. Across services, repositories, pipelines, and configurations.

[09:21] At that point, reviewing individual files becomes insufficient. Security depends on understanding the entire workflow. The hardest security problems aren’t hidden in a single function. They’re found in unintended consequences across connected systems. That means agents need guardrails to tell them what they can and can’t do, what is appropriate and what’s not. They need identities so that they’re accountable and we can see who did this and why they need access controls that limit the access capabilities that they

[09:57] have so that they can’t change things we didn’t intend and they need monitoring and human in the loop oversight without the proper oversight and enforcement agents can run amok and act as risk amplifiers rather than productivity tools. Here’s the new reality. We have to secure fast and validate continuously. AI is accelerating software development. That means we can generate more code in a minute than we used to be able to do in an entire day.

[10:27] And that means we’re gonna generate a lot more code. And that mean more code means more functionality. It also means more complexity. And complexity is the enemy of security. Speed alone doesn’t create value, trust does. The organizations that succeed will be the ones that embed security directly into everyday development workflows. Not as a compliance exercise, not as a release gate, but as a continuous validation practice. Because in the age of AI assisted development, the goal is no longer to simply review the code.

[11:02] The goal is to confidently verify outcomes across an ever expanding and increasingly complex code base and do it faster than we’ve ever done before. And remember to the left, to the left.