A Shiftleft é uma empresa de Consultoria Estratégica e Operacional de Engenharia de Software Seguro. De que forma é que prestam serviços especializados em engenharia de software?

O software é um ativo extremamente importante para grande parte, senão todas, as organizações. Muito pouco ou nada se faz hoje sem necessidade de software. É “pervasive”, está em todo o lado, por todo o lado, infiltra-se no negócio, condiciona-o.

A “transformação digital” não se faz. Ela existe. É o normal. É algo contínuo e permanente. O software que, indubitavelmente, suporta essa continuidade de transformação tem que ser plástico para acompanhar, reajustar, evoluir de forma una com organização.

O expectável é que o software condicione o negócio de forma positiva, ademais é para tal que é adquirido, é para tal que é desenvolvido. É preciso estar ciente que o tempo de vida do software é muito grande quando comparado com outros investimentos. Um projeto pequeno, de alguns dias ou semanas, pode persistir na organização durante a próxima década. Se não for um bom software, a empresa pode estar a comprar uma âncora, não as asas que pretendia. Infelizmente, por vezes, o software que devia ser o impulsionador da transformação, é o que impede a evolução natural da organização.

Há ativos que são fáceis de adquirir, e mesmo substituir. Se queremos um carro, definimos os critérios necessários, como potência e consumo, por exemplo. Mas, intrinsecamente, sabemos avaliar a qualidade subjacente do produto, definimos expetativas sobre a sua utilização futura, e normalmente conseguimos assegurar esses objetivos durante o período de exploração do ativo.

Software…not so much!

Avaliamos o software pela funcionalidade – Faz o que é pretendido e com a rapidez necessária – mas não temos a mesma desenvoltura em avaliar a qualidade do software pelas suas caraterísticas intrínsecas – Segurança, eficiência, facilidade de manutenção, portabilidade, fiabilidade.

Ficamos satisfeitos pelo facto do software responder funcionalmente, mas não chega. Ao fim de algum tempo, o esforço associado à manutenção, aumenta exponencialmente, e quando é identificada a necessidade de uma nova funcionalidade, por vezes, o tempo de implementação tão elevado que quando está disponível já se perdeu a oportunidade.

Lá se foi a “transformação digital”… Isso acontece por falta de qualidade na implementação da solução inicial.

Depois, há uma série normas e regulamentos que assumem o mínimo rigor sobre a qualidade do software. No setor financeiro, quem trabalhe com cartões, tem que demonstrar a sua adequação à norma PCI-DSS com o risco de não poder trabalhar com cartões. O requisito seis da norma é um conjunto de regras e boas práticas básicas sobre Security By Design no desenvolvimento de software. O RGPD, obriga a Privacy by Default e by Design. Quem trata de informação no setor da saúde conhece de certo a norma HIPPA. Seja pelo estado, nas diferentes formas, seja por organização autónoma de um dado setor, a necessidade de impor rigor e qualidade ao software existe.

Na Shiftleft, é isso que fazemos. Olhamos para as caraterísticas de qualidade do software, a adequação às best pratices da linguagem de programação utilizada, adequação das Framework, aos erros de implementação que possam abrir erros de segurança e que tornam o software vulnerável, ou que possam impedir a evolução futura do software. Ajudamos a proteger o investimento no software. A proteger o investimento num dos principais ativos da transformação digital e a adequar a organização às normas e regulamentos existentes.

A nossa primeira opção é implementar técnicas e ferramentas que permitam a auditoria e avaliação de forma continua (parte do que é o DevSecOps) ao longo do ciclo de vida do software. Queremos principalmente ajudar as organizações a assegurar a qualidade e segurança do ativo software. Dessa forma aconselhamos e auxiliamos na implementação de mecanismos automáticos para a auditoria contínua, que reduzem, e tendencialmente eliminam, os custos de re-work por falta de qualidade, e assim aumentam a rentabilidade do ativo software.

Como é que estes melhoram o sucesso de projetos e permitem reduzir os custos de desenvolvimento e manutenção?

Ao analisar o software, e a forma como é construído, descobrimos erros. Nem sempre erros com impacto nas funcionalidades do software, mas situações que só são observadas mais tarde, ou quando são observadas, já é tarde de mais. Por exemplo, não libertar recursos do servidor, evidencia-se ao fim de algum tempo com a lentidão da operação, pelo menos (mas pode ser origem de um Denial of Service numa forma mais grave). A solução habitual, normalmente, passa por comprar um servidor maior, mais rápido. Isso seria evitável com a correção de um ou duas linhas de código, e virtualmente sem custo, se identificado na fase de desenvolvimento.

Mas há mais exemplos. O utilizador queixa-se que algo não funciona. Simplesmente não funciona. Mas não há erro, os logs não indicam nada. Apenas porque o programador decidiu não reportar um erro de execução. Pode ser detetado automaticamente. O utilizador deixa de se queixar, porque deixa de usar. O ativo morre. O investimento perdeu-se.

Há inúmeros erros de programação e configuração, muitos reportados e bem conhecidos, que podem ser detetados durante o desenvolvimento. Mas não são detetados pelos testes funcionais ou de aceitação feitos pelos utilizadores.

É a responsabilidade de quem faz a gestão do desenvolvimento e aquisição de software assegurar que esses erros são minimizados, e havendo ferramentas automáticas para tal, parece-nos ser uma falha grave não o fazer.

Outro aspeto prende-se com a composição do software. Hoje em dia é muito pouco o software que não usa bibliotecas ou componentes de terceiros. Sejam o vulgo Open Source ou outras. É óbvio que se torna essencial saber que componentes e que versões são utilizados no software de uma organização e mais ainda saber se esses componentes têm algum impacto na segurança da informação, na performance da aplicação, se tem ou não licenciamento. É obrigatório saber que software estamos a usar, e se não auditarmos, não sabemos.

Parece-nos ser muito pouco responsável deixar que exista software numa organização que dependa de software vulnerável, no geral, e em particular no âmbito do RGDP seria muito irresponsável sujeitar uma organização a uma coima volumosa porque um software utiliza uma biblioteca conhecida por violar os direitos de privacidade, ou não fazer caso dos requisitos de consentimento. Ou, imagine-se o que é ter uma equipa a desenvolver uma solução durante meses, entra em produção, a organização fica parcialmente dependente dessa solução. Ao fim de algum tempo a organização é confrontada com a necessidade de pagar licenciamento por uma biblioteca que está a utilizar. É aceitável? Não.

Estes tipos de situações podem ser descobertos e corrigidos atempadamente, e se detetado na altura certa o custo para a organização será reduzido, tendencialmente nulo. Se não tomarmos a atenção devida, o custo será enorme. Seja por ser extremamente caro fazer a manutenção de funcionalidades, ou porque é permissivo em relação à segurança, ou porque alguns dos módulos/Bibliotecas open source utilizados obrigam a licenciamento para fins comerciais que teremos que honrar.

Trata-se antes do mais, saber o que estamos a comprar. Conhecer as limitações do software, os erros que inclui, e claro, tentar comprar o menor número possível de erros. Se não soubermos o que estamos a comprar, não conseguimos gerir o risco associado.

Como é que a Shiftleft alia a experiência em desenvolvimento e manutenção de software com a prática de Consultoria de Gestão?

De forma direta, recolhemos automaticamente indicadores de qualidade e segurança. Podemos identificar a produtividade, evolução de qualidade e de risco por equipa, projeto, área de negócio, linguagem, entre outros. Sabemos objetivamente quanto “risco” foi introduzido ou quantos erros eliminados numa dada entrega ou versão. Isso é uma ferramenta essencial de gestão do desenvolvimento. Podemos com isto impor e medir, objetivamente níveis de serviço assentes nas características do software, e.g., Segurança, facilidade de manutenção, fiabilidade, entre outros, e que não é sujeito a interpretação – está no código fonte, é inabalável.

Ao implementar uma Framework de Security by Design, onde são elencados requisitos que têm que ser cumpridos, em função da criticidade do software, a organização, fica dotada de indicadores objetivos que permitem atuar e melhorar continuamente o processo de aquisição e desenvolvimento de software e demonstrar a adequabilidade às normas em vigor.

Além disso, conhecendo o Risco de Manutenção, Risco de Operação e Risco de Segurança, obtidos por análise ao código fonte, tendo o inventário de componentes associados às aplicações e a sabendo medir a maturidade dos processos de desenvolvimento das equipas, a decisão sobre o melhor investimento numa estratégia de transformação fica suportada em dados técnicos mensuráveis. Em suma torna-se mais fácil decidir que aplicações merecem ser desenvolvidas, quais devem ser descontinuadas ou substituídas.

Por exemplo: A análise ao código e à composição de uma aplicação de suporte a uma área de negócio, resulta numa classificação Risco de Manutenção Elevado, ou seja, a manutenção é difícil, onerosa e pode fazer com que a aplicação fique instável. Os componentes utilizados, frameworks, tem um grau de obsolescência elevado.

Face á necessidade de transformação da área de negócio, poderá ser mais vantajoso considerar a substituição da aplicação para suportar as novas ofertas da área de negócio do que assumir o risco de fazer depender essa transformação de uma aplicação cuja adaptação será muito cara e com risco de instabilidade. Em opção, será hipoteticamente possível escolher outra aplicação existente em portfolio, cujo Risco de Manutenção seja reduzido, e que possa acomodar as novas funcionalidades de suporte. A tomada de decisão é suportada por factos objetivos relativos a custo e risco, podendo ser incluído ranking da produtividade de fornecedores por tecnologia, área de negócio, entre outros. para escolher o melhor fornecedor.

Para além de deixar de haver aplicações sem “atualização” e que torna a organização vulnerável, o risco de se incorrer em legacy, ou seja de fazer a organização depender de aplicações descontinuadas ou sem atualização, que impeçam a evolução e transformação continua, é imensamente reduzido porque se conhece as dependências das aplicações e se assegura a boa saúde técnica.