핵심 요약
- 자동 수정 봇이 도입되면 알림 백로그가 그대로 PR 백로그로 옮겨가고, 개발팀이 내용을 읽지 않고 PR을 닫아버리는 패턴이 반복된다
- 자동화 이전에 가장 먼저 적용해야 할 저비용 게이트는 ‘배포된 아티팩트에 취약 버전이 실제로 존재하는지’ 확인하는 단계이며, 이 단계에서 상당수의 findings이 제거된다
- 그 다음 게이트는 도달 가능성(reachability) 분석으로, 취약 함수가 외부 입력이나 네트워크 경로상에서 실제로 호출되는지를 정적·동적 신호로 판단한다
분석
목차
취약점 트리아지를 거치지 않은 자동 패치 봇은 알림을 PR로 옮겨놓는 일만 합니다. 한밤중에 Dependabot이 40개의 PR을 열고, 다음 날 백엔드 팀은 40개를 한 번에 close 합니다. 닫힌 PR 중 절반은 dev 브랜치 전용 라이브러리였고, 닫히지 말아야 할 3개도 같이 묻혔습니다.
이 패턴이 반복되는 이유는 단순합니다. 봇은 “버전이 매칭된다”까지만 보고, “배포됐는가”와 “도달 가능한가”를 보지 않습니다. 사람은 그 두 질문을 봇보다 훨씬 빠르고 정확히 답하는데, 정작 그 자리에 사람을 앉히지 않습니다.
왜 같은 일이 반복되는가
대부분의 팀이 자동 패치 봇을 도입할 때 SLA를 “PR 생성까지”로 정의합니다. PR이 만들어지면 봇의 책임은 끝나고, 이후는 개발자 몫입니다. 문제는 그렇게 닫힌 PR이 별도로 기록되지 않는다는 점입니다. 분기 보고서에는 “올해 1,240건 패치 PR 처리”라는 숫자만 남고, “그중 600건은 dev 브랜치였다”라는 사실은 남지 않습니다.
필자가 실무자 입장에서 가장 의미 있다고 본 지점은, 자동화 효율을 PR 생성 수로만 측정하면 봇이 무의미한 작업을 더 빠르게 만들어낸다는 사실입니다. 취약점 트리아지 자체를 별도 단계로 분리하지 않으면 자동화는 백로그를 옆 칸으로 옮기는 도구에 그칩니다.
취약점 트리아지 4단계 게이트 구조
1단계 — 배포 아티팩트 매핑
스캐너가 가리키는 버전이 실제 컨테이너 이미지나 런타임 패키지 목록에 포함되는지 확인합니다. dev/test 전용 의존성, 미배포 모듈, transitive 패키지의 중복 매칭은 여기서 제거합니다. 이 단계만으로 findings의 30~50%가 빠집니다.
2단계 — 도달 가능성
취약 함수가 실제로 호출 경로 위에 있는지 정적 호출 그래프와 런타임 신호로 확인합니다. unreachable 코드, 비활성 플래그 뒤의 경로는 패치 대상에서 제외합니다. 호출 그래프가 없으면 외부 입력에 닿는 경로만 휴리스틱으로 남깁니다.
3단계 — KEV/EPSS 우선순위
CISA KEV에 등재된 항목은 단독으로 최상위 큐로 이동시킵니다. EPSS 점수는 보조 지표로만 쓰고, “EPSS 0.05라 안 급하다”는 단일 근거로 이슈를 종결하지 않습니다. 이 규칙은 운영 위키와 자동 close 룰 양쪽에 남겨야 합니다.
4단계 — 노출 경로와 보상 통제
공개 인터넷 노출 여부, 내부 전용 여부, WAF·네트워크 분리·권한 제한 같은 보상 통제가 있는지 평가해 잔여 위험을 재산정합니다. 통제로 위험이 충분히 낮아진 경우 패치 우선순위를 조정합니다.
1·2단계는 봇이 자동화해도 됩니다. 3·4단계의 우선순위 충돌, 보상 통제 판단, 예외 승인은 사람이 명시적으로 결정합니다. 이 경계가 흐려지면 무관한 PR 폐기와 실제 위험 누락이 동시에 양산됩니다.
검증된 해법과 그 한계
4단계 게이트 구조는 2025년 이후 공개된 보안 운영 사례들에서 반복적으로 등장합니다. 자동 수정 도입 전 트리아지 범위를 어디까지 자동화할지가 여러 차례 거론됐고, 결론은 “도달 가능성과 보상 통제는 사람이 본다”로 수렴합니다.
한계도 분명합니다. 호출 그래프 유지 비용이 만만치 않고, 작은 조직은 KEV/EPSS 데이터 파이프라인을 자체 운영하기 어렵습니다. 1단계의 아티팩트 매핑조차 컨테이너 이미지가 일일 수십 개씩 바뀌면 사람의 손을 빌려야 합니다.
흔한 실수
- 봇 도입 효과를 “PR 생성 수”로만 측정한다
- EPSS 0.1 미만 항목을 자동 close 대상으로 묶는다
- 3·4단계 판단까지 자동화하려다 보상 통제를 누락한다
이 세 가지가 동시에 일어나면 취약점 트리아지 자체가 무너지고, 무관한 PR 폐기와 실제 위험 누락이 함께 발생합니다. 자동화 효율만 쫓아 사람의 판단 단계를 완전히 제거하는 패턴입니다.
취약점 트리아지 단계별 자동화·사람 비중
| 게이트 | 자동화 가능성 | 사람 판단 비중 | 유지 비용 |
|---|---|---|---|
| 1단계 아티팩트 매핑 | 높음 | 낮음 | 낮음 |
| 2단계 도달 가능성 | 중간 | 중간 | 중간 |
| 3단계 KEV/EPSS | 높음(룰 기반) | 낮음 | 낮음 |
| 4단계 노출·통제 | 낮음 | 높음 | 높음 |
지금 바로 해볼 것
- 스캐너 findings 중 dev 브랜치와 미배포 모듈 비율을 1회 추출하고, 취약점 트리아지 1단계 게이트의 필터링 효과를 함께 측정한다
- KEV 등재 항목을 별도 큐로 분리하는 룰을 오늘 작성한다
- EPSS 단독 close 룰이 코드에 남아 있는지 grep으로 검색한다
- 자동 생성 PR과 사람이 보는 PR을 GitHub 라벨로 분리한다
- 분기 1회 자동 close 비율을 리포팅 항목에 추가한다
실무 적용 포인트
- 1·2단계 게이트는 봇이 돌리고, 3·4단계에서 사람을 멈추게 설계한다
- KEV 등재 사실은 최상위 큐 점프의 충분 조건으로 문서화한다
- EPSS 낮은 점수만으로 이슈를 종결하지 않는다는 운영 규칙을 코드와 위키 양쪽에 남긴다
- 자동 close된 PR은 별도 로그에 누적해 분기 보고서에 반영한다
- 취약점 트리아지 단계에서 만든 호출 그래프 자원은 다른 보안 점검과 공유 가능한 자원으로 관리한다
자주 묻는 질문
자동 패치 봇 도입 전, 취약점 트리아지 게이트에서 가장 먼저 무엇을 만들어야 하나요?
스캐너 알림에서 dev/test 전용 의존성과 미배포 모듈을 제거하는 1단계 게이트부터 만듭니다. 이 단계만으로 PR 백로그의 상당 부분이 사라지고, 이후 단계의 정확도가 함께 올라갑니다.
EPSS 점수가 낮으면 패치를 미뤄도 되나요?
아닙니다. EPSS는 보조 지표일 뿐이며 단독 근거로 이슈를 종결하면 안 됩니다. KEV 등재 사실, 도달 가능성, 노출 경로를 함께 봐야 실제 위험이 보입니다.
호출 그래프가 없는 환경에서 취약점 트리아지 2단계 도달 가능성은 어떻게 판단하나요?
외부 입력에 닿는 함수 경로만 휴리스틱으로 남기고 나머지는 다음 게이트로 넘깁니다. 호출 그래프 자체를 일회성 점검 자산이 아니라 지속 자원으로 구축하는 것이 장기 과제입니다.
보상 통제로 위험이 충분히 낮아진 경우는 어떻게 판단하나요?
WAF, 네트워크 분리, 권한 제한이 실제 운용 중인지 확인한 뒤 잔여 위험을 재산정해 패치 우선순위를 조정합니다. 판단 근거는 PR 코멘트에 남겨 추후 재평가에 사용합니다.
원 스레드의 토론은 자동 수정 도입 전 트리아지 논의에서 확인할 수 있습니다.
같은 호출 그래프 자원을 공급망 점검과 함께 운용하는 절차는 공급망 보안 5단계 절차에서 다룹니다.
참고 원문
이 기사는 다음 원문을 확인해 작성했습니다: r/AskNetsec — Are we automating fixes before we can triage?
전문가 코멘트(AI)
애플리케이션 보안(AppSec) 전문가
트리아지 게이트 우선, 자동 패치 나중이라는 순서는 업계 수렴된 정답이지만 실행 비용의 현실성이 관건이다
배포 아티팩트 매핑 → 도달 가능성 → KEV/EPSS → 노출·보상 통제로 이어지는 4단계 구조는 SLSA·SSVC·VEX 등 국제 표준 흐름과 부합하는 검증된 프레임이다. 특히 1단계에서 dev 전용 의존성과 미배포 모듈을 걷어내는 것은 도구 없이도 즉시 적용 가능한 저비용·고효과 필터다. EPSS를 단독 close 근거로 쓰지 말라는 원칙도 EPSS가 ‘악용 확률’만을 반영하고 영향도를 담지 않는다는 통계적 한계를 정확히 짚은 것이다. 다만 도달 가능성 분석은 호출 그래프 구축·유지 비용이 커서 중소 조직에는 사실상 상용 도구 의존이 불가피하고, 이 부분에 대한 대안 제시가 약하다. KEV가 미국 인프라 중심이라는 지역·부문 편향도 보완 논의가 필요하다.
DevSecOps 운영 전문가
자동화 지표를 ‘PR 생성 수’에서 ‘실제 위험 제거율’로 바꾸는 것은 올바른 방향이지만, 파이프라인 유지보수 벽에 부딪힌다
수정(chatbot/봇) 자동화가 트리아지 없이 도입되면 문제를 줄이지 않고 백로그의 형태만 바꾼다는 통찰은 Dependabot·Renovate 대규모 도입 조직에서 반복 관찰되는 현실이다. 지표를 닫힌 PR 비율, 트리아지 통과율 중심으로 재설계하라는 접근은 측정 가능하고 즉시 실행 가능하다는 점에서 강점이 크다. 그러나 호출 그래프와 컨테이너 매핑 자원은 보안팀만의 일회성 구축으로 끝나기 쉽고, 이미지가 수십 개씩 바뀌는 CD 환경에서는 SBOM 실시간 동기화 같은 플랫폼 엔지니어링 투자 없이는 유지가 되지 않는다. 보상 통제 판단을 PR 코멘트에 기록하는 관행은 감사·재평가 관점에서 좋지만 개발자에게 추가 작업 부담을 주어 룰이 형해화될 위험이 있다. 결국 이 모델의 성패는 보안과 플랫폼 팀의 조직적 협업 구조에 달려 있다.
비판적 분석가
‘트리아지가 먼저’라는 상식적 결론 뒤에는 보안 자동화 벤더가 도구 판매 근거를 확보하려는 구조가 읽힌다
겉으로는 개발자의 소명 없는 PR 폐기를 막자는 합리적 제안이지만, 이면을 들여다보면 ‘1·2단계는 봇이 하고 3·4단계는 사람이 하라’는 구도는 사실상 고가의 도달 가능성 분석 도구와 위험 우선순위(VRM) 플랫폼에 대한 요구사항 명세로 읽힌다. 호출 그래프 유지 비용이 만만치 않다는 한계를 스스로 인정하면서도 자체 운영을 장기 과제로 남겨두는 것은, 결국 해당 기능을 제품으로 파는 벤더에게 유리한 심리적 발판을 깔아주는 방식이다. KEV·EPSS 파이프라인을 ‘코드와 위키 양쪽에 남겨라’는 운영 지침 역시 규모가 있는 조직일수록 외부 위협 인텔리전스 구독으로 귀결되기 쉽다. 우리가 진짜 주목해야 할 점은, 트리아지 자동화 논의가 확산될수록 단순 스캐너·Dependabot 계층은 무료화되고 판단 계층이 유료 SaaS로 이동하는 시장 재편이 동시에 진행된다는 사실이다. 그렇다면 이 글에서 말하는 ‘사람의 판단’은 정말 사람에게 돌아가는 것일까, 아니면 사람이 돈을 내고 구매하는 ‘자동화된 판단’일 가능성은 없을까.
물밑 시나리오
- 도달 가능성 분석 도구를 판매하는 벤더들이 자동 수정 봇의 폐해 사례를 수집·증폭해 시장이 트리아지 게이트 없이는 자동화를 도입하면 안 된다는 인식을 형성한 뒤, 그 게이트를 상품화하는 구도일 가능성이 있다 – 실제로 2023년 이후 ‘위험 우선순위’ 카테고리 벤더 자금 조달이 급증했다
- 트리아지 실패 사례가 대중화되는 타이밍이 AI 코드 수정 에이전트 출시 붐과 겹치는 것은 우연이 아니라, AI 자동 패치에 대한 불안을 조성해 폴리싱·게이팅 계층이라는 새로운 수익 공간을 열어주려는 내러티브 운용일 가능성이 있다