SBOM 취약점 스캐너

lockfile 또는 SBOM을 넣고 고정된 모든 버전을 알려진 취약점과 대조하세요. 로컬에서 파싱하고 OSV 데이터베이스와 대조합니다.

lockfile은 빌드가 실제로 설치하는 버전의 정확한 목록입니다. 고정된 모든 버전은 고정한 이후로 아무도 구멍을 찾지 못했다는 내기입니다. 이 스캐너는 그 목록(package-lock.json, requirements.txt, go.mod 또는 CycloneDX / SPDX SBOM)을 읽어 이름과 버전 쌍만 공개 OSV.dev 취약점 데이터베이스로 보내고, 어떤 패키지에 알려진 취약점이 있는지, 심각도는 어느 정도인지, 각 취약점을 수정하는 버전은 무엇인지, CVE 중 CISA의 알려진 악용 취약점(Known Exploited Vulnerabilities) 목록에 있는 것이 있는지 보고합니다. 함께 제공되는 가이드 lockfile에 취약점이 숨어 있나요?는 결과가 무엇을 증명하고 무엇을 증명하지 못하는지 설명합니다. 스캔에서 CVE가 플래그되면 Bulk CVE Triage에서 악용 맥락을 확인할 수 있습니다.

마지막 업데이트:

lockfile 또는 SBOM

지원 형식: package-lock.json, requirements.txt, go.mod, CycloneDX JSON, SPDX JSON. 최대 파일 크기 5 MB.

형식은 파일 이름과 내용에서 자동 감지되며, 아래에서 직접 선택할 수도 있습니다.

🔒 lockfile은 브라우저에서 파싱되며 업로드되지 않습니다. OSV.dev로 전송되는 것은 패키지 이름과 버전뿐이며, 자체 검사기로 전송되는 것은 KEV 플래그 확인용 CVE ID뿐입니다.

스캔 결과

아직 스캔하지 않았습니다. 위에서 lockfile 또는 SBOM을 업로드하거나 붙여넣고 "취약점 스캔"을 누르세요.

lockfile은 이 페이지를 떠나지 않습니다

파싱은 전적으로 브라우저에서 이루어집니다. 넣은 파일이나 붙여넣은 텍스트는 로컬에서 읽히며 어디에도 업로드되지 않습니다. 외부로 전송되는 것은 추출된 패키지 이름과 버전뿐이며, 공개 OSV.dev 취약점 데이터베이스(계정 불필요, 키 불필요)로 보내져 알려진 취약점과 대조합니다. 대조 결과의 CVE ID는 CISA KEV 조회를 위해 이 사이트 자체 검사기로 전송됩니다. 그 외에는 아무것도 이 페이지를 떠나지 않습니다. 파일 내용, 경로, 프로젝트 이름은 전송되지 않습니다.

스캔 제한

한 번의 실행에서 최대 500개의 패키지까지 스캔하며, 초과분은 스캔되지 않은 것으로 목록에 표시됩니다. 가져오는 취약점 세부 정보는 최대 200개입니다. 결과는 파일에 있는 정확한 버전에 대한 OSV 데이터베이스의 내용에 따른 것입니다. 데이터베이스가 한 번도 본 적 없는 패키지 버전은 일치 항목 없이 반환되지만, 이는 안전하다는 증명이 아닙니다.

솔직한 한계

"취약점을 찾지 못했습니다"는 이 정확한 버전에 대해 OSV 데이터베이스에 취약점이 없다는 뜻입니다. 코드가 안전하다는 뜻은 아닙니다. 아직 아무도 보고하지 않은 취약점, 악성 패키지, 타이포스쿼팅 이름, 손상된 릴리스는 버전 대조 검사로는 모두 보이지 않습니다.

대조는 버전 완전 일치 방식입니다. 파일에 정확한 버전 대신 범위가 고정되어 있으면 해당 행은 건너뛰고 그 사실이 목록에 표시됩니다. 스캐너는 실제로 설치된 버전을 추측하지 않습니다. 스캐너가 대응시킬 수 없는 에코시스템의 패키지도 마찬가지입니다. 건너뛴 것으로 목록에 표시되며 조용히 빠지지 않습니다.

KEV 플래그는 이 사이트 자체 검사기에 대한 한 번의 조회(CISA KEV 데이터, 매일 갱신)에서 가져옵니다. 해당 조회가 실패하거나 속도 제한에 걸려도 스캔은 완료됩니다. KEV 열은 결과를 막는 대신 단순히 "알 수 없음"으로 표시됩니다.

고정된 버전이 공격 표면인 이유

lockfile이 존재하는 이유는 "latest"가 버전이 아니기 때문입니다. 빌드가 설치한 정확한 트리를 기록하므로 모든 머신과 모든 배포에서 같은 코드가 나옵니다. 그 결정성 덕분에 lockfile을 스캔할 수 있습니다. 취약점 데이터베이스는 정확한 패키지와 버전을 키로 하므로, 고정된 버전은 한 번의 조회로 판단할 수 있지만, 유동적인 범위는 판단할 수 없습니다. 따라서 스캔의 정확도는 파일에 달려 있습니다. lockfile을 커밋하고 최신 상태로 유지하면, 스캐너는 배포하는 것에 대한 진실을 알려줄 수 있습니다.

이 검사는 의도적으로 범위를 좁게 잡았습니다. OSV.dev는 GitHub 권고, NVD, 각 언어 에코시스템의 취약점 기록을 모아 버전에 대조합니다. 할 수 없는 것은 코드 판단입니다. 알려진 CVE가 없는 패키지도 악성이거나, 방치되었거나, 설치하려던 패키지의 유사품일 수 있습니다. 버전 대조는 빠르고 저렴한 첫 번째 필터, 즉 업그레이드를 잊어버린 lodash를 잡아내는 필터이지 보안 감사가 아닙니다.

KEV 플래그가 높은 CVSS 점수보다 중요한 이유

CVSS 점수는 취약점이 악용될 경우 얼마나 심각할지를 측정합니다. CISA의 알려진 악용 취약점(Known Exploited Vulnerabilities) 카탈로그가 측정하는 것은 다른 것입니다. 지금 실제로 악용되고 있는지, 현실 세계에서, 바로 지금 말입니다. 심각도가 중간인 CVE가 KEV 목록에 있으면 이번 주에 패치해야 하고, 심각도가 치명적이어도 아무도 무기화하지 않았다면 다음 계획된 업그레이드까지 기다릴 수 있는 경우가 많습니다. 그래서 이 스캐너는 KEV 행을 별도로 배지 표시하고, 결과는 최악의 심각도 순으로 정렬합니다. 하지만 먼저 조치해야 할 것은 KEV 배지입니다.

수정 버전에도 나름의 위험이 있습니다. 취약점 수정은 대개 마이너 또는 패치 릴리스이지만, "4.17.21에서 수정"이 빌드를 깨뜨리는 동작 변경을 의미할 수도 있고, 수정 버전이 아예 없는 취약점도 있습니다. 스캐너는 그런 경우 지어내지 않고 솔직히 그렇게 표시합니다. 먼저 KEV 항목에 패치하고, 그다음 공개된 수정 버전이 있는 치명적인 항목을, 나머지는 계획에 넣으세요. 새 버전을 고정하고, lockfile을 커밋하고, 다시 스캔하세요. 같은 루프를 CI에 넣어야 하며, 분기에 한 번이 아니라 모든 풀 리퀘스트에서 실행해야 합니다.

이 SBOM의 라이선스

여기에 나열된 라이선스는 SBOM 자체에 포함된 라이선스 필드에서만 가져온 것입니다. lockfile(package-lock.json, requirements.txt, go.mod)에는 라이선스 데이터가 없으므로 아무것도 표시되지 않습니다. 이 페이지는 패키지별로 라이선스를 조회하지 않습니다. 라이선스를 안정적으로 제공하는 공개 데이터베이스가 없기 때문입니다.

lockfile과 SBOM 용어 정리

Lockfile. 빌드가 설치하는 모든 패키지의 정확한 버전을 기록한 파일입니다. npm의 package-lock.json, ==로 고정한 Python의 requirements.txt, Go의 go.mod/go.sum이 있으며, 설치를 재현 가능하게 합니다.

SBOM. 소프트웨어 자재 명세서(Software Bill of Materials): 소프트웨어에 포함된 모든 구성 요소를 기계가 읽을 수 있는 형태로 나열한 목록으로, 보통 CycloneDX 또는 SPDX 형식입니다. lockfile을 전체 공급망으로 일반화한 것입니다.

OSV.dev. Google의 공개 취약점 데이터베이스입니다. GitHub, NVD, 각 언어 에코시스템의 권고를 모아 정확한 패키지 이름, 에코시스템, 버전으로 조회할 수 있습니다.

GHSA. GitHub 보안 권고 ID(GHSA-xxxx-xxxx-xxxx)입니다. OSV의 npm, PyPI, Go 취약점 대부분에 부여되며, 보통 CVE ID와 함께 표시됩니다.

CVE. 공통 취약점 및 노출(Common Vulnerabilities and Exposures): 모든 데이터베이스, 스캐너, 벤더가 같은 취약점에 대해 이야기할 수 있게 하는 공유 번호 체계(CVE-YYYY-NNNNN)입니다.

CVSS. 공통 취약점 점수 시스템(Common Vulnerability Scoring System): 취약점이 악용될 경우의 심각도를 0~10점으로 나타낸 점수입니다. 9.0 이상이 CRITICAL, 7.0 이상이 HIGH, 4.0 이상이 MEDIUM, 4.0 미만이 LOW입니다.

KEV. CISA의 알려진 악용 취약점(Known Exploited Vulnerabilities) 카탈로그입니다. 현실 세계에서 악용이 확인된 취약점을 수정 기한과 함께 수록합니다. KEV 플래그는 CVSS와 관계없이 "지금 패치하라"는 뜻입니다.

Fixed version. 취약점이 더 이상 존재하지 않는 첫 번째 패키지 버전으로, 권고의 영향 범위 이벤트에서 가져옵니다. 아직 공개되지 않은 취약점도 있습니다.

Purl. 패키지 URL(pkg:npm/[email protected]): 에코시스템과 버전을 함께 패키지를 명명하는 표준 방식입니다. SBOM에는 purl이 포함되어 있어 스캐너가 구성 요소의 에코시스템을 알 수 있습니다.

자주 묻는 질문

lockfile이 브라우저를 떠나나요?

아니요. 파일은 로컬에서 파싱되며 업로드되지 않습니다. 외부로 전송되는 것은 추출된 패키지 이름과 버전뿐이며, 공개 취약점 데이터베이스인 OSV.dev로 전송되고, 대조 결과의 CVE ID만 KEV 조회를 위해 이 사이트 자체 검사기로 전송됩니다. 파일 내용, 경로, 프로젝트 이름은 이 페이지를 떠나지 않습니다.

패키지가 "건너뜀"으로 표시되는 이유는 무엇인가요?

세 가지 이유가 있습니다. 행이 정확한 고정이 아니라 범위(~= 또는 >= 등)이거나, -r 포함 또는 replace 지시문이어서, 에코시스템을 OSV.dev가 지원하는 것으로 대응시킬 수 없거나, 500개 패키지 상한에 도달했기 때문입니다. 건너뛴 항목은 항상 이유와 함께 목록에 표시되며 조용히 빠지지 않습니다.

"취약점을 찾지 못했습니다" — 안전한가요?

반드시 그렇지는 않습니다. 이 정확한 버전에 대해 OSV 데이터베이스에 보고된 취약점이 없다는 뜻입니다. 보고되지 않은 취약점, 악성 또는 타이포스쿼팅 패키지, 손상된 릴리스는 어떤 취약점 데이터베이스에도 나타나지 않습니다. 스캔을 첫 번째 필터로 취급하고 안전 증명으로 여기지 마세요.

무엇부터 수정해야 하나요?

KEV 배지가 있는 것부터 시작하세요. 그 취약점들은 지금 악용되고 있으며 CISA가 각각 기한을 정합니다. 그다음 공개된 수정 버전이 있는 CRITICAL 및 HIGH 행을, 애플리케이션이 실제로 가져오는 패키지부터 처리하세요. 각 CVE의 악용 맥락은 Bulk CVE Triage에서 확인할 수 있습니다.

취약점에 수정 버전이 없습니다. 어떻게 해야 하나요?

먼저 권고에 아직 기록되지 않은 최신 버전이 있는지 확인하세요. 권고는 릴리스보다 늦는 경우가 많습니다. 정말 수정이 없다면 의존성을 제거하거나, 교체하거나, 취약한 코드 경로를 완화하는(예: 영향받는 함수에 신뢰할 수 없는 입력을 전달하지 않는) 방법이 있으며, 권고 업데이트를 주시하세요. 변경 후 다시 스캔하세요.