오픈 소스를 언급하는 거부는 좀처럼 라이선스 문제가 아니다. 검토자는 보통 누군가 배포된 릴리스를 유지보수하는지, 설치된 빌드를 식별할 수 있는지, 평가가 연결되는 대상을 포괄하는지, 또는 연결을 철회할 수 있는지와 같은 요구사항을 지킨다. 뒤따르는 논쟁은 대개 아무도 묻지 않은 질문에 답한다.

라이선스를 변호하기 전에 어떤 요구사항이 적용되는지 물어라. 그 답이 필요한 문서를 결정한다.

라벨은 요구사항이 아니다

읽을 수 있는 소스 코드는 공개된 구현을 검사할 수 있다는 뜻이다. 누군가 검사했다는 뜻도, 게이트웨이의 빌드가 공개된 것과 일치한다는 뜻도, 유지관리자가 당신의 배포에 수정을 빚졌다는 뜻도 아니다. 각각은 별도의 소유자를 가진 별도의 주장이며, 그중 하나가 필요한 검토자는 나머지로 만족하지 않는다. 주장을 소리 내어 이름 붙이는 것만으로도 대개 대화가 바뀐다.

반대의 실수도 흔하다. 상용 라이선스는 지원이 당신이 의존하는 기능을 포함한다는 것도, 평가가 당신이 배포하는 구성요소를 조사했다는 것도, 공급업체가 유지보수 기간 안에 수정을 보낸다는 것도 증명하지 않는다. 라이선스는 배포 조건을 설명하고, 조달 결정은 신뢰에 관한 것이다. 어느 쪽이든 라이선스는 답에서 가장 정보가 적은 부분이다.

클라이언트와 서비스를 분리하라. 데스크톱 클라이언트 감사는 파트너의 게이트웨이 구성, 그들의 신원 제공자, 운영자가 계정 삭제를 처리하는 방식에 대해 아무것도 말해 주지 않는다. 수집하는 증거는 파트너에게 신뢰를 요청하는 경계와 일치해야 한다.

우려를 산출물로 바꿔라

승인자에게 요구사항을 한 문장으로 말해 달라고 요청하고, 그것을 충족할 산출물을 지목하라. 모호한 안심이 이 대화를 이데올로기 논쟁으로 만든다.

What the reviewer is protectingArtifact that answers itWho can sign it
The deployed release keeps getting fixesNamed maintainer, supported version list and the cadence for security releasesThe operating team, with the maintainer's published policy attached
The build is the one that was reviewedPackage source, version string and the checksum or signature you verify at installThe team that builds or vendors the package
An assessment covers the right scopeComponent and version assessed, findings raised, corrections made, retest dateWhoever performed the assessment
The access can be withdrawnIdentities granted, resources reachable, and the tested removal procedureThe service owner on the partner side

NIST Secure Software Development Framework은 여기서 조달 대화를 관행과 공급업체 커뮤니케이션이라는 공통 어휘로 틀 짓는다는 한 가지 좁은 이유로 유용하다. 이는 라벨을 두고 논쟁하는 대신 정의된 증거를 요구하는 것을 뒷받침하며, 특정 VPN이 통과하는 인증은 아니다.

가운데 열이 무엇을 하는지 보라. 각 행은 있거나 없는 문서를 요구하며, 이는 의견을 누군가 만들거나 거부할 수 있는 산출물로 바꾼다.

클라이언트와 서비스를 분리하라

클라이언트 애플리케이션에 대한 지원 계약은 당신의 트래픽이 도달하는 서버에 대한 약속이 아니다. 증거를 제시하기 전에 경로의 어느 부분을 파트너가 운영하고 어느 부분을 당신이 그들을 대신해 운영하는지 표시하라. 둘을 섞으면 철저해 보이지만 아무것도 답하지 않는 문서 묶음이 된다.

배포가 당신의 것이라면, 파트너는 신원과 접근 규칙만 신뢰하면 될 수 있으며, 이는 전체 소프트웨어 공급망을 신뢰하는 것보다 훨씬 작은 요청이다. 배포가 그들의 것이라면, 당신이 선호하는 클라이언트는 무관할 수 있고 게이트웨이 구성이 주제가 된다. 두 번째 회의 전에 어느 경우인지 파악하면 검토 주기 하나를 아낀다.

그다음 검토가 실제로 실패하는 운영상 질문, 즉 누가 계정을 제거하는지, 얼마나 빨리, 이후에 어떤 증거가 남는지를 확인하라. 제거 절차가 없는 아름답게 문서화된 평가는 여전히 미해결 지적이다.

논쟁이 아니라 결정으로 마무리하라

교환을 수용된 버전, 그에 붙은 통제, 지명된 운영자, 아직 남은 증거, 그리고 그 기한이라는 서면 결과로 끝내라. 해결되지 않은 것은 일반적인 승인 선언에 흡수되지 않고 조건으로 기록되어야 한다.

정책이 특정 승인 제품을 지목한다면, 아무도 승인하지 않은 병행 방안을 만드는 대신 예외 경로를 사용하라. 설득력 있는 기술적 논거는 허가를 주지 않으며, 비공식 배포는 발견되기를 기다리는 지적이다.

요구사항을 정말로 충족할 수 없다면 승인된 대안으로 옮기고 이유를 말하라. 이 작업의 목적은 조직이 무엇에 의존할 수 있는지 확립하는 것이며, 분명한 아니오는 나중에 아무도 변호할 수 없는 승인보다 나은 결과다.

관련 글