같은 오픈소스를 진단하던 5인 팀이 각자 대상을 맡기까지

CJ AI Security Wave 프로젝트에서는 AI의 제안을 사람이 검토한 뒤 실행하고, 결과를 기록하는 하네스를 만들고 침투테스트를 진행했다.

그 경험에서 이어진 이번 프로젝트는 2026년 9월 5일에 시작했다. 다섯 명이 LLM을 활용해 오픈소스의 취약점 후보를 찾고, 검토한 내용을 실제로 제보하는 데 도전하고 있다.

처음에는 공통 대상을 정해 각자 진단했다. 현재 진행 중인 2주차에는 각자 오픈소스를 고르고, 유의미한 후보가 나온 대상을 공유하는 방식으로 바꿨다. 나는 진단에 참여하면서 개인별 연구와 팀 검토를 연결할 워크플로를 구축했다.

첫 주의 결과를 보고 대상을 나누기로 했다

1주차에는 공통 대상을 정하고 각자 진단을 진행했다. 우리 작업에서는 LLM으로 1차 진단 결과를 얻는 과정이 비교적 빨랐다. 하지만 결과를 모아 보면 겹치는 사항이 많았고, 심각도가 낮은 후보도 많았다. 제보한 내용이 반려되는 경험도 반복됐다.

이 경험을 바탕으로, 2주차에는 각자 여러 오픈소스를 살펴보고 유의미한 결과가 나온 대상에 팀의 검토를 모으기로 했다. 개인이 대상을 탐색하는 동안에는 각자 진행하고, 집중해서 살펴볼 후보가 생기면 공유하는 것이다.

구분	1주차	2주차
대상 선정	공통 오픈소스 선정	각자 오픈소스 선정
진단 진행	같은 대상을 각자 LLM으로 진단	각자 맡은 대상을 진단하고 유의미한 결과가 나온 대상을 공유
팀이 집중할 지점	공통 대상의 진단 결과와 제보	High 이상 후보의 교차검수와 해당 대상의 집중 진단
결과 관리	진단 결과를 바탕으로 실제 제보	GitHub 저장소와 Project에서 연구·후보·제보 후 상태를 관리

새 방식에서는 각자 다른 대상을 보므로, 다른 팀원이 연구에 합류할 때 필요한 자료와 다음 작업을 함께 전달할 구조가 필요했다. 내가 구축한 워크플로는 이 인계 과정을 포함한다.

대상 연구와 개별 후보를 나눠 기록했다

먼저 대상 하나를 살펴보는 연구와, 그 안에서 발견한 개별 후보를 나눴다. 운영 문서에서는 대상별 연구를 Campaign, 개별 취약점 후보를 Finding으로 부른다.

대상별 연구에는 주담당자 한 명을 두고 범위와 기준 버전을 기록하도록 했다. 후보가 생기면 해당 연구에 연결해 별도로 관리한다. 연구를 마친 뒤에도 특정 후보의 제보나 유지보수자 응답은 계속 이어질 수 있으므로, 둘의 종료 시점도 따로 기록하게 했다.

기록을 찾는 위치도 나눴다.

위치	남기는 내용
GitHub Project	현재 담당자, 진행 단계, 다음 작업, 다음 확인일
Issue	발견 내용, 인계 요청, 검수자의 판단, 제출과 응답 이력
비공개 저장소	버전을 확인할 수 있는 근거 자료와 보고서

인계할 때는 다음 담당자, 요청할 작업, 검토할 자료의 버전을 함께 남기도록 했다. 검수자가 무엇을 확인했는지 나중에도 구분할 수 있게, 계속 바뀌는 문서 주소 대신 검토 당시의 커밋이나 파일 버전을 연결하는 규칙을 두었다.

High 이상을 공유하되, 낮은 평가도 남긴다

팀이 집중해서 검토할 후보의 기준은 High 이상으로 정했다. High 판정은 CVSS v3.1을 기준으로 했다. 다만 LLM이 제시한 심각도만으로 공유·제보 여부를 확정하지 않도록, 사람이 예비 심각도와 영향 근거를 확인한 뒤 발견자와 다른 팀원에게 교차검수를 요청하게 했다.

처음 평가와 검수 후 평가도 따로 남기도록 했다. 예비 High였던 후보가 검수 후 낮아질 수 있고, 근거가 부족해 보완이 필요할 수도 있기 때문이다. 후보의 유효성과 심각도를 각각 기록하고, 제보할지는 대상의 정책과 중복 여부 등을 함께 검토하도록 정했다.

High 미만인 결과도 저장소와 보드에 남긴다. 후보가 나오지 않은 연구는 수행 범위와 한계를 기록하도록 했다. 다음에 같은 대상을 살펴볼 때 어떤 부분을 확인했고 왜 그 판단을 내렸는지 찾아볼 수 있다.

검토한 결과가 제보 이후에도 이어지도록

워크플로에는 보고서 작성 이후의 과정도 넣었다. 검수자가 확인한 근거를 보고서에서 참조하고, 제출할 버전과 담당자를 정한 뒤 실제 제출 여부를 기록하도록 했다. 유지보수자에게서 응답이 오면 같은 후보 기록에 이어 남긴다.

보드의 상태를 바꿀 때는 사람의 검토 기록이나 실제 제보 접수 근거를 연결하도록 했다. GitHub 기능만으로 강제할 수 없는 부분은 팀의 운영 규칙으로 정했다.

현재는 새 방식으로 2주차를 진행하고 있다. 공통 대상을 진단하고 제보한 경험은 있지만, 바뀐 워크플로가 검토 시간이나 제보 결과에 어떤 차이를 만들었는지는 아직 비교할 단계가 아니다. 앞으로의 기록에서는 후보가 다른 팀원의 검토를 거치며 어떻게 달라졌는지, 제보 뒤 어떤 피드백을 받았는지를 실제 사례가 쌓이는 만큼 다루려 한다.