당사의 디지털 인프라를 거대하고 보안이 철저한 성(castle)이라고 상상해 보십시오. 이 성 안에서는 개발자들이 새로운 도구, 가구, 물자(이를 "아티팩트(artifacts)"라고 부릅니다)를 끊임없이 들여와 업무를 구축하고 유지합니다. 이러한 물자들은 오픈 소스 라이브러리, 사전 제작된 컨테이너, AI 모델, 코드 조각과 같이 외부 세계로부터 흘러 들어옵니다.

문제는 개발자가 인터넷에서 도구를 가져오는 것은 매우 쉽지만, "성 내부의 수비대"(기관) 입장에서는 그 도구가 안전한지, 어디에서 왔는지, 혹은 나중에 트로이 목마로 밝혀졌을 때 어떻게 제거해야 하는지 아는 것이 매우 어렵다는 점입니다.

이 논문은 **커스터디 엔벨로프 임계값(Custody Envelope Threshold)**이라는 새로운 규칙을 소개합니다. 이 규칙은 왜 어떤 도구들은 성 안으로 들어오는 "그린 라이트(승인)"를 받는 반 반면, 어떤 도구들은 성문에서 멈춰 서거나, 우리에 갇히거나, 혹은 경호원의 호위를 받아야만 들어올 수 있는지를 설명합니다.

다음은 쉬운 비유를 사용한 상세 내용입니다.

1. 핵심 개념: "커스터디 엔벨로프(Custody Envelope, 관리 봉투)"

성으로 가져오고 싶은 모든 도구를 하나의 패키지라고 생각하십시오. 이를 들여보내기 위해서는 커스터디 엔벨로프로 감싸야 합니다. 이 봉투는 종이로 만들어진 것이 아니라, 세 가지 특정 잠금장치로 만들어집니다:

1. 신원 잠금(Identity Lock): 이것이 정확히 무엇인지 아는가? (진짜인가, 아니면 가짜인가?)
2. 진입 잠금(Ingress Lock): 이것이 어떻게 여기에 왔는가? (배지를 달고 정문으로 걸어 들어왔는가, 아니면 창문을 통해 몰래 들어왔는가?)
3. 철회 잠금(Revocation Lock): 나중에 이것이 위험하다는 것을 알게 되었을 때, 즉시 붙잡아서 내다 버릴 수 있는가?

황금률: 이 봉투의 강도는 성 내부에서 해당 도구가 가진 **권한(Power)**과 일치해야 합니다.

• 낮은 권한: 도구가 단순히 장식용 스티커(낮은 권리)라면, 얇은 봉투도 괜찮습니다.
• 높은 권한: 도구가 성의 모든 문을 열 수 있는 마스터 키(높은 권한)라면, 봉투는 깨지지 않는 강철로 만들어져야 합니다. 만약 봉투가 약하다면, 그 도구는 들어올 수 없습니다.

2. 왜 어떤 도구들은 제지당하는가 (거버넌스 모드)

이 논문은 기관들이 단순히 "예" 또는 "아니오"라고만 답하지 않는다고 주장합니다. 그들은 완벽한 봉투를 갖추지 못한 도구들을 처리하기 위해 다양한 방식을 선택합니다. 이를 다음과 같은 서로 다른 보안 체크포인트로 생각할 수 있습니다.

• 프록시 방식 (Proxied, "완충 구역"):

  • 시나리오: 당신은 인기 있는 도구를 원하지만, 그것이 수상한 공공 거리에서 온 것입니다.
  • 해결책: 그것을 직접 걸어 들어오게 하지 않습니다. 대신, 신뢰할 수 있는 쿠리어(내부 피드 또는 미러 서버)가 그것을 가져와서 검사한 뒤 들여오도록 합니다. 도구 자체는 동일하지만, 그것이 지나온 경로가 통제되는 것입니다.
  • 예시: 소프트웨어 패키지를 공용 인터넷 대신 회사의 프라이빗 서버를 통해 다운로드하는 것.

• 정책 매개 방식 (Policy-Mediated, "엄격한 계약"):

  • 시나리오: 도구가 알려진 곳에서 왔지만, 나중에 이름이나 버전이 바뀔 수도 있습니다.
  • 해결책: 입장을 허용하되, 엄격한 계약을 체결하게 합니다: "당신은 반드시 이 버전을 유지해야 하며, 반드시 이 특정 인물에 의해 서명되어야 한다." 만약 변경된다면, 즉시 쫓겨납니다.
  • 예시: GitHub Action을 변경 불가능한 특정 코드 버전에 고정(pinning)했을 때만 허용하는 것.

• 벤더 매개 방식 (Vendor-Mediated, "에스코트 투어"):

  • 시나리오: 도구가 너무 복잡하거나 위험해서 직접 검사하기 어렵습니다.
  • 해결책: 전문 보안 업체(클라우드 제공업체나 마켓플레이스)를 고용하여 대신 검사하게 합니다. 우리는 그들의 봉투를 신뢰합니다.
  • 예시: AI 모델을 실행하기 전 바이러스를 스캔하는 관리형 클라우드 서비스를 통해서만 사용하는 것.

• 내재화 방식 (Internalized, "복사 및 붙여넣기"):

  • 시나리오: 도구가 너무 특수해서 외부 벤더가 당신의 성 구조를 이해할 수 없습니다.
  • 해결책: 도구를 가져와서, 우리만의 패키징으로 다시 감싸서 "내부" 제품으로 만듭니다. 이제 그것은 우리의 소유입니다.
  • 예시: 공개된 코드 모듈을 가져와서 회사의 특정 보안 규칙에 맞게 재작성하는 것.

• 격리/거부 방식 (Quarantined/Rejected, "출입 금지 표지판"):

  • 시나리오: 도구가 너무 위험해서 어떤 방식으로 감싸도 안전할 수 없습니다.
  • 해결책: 성 밖에 머물게 합니다. 샌드박스(놀이 공간) 안에서 관찰될 수는 있지만, 실제 성에는 절대 닿지 않습니다.

3. "정밀 조사(Scrutiny)" 요소

논문은 모든 성이 같지는 않다고 언급합니다.

• 낮은 정밀 조사: 작은 스타트업이나 취미 프로젝트는 감시하는 사람이 없기 때문에 거의 무엇이든 들여보낼 수 있습니다. 이들은 약한 봉투를 수용할 수도 있습니다.
• 높은 정밀 조사: 은행, 병원, 또는 정부 기관은 감사인, 규제 기관, 고객의 감시를 받습니다. 이들은 반드시 강력한 봉투를 가져야 합니다. 만약 높은 권한을 가진 도구를 약한 봉투와 함께 들여보낸다면, 이들은 곤경에 처할 것입니다.

논문은 조직이 더 많이 "정밀 조사"(더 많이 감사받고 규제됨)를 받을수록, 자연스럽게 더 엄격한 방식(프록시 또는 벤더 매개 방식 등)을 사용하기 시작할 것이라고 예측합니다.

4. 논문의 실제 사례

저자들은 이 규칙을 여섯 가지 유형의 도구에 대해 테스트했습니다:

• 소프트웨어 패키지: 보통 허용되지만, 회사의 "프록시"(내부 피드)를 통해서만 들어올 수 있습니다.
• GitHub Actions (자동화 스크립트): 이들은 매우 강력합니다(코드를 변경할 수 있음). 따라서 "정책 매개"(특정 버전에 고정)되지 않으면 차단되는 경우가 많습니다.
• 컨테이너 이미지 (사전 제작된 소프트웨어 박스): 무작위 공용 박스는 위험합니다. 보통 신뢰할 수 있는 이미지 목록을 통해 "프록시"됩니다.
• Terraform Providers (인프라 도구): 강력하지만 좋은 "신원 잠금"(서명)을 가지고 있어, 직접 허용되는 경우가 많습니다.
• Terraform Modules (디자인 템플릿): 회사의 특정 레이아웃에 맞춰야 하므로 주로 "내재화"됩니다.
• AI 모델: 까다롭습니다. 코드를 실행한다면 높은 권한을 가집니다. 주로 "벤더 매개"(안전한 클라우드 서비스를 통해 실행)되거나, 더 나은 안전 도구가 생길 때까지 "격리"됩니다.

5. "Curl | Bash" 테스트

논문은 흔한 개발자 습관인 curl | bash(인터넷에서 스크립트를 다운로드하여 즉시 실행하는 것)를 언급합니다.

• 판결: 이것은 궁극적인 "약한 봉투"입니다. 신원 확인도 없고, 통제된 경로도 없으며, 철회할 방법도 없습니다.
• 예측: 진지하고 정밀 조사가 높은 기업에서는 이것이 금지되거나 대폭 수정되어야 합니다. 만약 은행이 개발자들이 운영 서버에서 인터넷의 무작위 스크립트를 실행하도록 내버려 두고 있다면, 논문은 그 기관이 "커스터디 엔벨로프" 테스트를 통과하지 못했다고 말합니다.

요약

이 논문은 단순히 "조심하라"고 말하는 것이 아닙니다. 의사결정을 위한 수학적인 공식을 제공합니다:

만약 도구의 권한(Power) > 봉투의 강도(Strength)라면, 당신은 봉투를 바꾸거나(프록시, 매개, 내재화), 도구를 차단해야 한다.

이것은 왜 도구마다 다르게 취급되는지를 설명합니다. 그것은 도구가 "오픈 소스"인지 혹은 "인기가 있는지"의 문제가 아니라, 그 도구가 당신의 시스템 내에서 얼마나 많은 권한을 가지는지, 그리고 당신이 그것을 얼마나 잘 통제할 수 있는지에 관한 것입니다.