Como o DevSecOps capacita desenvolvedores cidadãos

Até 2025, total criação de dados globais atingirá 181 zettabytes. Para as empresas, esses dados são um ativo, permitindo-lhes aproveitar uma variedade de plataformas de tecnologia para criar experiências de cliente altamente personalizadas que geram fidelidade e atraem novos negócios. No entanto, essas experiências dependem de infraestruturas de nuvem usando modos de segurança compartilhados. É aí que reside o risco, que aumenta à medida que a tecnologia cresce para incorporar um novo exército de desenvolvedores cidadãos usando plataformas de baixo código e sem código.

Compreendendo e superando a mentalidade de herança 

Gartner estima que até 2025, 70% dos aplicativos corporativos serão criados a partir de plataformas de baixo código e sem código, como Salesforce e ServiceNow. Responder com uma mentalidade baseada em herança é uma maneira segura de configurar mais de dois terços dos aplicativos corporativos para falha.   

“Mentalidade de herança” é um descritor adequado para os problemas que assolam a infraestrutura. Isso lembra crianças ricas e mimadas que dependem inteiramente do trabalho realizado e das pessoas que vieram antes delas. Essa não é uma boa maneira de construir um legado e é uma maneira igualmente ruim de construir um sistema.

Quando você tem uma mentalidade herdada, assume que a infraestrutura está definida. A plataforma é segura e a segurança está integrada. A confiança é assumida simplesmente porque a tecnologia já existia antes do administrador.

Essa mentalidade de herança afeta plataformas de baixo código e sem código. Os usuários contam com a segurança de uma plataforma para transportá-los por toda uma infraestrutura corporativa. Em vez disso, a segurança dessa plataforma deve ser aplicada apenas a essa plataforma.

Digamos que os desenvolvedores do Salesforce criem um programa de atribuição automatizado para novos leads. Eles o usam no Salesforce para atribuições internas e está tudo bem. Eles podem confiar na segurança da plataforma. Eles decidem expandi-lo para melhorar a automação. Eles conectam esse programa a um CRM externo, como ServiceNow, SAP ou Oracle. A mentalidade de herança assume o controle: o Salesforce é seguro. ServiceNow, SAP ou terceiros são seguros.

Portanto, Salesforce + terceiros = seguro.

Mas, há muita incógnita nesse sinal de mais. Como você conecta com segurança e conformidade o programa interno criado no Salesforce ao programa externo criado na plataforma de terceiros? Há muito espaço para erros nesse único caractere.  

E isso é apenas uma conexão. Muitos programas criados no Salesforce tocam centenas de outros. São centenas de incógnitas sendo tratadas como o sinal de mais descrito acima por pessoas que têm pouca ou nenhuma experiência em desenvolvimento.  

A única solução é levar esse desenvolvimento de volta à realidade com um retorno aos princípios do DevSecOps.

Estabelecendo a estrutura DevSecOps 

DevSecOps frameworks foram escritos, reescritos e escritos novamente desde que o conceito foi criado. Não há necessidade de reinventar a roda ao estabelecê-los, especialmente quando SAFECode e a Cloud Security Alliance construiu seis pilares:

1. Responsabilidade coletiva: A segurança é responsabilidade de cada pessoa na empresa — mas as pessoas não podem atender aos padrões que não conhecem. Os líderes devem ser designados para conduzir a política de segurança cibernética e garantir que ela seja disseminada por toda a empresa.  
2. Colaboração e integração: O conhecimento deve ser compartilhado e transferido. Metade do motivo pelo qual as empresas caem na mentalidade do legado é que todos que conheciam o sistema antigo se foram. O compartilhamento contínuo de conhecimento ajuda a eliminar esse problema.
3. Implementação pragmática: A implementação pragmática está vinculada à experiência do desenvolvedor. Processos que são difíceis, mundanos e difíceis de manejar não são seguidos por muito tempo. A segurança deve ser incorporada às práticas de desenvolvimento — ou seja, cada linha de código requer uma linha de teste. Uma empresa de alto desempenho levaria isso adiante usando uma ferramenta para automatizar cada linha de código de teste.
4. Conformidade e desenvolvimento: Os requisitos de conformidade devem orientar o processo de desenvolvimento de forma a não permitir que os desenvolvedores se desviem deles. Um desenvolvedor de uma instituição financeira, por exemplo, trabalharia em uma plataforma projetada para estar em conformidade com a Lei Gramm-Leach-Bliley. O desenvolvedor não precisa conhecer os meandros individuais do ato para estar em conformidade porque eles são integrados à plataforma.  
5. Automação: Tarefas previsíveis, repetíveis e de alto volume devem ser automatizadas sempre que possível para remover a carga dos desenvolvedores e reduzir o risco de erro humano.
6. Monitor: As infraestruturas de nuvem modernas mudam e crescem. É vital acompanhá-lo — idealmente, por meio de alguma forma de orquestração que permita uma visão rápida de todas as várias interconexões.

Em um artigo do baixo ou nenhum código ambiente, esses pilares não são tão diretos quanto seria de esperar. As pessoas que usam essas ferramentas geralmente são especialistas em negócios com pouca familiaridade com os fundamentos do DevSecOps.

Unindo Pessoas, Processos e Tecnologia

O uso de plataformas de baixo código e sem código pode realmente ajudar a fechar essa lacuna de habilidades. Os funcionários querem aprender novas habilidades. As empresas podem apoiar isso estabelecendo uma estrutura DevSecOps com foco em pessoas, processos e tecnologia. 

• Processos: Em um ambiente de confiança zero, os desenvolvedores de código baixo e sem código não precisam se preocupar em fazer conexões que ponham em risco a integridade do sistema porque são incapazes de fazê-lo. Eles não têm autoridade de linha de base fora de seu sistema isolado.  
• Pessoas: Uma cultura de responsabilidade é diferente de uma cultura de culpa. Responsabilidade significa que os indivíduos se sentem à vontade para apresentar um problema ou erro porque o foco está no problema, não na pessoa.
• Tecnologia: A tecnologia é a maior barreira para a implementação adequada dos princípios do DevSecOps porque está fora do controle dos desenvolvedores. Eles devem usar o que a organização lhes dá. Se essa tecnologia não funcionar, os desenvolvedores apresentarão soluções alternativas que não são nem seguras nem seguras. Essencialmente, a tecnologia torna-se um grande gerador de sombra de TI.

Vivemos em um momento emocionante para o desenvolvimento. Mais e mais pessoas têm a oportunidade de construir software, testar estratégias e melhorar o valor do negócio. Mas com isso vem o risco. As empresas que procuram maneiras de transferir esse risco para a tecnologia manterão seu desenvolvimento realista, deixando espaço para explorar.