지니언스는 SLSA 준수를 위한 빌드시스템 전환 계획을 점진적으로 가지고 있습니다. SLSA란 무엇이며 지니언스는 어떻게 적용했는지 소개하겠습니다.
SLSA(Supply-chain Levels for Software Artifacts)는 *소프트웨어 공급망 보안을 위한 보안프레임워크입니다. 이를 통해 소프트웨어가 구현부터 고객에게 배포되기까지 조작되지 않았음을 확인 수 있습니다.
* 소프트웨어 공급망 : 제품 또는 서비스를 고객에게 제공하기 위해 수행하는 프로세스이며 소프트웨어 개발부터 고객에 배포되기까지의 전 프로세스를 관리해야 합니다.
공급망 보안과 관련한 이슈에서 빌드된 제품 패키지에 대한 보증은 SBOM과 더불어 매우 중요한 부분 입니다. 이를 위해서 Linux Foundation, Google, CNCF등의 기관이 연합하고 OpenSSF가 주축이 되어 SLSA(Supply-chain Levels for Software Artifacts) 라는 표준을 만들었습니다. (“salsa” 라고 읽습니다)
SLSA를 간단하게 요약하면
- 소프트웨어 패키지에는 출처를 증명하기위한 정보가 담겨 있어야 합니다. (Level 1)
- 빌드는 호스팅된 플랫폼(예. GitHub)에서 진행 되어야 합니다. (Level 2)
- 강력한 변조방지 기능을 제공하는 빌드플랫폼에서 빌드가 실행됨을 증명해야 합니다. (Level 3)
마이크로소프트나 애플에서 제공되는 코드사인은 SLSA Level 1 보다도 낮은 수준의 전자서명만 제공됩니다. SLSA Level 1의 출처정보에는 코드사인보다 더 많은 정보가 담겨있습니다. SLSA Level 2 이상의 기술적 핵심사항은 빌드를 소프트웨어 제조사가 직접 관리하는 플랫폼이 아닌 호스팅된 검증된 플랫폼에서 수행해야 한다는 것 입니다.
즉 소프트웨어 제조사라도 빌드 시스템에 SSH등으로 접근할 수 있어서는 안되며 신뢰할 수 있는 외부 패키지 참조(npm, go module등), 매 빌드시마다 새로운 운영체제에서 빌드가 새롭게 시작되어야 하는 등의 기술적 요건을 충족 해야 합니다. 현재 SLSA Level 3 인증을 받은 빌드플랫폼은 2개 입니다.
- GitHub Action
- Google Cloud Build
1. SW 공급망 보안 표준(SLSA) 이란?
SLSA는 산업 합의를 통해 수립된 보안 지침의 집합입니다. SLSA v1.0은 소프트웨어 생산자와 사용자 모두를 위한 명확한 보안 지침을 제공하여 공급망의 보안성을 강화하는데 중요한 역할을 합니다. SLSA v1.0은 "Supply Chain Levels for Software Artifacts"의 버전 1.0을 의미합니다. 이는 소프트웨어 아티팩트의 공급망 수준을 나타내는 지침의 첫 번째 버전을 나타냅니다. (SLSA v1.0 : https://slsa.dev/spec/v1.0/ )
SLSA 등급 설명
SLSA는 무결성 보증을 점진적으로 제공하는 Security levels로 구성되어 있습니다.
각 트랙 내에서 수준이 높아질수록 보안수준이 점점 더 강화되고 있음을 나타냅니다. 수준이 높을수록 공급망 위협에 대해 더 나은 보장을 제공하지만 구현 비용이 더 높아집니다. 낮은 SLSA 수준은 채택하기가 더 쉽도록 설계되었지만 적당한 수준의 보안만 보장됩니다.
- Build L0 : 이 레벨은 별다른 무결성 보증을 제공하지 않습니다. 다른 SLSA 레벨로의 이행을 위한 시작점이며, 초기 수용과 적용을 도와줍니다.
- Build L1 : 아티팩트의 무결성을 보장하며, 공개된 보안 업데이트와 패치를 적용하여 일부 보안 위협에 대비합니다.
- Build L2 : Build L1 의 보안 기능에 더해 지속적인 보안 모니터링과 보안 자동화가 포함됩니다. 사전에 정의된 보안 정책에 따라 아티팩트를 관리하고 반응합니다.
- Build L3 : 최고 수준의 무결성 보증을 제공하며, 보안 감사 및 충족 여부를 확인하기 위한 높은 수준의 자동화가 포함됩니다. 이는 고도의 보안 요구 사항을 충족하고 아티팩트의 보안을 보다 강력하게 보장합니다.
* 아티팩트 : 시스템이나 애플리케이션이 자동으로 생성한 데이터
2. 공급망 위협 설명
공격은 일반적인 소프트웨어 공급망의 모든 구간에서 발생할 수 있습니다. 공급망 전반에 걸쳐 발생할 수 있는 공격과 SLSA가 어떻게 도움이 될 수 있는지 설명합니다.
<그림1> 공급망 위협 도식화
출처 : https://slsa.dev/spec/v1.0/threats-overview (그림 재구성)
SLSA의 주요 초점은 공급망 무결성과 가용성입니다. 무결성이란 소프트웨어 수명 주기의 모든 단계에서 변조 또는 무단 수정부터 보호하는 것을 의미합니다. SLSA 내에서는 무결성을 소스 무결성과 빌드 무결성으로 나눕니다.
소스 무결성
소스 코드에 대한 모든 변경 사항이 SSH 등으로 생산자 의도를 반영하는지 확인합니다. 조직의 의도를 정의하기 어렵기 때문에 SLSA는 이를 두 명의 승인된 대리인의 승인으로 추정합니다. 소스 위협으로는 다음과 같은 사례가 존재합니다.
사례1 : 소스 무단 변경 제출
저장소 액세스 권한이 있는 계약자가 암호화폐를 자신에게 리디렉션하는 악의적인 커밋을 푸시했습니다. SLSA 기준을 활용하여 2인 검토를 통해 승인되지 않은 변경 사항을 감지할 수 있었습니다. (참고 : SushiSwap)
사례2 : 소스코드 저장소 손상
공격자는 PHP의 자체 호스팅 Git 서버를 손상시키고 두 개의 악성 커밋을 주입했습니다. SLSA 기준을 활용하여 GitHub 등과 같이 더 잘 보호된 소스코드 플랫폼은 공격자에게 훨씬 더 어려운 표적이 되었을 것입니다.(참고 : PHP)
사례3 : 수정된 소스로부터 빌드(소스 저장소와 일치하지 않음)
공격자는 소스 제어와 일치하지 않는 소스 파일을 사용하도록 빌드 인프라를 수정했습니다. SLSA 호환 빌드 서버는 사용된 실제 소스를 식별하는 출처를 생성하여 소비자가 이러한 변조를 감지할 수 있도록 합니다. (참고 : Webmin)
사례4 : 손상된 종속성 사용
공격자는 무해한 종속성을 추가한 후 나중에 종속성을 업데이트하여 악의적인 동작을 추가했습니다. 업데이트가 GitHub에 제출된 코드와 일치하지 않았습니다. 모든 종속성에 SLSA를 재귀적으로 적용하면 이 특정 벡터를 방지할 수 있습니다. 출처에 따르면 해당 벡터가 적절한 빌더에서 빌드되지 않았거나 소스가 GitHub에서 제공되지 않았음을 나타내기 때문입니다. (참고 : event-stream)
빌드 무결성
소프트웨어 생산자가 정의한 빌드 규칙에 따라 수정되지 않은 올바른 소스 및 종속성에서 패키지가 빌드되었는지, 개발 단계 간에 아티팩트가 수정되지 않았는지 확인합니다. 빌드 위협으로는 다음과 같은 사례가 존재합니다.
사례1 : 빌드프로세스 손상
공격자는 빌드 플랫폼을 손상시키고 각 빌드 중에 제품 컴파일과 관련된 실행 프로세스를 모니터링하고 소스 파일 중 하나를 대체하여 악의적인 동작을 주입하는 백도어 코드를 포함했습니다. SLSA 수준이 높을수록 빌드 플랫폼에 대한 더 강력한 보안 제어가 필요하므로 손상 및 지속성을 확보하기가 더 어려워집니다. (참고 : SolarWinds)
사례2 : 수정된 패키지 업로드
공격자는 유출된 사용자 인증 정보를 사용하여 사용자가 직접 다운로드할 수 있는 GCS 버킷에 악성 아티팩트를 업로드했습니다. GCS 버킷에 있는 아티팩트의 출처를 보면 아티팩트가 예상 소스 저장소에서 예상한 방식으로 빌드 되지 않았음을 알 수 있습니다. (참고 : CodeCov)
사례3 : 손상된 패키지 저장소
연구원은 악성 패키지를 제공하는 데 사용될 수 있는 여러 인기 패키지 저장소에 대해 미러를 실행했습니다. 위(수정된 패키지 업로드)와 유사하게, 악성 아티팩트의 출처를 보면 해당 아티팩트가 예상대로 또는 예상 소스 저장소에서 빌드되지 않았음을 알 수 있습니다. (참고 : 패키지 미러에 대한 공격)
사례4 : 훼손된 패키지 사용
공격자가 원본과 유사한 이름의 악성 패키지를 업로드했습니다. SLSA는 이 위협을 직접적으로 해결하지는 않지만 소스 제어에 다시 연결되는 출처를 통해 다른 솔루션을 활성화하고 향상시킬 수 있습니다. (참고 : Browserify typosquatting)
3. 지니언스 업데이트 서버 SLSA 적용 사례
지니언스는 SLSA 준수를 위한 빌드 시스템 전환에 앞서 지니언스 업데이트 서비스에 우선 적용 했습니다.
<그림2> SLSA Build L3를 적용한 지니언스 업데이트 서비스 구성도
지니언스 업데이트 서비스는 Genian NAC(네트워크 접근통제 제품)에 단말 가시성 정보, 단말 정보 등을 최신화 하기 위해 사용됩니다.
지니언스 업데이트 서비스를 구성하는 요소는 배포 파일 생성 관리를 위한 GitHub, 배포파일 저장 운영은 AWS를 이용합니다. 그리고 배포파일 무결성 보장을 위해 Sigstore를 사용합니다.
* GitHub : 분산 버전관리 툴인 깃 저장소 호스팅을 지원하는 웹 서비스
* Sigstore : SW를 서명하고, 서명을 검증하고, 서명을 추적할 수 있는 서비스
업데이트 서비스 절차
Genian NAC에 정보를 업데이트하기 위한 파일 생성 및 배포시에 SLSA L3를 적용했으며 절차는 다음과 같습니다.
배포파일 생성 절차
①, ② 에서 생성된 배포파일을 자동으로 수집하고 GitHub Actions (③)을 이용하여 Pull Request(④)를 요청합니다. Pull Request는 GitHub 저장소에 Push하여 새로운 사항이 적용된 경우, 다른 사용자에게 푸쉬된 상황을 알리는 것을 말합니다.
* GitHub Actions : 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼.
PR승인자(지니언스 배포파일관리자)는 자동 수집된 배포파일에 문제가 없는지 검토 및 승인(⑤)을 진행하면 GitHub Repository에 배포 파일이 저장됩니다.
GitHub Actions(Buld SLSA)을 이용해 GitHub Repository에 저장된 배포파일에 (⑥)Sigstore 전자서명을 하고 (⑦)AWS에 전자서명된 배포파일을 저장합니다.
배포파일 다운로드 절차
Genian NAC 정책서버는 주기적으로 배포파일이 갱신되었는지 Amazon S3에 요청(1) 하고 최신 파일을 다운로드합니다. 다운로드한 배포파일을 Sigstore 전자서명 검증(2)으로 무결성 확인 후 안전한 배포파일만 제품에 적용됩니다.
4. SLSA 적용 후 기대효과
지니언스는 SLSA 공급망 보안 표준 적용 (SLSA 3)하여 신뢰할 수 있는 빌드 명세 제공을 할 수 있게 되었습니다. 호스팅 된 빌드를 통해 개발사도 변조 불가한 빌드 체계를 구축했습니다. Sigstore를 활용한 전자서명으로 안전한 서명키 관리를 할 수 있습니다.
강화된 전자서명 검증 체계 적용으로 배포를 위한 업데이트 파일 소스는 GitHub에 저장 후 전자서명 완료된 배포 파일은 AWS S3에 저장되도록 개선했습니다.
소스 위협 예방 효과
소스 무결성 검증 체계가 강화되어 다음과 같은 소스 위협을 예방 할 수 있습니다.
무단 변경 제출
배포파일을 자동으로 수집하고 PR 승인자 검토를 통해 승인되지 않은 변경 사항을 포착할 수 있습니다.
소스코드 저장소 손상
GitHub를 이용해 배포파일 저장/관리되어 변경 이력이 관리되어 저장소 손상이 어렵습니다.
수정된 소스로부터 빌드
GitHub Actions를 이용해 사람의 개입없이 매번 빌드 환경을 새로 구축하고 GitHub Repository에서 배포파일을 읽어와 손상이 어렵습니다.
손상된 종속성 사용
모든 종속성에 SLSA를 적용하면 이 특정 벡터를 방지할 수 있습니다. 출처에 따르면 해당 벡터가 적절한 빌더에서 빌드되지 않았거나 소스가 GitHub에서 제공되지 않았음을 나타내기 때문입니다.
빌드 위협 예방 효과
빌드 무결성 검증 체계가 강화되어 다음과 같은 빌드 위협을 예방 할 수 있습니다.
빌드프로세스 손상
GitHub Actions를 이용해 사람의 개입없이 매번 빌드 환경을 새로 구축하여 운영하기 때문에 빌드 프로세스 손상이 불가합니다.
수정된 패키지 업로드
위(빌드프로세스 손상) 와 마찬가지로 GitHub Actions을 매번 빌드 환경을 새로 구축하고 이용해 GitHub Repository에서 배포 파일을 이용하여 Sigstore로 전자 서명 후 AWS S3에 배포 패키지 파일을 사람에 개입 없이 운영되기 때문에 손상이 불가 합니다.
손상된 패키지 저장소
Amazon S3는 확장성, 데이터 가용성 및 보안과 성능을 제공하는 객체 스토리지 서비스입니다. 데이터 레이크, 웹사이트, 클라우드 네이티브 애플리케이션, 백업, 아카이브와 같은 다양한 사용 사례에 대해 원하는 양의 데이터를 저장하고 보호합니다. SLSA 수준이 높은 플랫폼을 활용하기 때문에 손상 및 지속성을 확보하기가 더 어려워집니다.
훼손된 패키지 사용
Sigstore를 이용해 배포 파일 무결성을 보장합니다. Sigstore란 Linux Foundation에서 주도하는 Artifact(패키지)에 대한 전자서명 표준입니다. Keyless 서명 방식을 지원하는 것이 특징입니다.
글쓴이. 방지환
지니언스에서 정보보호시스템 사전인증(보안기능확인서, CC인증, 성능평가 등) 획득을 위한 업무를 담당하고 있습니다.
