Como posso ter certeza de que o código-fonte não vazou por nossos próprios desenvolvedores?

3

Eu não sou engenheiro de software. Então, estou curioso sobre como uma empresa pode garantir que o código-fonte de seu produto não seja vazado por seus próprios desenvolvedores / funcionários? Qual método você usa para rastrear uma vez que vazou?

    
por Liming Xu 10.09.2009 / 13:50

9 respostas

41

Contrate pessoas nas quais possa confiar e confiar nas pessoas que contratar. Se você agir como se não pudesse confiar neles, eles deixarão de confiar em você e deixarão de agir pelo bem da sua empresa.

Não há nada técnico que você possa fazer, pois, se eu puder trabalhar com seu código-fonte, posso colocá-lo em um pen drive ou enviá-lo por e-mail para minha conta ou qualquer outra forma de obtê-lo.

    
por 10.09.2009 / 13:53
11

Eu acho que Paul está certo com o 'Se você não confia neles, não os contrate', mas duas outras coisas para pensar:

O código-fonte é realmente tão especial?
Muitas vezes, é o processo de negócios completo, o nome da marca, combinado com o código que faz um produto realmente bom. A grande maioria do código que está escrito, provavelmente seria mais fácil para outros desenvolvedores reescreverem e lerem o que seus desenvolvedores escreveram.

Se realmente é tão especial
Sua única opção seria quebrar as tarefas e não permitir que todos os desenvolvedores vejam todo o código. Isso obviamente tem uma penalidade muito grande e provavelmente resultará em um código pior. Eu acho que o uso disso seria extremamente raro, talvez situações governamentais de alta segurança.

    
por 10.09.2009 / 14:10
2

Eu diria que a única maneira de proteger o código-fonte é não contratar ninguém e você é o único desenvolvedor do projeto.

Suponho que você poderia tentar dividir o projeto em módulos que são ligados individualmente mais tarde, para que ninguém possa montar seu produto completamente, mas não consigo imaginar a política (ou a moral diminuída) de tal ambiente ...

Caso contrário, você teria que conversar com um advogado sobre opções para processar desenvolvedores que o ativassem, aplicar um sistema de check-in de código que responsabilizasse quem já jogou com o código e usar muitos peer review para verificar malware escondido na fonte. E certifique-se de que todas as suas políticas (incluindo as cláusulas "sue-pants-off") sejam documentadas e conhecidas por seus funcionários.

É claro que há um grande desafio em fazer isso e não ser um idiota que merece ter seu código-fonte roubado.

Eu diria que você só tem que confiar em seus funcionários, assim como qualquer outro empregador tem que confiar em seus funcionários não estão usando o carro da empresa para corridas de arrancada e usando seus cubículos para executar um negócio pessoal de Lia Sophia ao lado. Não que você não vá se queimar de vez em quando, mas você vai estimular muito mais ressentimento e agitação se você tratar todo mundo como um criminoso.

Há também a possibilidade de uma mudança de atitude ... como o SO Podcast aponta, StackOverflow está sendo "roubado" periodicamente e re-proposto, mas obviamente há um original bem-sucedido ainda por aí. Se o seu código for roubado e alguém criar um negócio próspero baseado apenas no código fonte, a empresa em si tem falta de algumas áreas como experiência do cliente de suporte, profissionalismo, etc. Não é certo que ele seja roubado, mas ter alguma coisa tomada é sempre um risco que vem como um custo de fazer negócios, às vezes. Sem mencionar que é tecnicamente possível para alguém fazer engenharia reversa de qualquer produto (ou apenas roubar o produto e reembalá-lo, sem o código fonte, muito mais fácil de fazer ...)

Parece que a maioria das pessoas se preocupa com esse tipo de pirataria quando alguém rouba a fonte original e precisa brincar com a atualização e a alteração e compilação dessa forma.

    
por 10.09.2009 / 14:28
1

Uma abordagem adotada por um empregador anterior era a de que todos os arquivos fonte (e toda a documentação interna, aliás) tinham que conter um aviso de confidencialidade.

Havia também recursos significativos gastos na educação do pessoal sobre os riscos para a empresa como um todo, se houvesse vazamento.

Vale a pena explicitar o contrato de trabalho também, especialmente se você estiver em uma jurisdição onde o empregador tentaria reivindicar danos de qualquer pessoa com vazamento de PI.

    
por 10.09.2009 / 14:34
1

Outra maneira de lidar com esse problema é tornar o código-fonte open source . Não há nada para roubar, se é tudo público de qualquer maneira. No entanto, a única maneira de isso ser possível seria se o código-fonte não fosse o molho secreto que traz dinheiro. Se a empresa ganha dinheiro vendendo serviços ou hardware, distribuir o software seria um problema menor. Idem, se o software é apenas uma pequena parte de um sistema extremamente complexo.

    
por 10.09.2009 / 15:00
1

A única maneira que eu acho que você poderia conseguir isso seria departalizar tudo. Certifique-se de que cada equipe construa sua parte para especificar de que maneira o conhecimento é difundido entre uma variedade de pessoas e ninguém tem uma visão completa.

Você precisaria tornar os computadores fisicamente inacessíveis (sem gravadores ópticos / usb) e não conectá-los à Internet.

Mas além disso, é uma coisa de confiança e realmente as pessoas tendem a lembrar de resolver problemas e como eles resolveram. Isso é o que é codificação. Eles poderão reescrever o que fizeram.

    
por 10.09.2009 / 17:03
1

Para o extremamente paranóico, há sempre o modelo compartimentalizado de necessidade de conhecimento que limita o conhecimento (e o acesso) do todo a um número muito pequeno de pessoas. Eu acho que seria um ambiente muito difícil e desagradável para se trabalhar.

    
por 10.09.2009 / 18:00
0

Concordo totalmente com a resposta acima, é sempre melhor abordar isso com uma solução não técnica.

Mas aqui estão as minhas £ 0,02.

Solução não técnica: embora isso não seja ótimo para projetos pequenos ou simples. Você pode dividir o aplicativo em módulos / componentes para que seus desenvolvedores se pareçam mais com os trabalhadores de montagem em uma fábrica. Ninguém tem acesso a todo o projeto, eles só vêem a parte em que estão trabalhando.

Solução técnica: Supondo que os desenvolvedores estejam no local. Bloqueie as estações de trabalho usando um software de sentinela USB como o Sanctuary. Não forneça aos administradores locais dos desenvolvedores estações de trabalho para que eles não possam instalar software de terceiros para contornar a segurança (proxies ssh / http, etc.). Empregue alguma forma de software Data Loss Prevention (todas as empresas de software de segurança têm seu próprio CA, ClearSwift etc). Bloquear / monitorar o e-mail para a Internet e o acesso à Web. O trabalho nunca é levado para casa, não importa o quê, o mesmo vale para o teletrabalho, não o permita.

    
por 10.09.2009 / 14:22
0

Quando você tiver uma pergunta de segurança como essa, pergunte a si mesmo: " O que eles fariam nos filmes? "

Existe um filme que me vem à mente quando penso neste problema. Como fazer com que alguém escreva código, mas certifique-se de que não é possível levar o código para casa. De fato, depois de assistir ao filme ' Paycheck ' estrelado por Ben Affleck, eu acho que tenho o responda. Neste tomate podre, Ben interpreta um engenheiro que está trancado em uma sala até que ele termine o trabalho. Quando ele termina, seu empregador simplesmente lhe dá um cheque. Ah, e eles apagam a memória dele.

Então - bloqueie seus desenvolvedores em uma sala até que o software termine, depois limpe a memória deles.

texto alternativo http://upload.wikimedia.org /wikipedia/en/thumb/2/29/Paycheck_affleck.jpg/180px-Paycheck_affleck.jpg Obtendo sua memória limpa.

    
por 10.09.2009 / 17:20

Tags