Semgrep 1.181.0 업그레이드 점검: SBOM 목록과 취약점 결과 대조하기

Semgrep 1.181.0으로 올린 뒤 의존성 목록이 늘고 파싱 오류가 줄었다면, 먼저 입력 선언과 SBOM의 스캔 출처를 대조하세요. 버전 범위나 패키지 이름만 적은 항목도 목록에 들어올 수 있지만, 그 사실만으로 취약점 탐지 범위가 넓어졌다고 판단할 수는 없습니다. 작은 팀에서도 선언별 점검표와 내보내기별 점검표를 연결하면 변화의 원인을 설명할 수 있습니다.

이 글은 이미 Semgrep Supply Chain으로 저장소를 스캔하는 개발자를 위한 업그레이드 검토 가이드입니다. 대상은 1.181.0 정식 릴리스이며, GitHub 공개 시각은 2026년 10월 14일 21:26:24 UTC입니다. 10월 15일에 공식 문서와 고정 태그의 소스를 대조했습니다. 패키지 설치, 스캔 실행, 실제 SBOM 내보내기는 수행하지 않았습니다. 아래 예시는 실행 결과가 아닙니다.

1.181.0에서 달라진 범위부터 확인합니다

이번 변경의 대상은 Python의 requirements.txt 파싱입니다. 릴리스는 버전 범위나 버전 없는 이름도 의존성 인벤토리와 SBOM에 포함할 수 있다고 설명합니다. 다만 실제 버전이 확정되지 않은 이 항목들은 현재 Supply Chain 취약점 finding을 만들지 않습니다. 목록에 새 행이 생겼는데 finding 수가 그대로인 상황은 이 변경과 함께 나타날 수 있습니다. 이 동작을 uv.lock, Poetry나 모든 Python 의존성 파일에 일반화하지 마세요. 근거: 1.181.0 릴리스

확인 당시의 일반 지원 문서에는 기본 경로에서 정확히 고정한 의존성만 수집한다는 설명도 남아 있습니다. 이 글은 새 버전의 정적 선언 수집을 고정 태그 기준으로 다룹니다. 빌드나 동적 의존성 해결을 활성화하는 절차는 범위에 포함하지 않습니다.

예시 선언으로 읽는 목록의 의미

아래 패키지 이름과 버전은 설명을 위한 가상 예시입니다. 표시값과 분류는 1.181.0 파서 소스에서 도출한 예상이며, 플랫폼에서 관찰한 출력이 아닙니다.

  • demo-pinned==1.4.2: 파서가 기록하는 버전은 1.4.2입니다.
  • demo-range>=1,<2: 기록하는 값은 >=1,<2입니다. 설치된 단일 버전으로 바뀌지 않습니다.
  • demo-bare: 버전 값은 빈 문자열입니다.
  • demo-url @ https://example.invalid/demo.whl, ./dist/demo-local.whl: 이 파서는 해당 URL·로컬 경로 선언을 의존성 목록에서 건너뛰며, 그 생략 자체를 파싱 오류로 기록하지 않습니다.

대응하는 requirements.in이 없으면 범위·이름만 있는 선언은 direct로 분류하고, 정확한 pin의 전이성은 미확정 상태로 남깁니다. 따라서 direct 수가 늘었다면 선언 분류의 변화를 먼저 확인하세요. 이 라벨은 실제 의존성 그래프를 해결했다는 증거가 아닙니다. 위 예시와 분류 조건 모두 같은 고정 파서 소스에 근거합니다.

점검표 A: 입력 한 줄마다 근거를 남깁니다

다음은 이 글에서 제안하는 검토 양식입니다. Semgrep의 공식 필드나 실행 출력 형식이 아닙니다. 처음부터 모든 패키지를 수작업으로 옮기기보다, 업그레이드 뒤 새로 나타난 항목과 계속 누락된 항목부터 한 건씩 채워 보세요.

  1. 입력 위치: 저장소 · 파일 경로 · 줄 번호 · 원래 선언을 기록합니다. 같은 이름이라도 다른 파일의 선언은 별도로 추적합니다.
  2. 선언 상태: 정확한 버전 / 미해결 범위 / 버전 없음 / 로컬·URL 입력 / 잘못된 입력 중 해당 상태를 적습니다. ==1.*처럼 와일드카드가 붙으면 정확한 단일 버전으로 표시하지 않습니다.
  3. 목록과 오류: 해당 파일에서 가져온 항목이 실제 목록에 있는지, 어떤 버전 값으로 표시되는지, 관련 파싱 오류가 있는지를 각각 적습니다. 확인하지 못한 칸은 빈칸 대신 ‘미확인’으로 남깁니다.
  4. 해결된 버전의 근거: 검토 대상 배포의 승인된 잠금 파일이나 빌드 산출물 등에서 정확한 버전을 확인할 수 있는지 적습니다. 근거 파일의 리비전과 대상 환경도 함께 남깁니다. 선언 문자열만 있으면 ‘해결 근거 없음’으로 표시합니다.
  5. 관계와 후속 조치: direct·transitive·미확정 중 표시된 값, 대응 manifest 유무, 빠진 입력을 확인할 담당자와 다음 조치를 적습니다.

무엇이 표현됐고, 어느 버전의 근거가 있으며, 무엇이 아직 확인되지 않았는지 설명할 수 있어야 합니다. 정확한 pin이 있어도 그 파일이 실제 배포 환경을 대표하는지, 전이 의존성이 빠지지 않았는지, 필요한 규칙과 reachability 분석이 적용됐는지는 별도 확인 사항입니다. Python reachability는 취약한 버전과 코드 패턴의 일치를 함께 다룹니다. 근거: 공식 Python 지원 문서

점검표 B: SBOM 안의 두 데이터 출처를 맞춥니다

공식 SBOM 문서에 따르면 내보내기에 쓰는 의존성 정보는 프로젝트의 가장 최근 전체 스캔에서, 취약점 정보는 기본 브랜치에서 옵니다. 다른 브랜치에서 전체 스캔을 돌리는 작업 흐름이라면 한 SBOM에서 두 정보의 출처가 어긋날 수 있습니다. 문서는 이를 피하려면 내보내기 전에 가장 최근 전체 스캔이 기본 브랜치에서 수행됐는지 확인하도록 안내합니다.

내보낸 파일 한 개마다 아래 기록을 붙이세요. 점검표 A의 행들이 어느 결과에 속하는지 연결할 수 있도록 같은 검토 번호를 사용하면 편합니다.

  • 프로젝트: 저장소와 하위 프로젝트 범위, 기본 브랜치 이름
  • 의존성 출처: 최근 전체 스캔의 브랜치·커밋·완료 시각·실행 링크
  • 스캔 조건: 확인 가능한 CLI 버전, 입력 파일의 경로와 리비전, 적용 설정·규칙의 기록
  • 취약점 출처: 기본 브랜치의 관련 스캔·리비전 근거, 의존성 쪽과의 일치 여부
  • 내보내기: SBOM 생성 시각·형식·보관 위치, 연결한 점검표 A의 검토 번호

서비스 화면이나 보관된 로그에서 근거를 찾을 수 없다면 ‘같을 것’으로 채우지 마세요. 브랜치가 같아도 커밋과 시각까지 자동으로 같아지는 것은 아닙니다. 출처를 확인하지 못한 상태에서는 전후 finding 총수로 업그레이드의 효과를 결론 내리지 않습니다.

두 점검표를 함께 읽는 네 가지 경우

  • 정확한 버전 근거 있음 + 출처 일치: 같은 검토 범위에서 전후 차이를 살펴볼 준비가 된 상태입니다. 새 finding과 사라진 finding을 개별적으로 확인합니다. 이 조합만으로 보안 검토가 끝나는 것은 아닙니다.
  • 정확한 버전 근거 없음 + 출처 일치: 목록에 선언이 나타난 변화로 기록합니다. 버전 근거가 필요한 항목을 남기고, finding이 없는 것을 취약점 없음으로 처리하지 않습니다.
  • 정확한 버전 근거 있음 + 출처 불일치·미확인: 먼저 어떤 브랜치와 리비전을 보고 있는지 정리합니다. 패키지 버전만 맞춘 상태에서 서로 다른 스캔의 합계를 비교하지 않습니다.
  • 두 근거 모두 부족: 검토를 보류하고 입력·스캔 출처를 확보합니다. 로컬·URL 의존성처럼 목록에 나타나지 않은 입력은 별도 검토 대상으로 계속 남겨 둡니다.

작은 팀의 업그레이드 기록은 이렇게 남깁니다

  1. 기존 기준선을 보관합니다. 업그레이드 전 도구 버전, 커밋, 스캔 조건, 오류 목록과 SBOM을 묶습니다. 이전 결과를 새 파일로 덮어쓰지 않습니다.
  2. 변화를 종류별로 나눕니다. 새 선언의 목록 추가, 정확한 버전 변화, 누락 입력, 파싱 오류, finding 변화를 구별해 기록합니다. 총 항목 수 하나로 통과 기준을 만들지 않습니다.
  3. 비교 범위를 맞춥니다. 승인된 기존 CI 절차 안에서 같은 입력·설정으로 비교할 수 있는 결과를 확보합니다. 그사이 규칙이나 기본 브랜치가 바뀌었다면 함께 적고, 차이를 모두 CLI 업그레이드 탓으로 돌리지 않습니다.
  4. 보고서 판단을 되돌릴 수 있게 합니다. 비교 근거가 부족하면 새 보고서를 잠정 상태로 두고 이전 기준선을 참조합니다. 이는 보고 기준의 보류이며, 보안 도구를 임의로 다운그레이드하라는 권고가 아닙니다.

혼자 운영한다면 변경 요청 한 곳에 두 점검표와 산출물 링크를 모아 두는 정도로 시작해도 됩니다. 남길 결론은 “SBOM이 커졌다”보다 구체적이어야 합니다. 어떤 선언이 새로 보였고, 어떤 버전이 확인됐으며, 어느 스캔의 결과를 비교했는가를 답할 수 있으면 다음 업그레이드에서도 같은 기준을 사용할 수 있습니다.

검토 범위와 공식 자료

이 글은 문서·소스 검토 결과와 제안한 감사 절차를 구분해 작성했습니다. 성능 측정이나 탐지율 벤치마크는 포함하지 않습니다. SBOM 내보내기는 Supply Chain으로 스캔하는 저장소가 있는 AppSec Platform 이용 흐름을 전제로 하며, 공개 CLI 설치만으로 같은 플랫폼 기능을 이용할 수 있다는 설명이 아닙니다.

PyPI 메타데이터에서 semgrep CLI 1.181.0의 Python 요구사항은 >=3.10, 라이선스 표기는 LGPL-2.1-or-later입니다. 이는 CLI 배포물의 메타데이터이며, Supply Chain 서비스·Pro 엔진·규칙의 라이선스나 이용 권한을 뜻하지 않습니다.

댓글

댓글 쓰기