0
0
Passamos a confiar fortemente no ciclo de vida de desenvolvimento de software (SDLC) como o método ideal para obter segurança enraizada nos processos de desenvolvimento. De fato, a suposição de uma integração contínua abrangente / entrega contínua (CI / CD) tornou-se tão fundamental que nós, como indústria, passamos a maior parte do ano passado focados em abordar um de seus derivados: a segurança do pipeline de CI / CD como a peça central da cadeia de suprimentos de software. Esta é uma boa notícia, é claro. Um SDLC adequado e sua manifestação operacional, o CI/CD, nos permitiu incorporar controles de segurança onde eles são mais úteis – enquanto os desenvolvedores estão criando e testando seu software.
Com o aumento contínuo do desenvolvimento low-code/no-code e cidadão na empresa, muitas equipes da AppSec estão ocupadas com a criação de diretrizes de desenvolvimento seguras para esses novos aplicativos de negócios. Colaborações intersetoriais surgiram para fornecer uma estrutura de risco de segurança. O verdadeiro desafio, no entanto, é trazer essa nova onda de usuários de negócios que se tornam desenvolvedores sob o guarda-chuva da segurança.
Os usuários de negócios são os melhores em saber o que os negócios precisam e, portanto, estão melhor posicionados para atender a essas necessidades quando capacitados com ferramentas low-code/no-code que lhes permitem criar seus próprios aplicativos. Por outro lado, tentar discutir riscos de segurança ou práticas de desenvolvimento com usuários de negócios pode ser um desafio.
A incorporação de segurança no SDLC funciona porque é onde é mais confortável para os desenvolvedores consumi-la, tornando menos dispendiosa a correção de uma vulnerabilidade de segurança. Para fazer o mesmo para os usuários corporativos, devemos entender como funciona o processo de criação de aplicativos.
R.I.P. para o SDLC
Uma versão clichê do SDLC mostra como o software vai de articular uma necessidade do negócio; ao planejamento, desenvolvimento e testes por equipes de engenharia e perguntas e respostas; para implantação, monitoramento e gerenciamento pelas equipes de operações. Isso, é claro, varia muito entre as organizações. O ponto importante para nossa discussão é que a responsabilidade é transferida entre diferentes equipes e talvez diferentes departamentos ao longo do ciclo de vida do desenvolvimento. Cada transição também pode ser aproveitada como um portão de garantia de qualidade ou segurança, seja automatizado, como ferramentas SAST/DAST/IAST, ou manualmente, como modelagem de ameaças ou revisão de segurança.
Em contraste, considere o processo de desenvolvimento low-code/no-code. Um usuário de negócios articula suas necessidades, passa a criar seu aplicativo ou automação com uma interface intuitiva de arrastar e soltar, clica em salvar e … é isso! Às vezes, até mesmo a etapa de salvamento é ignorada com um salvamento automático útil. Embora nem todos os aplicativos low-code/no-code sejam criados dessa maneira pela pessoa que os imaginou, muitos são. Observe o quão mais rápido o processo de desenvolvimento pode ser agora – sem troca de responsabilidade ou convencendo alguém a se alinhar com seus objetivos, e todos podem atender às suas próprias necessidades de negócios à medida que são detectados, por conta própria. Este é o poder do desenvolvimento liderado pelas empresas e das iniciativas maduras de desenvolvimento dos cidadãos.
Infelizmente, isso vem com o custo de pular os portões de segurança e qualidade que incorporamos ao ciclo de vida do desenvolvimento. Esses portões foram críticos, especialmente em uma empresa que precisa impor valores que são tão importantes quanto a produtividade dos negócios: segurança, conformidade e privacidade, para citar alguns.
Conhecendo desenvolvedores onde eles estão
Os usuários de negócios estão criando e continuarão a criar mais aplicativos do que já vimos antes. Para colocá-los sob o guarda-chuva da segurança, devemos encontrá-los onde eles estão e falar a sua língua. Em vez de confiar na existência de um pipeline de CI/CD e apresentar aos usuários de negócios conceitos como ambientes de produção versus teste, devemos aceitar a realidade e nos concentrar em facilitar a criação de aplicativos seguros e difíceis de criar aplicativos arriscados.
Para fazer isso, devemos entender as plataformas low-code/no-code que eles usam para criar aplicativos e as maneiras pelas quais esses aplicativos são construídos e adotados por outros. Devemos abraçar nossa responsabilidade de orientar esses novos desenvolvedores, aplicar as melhores práticas de segurança aos aplicativos que eles criam de acordo com o apetite ao risco de nossa organização e adotar uma abordagem retroativa para resolver problemas críticos rapidamente.
FONTE: DARK READING