River, 보안 취약점 대응의 끝까지

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Shopify의 Slack 기반 AI agent River는 보안 취약점 패치를 만드는 데서 멈추지 않고, 최신 코드와 PR 상태를 다시 확인한 뒤 수정·rebase·CI 재실행·인간에게 판단 위임·병합 후 폐쇄 검증까지 이어갑니다. River는 dependency 취약점의 경우 최신 repository head에 upgrade를 다시 적용하고 lockfile을 갱신하며, 이전 커밋에서 나온 CI 성공 결과는 새 커밋에 유효하지 않으므로 폐기합니다. 첫 11일 동안 open issue backlog가 약 70% 줄었고, freshness-gated merge queue를 통한 security merge 비율은 약 10%에서 80%로 높아졌습니다. 핵심은 PR 수나 녹색 CI 결과가 아니라 기본 브랜치·tracker·ledger가 증거와 함께 같은 결과를 기록할 때만 remediation 완료로 간주하는 운영 프로토콜입니다.

빠른 이해

새로운 점

패치 생성이 아니라 최신 코드·PR·tracker를 연결해 병합 후 실제 취약점 제거까지 판정하는 remediation 운영 루프입니다.

핵심 메커니즘

River는 work ledger에서 처리할 항목을 읽은 뒤 live repository, PR, vulnerability tracker와 대조합니다. 취약점이 남아 있으면 dependency upgrade를 현재 repository head에 replay하고 lockfile을 재생성하거나 application용 draft PR을 만들며, rebase마다 이전 CI 결과를 폐기하고 새 head에서 다시 실행합니다. 판단 권한이 필요한 경우 현재 상태와 시도·근거·하나의 질문을 code owner에게 넘기고, 병합 뒤 repository head의 dependency graph와 tracker·ledger를 맞춰야 remediation 완료로 판정합니다.

핵심 수치

Dependency backlog 감소: 첫 11일 동안 open issue backlog 약 70% 감소- 감소분 중 대략 3분의 2는 직접 병합, 나머지는 obsolete 또는 다른 수정으로 이미 해결된 항목
Security merge 비율: 약 10% -> 80%- 출시 이후 freshness-gated merge queue를 통한 security merge 비율
동시 처리 규모: 1분 안에 4개 thread, 35개 finding- 여러 codebase를 각기 독립적인 흐름으로 처리한 최근 실행
Dependency PR 재작업: 8개 중 7개 rebase, 6개 녹색- 7개 rebase PR 중 6개가 승인만 남긴 상태로 stewarding team에 전달

섹션별 상세

패치 이후가 진짜 과제

Shopify는 dependency upgrade와 first-party code 수정 PR을 만들 수 있었지만, PR이 검토를 기다리는 동안 저장소가 바뀌거나 병합 전후 상태가 달라져 취약점이 실제로 사라졌는지 보장하기 어려웠습니다. Slack에 사는 AI agent River는 Shopify의 monorepo World 루트에서 개발자와 같은 재현 가능한 환경과 engineering convention을 사용하고, 여기에 보안 remediation 로직을 결합합니다. River는 원래 finding을 현재 코드와 대조하고 안전할 때 최신 head에 패치를 갱신하며, 인간 판단이 필요한 순간에는 관련 엔지니어에게 현재 head·시도한 작업·근거·결정 질문을 넘깁니다. 병합 뒤에는 repository head와 dependency graph를 다시 확인하므로, 패치를 많이 만든 양이 아니라 취약점이 증거와 함께 제거됐는지가 완료 기준이 됩니다.

두 입력이 하나의 루프로

Dependency 대응은 취약한 dependency upgrade를 겨냥한 PR에서 시작하고, application 대응은 agent가 찾은 security finding과 권장 수정안에서 시작합니다. River는 application finding마다 Slack thread를 하나씩 만들고 dependency upgrade PR은 같은 코드 영역에 영향을 주는 항목을 묶어 공유 thread로 관리합니다. 한 번의 실행에서 1분 안에 4개 thread가 올라와 여러 codebase의 35개 finding을 나눠 처리했으며, 각 흐름은 서로 기다리지 않고 rebase·CI 재실행·질문 응답을 이어갔습니다. 작업 전에는 ledger, live repository, PR, vulnerability tracker를 대조하고, 이후 실행에서는 thread 상태를 다시 읽어 기록을 갱신하므로 Slack thread가 단순 대화 기록을 넘어 조사와 handoff의 공용 맥락으로 남습니다.

실제 상태를 먼저 대조

River는 ledger를 운영상의 진실로 간주하지 않고 실제 상태를 확인해야 하는 주장으로 취급합니다. GitHub의 실제 PR 상태와 ledger를 맞춰 보니 이미 병합됐거나 최근 upgrade가 उपलब्ध해 시스템에서 종료된 항목이 드러났고, 겉으로 보이던 dependency backlog의 큰 부분이 제거됐습니다. Dependency finding은 현재 codebase가 취약한 버전을 resolve하는지 또는 다른 PR이 이미 upgrade를 수행했는지 확인하고, application finding은 repository head에서도 보고된 동작이 남아 있는지와 다른 PR의 수정 진행 여부를 찾습니다. 이미 다른 변경이 문제를 해결했다면 근거를 기록하고 중단하며, 모든 검색을 수행할 수 없을 때는 그 한계도 handoff에 남겨 낡은 전제 위에서 불필요한 production 변경을 만들지 않습니다.

판단은 근거와 함께 위임

River가 스스로 결과를 결정할 수 없는 경우에는 현재 head, 수행한 작업, 확인된 근거, 소유자가 답할 최소 질문을 함께 넘깁니다. Rebase한 7개 PR 가운데 6개는 녹색 결과로 stewarding team의 승인만 남았고, 1개는 패치보다 배포 여부와 runtime type change의 동작을 판단해야 해 중단됐습니다. 다른 finding에서는 장기간 유지된 기능을 hardening하는 수정과 테스트까지 준비했지만, 개발자가 원래 요구사항을 묻자 River는 과거 설계 목적과 당시 security review, 이후 추가된 platform-level protection을 조사했습니다. 권장 패치가 보존하려던 흐름을 깨뜨린다는 근거가 나오자 River는 자신의 수정안을 철회했으며, 근거가 바뀌면 권고도 바뀌어야 한다는 handoff의 역할을 보여줬습니다.

병합 뒤에 완료 판정

보안 finding은 steward에게 ownership이 넘어가도 수정 사항이 배포될 때까지 열려 있으므로 River는 review 이후의 dependency PR도 계속 추적합니다. PR이 바뀌면 이전 테스트 결과를 무효화하고, 병합 뒤에는 repository head가 취약한 dependency를 더 이상 사용하지 않는지 확인한 다음 vulnerability record와 ledger를 같은 결과로 맞춥니다. CI를 통과한 두 dependency PR 중 하나는 병합되어 취약한 버전과 backlog item을 제거했지만, 다른 하나는 review 대기 중이라 repository head와 backlog item에 취약점이 남았습니다. 따라서 ‘done’은 녹색 PR이나 PR 개수가 아니라 source system의 결과, default branch의 실제 상태, tracker와 ledger의 일치가 모두 증거로 연결된 상태입니다.

프롬프트 밖의 운영 보장

River의 prompt와 skill은 전체 항목 열거, draft-only 동작, 인간의 merge 권한을 규정하지만, prompt 문구만으로 pagination·deduplication·current-head identity·accounting 같은 불변 조건을 보장할 수는 없습니다. 실제 실행에서 River가 진행 중인 claim 중 가장 오래된 항목만 다시 확인하고 그 사실을 보고한 사례는 ‘prompt에 적혀 있다’와 완전한 검증이 다르다는 점을 보여줬습니다. Shopify는 반복 실행이 성숙할수록 이런 보장을 code로 결정적으로 옮기고, prompt는 보고된 코드 동작이 여전히 존재하는지와 중단 근거가 충분한지 같은 판단에 사용해야 한다고 정리합니다. 다른 조직도 수정 전에 live state를 재검증하고, 테스트를 현재 SHA에 묶고, 판단 위임 때 근거와 하나의 질문을 남기며, 패치 수가 아니라 fixed·rejected·escalated라는 증거 기반 결과를 측정할 수 있습니다.

용어 해설

보안 취약점 대응(Vulnerability Remediation): — 발견된 보안 취약점을 패치 작성에서 끝내지 않고, 최신 코드에 수정 사항을 적용하고 테스트·검토·병합한 뒤 기본 브랜치와 취약점 추적 기록에서 실제로 제거됐는지 확인하는 전체 절차입니다. 이 글에서는 River가 이 과정을 자동화합니다.
모노레포(Monorepo): — 여러 애플리케이션이나 라이브러리의 소스 코드를 하나의 저장소에서 관리하는 구조입니다. River는 Shopify의 monorepo인 World의 루트에서 개발 환경, 기술 문서, engineering convention을 사용해 저장소의 맥락을 유지합니다.
Lockfile: — 프로젝트가 실제로 사용할 dependency의 정확한 버전과 의존성 관계를 고정하는 파일입니다. River는 오래된 PR의 lockfile을 그대로 재사용하지 않고 repository head의 최신 lockfile에 upgrade를 반영해 다른 변경 사항이 되돌아가지 않게 합니다.
최신 상태 검증 병합 큐(Freshness-Gated Merge Queue): — PR의 테스트 결과가 현재 커밋과 일치하는지 확인한 뒤 병합하는 queue입니다. PR이 rebase되거나 force-push되면 이전 CI 결과를 폐기하고 새 repository head에서 다시 검증해 오래된 성공 결과가 병합 판단에 쓰이지 않게 합니다.
저장소 최신 커밋(Repository Head): — 특정 시점에 저장소의 기본 브랜치 또는 작업 브랜치가 가리키는 최신 커밋입니다. PR이 통과했는지만 보지 않고 병합 후 repository head가 취약한 dependency를 더 이상 사용하지 않는지 확인해야 취약점 제거를 판정할 수 있습니다.
작업 원장(Work Ledger): — 취약점과 PR의 진행 상태를 기록하는 운영용 목록입니다. 다만 실제 저장소·PR·취약점 추적 시스템의 현재 상태와 어긋날 수 있으므로, River는 ledger의 각 항목을 사실이 아니라 다시 확인해야 할 주장으로 취급합니다.

기술

River
Slack
World
GitHub
CI
dependency graph
lockfile
freshness-gated merge queue

언급된 리소스

문서원문 링크