Porque uma VPN de código aberto é rejeitada nas compras
Um revisor que se opõe ao código aberto protege normalmente um requisito, não um gosto por licenças. Pergunte qual, e depois produza o artefacto que lhe responde.
As rejeições que invocam o código aberto raramente dependem da licença. O revisor protege normalmente um requisito: que alguém mantenha a versão implementada, que a compilação instalada possa ser identificada, que uma avaliação cubra o que está a ser ligado, ou que a ligação possa ser retirada. O debate que se segue responde muitas vezes a uma pergunta que ninguém fez.
Pergunte que requisito se aplica antes de defender uma licença. A resposta decide que documento precisa.
O rótulo não é o requisito
Código-fonte legível significa que a implementação publicada pode ser inspecionada. Não significa que alguém a inspecionou, que a compilação no gateway corresponde à publicada, ou que um mantenedor deva uma correção à sua implementação. Cada uma destas é uma afirmação separada com um proprietário separado, e um revisor que precisa de uma delas não ficará satisfeito com as outras. Nomear a afirmação em voz alta costuma bastar para mudar a conversa.
O erro inverso é igualmente comum. Uma licença comercial não prova que o suporte cobre a funcionalidade de que depende, que uma avaliação examinou o componente que implementa, ou que o fornecedor enviará uma correção dentro da sua janela de manutenção. O licenciamento descreve termos de distribuição, enquanto as decisões de compra dizem respeito à confiança. Em qualquer dos casos, a licença é a parte menos informativa da resposta.
Mantenha também o cliente e o serviço separados. Uma auditoria de um cliente de ambiente de trabalho não diz nada sobre a configuração do gateway do parceiro, o seu fornecedor de identidade ou a forma como os seus operadores tratam a remoção de contas. Qualquer evidência que reúna tem de corresponder ao limite que se pede ao parceiro para confiar.
Transforme a preocupação num artefacto
Peça ao aprovador que declare o requisito numa frase, e depois nomeie o artefacto que o satisfaria. É a tranquilização vaga que transforma estas conversas num debate sobre ideologia.
| What the reviewer is protecting | Artifact that answers it | Who can sign it |
|---|---|---|
| The deployed release keeps getting fixes | Named maintainer, supported version list and the cadence for security releases | The operating team, with the maintainer's published policy attached |
| The build is the one that was reviewed | Package source, version string and the checksum or signature you verify at install | The team that builds or vendors the package |
| An assessment covers the right scope | Component and version assessed, findings raised, corrections made, retest date | Whoever performed the assessment |
| The access can be withdrawn | Identities granted, resources reachable, and the tested removal procedure | The service owner on the partner side |
NIST Secure Software Development Framework é útil aqui por uma razão estreita: enquadra as conversas de compra em torno de um vocabulário partilhado de práticas e comunicação com fornecedores. Isso apoia o pedido de evidência definida em vez de uma discussão sobre um rótulo, e não é uma certificação que qualquer VPN concreta passe.
Repare no que faz a coluna central. Cada linha pede um documento que existe ou não existe, o que converte uma opinião num resultado que alguém pode produzir ou recusar.
Separe o cliente do serviço
Um contrato de suporte para uma aplicação cliente não é um compromisso sobre o servidor que o seu tráfego alcança. Antes de apresentar evidência, marque que partes do caminho o parceiro opera e que partes opera você em seu nome. Misturar as duas produz um pacote de documentos que parece exaustivo e não responde a nada.
Se a implementação é sua, o parceiro pode só precisar de confiar numa identidade e numa regra de acesso, o que é um pedido muito menor do que confiar em toda a sua cadeia de fornecimento de software. Se a implementação é dele, o cliente que prefere pode ser irrelevante e a configuração do gateway passa a ser o assunto. Determinar em que caso está antes da segunda reunião poupa um ciclo de revisão.
Depois verifique as questões operacionais em que as revisões falham de facto: quem remove uma conta, com que rapidez e que evidência existe depois. Uma avaliação bem documentada sem procedimento de remoção continua a ser uma constatação aberta.
Termine com uma decisão, não com um debate
Termine a troca com um resultado escrito: a versão aceite, os controlos associados, os operadores nomeados, a evidência ainda em falta e a data em que é devida. Tudo o que ficar por resolver deve ser registado como condição em vez de ser absorvido numa declaração geral de aprovação.
Se a política nomear um produto aprovado específico, use a via de exceção em vez de construir um acordo paralelo que ninguém autorizou. Um argumento técnico convincente não concede permissão, e uma implementação não oficial é uma constatação à espera de ser descoberta.
Se um requisito realmente não puder ser cumprido, passe para a alternativa aprovada e diga porquê. O objetivo do exercício é estabelecer aquilo em que a organização se pode basear, e um não claro é um resultado melhor do que uma aprovação que ninguém poderá defender mais tarde.