경계값을 맞추고 오늘 고칠 것만 남긴다

목표

SBOM 을 취약점 자료와 대조해 실제로 영향받는 것만 골라 내고, '고칠 판이 있는가' 와
'사용자에게 닿는가' 라는 두 축으로 갈라 정책 관문을 프로그램으로 적습니다.

왜 중요한가

스캐너를 처음 돌리면 빨간 줄이 수백 개 나옵니다. 그 목록을 그대로 개발팀에 보내면
아무 일도 일어나지 않습니다 — 다 고칠 수 없다는 것을 모두가 알기 때문입니다.
줄어드는 자리는 두 곳입니다. 첫째, 구간 판정이 정확해야 합니다. 고쳐진 버전을
쓰고 있는데도 걸리는 오탐이 섞이면 목록 전체의 신뢰가 무너집니다. 둘째,
고칠 판이 있는 것과 없는 것은 다른 일입니다. 고칠 판이 있으면 오늘 올리면 되고,
없으면 완화책과 기한을 적어 면제로 관리해야 합니다. 이 둘을 섞어 두면 회의는
"심각도가 높다 / 낮다" 로만 돌고 아무것도 바뀌지 않습니다.

단계

1. /opt/fixtures/sbom/feeds/advisories.json 를 읽어 /root/adv/01-feed.json 에 자료의 모양을 적습니다.
2. /opt/fixtures/sbom/sbom/paygate-1.4.2.cdx.json 의 components 를 평평하게 펴 /root/adv/02-components.json 에 씁니다.
3. /root/adv/semver_cmp.py 에 버전 비교기를 만듭니다.
4. 경계값까지 맞춰 영향받는 것만 /root/adv/04-findings.json 에 씁니다.
5. 고칠 판이 있는 것만 /root/adv/05-upgrade-plan.json 으로 옮깁니다.
6. 사용자에게 닿는 것과 빌드에서 끝나는 것을 /root/adv/06-shipped.json 에 가릅니다.
7. /root/adv/gate-vuln.py 로 정책을 적고 결과를 /root/adv/07-verdict.json 에 남깁니다.
8. /root/adv/waivers.json 의 면제를 적용해 /root/adv/08-verdict.json 으로 다시 판정합니다.

참고

• 작업은 전부 /root/adv 아래에서 합니다. 먼저 mkdir -p /root/adv 를 하세요.
• 구간은 introduced 이상 fixed 미만입니다. fixed 와 같은 버전은 이미 고쳐진 것입니다.
• introduced 의 "0" 은 "어떤 버전보다도 앞" 을 뜻하는 특수값입니다.
• last_affected 는 그 값까지 영향받는다는 뜻이라 경계의 포함 여부가 fixed 와 반대입니다.
• 기준일은 2026-09-11 로 고정합니다. date 를 읽어 쓰면 내일 다른 답이 나옵니다.
• 흔한 실수 — 버전을 문자열로 비교하는 것("1.9.0" > "1.10.0" 이 참이 됩니다), 그리고

한 권고에 구간이 둘 이상일 때 첫 구간만 보고 끝내는 것입니다.

• 패키지 이름과 권고 번호는 실습용으로 지어낸 것입니다.

단계 8개

1. 자료가 무엇을 말하는지부터 읽는다
2. 무엇을 대조할 것인지 목록으로 세운다
3. 버전을 문자열로 비교하면 안 되는 이유를 코드로 못박는다
4. 경계값까지 정확히 맞춘다
5. 오늘 고칠 수 있는 것만 계획으로 옮긴다
6. 사용자에게 닿는 것과 빌드에서 끝나는 것을 가른다
7. 정책을 사람 말이 아니라 프로그램으로 적는다
8. 면제는 고칠 수 없는 것에만 준다