TL, DR
Nos últimos anos, a indústria tecnológica tem defendido fervorosamente o conceito de “mudança para a esquerda” no desenvolvimento de software, defendendo a integração precoce de práticas de segurança no ciclo de vida de desenvolvimento. Este movimento visa capacitar os desenvolvedores com a responsabilidade de garantir a segurança do seu código desde o início do projeto. No entanto, embora as intenções por trás desta abordagem sejam nobres, a realidade pinta um quadro mais matizado – onde a noção simplista de confiar apenas nos desenvolvedores para manter segurança da cadeia de suprimentos de software revela-se inadequada. Neste artigo, apresentarei uma abordagem de equilíbrio complementar: barreiras de proteção SDLC dirigidas pelo CISO – medidas de controle automático que governam ou aplicam a política de segurança do SDLC.
Quem saiu do meu queijo?
O paradigma da mudança para a esquerda, em essência, visa abordar questões de segurança nos estágios iniciais de desenvolvimento, esperando que os desenvolvedores incorporem proativamente medidas de segurança em seu código. É uma ideologia atraente em que os desenvolvedores têm a tarefa de identificar vulnerabilidades e implementar controles de segurança à medida que escrevem e implantam seu código.
No entanto, esta abordagem idealista encontra desafios significativos na implementação prática. Embora proficientes em codificação, os desenvolvedores podem não ter conhecimento abrangente em técnicas e práticas recomendadas de segurança. Seu foco principal gira em torno do atendimento aos requisitos funcionais, e esperar que eles possuam uma compreensão exaustiva do cenário em constante evolução da segurança cibernética não é realista.
Além disso, as restrições de tempo e as pressões do projeto resultam frequentemente em compromissos entre a segurança e o cumprimento dos prazos. Na pressa de fornecer recursos prontamente, os desenvolvedores podem inadvertidamente ignorar possíveis brechas de segurança ou empregar práticas de codificação menos seguras, deixando as vulnerabilidades sem solução até fases posteriores. No final das contas, seus KPIs são orientados para a velocidade e a segurança sempre estará em segundo lugar para a maioria deles.
Insira as proteções CI/CD
É aqui que a necessidade de implementar “proteções” de segurança no pipeline de Integração Contínua/Implantação Contínua (CI/CD) se torna evidente. Os Guardrails atuam como pontos de verificação automatizados incorporados ao pipeline de desenvolvimento, garantindo que as medidas de segurança não dependam apenas de intervenções manuais ou da experiência ou motivação individual do desenvolvedor.
Guardrails atuam como guardiões proativos, monitorando e aplicando constantemente padrões, políticas e regras de segurança em todo o ciclo de vida de desenvolvimento de software (SDLC). Essas verificações automatizadas podem abranger vários aspectos de segurança, incluindo, entre outros, lista de bloqueio de pacotes ruins, interrupção de código que contém vulnerabilidades críticas, falha em testes de análise de código estático ou tem dependências problemáticas e adesão a padrões de conformidade ou a políticas SDLC seguras (por exemplo, código revisão para cada commit).
Usando conceitos de política como código, pode-se criar quase qualquer regra que se possa imaginar para ser implementada como uma proteção. Aqui estão alguns exemplos de regras de guarda-corpos em linha com NIST800-204D:
Regras exemplares de guarda-corpos:
- Estação de trabalho do desenvolvedor
- Verifique o conjunto de segurança de endpoint da estação de trabalho do desenvolvedor
- SCM
- Verifique as regras de proteção de filiais: aplique revisões múltiplas\específicas
- Verifique se os arquivos CI são modificados apenas por pessoal autorizado
- Verifique se a verificação secreta está em vigor e se os segredos não foram detectados.
- CI
- Verifique se a digitalização do código está em vigor.
- Verifique se os resultados da verificação de código estão em uma barra predefinida
- Dependências
- Verifique o licenciamento de código aberto.
- Verifique se as vulnerabilidades de código aberto estão em conformidade com a política da organização
- Artefatos
- Verifique se a identidade correta assina os artefatos.
- Verifique as vulnerabilidades do artefato final.
Guarda-corpos, não corrimãos
Ao integrar proteções ao pipeline de CI/CD, as organizações podem impor sistematicamente protocolos de segurança e resultar em um produto seguro sem depender apenas dos desenvolvedores para garantir medidas de segurança abrangentes. Levando em conta que os desenvolvedores podem contornar as medidas de segurança em prol do ritmo de desenvolvimento, a abordagem de guardrails torna essas decisões impossíveis ou pelo menos visíveis, para que possam ser levadas em consideração – tanto no nível de construção única (por exemplo, decidir sobre a confiabilidade do artefato ) e no nível organizacional (compreender o que pode e o que não pode ser esperado dos desenvolvedores da organização). Ferramentas automatizadas podem sinalizar ou até mesmo bloquear possíveis vulnerabilidades ou problemas de não conformidade antes que a nova versão seja lançada para produção ou entregue ao cliente. Afinal, lidar com um problema de segurança na fase de desenvolvimento e não após a entrega é de facto muito mais fácil, rápido e barato.
É imperativo reconhecer que, embora a mudança para a esquerda incentive o envolvimento dos desenvolvedores nas práticas de segurança, ela não deve absolver outras partes interessadas — profissionais de segurança, engenheiros de DevOps e equipes de garantia de qualidade — de suas funções. Se você é um segurança de produto, AppSec, DevSecOps ou CISO, então já sabe que “mudar para a esquerda” a responsabilidade para com os desenvolvedores não tira a responsabilidade de seus ombros. Como a maioria dos CISOs e suas equipes não vêm de P&D, os ambientes de desenvolvimento de software estiveram historicamente fora de vista. Tradicionalmente, eles se concentrariam na segurança operacional, na segurança da rede e na conectividade entre organizações. A abordagem de guardrails é uma maneira de levar “delicadamente” os CISOs para o oeste selvagem dos ambientes de desenvolvimento, recuperando o controle sobre o que eles são responsáveis. Por “delicadamente” quero dizer “colaborativamente”. Como a segurança do produto é um esforço conjunto das equipes de segurança e desenvolvimento, a colaboração entre essas entidades é essencial para projetar e implementar proteções robustas que fortaleçam o pipeline de CI/CD contra possíveis ameaças à segurança sem impedir a velocidade do desenvolvimento.
A integração dos princípios de mudança para a esquerda com o estabelecimento de barreiras de proteção no pipeline CI/CD é um bom equilíbrio. Os desenvolvedores continuam responsáveis por escrever código seguro e compreender os princípios básicos de segurança enquanto a equipe de segurança decide os padrões que o produto precisa atender para ser lançado. Em seguida, as proteções são automatizadas em ferramentas e processos para atuar como rede de segurança, monitorando e reforçando continuamente os padrões de segurança e a política SDLC. As proteções são um passo essencial em direção a produtos seguros por design e por padrão.
Resumindo
Concluindo, embora bem-intencionado, o conceito de mudança para a esquerda não garante segurança abrangente de software apenas através do envolvimento do desenvolvedor. Para reforçar a integridade e a confiabilidade do artefato de software final, as organizações devem adotar a implementação de proteções dentro do pipeline de CI/CD. Essa abordagem combinada não apenas eleva a postura de segurança do software, mas também promove um ambiente colaborativo onde desenvolvedores, profissionais de segurança e ferramentas de automação trabalham sinergicamente em direção a um objetivo comum de criar software seguro.
Este conteúdo é oferecido a você pela Scribe Security, um fornecedor líder de soluções de segurança de cadeia de suprimentos de software ponta a ponta – fornecendo segurança de última geração para artefatos de código e processos de desenvolvimento e entrega de código em todas as cadeias de suprimentos de software. Saiba mais.
Artigos Relacionados
