보통 사내 개발 프레임워크, 재사용되는 공통 라이브러리, 제품 내부 바이너리 등은 다음과 같은 원칙으로 SBOM을 운영한다고 한다.

 

• OSS 라이선스 분석 대상에서는 제외시키기 위해 “Proprietary” 혹은 "Internal component"로 태깅하여 OSS 필터링에서 자동 제외
• 자체 코드 제외는 SBOM 누락을 야기하기 때문에 빌드 스캔 시 ‘자체 코드 제외’는 지양
• NOASSERTION 은 라이선스 정보를 못 찾은 OSS 파일에 대한 “미확정 상태 표시”이므로 보안팀/컴플라이언스팀이 반드시 다시 리뷰해야함

 

 

---

 

---

1) 기업 내부 코드 자동 필터링 규칙 설계

내부 코드 자동 분류 규칙의 모범 사례입니다:

 규칙 1 — 자체 코드의 네임스페이스 기반 판단

예:

- src/company/** → 내부 코드
- src/core/** → 내부 코드
- modules/internal/** → 내부 코드

 규칙 2 — Vendor / ThirdParty 외의 디렉토리는 내부 코드로 분류

예:

/thirdparty/
/external/
/oss/

이런 폴더가 아니면 내부 코드로 간주.

 규칙 3 — 확장자 기반 예외 처리

내부 코드라도 라이선스 검토가 필요한 경우:

*.c, *.cpp, *.java, *.kt → 내부 코드
*.LICENSE, NOTICE 포함 시 외부 OSS 확인

 규칙 4 — 빌드 산출물(바이너리)은 내부 코드로 간주 (단 캐시 제외)

*.exe, *.dll, *.so, *.apk, *.jar → internal binary

---

2) Proprietary/Internal 분류 룰

구분	의미	licenseDeclared	SPDXID	포함 여부
Internal(자체 개발 코드)	사내 개발 소스/라이브러리	Proprietary	SPDXRef-Internal-xxx	SBOM에 포함
External OSS	외부 Open Source	실제 라이선스	SPDXRef-Package-OSS-xxx	SBOM에 포함
기타 산출물	빌드 결과물 • 바이너리	NONE or Proprietary	SPDXRef-Artifact-xxx	포함 가능

규칙:

• 내부 코드 = 반드시 Proprietary 또는 NONE

• 외부 OSS = 반드시 SPDX 라이선스 ID 필요

• 라이선스를 모른다 = NOASSERTION (OSS에서만 사용)

---

3) FOSSLight Scanner에서 자체 코드 제외 OR Internal labeling 자동화

방법 A — 자체 코드 제외

.fosslight_ignore 파일 사용:

src/internal/**
src/company/**
*.dll
*.exe
build/**

프로젝트 루트에 저장하면 자동 제외됨.

방법 B — 자체 코드 포함 but Internal 표기

SBOM 변환 시 다음 메타데이터 적용:

oss_name: company.internal.module
license: Proprietary
comment: Internal proprietary source code

---

4) SPDX 내부 코드 정의 예시

 패키지 단위 (Proprietary Code)

{
  "SPDXID": "SPDXRef-Internal-CoreModule",
  "name": "company-core-module",
  "downloadLocation": "NONE",
  "supplier": "Organization: MyCompany",
  "licenseDeclared": "Proprietary",
  "licenseConcluded": "Proprietary",
  "copyrightText": "NOASSERTION"
}

 파일 단위

{
  "SPDXID": "SPDXRef-File-CompanySrc1",
  "fileName": "src/company/core/utils.cpp",
  "licenseConcluded": "Proprietary",
  "comment": "Internal proprietary source file"
}

---