Testes de CI para impor regras de desenvolvimento específicas - boa prática?

5
O seguinte é puramente hipotético e qualquer parte particular dele pode ou não descrever com precisão pessoas reais ou situações, sejam elas vivas, mortas ou apenas fingindo.

Digamos que eu seja um desenvolvedor sênior ou arquiteto encarregado de uma equipe de desenvolvedores trabalhando em um projeto. Este projeto inclui uma biblioteca de segurança para autenticação / autorização do usuário do aplicativo em desenvolvimento. A biblioteca deve estar disponível para os desenvolvedores editarem; no entanto, desejo "confiar, mas verificar" que os codificadores não estão fazendo coisas que poderiam comprometer a segurança do sistema finalizado, e como essa não é minha única responsabilidade, quero que isso seja feito de maneira automatizada.

Como um exemplo, digamos que eu tenha uma interface que represente um usuário que tenha sido autenticado pela biblioteca de segurança do sistema. A interface expõe informações básicas do usuário e uma lista de coisas que o usuário está autorizado a fazer (para que o aplicativo cliente não precise ficar perguntando ao servidor "posso fazer isso?"), Tudo de uma forma imutável, é claro. Há apenas uma implementação dessa interface no código de produção e, para os fins deste post, podemos dizer que todas as medidas apropriadas foram tomadas para garantir que essa implementação só possa ser usada pela única parte de nosso código que precisa ser capaz para criar concreções da interface.

Os codificadores foram instruídos de que essa interface e sua implementação são sacrossantos e quaisquer mudanças devem passar por mim. No entanto, essas são apenas palavras; a fonte da biblioteca de segurança está aberta para edição por necessidade. Qualquer um dos meus desenvolvedores poderia decidir que essa implementação segura, privada e checada por hash precisa ser pública para que eles pudessem fazer X, ou alternativamente eles poderiam criar sua própria implementação dessa interface pública em uma biblioteca diferente, expondo o algoritmo de hash que fornece a soma de verificação segura, a fim de fazer Y. Eu não posso estar ciente dessas alterações para que eu possa bater o desenvolvedor sobre a cabeça por isso. Um invasor pode então encontrar esses pequenos nuggets em uma biblioteca do produto compilado e explorá-lo para fornecer usuários falsos e / ou permissões administrativas falsamente elevadas, evitando todo o sistema de segurança.

Esta possibilidade me mantém acordado por algumas noites, e então eu crio um teste automatizado que verifica reflexivamente a base de código para tipos derivados da interface, e falha se encontrar algum que não seja exatamente o que e onde eu espero que eles estar. Eu compilo este teste em um projeto em uma pasta separada do VCS que só tenho o direito de comprometer, tenho CI compilar como uma biblioteca externa do projeto principal, e configurá-lo para executar como parte do conjunto de testes CI para usuário confirma. Agora, tenho um teste automatizado sob o meu controle completo que me dirá (e a todos os outros) se o número de implementações aumenta sem o meu envolvimento, ou uma implementação que eu saiba tem algo novo adicionado ou tem seus modificadores ou seus membros alterados. Eu posso então investigar mais e recuperar a oportunidade de vencer os desenvolvedores quando necessário.

Isso é considerado "razoável" para se fazer em situações como essa? Eu vou ser visto em uma luz negativa por ir atrás das costas de meus devs para garantir que eles não estão fazendo algo que não deveriam?

    
por KeithS 04.04.2012 / 21:45
fonte

2 respostas

4

Isso não é irracional, porque é uma boa ideia fazer revisões de código para código baseado em segurança. Você pode exigir que os desenvolvedores façam revisões de código antes de verificar o código, mas isso não protege você se eles esquecerem e fizerem o check-in de qualquer maneira.

    
por 04.04.2012 / 22:01
fonte
1

O que você quer é completamente razoável. Nosso processo de criação de CI, além de compilar o código, executa o StyleCop, o FxCop e o NCover e executa testes de unidade. O resultado foi um código de qualidade muito maior, código mais legível e sustentável. Você também pode fazer outras coisas automatizadas, como a análise estática dos contratos de código C #.

Um bom efeito colateral é que, durante nossas revisões de código, podemos nos concentrar em coisas que realmente importam, em vez de estilos / práticas recomendadas.

    
por 05.04.2012 / 04:02
fonte