Bom, vamos explorar um pouco mais agora sobre o conceito de DevSecOps. DevSecOps nada mais é do que incluirmos segurança no ciclo do desenvolvimento do software e não mais como uma equipe ou um departamento apartado onde tínhamos mais interação quando o software já estava em produção. Essa abordagem traz muito mais confiabilidade ao produto, pois trazemos as etapas de segurança para a fase inicial do desenvolvimento e garantimos que o nosso software esteja sem vulnerabilidades críticas a serem exploradas, até porque não adianta um código funcional que não tenha segurança. Então aqui toca fortemente em segurança by design, a gente pode ter um código extremamente funcional, extremamente performático, atende todas as funcionalidades do ponto de vista funcional e não funcional, exceto segurança. Então é um código que acaba não servindo para gente. E para gente conseguir alavancar esse pilar de segurança dentro do ciclo de desenvolvimento do software, utilizando DevOps para isso, a gente passa a ter algumas técnicas ali. Então, vamos falar um pouquinho mais sobre cada uma delas. A primeira seria o SAST, ou Static Application Security Testing. Bom, ela é uma técnica de análise estática que examina o código fonte, ou código compilado, de uma aplicação em busca de vulnerabilidades de segurança. Ela procura por falhas de segurança como vulnerabilidades de SQL Injection ou XSS e uso inadequado de APIs e outras vulnerabilidades. O SAST é realizado durante a fase de desenvolvimento do software, geralmente como parte do processo de continuous integration. Eu acho que vale pontuar que, além dessa análise estática procurando por exploits, por essas vulnerabilidades que a gente possa estar injetando dentro do nosso código, muitas dessas ferramentas possuem algumas métricas de code smells, que são indicadores que podem indicar que tenhamos potencialmente algo para ser corrigido dentro do nosso código. Então, pode ser que não sejam exatamente bugs ou falhas de segurança, mas pode estar mais relacionado, por exemplo, a padrões de código que podem indicar algum problema de design, algum tipo de complexidade desnecessária, falta de coesão, acoplamento, ou questões que podem afetar a qualidade e dificultar a manutenção do código de forma geral. Alguns exemplos, por exemplo, de code smells que podem surgir, são métodos ou funções muito grandes, trechos de código duplicados, dependência cíclica, trechos de código duplicados, dependência cíclica, onde a gente usa de repente algum componente que depende de um outro e vai acabar gerando um problema, ou até complexidade temporal, onde a gente tem ali o for dentro de for, e quando a gente mudar de repente os dados que a gente está trabalhando, a gente passa a ter um problema dentro do nosso ambiente, um problema de performance dentro do nosso aplicação. Então, além dessa questão das vulnerabilidades em si, eu acho bem legal essa questão do CodeSmells também, que vale pontuar. também que vale pontuar. Bom, uma outra técnica que a gente poderia utilizar, que a gente utiliza bastante aqui também, falando de DevSecOps, é o DAST, que é uma técnica de análise dinâmica que avalia o software em execução para implementar vulnerabilidades de segurança enquanto ela está sendo executada. O DAST envolve pen-tests automatizados ou manuais, onde é feita a simulação de ataques de um invasor externo. Ele procura por vulnerabilidades que podem ser exploradas quando o software está em execução, como configurações erróneas, inadequadas, falhas de autenticação e autorização, entre outros. O DAST normalmente é realizado em um ambiente de homologação ou até mesmo de produção, tendo como principal foco ambientes de perímetro, ambientes que ficam expostos para a internet. ambientes que ficam expostos para a internet. Então, essas ferramentas, elas são geralmente também baseadas ali no ASP, no ASP Top 10, e dependendo do ambiente, podem ser necessários algumas questões regulatórias, como, por exemplo, compliance com PCI. Então então ambientes que requerem esse tipo de compliance esse nível a mais de segurança, SAST é uma excelente técnica são ferramentas que a gente consegue colocar dentro do nosso ambiente para trazer tanto essa questão regulatória quanto essa camada de segurança adicional. Então, o que a gente falou, o SAST é muito mais voltado para o código-fonte, capturando exploits e essa questão de qualidade do CodeSmells, e o DAST a gente já está falando de uma análise dinâmica. A gente já tem esse código em produção funcionando ali. Então, é rodar e entender quais são as vulnerabilidades depois que esse cara já está em produção, que a gente pode explorar e baseado fortemente nas vulnerabilidades mapeadas pelo OASP. e baseado fortemente nas vulnerabilidades mapeadas pelo OASP. Indo para a última técnica, o IAST, Interactive Application Security Testing, é uma técnica que combina elementos de SAST e DAST. Ao contrário do SAST, que analisa o código-fonte em repouso, e do DAST, que testa o aplicativo em tempo de execução, o IAST monitora a execução da aplicação durante os testes de segurança e examina o código-fonte em busca de vulnerabilidades enquanto a aplicação está sendo executada. Isso permite uma análise mais precisa e contextualizada das vulnerabilidades, pois leva em consideração o contexto da aplicação em execução. Vale pontuar que o IAST pode ser implementado tanto no CI, após a compilação do código, utilizando alguma ferramenta como o Fortnite, por exemplo, quanto no CD, em fase de deploy, geralmente utilizando como base o ambiente de homologação ou testes.