FOSSology는 웹기반의 프로그램으로 사용자는 웹사이트에 로그인하여 개별 파일 혹은 소프트웨어 패키지를 업로드할 수 있다. FOSSology는 업로드된 파일 내에 라이선스 텍스트와 Copyright 정보를 검출한다. 개발자는 사용하고자 하는 오픈소스의 라이선스가 무엇인지, Copyright은 어떻게 되는지에 대한 정보를 확인하고자 할때 FOSSology를 이용하는 것이 좋다. FOSSology는 개발자가 업로드한 오픈소스 패키지 내의 모든 파일을 스캔하여 각 파일 내 라이선스 관련 텍스트와 Copyright 정보를 자동으로 검출하고, 이를 리포트로 생성한다. FOSSology 주요 특징에 대한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/features/

설치

기업 내에서 FOSSology를 사용하기 위해서는 사내에 FOSSology 서버를 구축해야 한다. 이를 위해 리눅스 기반의 서버 시스템에 FOSSology를 설치해야 한다. FOSSology는 다음 세 가지 방법으로 설치할 수 있다.

Docker 사용
Vagrant와 VirtualBox 사용
Source build하여 설치

여기서는 가장 간편한 방법인 Docker를 사용하는 방법에 대해 설명한다.

FOSSology는 컨테이너화 된 Docker 이미지를 Docker Hub (https://hub.docker.com/)를 통해 공개하고 있다. : https://hub.docker.com/r/fossology/fossology

Pre-built 된 Docker 이미지는 다음 명령어를 사용하여 실행할 수 있다.

$ docker run -p 8081:80 fossology/fossology

Docker 이미지는 다음 URL과 계정 정보로 사용할 수 있다. : http://[IP_OF_DOCKER_HOST]:8081/repo

Username : fossy
Passwd : fossy

설치와 관련한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://github.com/fossology/fossology/blob/master/README.md

테스트 서버

FOSSology를 설치할 수 있는 시스템 구축이 곤란한 상황이라면, FOSSology Project에서 제공하는 테스트 서버를 이용할 수 있다. FOSSology 프로젝트에서는 테스트를 위한 환경을 제공한다. (테스트 서버는 예고없이 중단될 수 있다.)

사용자는 다음 계정으로 FOSSology 테스트 서버에 접속하여 FOSSology 기능을 시험해볼 수 있다.

테스트 서버 URL: [https://fossology.osuosl.org/](https://fossology.osuosl.org/) * Username: fossy * Password: fossy

Basic Workflow

FOSSology의 기본 사용 절차는 다음과 같다.

사용하고자 하는 오픈소스의 라이선스와 Copyright 정보를 확인하기 위해 오픈소스의 소스 코드를 하나의 파일로 압축하여 FOSSology에 업로드한다.
이를 위해 메뉴 > Upload > From File을 선택합니다.
업로드할 파일을 선택하고 Upload 버튼을 클릭한다.
업로드가 완료되면 Job Agent에 의해 자동으로 분석을 수행한다.
메뉴 > Jobs > My Recent Jobs에서 분석 중인 Status를 확인할 수 있다.
분석이 완료되면 메뉴 > Browse에서 분석 결과를 확인할 수 있다.
개별 파일을 선택하면 FOSSology가 검출한 라이선스 관련 텍스트가 무엇인지 확인할 수 있다.
메뉴 > Browser > 파일 혹은 디렉터리를 선택 > Copyright/Email/Url/Author에서는 FOSSology가 검출한 Copyright/Email/Url/Author 정보를 보여다.

사용자는 FOSSology는 이렇게 분석한 결과가 유효한지 여부에 대해 확인 후 잘못 검출된 항목에 대해서는 분석 결과에서 제외시키는 작업을 할 수 있다. FOSSology는 이를 Clearing 과정이라고 설명하며, 자세한 사항은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/get-started/basic-workflow/

위와 같은 방법으로 사용하고자 하는 오픈소스의 라이선스는 무엇인지, Copyright 정보는 어떻게 되는지를 간단히 확인할 수 있다.

2 - SW360

(Updated on August 29, 2023.)

오픈소스를 포함하는 제품을 개발하고 배포하는 기업이라면 각 제품과 릴리스 버전마다 사용한 오픈소스의 버전, 라이선스 등의 정보를 수집하고 추적해야 한다. 이를 통해 기업은 올바른 오픈소스 컴플라이언스 활동을 수행할 수 있다.

특히, NVD (https://nvd.nist.gov/vuln)에서 특정 오픈소스 버전에 보안 취약점이 보고 되었을때, 해당 버전을 사용하고 있는 제품이 무엇인지 추적을 할 수 없다면, 그 기업은 어느 제품에 보안 패치를 적용해야 할 지 알 수 없는 상황에 처하게 되고, 그 기업의 제품들은 보안취약점에 그대로 노출이 될 수 밖에 없다.

이렇듯, 오픈소스 정보를 추적하는 활동은 꼭 필요하다. 기업들은 이를 위해 자체 시스템을 구축하거나, 상용 서비스를 구매하여 사용하기도 한다. SW360은 Eclipse 재단에서 후원하는 오픈소스로서 소프트웨어 BOM에 대한 정보를 수집 및 추적하기 위한 웹 애플리케이션 및 저장소를 제공한다.

< https://www.eclipse.org/sw360/ >

주요 특징

SW360은 웹 기반의 UI를 제공하며 주요 기능은 다음과 같다.

제품에 사용된 컴포넌트 추적
보안 취약점 평가
라이선스 의무 관리
고지문 등 법적 문서 생성

설치

SW360은 다음과 같이 구성된다.

Frontend : Liferay-(Tomcat-)based portal application
Backend : Tomcat-based thrift service
Database : CouchDB

Project 구조와 설치를 위해 요구되는 소프트웨어 등 자세한 내용은 README의 Required software 부분에서 확인할 수 있다. : https://github.com/eclipse-sw360/sw360

SW360은 다음 두 가지의 설치 방법을 제공한다. 사용자는 이 중 하나를 선택하여 설치할 수 있다.

Docker를 통해 Deploy 할 수 있다. : https://github.com/eclipse-sw360/sw360/blob/main/README_DOCKER.md
SW360의 구성요소를 개별적으로 설치할 수 있다. : https://github.com/eclipse/sw360
Vagrant (https://www.vagrantup.com/) 기반 설치 : Vagrant는 가상화 인스턴스를 관리하는 도구로서 sw360vagrant에서는 SW360을 한 번에 Deploy 하기 위한 환경을 제공한다. : https://github.com/sw360/sw360vagrant
- Vagrant 기반 설치 가이드는 여기에서 확인할 수 있다. (단, 가이드 작성 시점과 현재 코드가 상이하여 정상동작하지 않을 가능성이 있습니다.)

이 가이드에서는 Docker로 Deploy하는 방법을 소개한다. 자세한 사항은 README를 참고한다. : https://github.com/eclipse-sw360/sw360/blob/main/README_DOCKER.md

1. 코드 다운로드

Docker Image 빌드를 위해 코드를 다운로드 한다. 테스트가 완료된 코드는 여기서 받을 수 있다. : https://github.com/haksungjang/sw360/tree/docker_build

git clone -b docker_build https://github.com/haksungjang/sw360.git

2. 빌드

먼저 Docker를 설치한다. (기업 개발자가 사용하려면 유료 구매가 필요할 수 있음에 주의하세요.)

아래와 같이 docker_build.sh를 실행하여 빌드한다.

cd sw360
./docker_build.sh

정상적으로 빌드가 완료되면 아래와 같이 생성된 이미지를 확인할 수 있다.

docker image ls

REPOSITORY                       TAG              IMAGE ID       CREATED          SIZE
eclipse-sw360/sw360              18-development   ab0fd848bf80   8 minutes ago    2.95GB
eclipse-sw360/sw360              latest           ab0fd848bf80   8 minutes ago    2.95GB
ghcr.io/eclipse-sw360/sw360      18-development   ab0fd848bf80   8 minutes ago    2.95GB
ghcr.io/eclipse-sw360/sw360      latest           ab0fd848bf80   8 minutes ago    2.95GB
eclipse-sw360/binaries           18-development   aa7debf0a1fc   8 minutes ago    347MB
eclipse-sw360/binaries           latest           aa7debf0a1fc   8 minutes ago    347MB
ghcr.io/eclipse-sw360/binaries   18-development   aa7debf0a1fc   8 minutes ago    347MB
ghcr.io/eclipse-sw360/binaries   latest           aa7debf0a1fc   8 minutes ago    347MB
eclipse-sw360/base               18-development   e5147733fc88   37 minutes ago   1.52GB
eclipse-sw360/base               latest           e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/base       18-development   e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/base       latest           e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/thrift     0.18.1           0012d7998058   4 weeks ago      152MB
ghcr.io/eclipse-sw360/thrift     latest           0012d7998058   4 weeks ago      152MB
eclipse-sw360/thrift             0.18.1           0012d7998058   4 weeks ago      152MB
eclipse-sw360/thrift             latest           0012d7998058   4 weeks ago      152MB

3. 실행

docker-compose up 명령으로 생성된 이미지를 실행한다.

docker-compose up

정상적으로 실행이 완료되면 아래와 같이 세개의 container가 실행된 것을 볼 수 있다.

docker ps 

CONTAINER ID   IMAGE                 COMMAND                  CREATED         STATUS                   PORTS                                              NAMES
4299fd39010c   eclipse-sw360/sw360   "/app/entry_point.sh"    3 minutes ago   Up 3 minutes             0.0.0.0:8080->8080/tcp, 0.0.0.0:11311->11311/tcp   sw360
13fd5696b140   postgres:14           "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes (healthy)   0.0.0.0:5438->5432/tcp                             sw360-postgresdb-1
7bb70f2daaf4   couchdb               "tini -- /docker-ent…"   3 minutes ago   Up 3 minutes (healthy)   4369/tcp, 9100/tcp, 0.0.0.0:5984->5984/tcp         sw360-couchdb-1

이 상태에서 http://localhost:8080/로 접근하면 다음과 같은 화면에 진입한다.

설정

SW360을 정상적으로 설치한 후에는 아래의 절차대로 초기 설정이 필요하다. 자세한 내용은 여기에서 확인할 수 있다. : SW360 Initial Setup Configuration

설정을 위해 다음 계정으로 로그인한다.

id : setup@sw360.org
pw : sw360fossy

로그인을 하면 아래와 같이 Not Found라는 표시가 나타나게 된다.

화면 우상단의 아이템 아이콘(큐브 모양)을 클릭하고 Control Panel 탭을 선택한다.

SECURITY > Password Policies > Default Password Policy > PASSWORD CHANGES > Change Requried를 활성화한다.

그리고, 다시 Control Panel탭에서 CONFIGURATION > Instance Settings을 선택한다. 그러면, PLATFORM메뉴를 볼 수 있다.

거기서 Users를 선택한다. 그리고, Default User Associations 메뉴로 진입하고, Apply to Existing Users를 체크한다. 그리고 Save한다.

이번에는 Instance Settings > PLATFORM에서 User Authentication를 선택한다. General로 진입하여 모든 항목을 Uncheck한다. (관리 목적상 필요한 항목은 Check하여 활성화할 수 있다.) 그리고 Save한다.

끝으로, jquery와 font awesome을 활성화시켜야 한다. 이를 위해 Control Panel 탭에서 CONFIGURATION > System Settings으로 진입하면 PLATFORM 하위에 Third Party를 볼 수 있다.

Third Party에 진입하여 JQuery와 Font Awesome을 각각 Enable시킨다.

브라우저를 새로 실행하면 변경 사항이 적용된다.

2. LAR 파일 import

SW360 설정을 위해서는 *.lar 파일들을 import해야 한다. 이를 설정하기 위해서는 메뉴로 진입해야 하는데, 메뉴 버튼은 화면 좌측 상단에 있다.

메뉴에서 Publishing > Import에 진입한다.

우측의 + 버튼을 눌러 LAR 파일을 업로드 할 수 있는데, LAR 파일은 SW360 소스 파일 내 frontend/configuration 폴더 하위에 있다. (예: https://github.com/haksungjang/sw360/tree/docker_build/frontend/configuration)

먼저, Public_Pages_7_4_3_18_GA18.lar 파일을 업로드하고 Continue 버튼을 누른다.

File Summary 화면에서 업로드된 LAR 파일 세부 내용을 볼 수 있다.

제일 아래의 AUTHORSHIP OF THE CONTENT를 Use the Current User as Author로 변경하고 Import 버튼을 누른다.

그러면 Import가 성공적으로 완료된 걸 볼 수 있다.

이와 유사하게 Private_Pages_7_4_3_18_GA18.lar 파일을 Import한다. File Summary 화면에서 아래와 같이 PAGES > Private Pages로 변경한다.

그리고, PERMISSIONS, UPDATE DATA, AUTHORSHIP OF THE CONTENT 항목을 각각 아래 이미지와 같이 선택하고, Import버튼을 눌러 Import를 수행한다.

여기까지 수행을 마친 후 메뉴 상단의 Home 버튼을 누른다.

그럼 아래와 같이 Welcome to SW360! 화면에 진입한다.

Start 버튼을 눌러 SW360 첫 화면에 진입할 수 있다. (모든 항목이 비어있다.)

3. User Account 설정 (테스트용)

SW360 메뉴에서 Admin > User를 선택한다.

화면 하단의 UPLOAD USERS 메뉴에서 테스트를 위한 User 리스트를 업로드 한다. (테스트를 위한 User 리스트는 여기에서 다운 받을 수 있다. : test_users_with_passwords_12345.csv )

그러면 다음과 같이 9개의 User 리스트가 업로드 된 것을 볼 수 있다.

여기서 보이는 User 리스트 중 하나인 user@@sw360.org 계정으로 다시 로그인을 시도한다. Password는 12345이다.

Basic Workflow

1. License 등록

SW360을 처음 설치하면 먼저 자주 사용하는 오픈소스 라이선스 들을 등록해야 한다. 라이선스 다음과 같은 정보를 포함한다.

Full Name
Short Name
License Type
GPL-2.0 Compatibility (예: yes, no)
License Text

메뉴 > Licenses > Add License를 선택하면 다음과 같이 Create License 화면으로 진입한다.

이와 같이 라이선스를 하나씩 수동으로 등록하는 일은 상당히 수고스러울 수 있는데, 다행히 SW360은 SPDX License List를 한 번에 Import 하는 기능을 제공한다. 메뉴 > Admin < Import SPDX Information을 클릭한다.

그러면, 곧 SPDX License List가 자동으로 등록됩니다. 메뉴 > Licenses에서 338개의 License가 등록된 것을 확인할 수 있다.

2. Component 및 Release 등록

SW360에서 Component는 하나의 소프트웨어 단위이다. 여기에는 다양한 형태의 소프트웨어가 해당할 수 있으며, 그 예는 다음과 같다.

오픈소스 소프트웨어
라이브러리
3rd party 소프트웨어

Component는 다음과 같은 정보를 포함한다.

Component Name
Main Licenses
Categories (예: Library, Cloud, Mobile, …)
Component Type (예: OSS, Internal, InnerSource, Service, Freeware)
Default Vendor
Homepage URL

Release는 Component에서 하나의 Version을 가리키는 단위이다. 따라서 하나의 Component는 여러 개의 Release를 가질 수 있다. Release는 하나의 Component 하위에 생성되어 관리된다.

Release는 다음과 같은 정보들을 포함한다.

Component Name
Version
License
Download URL
CPE ID (예: cpe:2.3:a:apache:maven:3.0.4)

예를 들어, zlib-1.2.8을 등록해야 한다면, 먼저 Component에 zlib을 먼저 등록한 후, Release에 zlib 1.2.8을 등록한다. Menu > Components > Add Component를 선택하면 Create Component 화면으로 진입하여 zlib에 대한 정보를 등록할 수 있다.

Component를 생성하면, Components > Releases > Add Release에서 zlib-1.2.8 version에 대한 정보를 등록할 수 있다.

하나의 zlib이라는 Component에 1.2.8과 1.2.11 version을 각각의 Release로 등록하였을 때, Release Overview 화면에서 다음과 같이 2개의 Release가 존재하는 것을 볼 수 있다.

SW360은 다수의 Component 정보를 Import 시키기 위한 기능을 제공한다. 메뉴 > Admin > Import / Export에 CSV template에 등록을 원하는 Component 정보를 입력 후 Import 할 수 있다.

단, 이 기능은 2020년 2월 기준 아직 안정적으로 동작하지 않을 수 있다.

3. Project 생성

Project는 하나의 제품을 가리킨다. 사업 유형에 따라 제품일수도 있고, 서비스 혹은 소프트웨어 일수도 있다. Project에는 제품에 사용된 Component/Release를 등록하여 관리한다.

Project 생성 시에는 다음과 같은 정보를 등록한다.

Project Name
Version
Project type (예: Product, Customer Project, Service, Internal Project, InnerSource)

메뉴 > Projects > Add Project를 통해 Project를 생성할 수 있다.

Project를 생성하고 나면, 포함하는 Release나 하위 Project를 등록한다. 메뉴 > Projects에서 해당 Project를 선택하면 “Linked Releases and Projects”에서 Linked Projects와 Linked Releases를 등록할 수 있다.

다음은 SuperCalc라는 Project에 OpenSSL 1.0.1과 zlib 1.2.8을 Linked Releases로 등록한 이후의 화면이다.

4. 보안 취약점 관리

SW360은 등록된 Release에 대해 보안 취약점이 있는지 자동으로 확인할 수 있다. 이를 위해 SW360은 CVE 정보를 주기적으로 수집하도록 스케쥴링하는 기능을 제공한다. 메뉴 > Admin > Schedule 에서 CVE SEARCH 정보를 24시간마다 수집하도록 스케쥴링을 설정할 수 있다.

이렇게 스케쥴링을 설정하면 SW360은 정해진 시간에 CVE Search 사이트(https://cve.circl.lu/)에서 CVE 정보를 수집한다. 수집한 CVE 정보는 메뉴 > Vulnerabilities에서 확인할 수 있다.

이렇게 Vulnerabilities 정보가 수집된 이후에는 생성한 Project에 보안 취약점이 있는지 조회할 수 있다. 위에서 생성한 SuperCalc Project에서는 85개의 보안 취약점이 보고된 것을 확인할 수 있다.

이와 같은 방법으로 기업에서 개발/배포하는 소프트웨어를 SW360에 등록하여 관리한다면, 오픈소스 컴플라이언스뿐만 아니라 보안 취약점에 대해서도 리스크를 최소화할 수 있는 형태로 관리가 가능하다.

또한 SW360은 위와 같은 Web Interface 뿐만 아니라 대부분의 기능을 REST API로 제공하여서 FOSSology 등의 다른 도구와의 연동이 가능하다. : https://github.com/eclipse/sw360/wiki/Dev-REST-API

즉, 소스 코드 스캐닝 도구의 분석 결과를 SW360에 Import 시키는 등의 방법으로 DevOps에 Integration 시켜서 Project, Release 등록을 자동화시켜서 관리한다면 효율성이 크게 증가될 것이다.

3 - FOSSLight

FOSSLight는 LG Electronics가 주도하는 오픈소스 컴플라이언스 도구 모음입니다. 소스 코드·의존성·바이너리를 분석하는 FOSSLight Scanner와, 분석 결과를 중앙에서 관리하는 웹 플랫폼 FOSSLight Hub로 구성됩니다.

GitHub (Hub): https://github.com/fosslight/fosslight
GitHub (Scanner): https://github.com/fosslight/fosslight_scanner
공식 문서: https://fosslight.org/fosslight-guide/
라이선스: AGPL-3.0-only

주요 특징

FOSSLight Hub

컴플라이언스 프로세스 통합 관리: 프로젝트별 BOM 관리, 라이선스 의무사항 이행, 공지문 생성까지 일괄 처리
취약점 모니터링: NVD·CVE 연동으로 사용 중인 오픈소스의 취약점 현황 추적
3rd Party 관리: 외부 소프트웨어 공급망의 오픈소스 현황 등록 및 관리
SBOM 관리: SPDX(ISO 표준) 형식 지원

FOSSLight Dependency Scanner

14개 이상의 패키지 매니저 지원: NPM, Yarn, Maven, Gradle, PyPI, Go, Cargo, NuGet, CocoaPods 등
자동 감지: manifest 파일을 자동으로 탐지하여 분석
직·간접 의존성 분석: 전이적 의존성까지 재귀적으로 수집
다양한 출력 형식: Excel, SPDX, CycloneDX, YAML, CSV

FOSSLight Hub 설치

Docker Compose를 사용합니다. 공식 저장소를 clone하여 실행합니다.

# 저장소 clone
git clone https://github.com/fosslight/fosslight.git
cd fosslight

# 실행 (db + web 서비스만 기동)
docker compose up -d db web

기본적으로 웹 UI는 포트 8180에서 실행됩니다.

첫 실행 시 DB 초기화와 애플리케이션 기동에 1~2분 소요됩니다. docker compose logs -f web 으로 기동 상태를 확인할 수 있습니다.

초기 로그인

브라우저에서 http://localhost:8180 접속 후 아래 계정으로 로그인합니다.

항목	값
ID	`admin`
Password	`admin`

최초 로그인 후 비밀번호를 즉시 변경하세요. 기능을 먼저 체험하려면 데모 사이트를 이용할 수 있습니다.

서버 관리

# 중지
docker compose stop db web

# 재시작
docker compose start db web

# 완전 종료 (볼륨 유지)
docker compose down

FOSSLight Dependency Scanner 설치 및 사용

Python 3.10 이상 환경에서 설치합니다. virtualenv 사용을 권장합니다.

pip3 install fosslight_dependency

기본 사용법

# 현재 디렉토리 분석 (패키지 매니저 자동 감지)
fosslight_dependency

# 경로 지정 분석
fosslight_dependency -p /path/to/project

# 출력 형식 지정 (excel/csv/yaml/spdx-json/cyclonedx-json)
fosslight_dependency -p /path/to/project -f yaml -o ./output

# 특정 경로 제외
fosslight_dependency -p /path/to/project -e "test/" "node_modules/"

분석 결과는 fosslight_report_dep_[날짜시간].xlsx 파일로 저장됩니다.

패키지 매니저별 사전 조건

일부 패키지 매니저는 분석 전 빌드 도구 설치가 필요합니다.

패키지 매니저	사전 조건
NPM / Yarn	`npm install -g license-checker`
Gradle	`./gradlew downloadLicenses` 실행
Maven	Maven 3.5.4+, Java 11+
Go / Cargo / Helm	별도 조건 없음
CocoaPods	macOS, `pod install` 완료

FOSSLight Hub와의 연동 흐름

fosslight_dependency 실행
    → SBOM 파일(xlsx/spdx/cyclonedx) 생성
        → FOSSLight Hub에 프로젝트 생성
            → 스캔 결과 업로드
                → 라이선스·취약점 현황 확인

참고 자료

FOSSLight Hub 가이드: https://fosslight.org/hub-guide/
FOSSLight Scanner 가이드: https://fosslight.org/fosslight-guide/
데모 사이트: https://demo.fosslight.org/
FOSSLight GitHub: https://github.com/fosslight

4 - OSV-SCALIBR

OSV-SCALIBR (Open Source Vulnerabilities - Software Composition Analysis LIBRary)은 Google이 개발한 오픈소스 소프트웨어 구성 분석 도구입니다. 파일시스템, 컨테이너 이미지, 바이너리를 스캔하여 포함된 패키지를 식별하고, OSV(Open Source Vulnerabilities) 데이터베이스와 대조하여 알려진 취약점을 검출합니다. SPDX, CycloneDX 형식의 SBOM 생성도 지원합니다.

GitHub: https://github.com/google/osv-scalibr
라이선스: Apache-2.0

1. 주요 특징

다양한 스캔 대상 지원: 로컬 파일시스템, 컨테이너 이미지, 아카이브 파일
폭넓은 생태계 지원: Go, Python, Java(Maven), JavaScript(npm), Rust, Ruby 등
OSV DB 연동: 스캔 결과를 OSV 데이터베이스와 대조하여 CVE 등 취약점 정보 제공
다양한 SBOM 출력 형식: SPDX 2.3, CycloneDX JSON 형식으로 결과 내보내기 가능
CLI 및 라이브러리 이중 제공: 독립 실행 바이너리(CLI)와 Go 라이브러리 모두 제공

2. 설치 방법

Go 1.21 이상이 설치된 환경에서 아래 명령으로 설치합니다.

go install github.com/google/osv-scalibr/binary/scalibr@latest

설치 후 바이너리는 $(go env GOPATH)/bin/scalibr 경로에 위치합니다. PATH에 $(go env GOPATH)/bin이 포함되어 있으면 scalibr 명령으로 바로 실행할 수 있습니다.

또는 소스에서 직접 빌드할 수 있습니다.

git clone https://github.com/google/osv-scalibr.git
cd osv-scalibr
go build -o scalibr ./binary/scalibr/...

3. 기본 사용법

OSV-SCALIBR은 서브커맨드 없이 플래그(flag) 방식으로 실행합니다.

(1) 파일시스템 스캔

# 현재 디렉토리 스캔 후 결과 파일 생성
scalibr --root=. --result=result.textproto

# SPDX JSON 형식으로 SBOM 생성
scalibr --root=/path/to/project -o spdx23-json=sbom.spdx.json

# CycloneDX JSON 형식으로 SBOM 생성
scalibr --root=/path/to/project -o cdx-json=sbom.cdx.json

# 여러 형식 동시 출력
scalibr --root=/path/to/project \
  --result=result.textproto \
  -o spdx23-json=sbom.spdx.json \
  -o cdx-json=sbom.cdx.json

(2) 컨테이너 이미지 스캔

# 원격 이미지 스캔
scalibr --remote-image=ubuntu:22.04 --result=result.textproto -o cdx-json=sbom.cdx.json

# 로컬 Docker 이미지 스캔 (docker image ls 에 표시되는 이미지)
scalibr --image-local-docker=ubuntu:22.04 --result=result.textproto

(3) 결과 확인

# CycloneDX JSON 결과에서 컴포넌트 목록 조회
cat sbom.cdx.json | jq '.components[].name'

# SPDX JSON 결과에서 패키지 목록 조회
cat sbom.spdx.json | jq '.packages[].name'

4. 활용 시나리오

OSV-SCALIBR은 CI/CD 파이프라인에 통합하여 빌드·배포 단계에서 자동으로 취약점을 검출하는 데 적합합니다.

# GitHub Actions 예시
- name: Install OSV-SCALIBR
  run: go install github.com/google/osv-scalibr/binary/scalibr@latest

- name: Run OSV-SCALIBR
  run: |
    scalibr --root=. -o cdx-json=sbom.cdx.json --result=result.textproto

- name: Upload SBOM
  uses: actions/upload-artifact@v4
  with:
    name: sbom
    path: sbom.cdx.json

5. 참고 자료

OSV-SCALIBR GitHub: https://github.com/google/osv-scalibr
OSV 데이터베이스: https://osv.dev/
SPDX 공식 사이트: https://spdx.dev/
CycloneDX 공식 사이트: https://cyclonedx.org/

5 - cdxgen

cdxgen은 OWASP(Open Web Application Security Project)가 관리하는 오픈소스 SBOM 생성 도구입니다. 소스 코드, 빌드 결과물, 컨테이너 이미지를 분석하여 CycloneDX 형식의 SBOM을 자동으로 생성합니다.

GitHub: https://github.com/CycloneDX/cdxgen
라이선스: Apache-2.0

주요 특징

광범위한 언어·생태계 지원: Java(Maven/Gradle), Node.js, Python, Go, Rust, PHP, Ruby, .NET 등 20개 이상
다양한 스캔 대상: 소스 코드 디렉토리, 컨테이너 이미지, GitHub 저장소
CycloneDX 표준 출력: CycloneDX 1.4/1.5/1.6 JSON 및 XML 형식 지원
REPL 모드: 대화형 인터페이스로 SBOM 탐색 및 조회 가능
CI/CD 통합: GitHub Actions, GitLab CI 등 주요 파이프라인과 쉽게 연동

설치 방법

Node.js 18 이상이 설치된 환경에서 아래 명령으로 설치합니다.

npm install -g @cyclonedx/cdxgen

또는 Docker 이미지를 사용할 수 있습니다.

docker pull ghcr.io/cyclonedx/cdxgen

기본 사용법

참고: 환경변수에 API 키가 설정된 경우 SECURE MODE 경고 메시지가 출력될 수 있습니다. 이는 빌드 도구가 환경변수를 읽을 수 있음을 알리는 정보성 메시지로, 스캔 결과에는 영향을 주지 않습니다.

(1) 소스 코드 디렉토리 스캔

# 현재 디렉토리 스캔 후 CycloneDX JSON SBOM 생성
cdxgen -o sbom.json .

# 언어 명시 스캔 (자동 감지 실패 시)
cdxgen -t java -o sbom.json /path/to/project

(2) 컨테이너 이미지 스캔

cdxgen -t docker -o sbom.json ubuntu:22.04

(3) GitHub 저장소 스캔

cdxgen -t github -o sbom.json https://github.com/org/repo

(4) REPL 모드로 SBOM 탐색

cdxgen --repl -o sbom.json .

CI/CD 연동 예시

# GitHub Actions 예시
- name: Generate SBOM with cdxgen
  run: |
    npm install -g @cyclonedx/cdxgen
    cdxgen -o sbom.json .
- name: Upload SBOM
  uses: actions/upload-artifact@v4
  with:
    name: sbom
    path: sbom.json

참고 자료

cdxgen GitHub: https://github.com/CycloneDX/cdxgen
CycloneDX 표준: https://cyclonedx.org/
OWASP CycloneDX: https://owasp.org/www-project-cyclonedx/

6 - Syft

Syft는 Anchore가 개발한 오픈소스 SBOM 생성 CLI 도구입니다. 컨테이너 이미지, 파일시스템, 아카이브를 스캔하여 포함된 패키지를 식별하고 SPDX 또는 CycloneDX 형식의 SBOM을 생성합니다.

GitHub: https://github.com/anchore/syft
라이선스: Apache-2.0

주요 특징

다양한 스캔 대상: 컨테이너 이미지(Docker, OCI), 로컬 파일시스템, tar 아카이브
폭넓은 생태계 지원: Alpine(apk), Debian/Ubuntu(dpkg), RPM, Python, Java, Go, Node.js, Ruby, Rust 등
표준 출력 형식: SPDX 2.2/2.3 (JSON·tag-value), CycloneDX 1.4/1.5 (JSON·XML), Syft JSON
Grype 연동: Anchore의 취약점 스캐너 Grype와 자연스럽게 연동하여 SBOM 기반 취약점 분석 가능
빠른 설치: 단일 바이너리 배포, 별도 런타임 불필요

설치 방법

스크립트 설치 (Linux/macOS)

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

Homebrew (macOS)

brew install syft

Docker

docker pull anchore/syft

기본 사용법

(1) 컨테이너 이미지 스캔

# Docker 이미지 스캔 (SPDX JSON 출력)
syft ubuntu:22.04 -o spdx-json=sbom.spdx.json

# CycloneDX JSON 출력
syft ubuntu:22.04 -o cyclonedx-json=sbom.cdx.json

(2) 로컬 디렉토리 스캔

syft dir:/path/to/project -o spdx-json=sbom.spdx.json

(3) 표준 출력으로 결과 확인

# 터미널에서 패키지 목록 확인
syft ubuntu:22.04

# JSON 형식으로 표준 출력
syft ubuntu:22.04 -o json

(4) Grype와 연동하여 취약점 스캔

# Syft로 SBOM 생성 후 Grype로 취약점 분석
syft ubuntu:22.04 -o json | grype

CI/CD 연동 예시

# GitHub Actions 예시
- name: Generate SBOM with Syft
  uses: anchore/sbom-action@v0
  with:
    image: myapp:latest
    format: spdx-json
    output-file: sbom.spdx.json
- name: Upload SBOM
  uses: actions/upload-artifact@v4
  with:
    name: sbom
    path: sbom.spdx.json

참고 자료

Syft GitHub: https://github.com/anchore/syft
Grype(취약점 스캐너): https://github.com/anchore/grype
SPDX 표준: https://spdx.dev/
CycloneDX 표준: https://cyclonedx.org/

7 - Dependency-Track

Dependency-Track은 OWASP가 관리하는 오픈소스 SBOM 관리 및 취약점 분석 플랫폼입니다. 업로드된 SBOM(CycloneDX, SPDX)을 기반으로 컴포넌트별 취약점을 지속적으로 모니터링하고, 정책 위반 여부를 자동으로 평가합니다.

GitHub: https://github.com/DependencyTrack/dependency-track
공식 문서: https://docs.dependencytrack.org/
라이선스: Apache-2.0

주요 특징

SBOM 기반 지속 모니터링: SPDX 및 CycloneDX 형식의 SBOM을 업로드하면 컴포넌트별 최신 취약점을 자동으로 추적
다양한 취약점 데이터소스 연동: NVD, OSV, GitHub Advisories, VulnDB 등
정책 엔진: 라이선스 정책, 취약점 심각도 기준, 컴포넌트 사용 가능 여부를 규칙으로 정의하여 자동 평가
REST API: CI/CD 파이프라인과 통합하여 빌드 시 SBOM을 자동 업로드하고 결과를 피드백
웹 UI 대시보드: 프로젝트별 위험 점수, 취약점 현황, 라이선스 분포를 한눈에 파악
알림: Slack, 이메일, Webhook 등 다양한 채널로 신규 취약점 알림 발송

설치 방법

Docker Compose를 사용하는 방법이 가장 간편합니다.

# 공식 Docker Compose 파일 다운로드
curl -LO https://raw.githubusercontent.com/DependencyTrack/dependency-track/HEAD/src/main/docker/docker-compose.yml

# 실행
docker compose up -d

기본적으로 API 서버는 포트 8081, 프론트엔드는 포트 8080에서 실행됩니다. 초기 관리자 계정: admin / admin (최초 로그인 후 즉시 변경 필요)

기본 사용법

(1) 웹 UI에서 프로젝트 생성 및 SBOM 업로드

http://localhost:8080 접속
Projects → Create Project 클릭
프로젝트 이름·버전 입력 후 저장
해당 프로젝트 → Components 탭 → Upload BOM 클릭
SBOM 파일(.cdx.json 또는 .spdx.json) 업로드

업로드 후 Dependency-Track이 자동으로 취약점 분석을 시작합니다.

(2) API를 통한 SBOM 업로드 (CI/CD 연동)

# API Key는 Administration > Access Management > Teams에서 발급
API_KEY="your-api-key"
PROJECT_UUID="your-project-uuid"

curl -X PUT \
  "http://localhost:8081/api/v1/bom" \
  -H "X-Api-Key: ${API_KEY}" \
  -H "Content-Type: multipart/form-data" \
  -F "project=${PROJECT_UUID}" \
  -F "bom=@sbom.cdx.json"

(3) GitHub Actions 연동 예시

- name: Upload SBOM to Dependency-Track
  uses: DependencyTrack/gh-upload-sbom@v3
  with:
    serverhostname: dependency-track.example.com
    apikey: ${{ secrets.DT_API_KEY }}
    project: ${{ secrets.DT_PROJECT_UUID }}
    bomfilename: sbom.cdx.json

cdxgen / Syft와 함께 사용하기

Dependency-Track은 SBOM 생성 도구(cdxgen, Syft)와 함께 사용할 때 가장 효과적입니다.

cdxgen 또는 Syft  →  SBOM 생성  →  Dependency-Track 업로드  →  지속 모니터링

SBOM 생성: cdxgen 또는 Syft로 빌드 시 SBOM 생성
중앙 관리: Dependency-Track에 업로드하여 전사 프로젝트 취약점 현황 통합 관리

cdxgen과 Dependency-Track을 조합하여 라이선스 정책 및 취약점 모니터링 환경을 처음부터 구축하는 방법은 오픈소스 관리 자동화 환경 구성: cdxgen + Dependency-Track을 참조하시기 바랍니다.

참고 자료

Dependency-Track 공식 문서: https://docs.dependencytrack.org/
Dependency-Track GitHub: https://github.com/DependencyTrack/dependency-track
CycloneDX 표준: https://cyclonedx.org/

8 - 오픈소스 관리 자동화 환경 구성: cdxgen + Dependency-Track

오픈소스 관리를 처음 시작하는 기업이 하루 안에 기본 자동화 환경을 갖출 수 있는 도구 조합으로 cdxgen + Dependency-Track을 권장합니다.

이 가이드는 설치·설정부터 라이선스·취약점 점검 환경 구성, 일상 운영까지 단계별로 안내합니다.

왜 cdxgen + Dependency-Track인가

오픈소스 관리의 핵심은 두 가지입니다.

무엇이 들어있는지 파악 — SBOM(Software Bill of Materials) 생성
위험 요소 지속 모니터링 — 취약점(CVE)·라이선스 정책 위반 탐지

cdxgen은 1번을, Dependency-Track은 2번을 담당합니다. 두 도구 모두 Apache-2.0 라이선스의 무료 오픈소스입니다.

전체 자동화 흐름

flowchart TD
    A["개발자 PC / CI·CD 파이프라인"] --> B["cdxgen 실행\n소스코드·컨테이너 이미지 스캔"]
    B -->|"CycloneDX SBOM (.json)"| C["Dependency-Track\n중앙 서버 자동 분석"]
    C --> D["취약점(CVE) 탐지\n→ 담당자 알림"]
    C --> E["라이선스 정책 위반\n→ 검토 요청"]

    style A fill:#2d3748,color:#fff
    style B fill:#2b6cb0,color:#fff
    style C fill:#2b6cb0,color:#fff
    style D fill:#c53030,color:#fff
    style E fill:#744210,color:#fff

이 조합을 선택한 이유

기준	내용
비용	두 도구 모두 무료 오픈소스 (Apache-2.0)
표준 준수	CycloneDX 형식 — ISO/IEC 5230 및 NTIA SBOM 요건 충족
광범위한 언어 지원	Java, Node.js, Python, Go, Rust 등 20개 이상
중앙 통합 관리	전사 프로젝트 취약점·라이선스 현황을 한 화면에서 파악
자동화 용이성	REST API 기반 — CI/CD 파이프라인 연동 간단

다른 도구와의 비교: FOSSology, SW360 등도 강력한 도구이지만 초기 설정 복잡도가 높습니다. 이 가이드의 조합은 하루 안에 기본 환경을 갖출 수 있도록 최소화했습니다. 각 도구의 상세 기능은 cdxgen 가이드와 Dependency-Track 가이드를 참고하세요.

Dependency-Track 설치

사전 준비: Docker 환경

Dependency-Track은 Docker Compose로 실행합니다. Docker가 없다면 Rancher Desktop을 설치합니다 (macOS·Windows, 무료). 설치 후 터미널에서 아래 명령으로 정상 설치를 확인합니다.

docker --version

docker compose 명령어 호환성: Docker Desktop·Rancher Desktop 환경에서는 docker compose(플러그인)를 사용합니다. macOS에서 Homebrew나 Colima로 Docker를 설치한 경우 docker-compose(하이픈)를 사용해야 할 수 있습니다. 이 가이드의 모든 docker compose 명령이 실패하면 docker-compose로 대체하세요.

설치 및 실행

홈 디렉토리에 전용 폴더를 만들고 공식 설정 파일을 받아 실행합니다.

# 1. 작업 폴더 생성 (홈 디렉토리 기준)
mkdir ~/dependency-track && cd ~/dependency-track

# 2. 공식 docker-compose.yml 다운로드
curl -LO https://raw.githubusercontent.com/DependencyTrack/dependency-track/HEAD/src/main/docker/docker-compose.yml

# 3. 실행 (처음 실행 시 이미지 다운로드로 1~2분 소요)
docker compose up -d

API 서버는 포트 8081, 프론트엔드는 포트 8080에서 실행됩니다.

초기 로그인

브라우저에서 http://localhost:8080 접속합니다.

Dependency-Track 로그인 화면

초기 계정 admin / admin으로 로그인합니다. 로그인 직후 비밀번호 변경 화면이 자동으로 표시됩니다. 즉시 새 비밀번호로 변경하세요.

브라우저에서 로그인이 정상적으로 되지 않는 경우, API 서버(8081 포트)가 완전히 기동될 때까지 추가로 1~2분 대기 후 재시도하세요.

서버 관리

# 시작 (PC 재부팅 후)
cd ~/dependency-track && docker compose up -d

# 중지
docker compose down

# 상태 확인
docker compose ps

초기 설치 후 NVD 등 취약점 데이터베이스 동기화에 최소 24시간 이상 소요됩니다. 서버 로그에 Mirroring 메시지가 출력되는 것은 정상입니다. 동기화 완료 전에는 취약점이 탐지되지 않을 수 있습니다.

Vulnerability Sources 최소 권장 설정

기본값으로 다수의 취약점 소스가 활성화되어 있습니다. 처음부터 모두 켜면 중복 알림이 과도하게 발생하여 관리 부담이 커집니다.

권장: 초기에는 NVD + GitHub Advisories 중심으로 시작

Administration → Vulnerability Sources에서 아래 표를 참고하여 설정합니다.

소스	권장 설정	이유
NVD	활성화 + API 미러링 ON	CVE 기반 표준 DB. CVSS 점수 포함. 필수
GitHub Advisories	활성화 + PAT 입력	npm·Python·Go·Ruby 생태계 패키지 보안 권고. NVD와 보완적
Google OSV	초기 비활성화	NVD·GitHub와 중복이 많아 알림 폭증 원인. 운영 안정 후 필요 시 추가
OSS Index	초기 비활성화	계정 등록 필요. 중복 커버리지
VulnDB	비활성화	유료 서비스

운영 팁: 6개월 이상 운영 후 탐지 누락이 있다고 판단되면 OSV를 추가 활성화하세요. 처음부터 전부 켜는 것보다 점진적으로 확장하는 방식을 권장합니다.

NVD (필수): API 미러링으로 설정

Enable mirroring via API가 OFF이면 구버전 feed 방식으로 동작할 수 있어 최신 환경에서는 동기화 실패 또는 지연 가능성이 큽니다. 반드시 API 미러링을 사용하세요.

Enable NVD mirroring: ON
Enable mirroring via API: ON
API endpoint: https://services.nvd.nist.gov/rest/json/cves/2.0 (기본값 유지)
API key: NVD에서 발급받은 키 입력
Additionally download feeds: OFF 유지 (일반 운영에서는 불필요)

적용 후 Last Modification이 비어 있으면 초기 동기화가 진행 중일 수 있습니다. 초기 동기화 완료 후 값이 채워지는지 확인하세요.

GitHub Advisories: PAT 없으면 동작하지 않음

GitHub Advisory 미러링은 Personal Access Token(PAT) 입력이 필요합니다.

Enable GitHub Advisory mirroring: ON
Enable vulnerability alias synchronization: ON 유지
Personal Access Token: classic PAT(ghp_...) 입력

참고: fine-grained PAT(github_pat_...)은 환경에 따라 인증 이슈가 보고되어 classic PAT 사용을 권장합니다.

Google OSV: Ecosystem 선택이 있어야 활성화

OSV는 Ecosystem을 하나 이상 선택해야 실제 미러링이 동작합니다.

Select ecosystem to enable Google OSV Advisory mirroring: ON
Enable vulnerability alias synchronization: ON
OSV Base URL: 기본값 유지
Ecosystem(예시): PyPI, npm, Maven, Go, Linux (환경에 따라 NuGet, RubyGems, crates.io 추가)

적용 순서 (권장)

# 설정 저장 후 미러링 로그 확인
docker compose logs -f dtrack-apiserver | grep -iE "nvd|github|osv|mirror"

필요 시 초기 설정 반영을 위해 API 서버를 재시작합니다.

docker compose restart dtrack-apiserver

라이선스 정책 설정

Dependency-Track의 정책 엔진(Policy Engine)을 사용하면 라이선스 위반을 자동으로 탐지할 수 있습니다.

좌측 메뉴 → Policy Management → 화면 우측 상단 Create Policy 클릭

정책 1: Copyleft 라이선스 경고

독점 소프트웨어에 Copyleft 라이선스 컴포넌트가 포함되면 소스 공개 의무가 발생할 수 있습니다. 검토 트리거를 위한 경고로 설정합니다.

정책 기본 설정:

항목	설정값
Policy Name	`Copyleft License Warning`
Policy Operator	`ANY` (조건 중 하나라도 일치하면 발동)
Violation State	`WARN`

Create 버튼으로 정책 저장 후, 생성된 정책을 클릭하여 상세 화면으로 진입합니다. Conditions 섹션에서 + Add Condition을 클릭하여 라이선스마다 조건을 하나씩 추가합니다.

Condition Subject	Condition Operator	Condition Value
License	`IS`	`GPL-2.0-only`
License	`IS`	`GPL-3.0-only`
License	`IS`	`AGPL-3.0-only`
License	`IS`	`LGPL-2.1-only`
License	`IS`	`LGPL-3.0-only`

WARN으로 설정하면 빌드가 중단되지 않고 검토 요청 알림만 발송됩니다.

정책 2: 상업적 사용 제한 라이선스 차단

상업적 사용 자체를 제한하는 라이선스는 처음부터 사용을 막아야 합니다. 같은 방법으로 두 번째 정책을 생성합니다.

항목	설정값
Policy Name	`Restricted License Block`
Policy Operator	`ANY`
Violation State	`FAIL`

Condition Subject	Condition Operator	Condition Value
License	`IS`	`BUSL-1.1`
License	`IS`	`SSPL-1.0`

FAIL로 설정하면 해당 컴포넌트를 포함한 프로젝트에 위반 표시가 나타납니다.

정책 적용 범위: 정책 생성 후 Projects 탭에서 특정 프로젝트에 적용하거나, Portfolio 전체에 적용할 수 있습니다.

SKT SBOM Scanner로 빠르게 시작하기 (Easy Mode)

cdxgen을 직접 설치하지 않고 Docker만으로 SBOM을 생성하는 방법입니다. SK텔레콤이 공급망 관리를 위해 개발한 오픈소스 도구로, Node.js 설치 없이 소스코드·Docker 이미지·바이너리를 분석하여 CycloneDX JSON을 바로 출력합니다.

Dependency-Track 호환

출력 형식이 CycloneDX JSON이므로 이 섹션의 Dependency-Track에 그대로 업로드할 수 있습니다.

사전 준비

Docker v20.10 이상 및 약 4–5 GB 디스크 여유 공간이 필요합니다. 첫 실행 시 Docker 이미지 다운로드로 5–10분 소요됩니다.

설치 및 실행

# Linux / macOS
curl -O https://raw.githubusercontent.com/sktelecom/sbom-tools/main/scripts/scan-sbom.sh
chmod +x scan-sbom.sh

# 소스코드 분석 (프로젝트 루트에서 실행)
./scan-sbom.sh --project "MyApp" --version "1.0.0" --generate-only
# 결과: MyApp_1.0.0_bom.json 생성

:: Windows
curl -O https://raw.githubusercontent.com/sktelecom/sbom-tools/main/scripts/scan-sbom.bat
scan-sbom.bat --project "MyApp" --version "1.0.0" --generate-only

Docker 이미지, 바이너리·펌웨어, RootFS 분석도 지원합니다.

# Docker 이미지 분석
./scan-sbom.sh --target "myapp:v1.0" --project "MyApp" --version "1.0" --generate-only

# 펌웨어 분석
./scan-sbom.sh --target firmware.bin --project "RouterOS" --version "2.0" --generate-only

Dependency-Track에 업로드

생성된 *_bom.json 파일을 아래 명령으로 업로드합니다.

curl -X "POST" "http://localhost:8081/api/v1/bom" \
  -H "X-Api-Key: ${DT_API_KEY}" \
  -F "autoCreate=true" \
  -F "projectName=MyApp" \
  -F "projectVersion=1.0.0" \
  -F "bom=@MyApp_1.0.0_bom.json"

지원 언어

Java, Python, Node.js, Go, Rust, Ruby, PHP, .NET, C/C++(패키지 매니저 사용 시)를 한 번에 분석합니다. C/C++ 헤더 직접 관리 방식·정적 링크 바이너리는 감지에 한계가 있습니다.

소스: github.com/sktelecom/sbom-tools (Apache-2.0)

cdxgen SBOM 생성 및 자동 업로드

API Key 발급

자동화 스크립트가 Dependency-Track에 SBOM을 업로드하려면 API Key가 필요합니다.

Administration → Access Management → Teams

Teams 관리 화면

+ Create Team 클릭 → 팀 이름 Automation Agents 입력 후 Create
생성된 팀을 클릭하여 상세 화면 진입
Permissions 섹션에서 아래 두 항목 체크:
- BOM_UPLOAD (SBOM 업로드 권한)
- PROJECT_CREATION_UPLOAD (프로젝트 자동 생성 권한)
API Keys 섹션 → + Create API Key 클릭

API Key 생성 화면

생성된 키(odt_publicId_... 형식)를 복사하여 안전한 곳에 보관합니다. 키는 생성 직후에만 전체 값을 확인할 수 있습니다.

cdxgen 설치

npm install -g @cyclonedx/cdxgen

Node.js가 없는 환경에서는 Docker 이미지를 사용할 수 있습니다. 자세한 설치 방법은 cdxgen 가이드를 참고하세요.

SBOM 생성 및 업로드 스크립트

아래 스크립트를 scan-upload.sh로 저장하면 SBOM 생성과 업로드를 한 번에 처리합니다.

버전 호환성: cdxgen 최신 버전(v12+)은 CycloneDX 1.7 형식을 기본 생성하지만, Dependency-Track v4.14 기준 CycloneDX 1.6까지 지원합니다. --spec-version 1.6 옵션을 반드시 지정하세요.

#!/bin/bash
# 사용법: ./scan-upload.sh <프로젝트명> <버전>
# 예시:   ./scan-upload.sh "my-app" "1.0.0"

PROJECT_NAME="${1:?프로젝트명을 입력하세요}"
PROJECT_VERSION="${2:?버전을 입력하세요}"
DT_URL="http://localhost:8081"
API_KEY="${DT_API_KEY:?환경변수 DT_API_KEY를 설정하세요}"

# SBOM 생성
echo "[1/2] SBOM 생성 중..."
cdxgen -r --spec-version 1.6 -o sbom.json .

if [ ! -s sbom.json ]; then
  echo "SBOM 생성 실패: package.json, pom.xml 등 의존성 파일이 있는지 확인하세요."
  exit 1
fi

# Dependency-Track 업로드
echo "[2/2] Dependency-Track 업로드 중..."
RESPONSE=$(curl -s -X POST "${DT_URL}/api/v1/bom" \
  -H "X-Api-Key: ${API_KEY}" \
  -F "autoCreate=true" \
  -F "projectName=${PROJECT_NAME}" \
  -F "projectVersion=${PROJECT_VERSION}" \
  -F "bom=@sbom.json")

if echo "${RESPONSE}" | grep -q '"token"'; then
  echo "업로드 완료: http://localhost:8080 에서 결과를 확인하세요."
else
  echo "업로드 실패: ${RESPONSE}"
  exit 1
fi

# 실행 방법
export DT_API_KEY="발급받은_API_KEY"
chmod +x scan-upload.sh
./scan-upload.sh "my-app" "1.0.0"

업로드 후 Dependency-Track에서 프로젝트가 자동 생성된 것을 확인합니다.

업로드 완료 후 Projects 목록

결과 확인 및 일상 운영

대시보드 개요

http://localhost:8080 → Dashboard

Dependency-Track 대시보드

항목	내용
Portfolio Vulnerabilities	전사 프로젝트의 취약점 심각도별 현황
Projects at Risk	위험도가 높은 프로젝트 목록
Policy Violations	라이선스 정책 위반 현황

취약점 Triage 기준

Projects → 프로젝트 선택 → Audit Vulnerabilities 탭

무조건 모든 Critical 취약점을 긴급 처리할 필요는 없습니다. 아래 3단계로 판단합니다.

flowchart TD
    A["취약점 발견"] --> B{"실제 사용 중인\n버전인가?"}
    B -- 아니오 --> C["Not Affected 처리\n(스캐너 오탐)"]
    B -- 예 --> D{"취약한 기능을\n우리 코드가 호출하는가?"}
    D -- 아니오 --> E["Not Affected 처리\n+ 사유 Comment 기록"]
    D -- 예 --> F{"패치 버전이\n존재하는가?"}
    F -- 예 --> G["Exploitable 설정\n개발팀에 업그레이드 요청"]
    F -- 아니오 --> H["In Triage 설정\n완화 조치 검토"]

    style C fill:#276749,color:#fff
    style E fill:#276749,color:#fff
    style G fill:#c53030,color:#fff
    style H fill:#744210,color:#fff

라이선스 정책 위반 대응

좌측 메뉴 → Policy Violation Audit에서 전사 위반 항목을 확인합니다.

WARN (경고): 개발팀과 라이선스 사용 여부 협의 후 문제없으면 Approved 처리
FAIL (차단): 해당 컴포넌트를 허용 라이선스 버전으로 교체 요청

일상 점검 체크리스트

주기	점검 항목
매일	Dashboard에서 신규 Critical 취약점 발생 여부 확인
매주	`Not Set` 상태 취약점을 `Exploitable` 또는 `Not Affected`로 분류
매월	팀별 Risk Score 변화 추이 검토 (점수 감소 추세가 정상)

9 - SCANOSS

SCANOSS는 오픈소스 컴포넌트를 파일 단위뿐 아니라 스니펫(코드 조각) 단위까지 식별할 수 있는 소프트웨어 구성 분석(SCA) 도구입니다. 1억 개 이상의 파일을 인덱싱한 지식베이스(OSSKB, Open Source Knowledge Base)와 대조하여 라이선스·저작권 정보를 검출하고, CycloneDX·SPDX 형식의 SBOM을 자동으로 생성합니다.

GitHub: https://github.com/scanoss
공식 사이트: https://www.scanoss.com
라이선스: Apache-2.0

1. 주요 특징

스니펫 수준 매칭: 파일 전체가 아닌 코드 일부를 복사·수정한 경우도 출처 추적 가능
대규모 지식베이스: OSSKB에 1억 개 이상의 오픈소스 파일 인덱싱 — 주요 패키지 저장소와 GitHub 커버
SBOM 자동 생성: CycloneDX(JSON/XML) 및 SPDX 형식 출력 지원
CLI & REST API 이중 제공: scanoss-py(Python) CLI와 REST API를 모두 지원하여 자동화 통합이 용이
CI/CD 파이프라인 통합: GitHub Actions 등 CI 환경에서 커맨드 한 줄로 스캔 가능

2. 설치 방법

Python 3.8 이상 환경에서 pip로 설치합니다.

pip install scanoss

설치 확인:

scanoss-py --version

3. 기본 사용법

(1) 디렉토리 스캔

# 현재 디렉토리 스캔 후 결과를 JSON으로 저장
scanoss-py scan . --output results.json

(2) SBOM 생성 (CycloneDX)

# 스캔 결과를 CycloneDX JSON 형식의 SBOM으로 변환
scanoss-py convert --input results.json --format cyclonedx --output sbom.json

(3) 결과 확인

# 검출된 컴포넌트 목록 조회
cat results.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for f, matches in data.items():
    for m in matches:
        if m.get('id') != 'none':
            print(f\"{f}: {m.get('component','?')} ({m.get('licenses','?')})\")"

4. CI/CD 연동

GitHub Actions에서 스캔을 자동화하는 예시입니다.

# .github/workflows/scanoss.yml
name: SCANOSS License Scan

on: [push, pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install SCANOSS
        run: pip install scanoss
      - name: Run scan
        run: scanoss-py scan . --output results.json
      - name: Generate SBOM
        run: scanoss-py convert --input results.json --format cyclonedx --output sbom.json
      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

5. 참고 자료

SCANOSS GitHub: https://github.com/scanoss
SCANOSS 공식 문서: https://docs.scanoss.com
OSSKB 지식베이스: https://osskb.org
CycloneDX 공식 사이트: https://cyclonedx.org

10 - onot

SK텔레콤은 사내에서 사용하는 오픈소스 고지문 자동 생성 도구를 onot이라는 이름으로 오픈소스로 공개하였다. 카카오에서도 주요 기능을 기여하는 방식으로 공동 개발에 참여하였다.

주요 특징

onot은 SPDX 문서 형식으로 작성된 SBOM을 입력받아 오픈소스 고지문 형식으로 자동 변환한다. Python 기반으로 가볍고 간단하게 사용할 수 있으며, 다음과 같은 특징을 가진다.

SBOM 기반 자동 생성 — cdxgen, Syft 등으로 생성한 SPDX SBOM을 그대로 입력으로 사용
Python 기반 — 별도 서버 구축 없이 CLI 도구로 간단히 실행
오픈소스 공개 — 누구나 무료로 사용·수정·배포 가능

설치

Python 패키지 관리자(pip)로 설치한다.

pip install onot

설치와 관련한 자세한 내용은 공식 저장소를 참고한다. : https://github.com/sktelecom/onot

기본 사용법

SBOM(SPDX 형식)을 준비한 후 다음 명령어로 고지문을 생성한다.

onot -f sbom.spdx

실행하면 입력한 SBOM 파일을 분석하여 오픈소스 고지문 파일을 출력한다. 생성된 고지문은 배포 패키지에 포함하거나 오픈소스 웹사이트에 게시하여 라이선스 의무를 이행할 수 있다.

자세한 사용법은 공식 저장소의 README를 참고한다. : https://github.com/sktelecom/onot

Tools

1 - FOSSology

주요 특징

설치

테스트 서버

Basic Workflow

2 - SW360

주요 특징

설치

1. 코드 다운로드

2. 빌드

3. 실행

설정

1. User, Login 설정

2. LAR 파일 import

3. User Account 설정 (테스트용)

Basic Workflow

1. License 등록

2. Component 및 Release 등록

3. Project 생성

4. 보안 취약점 관리

3 - FOSSLight

주요 특징

FOSSLight Hub

FOSSLight Dependency Scanner

FOSSLight Hub 설치

초기 로그인

서버 관리

FOSSLight Dependency Scanner 설치 및 사용

기본 사용법

패키지 매니저별 사전 조건

FOSSLight Hub와의 연동 흐름

참고 자료

4 - OSV-SCALIBR

1. 주요 특징

2. 설치 방법

3. 기본 사용법

(1) 파일시스템 스캔

(2) 컨테이너 이미지 스캔

(3) 결과 확인

4. 활용 시나리오

5. 참고 자료

5 - cdxgen

주요 특징

설치 방법

기본 사용법

(1) 소스 코드 디렉토리 스캔

(2) 컨테이너 이미지 스캔

(3) GitHub 저장소 스캔

(4) REPL 모드로 SBOM 탐색

CI/CD 연동 예시

참고 자료

6 - Syft

주요 특징

설치 방법

스크립트 설치 (Linux/macOS)

Homebrew (macOS)

Docker

기본 사용법

(1) 컨테이너 이미지 스캔

(2) 로컬 디렉토리 스캔

(3) 표준 출력으로 결과 확인

(4) Grype와 연동하여 취약점 스캔

CI/CD 연동 예시

참고 자료

7 - Dependency-Track

주요 특징

설치 방법

기본 사용법

(1) 웹 UI에서 프로젝트 생성 및 SBOM 업로드

(2) API를 통한 SBOM 업로드 (CI/CD 연동)

(3) GitHub Actions 연동 예시

cdxgen / Syft와 함께 사용하기

참고 자료

8 - 오픈소스 관리 자동화 환경 구성: cdxgen + Dependency-Track

왜 cdxgen + Dependency-Track인가

전체 자동화 흐름

이 조합을 선택한 이유

Dependency-Track 설치

사전 준비: Docker 환경