SecureChain은 모든 크레이트를 재구성하지만, 고객의 화물 처리 워크플로에는 전혀 간섭하지 않습니다.

주요 내용

• 화물 소스 교체는 교체된 소스가 기존 크레이트의 내용물과 동일한 역할을 수행한다고 가정하므로, 프로젝트 파일을 변경할 필요가 없습니다.
• 등록기관 측의 심사에서는 상자의 명성보다는 그 안에 들어 있는 내용물을 기준으로 평가합니다.
• 검증 경로는 다음과 같습니다. .cargo/config.toml 변경하되, 다음은 수정하지 마십시오. Cargo.toml 또는 Cargo.lock.
• 패치된 크레이트는 예외이며, 이를 선택하면 명시적인 변경 사항이 발생합니다.

누구도 의도적으로 crates.io를 기본값으로 신뢰하기로 결정하는 경우는 거의 없습니다. 그저 기본값일 뿐이죠. 누군가가 이를 직접 살펴보기 전까지는 말입니다. 그 다음으로 떠오르는 질문은 대개 ‘대신 무엇을 해야 할까’와 같은 내용인데, 바로 그 지점에서 비공개 카고 레지스트리가 더 이상 당연한 선택지가 아니게 됩니다.

이 용어는 적어도 세 가지 서로 다른 구성을 포괄하며, Cargo는 이들을 상당히 다르게 처리하기 때문에 잘못된 것을 선택하면 나중에 문제가 발생합니다. 하나는 프로젝트 파일을 전혀 수정할 필요가 없습니다. 다른 하나는 리디렉션하려는 종속성을 선언한 모든 매니페스트를 수정해야 합니다. 대부분의 팀은 이미 작업을 어느 정도 진행한 후에야 어느 것이 어느 것인지 알게 됩니다.

무엇보다 먼저 한 가지 예외를 짚어둘 필요가 있는데, 이는 보통 나중에야 발견되는 사항이기 때문입니다. 검증 과정에서는 프로젝트 파일에 변경 사항이 발생하지 않습니다. 반면 패치된 크레이트의 경우 그렇지 않으며, 이를 적용하는 것은 항상 의도적인 수정 작업입니다.

일반적으로 ‘사설 화물 등록부’가 의미하는 바

‘벤더링(vendoring)’, ‘소스 대체(미러링)’, 그리고 사설 레지스트리를 포함한 ‘대체 레지스트리’라는 세 가지 접근 방식이 하나의 범주 아래서 논의됩니다. Cargo의 공식 문서에서는 소스 대체를 사설 레지스트리의 한 유형이 아니라 사설 레지스트리와는 별개의 개념으로 다루고 있습니다.

소스 교체는 워크플로우 변경이 발생하지 않는다는 주장을 뒷받침하는 경우이며, 이 주장이 성립하는 이유는 Cargo가 양쪽의 크레이트 내용이 동일하다고 가정하기 때문입니다.

화물 소스 교체 기능은 미러 서버용으로 설계되었습니다. 이 기능은 교체된 화물이 원본과 동일한 소스를 포함한다고 가정하며, 원본에 없는 크레이트를 교체된 화물이 포함하는 것을 허용하지 않습니다. 많은 상인의 상품 설명이 이 부분을 지나치게 확대 해석하는 경우가 많으므로, 이 점에 대해 정확히 짚어둘 필요가 있습니다.

Cargo는 교체된 패키지를 crates.io와 대조하여 재확인하지 않습니다. 실제 프로젝트에서 이를 적용하는 방법은 다음과 같습니다. Cargo.lock, 이미 그곳에 기록된 체크섬은 내용이 변경된 크레이트와 일치하지 않으므로, 대체 크레이트를 아무런 오류 메시지 없이 자동으로 적용하는 대신 빌드가 실패하게 됩니다.

그건 제한 사항처럼 들리네요. 검증용 미러의 경우, 그게 바로 핵심입니다. 대체 미러는 해당 빌드에 이미 해결된 것과 동일한 크레이트 내용을 제공해야 합니다.

SecureChain도 본질적으로는 같은 방식으로 작동합니다. 소스 코드에서 크레이트를 다시 빌드하고 검증한 뒤, 기존 환경에 자연스럽게 통합되므로 개발자들은 평소와 똑같이 Cargo 명령어를 계속 사용할 수 있습니다.

카고를 통해 화물 상자의 배송지를 변경할 수 있는 두 가지 방법

소스 대체 파일은 다음 위치에 있습니다. .cargo/config.toml 그리고 프로젝트 내의 어떤 것도 건드리지 않습니다.

[source.crates-io]
replace-with = "securechain"

[source.securechain]
registry = "<your SecureChain registry index URL>"

대체 레지스트리는 또 다른 메커니즘으로, 설계상 작동 방식이 다릅니다.

[registries.securechain]
index = "<your SecureChain registry index URL>"

대체 레지스트리를 사용할 경우, 각 종속성마다 이름을 지정해야 합니다.

[dependencies]
serde = { version = "1.0", registry = "securechain" }

이는 해당 크레이트 중 하나를 선언한 모든 매니페스트에 걸쳐 의존성별로 적용되는 수정 사항이며, 이는 바로 소스 대체 경로가 피하는 마이그레이션 비용과 정확히 일치합니다.

현실 점검: 수정된 크레이트를 제공하면서도 프로젝트 파일의 내용은 전혀 변경되지 않는다고 주장하는 벤더는, 표준 Cargo 소스 대체 기능이 지원하지 않는 방식을 설명하고 있는 것입니다. 해당 통합 기능이 실제로 두 가지 메커니즘 중 어느 것을 사용하는지 물어보면, 나머지 평가 과정이 훨씬 더 간단해집니다.

소스 교체 시 잠금 파일이 유효한 상태를 유지하는 이유

신중한 Rust 엔지니어가 가장 먼저 던지는 질문은 다음과 같다. Cargo.lock 중단됩니다. 검증 경로에서는 그렇지 않은데, 그 이유는 이것이 현재 확보된 가장 강력한 증거이기도 하기 때문입니다.

A .crate 파일은 패키지화된 크레이트 소스 코드가 압축된 tar 아카이브입니다. Cargo의 자체 체크섬 검증 기능은 다운로드된 아카이브가 레지스트리 메타데이터와 락파일에서 예상되는 체크섬과 일치하는지 확인하며, 이것이 Cargo가 수행하는 전부입니다. Cargo는 어떤 것도 재컴파일하지 않습니다. 독립적인 재컴파일 및 비교 단계는 크레이트가 대체 소스를 통해 제공되기 전에, SecureChain과 같은 업스트림 서비스에서 이루어집니다.

재빌드 결과가 공개된 아티팩트와 일치하지 않을 경우, 이러한 불일치는 그냥 지나치는 것이 아니라 조사해야 할 문제로 간주됩니다. 패키징 과정의 특이점이나 재현 불가능한 릴리스 단계에서도 이러한 불일치가 발생할 수 있으므로, 불일치 자체만으로는 조작의 증거가 될 수 없습니다. 중요한 점은 이러한 문제가 그냥 사라지지 않고 표면화된다는 것입니다.

따라서 유용한 점은 검증 과정이 눈에 띄지 않는다는 것이 아닙니다. 검증된 크레이트는 변경되지 않은 채로 전달되는 반면, 예상치 못한 사항은 조용히 받아들여지는 대신 명확하게 드러난다는 점입니다.

rm -rf ~/.cargo/registry
cargo build --locked

레지스트리 캐시를 완전히 지우고, 또한 --locked 변경되지 않은 파일을 대상으로 성공적인 빌드를 수행합니다. Cargo.lock, 호환성 주장은 슬라이드 상이 아니라 귀하의 환경에서 실제로 입증됩니다. --locked 이 플래그가 여기서 중요한데, 이는 락 파일을 조용히 다시 작성하는 대신 오류를 발생시키기 때문입니다. 캐시를 먼저 지워야만 모든 크레이트를 다시 가져오고 체크섬 검증을 다시 수행하게 됩니다.

전문가 팁: 다음 명령을 사용하여 파일럿을 실행합니다. --locked 그리고 --offline 별도의 단계로. --locked 이는 기존 잠금 파일을 변경 없이 그대로 사용할 수 있음을 보여줍니다. --offline 빌드가 추가적인 네트워크 접속 없이 완료되었음을 확인합니다. crates.io에서 직접 아무것도 가져오지 않았는지 확인하려면, 다음을 신뢰하기보다는 이그레스 로깅이나 방화벽 규칙(4단계 참조)을 사용하십시오. --offline 혼자.

검진을 통해 발견되는 것과 발견되지 않는 것

비공개 화물 등록 시스템은 두 가지 관련 위협에 맞서 그 존재 가치를 입증하고 있으며, 이 두 가지 위협 모두 이름이나 체크섬을 확인하는 것만으로는 해결되지 않습니다.

첫 번째는 사칭으로, 인기 있는 이름과 충분히 유사한 이름으로 크레이트를 공개하여, 오타를 입력하거나 대충 훑어보는 경우 Cargo.toml, 어쨌든 설치하게 됩니다. 두 번째는 ‘인수’로, 수년간 신뢰를 받아온 크레이트가 유지보수자의 사임, 계정 해킹 또는 조용한 소유권 이전을 통해 소유주가 바뀌고, 이후 여러분의 팀이 이미 신뢰하고 있는 이름 아래에서 전혀 다른 내용을 배포하기 시작하는 경우입니다.

두 가지 모두 의존성 트리 어딘가에 존재하는 취약한 코드 줄에 의존하지 않습니다. 둘 다 crates.io의 기본 모델에 의존하는데, 이 모델에서는 누구나 크레이트를 공개할 수 있으며, 이름과 그 이력만으로는 현재 누가 이를 관리하는지 알 수 없습니다.

크레이트가 빌드에 포함되기 전에 수행되는 사전 검사는 바로 이러한 목적을 위한 것입니다. 크레이트는 소스 코드부터 재컴파일되어 알려진 악성코드 패턴 및 의심스러운 동작에 대해 검사되므로, 이름만 보고 신뢰하는 대신 그 자체의 내용을 바탕으로 평가됩니다. 이를 통해 위험 가능성이 상당히 낮아집니다. 이는 모든 악성 크레이트가 반드시 식별된다는 보장은 아니며, 그러한 보장을 내세우는 공급업체는 과대광고를 하고 있는 것입니다.

또한 이는 빌드 내의 어떤 코드도 임의의 코드를 실행하지 않는다는 보장과는 다른 것입니다. 검사는 크레이트가 도착하기 전에 이루어집니다. 일단 크레이트가 빌드 트리에 포함되면, 사용자는 직접 cargo build 예전처럼 잘 작동합니다.

패치된 크레이트가 통합 과정을 어떻게 변화시키는가

또한 이 지점에서 인수 문제는 더 이상 단순한 선별 문제로만 그치지 않게 됩니다. 소유권이 조용히 넘어가는 크레이트는 일회성 탐지 문제가 아닙니다. 이는 지속적인 유지 관리상의 허점이며, 단일 릴리스에 대한 선별만으로는 이 문제를 해결할 수 없습니다.

업스트림에서 더 이상 지원하지 않는 크레이트에 대한 지속적인 패치 작업은 검증과는 별개의 서비스이며, 이를 통해 생성된 크레이트의 내용은 crates.io에 게시된 내용과 의도적으로 다릅니다. 내용이 다르면 체크섬도 달라지며, 소스 대체 기능은 설계상 일치하지 않는 모든 항목을 거부합니다.

따라서 패치 적용은 크레이트별로 명시적으로 동의해야만 가능합니다. 자체 매니페스트에서 선언한 종속성의 경우, 대체 레지스트리 이름을 지정하기만 하면 됩니다.

[dependencies]
abandoned-crate = { version = "1.2.4", registry = "securechain" }

전달적으로만 나타나는 크레이트의 경우, 해당 선언은 아무런 영향도 미치지 않습니다. 왜냐하면 이 선언은 사용자가 명시한 단 하나의 종속성만을 다루기 때문입니다. 최상위 수준의 [patch] 오버라이드는 전이적인 경우를 위해 고안된 메커니즘입니다.

[patch.crates-io]
abandoned-crate = { version = "1.2.4", registry = "securechain" }

그 중에서도 Cargo.toml 매니페스트, Cargo는 다음과 같이 읽습니다 [patch] 작업 공간 루트에 있는 파일에서만 적용되며, 거기서부터 전체 종속성 그래프 전반에 걸쳐 적용됩니다. 또한 다음 위치에 있을 수도 있습니다. .cargo/config.toml, 다만 Cargo의 문서에서는 공유되는 파일의 경우 이를 피하도록 권장하고 있는데, 설정 파일은 대개 버전 관리 시스템에 체크인되지 않기 때문입니다.

따라서 실제 배포의 구체적인 구조는 2계층 형태입니다.

그 표에 드러나지 않은 한 가지 사실은 분명히 밝혀둘 필요가 있습니다. 수정된 크레이트를 선택하면 다음 항목에 기록된 소스 및 체크섬이 변경될 수 있습니다. Cargo.lock, 따라서 락파일이 업데이트되며, 이 업데이트는 다른 의존성 변경 사항과 마찬가지로 커밋되고 검토되어야 합니다. 검증 과정에서는 락파일을 건드리지 않지만, 패치 과정에서는 그렇지 않습니다.

이는 막연한 주장보다 훨씬 더 타당한 설명입니다. 보안 서비스 구매자는 계약서에 서명하기 전에 패치 비용이 얼마인지 확인할 수 있기 때문입니다. 패치를 적용하기로 선택한 각 크레이트에 대해 사소한 변경 사항을 의도적으로 적용해 달라는 요청은 합리적인 요구입니다. 반면, 시범 운영 도중에 모든 매니페스트를 수정해야 한다는 사실을 알게 되는 것은 그렇지 않습니다.

SC Media가 보고한 업계 코드베이스 감사 결과에 따르면, 스캔 대상 코드베이스의 93%에서 지난 2년 동안 개발 활동이 전혀 없었던 구성 요소가 발견되었습니다. 이 그룹 중 진정으로 버려진 코드베이스의 경우, 수정된 릴리스를 제공할 업스트림 유지보수자가 남아 있지 않으며, 백포팅을 하려면 컨텍스트를 처음부터 재구성해야 합니다. 버그를 재현하고, 누구도 의존하고 있는 동작을 변경하지 않는 수정 코드를 작성한 뒤, 현역 유지보수자의 검토나 판단에 의존하지 않고 이를 검증해야 합니다. TuxCare가 SecureChain을 통해 취하는 입장은 업스트림 개발을 대체하기보다는 장기적인 관리에 중점을 두는 것이므로, 두 기능은 서로 다른 방식으로 통합됩니다.

시행하기

4단계로 구성되며, 각 단계에서 증거를 확보한 후에야 다음 단계로 넘어가 범위를 확대하도록 순서가 정해져 있습니다.

3단계에서 이러한 출시 과정이 실제로 차질을 빚게 됩니다. 카고 병합 .cargo/config.toml 현재 디렉터리에서 상위 디렉터리 순으로 파일을 검색한 후, 그렇지 않은 경우 $CARGO_HOME/config.toml, 이 경우 더 깊은 위치에 있는 파일이 우선하며 홈 디렉터리는 최하위 순위를 차지합니다. CI 이미지는 여전히 아무도 예상하지 못한 구성을 포함할 수 있으며, cargo가 호출된 디렉터리에 따라 병합 대상 파일이 결정됩니다. 추측하기보다는 러너에서 실제 적용되는 구성을 직접 확인하십시오.

cargo +nightly -Z unstable-options config get --show-origin source

이 보고서는 실제 소스 구성과 각 값의 출처를 보여줍니다. 노트북보다는 빌드 에이전트에서 이 보고서를 실행하세요. 두 환경은 대개 서로 다르며, 문서화되어 있는 것은 그중 하나뿐이기 때문입니다.

참고: 이 작업에는 매일 밤 실행되는 Cargo가 필요하며, 다음을 포함해야 합니다. -Z unstable-options, 따라서 이를 있는 그대로 안정적인 CI 파이프라인에 반영해서는 안 됩니다.

전문가 팁: 프로덕션 환경으로 전환하기 전에 스테이징 환경에서 4단계를 일주일 동안 운영해 보세요. index.crates.io의 스파스 인덱스와 static.crates.io의 다운로드 기능을 차단하고, 플릿 내의 어떤 구성 요소라도 여전히 git 프로토콜을 사용하는 경우 github.com에 있는 crates.io 인덱스 저장소도 차단해야 합니다. 작동이 중단된 파이프라인은 대개 아무도 몰랐던, 여전히 crates.io에서 직접 데이터를 가져오던 경로들을 드러내게 되는데, 그 목록은 사후 분석 보고서로서보다 문서로서 더 큰 가치가 있습니다.

사설 레지스트리만으로는 한계가 있는 경우

‘검증된 미러링’, 즉 소스 대체는 ‘이 패키지가 정말 같은 패키지인가’라는 문제를 해결합니다. 빌드에 포함되는 크레이트는 lockfile에서 이미 해결된 바로 그 크레이트입니다. 하지만 이 방식은 해당 크레이트가 애초에 신뢰할 만한지 여부는 알려주지 않으며, 바로 이 점을 이름이 유사한 크레이트나 크레이트 탈취 공격이 실제로 악용하는 것입니다.

Rust용 SecureChain은 이 두 가지 측면을 모두 다룹니다. 모든 크레이트는 소스 코드부터 다시 빌드되어 무결성이 검증된 후, 사용자에게 전달되기 전에 악의적이거나 의심스러운 행동이 있는지 검사받습니다. 따라서 타이포스쿼팅이나 인수 공격으로 오염된 릴리스는 이름이나 이력만 보고 신뢰하는 대신, 실제 포함된 내용을 기준으로 판단됩니다.

또한 유지보수자가 활동을 중단한 후에도 스택에 이미 포함된 구성 요소에 대한 패치를 지속적으로 제공하며, 크레이트가 수명 주기의 끝 단계에 도달하면 ‘Endless Lifecycle Support’를 통해 백포트된 수정 사항이 계속해서 제공되므로, 더 이상 관리되지 않는 종속성이 아무도 모르게 패치되지 않은 상태로 방치되는 일이 없습니다.

실제 종속성 트리에 대해 검증 및 패치된 커버리지의 비용을 확인하고 견적을 요청하세요.

자주 묻는 질문

사설 화물 선박 등록부란 무엇인가요?

비공개 카고 레지스트리는 Rust 크레이트를 위한 내부 또는 벤더가 운영하는 대체 레지스트리입니다. 이는 리포지토리에 크레이트를 벤더링하는 방식이나, 카고 소스 대체 기능을 통해 crates.io를 미러링하는 방식과는 구별됩니다. 이러한 방식들은 크레이트의 출처를 각기 다른 방식으로 제어하지만, 카고의 정의에 따라 비공개 레지스트리로서 기능하는 것은 오직 대체 레지스트리뿐입니다.

소스 대체를 통해 crates.io를 미러링하면 Cargo.lock 파일이 손상되나요?

대체 소스 코드가 검증되고 수정되지 않은 크레이트를 제공하는 경우에는 그렇지 않습니다. 내용은 동일하며, 기록된 체크섬은 기존 잠금 파일과 여전히 일치하기 때문입니다. 내용이 수정된 크레이트는 소스 코드 대체 과정을 통해 절대 전달될 수 없습니다.

Cargo에서 소스 대체 기능을 어떻게 설정하나요?

[추가] [source.crates-io] ~로 블록 만들기 replace-with 명명된 소스를 지정한 다음, 해당 소스를 레지스트리 인덱스 URL로 정의하십시오. 이 두 가지는 모두 .cargo/config.toml. 변경 사항 없음 Cargo.toml 또는 Cargo.lock 이 필요합니다.

소스 대체 기능을 통해 타이포스쿼팅되거나 탈취된 크레이트를 감지할 수 있나요?

소스 교체만으로는 충분하지 않습니다. 이 기능의 역할은 크레이트의 내용은 그대로 유지한 채 Cargo를 동등한 소스로 리디렉션하는 것입니다. 이름이 유사한 크레이트나 소유주가 변경된 크레이트를 식별하는 것은 선별 기능으로, 크레이트가 처음 재구축될 때와 새 버전이 공개될 때마다 평가되며, 리디렉션 메커니즘의 속성은 아닙니다.

패치된 크레이트는 Cargo에서 어떻게 작동하나요?

패치된 크레이트의 내용은 crates.io에 게시된 내용과 다르므로, 소스 대체 방식을 통해 전달할 수 없습니다. 직접 의존성은 대체 레지스트리를 가리킬 수 있는 반면, 최상위 [patch] 오버라이드는 전이적 사용 사례를 포함하여 의존성 그래프 전반에 걸쳐 패치된 사본으로 대체합니다. 어느 쪽이든 잠금 파일에는 해당 변경 사항이 기록됩니다.

호환성 주장을 직접 확인하려면 어떻게 해야 하나요?

지우기 ~/.cargo/registry, 그런 다음 다음을 실행합니다. cargo build --locked. 변경되지 않은 잠금 파일을 대상으로 캐시를 지우고 빌드를 성공적으로 수행하면, 대체 소스 코드가 잠긴 종속성 세트와 호환되며 다운로드된 패키지가 Cargo가 기대하는 체크섬 조건을 충족함을 알 수 있습니다. 다음 명령을 실행하면 cargo build --offline 이후에는 추가적인 네트워크 접속 없이 빌드가 완료되었음을 확인해 주지만, 이미 캐시된 데이터의 출처는 확인하지 않으므로, 이를 확인하려면 출력 로깅이나 방화벽 규칙을 사용해야 합니다.

요약

기사 이름

개인 화물 등록 옵션 및 검증된 크레이트 배송

설명

개인 화물 등록부가 벤더링 및 미러링과 어떻게 다른지, 그리고 크레이트에 패치가 적용될 때 Cargo.lock 파일에 실제로 어떤 변화가 일어나는지.

작성자

아르템 카라세프

게시자 이름

TuxCare

게시자 로고