Conhecer as vulnerabilidades é apenas metade da batalha
À medida que continuamos nossa jornada rumo à TI contínua, há muito foco na segurança. E bem que deveria haver. Violações abundam. Vulnerabilidades são descobertas diariamente, e a lacuna entre patches não parece estar diminuindo.
Uma das soluções frequentemente sugeridas para tornar o código mais seguro é escanear o código-fonte. As verificações de segurança estáticas e dinâmicas se tornaram um ingrediente essencial nos processos de entrega contínua. Nossos próprios pipelines internos os incluem, e eu posso - a qualquer momento - dar uma olhada em um painel que me diz tudo sobre o que essas varreduras encontram.
 |
Mas saber que existem vulnerabilidades no código-fonte - como G.I. Joe nos lembra - é apenas metade da batalha. Embora fosse fascinante se a outra metade realmente fosse composta de lasers azuis e vermelhos, a realidade da segurança de aplicativos é que a outra metade está "fazendo algo sobre essas vulnerabilidades". Infelizmente, não vemos essa realidade se tornando realidade. Você deve se lembrar de um relatório da Tripwire ( State of Container Security de 2019 ) no qual 17% dos entrevistados admitiram ter contêineres vulneráveis, sabiam o que eram e os implantaram mesmo assim. Você também pode se lembrar de um relatório de 2017 da Arxan/IBM sobre segurança de aplicativos móveis e IoT que descobriu que 53% dos entrevistados usam testes de segurança estáticos e 51% usam testes de segurança dinâmicos para aplicativos móveis. E apesar das preocupações significativas em relação a uma violação, quase metade (44%) não estava tomando nenhuma medida para evitá-la. |
O problema de não testar e não fazer nada sobre vulnerabilidades conhecidas está quase sempre ligado à pressão para diminuir o tempo de retorno do investimento. Quase metade (48%) dos desenvolvedores afirmam não ter tempo suficiente para se dedicar à segurança ( Pesquisa da Comunidade DevSecOps de 2018 ). Outras pesquisas concordam: há uma pressão incrível sobre os desenvolvedores para produzir códigos mais rápido e com mais frequência. Acontece que a segurança continua sendo o "algo" que é descartado quando a velocidade está em jogo, seja no caminho dos dados ou da entrega.
É bem estabelecido que as pessoas trabalham para atingir aquilo pelo qual são avaliadas. E como os desenvolvedores são pessoas, isso significa que eles também estão sujeitos a essa regra. Se eles forem avaliados quanto à rapidez de chegada ao mercado, eles trabalharão para isso, mesmo que isso signifique pular etapas que comprometam a segurança. Se quisermos entregar aplicativos seguros ao mercado, precisamos adotar uma mudança cultural que meça e valorize a chegada segura ao mercado tanto quanto a chegada rápida ao mercado .
Até que isso aconteça, estamos tão seguros confiando em lasers vermelhos e azuis para lidar com vulnerabilidades quanto em desenvolvedores.