0 
0 Em 2025, a criação total de dados globais atingirá 181 zettabytes. Para as empresas, esses dados são um ativo, permitindo que elas aproveitem 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, e está aumentando à medida que a tecnologia cresce para incorporar um novo exército de desenvolvedores cidadãos usando plataformas low-code e no-code.
Entendendo e superando a mentalidade de herança
O Gartner estima que até 2025, 70% dos aplicativos corporativos serão construídos a partir de plataformas low-code e no-code, 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 falhas.
A “mentalidade de herança” é uma descrição adequada para os problemas que assolam a infraestrutura. Isso traz à mente crianças ricas e mimadas que são inteiramente dependentes do trabalho feito 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, supõe que a infraestrutura está definida. A plataforma é segura e a segurança é incorporada. A confiança é presumida simplesmente porque a tecnologia estava lá antes do administrador.
Essa mentalidade de herança aflige plataformas low-code e no-code. Os usuários contam com a segurança de uma plataforma para transportá-los por toda a infraestrutura corporativa. Em vez disso, a segurança dessa plataforma deve se aplicar 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 tudo bem. Eles podem contar com a 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 Salesforce é seguro. ServiceNow, SAP ou terceiros estão seguros.
Então, Salesforce + terceiro = seguro.
Mas, há muito desconhecido 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 de desenvolvimento.
A única solução é levar esse desenvolvimento de volta à realidade com um retorno aos princípios do DevSecOps.
Estabelecendo a estrutura DevSecOps
Os frameworks DevSecOps 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 o SAFECode e a Cloud Security Alliance construíram seis pilares:
- Responsabilidade coletiva: A segurança é responsabilidade de cada pessoa na empresa — mas as pessoas não podem atender a padrões que não conhecem. Os leads devem ser atribuídos para conduzir a política de segurança cibernética e garantir que ela seja disseminada em toda a empresa.
- Colaboração e integração: O conhecimento deve ser compartilhado e transferido. Metade da razão pela qual as empresas caem na mentalidade do legado é que todos que conheciam o antigo sistema se foram. O compartilhamento contínuo de conhecimento ajuda a eliminar esse problema.
- Implementação pragmática: A implementação pragmática está ligada à experiência do desenvolvedor. Processos que são difíceis, mundanos e complicados 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.
- Conformidade e desenvolvimento: Os requisitos de conformidade devem orientar o processo de desenvolvimento de uma forma que não permita 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 detalhes individuais do ato para estar em conformidade porque eles são incorporados à plataforma.
- 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.
- Monitorar: 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 ambiente com pouco ou nenhum código , esses pilares não são tão diretos quanto se poderia esperar. As pessoas que usam essas ferramentas geralmente são especialistas em negócios com pouca familiaridade com os fundamentos do DevSecOps.
Reunindo pessoas, processos e tecnologia
O uso de plataformas low-code e no-code 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 coloquem 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 de DevSecOps porque está fora do alcance 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 seguras nem seguras. Essencialmente, a tecnologia se torna uma grande sombra geradora de TI.
Vivemos 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.
FONTE: DARK READING