0 
0 O código aberto transformou o mundo do software, reduzindo tremendamente o custo de introduzir novas tecnologias, permitindo um amplo reaproveitamento entre produtos e indústrias. No entanto, as organizações que retiram seu código de código aberto muitas vezes se encontram em cenários onde criaram um artefato final frankensteined, com origens extremamente fragmentadas.
Isso pode causar problemas quando as organizações não consideram o suporte a longo prazo das bibliotecas de código aberto em que confiam e, na pior das hipóteses, podem criar problemas de segurança dentro de seus aplicativos. A série de vulnerabilidades log4j no final de 2021 é um exemplo perfeito disso. As organizações devem ter tempo para considerar cuidadosamente sua abordagem para a segurança da cadeia de suprimentos para se preparar para possíveis incidentes futuros de segurança e para obter todos os benefícios do código aberto.
O código aberto não é exatamente gratuito
O código derivado de múltiplas fontes traz desafios exclusivos de segurança que as organizações nem sempre estão equipadas para lidar – ou mesmo conscientes. A cadeia de suprimentos pode ser incrivelmente complexa, composta por uma enorme árvore de dependências de código aberto, todas sendo atualizadas regularmente. As equipes de TI normalmente não auditam todas as linhas de código em seu sistema quando o software de código aberto upstream é atualizado ou alterado. Com uma teia de dependências, mudanças constantes e falta de avaliações profundas das equipes de TI, as ameaças à segurança externa devem ser uma preocupação, apesar das origens de fora da organização.
Independentemente de quem é inicialmente responsável pelos bugs, as organizações enfrentam responsabilidade ao enviar software que inclui código-fonte aberto cheio de vulnerabilidades. Sem processos para vetar a inclusão e as atualizações de código aberto, as organizações continuarão a cair na armadilha de utilizar componentes de código aberto sem entender os riscos que estão assumindo. Além disso, à medida que o mundo dos softwares continua a evoluir, novas tecnologias como a containerização colocarão uma postura segura ainda mais fora de alcance.
Após a publicação de uma vulnerabilidade em um projeto de código aberto, as organizações podem ser esmagadas com o ônus de auditar atualizações para todas as atualizações de software relevantes dentro de prazos potencialmente apertados. Isso pode devastar a produtividade dos desenvolvedores, já que os especialistas no assunto devem optar por auditar milhares de linhas de código, aceitar cegamente a versão mais recente de suas dependências, ou ambos, arriscando a introdução de bugs no processo.
Apesar dos fatores de risco, existem maneiras de as organizações protegerem e protegerem efetivamente seu uso do código-fonte aberto. Com maior compreensão das dependências e verificações e equilíbrios adequados para mitigar riscos, as equipes podem começar a se sentir seguras em sua utilização de código aberto e abraçar totalmente seus benefícios.
Fabricantes de diferenças para manter o código aberto seguro
Os líderes de TI devem, antes de tudo, estabelecer políticas que se concentrem na mitigação de ameaças e riscos antes do início dos projetos. As políticas que garantem a revisão e aprovação de novas dependências de código aberto, bem como as atualizações regulares dessas dependências são imperdíveis para reduzir o risco de cenários futuros de desastres. Isso deve ser feito com o buy-in do desenvolvimento, é claro – os desenvolvedores querem usar a mais recente e maior tecnologia, e se eles não podem usar a melhor ferramenta para o trabalho eles não serão desenvolvedores felizes – mas uma política de linha de base mínima pode ajudar a enquadrar o problema. O inventário e a manutenção regular são fundamentais aqui porque você não pode corrigir o que você não está ciente, e é muito mais fácil atualizar uma dependência do lançamento da semana passada do que é atualizar de um lançamento da última década.
Uma vez que essas diretrizes estejam em vigor, o desenvolvimento deve assumir a liderança na implementação de procedimentos para atender aos requisitos da política. É aí que entra o DevSecOps: trazer uma mentalidade de desenvolvimento de software para resolver problemas de segurança pode reduzir custos e ajudar a quebrar barreiras dentro das organizações.
Em primeiro lugar, as equipes precisam entender que software é implantado em seus ambientes, assumindo que eles não estão documentando um projeto de lei de materiais desde o início. Isso pode ser difícil porque há muitas camadas de dependências em uma pilha de software moderna. Por exemplo, a maioria dos scanners de vulnerabilidade de contêiner estão limitados a pacotes instalados através do gerenciador de pacotes do sistema operacional (por exemplo, apt ou yum). Pelo design, isso perde muitas dependências, como binários estáticamente ligados, pacotes instalados manualmente, dependências de linguagem de programação e muito mais.
Em segundo lugar, as equipes precisam implementar processos para manter as dependências atualizadas. Embora isso possa ser uma pressão sobre o tempo e os recursos do desenvolvedor, esse custo contínuo é certamente muito menor do que o que seria exigido das equipes durante uma violação inesperada – e mais seguro financeiramente, também.
Alternativamente, as organizações que não possuem os recursos do desenvolvedor para aumentar as dependências de estoque e monitorar continuamente as vulnerabilidades devem reduzir sua pegada de segurança usando produtos PaaS (Platform-as-a-service) de provedores de serviços em nuvem. Por exemplo, comprar um produto DBaaS (Banco de Dados como serviço de serviço) em vez de auto-hospedar um cluster PostgreSQL em um conjunto de máquinas virtuais pode eliminar a responsabilidade de uma organização por uma pilha muito grande de dependências. Isso pode permitir que as equipes mudem o foco para longe do mundano “levantamento pesado indiferenciado” e em direção à inovação e ao valor dos negócios.
Puxando o bom para fora da caixa e selando o ruim
As organizações podem – e devem – aproveitar as ricas recompensas da comunidade de código aberto para excelentes códigos e soluções inovadoras. Mas isso deve vir com consideração e planejamento para os potenciais riscos à segurança em mãos. As equipes de liderança de TI podem mitigar significativamente o risco da cadeia de suprimentos quando tomam as medidas apropriadas para avaliar e orientar a inclusão de dependências de código aberto. Preparar-se com antecedência pode dar tranquilidade hoje, manter os riscos à distância e incentivar a inovação dos desenvolvedores.
FONTE: HELPNET SECURITY