Para cada empresa em todos os setores, é provável que a concorrência venha de uma startup desconhecida, já que é de rivais de longa data. Na economia moderna, se você não está inovando rápido o suficiente, você será atropelado por alguém que é. Basta perguntar às empresas de transmissão e televisão a cabo sobre o Netflix. Pergunte ao Hilton e Marriott sobre o Airbnb. O medo da morte pode ser um poderoso motivador.

Alguns dos maiores desafios para os encarregados são equipes de liderança apoiadas em seus louros, normas culturais profundamente enraizadas e silos de longa data erguidos por equipes de desenvolvimento de software, segurança de aplicativos e operações de TI. As normas culturais entrincheiradas e silos fricção de combustível diminuem velocidade, e diminuem inovação.

Essa dura realidade e o medo da morte é o motivo pelo qual muitas organizações não veem mais o desenvolvimento de software como um custo de fazer negócios, mas sim como uma competência essencial e um imperativo estratégico que define toda a empresa. Todas as empresas são agora empresas de software. É também por isso que as organizações em todo o mundo estão adotando cada vez mais um conceito chamado DevOps - onde as barreiras entre as operações de TI e os desenvolvedores são derrubadas, práticas desperdiçadas são arrancadas e colaboração em escala é recompensada. Quanto mais rápido as empresas trazem valor ao mercado, mais o mercado as recompensa.

A magia do código aberto

Insira práticas de desenvolvimento de código aberto - a droga milagrosa de escolha que impulsiona o DevOps e a moderna inovação em software.

Componentes de código aberto, ou partes de software desenvolvidos pela comunidade e reutilizáveis, permitem que as empresas economizem tempo e dinheiro, melhorem a qualidade, proporcionem agilidade aos negócios e mitigam (alguns) riscos de negócios. O conceito não é novo. Muito antes do advento do código aberto, Isaac Newton disse de maneira célebre: "Eu vejo ainda mais em pé sobre os ombros de gigantes e descubro a verdade construindo sobre descobertas anteriores". Essa ideia é a principal razão pela qual os componentes de código aberto são tão atraentes para as equipes de desenvolvimento. O mesmo vale para o uso crescente de aplicativos em contêiner. Simplesmente declarado, o acesso livre e aberto a componentes de software e containers pré-existentes elimina a reinvenção de rodas e expõe software a uma comunidade global de “co-desenvolvedores,” para projetar e expandir.

Com tantos benefícios - não é de admirar que 80% a 90% de um aplicativo moderno seja composto de componentes de código aberto. E também por que 80 a 90% da infra-estrutura moderna está sendo conteinerizada.

Você pode estar se perguntando - qual é o problema? Bem - enquanto essas partes desempenham um papel vital em impulsionar a inovação e alimentar o mundo como o conhecemos, nem todas as partes são criadas iguais. Nossa análise de componentes de código aberto baixados do Repositório Central (o maior e mais ativo banco de dados de componentes de código aberto Java) descobriu que, em 2017, 1 em cada 8 componentes baixados por desenvolvedores do Reino Unido continham um conhecido vulnerabilidade de segurança.

Essas verdades não são desconhecidas no mercado. O Heartbleed era uma vulnerabilidade de código aberto notória. O Equifax foi violado por meio de um componente vulnerável de código aberto. E de acordo com a Pesquisa da Comunidade DevSecOps de 2018, com mais de 2.000 profissionais de TI, 3 em cada 10 suspeitaram ou confirmaram uma violação relacionada ao código aberto em 2017.

De acordo com a mesma pesquisa, apenas 6 em 10 organizações têm políticas que exigem a avaliação de componentes de código aberto em algum estágio do ciclo de vida de desenvolvimento. Mas com grande parte dessa exigência baseando-se em tediosas revisões manuais fora dos canais de desenvolvimento, a realidade é que as políticas são frequentemente ignoradas (46% do tempo) e os defeitos continuam a se encaminhar para aplicações concluídas. Open source e DevOps dão às empresas o poder de se manterem vivas e, em muitos casos, superarem seu concorrente, mas essa inovação não deve, e não tem que ser, em detrimento de seus clientes..

O papel da regulação

A Estratégia Nacional de Segurança Cibernética do Reino Unido 2016-2021 declarou que “Empresas e organizações decidem onde e como investir em segurança cibernética com base em uma avaliação de custo-benefício, mas elas são responsáveis ​​pela segurança de seus dados e sistemas.” Essa noção de responsabilidade está sendo cada vez mais aplicada não apenas no Reino Unido, mas em todo o mundo, à medida que os governos criam regulamentações.

Por exemplo, tanto os legisladores franceses quanto o governo do Reino Unido anunciaram recentemente diretrizes mais rígidas para fabricantes de dispositivos. O Reino Unido exigiu especificamente que a segurança seja incorporada aos dispositivos inteligentes desde o início e que o software seja atualizado automaticamente.

A UE aprovou um dos regulamentos mais amplamente discutidos com o próximo Regulamento Geral de Proteção de Dados (GDPR). O artigo 32 do GDPR determina que as empresas devem “implementar medidas técnicas e organizacionais apropriadas” para “garantir a confidencialidade, integridade, disponibilidade e resiliência contínuas dos sistemas e serviços de processamento.” Quando combinado com o Artigo 25, que determina que as medidas de proteção de dados sejam implementadas “por design e por padrão”, É claro que a privacidade e a segurança devem se tornar enraizadas em todos os elementos da infraestrutura de TI. Se você não seguir essas regras e as vulnerabilidades conhecidas acabarem inadvertidamente ajudando os hackers a roubar dados confidenciais do consumidor, você poderá ser multado em até € 20 milhões, ou 4% do faturamento anual global - o maior dos dois.

Ecoando as políticas européias, quatro Senadores dos EUA introduziram uma peça legislativa bipartidária chamada Lei de Melhoria da Segurança Cibernética da Internet das Coisas. De acordo com uma ficha informativa divulgada ao lado da legislação, “Enquanto os dispositivos de 'Internet of Things' (IoT) e os dados que transmitem apresentam enormes benefícios para os consumidores, a relativa insegurança de muitos dispositivos apresenta enormes desafios.” A legislação exige especificamente que os fornecedores vendam dispositivos IoT “para fornecer uma certificação por escrito de que o dispositivo não contém, no momento de enviar a proposta, qualquer componente de hardware, software ou firmware com quaisquer vulnerabilidades ou defeitos de segurança conhecidos.”

Com grandes poderes vem grandes responsabilidades

Essa linha de regulamentação voltada para a proteção do consumidor não é nova. Cinco anos atrás, nenhuma montadora poderia enviar airbags Takata defeituosos conhecidos em um veículo. Reguladores introduziram diretrizes de alimentação de gado para limitar a disseminação da doença da vaca louca há mais de 20 anos.

Passar o ônus para os fabricantes de dispositivos e organizações que desenvolvem software para garantir que ele seja seguro desde o início e ao longo do tempo reflete regulamentações semelhantes que orientam a segurança do consumidor em outros setores. É especialmente importante quando o software agora controla nossa saúde (por exemplo, marca-passos conectados à Internet), nosso transporte (por exemplo, veículos autônomos) e nossas finanças (por exemplo, aplicativos de banco on-line)..

Atualmente, ataques e violações de aplicativos geralmente são o resultado de vulnerabilidades facilmente exploradas - e facilmente corrigidas. Embora gostemos de pensar que as empresas auto-regulariam sua higiene de segurança cibernética em nosso mundo orientado por software, manchetes de violação diárias indicam que as regulamentações governamentais podem ser um motivador necessário para a ação.

Se nenhuma outra indústria de manufatura tiver permissão para enviar peças vulneráveis ​​ou defeituosas conhecidas em seus produtos, por que os fabricantes de software deveriam ser diferentes? Em qualquer outra indústria, seria considerado negligência grosseira.

Nunca passe defeitos conhecidos a jusante

Felizmente, muitos dos desafios relacionados ao uso de componentes de software vulneráveis ​​conhecidos são facilmente resolvidos. Grandes e pequenas empresas estão colocando os princípios e práticas do DevSecOps para funcionar. Um dos princípios mais importantes se origina do líder da DevSecOps, Gene Kim, e seu romance, o Phoenix Project, que dirige, “Enfatize o desempenho de todo o sistema e nunca passe um defeito a jusante”.

Para as empresas que decidem seguir isso, a automação é imperativa. O grande volume de artefatos consumidos pelas organizações hoje superaria qualquer tentativa de revisá-los manualmente para determinar sua saúde. As máquinas podem realizar verificações em milissegundos, onde os humanos podem levar horas para chegar a conclusões semelhantes. Essa realidade é semelhante à necessidade de análise robótica de peças sendo montadas em uma linha de fabricação de eletrônicos de alta velocidade - os exames humanos nunca poderiam acompanhar o ritmo e são propensos a erros..

A questão não é, podemos desenvolver um software seguro? Certamente nós podemos. A economia de aplicativos pode crescer e prosperar em ambientes seguros e regulamentados, se gerenciada adequadamente. Por outro lado, se as empresas decidirem ignorar a higiene apropriada da cibersegurança, pensando que estão optando pela inovação, pode ser mais do que apenas a sua morte, elas serão responsáveis ​​pela inovação..

Derek Weeks, vice-presidente da Sonatipo

  • Também destacamos as melhores suítes de segurança de internet