왜 지금 이 진단이 필요한가
보안 업데이트 대응 속도를 이야기할 때, 대부분의 팀은 자사 코드베이스나 벤더 패치 주기를 먼저 본다. 그런데 실제 지연이 발생하는 지점은 종종 다른 곳에 있다. 자사 서비스가 직접 호출하지도 않는 깊은 의존성, 그 프로젝트를 혼자 유지하는 개발자가 응답하지 않는 상황이다.
공개된 분석 결과 중 하나를 보면, 스마트폰·브라우저·서버가 의존하는 23개 핵심 오픈소스 프로젝트 가운데 11개는 최근 1년간 코드를 10회 이상 수정한 사람이 1명 또는 2명뿐이었다. 압축 도구 xz, 타임존 데이터베이스, bash 셸, zlib, SQLite가 여기 포함된다. 이 프로젝트들은 사실상 모든 리눅스 서버, iOS와 안드로이드 기기, 주요 브라우저에서 실행된다.
숫자보다 중요한 것은 이 상황이 만들어내는 실제 위험 구조다. 유지보수자가 1명인 프로젝트에서 보안 결함이 발견되면, 패치 타임라인은 그 한 사람의 가용 시간과 판단에 달려 있다. 그 사람이 비상근이거나 재정 지원 없이 운영하고 있다면 대응 속도는 더 느려질 수 있다. 팀이 SLA를 아무리 짧게 잡아도, 업스트림 패치가 나오지 않으면 선택지는 좁아진다.
진단 대상과 범위를 먼저 정하라
진단을 시작하기 전에 범위를 정해야 한다. 전체 의존성 트리를 한꺼번에 보려 하면 우선순위를 잡기 어렵다. 다음 두 기준으로 범위를 좁히는 것이 현실적이다.
첫째, 프로덕션 환경에서 실제로 실행되는 패키지만 대상으로 한다. 개발 도구나 테스트 전용 라이브러리는 1차 진단에서 제외할 수 있다.
둘째, 시스템 콜과 가까운 위치에 있거나 네트워크 입력을 직접 처리하는 컴포넌트를 우선순위에 올린다. 압축, 파싱, 인증, 암호화 관련 라이브러리가 여기 해당한다. 이 계층에서 취약점이 발생했을 때 영향 반경이 가장 넓다.
범위를 정했으면 npm audit, pip-audit, Dependabot, OWASP Dependency-Check 같은 도구로 현재 의존성 목록을 뽑는다. 이 단계의 산출물은 '프로덕션 의존성 목록'이며, 다음 단계의 입력이 된다.
유지보수자 현황 데이터를 어디서, 어떻게 수집하는가
의존성 목록이 준비됐다면, 각 프로젝트의 유지보수자 현황을 확인해야 한다. 자동화 도구가 이 작업을 완전히 대신할 수는 없다. 수작업이 필요한 이유는, 기여자 수가 같아도 실제로 리뷰·릴리스를 승인하는 사람이 다를 수 있기 때문이다.
GitHub 저장소에서 확인할 수 있는 항목
- 최근 12개월 커밋 로그: 전체 커밋 중 특정 계정이 차지하는 비율
- 이슈·PR 응답 이력: 마지막 응답까지 걸린 시간, 미해결 보안 이슈의 체류 기간
- 릴리스 권한 보유자: 누가 태그를 생성하고 패키지를 배포하는가
공개 재정 정보를 통해 확인할 수 있는 항목
- Open Collective, GitHub Sponsors, Sovereign Tech Agency 지원 여부
- 기업 후원 여부(README, FUNDING.yml 파일 확인)
이 두 축을 조합하면 프로젝트별로 다음 네 가지 유형 중 하나로 분류할 수 있다.
| 유형 | 유지보수자 수 | 재정 지원 | 위험 수준 |
|---|---|---|---|
| A | 1~2명 | 없음 | 높음 |
| B | 1~2명 | 있음 | 중간 |
| C | 3명 이상 | 없음 | 중간 |
| D | 3명 이상 | 있음 | 낮음 |
유형 A에 해당하는 의존성이 프로덕션 핵심 경로에 있다면, 이후 단계에서 별도 대응 계획이 필요하다.
이 단계의 산출물은 '의존성별 유지보수자 현황 시트'다. 프로젝트명, 유형 분류, 최근 릴리스 날짜, 미해결 보안 이슈 수, 재정 상태를 포함한다.
유지보수자 단일 의존 프로젝트에서 나타나는 실제 위험 패턴
유지보수자 현황 데이터가 왜 보안 계획에 들어가야 하는지, 공개 사례 세 가지를 통해 설명한다.
패치 타임라인 지연. bash 셸의 Shellshock 취약점은 1989년에 작성된 코드에서 비롯됐고, 2014년에 공개됐다. 유지보수자는 단일 인물로, 본업이 따로 있는 비상근 관리자였다. 취약점이 수억 대 서버에 영향을 미치는 규모였음에도 초기 대응 속도는 유지보수자 한 명의 가용 시간에 묶여 있었다.
공급망 침해 가능성. xz 압축 도구의 경우, 유지보수자가 장기간 정신 건강 문제를 안고 혼자 운영하면서 역량에 한계가 있다고 공개적으로 밝혔다. 이 상황을 파악한 외부 행위자가 수개월에 걸쳐 기여자 신뢰를 쌓고 커밋 권한을 얻은 뒤 악성 코드를 삽입했다. 재정 지원이 있었다면, 또는 릴리스 검토 인력이 한 명 더 있었다면 결과가 달랐을 것이라고 단정할 수는 없다. 그러나 단일 유지보수자 구조가 이 공격 경로를 더 쉽게 만든 것은 사실이다.
법적·운영 공백. 타임존 데이터베이스는 세계 40억 대 이상의 기기가 현지 시각을 계산하는 데 사용한다. 2011년에 저작권 소송으로 배포 서버가 일시 오프라인 상태가 됐고, 유지보수자가 교체되지 않으면 갱신이 중단될 수 있는 구조다. 이 프로젝트에는 현재도 공개 후원 채널이 없다.
세 사례가 보여주는 공통 패턴은 이렇다. 단일 유지보수자 프로젝트에서 위기는 코드 품질 문제가 아니라 운영 구조 문제에서 시작된다. 유지보수자의 건강, 재정, 법적 상황, 가용 시간이 패치 타임라인에 직접 반영된다.
보안·장애 대응 계획에 반영하는 방법
유지보수자 현황 시트가 완성됐으면, 이를 기존 보안 및 장애 대응 계획에 연결하는 작업이 남는다. 세 개 항목으로 나눠 설명한다.
1. 위험 시나리오 등록
유형 A 의존성마다 "이 프로젝트에 보안 취약점이 공개됐는데 업스트림 패치가 30일 이상 나오지 않으면 우리 팀은 무엇을 하는가"라는 질문에 미리 답을 써둔다. 선택지는 세 가지 정도로 좁혀진다. 첫째, 직접 포크해서 패치한다. 둘째, 대체 라이브러리로 전환한다. 셋째, 해당 기능을 임시 비활성화하거나 격리한다. 어떤 선택이 현실적인지는 의존성의 용도와 팀 역량에 따라 다르다. 중요한 것은 이 판단을 사고 발생 후에 처음 하는 것이 아니라, 지금 미리 해두는 것이다.
2. 모니터링 항목 추가
유형 A 프로젝트에 대해서는 CVE 알림 외에 저장소 활동 모니터링을 추가한다. 유지보수자 계정의 커밋이 3개월 이상 없거나, 보안 관련 이슈에 응답이 없거나, 릴리스가 예정보다 지연되는 신호가 보이면 조기에 대응 시나리오를 검토할 수 있다.
3. 업스트림 기여 또는 재정 지원 여부 검토
이 항목은 선택적이지만, 가능하다면 실질적인 영향을 준다. sudo의 경우, 유지보수자가 후원을 공개적으로 요청한 이후 언론 보도가 이어지면서 연간 약 6만 달러 수준의 후원이 모였다. 이것이 단일 유지보수자 구조의 위험을 해소하지는 않지만, 유지보수자의 운영 여건을 개선한다. 자사 서비스에 깊이 의존하는 유형 A 프로젝트에 대해 GitHub Sponsors나 Open Collective를 통해 소규모라도 후원하는 것은 기업 입장에서 비용 대비 위험 경감 효과가 있는 선택일 수 있다.
이 단계의 산출물은 '의존성 위험 등록부'다. 유형, 위험 시나리오, 대응 시나리오, 담당자, 모니터링 조건을 포함한다.
정기 검토를 어떻게 운영할 것인가
유지보수자 현황은 정적이지 않다. 오늘 활발한 프로젝트가 6개월 뒤 사실상 방치 상태가 될 수도 있다. 반대로 재정 지원이 들어오거나 새 기여자가 합류하면서 위험이 낮아지기도 한다.
현실적인 검토 주기는 분기 1회 정도다. 의존성 목록 전체를 매번 다시 분석하기보다, 유형 A로 등록된 항목만 빠르게 상태를 확인하는 방식이 지속 가능하다. 확인 항목은 세 가지면 충분하다. 마지막 릴리스가 언제인가, 미해결 보안 이슈가 늘었는가, 유지보수자 상태에 변화가 있는가.
이 검토를 누가 할 것인지도 미리 정해야 한다. 보안 팀이 담당할 수도 있고, 플랫폼 엔지니어링 팀이 담당할 수도 있다. 중요한 것은 담당자가 정해져 있고, 검토 결과가 위험 등록부에 반영되는 루프가 닫혀 있어야 한다는 점이다.
