Home > Gestão

10 coisas que os CIOs precisam saber sobre seu software

Com o tipo certo de inteligência de software, os CIOs podem manter o baixo risco enquanto modernizam os sistemas para o sucesso futuro

Frederic Veron, da CIO (EUA)*

11/04/2019 às 11h35

Foto: Shutterstock

O software está se tornando cada vez mais complexo e, como resultado, fica cada vez mais difícil ter uma compreensão real e em tempo real do que realmente está nos portfólios de software. Desde recursos não documentados a vulnerabilidades de segurança desconhecidas para bibliotecas de código usadas, os CIOs e suas equipes estão tomando grandes decisões no escuro todos os dias. E, sem intenção, é claro, essa falta de tomada de decisão informada coloca a organização em grande risco.

À medida que a complexidade do software e a grande quantidade de códigos continuam aumentando, esse risco só irá crescer. Para colocar as coisas em perspectiva, o carro médio de hoje (excluindo carros autônomos) tem mais de 150 milhões de linhas de código, o que é mais do que um caça F-35 ou um Boeing 787.

Uma reportagem recente da The Atlantic aponta exatamente porque os CIOs precisam pensar sobre o software de maneira diferente: “As peças do carro já foram puramente mecânicas. Eles agora, muitas vezes, vêm com milhões de linhas de código. E, embora parte deste código – para piloto automático adaptável, para frenagem automática e assistência em faixa – realmente tenha tornado os carros mais seguros, também criou um nível de complexidade totalmente novo. E isso tornou possível um novo tipo de falha."

Como CIOs, precisamos contornar essa complexidade. Não só para melhorar a segurança da aplicação e a eficiência de custos, mas para garantir a capacidade de suporte básico e a estabilidade dos sistemas que poderiam colocar nossas vidas em risco, como em sistemas médicos ou de carros, sejam eles autônomos ou não.

A boa notícia é que agora temos ferramentas aprimoradas que nos dão uma visão muito mais profunda do que está dentro do software para identificar pontos fortes, pontos fracos e oportunidades de melhoria. Essa nova inteligência de software está equipando os CIOs para serem mais proativos no gerenciamento da complexidade do software e na proteção das operações comerciais.

Em sua busca pela inteligência de software, aqui estão as 10 principais características que acredito que os CIOs devem absolutamente saber sobre o seu software:

Inventário de código fonte
Uma coisa de cada vez! Obtenha um inventário completo de todo o código-fonte com o controle de versão apropriado em repositórios protegidos e com backup. Muitas vezes, não fizemos nosso dever de casa nessa área. Entender a base de código e avaliar a qualidade do software é essencial para simplificar a complexidade e estabelecer uma linha de base para os esforços de modernização, manutenção e transformação.

A manutenção de um repositório de software atual não apenas ajuda as equipes a gerenciar binários, simplificar a funcionalidade de plataforma cruzada, criar ferramentas e fornecer formatos de empacotamento – também permite que o CIO execute análises em tempo real sobre a integridade e o desempenho de software para gerar relatórios mais eficazes e taxas de resposta a incidentes mais rápidas.

Começando com uma linha de base do que você tem dentro de seu portfólio, você será capaz de obter as informações mais relevantes sobre o que seus aplicativos estão fazendo, quaisquer redundâncias e como eles se encaixam.

Conformidade de arquitetura
A conformidade arquitetônica é uma medida muito reveladora sobre a capacidade de uma organização de reforçar a segurança, reduzir riscos e manter a alta eficiência.

A arquitetura do aplicativo Blueprinting acelera o aprendizado para novos desenvolvedores e ajuda os arquitetos a entenderem a estrutura dos aplicativos para que eles possam trabalhar mais rapidamente e fazer alterações com menos retrabalho. Também acelera a modernização, porque as interdependências dos componentes já estão estabelecidas e as áreas de alto potencial de risco podem ser sinalizadas antes do início do trabalho.

Em minha própria experiência, avaliar a conformidade de arquitetura tem sido incrivelmente útil para entender a complexidade, a dívida técnica e onde mais esforços devem ser focados. Ele também ajuda a informar uma Pontuação de Risco de TI, que alinha a conformidade arquitetônica com a segurança e a integridade geral dos sistemas.

Os principais aspectos da arquitetura, que eu pessoalmente gosto, de verificar a estabilidade e o desempenho do sistema incluem tratamento de exceções, desempenho de acesso a dados e gerenciamento de dados, validação de entrada, conformidade de design de arquitetura segura (especialmente evitando o uso de credenciais codificadas) e conformidade com o design da arquitetura inicial.

Privacidade de dados
Os CIOs também devem ser capazes de procurar e identificar características específicas de software em tempo hábil para responder a requisitos precisos, como a certificação contra a conformidade com o GDPR, por exemplo. Após uma violação ou incidente de dados, os CIOs costumam ser solicitados a relatar a segurança e a confiabilidade do sistema.

O aumento de regulamentações e regras mais rígidas em relação à privacidade de dados também está forçando o CIO a informar sobre problemas como a proteção de números de seguridade social dos clientes ou até mesmo endereços IP codificados. Tais solicitações geram uma quantidade significativa de descoberta, pesquisa e esforço.

Ter acesso a métodos e ferramentas que o ajudem a responder a essas perguntas de maneira rápida e abrangente com certeza fará uma grande diferença na percepção do CIO e no sucesso a longo prazo.

Código aberto e risco de licença IP
Embora tenha sido previsto que a ascensão do software de código aberto (OSS) poderia ajudar a melhorar a segurança do software e a qualidade em geral, isso não se tornou a nossa realidade (pelo menos não em 2019). O uso de componentes do OSS se espalhou como um incêndio e com boas razões. Ele ajuda as equipes a obter projetos de forma mais rápida, economizar dinheiro e alavancar uma tecnologia que foi validada por outras pessoas.

Por exemplo, “a explosão de dados e a necessidade de usá-los efetivamente tem sido um fator importante que impulsionou a crescente adoção de código aberto em todo o setor público”, diz Shaun Bierweiler, da Hortonworks.
Mas o OSS também pode expor uma organização a riscos desnecessários e imprevisíveis. Dados recentes mostram que as violações de código aberto aumentaram em 70%. Muitos componentes [de código aberto] podem ser de baixa qualidade, com múltiplas falhas para os hackers explorarem, e uma vez que um hacker tenha encontrado um caminho para o OSS, eles são capazes de hackear todos os sistemas de TI que usam esse componente.

Para evitar isso, os CIOs devem conhecer os componentes e artefatos de seus softwares, as obrigações de licenciamento que eles carregam consigo e se ainda são suportados. O código-fonte aberto e o risco de licença devem ser tratados de forma mais proativa do que o que historicamente conseguimos fazer, ou corremos o risco de se tornar o próximo Equifax.

Dívida técnica
A dívida técnica pode ser um impedimento significativo à manutenção do sistema. Ano após ano, lançamento após lançamento, novo recurso após novo recurso, é fácil que a dívida técnica aumente da noite para o dia se você não for cuidadoso.

Frequentemente calculados como 100% violações de alta gravidade + 50% violações de gravidade média x necessidade de corrigir violações x O custo do desenvolvimento, expressar as prioridades das dívidas técnicas para a gerência sênior muitas vezes pode ajudar os CIOs a garantirem mais orçamento para atividades de manutenção e modernização. Na verdade, eu diria que usar a dívida técnica para ajudar a alocar o orçamento para as atividades de manutenção é uma etapa essencial para garantir que as atividades estejam focadas nas coisas certas para melhorar a qualidade geral do software.

Como Myles F. Suer escreveu em sua coluna Adaptive CIO, “reduzir a dívida técnica necessita do aumento de foco. Não é desperdiçar dinheiro. Trata-se de substituir sistemas frágeis e monolíticos por sistemas personalizáveis, mais fluídos e seguros. Os CIOs enfatizam que há ROI (retorno sobre investimento) em menos mão de obra de manutenção, menos incursões e mudanças mais fáceis”.

Racionalização do portfólio de aplicativos
As ferramentas existentes hoje para analisar os padrões de transação e compará-los com vários conjuntos de códigos fornecem aos CIOs os dados necessários para racionalizar os portfólios de aplicativos com mais eficiência. Aposentar aplicativos é sempre um desafio, e essas ferramentas agora nos fornecem os dados necessários para avaliar e priorizar nossos esforços, garantindo que possamos realmente aposentar um aplicativo inteiro e mover com segurança as transações comerciais associadas a um conjunto de sistemas mais apropriado.

O preço? A redução dos custos, obviamente, mas mais importante, a redução dos riscos gerais a partir de uma perspectiva operacional, com menos incidentes e menos área de superfície a ser atacada. Hoje, a maior parte da análise usada para tomar decisões de racionalização é baseada em características que achamos que são usadas, deixando lacunas no processo de tomada de decisão. Com ferramentas modernas, podemos ver padrões reais de transação para identificar o código com maior utilização, o código que precisa ser modernizado e até o código desperdiçado, que pode ser retirado para aplicações mais eficientes e seguras.

Análise no nível de sistemas
A maioria dos CIOs continua sem visibilidade da arquitetura geral e das interdependências do sistema e de como os problemas de qualidade de software afetam o sistema como um todo, além de apenas aplicativos e componentes individuais. As ferramentas tradicionais de varredura de código não fornecem uma visualização no nível do sistema e, portanto, geram montes de falsos positivos e descobertas que nem sempre são úteis no nível do CIO.

A compreensão da integridade do software em todo o sistema fornece aos CIOs uma imagem muito mais precisa da qualidade do software e falhas que afetam a segurança e o desempenho. A análise em nível de sistema permite que o CIO defina expectativas baseadas em conjunto de fatos para contrapartidas de negócios, e a qual forneça uma orientação mais prática aos desenvolvedores sobre onde concentrar seus esforços e como planejar testes integrados em fluxos de dados com sistemas upstream e downstream.

Quantas vezes os CIOs não testam o impacto de um aplicativo upstream pensando que ele não será afetado? A análise em nível de sistema elimina as dúvidas e ajuda as equipes a evitarem situações embaraçosas.
Muitas soluções de nível de sistema presentes no mercado também tem adicionado aspectos de visualização para identificar rapidamente as dependências imprevisíveis, as lacunas de conformidade e as vulnerabilidades de arquitetura, com uma direção clara para uma rápida correção.

Nuvem pronta para aplicativos
Espera-se que os gastos em nuvem pública alcancem US$ 200 bilhões este ano. Portanto, não é surpresa que a migração para nuvem esteja se tornando uma prioridade maior para os CIOs. Mas saber que a nuvem é uma prioridade e entender quais aplicativos devem ser migrados para a nuvem são dois assuntos completamente diferentes.

Isso requer a racionalização do portfólio de aplicativos – determinando a estrutura interna dos aplicativos – para modelar e prever como cada aplicativo desempenhará e funcionará em um ambiente de nuvem antes de ser replantado novamente. O esforço de racionalização deve considerar aspectos como impacto nos negócios, segurança, qualidade e dívida técnica como prioridade.

Para refinar ainda mais essas medidas, percorrer os 5Rs de racionalização da nuvem e identificar os resultados principais para cada um deles, é um passo essencial para o sucesso na nuvem. São eles:

1. Rehost - tipicamente escolhido para reduzir custos e garantir ganhos rápidos.
2. Refactor - normalmente escolhido para promover ciclos de entrega mais rápidos e com maior eficiência.
3. Rearchitect - normalmente escolhido quando os aplicativos existentes não são compatíveis com as plataformas de nuvem.
4. Rebuild - normalmente escolhido quando os aplicativos existentes não suportam a demanda de negócios e é necessária uma inovação mais rápida.
5. Replace - normalmente escolhido quando os aplicativos estão desatualizados ou estão programados para serem retirados.

Prevalência e criticidade de vulnerabilidades de segurança de aplicativos
Pesquisas recentes mostram que a segurança é a prioridade Número Um dos CIOs em 2019. Os problemas de segurança mantêm os CEOs acordados à noite, e a responsabilidade de proteger os sistemas de missão crítica, muitas vezes recai sobre o CIO, mesmo que um CISO esteja presente dentro da organização.

Para proteger os negócios, os CIOs devem direcionar esforços para reduzir as vulnerabilidades e a área de superfície potencial de ataque. Isso significa reduzir a dívida técnica, racionalizar os portfólios de aplicativos e priorizar as violações de segurança com ferramentas que ofereçam SAST, DAST, IAST e, mais frequentemente, Análise de Composição de Software (SCA). Em um blog, no ano passado, a analista da Forrester, Amy DeMartine, relatou que os recursos apressados geralmente resultam em segurança desleixada.

Um grande desafio para concentrar o esforço de segurança é classificar o grande número de violações que essas ferramentas geralmente sinalizam. É difícil priorizar os esforços de uma equipe na correção de problemas críticos quando eles são bombardeados por centenas de novas notificações todos os dias. Para evitar isso, os CIOs devem procurar ferramentas que ofereçam análise em nível de sistema – o que significa uma visão arquitetural abrangente das violações baseadas em interdependências de componentes. Caso sejam explorados, esses são os problemas que causam maior impacto na empresa e na segurança de dados.

Uma visão baseada em padrões de integridade do software
Com a complexidade cada vez maior dos sistemas, os CIOs devem monitorar a integridade geral do software e estarem armados com dados em tempo real sobre os possíveis riscos e pontos de acesso. Adotar uma visão de nível de portfólio de integridade de software ajudará os CIOs a entender melhor se a organização está pronta para iniciar um projeto de modernização digital, e se há problemas de qualidade de linha de base ou falhas de segurança em seus aplicativos, etc.

Basear essa análise em nível de portfólio nos padrões do setor, como CISQ, CWE, NIST, OWASP, PCI, STIG e outros, ajudará a promover conversas mais produtivas com equipes de negócios e desenvolvedores, com base em fatos relacionados à capacidade de gerenciamento, desempenho e segurança de software, o que ajudará os esforços de modernização a decolar mais rapidamente.

Em minha própria experiência, o uso de métricas de integridade de software para priorizar investimentos e recursos, também ajudou a reduzir conflitos e alinhar equipes multifuncionais para uma entrega mais rápida e com maior qualidade, produzindo resultados de negócios mais produtivos no curto prazo. Esses fatores são essenciais para o sucesso do CIO.

Para ter sucesso no futuro digital, os CIOs devem fazer com que os recursos e funções intangíveis do software se tornem visíveis a olhos nus e destreinados. Com essas 10 características, os CIOs podem tomar decisões mais produtivas e bem informadas sobre as suas tecnologias, ao mesmo tempo em que colocam as equipes e a liderança sênior no caminho certo.

*Frederic Veron é consultor sênior da New Bridge Consulting Group

Junte-se a nós e receba nossas melhores histórias de tecnologia. Newsletter Newsletter por e-mail