공급망 위협

소프트웨어 공급망 공격은 조직을 직접 침해하는 대신, 조직이 신뢰하고 사용하는 것을 오염시켜 조직을 침해합니다. 여기에는 라이브러리, 빌드 도구, 컨테이너 기본 이미지 또는 업데이트 서버가 포함됩니다.

현대 소프트웨어는 수백 개의 타사 구성 요소로 조립되므로, 오염된 연결 하나가 이후의 모든 사용자에게 전달됩니다. 공격자는 한 번 투자해 수많은 피해자에게 도달합니다.

• 신뢰 역전 — 보안 경계가 자체 코드 외부로 이동합니다
• 전이적 피해 범위 — 악성 패키지 하나가 수천 개의 빌드로 흘러갑니다

직접 의존성 하나를 추가하면, 선택하지도 않은 전이적 의존성 수십 개가 함께 들어오는 경우가 많습니다. 일반적인 Node 또는 Python 애플리케이션은 소수의 패키지만 선언하지만, 실제로는 수백 개로 해석됩니다.

매니페스트만이 아니라 전체 해석 결과 트리를 나열하여 실제로 무엇을 배포하는지 확인하십시오:

공격자는 인기 패키지와 비슷한 이름의 악성 패키지를 게시하고, 치명적인 오타가 발생하기를 노립니다.

• 타이포스쿼팅 — requests 대신 reqeusts 사용
• 콤보스쿼팅 — 실제 이름을 흉내 낸 python-requests
• 의존성 혼동 — 내부 비공개 패키지와 같은 이름의 공개 패키지를 게시하여, 잘못 구성된 해석기가 공격자 버전을 가져오게 하는 방식

신뢰할 수 있는 내부 레지스트리를 고정하고, 범위 지정 또는 네임스페이스 지정 비공개 패키지를 사용하여 방어하십시오.

합법적이고 널리 신뢰받는 패키지도 유지 관리자 계정이 침해되거나 악의적인 기여자가 게시 권한을 얻으면 악성으로 바뀔 수 있습니다.

최근 실제 사건에서는 공격자가 유지 관리자의 자격 증명을 피싱한 뒤, 설치 중 토큰을 빼돌리는 오염된 패치 버전을 배포했습니다.

• 모든 게시 계정에 2단계 인증을 요구합니다
• 범위가 지정된 게시 토큰과 보호된 출시 절차를 사용하는 패키지를 우선합니다
• 중요한 의존성에 예상치 못한 새 유지 관리자가 추가되는지 확인합니다

많은 생태계는 애플리케이션이 실행되기도 전에 설치 시점에 코드를 실행합니다. npm install은 환경 변수나 SSH 키를 훔치는 postinstall 후처리 작업을 실행할 수 있습니다.

지속적 통합 환경에서는 임의의 설치 스크립트를 비활성화하고, 설치 스크립트가 필요한 패키지는 감사하십시오:

빌드 환경 자체가 가치 높은 공격 대상입니다. 공격자가 컴파일러, 지속적 통합 실행기 이미지 또는 빌드 플러그인을 오염시키면 소스 코드가 깨끗하더라도 해당 환경이 생성하는 모든 결과물에 백도어가 심깁니다.

대표적인 사례는 트로이 목마화된 업데이트 메커니즘입니다. 이 메커니즘은 합법적인 코드 서명 키로 악성 코드에 서명하므로 피해자는 이를 진짜로 받아들입니다.

• 빌드 인프라를 철저히 보안 강화한 운영 환경으로 취급합니다
• 일시적이고 재현 가능한 빌드 실행기를 사용합니다
• 서명 키를 빌드 호스트와 분리합니다

잠금 파일은 정확한 버전과 콘텐츠 해시를 고정하므로, 의존성을 다시 해석해도 다른 결과물이 몰래 바뀌어 들어오는 것을 막습니다. 항상 저장소에 커밋하고, 자유롭게 다시 해석하는 대신 지속적 통합 환경에서 이를 검증하도록 하십시오.

무결성 필드에는 해시가 저장됩니다. 다운로드한 tar 아카이브가 일치하지 않으면 설치가 실패합니다.

알려진 취약 버전(CVE로 추적되는 버전)은 가장 흔한 공급망 약점입니다. 소프트웨어 구성 분석(SCA) 도구는 해석된 의존성을 취약점 데이터베이스와 대조합니다.

지속적 통합 환경에서 검사를 실행하고 심각한 발견 사항이 있으면 빌드를 실패 처리하십시오:

유동적인 버전 범위(^1.2.0)를 사용하면 새 버전이 자동으로 들어옵니다. 편리하지만 악성 패치에 노출될 수 있습니다.

• 정확한 버전으로 고정하고 업그레이드를 신중하게 검토합니다
• 컨테이너 이미지는 latest 같은 변경 가능한 태그가 아니라 다이제스트로 고정합니다
• 중요한 의존성을 자체 저장소 또는 미러에 직접 포함하여, 상위 저장소의 삭제로 인해 문제가 발생하거나 오염되지 않도록 합니다

공급망 보안은 한 번 검사하고 끝나는 일이 아니라 지속적으로 수행해야 합니다. 무엇을 배포하는지, 어디서 왔는지, 언제 취약해지는지를 알아야 합니다.

• 모든 출시 버전에 대해 SBOM을 생성합니다(다음 수업)
• 빌드 출처 정보를 수집하여 결과물이 어떻게 생성되었는지 입증할 수 있게 합니다
• 보안 권고를 구독하여 새로 공개된 CVE가 이미 배포한 빌드를 다시 평가하도록 합니다

신뢰할 수 없는 입력이 들어오는 모든 단계를 매핑하십시오. 개발자 컴퓨터, 소스 코드 관리, 의존성 레지스트리, 빌드 시스템, 결과물 저장소 및 업데이트 경로가 여기에 포함됩니다. 각각이 잠재적인 주입 지점입니다.

각 단계마다 다음을 질문하십시오. 누가 여기에 쓸 수 있는가, 침해되면 무엇을 할 수 있는가, 그리고 이를 어떻게 탐지할 것인가? 이렇게 하면 일반적인 점검 목록이 아니라 우선순위가 정해진 통제 수단 목록을 만들 수 있습니다.

의존성이 공격 경로가 되는 이유와 그 노출을 줄이는 방법을 배웠습니다.

• 신뢰 역전은 통제할 수 없는 제3자에게 보안이 의존한다는 뜻입니다
• 주요 위협은 타이포스쿼팅, 의존성 혼동, 유지 관리자 탈취, 악성 설치 스크립트 및 침해된 빌드 도구입니다
• 핵심 방어책은 무결성 해시가 포함된 잠금 파일, SCA 검사, 다이제스트를 사용한 정확한 버전 고정, 게시자에 대한 2단계 인증 및 지속적 모니터링입니다

다음으로 SBOM을 사용하여 소프트웨어에 정확히 무엇이 포함되어 있는지 목록화합니다.