Rust의 기본 보안 도구에는 공격자들이 이미 파악하고 있는 취약점이 존재한다

주요 내용

• 화물 감사 시스템은 이미 누군가가 제출한 주의보에 대해서만 파악하고 있습니다.
• 빌드 스크립트와 proc 매크로는 컴파일 시점에 임의의 코드를 실행하며, 안정판 Cargo에서는 이 기능을 비활성화할 수 없습니다.
• 버려진 상자에는 유효기간이 없으므로, 만료되는 항목은 없으며 누군가가 이를 신고해야만 경고가 표시됩니다.
• 자문 공지가 패치된 버전 없이 배포될 경우, 해당 수정 작업은 사용자의 몫이 됩니다.

Rust 개발팀은 의존성 보안에 본격적으로 나서게 되는데, 첫 번째 조치는 거의 항상 똑같습니다. cargo audit를 설치하고, CI에 연동한 뒤, 테스트가 통과되는 것을 확인하고, 마음이 놓입니다.

좋은 조치입니다. 하지만 화물 감사는 대부분의 팀이 생각하는 것보다 더 좁은 범위의 질문에 답을 제공합니다. 그 내용은 다음과 같습니다. Cargo.lock 그리고 어떤 크레이트에 대해 보안 권고 사항이 등록되어 있는지 알려줍니다. 하지만 이는 컴파일하려는 코드가 컴파일해도 안전한지 여부를 아는 것과는 다릅니다.

Rust의 툴셋은 언어 커뮤니티가 우선시한 요소들을 탄탄하게 갖추고 있습니다. 재현 가능한 빌드, 불변 버전, 체크섬이 적용된 잠금 파일 등이 바로 그것입니다. 부족한 부분은 부주의 때문이 아닙니다. 이는 툴체인이 적대적인 의존성이 아닌 정직한 의존성을 위해 구축되었을 때 자연스럽게 나타나는 현상입니다.

화물 감사를 통해 실제로 확인하는 사항

비록 이 도구에 더 많은 공로가 인정되기는 하지만, 세 가지가 있습니다.

이 도구는 사용자의 잠금 파일(lockfile)에 있는 크레이트를 RustSec 권고 사항 데이터베이스와 대조하여 확인합니다. 더 이상 사용되지 않는 버전을 표시해 줍니다. 또한 정보성 권고 사항을 표시해 주는데, 이는 대부분의 패키지 관리자가 아예 생략하는 부분을 Rust가 처리해 주는 부분입니다.

cargo install cargo-audit --locked
cargo audit

RustSec은 조사 결과를 여러 범주로 분류하는데, 취약점이 아닌 세 가지 유형은 대부분의 팀이 예상하는 것보다 실질적인 중요도가 더 높습니다.

어떤 정보 범주도 단독으로 실행 시 오류가 발생하지 않기 때문에, 단순한 카고 감사(cargo audit)만 실행하는 CI 작업은 트리 내에 유지보수가 중단된 크레이트가 그대로 남아 있어도 정상(green)으로 표시됩니다. 이는 대개 팀들이 바로 잡아내고 있다고 믿는 바로 그 문제입니다.

cargo audit --deny warnings

그러면 상황이 달라집니다. 특정 유형의 발견 사항만 강조하고 나머지는 제외하고 싶다면, ‘유지보수되지 않음’, ‘결함 있음’, ‘제거됨’과 같이 더 좁은 범주의 항목을 제외할 수도 있습니다. 성숙한 프로젝트에서 처음 이 작업을 수행할 때는 논란이 거세질 것으로 예상됩니다.

'unmaintained' 태그는 누군가가 이를 등록해야만 존재합니다. 유지보수자가 2023년에 조용히 커밋을 중단하고 아무런 공지조차 하지 않은 크레이트의 경우, 관련 공지는 전혀 생성되지 않습니다. cargo audit을 정상적으로 실행한다고 해서, 의존성 프로젝트에 여전히 관리자가 있는지 여부는 알 수 없습니다.

각 Rust 보안 도구가 다루는 범위

이 도구는 기능 수보다 더 중요한 두 가지 기준에 따라 구분됩니다. 바로 ‘사람이 실제로 코드를 검토해야 하는지’와 ‘빌드를 중지시킬 수 있는지’ 여부입니다.

cargo deny는 실제로 제공하는 기능에 비해 충분히 활용되지 못하고 있는 도구입니다. 이 도구는 cargo audit과 동일한 RustSec 권고 사항을 다루며, 라이선스 및 차단 정책을 추가하고, 허용 목록을 설정하여 사용자가 승인하지 않은 레지스트리의 크레이트가 몰래 유입되는 것을 방지합니다. 현재 버전은 취약점 및 공지 권고 사항에 대한 검사를 통과하지 못하며, 트리 내 어디에서든 유지보수가 중단된 크레이트에 대해서는 기본적으로 실패로 처리하고, 직접 의존성에 포함된 부적절한 권고 사항에 대해서도 실패로 처리합니다. 이는 대부분의 팀이 처음부터 원했던 동작입니다.

cargo auditable은 또 다른 문제를 해결합니다. Rust 바이너리가 컴파일되면 정확한 의존성 목록을 복원하는 것은 신뢰할 수 없습니다. cargo audit bin은 패닉 메시지를 파싱하여 이를 부분적으로 재구성할 수 있으며, 이 도구의 문서에서는 그 한계에 대해 놀라울 정도로 솔직하게 밝히고 있습니다. 임베디드 C 코드는 이 도구에 감지되지 않으며, 컴파일러가 절대 발생하지 않을 패닉을 제거하는 데 매우 능숙하기 때문에 Rust 의존성의 약 절반이 누락됩니다. 빌드 시점에 실제 목록을 포함시키면 이 문제를 해결할 수 있으며, 빌드 명령어에 단 한 단어만 추가하면 됩니다.

실행 cargo tree --duplicates 현재 진행 중인 어떤 감사 작업이든 간에. 하나의 소스 트리 내에 동일한 크레이트의 여러 버전이 존재하면, 한 의존성 경로를 업그레이드하더라도 바이너리에 이전 버전이 여전히 컴파일되어 남아 있을 수 있기 때문에 문제 해결이 겉보기보다 훨씬 복잡해집니다.

첫 번째 격차는 타이밍이다

해당 테이블에 나열된 모든 도구는 Cargo가 이미 해결한 의존성 그래프를 기반으로 작동합니다. 이 도구들은 빌드를 실패하게 하거나 릴리스를 차단할 수 있습니다. 하지만 이 도구들 중 어느 것도 애초에 크레이트가 해결된 그래프에 포함되지 않도록 막아주지는 않습니다.

대부분의 종속성 문제의 경우, 이 정도면 충분합니다. 알려진 취약점이 있는 크레이트는 10분이 지나도 여전히 취약한 상태이며, CI 단계에서 이를 포착하는 것만으로도 충분히 빠른 대응입니다.

악성 코드의 경우, 타임라인상 잘못된 위치에 해당합니다. Rust는 컴파일 과정에서 신뢰할 수 없는 코드를 실행하기 때문입니다. 빌드 스크립트는 cargo build. 절차적 매크로는 컴파일러 내부에서 실행됩니다. 두 매크로 모두 Cargo로부터 샌드박스를 할당받지 않으므로, 빌드를 시작한 사용자의 권한으로 실행되며, 파일 시스템과 네트워크에 접근할 수 있을 뿐만 아니라 빌드 환경이 보유하고 있는 모든 인증 정보에도 접근할 수 있습니다.

Stable Cargo에는 두 기능 중 하나를 비활성화할 수 있는 플래그가 없습니다.

cargo vendor vendored/
find vendored/ -name build.rs | wc -l

실제 프로젝트에서 이 방법을 적용해 보세요. 트리 내에 수백 개의 크레이트가 있는 중규모 서비스라면 빌드 스크립트가 수십 개는 쉽게 나올 수 있는데, 타깃을 위해 실제로 빌드되는 크레이트에 속한 스크립트는 모두 클린 빌드에서 실행됩니다. 팀원 중 그 스크립트를 하나라도 읽어본 사람은 아마 없을 겁니다.

이건 가정이 아닙니다. 2026년 5월, 연구자들은 TrapDoor 캠페인 다음과 같은 상자들을 발견했다. sui-framework-helpers 그리고 move-compiler-tools Sui 및 Move 개발자를 대상으로 합니다. 이들의 build.rs 스크립트는 프로젝트가 컴파일되는 즉시 로컬 지갑 키스토어를 찾아, 발견한 내용을 GitHub Gists에 업로드했습니다. 설치 후크도, 임포트도 없이, 그저 cargo build 설계된 대로 정확히 작동하고 있다.

Rust에는 그런 것이 전혀 없습니다 npm install --ignore-scripts. 크레이트를 컴파일하기 전에 소스 코드를 읽어볼 수 있으며, 민감한 내용이 있다면 반드시 그렇게 해야 합니다. 안정판 Cargo는 종속성 빌드 스크립트와 proc 매크로를 건너뛰고 일반 빌드를 실행하지 않으므로, “감사 후 컴파일”은 플래그로 설정할 수 있는 기능이 아니라 수동으로 수행해야 하는 작업으로 남아 있습니다.

크레이트가 개발자에게 전달되기 전에 이를 검사하고, 통제된 환경에서 검증된 소스 코드를 기반으로 크레이트를 빌드하는 것은 컴파일 시점 실행보다 더 이른 단계에서 이루어지는 몇 안 되는 제어 수단 중 하나입니다. SecureChain for Rust는 이미 가져온 트리 구조에 또 다른 처리 단계를 추가하는 대신, 바로 이러한 시기적 문제를 해결하기 위해 설계되었습니다.

두 번째 문제점은 아무도 패치를 적용하지 않는다는 점이다

RustSec은 취약점을 기록합니다. 취약점을 수정하지는 않습니다.

그 차이는 눈앞에 놓인 보안 권고 사항에 패치된 버전이 없을 때까지는 이론적인 수준에 그칩니다. 그때가 되면 그게 바로 문제의 전부이며, 해결 방안은 순식간에 좁아집니다.

그 규모도 계속 늘어나고 있습니다. RustSec에는 2025년 공개 예정일자가 표기된 170건의 보안 권고문이 등록되어 있으며, 2026년 공개 예정일자가 표기된 권고문은 지난 5월에 이미 그 수를 넘어섰고, 8월 중순에는 257건에 달했습니다. 이는 4년 연속으로 건수가 증가한 것으로, 올해 등록된 항목 중 약 160건은 취약점으로 분류되었고, 나머지는 유지보수가 중단된 항목과 타당하지 않은 발견 사항으로 나뉘었습니다. 이러한 수치는 사후에도 서서히 증가하는 경향을 보이는데, 이는 오래된 공개 사항에 대한 권고문이 몇 달 뒤에도 계속 등록되기 때문입니다. 이는 프로젝트의 건전성을 보여주는 지표입니다. 하지만 데이터를 활용하는 이들에게는 운영 부담이 커지는 요인이기도 합니다. 업스트림에서 패치되지 않는 트리에 대한 발견 사항이 늘어날수록, 버전만 올리는 것으로 해결할 수 없는 문제가 더 많아지기 때문입니다.

Rust는 기존 사용자들도 만족시키고 있습니다. 개발자들은 스택 오버플로우(Stack Overflow)의 2025년 개발자 설문조사에서 다시 한번 Rust를 가장 ‘존경받는’ 언어로 꼽았으며, 지지율은 72%를 기록했습니다. 다만 ‘존경받는’이라는 지표는 채택 속도가 얼마나 빠르게 증가하고 있는지가 아니라, 현재 사용자 중 얼마나 많은 사람이 계속 사용하고 싶어 하는지를 나타내는 것입니다. 어쨌든, 현재 많은 기업에서 ‘권고 사항’만 있고 수정 패치가 없는 크레이트에 대해 어떻게 처리해야 할지에 대한 확립된 지침 없이도 프로덕션 환경에서 Rust를 운영하고 있습니다.

패치된 버전이 없을 때는 어떤 선택지든 곤란합니다. 크레이트를 포크한 뒤 수정 사항을 적용하고 자신의 이름으로 유지 관리할 수 있습니다. 의존성을 교체할 수도 있는데, 이는 대개 해당 의존성을 사용하던 코드를 다시 작성해야 함을 의미합니다. 또는 다음을 통해 로컬에서 패치를 적용할 수도 있습니다. [patch.crates-io] 그리고 해당 패치를 무기한으로 소유하게 됩니다. 상쇄 통제 조치를 문서화하고 위험을 수용할 수도 있습니다. 아니면, 상류 코드에 남겨진 수정 사항을 백포트하는 것을 주 업무로 하는 사람을 영입할 수도 있습니다.

유지보수자가 더 이상 관여하지 않는 버전에 보안 수정 사항을 역이식하는 것은 새로운 기능을 개발하는 것과는 다른 접근 방식입니다. 여기에는 회귀 테스트, 호환성 검증, 그리고 동작을 변경하지 않겠다는 신중한 결심이 필요하며, 이는 업스트림 개발이 추구하는 방향과는 대략적으로 정반대입니다.

세 번째 격차는 공식적으로 은퇴하지 않는 크레이트들입니다

PHP는 지원 종료( EOL) 일정을 공개합니다. Node.js도 자체 일정에 따라 이를 공개합니다. 반면, 2019년에 한 사람이 올린 크레이트는 애초에 지원 종료에 대한 약속이 없었기 때문에 아무런 정보도 공개하지 않습니다.

다음 주소의 등록부: crates.io 이는 한 가지 특정 측면에서 상황을 더 까다롭게 만듭니다. 공개된 버전은 사실상 불변입니다. 삭제는 다운로드 횟수가 거의 없고 의존하는 크레이트도 없는 크레이트에 한해 아주 짧은 기간 동안만 가능하므로, 크레이트를 제거하는 것이 실질적인 해결책입니다. 이러한 불변성은 태그를 변경할 수 있도록 허용하는 레지스트리와 비교할 때 진정한 보안상의 강점입니다. 또한 이는 버려진 크레이트도 계속 설치 가능하고, 정상적으로 해결되며, 아무런 흔적도 남기지 않는다는 것을 의미합니다. Cargo.lock 이 프로젝트의 관리자가 3년 전에 손을 뗐음을 시사한다.

이를 알려줄 신호를 종합해 주는 도구는 없으므로, 이 부분은 여전히 수작업으로 처리해야 합니다. 마지막 릴리스 날짜와 미해결 이슈 수를 비교해 보세요. GitHub 저장소가 아카이브 처리되었는지 확인하세요. Cargo는 이 사실을 절대 언급하지 않습니다. crates.io 페이지에 나열된 소유자 수를 세어보세요. 소유자가 한 명뿐이라면 ‘버스 팩터’가 1이 되기 때문입니다. 또한 해당 크레이트가 빌드 종속성인지, 아니면 proc 매크로인지 확인하세요. 이 둘은 유지보수가 얼마나 잘 되어 있든 상관없이 컴파일 시점에 실행되기 때문입니다.

실행 cargo owner --list <crate> 트리 내의 보안 관련 요소에 대해. 프로덕션 바이너리로 컴파일되는 크레이트의 소유자가 한 명뿐인 경우, 이는 공급망 위험에 해당하며, 단순히 권고 사항 대조만으로는 이를 파악할 수 없습니다.

어떤 결과가 실제로 중요한지 파악하려면 그런 맥락이 필요합니다. 유지보수 상태, 수정 패치가 있는지 여부, 크레이트가 빌드 경로에 포함되어 있는지 아니면 개발 의존성(dev-dependencies)에만 있는지 등입니다. Advisory 매칭 기능으로는 이러한 정보를 전혀 제공하지 않기 때문에, 팀들은 실제 노출 위험을 기준으로 삼지 못하고 RUSTSEC ID를 기준으로 우선순위를 정하게 됩니다.

화물 검증 서비스가 도움이 되는 부분과 한계가 있는 부분

cargo vet는 다른 접근 방식을 취하며, 지금까지의 채택률보다 더 널리 사용될 가치가 있습니다. 이 도구는 보안 권고 사항을 대조하는 대신, 자체 팀이 수행한 감사와 감사 결과를 공개하는 기관에서 가져온 감사를 활용하여 의존성 그래프 전반에 걸쳐 감사 기준을 적용합니다.

cargo vet init
cargo vet suggest

시작하기 전에 알아두면 좋은 점: cargo vet init 의도적으로 트리 내에 이미 존재하는 모든 요소를 제외함으로써, 채택 과정에서 첫날부터 CI가 중단되는 상황을 방지합니다. 백로그는 다음을 통해 드러납니다. cargo vet suggest, 그리고 팀이 감당할 수 있는 속도에 맞춰 면제 조치를 실제 감사로 대체합니다. 대규모 조직의 감사 결과를 가져오면, 팀 구성원이 직접 코드를 검토하지 않아도 미처리 업무의 상당 부분을 처리할 수 있습니다.

이러한 한계는 구조적인 문제입니다. 적용 범위는 사용자가 실제로 의존하고 있는 버전에 대해 누군가가 감사를 수행했는지에 달려 있으며, 이미 가져온 감사 결과나 면제 조항이 적용되지 않는 한 새로운 릴리스에는 새로운 증거가 필요합니다. 델타 감사는 일반적으로 처음부터 다시 시작하는 것이 아니라 이미 승인된 버전과의 차이점(diff)을 검토하기 때문에 관리하기 쉽습니다. 또한, 사람이 수행하는 감사는 코드 품질과 의도에 대한 판단일 뿐, 보장을 의미하지는 않습니다. 검토자들도 특히 난독화된 빌드 스크립트의 경우 놓치는 부분이 있습니다.

위임된 신뢰라도 신뢰가 전혀 없는 것보다는 낫습니다. 다만 커버리지 곡선이 존재할 뿐이며, 그 곡선은 새 크레이트나 잘 알려지지 않은 크레이트가 위치한 지점에서 가장 얇아지는데, 바로 그곳이 악의적인 패키지가 주로 나타나는 곳이기도 합니다.

CI에서 실제로 실행해야 할 것

모든 것을 한꺼번에 설치하기보다는 프로젝트의 진행 상황에 따라 선택하십시오.

오늘 준비된 것이 없으니, 다음부터 시작해 보세요. cargo deny check advisories sources. 이 도구는 RustSec 권고 사항을 모두 다루며, 한 번의 단계로 소스 허용 목록을 추가하고, 핵심 권고 사항 범주를 기본적으로 빌드 중단 오류로 처리합니다.

화물 감사가 이미 진행 중이라면 다음을 추가하십시오. --deny warnings 유지보수가 제대로 이루어지지 않았거나 신뢰할 수 없는 검사 결과가 더 이상 조용히 통과되지 않도록 한 다음, 생성된 목록을 해당 크레이트가 빌드 경로에 포함되어 있는지 여부에 따라 우선순위를 정하십시오.

고객에게 바이너리를 배포하거나 규제 대상 환경으로 배포하는 경우, ‘cargo auditable’ 옵션을 추가하여 배포한 아티팩트에 자체 의존성 목록이 포함되도록 하세요. 나중에 이를 재구성하는 일은 번거로울 뿐만 아니라 정보도 불완전해집니다.

빌드 에이전트에 클라우드 인증 정보나 서명 키가 저장되어 있는 경우, 컴파일 시 실행을 주요 위험 요인으로 간주하고 해당 인증 정보의 유효 기간을 단축해야 합니다. 빌드가 시작되면 자체 코드가 실행되기 전에 종속성 빌드 스크립트가 먼저 실행될 수 있기 때문입니다.

만약 위협 모델상 컴파일 시점에서의 실행이 허용되지 않는다면, Cargo만으로는 그 경계를 강제할 수 없습니다. 이 제어는 크레이트 해결 단계보다 더 앞선 단계, 즉 크레이트가 빌드 단계에 도달하기 전의 선별 및 재빌드 단계로 옮겨가거나, 코드가 악의적이라고 가정하는 격리된 빌드 환경으로 옮겨져야 합니다.

결과는 트리 구조에 따라 달라질 수 있습니다. 직접 의존성이 40개이고 proc-macro를 많이 사용하는 프레임워크가 없는 프로젝트라면 감사가 비교적 수월합니다. 반면, 비동기 런타임, 직렬화, 웹 프레임워크를 포함하는 서비스의 경우, 수백 개에 달하는 전이적 크레이트와 수많은 컴파일 타임 실행 지점이 발생할 수 있으며, 이 두 가지 사례를 동일하게 취급하는 조언은 두 번째 사례에 대해 ‘cargo tree’ 명령어를 실행해 본 적이 없는 사람이 한 말입니다.

Rust용 SecureChain의 적용 분야

위에서 언급한 모든 내용은 취약점을 찾아내는 것이지, 이를 해결하는 것이 아닙니다. `cargo audit`은 이미 문제가 표시된 부분을 알려주고, `cargo vet`은 이미 누군가가 검토한 부분을 알려줍니다. 두 도구 모두 해당 크레이트를 확인하기 전에 악성 코드가 실행되는 경우에는 아무런 조치를 취하지 않으며, 업스트림 패치가 없는 보안 권고 사항에 대한 수정 사항도 제공하지 않습니다.

바로 이것이 Rust용 SecureChain이 구축된 목적입니다. 이 솔루션은 격리된 환경에서 소스 코드를 기반으로 크레이트를 재컴파일하고, 설치 시 악성코드 및 의심스러운 패턴을 검사하며, 새로운 CVE가 발견될 때마다 SLA에 따라 지속적으로 패치를 적용합니다. 업스트림 유지보수가 종료되면 ‘Endless Lifecycle Support’가 해당 크레이트를 인수하여, 해당 크레이트가 사용자의 스택에 남아 있는 한 계속해서 수정 사항을 제공하므로, 더 이상 유지보수되지 않는 종속성이 사용자의 소스 트리에서 패치가 적용되지 않은 상태로 방치되는 일이 결코 없습니다.

전이적 종속성 속에 숨겨진 문제를 미리 파악하고자 한다면, TuxCare의 ‘종속성 빙산’ 웨비나를 통해 대시보드가 깨끗해 보일 때조차 눈에 띄지 않는 종속성 체인을 통해 CVE가 어떻게 전파되는지 더 깊이 알아볼 수 있습니다.

자주 묻는 질문

화물 감사는 어떤 역할을 하나요?

이 기능은 사용자의 Cargo.lock RustSec 권고 사항 데이터베이스와 대조하여 취약점, 사용 중단된 버전, 유지보수가 중단되었거나 안전하지 않은 크레이트에 대한 정보성 권고 사항을 보고합니다. 크레이트 소스 코드를 읽지 않으며 설치 과정을 가로채지도 않지만, 종료 상태를 통해 완벽한 CI 게이트 역할을 수행합니다. 실험적인 cargo audit fix 이 하위 명령어는 일부 취약한 종속성 요구 사항을 업데이트할 수 있지만, 이를 이용하려면 수정 기능이 활성화된 상태로 cargo audit을 설치해야 합니다.

유지보수가 제대로 이루어지지 않은 크레이트의 경우 화물 검사가 실패하나요?

기본적으로는 그렇지 않습니다. 별도로 설정하지 않는 한, 유지 관리되지 않는 경고를 포함한 정보성 알림은 경고로 표시됩니다. 다음 명령을 실행하세요. cargo audit --deny warnings 그 부분에서 실패하거나, ‘유지보수되지 않음’과 같은 단일 범주를 배제해 놓고도, 이미 자리 잡은 프로젝트에서 첫 실행이 오래 걸릴 것이라고 기대해서는 안 된다.

화물 감사와 화물 검사의 차이점은 무엇인가요?

화물 감사(cargo audit)는 특정 크레이트에 대해 등록된 권고 사항이 있는지 확인하며, 이 과정에서 사용자에게 별도의 조치가 요구되지 않습니다. 화물 베트(cargo vet)는 사용자가 직접 설정한 감사 기준, 가져온 감사, 델타 감사 및 적용 중인 모든 예외 사항을 바탕으로 의존성 그래프가 감사 기준을 충족하는지 확인합니다. 새로운 버전은 이미 해당 버전을 다루는 항목이 없는 한 새로운 증거가 필요하며, 델타 감사는 일반적으로 이미 감사된 버전과의 차이점만 검토하는 것을 의미합니다.

Cargo가 스크립트 실행을 차단할 수 있나요?

아닙니다. Stable Cargo에는 빌드 스크립트나 절차적 매크로를 비활성화할 수 있는 지원되는 플래그가 없습니다. 이 둘 모두 컴파일 중에 임의의 코드를 실행하며, 빌드 환경에 포함된 모든 요소에 접근할 수 있습니다.

의존성 트리에서 사용되지 않는 크레이트를 어떻게 찾을 수 있나요?

이를 위한 단일 명령어는 없습니다. 다음을 실행하세요. cargo audit --deny warnings 관리되지 않는 보안 권고 사항을 파악하려면, 마지막 공개 날짜, 저장소가 아카이브 처리되었는지 여부, 소유자 수 등을 다음을 통해 확인하십시오. cargo owner --list 보안과 관련된 모든 사항에 대해.

RustSec 권고 사항에 패치된 버전이 없을 경우 어떻게 되나요?

이 문제를 자동으로 해결해 주는 방법은 없습니다. 크레이트를 포크하여 수정하고, 종속성을 교체한 뒤, 다음을 통해 로컬 패치를 적용해야 합니다. [patch.crates-io] 그리고 이를 유지 관리하거나, 보완 통제 수단을 문서화하거나, 업스트림 유지 관리자가 더 이상 유지 관리를 중단한 크레이트에 대한 수정 사항을 역포트해 주는 벤더를 영입할 수 있습니다.