납품 전 SBOM 검수와 재생성
빠진 부품을 찾고,
목록을 다시 만든 실제 기록
ScanLedger가 실제로 실행한 4단계를 그대로 재생합니다.
SBOM은 프로그램에 들어간 부품(라이브러리) 목록입니다. 목록에서 빠진 부품은 목록으로 취약점을 찾는 검사에서도 빠져, 그 부품에 알려진 취약점이 있어도 경고가 나오지 않습니다.
이 데모의 시험 사례
실제 설치에서 고른 Python 패키지 8개를 기준으로, 의도적으로 패키지 1개(referencing)와 그에 걸린 의존관계(패키지끼리의 연결) 5개를 뺀 SBOM을 검사했습니다.
직접 해 보기: 부품을 빼 보세요
불러오는 중…
포스터의 사례 A(Debian OS 이미지)는 보존 기록 기준 OS 부품 0/88 → 88/88입니다. 이 페이지는 사례 B(Python) 실행을 재생합니다.
실제로 실행한 기록 4단계
찾기 → 다시 만들기 → 확인 → 거절
결과 번호(종료 코드): 0 일치 1 검토 필요 2 실패·거절
프로그램이 끝날 때 돌려주는 번호입니다. 다른 자동화 도구가 이 번호를 보고 다음 단계를 정합니다.
명령은 보기 쉽게 줄였습니다. 실제로는 전체 경로를 넣은 python -m scanledger로 실행했고 옵션은 같습니다. 출력의 폴더 경로도 표시용으로 줄였습니다.
실제 화면 녹화 (91초, 소리 없음)
위 4단계를 실제로 실행한 화면입니다. 자막이 들어 있습니다. 주소창의 녹화 PC 경로를 가린 사본입니다. 녹화 원본은 보존했습니다.
프로그램이 실제로 만든 결과 화면
보고서 전후
아래는 프로그램이 만든 원본 화면(수정 없음)
실행이 저장한 report.html 파일을 수정 없이 줄여서 보여 줍니다. 글자가 작으면 ‘크게 열기’로 보세요.
결과를 넘겨받은 사람의 확인
지문으로 결과 확인
결과를 받은 사람이 ‘내가 받은 결과가 원래 결과와 같은가?’를 확인하는 방법입니다.
실행이 끝나면 결과 폴더에 completion.json(완료 기록)이 만들어집니다. 이 파일의 지문(SHA-256 해시, 제품에서는 ‘핀’이라고 부름)은 한 글자만 바뀌어도 달라지므로, 결과 폴더와 따로 보관해 두었다가 비교합니다.
받는 쪽에서 하는 일
- 0보관한 생성 후 지문을 넣으면, 결과 폴더의 기록 파일이 지문과 맞는지 먼저 확인한 뒤 저장된 판정 “대응 확인”을 돌려줍니다.
- 2다른 지문(생성 전 지문)을 넣으면
Project completion pin mismatch(지문 불일치)로 멈춥니다.
보관한 지문과 받은 파일의 SHA-256을 비교해 변경 여부를 확인합니다. 작성자 인증이나 안전성 보증은 아닙니다.
확인한 범위
한계
- 이번 확인 범위는 같은 PC에서 고른 Python 패키지 8개와 그 의존관계입니다.
- 종료 0은 선택한 패키지·의존관계가 기준 목록과 일치한다는 뜻입니다. 보안 인증이나 납품 승인은 아닙니다.
- 패키지·의존관계는 ScanLedger로 대조하고, 취약점(CVE)은 별도 검사 도구로 확인합니다.
- 다른 PC·고객 환경 재현은 다음 확인 과제입니다.
- 같은 절차를 갖춘 별도 스크립트로도 같은 확인을 할 수 있습니다. ScanLedger는 입력·조건·판정·지문을 하나의 기록으로 묶어 줍니다.
왜 실행이 아니라 재생인가요?
이 페이지는 재현성을 위해 실제 실행 기록을 그대로 재생합니다. 숫자는 기록 파일에서 자동으로 뽑고, 기록과 일치해야 페이지를 만듭니다. 같은 명령은 제출한 소스 코드의 설치 안내로 직접 실행할 수 있습니다.
이 페이지의 보안
- 정적 파일만 사용합니다. 서버에서 실행하거나 파일을 받는 기능이 없습니다.
- 콘텐츠 보안 정책(CSP)으로 이 사이트 밖의 스크립트·요청을 막습니다.
- 보고서는 스크립트가 꺼진 sandbox 틀 안에서 보여 줍니다.
- 다른 사이트로 이동할 때 주소 정보를 보호하도록 no-referrer 정책을 적용합니다.