Por que se rexeita unha VPN de código aberto na contratación
Un revisor que se opón ao código aberto adoita protexer un requisito, non un gusto polas licenzas. Pregunte cal, e despois produza o artefacto que o responde.
Os rexeitamentos que citan o código aberto raramente dependen da licenza. O revisor adoita protexer un requisito: que alguén manteña a versión despregada, que a compilación instalada poida identificarse, que unha avaliación cubra o que se conecta ou que a conexión poida retirarse. O debate que segue adoita responder a unha pregunta que ninguén fixo.
Pregunte que requisito se aplica antes de defender unha licenza. A resposta decide que documento necesita.
A etiqueta non é o requisito
O código fonte lexible significa que a implementación publicada pode inspeccionarse. Non significa que alguén a inspeccionase, que a compilación da pasarela coincida coa publicada ou que un mantedor deba unha corrección ao seu despregamento. Cada unha desas é unha afirmación distinta cun propietario distinto, e un revisor que necesita unha delas non quedará satisfeito coas outras. Nomear a afirmación en voz alta adoita abondar para cambiar a conversa.
O erro inverso é igual de común. Unha licenza comercial non demostra que o soporte cubra a función da que depende, que unha avaliación examinase o compoñente que despregue ou que o provedor vaia enviar unha corrección dentro da súa xanela de mantemento. A licenza describe condicións de distribución, mentres que as decisións de compra tratan da confianza. En calquera caso, a licenza é a parte menos informativa da resposta.
Manteña tamén separados o cliente e o servizo. Unha auditoría dun cliente de escritorio non di nada sobre a configuración da pasarela do socio, o seu provedor de identidade nin a forma en que os seus operadores xestionan a eliminación de contas. Calquera evidencia que reúna debe coincidir co límite que se lle pide ao socio que confíe.
Converta a preocupación nun artefacto
Pida ao aprobador que formule o requisito nunha frase e logo nomee o artefacto que o satisfaría. A tranquilidade vaga é o que converte estas conversas nun debate sobre ideoloxía.
| 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 aquí por unha razón estreita: enmarca as conversas de adquisición arredor dun vocabulario compartido de prácticas e comunicación con provedores. Iso respalda pedir evidencia definida en lugar de discutir sobre unha etiqueta, e non é unha certificación que supere ningunha VPN concreta.
Fíxese no que fai a columna central. Cada fila pide un documento que existe ou non existe, o que converte unha opinión nun entregable que alguén pode producir ou rexeitar.
Separe o cliente do servizo
Un contrato de soporte para unha aplicación cliente non é un compromiso sobre o servidor ao que chega o seu tráfico. Antes de presentar evidencia, marque que partes do camiño opera o socio e que partes opera vostede no seu nome. Mesturar as dúas produce un paquete de documentos que parece exhaustivo e non responde a nada.
Se o despregamento é seu, pode que o socio só necesite confiar nunha identidade e unha regra de acceso, o que é unha petición moito menor que confiar en toda a súa cadea de subministración de software. Se o despregamento é del, o cliente que prefire pode ser irrelevante e a configuración da pasarela pasa a ser o tema. Aclarar en que caso está antes da segunda reunión aforra un ciclo de revisión.
Despois comprobe as cuestións operativas nas que as revisións fallan de verdade: quen elimina unha conta, con que rapidez e que evidencia queda despois. Unha avaliación ben documentada sen procedemento de eliminación segue sendo un achado aberto.
Pechar cunha decisión, non cun debate
Termine o intercambio cun resultado escrito: a versión aceptada, os controis asociados, os operadores nomeados, a evidencia aínda pendente e a data en que debe entregarse. Todo o que quede sen resolver debe rexistrarse como condición en lugar de absorberse nunha declaración xeral de aprobación.
Se a política nomea un produto aprobado concreto, use a vía de excepción en lugar de construír un acordo paralelo que ninguén autorizou. Un argumento técnico convincente non concede permiso, e un despregamento non oficial é un achado agardando ser descuberto.
Se un requisito realmente non pode cumprirse, pase á alternativa aprobada e diga por que. O propósito do exercicio é establecer en que pode confiar a organización, e un non claro é un mellor resultado que unha aprobación que ninguén poida defender despois.