공급망
소프트웨어 공급망 보안이란?
소프트웨어 공급망 보안은 소프트웨어가 사용자에게 도달하기 전에 그 안에 들어가는 모든 것, 즉 오픈 소스 패키지, 빌드 시스템, 파이프라인의 도구, 그리고 릴리스 자체를 보호하는 활동입니다. 공격자들은 점점 더 애플리케이션 대신 이들을 노립니다. 손상된 패키지나 빌드 단계 하나가 그것을 사용하는 모든 제품에 도달하기 때문입니다.
업데이트
소프트웨어 공급망이란?
소프트웨어 공급망은 소프트웨어가 개발자의 편집기에서 프로덕션에 이르기까지 관여하는 모든 사람과 모든 것입니다. 각각 고유한 위험이 있는 네 단계로 생각해 볼 수 있습니다.
| 단계 | 포함되는 것 | 발생하는 문제 |
|---|---|---|
| 소스 | 코드, 리포지토리, 개발자 계정 | 자격 증명 탈취, 악의적인 커밋, 시크릿 유출 |
| 종속성 | 오픈 소스 패키지, 베이스 이미지, 서드파티 코드 | 취약한 버전, 악성 릴리스, 타이포스쿼팅 |
| 빌드 | CI 러너, GitHub Actions, 빌드 도구, 캐시 | 손상된 액션, 오염된 캐시, 탈취된 파이프라인 시크릿 |
| 릴리스 | 아티팩트, 레지스트리, 배포, 업데이트 | 바꿔치기된 아티팩트, 변조된 업데이트, 출시된 내용의 기록 부재 |
지금 중요한 이유
출시하는 것의 대부분은 직접 작성한 것이 아닙니다. 현대 애플리케이션은 대부분 오픈 소스이며, 각 직접 종속성은 팀의 누구도 선택하지 않은 다른 종속성을 끌고 옵니다. 이 패키지들은 자체 코드와 같은 권한으로 실행되며, 그 설치 스크립트는 CI 파이프라인 안에서 시크릿 바로 옆에서 실행될 수 있습니다.
지난 몇 년간의 기록은 이것이 어떻게 악용되는지 보여 줍니다.
- SolarWinds: 빌드가 손상되어, 깨끗한 소스 트리에서 오염된 릴리스가 만들어졌습니다.
- Log4Shell: 로깅 라이브러리 하나의 결함이 그것을 사용하는 줄도 몰랐던 제품들에 도달했습니다.
- xz utils: 신뢰받는 기여자가 Linux 배포판에 포함된 프로젝트에 백도어를 몰래 심었습니다.
- tj-actions: 탈취된 GitHub Action이 이를 사용하는 파이프라인에서 시크릿에 접근할 수 있는 상태로 공격자 코드를 실행했습니다.
- Shai-Hulud: 웜이 npm 패키지를 통해 퍼지며, 이를 설치한 머신과 CI 작업에서 토큰을 탈취했습니다.
이러한 공격이 단계별로 어떻게 작동하는지는 공급망 공격이란 무엇인가를 참조하세요.
소프트웨어 공급망 보안의 작동 방식
프로그램에는 네 가지가 필요합니다. 나머지는 세부 사항입니다.
- 출시하는 것을 파악하세요. 모든 릴리스에 대해 그것을 만든 빌드로부터 정확한 SBOM을 유지하세요. 전이적 종속성도 포함해야 합니다.
- 들어오는 것을 통제하세요. 버전을 고정하고, 잠금 파일을 사용하며, 빌드가 가져올 수 있는 곳을 제한하고, 새 패키지를 검증하세요.
- 빌드를 보호하세요. 작업을 격리하고, 시크릿을 제한하며, 액션을 커밋으로 고정하고, 아웃바운드 트래픽을 제한해 손상된 패키지가 토큰을 어디로도 보낼 수 없게 하세요. 러너 보안과 공급망 보안이 CI에 속하는 이유를 참조하세요.
- 출시된 것을 계속 감시하세요. 새로운 취약점은 이미 프로덕션에 있는 소프트웨어에 영향을 줍니다. 이를 모니터링하고, 어떤 릴리스가 영향을 받는지 추적하며, 각 수정이 새 릴리스로 이어질 때까지 따라가세요.
자세한 체크리스트는 소프트웨어 공급망 보안 모범 사례를 참조하세요.
프레임워크와 규제
| 이름 | 내용 | 적합한 용도 |
|---|---|---|
| SLSA | 빌드 무결성과 출처 증명을 위한 수준 | 소프트웨어 빌드 방식 강화 |
| NIST SSDF | 보안 개발 관행, SP 800-218 | 완전한 보안 개발 프로그램 |
| NIST SP 800-161 | 사이버 보안 공급망 위험 관리 | 조직 전반의 위험 관리 |
| OpenSSF Scorecard | 오픈 소스 프로젝트 상태의 자동화된 점검 | 종속성 검증 |
| Cyber Resilience Act | 디지털 요소가 있는 제품에 대한 EU 법률 | EU에서의 판매. CRA란 무엇인가 참조 |
어떤 도구가 관련됩니까?
이 모든 것을 다루는 단일 제품은 없습니다. 이 범주는 SCA 도구, SBOM 도구, CI/CD 및 러너 보안, 패키지 방화벽, 애플리케이션 보안 태세 관리, 바이너리 분석으로 나뉩니다. 각각이 하는 일과 판매하는 곳은 소프트웨어 공급망 보안 도구 비교와 비용을 참조하세요.
시작하는 방법
- 가장 중요한 제품의 CI 빌드에서 SBOM을 생성하고 읽어 보세요.
- 종속성 취약점 알림을 켜고, 누가 담당할지 정하세요.
- GitHub Actions를 커밋으로 고정하고, 워크플로가 접근할 수 있는 시크릿을 검토하세요.
- 빌드의 아웃바운드 트래픽을 실제로 필요한 호스트로 제한하세요.
- 빌드 중인 것뿐 아니라 출시한 것에 대한 모니터링을 설정하세요.
CRACI의 접근 방식
CRACI는 빌드에서 시작합니다. 빌드가 모든 것을 볼 수 있는 유일한 곳이기 때문입니다. CRACI는 GitHub 호스팅 러너를 더 빠르고 저렴한 러너로 대체하며, 이 러너는 각 작업이 가져오는 모든 패키지를 트리의 모든 깊이에서, CI 캐시에서 복원된 패키지까지 포함해 기록합니다. 이그레스 정책은 빌드에 필요하지 않은 연결을 차단하므로, 아무도 본 적 없는 공격에 대해서도 보호합니다. 이후 CRACI는 출시된 것을 새로운 취약점과 계속 대조하고, 각 취약점을 분류부터 수정된 릴리스까지 추적합니다. CRACI로 하는 소프트웨어 공급망 보안을 참조하세요.
소프트웨어 공급망 보안: 자주 묻는 질문
소프트웨어 공급망 보안이란 무엇입니까?
소프트웨어가 사용자에게 도달하기 전에 그 안에 들어가는 모든 것, 즉 오픈 소스 종속성, 빌드 시스템, 파이프라인 도구, 릴리스를 보호하는 활동입니다.
소프트웨어 공급망 공격의 사례로는 무엇이 있습니까?
SolarWinds 공격에서는 빌드가 손상되어 고객들이 신뢰하는 공급업체로부터 오염된 업데이트를 받았습니다. Shai-Hulud 공격에서는 웜이 npm 패키지를 통해 퍼지며 이를 설치한 머신에서 토큰을 탈취했습니다.
공급망 보안과 애플리케이션 보안의 차이는 무엇입니까?
애플리케이션 보안은 직접 작성하는 코드의 결함을 살펴봅니다. 공급망 보안은 직접 작성하지 않은 것과 소프트웨어가 빌드되고 출시되는 방식을 살펴봅니다. 프로그램에는 둘 다 필요합니다.
SBOM만으로 공급망 보안이 충분합니까?
아닙니다. SBOM은 출시하는 것을 알려 주며, 이는 기반입니다. 그 밖에도 들어오는 것을 통제하고, 빌드를 보호하며, 출시한 것을 계속 모니터링해야 합니다.
주요 프레임워크는 무엇입니까?
빌드 무결성을 위한 SLSA, 보안 개발 관행을 위한 NIST SSDF, 공급망 위험 관리를 위한 NIST SP 800-161이 있습니다. EU에서는 Cyber Resilience Act가 디지털 요소가 있는 제품에 대한 법적 요구 사항을 정합니다.
소프트웨어 공급망 보안은 누가 담당합니까?
대개 애플리케이션 보안 또는 제품 보안 팀이 담당하며, 파이프라인을 운영하는 플랫폼 및 DevOps 팀과 협력합니다. 수정은 각 서비스를 소유한 엔지니어링 팀이 진행합니다.