Questão de Segurança da Informação — Ciclo de Vida de Desenvolvimento Seguro — VUNESP 2023

Shadow Code e o Ciclo de Vida de Desenvolvimento Seguro

Gabarito: letra A. A introdução de shadow code (código-fantasma) no código-fonte de aplicações web é causada, tipicamente, pela cópia de códigos disponíveis em fóruns ou repositórios abertos da Internet por parte do desenvolvedor, sem respeitar verificações de segurança e diretrizes da empresa. Esse é um problema de governança e segurança no processo de desenvolvimento, diretamente ligado ao conceito de shadow IT e às boas práticas de desenvolvimento seguro, como as descritas nos controles CIS e na norma ABNT NBR ISO/IEC 27002.

O shadow code é um termo usado para designar código que entra no projeto sem passar pelos processos formais de revisão, controle de versão e aprovação de segurança da organização. Ele é a materialização, no nível do código, do conceito mais amplo de shadow IT — a prática de usar tecnologias, softwares ou serviços sem o conhecimento ou a aprovação do departamento de TI. Quando um desenvolvedor copia um trecho de código de um fórum, de um repositório público (como GitHub) ou de um blog, e o cola diretamente na aplicação, sem avaliar se aquele código é seguro, sem verificar sua licença, sem testá-lo adequadamente e sem seguir as diretrizes de codificação segura da empresa, ele está introduzindo shadow code. Esse código pode conter vulnerabilidades conhecidas, backdoors, funções maliciosas ou simplesmente não seguir os padrões de segurança da organização, criando uma superfície de ataque não gerenciada.

A segurança no desenvolvimento de software é um processo que deve estar presente em todo o ciclo de vida, desde a concepção até a manutenção. As boas práticas incluem: estabelecer um ciclo de vida de desenvolvimento seguro (como o SDL da Microsoft ou o CLASP), usar bibliotecas de padrões de projeto seguros, realizar modelagem de ameaças, treinar os desenvolvedores em práticas de codificação segura e, crucialmente, avaliar as dependências de software e mitigar possíveis riscos à segurança. O controle 16 dos Controles CIS, sobre segurança de aplicações, destaca que os desenvolvedores precisam ser treinados em conceitos de segurança e que deve haver um processo para adquirir ou avaliar software, módulos e bibliotecas de terceiros, garantindo que não apresentem falhas de segurança. A cópia indiscriminada de código da Internet viola exatamente essa diretriz.

A pegadinha desta questão está em não confundir a causa do shadow code com outras ameaças ou características do desenvolvimento. O shadow code não é um malware que infecta o computador, não é uma limitação de ferramenta de edição, não é uma consequência do paradigma de programação e não tem relação com o tamanho da equipe. É um problema de processo e de comportamento do desenvolvedor em relação à origem e à qualidade do código que ele incorpora ao projeto. A banca explora a tendência do candidato de associar qualquer problema de segurança a ataques externos (ransomware) ou a más práticas genéricas, quando a resposta correta aponta para uma falha específica e bem definida no fluxo de desenvolvimento.

Guarde o critério decisivo: shadow code é código de origem não confiável ou não aprovado que entra no projeto. É essa a fronteira que separa a alternativa correta das demais — as outras opções descrevem cenários que podem ser problemáticos, mas não são a causa direta e específica da introdução de shadow code.

Alternativa A — ✅ Correta ⟵ GABARITO

Esta é a definição precisa de shadow code. A cópia de código de fóruns e repositórios abertos, sem passar pelas verificações de segurança e pelas diretrizes da empresa, introduz código não aprovado e potencialmente vulnerável no projeto. O desenvolvedor, ao agir assim, contorna os controles de segurança do ciclo de desenvolvimento, criando uma dívida de segurança que pode ser explorada por atacantes. As boas práticas de desenvolvimento seguro exigem que todo código, especialmente o de terceiros, seja avaliado quanto a vulnerabilidades, licenças e conformidade com os padrões da organização antes de ser integrado.

Alternativa B — ❌ Incorreta

Ataques de ransomware no computador do desenvolvedor são uma ameaça à disponibilidade e integridade do ambiente de desenvolvimento, podendo criptografar ou destruir o código-fonte. No entanto, isso não é a causa da introdução de shadow code. O shadow code é um problema de origem e governança do código, não um efeito de um ataque de malware. A confusão aqui é associar qualquer problema de segurança a um ataque externo, quando a causa apontada na alternativa correta é uma falha de processo interno.

Alternativa C — ❌ Incorreta

O uso de editores de texto simplificados, como o Bloco de Notas, em vez de IDEs especializadas, pode dificultar o desenvolvimento e a detecção de erros, mas não é a causa da introdução de shadow code. A ferramenta de edição não determina a origem do código; um desenvolvedor pode copiar código inseguro da Internet tanto usando um editor simples quanto uma IDE avançada. A questão é sobre a procedência e a validação do código, não sobre a ferramenta utilizada para escrevê-lo.

Alternativa D — ❌ Incorreta

O uso de linguagens de programação estruturadas, não orientadas a objeto, é uma escolha técnica de paradigma de programação. Isso não tem relação com a introdução de shadow code. Tanto linguagens estruturadas quanto orientadas a objeto podem receber código de fontes não confiáveis. A alternativa tenta confundir o candidato com um fator técnico irrelevante para o problema de governança de código.

Alternativa E — ❌ Incorreta

O shadow code não está relacionado ao tamanho da equipe. Um único desenvolvedor pode copiar código inseguro da Internet, assim como uma equipe grande pode ter processos falhos que permitam a entrada de código não aprovado. A alternativa inverte a lógica: o problema não é a quantidade de pessoas, mas a existência e o cumprimento de processos de segurança no desenvolvimento. A ausência de controles pode ocorrer tanto em equipes pequenas quanto grandes.

Gabarito: letra A