악성 패키지가 운영 환경에 접근하는 것을 방지하십시오.

---

개발자는 의심스러운 코드를 한 줄도 작성하지 않고도 프로젝트에 악성 코드를 삽입할 수 있습니다. 단순히 패키지를 설치하는 것만으로도 충분할 수 있습니다. 해당 종속성이 정상적인 것처럼 보이고 익숙한 이름을 가지고 있더라도 설치 과정에서 원치 않는 코드를 실행할 수 있습니다.

이로 인해 패키지 보안은 애플리케이션이 프로덕션 환경에 배포되기 훨씬 전부터 문제가 됩니다. 첫 번째 심각한 사고는 Windows 개발자의 업무용 컴퓨터 , CI 실행 환경 또는 자동 빌드 프로세스 중에 발생할 수 있습니다. 배포 단계 직전에만 보안 제어를 배치하면 이러한 경로의 상당 부분이 노출됩니다.

위험은 개발자의 기기에서 시작됩니다.

현대 프로젝트는 방대한 의존성 트리에 의존합니다. 개발자가 의도적으로 10개의 패키지를 설치하더라도 패키지 관리자는 자동으로 수백 개의 간접 의존성 패키지를 가져옵니다. 이 연결 고리 내의 각 패키지를 일일이 검토하는 사람은 거의 없으며, 이를 수동으로 처리한다면 일반적인 개발 과정이 느리고 지루해질 것입니다.

공격자들은 이러한 신뢰를 악용합니다. 일부 악성 패키지는 환경 변수, 자격 증명, 브라우저 데이터 또는 인증 토큰을 훔치려고 시도합니다. 다른 패키지는 개발자가 패키지를 열기도 전에 설치 스크립트를 통해 추가 페이로드를 다운로드하거나 코드를 실행합니다.

Windows 시스템에서 영향을 받는 환경에는 PowerShell 세션, 패키지 관리자 자격 증명, SSH 키, 클라우드 도구 및 현재 사용자 계정에서 사용 가능한 파일이 포함될 수 있습니다. WSL은 근본적인 공급망 위험을 제거하는 대신 동일한 시스템에 추가 개발 환경을 추가합니다.

해로운 의존성이 항상 나쁜 것처럼 보이는 것은 아닙니다.

번들 공격은 악성 구성 요소가 개발자가 예상하는 것과 유사할 때 탐지하기 어렵습니다. 이러한 침입 경로는 다양합니다.

• 타이포스쿼팅: 해당 패키지는 일반적인 종속 패키지와 한두 글자만 다른 이름을 사용합니다.
• 의존성 혼동: 일반 패키지가 내부 종속성과 충돌하여 자동 빌드 프로세스에 의해 선택될 수 있습니다.
• 해킹당한 관리자 계정: 공격자가 배포 권한을 획득한 후, 신뢰받던 패키지가 악성 버전을 수신합니다.
• 악의적인 업데이트: 이전에는 안전했던 프로젝트가 이후 버전에서 동작 방식이 변경되어 문제가 발생할 수 있습니다. 일부 직종은 더 이상 운영되지 않습니다.؛
• 숨겨진 일시적인 결과: 위험한 코드는 개발자가 선택한 패키지보다 여러 단계 아래에 삽입되어 있습니다.

인기가 곧 안전을 보장하는 것은 아닙니다. 악성 프로젝트라도 이전의 안전한 릴리스 덕분에 수년간 좋은 평판을 유지할 수 있는 반면, 새로운 악성 패키지는 의심스러운 행위가 감지되기 ​​전에 많은 다운로드 수를 기록할 수도 있습니다.

검사가 늦어지면 너무 늦을 수 있습니다.

많은 팀들이 이미 의존성 검사를 수행하고 있으며, 이는 여전히 매우 중요합니다. 소프트웨어 구성 요소 분석을 통해 알려진 취약점을 식별할 수 있습니다. 저장소 스캔 도구는 노출된 비밀 정보나 위험한 코드를 찾아낼 수 있습니다. 지속적 무결성 보안(CI) 검사는 문제가 있는 릴리스의 배포를 방지합니다.

하지만 이러한 통제 조치가 무엇을 예방할 수 있는지를 결정하는 데에는 시기가 매우 중요한 역할을 합니다.

개발자가 Windows 터미널에서 설치 명령을 실행했는데 요청된 패키지에 악성 설치 스크립트가 포함되어 있는 경우, 첫 번째 중요한 지속적 무결성(CI) 검사가 수행되기 전에 해당 코드가 로컬에서 실행될 수 있습니다. 깨끗한 프로덕션 환경을 갖추고 있다고 해서 빌드가 시작된 시스템에서 자격 증명이 탈취될 가능성이 완전히 사라지는 것은 아닙니다.

알려진 취약점을 검색하는 것은 완전히 다른 질문에 대한 답을 제공합니다. 알려진 보안 문제 와 관련된 버전을 찾는 데는 효과적이지만 , 새로 배포된 악성 패키지는 아직 CVE 또는 문서화된 취약점 기록이 없을 수도 있습니다.

소포를 통과시키기 전에 검사합니다.

한 가지 방법은 개발자 또는 빌드 시스템과 패키지 레지스트리 사이에 제어 메커니즘을 구현하는 것입니다. 요청된 모든 패키지를 환경에 직접 허용하는 대신, 제어 메커니즘이 먼저 패키지를 평가하고 의심스러운 기준을 충족하는 소프트웨어를 차단할 수 있습니다.

이것이 바로 의존성 방화벽 개념의 기본 아이디어입니다.

핵심은 결정 시점입니다. 패키지는 설치 전에 평가할 수 있으며, 환경에 이미 도입된 후에 문제가 발견되는 것을 방지할 수 있습니다. 의심스러운 배포 패턴, 기존 패키지를 모방하여 새로 생성된 패키지 또는 추가 조사가 필요한 기타 동작 등이 문제 징후로 작용할 수 있습니다.

하지만 그렇다고 해서 제어 메커니즘이 완벽하다는 의미는 아닙니다. 오탐지 또한 중요한 문제입니다. 새로 출시된 패키지가 정상적인 것일 수도 있고, 비정상적인 배포 활동이 반드시 악의적인 것은 아닙니다. 패키지 검사로 인해 정상적인 업데이트가 지속적으로 중단된다면 개발자들은 이를 우회하는 방법을 찾기 시작할 수 있습니다.

윈도우 개발은 그 자체로 몇 가지 약점을 가지고 있습니다.

Windows 개발 환경에서는 Git, Node.js, Python, PowerShell, Visual Studio Code, Docker Desktop, WSL, 클라우드 명령줄 도구(CLI) 및 로컬에 저장된 자격 증명이 단일 워크스테이션에 함께 설치되는 경우가 많습니다. 따라서 패킷 위험 측면에서 계정 권한 및 로컬 보안이 매우 중요합니다.

몇 가지 간단한 선택만으로 잠재적인 공격 범위를 줄일 수 있습니다.

• 일상적인 개발은 가능한 한 비행정 계정으로 처리하십시오.
• 익숙하지 않은 설치 명령을 관리자 권한으로 실행하지 마십시오.
• 프로덕션 환경 자격 증명과 로컬 개발자 자격 증명을 분리하십시오.
• 설치 또는 설치 후 스크립트를 갑자기 삽입하는 패키지를 확인하십시오.
• 아직 신뢰를 얻지 못한 프로그램에는 격리된 환경을 사용하십시오.

Windows 보안 기능은 운영 체제 수준에서 도움을 줄 수 있지만, 종속성 트리에 있는 각 타사 패키지가 특정 프로젝트에 속하는지 여부를 판단할 수는 없습니다.

Lockfile 파일은 도움이 되지만, 무엇이 안전한지 판단할 수는 없습니다.

락파일은 패키지 버전을 더 예측 가능하게 만들고 설치 간 예기치 않은 변경 사항을 줄여줍니다. 하지만 락파일만으로는 잠긴 버전 자체가 유해한지 여부를 판단할 수는 없습니다.

다른 제어 기능을 단독으로 사용할 때도 동일한 제한 사항이 적용됩니다. 버전 고정은 일관성을 제공합니다. 코드 검토는 개발자가 이미 확인할 수 있는 변경 사항을 감지합니다. 취약점 검사는 알려진 취약점을 찾아냅니다. 엔드포인트 보호는 장치에서의 활동을 모니터링합니다.

팀은 내부 패키지 배포, 더 이상 사용되지 않는 종속성 제거, Lockfile 변경 사항 모니터링, 불필요한 설치 스크립트 제한, 중요한 타사 프로젝트의 소유권 변경 조사 등을 위해 다단계 인증(MFA)을 요청할 수도 있습니다.

가장 견고한 접근 방식은 다계층 방식입니다. 단일 제어 방식으로는 패키지 레지스트리에서 개발자 컴퓨터, 빌드 시스템, 프로덕션 환경에 이르는 전체 경로를 모두 포괄할 수 없습니다.

가능한 한 빨리 배송을 중단하세요.

실제 운영 환경의 보안은 실제 운영 단계에 들어가기 전부터 시작됩니다. 유해한 종속성이 출시된 버전에 나타날 때쯤이면 이미 개발자의 노트북, 패키지 캐시, 빌드 시스템, 그리고 지속적 통합(CI) 인프라를 거쳐 확산되었을 가능성이 높습니다.

패키지 검사를 설치 프로세스에 더 가깝게 이동하면 후속 검사의 필요성을 없애지 않으면서 이러한 위험 시간을 줄일 수 있습니다. Windows 기반 팀의 경우 개발 장치가 소스 코드, 자격 증명, 클라우드 도구 및 내부 시스템과 가까운 곳에 위치하는 경우가 많기 때문에 워크스테이션 보안이 매우 중요합니다.

실질적인 문제는 단일 도구가 모든 패키지의 보안을 보장할 수 있는지 여부가 아니라, 개발 프로세스에서 실행되어서는 안 되는 패키지를 얼마나 빨리 거부할 수 있는지입니다.