종속성 분석을 통한 라이선스 준수 감사

인수합병 실사 요청이 화요일 아침에 도착합니다. 모든 소프트웨어에 대한 오픈 소스 라이선스 준수 보고서를 금요일까지 제출하라는 내용입니다. 법무팀은 인수 기업의 법률 검토 전에 전체 제품 코드베이스에 포함된 모든 오픈 소스 구성 요소, 적용되는 모든 라이선스, 그리고 이행해야 할 모든 의무 사항을 목록으로 작성해야 하는 3일의 시간을 갖게 됩니다. 라이선스 준수를 주기적인 수동 검토 작업으로 취급하는 기업에게는 그 화요일 아침이 기업 소프트웨어 업계에서 가장 비용이 많이 드는 긴급 대응 훈련의 시작이 됩니다. 하지만 성숙한 의존성 분석 인프라를 갖춘 기업에게는 보고서를 실행하는 것만으로도 충분합니다.

소프트웨어는 대부분 작성되는 것이 아니라 조립되는 방식입니다. Black Duck 2026 OSSRA 보고서에 따르면 상용 코드베이스의 98%가 오픈 소스 구성 요소를 포함하고 있으며, 87%는 최소 하나 이상의 알려진 취약점을 가지고 있고, 코드베이스당 평균 취약점 수는 전년 대비 두 배 이상 증가했습니다. 라이선스 준수 감사는 이와는 다르지만 관련된 질문에 대한 답을 찾는 분야입니다. 즉, 어떤 구성 요소에 취약점이 있는지뿐만 아니라 소프트웨어의 배포, 수정 또는 상용화 방식에 대한 법적 의무를 부과하는 구성 요소는 무엇인지를 밝히는 것입니다. 독점 상용 제품에서 GPL-2.0 종속성을 누락하는 것은 단순한 보안 사고가 아닙니다. 이는 소스 코드 공개, 법적 합의 또는 제품 회수를 요구할 수 있는 라이선스 위반입니다.

라이선스 준수 감사의 핵심은 의존성 분석입니다. 의존성 분석은 코드베이스가 직간접적으로 의존하는 모든 소프트웨어 구성 요소를 체계적으로 식별하고, 각 구성 요소에 적용되는 라이선스를 완벽하게 파악하는 작업입니다. 의존성 분석은 패키지 매니페스트를 단순히 스캔하는 것이 아닙니다. 빌드 시점과 런타임에 소프트웨어에 실제로 포함된 모든 요소를 ​​구조적으로 완벽하게 검사하는 것입니다. 이때 포함된 요소들이 선언적이든, 전이적이든, 벤더링되었든, 암시적이든 관계없이 모든 경우를 고려합니다.

종속성 분석이 기초가 되는 이유

라이선스 준수는 법적인 문제이기 이전에 의존성 문제입니다. 소프트웨어 제품의 라이선스 의무를 평가하려면 먼저 해당 제품을 구성하는 모든 구성 요소, 모든 라이브러리, 모든 복제된 코드 조각을 파악해야 합니다. 라이선스 분석은 의존성 목록 작성 이후에 이루어집니다. 의존성 목록 작성이 잘못되면 라이선스 분석은 불완전한 정보를 바탕으로 진행될 수밖에 없습니다.

라이선스 규정 준수를 위해 의존성 분석에서 반드시 답해야 할 세 가지 질문:

어떤 구성 요소가 포함되어 있나요? 단순히 명시된 직접적인 종속성뿐만 아니라 package.json or pom.xml하지만 모든 전이적 종속성, 소스 트리에 복사되는 모든 벤더링 라이브러리, 바이너리에 컴파일되는 모든 정적 링크 구성 요소, 그리고 런타임에 호출되는 모든 동적 로드 모듈까지 모두 고려해야 합니다. 우수한 SCA 엔진은 이러한 구성 요소를 NVD와 같은 취약점 데이터베이스와 상호 참조하고, 라이선스 메타데이터를 확인하며, 배포 파이프라인에 영향을 미치기 전에 알려진 익스플로잇이나 법적 위험을 표시합니다. 또한 라이선스 분석을 신뢰할 수 있으려면 소프트웨어에 실제로 포함된 내용에 대한 인벤토리 수준에서도 정확해야 합니다.

해당 구성 요소 는 어떤 라이선스의 적용을 받습니까? 구성 요소는 단일 라이선스를 보유할 수도 있고, 옵션이 있는 이중 라이선스를 보유할 수도 있으며, 서로 다른 파일에 적용되는 여러 라이선스를 보유할 수도 있고, 버전별로 라이선스가 변경될 수도 있습니다. FOSSA의 라이선스 감지 엔진은 99.8%의 정확도를 자랑하며, 이는 법무팀이 보안 목록과 함께 오픈 소스 의무 사항을 검증해야 할 때 중요한 요소입니다. 구성 요소 수준에서의 라이선스 식별은 필요하지만 충분하지는 않으며, 서로 다른 파일에 서로 다른 라이선스가 적용되는 구성 요소의 경우 파일 또는 코드 조각 수준에서의 식별이 필요합니다.

각 라이선스는 어떤 의무를 부과할까요? 관대한 라이선스(MIT, Apache-2.0)는 저작자 표시를 요구합니다. 약한 카피레프트 라이선스(LGPL)는 구성 요소가 동적으로 링크되는지 정적으로 링크되는지에 따라 다른 의무를 부과합니다. 강력한 카피레프트 라이선스(GPL-2.0, GPL-3.0)는 전체 결합 작업의 소스 코드를 배포하도록 요구할 수 있습니다. 의무를 이해하려면 라이선스 식별자뿐만 아니라 라이선스 조건을 이해해야 합니다.

라이선스 노출을 유발하는 네 가지 유형의 종속성

모든 종속성이 기존 도구로 동일하게 드러나거나 관리되는 것은 아닙니다. 라이선스 노출은 각각 다른 검색 방법을 필요로 하는 네 가지 유형의 종속성에서 발생합니다.

1. 패키지 관리자 종속성(선언된 종속성 및 전이적 종속성)

가장 눈에 띄는 계층: 매니페스트 파일에 선언된 종속성(package.json, pom.xml, requirements.txt, go.mod, Cargo.toml) 및 빌드 시점에 해결되는 전이적 종속성. 패키지 관리자 종속성은 가장 잘 다뤄지는 범주이며, SCA 도구는 매니페스트, 잠금 파일 및 빌드 아티팩트를 스캔하여 이를 열거합니다.

핵심적인 구분은 직접 종속성과 전이 종속성입니다. 직접 종속성은 개발자가 직접 선택한 종속성이고, 전이 종속성은 직접 종속성이 필요로 하는 종속성입니다. 개발자가 하나의 라이브러리를 추가하면 전이 종속성이 생성됩니다. react-data-grid Node.js 프로젝트에 패키지를 추가하면 수십 개의 전이적 종속성을 가져올 수 있으며, 각 종속성에는 고유한 라이선스가 있습니다. 개발자는 이러한 라이선스를 선택하지 않았지만, 종속성 트리에는 이러한 라이선스가 존재합니다.

JSON

// package.json: 1 direct dependency declared
{
  "dependencies": {
    "react-data-grid": "^7.0.0"
  }
}

// npm lockfile resolves to 47 transitive dependencies, including:
// - react@18.2.0 (MIT)
// - clsx@1.2.1 (MIT)
// - scheduler@0.23.0 (MIT)
// - tslib@2.6.0 (0BSD)
// - ...43 more, each with its own license
// The developer declared 1 license obligation; they shipped 47.

전이적 라이선스 함정: 라이선스 위험은 여러분이 선언한 내용에 있는 것이 아닙니다. 의존성 패키지의 라이선스 선언, 그리고 그 의존성 패키지의 의존성 패키지가 선언한 내용에 있습니다. 관대한 라이선스를 사용하는 깔끔한 직접 의존성 트리 구조는 GPL 라이선스가 적용된 3단계 깊이의 전이적 의존성을 숨길 수 있으며, 이는 전체 배포판에 카피레프트 의무를 부과하게 됩니다.

2. 공급업체 제공 및 복제된 소스 코드

외부 프로젝트의 소스 코드가 저장소에 직접 복사되었는데, 이는 C/C++ 프로젝트, 모듈이 없는 Go 프로젝트, 그리고 레거시 코드베이스에서 흔히 볼 수 있는 패턴입니다. 벤더링된 코드는 종속성 관리자를 통하지 않고 복사 붙여넣기를 통해 추가되었기 때문에 패키지 관리자 매니페스트에 나타나지 않습니다.

SCANOSS의 스니펫 수준 스캔은 매니페스트 기반 탐지를 훨씬 뛰어넘어 OSSKB에 있는 100억 개 이상의 오픈 소스 파일과 소스 코드 조각을 대조합니다. 스니펫 수준 스캔은 벤더링된 코드와 복사된 함수를 식별하는 데 필수적입니다. 이러한 방식은 매니페스트에 종속성을 선언하지 않지만, 마치 해당 구성 요소가 명시적으로 포함된 것처럼 모든 라이선스 의무를 준수해야 합니다.

GPL 라이선스가 적용된 코드에서 유래한 Stack Overflow 답변에서 복사한 유틸리티 함수는 직접적인 GPL 종속성과 동일한 카피레프트 의무를 가지지만, 패키지 매니페스트, 락파일 또는 선언된 종속성만 읽는 자동 스캔 어디에도 나타나지 않습니다.

3. 정적으로 링크된 라이브러리

빌드 시 애플리케이션 바이너리에 직접 컴파일되는 라이브러리입니다. 런타임에 별도의 파일로 존재하는 동적 링크 라이브러리와 달리, 정적 링크 라이브러리는 실행 파일에 포함됩니다. 패키지 관리자 매니페스트에는 표시되지 않고 빌드 구성에 나타납니다.Makefile, CMakeLists.txt(링커 스크립트 포함) 및 컴파일된 바이너리 자체에 있습니다.

특히 LGPL 라이선스가 적용된 라이브러리의 경우, 정적 링크와 동적 링크의 구분은 라이선스 의무를 결정합니다. LGPL은 카피레프트 전파 없이 동적 링크를 허용하지만, 정적 링크는 결합된 결과물에 카피레프트 요구 사항을 발생시킬 수 있습니다. 따라서 소스 코드 매니페스트뿐만 아니라 컴파일된 결과물 전체를 분석하는 바이너리 분석 도구가 있어야 정적으로 링크된 구성 요소와 해당 라이선스를 식별할 수 있습니다.

4. 런타임 로드 종속성

라이브러리는 플러그인 아키텍처, 지연 바인딩 또는 스크립팅 엔진 통합을 통해 런타임에 동적으로 로드됩니다. 이러한 종속성은 소스 코드 분석만으로는 해결할 수 없으며, 런타임 환경, 구성 및 실행 경로에 따라 달라집니다. 리플렉션을 통해 로드되는 데이터베이스 드라이버, 서비스 로더 메커니즘을 통해 발견되는 파서 플러그인, 시작 시 파일 시스템 경로에서 로드되는 스크립팅 확장 프로그램은 모두 잠재적인 라이선스 문제를 야기할 수 있는 런타임 종속성입니다.

라이선스 위험 범주 및 관련 의무

오픈 소스 라이선스는 관대한 라이선스부터 엄격한 라이선스까지 다양한 스펙트럼에 걸쳐 있습니다. 각 라이선스가 이 스펙트럼에서 어느 위치에 있는지 파악하는 것은 해당 라이선스가 발생시키는 규정 준수 의무를 결정하는 데 중요합니다.

관대한 라이선스 (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC)

의무 사항: 출처 표기, 배포 시 라이선스 텍스트 및 저작권 고지 포함. 소스 코드 공개는 필수가 아닙니다. 상업적 사용은 제한 없이 허용됩니다. 독점 제품에 통합하는 것도 허용됩니다.

상용 소프트웨어의 위험 수준: 낮음. 저작권 귀속은 자동으로 쉽게 처리됩니다.

약한 카피레프트 라이선스 (LGPL-2.0, LGPL-2.1, LGPL-3.0, MPL-2.0, EUPL-1.2)

의무: 라이선스가 부여된 구성 요소에 대한 출처 표기 및 수정 사항을 공유해야 합니다. 특히 LGPL의 경우, 동적 링크는 일반적으로 호출 코드에 카피레프트를 발생시키지 않고 라이선스를 충족하지만, 정적 링크는 그렇지 않을 수 있습니다.

상용 소프트웨어의 위험 수준: 중간. 링크 방식에 따라 다릅니다. 동적 링크는 일반적으로 안전하지만, 정적 링크는 신중한 법률 검토가 필요합니다.

강력한 카피레프트 라이선스 (GPL-2.0, GPL-3.0, AGPL-3.0)

의무: 저작자 표시와 함께 GPL 구성 요소를 포함하는 전체 결합 저작물을 GPL 조건(소스 코드 공개)에 따라 제공해야 합니다. AGPL은 이를 네트워크를 통해 접근하는 소프트웨어까지 확장합니다.

상용 소프트웨어의 위험 수준: 높음. GPL 라이선스가 적용된 구성 요소가 독점 상용 제품에 정적으로 링크되거나 해당 제품에서 파생된 경우, 독점 소스 코드 공개가 요구될 수 있습니다. 이는 가장 큰 규모의 법적 합의금을 발생시키는 라이선스 관련 위험입니다.

네트워크 카피레프트(AGPL-3.0)

의무: GPL-3.0의 모든 의무 사항에 더하여, 네트워크를 통해 소프트웨어와 상호 작용하는 사용자는 소프트웨어를 수신하는 것으로 간주되므로, 바이너리를 배포하지 않는 SaaS 제품이라도 소스 코드 공개 의무가 발생합니다.

SaaS 제품의 위험 수준: 매우 높음. AGPL은 GPL의 "SaaS 허점"을 막기 위해 특별히 설계되었습니다. AGPL 구성 요소를 포함하는 상용 SaaS 제품은 네트워크를 통해 해당 제품과 상호 작용하는 모든 사용자에게 소스 코드를 공개해야 합니다.

독점 및 상업 라이선스

의무 사항: 라이선스 계약에 따라 정의되며, "재배포 금지"부터 "단위당 로열티", "엔터프라이즈 시트 라이선스"까지 다양합니다. 이러한 라이선스는 오픈 소스가 아니지만 상용 구성 요소를 사용할 때 종속성 트리에 나타납니다.

위험 수준: 계약 조건에 따라 다릅니다. 인수 대상 제품의 라이선스 비용 의무를 확인하는 인수합병 실사 과정에서 흔히 발견됩니다.

라이선스 호환성: 가장 중요한 요소

서로 다른 라이선스를 가진 구성 요소들을 하나의 소프트웨어 제품에 결합할 경우, 해당 라이선스들은 호환되어야 합니다. 호환되지 않는 라이선스 조합은 단순히 출처를 밝히는 것만으로는 해결할 수 없는 법적 위험을 초래하며, 해당 조합 자체가 하나 또는 두 개의 라이선스를 모두 위반할 수 있습니다.

와 결합	MIT	아파치-2.0	LGPL-2.1	GPL-2.0	GPL-3.0	PLFA-3.0
MIT	지원	지원	지원	지원	지원	지원
아파치-2.0	지원	지원	지원	호환되지 않는	지원	지원
LGPL-2.1	지원	지원	지원	지원	호환되지 않는	호환되지 않는
GPL-2.0	지원	호환되지 않는	지원	지원	호환되지 않는	호환되지 않는
GPL-3.0	지원	지원	호환되지 않는	호환되지 않는	지원	지원
소유권	지원	지원	주의	호환되지 않는	호환되지 않는	호환되지 않는

상용 소프트웨어에 있어 가장 심각한 비호환성은 Apache-2.0과 GPL-2.0의 호환성 문제입니다. Apache-2.0 라이선스가 적용된 라이브러리는 GPL-2.0 라이선스가 적용된 구성 요소와 동일한 작업에서 함께 사용할 수 없습니다. 많은 핵심 오픈 소스 구성 요소(리눅스 커널 모듈, 일부 구형 자바 라이브러리)가 GPL-3.0이 아닌 GPL-2.0 라이선스를 따르기 때문에, 이러한 비호환성은 혼합된 의존성 트리에서 실질적인 라이선스 준수 위험을 초래합니다.

AGPL-3.0 조항은 SaaS에 있어 가장 엄격한 제한 사항입니다. 사실상 상용 제품에서 AGPL-3.0을 준수하는 것은 네트워크 카피레프트 의무를 발생시키지 않고서는 거의 불가능합니다.

CI/CD 환경에서 라이선스 정책 시행

주기적인 감사에 의존하는 라이선스 준수 방식은 도입되는 순간부터 실패합니다. 예를 들어, 지난 스프린트에 추가된 GPL 종속성은 분기별 감사에서 적발되기 전에 이미 3주 동안 프로덕션 환경에 배포되어 있을 수 있습니다. 병합 단계에서의 지속적인 강제 적용만이 비준수 종속성이 코드베이스에 유입되는 것을 방지하는 유일한 접근 방식입니다.

얌

# GitHub Actions: license compliance gate on every PR
name: License Compliance Check

on:
  pull_request:

jobs:
  license-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install license checker
        run: npm install -g license-checker fossa-cli

      - name: Scan dependency licenses
        run: |
          license-checker --summary --excludePrivatePackages \
            --out license-report.json

      - name: Enforce license policy
        run: |
          # Block GPL-2.0, GPL-3.0, AGPL-3.0, SSPL in commercial product
          FORBIDDEN=$(license-checker --failOn \
            "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL" \
            --excludePrivatePackages 2>&1 || true)

          if echo "$FORBIDDEN" | grep -q "FAIL"; then
            echo "Forbidden license detected in dependencies"
            echo "$FORBIDDEN"
            exit 1
          fi

      - name: Generate SBOM artifact
        run: |
          # Generate CycloneDX SBOM for audit trail
          npx @cyclonedx/cyclonedx-npm \
            --output-file sbom-$(date +%Y%m%d).json

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

주의: 라이선스 정책은 조직별로 다릅니다. 위 예시의 금지 목록은 일반적인 상업 정책을 반영한 것이지만, 조직의 법무팀은 특정 제품 유형, 배포 모델 및 고객 계약에 따라 어떤 라이선스가 허용되고, 검토 대상으로 지정되고, 금지되는지 정의해야 합니다. 내부 도구에서 허용되는 라이브러리가 고객에게 배포하는 제품에서는 금지될 수 있습니다.

SBOM 생성 및 형식 표준

소프트웨어 구성 요소 명세서(SBOM)는 라이선스 준수 여부를 감사하고, 공유하고, 기계적으로 검증할 수 있도록 구조화된 산출물입니다. SBOM이 이러한 데이터를 제공하면 규정 준수 팀은 수동 감사 없이도 라이선스 의무 사항을 확인할 수 있습니다. 현재 시장에는 두 가지 형식이 주를 이룹니다.

OWASP에서 개발한 CycloneDX 는 보안 및 공급망 활용 사례를 위해 설계되었습니다. 구성 요소, 서비스, 취약점(VEX), 공식 및 머신 러닝 모델 기반 SBOM(제품 명세서)을 지원합니다. 보안 중심의 SBOM에 권장되는 형식이며, 대부분의 최신 SCA 도구 통합에 필요한 형식입니다.

SPDX리눅스 재단에서 유지 관리하는 ISO/IEC 표준(ISO 5962:2021)입니다. 행정명령 14028의 일부 조항을 포함한 일부 정부 조달 표준에서 요구됩니다. 보안보다는 라이선스 준수에 더 중점을 두고 있으며, 더 풍부한 라이선스 표현 언어(SPDX 표현식은 복잡한 다중 라이선스 시나리오를 처리할 수 있음)를 제공합니다. GPL-2.0-only AND MIT OR Apache-2.0).

행정명령 14028호는 이미 SBOM(표준 제품 명세서)을 제공하지 않는 업체는 연방 계약 수주를 막고 있으며, 캐나다 국세청(CRA)은 2026년 9월부터 취약점 보고를 의무화하고 있고, PCI DSS 4.0은 이미 감사 담당자들의 손에 들어갔습니다. SBOM을 제공하든지, 아니면 계약을 잃게 될 것입니다.

기업용 소프트웨어 제품의 경우, 동일한 종속성 분석을 기반으로 생성하는 것 외에는 두 가지 형식을 모두 제작하는 데 추가 비용이 거의 들지 않습니다. 각 형식의 대상 고객은 다릅니다. 보안 팀과 취약점 관리 워크플로는 CycloneDX를 사용하는 반면, 법무 팀, 구매 및 규정 준수 워크플로는 일반적으로 SPDX를 선호합니다.

기존 코드베이스 문제: 패키지 관리자도 없고, 매니페스트도 없음

위에서 설명한 의존성 분석 도구(SCA 스캐너, 락파일 파서, SBOM 생성기)는 소프트웨어 의존성이 패키지 관리자를 통해 관리되고 매니페스트 파일에 선언된다는 가정을 기반으로 작동합니다. 이러한 가정은 최신 Java, JavaScript, Python, Go, Rust 프로젝트에는 적용되지만, COBOL, JCL 및 메인프레임 플랫폼을 기반으로 구축된 기존 엔터프라이즈 환경에는 적용되지 않습니다.

메인프레임 환경에서 타사 소프트웨어 종속성은 표준 SCA 도구로는 감지할 수 없는 세 가지 방식으로 나타납니다.

라이선스가 부여된 분류 및 유틸리티 제품. JCL 작업 스트림은 유틸리티 프로그램, 정렬 제품(DFSORT, SyncSort/Syncsort(현재 Precisely로 알려짐), CA Sort), 보고서 작성기(SAS, EASYTRIEVE) 및 데이터 변환 도구를 호출합니다. 이러한 프로그램은 자체 라이선스 조건, 유지 관리 계약 및 규정 준수 요구 사항이 있는 라이선스 상용 소프트웨어입니다. 이러한 프로그램은 JCL에서 다음과 같이 나타납니다. PGM=SORT, PGM=IEBGENER, PGM=ICETOOL프로그램 이름이지 패키지 식별자가 아닙니다. SCA 도구 중 프로그램 이름을 읽는 도구는 없습니다. package.json or pom.xml 우리가 찾아낼 겁니다.

벤더 제공 COBOL 카피북. 타사 소프트웨어 벤더는 라이선스 소프트웨어인 COBOL 카피북을 제공합니다. 결제 처리용 COBOL 프로그램을 제공하는 핀테크 소프트웨어 벤더는 자사 고유의 데이터 구조를 정의하는 카피북을 제공할 수 있습니다. 이러한 카피북을 포함하는 모든 COBOL 프로그램은 라이선스 소프트웨어를 사용하고 있는 것입니다. 라이선스 의무는 실제로 존재하며, 패키지 관리자 항목은 존재하지 않습니다.

라이선스 소스에서 가져온 임베디드 알고리즘. COBOL 시스템을 사용하는 금융 기관은 라이선스가 부여된 알고리즘, 보험 계리 계산 루틴, 암호화 구현, 수치 해석 라이브러리 등을 COBOL 소스 코드에 직접 통합했을 수 있습니다. 이러한 요소들은 라이선스 소스에서 유래되어 코드베이스에 컴파일되었을 수 있으며, 패키지 관리자를 통해 식별할 수 없습니다.

이러한 구성 요소의 경우, 소스 코드 분석을 통해 구성 요소를 찾아냅니다. 즉, CALL 문을 추적하여 호출된 프로그램을 식별하고, COPY 문을 검사하여 포함된 멤버를 식별하며, 프로그램 이름을 알려진 타사 구성 요소 레지스트리와 대조합니다. 이렇게 얻은 결과는 동일한 라이선스 준수 워크플로에 활용되지만, 최신 패키지 매니페스트 형식뿐 아니라 COBOL 및 JCL 의미 체계를 이해하는 도구가 필요합니다.

감사 준비를 위한 완벽한 규정 준수 패키지 구축

법무팀, 규정 준수팀 또는 외부 감사인이 라이선스 준수 증빙 자료를 요청할 경우, 스캔 보고서가 필요하지만 그것만으로는 충분하지 않습니다. 감사 준비용 규정 준수 패키지에는 다음이 포함됩니다.

• 완전한 의존성 목록모든 구성 요소, 버전 및 라이선스(전이적 종속성 포함)가 제품 및 버전별로 정리되어 있습니다.
• 라이선스 의무 매트릭스각 라이선스 범주에 대해 구체적인 의무 사항(저작자 표시, 출처 공개, 수정 고지)과 각 의무 사항을 이행하는 방법을 명시합니다.
• 저작권 표시 파일저작권 표시가 필요한 모든 구성 요소에 대해 각 라이선스에서 요구하는 형식(Apache-2.0의 경우 NOTICE 파일, MIT의 경우 LICENSE 파일 등)으로 법적 고지 사항을 작성했습니다.
• 호환성 분석결합된 제품에 호환되지 않는 라이선스 조합이 없음을 입증하는 문서와, 경계 사례가 있는 경우 법적 근거를 제시해야 합니다.
• SBOM 아티팩트현재 CycloneDX 또는 SPDX 파일(서명 및 타임스탬프 포함, 범위 내 모든 구성 요소 포함)
• 정책 문서해당 조직의 공식 오픈 소스 라이선스 정책(새로운 라이선스 승인 절차 포함)
• 승인 기록포함 전에 법률 검토가 필요한 모든 라이선스의 경우, 문서화된 승인서와 사업적 타당성 근거를 제출해야 합니다.
• 개선 이력이전에 확인된 위반 사항 및 이를 해결하기 위해 취해진 조치에 대한 문서화

특히 M&A 실사에서, 인수 기업은 기술 실사의 일환으로 이러한 패키지를 점점 더 많이 요구하고 있습니다. 미해결 위반 사항이 없는 깔끔한 규정 준수 패키지는 실사 과정을 가속화합니다. 반면, 독점 제품에서 해결되지 않은 GPL 위반 사항이 드러나는 패키지는 일반적으로 가격 조정, 에스크로 요구, 또는 시정 조치 등의 거래 조건으로 이어지는데, 이러한 조치들은 모두 위반 사항을 예방할 수 있었던 규정 준수 프로그램보다 훨씬 더 많은 비용을 초래합니다.

방법 SMART TS XL 엔터프라이즈 코드베이스의 라이선스 규정 준수를 지원합니다.

SMART TS XL의 애플리케이션 종속성 매핑 이 플랫폼은 특히 표준 SCA 도구가 한계에 도달하는 레거시 환경에서 엔터프라이즈 코드베이스에 대한 구조적 종속성 분석 계층을 제공합니다.

메인프레임 환경의 경우, 종속성 맵은 다른 모든 프로그램에서 호출되는 모든 프로그램(JCL 및 COBOL에 포함된 타사 유틸리티 호출 포함), 모든 프로그램에서 포함하는 모든 카피북(벤더 제공 카피북 종속성 포함), 그리고 모든 프로그램에서 액세스하는 모든 데이터 세트(라이선스 데이터베이스 제품에 대한 데이터 계층 종속성 포함)를 식별합니다. 이 분석을 통해 패키지 관리자가 없는 환경에서 라이선스 준수 감사에 필요한 구성 요소 목록이 생성됩니다.

정적 코드 분석 기능은 특정 타사 구성 요소와 관련된 코드 패턴을 식별합니다. 여기에는 독점 API 호출 시그니처, 공급업체별 데이터 구조 규칙, 사용자 지정 COBOL 소스에 포함된 라이선스 알고리즘 구현 등이 포함됩니다. 이러한 분석 결과는 매니페스트 기반 인벤토리를 보완하여 매니페스트 스캔으로는 파악할 수 없는 코드 수준의 종속성을 제공합니다.

영향 분석 기능을 통해 라이선스 정책 변경 사항을 실질적인 조치로 전환할 수 있습니다. 예를 들어, 구성 요소의 라이선스가 변경되거나, 종속성 구성 요소의 라이선스가 MIT에서 AGPL-3.0으로 변경되거나, 공급업체가 약관을 수정하는 경우, 영향 분석은 해당 구성 요소에 직간접적으로 의존하는 포트폴리오 내 모든 프로그램을 식별합니다. 이를 통해 라이선스 변경 이벤트는 미지의 위험에서 명확한 해결 범위로 전환됩니다.

엔터프라이즈 검색 기능을 통해 규정 준수 목적으로 종속성 목록을 조회할 수 있습니다. 특정 유틸리티를 호출하는 모든 프로그램, 특정 공급업체에서 제공한 구성 요소를 포함하는 모든 카피북, 특정 라이선스 구성 요소에 의존하는 모든 프로그램을 전체 레거시 포트폴리오에서 몇 초 만에 찾을 수 있습니다. 이 검색 기능은 화요일 아침에 발생하는 M&A 감사 요청에 대한 실용적인 도구입니다. 수동 검토 대신 조회를 통해 간편하게 처리할 수 있습니다.

현대 시스템과 기존 시스템 모두를 아우르는 포괄적인 SBOM(소프트웨어 정의 매뉴얼) 적용 범위를 구축하는 조직의 경우, SMART TS XL 표준 SBOM 생성기가 생성할 수 없는 레거시 구성 요소 목록을 제공하여 Syft, FOSSA 및 Dependency-Track과 같은 최신 스택용 도구를 보완합니다.

절대 놀라서는 안 될 감사

라이선스 준수 감사는 규제 기관이 아닌, 라이선스 약관을 검토하고 준수 증거를 요구하는 비즈니스 파트너, 인수 기업, 고객사 법무팀 또는 유통업체에 의해 비준수에 대한 처벌이 발견되는 몇 안 되는 규제 분야 중 하나입니다. 이러한 발견으로 인한 비용은 위반의 심각성과 거래 단계에 따라 곤란한 상황에서부터 사업 존폐 위기에 이르기까지 다양합니다.

이러한 문제가 예상치 못한 상황으로 발생하는 것을 방지하는 종속성 분석 프로그램은 그로 인해 완화되는 위험에 비해 비용이 많이 들지 않습니다. 이를 위해서는 소프트웨어의 모든 구성 요소, 모든 전이적 종속성, 모든 공급업체 제공 코드 조각, 모든 레거시 유틸리티를 파악하고, 각각을 조직의 라이선스 정책에 따라 주기적으로가 아니라 지속적으로 점검해야 합니다. 필요한 도구는 이미 존재합니다. 표준(SBOM, SPDX, CycloneDX)도 존재합니다. 규제 의무(EO 14028, CRA, PCI-DSS 4.0)도 마련되어 있습니다. 대부분의 조직에 부족한 것은 종속성 분석을 단순한 감사 활동이 아닌 인프라의 일부로 인식하고 관리하는 역량입니다.

화재 대피 훈련 대신 보고서 작성으로 시작되는 화요일 아침은, 바로 그런 화요일 아침을 가능하게 한 것은 바로 의존성 분석 인프라입니다.