수집처별 법적·운영 경계 정리

0URL이 열린다는 사실만으로 수집할 수는 없습니다

고객사가 직접 운영할 보안데이터 수집 체계를 설명하려면 데이터 종류와 공급처만 적어서는 부족했습니다. 같은 공개 URL이어도 공공데이터, OSS 저장소, API 키가 필요한 서비스, 자동 접근을 제한하는 사이트의 운영 경계가 달랐습니다.

현재 크롤러가 실제로 쓰는 수집처를 다시 맞추고, 약관·데이터 라이선스·API 정책·robots 조건을 한 표에서 비교했습니다. 이 과정은 수집기의 기술 설계에 필요한 사전 검토이며 법률 자문이나 최종 승인 문서가 아닙니다.

1검토 범위를 먼저 잘랐습니다

고객 보고 범위는 라이브러리, 취약점, 13개 OS 배포판 보안 데이터, 라이선스와 호환성 자료였습니다. 파일·함수·바이너리 컴포넌트, 코드 레벨 취약점, exploit/PoC 데이터, Snyk는 1페이지 요약에서 제외했습니다.

원문 URL, 공식 API·파일·저장소 여부, 수집 방식과 주기, 약관 원문, rate limit, API 키 명의를 함께 보았습니다. “공개되어 있음”과 “현재 운영 모델에서 사용 가능함”을 같은 의미로 쓰지 않았습니다.

2세 등급을 행동으로 연결했습니다

접근 차단 우회는 선택지에서 제외했습니다. HTML을 다른 방식으로 호출하는 것도 공식 인터페이스나 허가가 없으면 해결책으로 보지 않았습니다.

4실제 판단 사례

• npm — 공개 crawler 정책이 API 복제를 허용하지만 초당 1회·월 500만 요청 조건을 운영 설정에 반영해야 합니다.
• GitLab Advisory — gemnasium-db의 상업적 사용 제한 가능성을 피하기 위해 MIT 라이선스의 advisories-community 전환을 검토 대상으로 뒀습니다.
• Amazon·Oracle OS 패키지 — 자동 수집 제한이 있어 vendor repodata 같은 대체 경로나 서면 동의가 필요합니다.
• Cloudera·Atlassian Maven — 약관과 robots 제한을 확인해 공식 지원 프로토콜의 허용 범위를 확인하거나 서면 협의하도록 분리했습니다.
• NVD·GitHub API — API 키·토큰 명의와 rate limit를 고객 운영 주체에 맞춰 정해야 합니다.

5결과

• 수집 데이터와 공급처를 고객 보고용 1페이지 표로 줄이면서도, 고위험 출처와 필요한 대체 경로를 감추지 않았습니다.
• 공개 API·파일·저장소 우선, 접근 차단 우회 금지, source별 rate limit, attribution, API 키 명의를 공통 운영 조건으로 정리했습니다.
• 고객이 직접 운영하는 수집 체계와 회사가 자체 DB를 제3자에게 제공하는 경우를 분리했습니다. 후자의 공급자 협약 문제는 아직 Needs confirmation입니다.
• 고위험 출처의 서면 동의 여부, 중위험 출처의 설정 반영 여부, 개인정보·출처 표기 방식은 후속 확인 항목으로 남겼습니다.

6역할

현재 crawler fleet와 기존 수집처 문서를 대조하고, 출처별 이용 조건과 대체 경로를 표로 정리했습니다. 법적 결론을 대신 내리지 않고 기술적으로 확인된 제약, 사업 계약에 들어갈 가정, 법무 판단이 필요한 항목을 분리했습니다.

관련 항목: 12개 라이브러리 크롤러 누락 점검과 Python 전환 · 취약점 검증 및 고객사 대응