내가 참여하고 있는 구식 및 최신 건축 박물관은 나에게 이들을 보호하는 방법을 알아보도록 강요했습니다. 예를 들어, 오래된 종속성은 CVE로 변환될 수 있으며, 견고한 오픈 소스 프로젝트는 상업적으로 전환될 수 있습니다. 이러한 상황에서 시스템의 라이센스 및 종속성 생태계를 기록하는 소프트웨어 자재 명세서(SBOM) 개념이 등장했습니다. 이 빌드 아티팩트는 구성 요소가 다음과 같은지 여부를 판단하기 위해 분석됩니다:
- 악용에 취약한지,
- 상업적이거나 포식적인 조건으로 라이센스가 부여되었는지와 같은 바람직하지 않은 조건에 따르는지.
이 기사는 다음을 사용하여 이러한 취약성을 제어하는 방법을 설명할 것입니다:
- SBOM 생성을 위한 BitBucket 파이프, 그리고
- OWASP의 Dependency Track이 이를 분석하는 방법.
위험 알기
코드와 컨테이너에 무엇이 숨어 있는지 모르는 것은 행복하지만 위험합니다. 그러나 모든 구성 요소를 종속성 분석기를 통해 통과시키는 것은 압도적인 피드백을 줄 수 있습니다. 종속성 문제의 양이 어제보다 항상 적어야 한다는 것을 팀 문화에 대시보드로 심는 것이 더 좋습니다.
위키백과에 따르면: “오픈 전 세계 애플리케이션 보안 프로젝트 (OWASP)는 IoT, 시스템 소프트웨어 및 웹 애플리케이션 보안 분야에서 자유롭게 이용 가능한 기사, 방법론, 문서, 도구 및 기술을 제작하는 온라인 커뮤니티입니다.” 따라서 그들이 시스템의 취약성을 추적하고 분석할 수 있는 플랫폼을 제공하는 것은 놀라운 일이 아닙니다. 그들의 가장 눈에 띄는 특징은 주요 대시보드입니다:
가장 큰 그래프 중앙에는 추적되고 있는 모든 프로젝트의 취약점 수가 표시됩니다. 중요한 것, 중간 것, 낮은 것에 대한 지표가 바로 아래에 표시됩니다. Dependency Track은 하나 이상의 출처에서 알려진 취약점을 가져옵니다. 이 중 가장 주목할 만한 것은 미국 국립 취약점 데이터베이스의 공통 취약점 및 노출 (CVE) 목록입니다. 각 CVE는 알 수 없는 것과 낮은 것에서부터 중요한 것까지의 중요도 수준이 할당됩니다. 이 위험 분석은 관련 소프트웨어 자재 명세서 (SBOM)를 입력으로 사용하여 Dependency Track에 의해 정기적으로 백그라운드에서 수행됩니다.
가장 큰 그래프 바로 아래 섹션은 정책 위반에 대한 세부 정보를 제공하며, 정책은 개인이 중요하다고 생각하는 것에 따라 구성됩니다. 특정 종속성을 원하지 않는 것으로 등록할 수 있으며, 특정 라이센스 또는 라이센스 그룹이 대시보드에 포함되고 보고되도록 요구할 수 있습니다. 이 피드백 메커니즘은 정책별로 구성 가능합니다.
상단 섹션은 포트폴리오 취약점, 위험에 처한 프로젝트, 취약한 구성 요소 및 시간이 지남에 따라 위험 점수를 나타냅니다.
더 많은 뷰, 그래프 및 통계가 있으며, 감사 진행 상황, 프로젝트별 취약점 시간 경과에 따른 변동 및 구성 요소별 취약점 시간 경과에 따른 변동 등이 있지만, BitBucket이 SBOM을 생성하고 Dependency Track에 전송하는 방법에 주목해 보겠습니다.
BitBucket이 SBOM을 준비합니다.
SBOM의 준비는 풀 리퀘스트가 메인 브랜치에 병합된 후 실행되는 BitBucket CI/CD 파이프라인에서 이루어집니다. 이렇게 하면 대시보드가 항상 현재 상황을 반영하여 최신 상태를 유지합니다.
저는 syft를 래핑하여 CycloneDX SBOM을 생성하는 BitBucket 파이프를 사용했습니다. 코드 및 컨테이너 조사에 대한 syft 명령은 약간 다릅니다.
코드 스니핑
프로젝트의 루트에서 코드를 분석하는 syft 명령은 다음과 같습니다:
syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .
이 명령은 SBOM을 code-cdx-sbom.json이라는 파일로 출력하며, 네트워크를 사용하여 인터넷에서 라이선스 정보를 가져옵니다. 예를 들어, 중앙 Maven 리포지토리에서 가져올 수 있습니다.
Syft BitBucket 파이프는 shiftleftcyber로부터(감사합니다!) 받았습니다. 그런 다음 이 syft 명령을 BitBucket 파이프라인의 스크립트 블록에 다음과 같이 구성했습니다:
pipedocker//ccideas/syft-bitbucket-pipe1.0.0
variables
SYFT_CMD_ARGS'. --output cyclonedx-json=code-cdx-sbom.json'
SYFT_JAVA_USE_NETWORK'true'
Syft 프로젝트의 readme에는 지원되는 언어들의 인상적인 배열이 나열되어 있지만, 저는 Java와 JavaScript에서만 사용했고 Python 프로젝트는 백로그에 남아 있습니다.
컨테이너에는 어떤 것이 숨어 있을까요?
레지스트리에서 컨테이너를 스캔하려면 다음 명령을 “도커 로그인” 범위 내에서 실행합니다:
syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry
해당하는 BitBucket 파이프는 다음과 같습니다:
pipedocker//ccideas/syft-bitbucket-pipe1.0.0
variables
SYFT_REGISTRY_AUTH_USERNAMEsadilar
SYFT_REGISTRY_AUTH_PASSWORD$DOCKER_PWD
SYFT_CMD_ARGS'docker.s2c.co.za/container:latest --output cyclonedx-json=container-cdx-sbom.json --scope all-layers'
all-layers 스위치는 syft가 컨테이너 이미지의 모든 레이어를 검사하도록하며 최종 제품뿐만 아니라 모든 것을 검사하도록 지시합니다.
저금통으로서의 BitBucket
남은 일은 Dependency Track이 SBOM을 흡수하는 것입니다. SBOM을 생성한 BitBucket 파이프의 자매 파이프를 사용했습니다:
pipedocker//ccideas/sbom-utilities-pipe1.5.0
variables
PATH_TO_SBOMcode-cdx-sbom.json
SEND_SBOM_TO_DTRACK'true'
DTRACK_URLhttps//deptrack.test.s2c.co.za
DTRACK_PROJECT_IDdf3327b2-5439-43ab-bb33-1f24228b6074
DTRACK_API_KEY$DTRACK_TEST
세 가지 입력 매개변수를 지정했습니다:
- 의존성 추적 인스턴스의 URL
- SBOM을 로드할 의존성 트랙 프로젝트의 ID
- 업로드를 인가하는 API 키
프로젝트 ID는 프로젝트 보기에서 “세부정보 보기”를 클릭하여 쉽게 찾을 수 있습니다:
그런 다음 하단의 객체 식별자를 복사합니다:
API 키는 좌측 패널의 자동화 팀의 동일한 이름의 항목 필드에서 찾을 수 있습니다. 관리 메뉴에서 접근할 수 있습니다:
결론
과거 사건은 약점을 악용하는 것이 이웃 시스템이나 산업으로 퍼져서 서비스 중단으로 이어질 수 있음을 보여주었습니다. 예상치 못한 비용과 불편을 초래합니다. 이로 인해 개발자와 리소스가 팀 목표에서 벗어날 수 있습니다.
또한, 오픈 프로젝트의 라이선스는 상업적으로 변할 수 있고, 조직이 과거의 라이선스 비용을 부과받을 수 있습니다. 반대로, 포악한 라이선스 조건으로 경쟁 우위를 얻기 위해 사용된 중요한 IP를 오픈소스화해야 할 수도 있습니다.
따라서 각 개발자는 이러한 위험에 대항하기 위한 적극적인 전략을 구현하고 지원해야 합니다. 만약 여러분의 코드가 BitBucket에 있다면, 위에서 설명한 접근 방식이 여러분의 시스템이 프로그램에 따라가는 데 도움이 될 수 있습니다. 그러나 의존성 추적 API는 BitBucket에만 액세스를 제한하지 않으며, 다른 CI/CD 파이프라인 기술로부터 소프트웨어 부품 목록을 가져올 방법이 있어야 합니다.
Source:
https://dzone.com/articles/on-sboms-bitbucket-and-owasp-dependency-track