기술 지원
문서
로그인
문의하기
이 블로그 글의 AI 요약으로 바로 가기 
주요 요점
- 자바스크립트 앱에는 직접 및 전이 종속성 모두 수백 개의 숨겨진 종속성이 포함되어 있는 경우가 많습니다.
- SBOM은 코드베이스에 대한 완벽한 가시성을 제공하여 취약점을 노출하고 투명성을 보장합니다.
- Syft 및 CycloneDX와 같은 도구를 사용하면 SBOM 생성이 간편해져 보안을 강화하고 규정 준수를 유지할 수 있습니다.
자바스크립트 앱은 종속성의 블랙박스입니다. node_modules를 열면 전혀 몰랐던 수천 개의 패키지를 발견할 수 있으며, 일부는 레이더 화면에서 UFO처럼 비밀스러운 패키지를 발견할 수도 있습니다. 공급망 공격이 증가하는 시대에 이는 단순히 소름 끼치는 일이 아니라 위험한 일입니다.
자바스크립트 종속성의 은하계를 탐색하기 위한 별자리 차트인 SBOM(소프트웨어 자재 명세서)을 소개합니다. 이 글에서는 SBOM이 무엇인지, 프론트엔드 개발자가 이를 무시할 수 없는 이유는 무엇인지, CycloneDX 및 Syft와 같은 도구를 사용하여 에코시스템을 매핑하고, 보안을 워크플로에 통합하고, 취약점이 충돌하기 전에 포착하는 방법을 자세히 설명합니다.
자바스크립트 종류와 밀접한 만남
소프트웨어를 전체적으로 보면 모든 것을 연결하는 다양한 조각이 있습니다. 패키지, 라이선스, 사람, 프로세스 등이 퍼즐 조각처럼 서로 맞물려 있는경우가 대부분입니다.
소프트웨어 종속성은 때로는 설명이 가능하고, 때로는 당황스럽고, 항상 갑작스러운 만남의 가능성을 안고 있는 UFO(미확인 비행 물체)나 UAP(미확인 공중 현상)처럼 낯설게 느껴질 수 있습니다.
코드 내에 이상값이 있다는 것을 알고도 눈 깜짝할 사이에 소프트웨어가 손상될 수 있습니다. 바로 이때 SBOM이 등장합니다.
패키지를 설치하고, 그 패키지가 또 다른 패키지를 설치하면 모선과 그 자식 함선이 모두 파괴된다고 생각하면 됩니다.
이 영화가 모든 것을 요약해줍니다!
앱에 얼마나 많은 종속성이 있나요?
앱에 20개의 종속성이 있나요? 200? 아니면 작은 은하계 정도, 즉 천 개에 가깝나요?
터미널에서 npm ls를 실행하면 종속성 목록을 볼 수 있습니다.
모든 종속성을 나열하지 않는 이유는 무엇인가요? 종속성 트리가 커질 수 있으므로 터미널에 과부하가 걸릴 수 있지만 가능합니다.
이러한 방식으로 종속성을 나열하면 직접 종속성뿐만 아니라 전이 종속성도 표시됩니다.
두 가지 형태의 종속성
프로젝트의 종속성을 살펴보면 두 가지 유형이 있습니다. 하나는 직접 종속성입니다. 패키지.json 파일을 열면 직접 종속성 트리를 볼 수 있습니다.
예를 들어 다음 앱을 빌드하려면 다음이 필요하므로 다음이 직접적인 종속성입니다.
JSON
"dependencies": {
"react": "^19.0.0",
"react-dom": "^19.0.0",
"next": "15.3.4"
}
그런 다음 전이적 종속성이 있습니다. 이러한 종속성은 자세히 살펴봐야 하는 종속성 간의 종속성입니다. 일반적으로 패키지 폴더의 node_modules 폴더에 있는 package.json 파일에 있습니다.
이 예에서 @next/env는 다음의 전이적 종속성입니다.
JSON
"dependencies": {
"@next/env": "15.3.4"
}
SBOM이란 무엇인가요?
SBOM은 기본적으로 모든 구성 요소, 종속성 및 관계를 설명하는 기계 판독 가능한 인벤토리인 프로젝트의 적하 목록입니다. 코드베이스의 재료 목록 또는 비행기에 누가 탑승했는지 정확히 알려주는 항공기 적하 목록이라고 생각하면 됩니다. SBOM에는 프로젝트 내의 모든 종속성과 버전이 나열됩니다.
아래는 Medium에 올라온 타히르 발라라베의 글에서 발췌한 내용입니다. 이 설명은 모든 것을 완벽하게 요약합니다.
"SBOM(소프트웨어 자재 명세서)은 종속성, 메타데이터, 구성 요소 간의 관계를 포함하여 소프트웨어 내의 모든 구성 요소에 대한 상세하고 기계가 읽을 수 있는 목록입니다."
"SBOM이 왜 필요한가요?"라고 자문해 보셨을 것입니다. 소프트웨어를 생산하거나 소비할 때 SBOM 또는 SBOM이 필요한 이유는 여러 가지가 있습니다. 그 중 하나는 투명성입니다. 우리는 제품에 무엇이 들어 있는지 알아야 합니다. 제품을 배송하거나 안전하지 않은 제품을 제공하는 것은 누구에게도 도움이 되지 않으며 결국 나중에 문제가 발생할 수 있습니다.
종속성 트리에 무엇이 포함되어 있는지 투명하게 파악하면 보안을 유지하고 규정을 준수하는 데 도움이 되며, 이는 매우 중요한 두 가지 이유이기도 합니다. 제품에 무엇이 포함되어 있는지 아는 것과 보안 및 규정을 준수하는 것은 별개의 문제입니다.
SBOM의 유형
소프트웨어에 대한 다양한 SBOM에 대해 이야기하거나 생각해낼 때 6가지 유형이 있습니다. 이 모든 유형은 SLDC(소프트웨어 개발 수명 주기)의 다양한 부분으로 나뉩니다.
- SBOM 디자인
- 출처 SBOM
- SBOM 구축
- 분석된 SBOM
- 배포된 SBOM
- 런타임 SBOM
이러한 SBOM의 정의에 대한 자세한 내용은 CISA(사이버 보안 및 인프라 보안 기관)에서 제공하는 소프트웨어 자재 명세서(SBOM) 유형 PDF를 참조하세요.
SBOM에 대해 논의할 때 명심해야 할 한 가지는 패키지 파일이나 잠금 파일이 아니라 더 포괄적이라는 점입니다. 또한 SBOM은 컴포넌트, 메타데이터 등 프로젝트 내의 모든 항목에 대한 표준화된 전체 목록을 제공합니다.
큰 프론트엔드 문제
이 글을 읽고 있는 여러분이 npm을 사용하여 프론트엔드에 무언가를 설치했다면, 근육 기억을 통해 입력하는 문제를 100번도 넘게 겪어봤을 것입니다. 때로는 주의를 기울이지 않고 필요하다고 생각되는 것만 설치할 수도 있습니다. 심지어 공급업체 사이트나 npm 레지스트리에서 직접 복사하여 붙여넣지 않을 수도 있습니다. 이로 인해 많은 문제가 발생하는데, 바로 오타 스쿼팅입니다.
타이포스쿼팅은 URL 하이재킹이라고도 합니다. 공격자가 철자를 약간 다르게 변형한 도메인을 등록하여 사용자를 속여 사이트를 결제하도록 유도하는 공격 유형으로, 대개 악의적인 경우가 많습니다. 이는 패키지 관리에도 적용됩니다. 공격자는 도메인과 마찬가지로 악성 패키지를 게시하고 철자를 잘못 입력합니다. 개발자가 실수로 타이핑 실수를 하여 올바른 패키지 대신 악성 패키지를 설치할 수 있습니다.
예를 들면 아래와 같습니다:
엔엔엠인스톨 익스프레스 와 엔엔엠인스톨 익스프레스의 차이점
두 번째 버전은 잘못된 버전의 익스프레스이며 잠재적으로 유해할 수 있음을 알 수 있습니다.
SBOM이 중요한 이유는 무엇인가요?
SBOM을 보유하는 것이 매우 중요한 이유는 몇 가지가 있습니다:
- 컴포넌트 가시성
- 취약점 관리
- 공급망 보안
- 협업 및 패치 관리
- 규정 준수
특히 전이적 종속성과 관련해서는 컴포넌트에 대한 가시성을 확보하는 것이 중요합니다. 또한 설치한 것을 기반으로 취약성을 관리할 수 있어야 합니다. 그리고 인적 요소도 간과하지 마세요. SBOM을 공유하면 고객의 신뢰를 구축하여 소프트웨어 공급망이 투명하고 안전하다는 것을 증명할 수 있습니다.
웹 및 소프트웨어 전문가로서 다른 사람들이 사용할 소프트웨어를 제작하는 경우 고객과 견고한 관계를 유지하고 싶을 것입니다. 고객이 SBOM을 사용할 수 있는지 확인하는 것은 매우 중요합니다.
SBOM 생성 도구 설치하기
SBOM을 생성하기 위해 다양한 도구를 설치하는 방법에는 몇 가지가 있습니다. 이 글에서는 Syft by Anchore를 사용하겠습니다. 다음은 컴퓨터에 Syft를 설치하는 몇 가지 명령어입니다.
권장되는 방법은 컬을 사용하는 것입니다:
curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin
Brew를 사용하여 패키지를 설치할 수도 있습니다:
brew install syft
Chocolatey를 통해 설치할 수 있는 Windows용 버전도 있습니다:
choco install syft -y
Microsoft는 Winget을 사용하여 SBOM을 생성하는 도구도 제공합니다:
winget install Microsoft.SbomTool
Syft가 설치되면 프로젝트에서 SBOM을 생성하는 단계로 넘어갈 수 있습니다.
SBOM 세대
SBOM을 생성하는 데 널리 사용되는 두 가지 형식은 SPDX와 CycloneDX입니다. 다음 예제에서는 SPDX를 사용하여 SBOM의 형식을 지정합니다. 또한 Angular 프로젝트, 특히 v19에서 SBOM을 생성하고 있습니다.
프로젝트에 들어가면 아래 명령을 실행하여 SBOM을 생성합니다. 이 명령은 기계 판독이 가능하지만 두 번째로 실행할 명령으로 이 문제를 해결하겠습니다. 명령의 끝에 -source-name과 -source-version이라는 두 개의 플래그가 있는 것을 볼 수 있습니다. 명령에 이 두 플래그를 전달하지 않으면 터미널에서 비명을 지르게 됩니다. 이 두 플래그를 포함하는 것이 가장 좋습니다.
syft packages dir:. -o json > sbom.json --source-name "my-js-project" --source-version "1.0"
이제 사람이 읽을 수 있는 SBOM 버전을 생성해 보겠습니다. jq라는 명령을 실행하여 SBOM을 예쁘게 인쇄하면 생성된 내용을 살펴볼 수 있습니다.
jq . sbom.json > sbom-pretty.json
새 패키지를 설치할 때는 설치하는 패키지를 문서화할 수 있도록 새 SBOM을 생성하는 것이 좋습니다. 아래는 Angular용 Lucide 패키지를 설치한 후 새 패키지가 반영된 것을 확인하기 위해 SBOM을 수동으로 다시 생성하는 동영상입니다.
이 작업은 GitHub 액션을 사용하여 수행할 수도 있습니다. 메인, 개발 또는 릴리스 브랜치로 푸시하면 워크플로우가 트리거되어 새 SBOM 아티팩트를 JSON 형식으로 생성하고, 이 파일은 GitHub에 저장됩니다. 해당 파일로 무엇을 할지는 사용자가 선택할 수 있습니다.
최종 생각
SBOM은 더 이상 선택 사항이 아니라 최신 소프트웨어 개발의 필수 요소입니다. 단순히 무엇이 설치되어 있는지만 알려주는 것이 아니라 직접 및 전이 종속성에 대한 살아있는 맵을 제공합니다. 또한 취약성 관리 및 규정 준수 인식에도 도움이 됩니다.
투명성이 가장 중요하며, 많은 조직에서 SBOM은 가시성에 대한 약속을 입증하는 수단입니다. 예를 들어, 애플리케이션에 대한 무한 수명 주기 지원(ELS)의 일환으로 TuxCare는 각 패키지가 빌드, 검증 및 배포되는 방식에 대한 포괄적인 세부 정보를 제공하는 SBOM을 자동으로 사용자에게 제공합니다. 이러한 방식으로 TuxCare는 수명이 다한 오픈 소스 소프트웨어 제품에 대한 확장 패치를 사용하는 개발자가 소프트웨어 에코시스템의 투명성과 책임성을 보장할 수 있도록 지원합니다.
따라서 다음에 프로젝트를 열면 SBOM을 생성하고 취약성 스캐너를 통해 실행하여 알려진 익스플로잇을 숨기고 있을 수 있는 패키지를 정확히 확인하세요. 이는 프론트엔드 보안 태세를 강화하는 가장 간단하고 현명한 방법 중 하나입니다.
수명이 다한 버전을 안전하게 유지하세요.
무한 수명 주기 지원(ELS)은 런타임 및 라이브러리부터 OS 및 애플리케이션에 이르기까지 스택에 있는 지원 종료된 오픈 소스 도구에 대한 보안 패치를 지속적으로 전송합니다.