3주차: 제보 결과를 정리하고 공동 연구를 마치며

2주차 기록에서는 각자 오픈소스를 탐색하고 유의미한 후보에 팀의 검토를 모으는 방식과, 이를 관리할 워크플로를 적었다. 3주차에는 그동안 제출한 보고서의 결과를 정리하고 공동 연구를 마무리했다.

그동안 제출한 보고서의 결과

공동 연구를 마무리할 때까지 팀이 제출한 취약점 보고서 중 채택된 보고서는 3건, 반려된 보고서는 4건이었다. 이번 주에는 그동안의 제보 결과를 정리했다. 아래는 채택된 사례 중 하나로, maintainer의 수락 이후 수정 관련 응답도 받았다.

반려된 보고서 4건의 사유는 다음과 같았다.

반려 사유	건수
영향이 미미해 정보성 제보로 판단됐고, 취약점으로 인정되지 않음	1건
공격이 성립하려면 가정과 전제 조건이 너무 많이 필요해, 일반적인 공격 상황에 적용하기 어려움	2건
라이브러리 취약점으로 인정되지 않고, 제시한 사례는 애플리케이션의 특수한 구현에서 생기는 문제로 판단됨. AI가 생성한 장문의 보고서라는 지적도 받음	1건

검증과 보고서 작성에 참여하며 돌아본 점

한 제보에서 maintainer는 라이브러리의 취약점으로 보이지 않으며, 기껏해야 특수한 경계 조건의 버그에 가깝다고 답했다. 제시한 사용 방식이 실제 애플리케이션에서 쓰이는지 의문을 제기했고, 데코레이터 작성 등 애플리케이션 구현에서 생긴 문제를 라이브러리가 감지할 수는 없다고 설명했다. 같은 방식을 쓰는 애플리케이션이 있다면 그쪽에 제보할 사안이라는 판단이었다.

보고서 작성 방식에 대한 지적도 별도로 있었다. 사람이 내용을 이해하고 작성한 보고서라기보다 AI가 생성한 긴 출력물에 가깝다며, 프로젝트의 AI 정책을 확인하라는 요청을 받았다. 이 응답은 취약점 자체를 인정한 채 분량만 문제 삼은 것이 아니다. 제보한 현상이 왜 해당 라이브러리의 보안 문제인지, 공격 조건이 현실적인지부터 설명할 수 있어야 했다. AI가 제시한 근거를 직접 이해하고 검토하는 일과, 그중 판단에 필요한 내용을 추려 쓰는 일을 함께 돌아보게 됐다.

CVSS 점수는 GitHub의 CVSS 계산기를 이용해 산정했다. 제보 결과를 돌아보면서 점수가 어떻게 매겨지는지 다시 검토했다. 계산기에서 선택한 항목이 실제 공격 조건과 영향을 적절하게 반영하는지, 그 선택의 근거를 설명할 수 있는지를 짚어봤다.

보고서에는 문제가 발생하는 환경과 조건, 재현 절차, 실제로 확인한 결과와 영향, 이를 뒷받침하는 근거가 드러나야 한다고 정리했다. maintainer가 보고서를 읽고 문제를 재현하고 판단하려면 무엇이 필요한지를 생각했다. 정확한 설명이라도 같은 내용을 반복하거나 문제와 직접 관계없는 부분까지 길게 풀어쓰면 정작 확인해야 할 근거를 찾기 어려워질 수 있다. 자료를 많이 담기보다, 판단에 필요한 근거를 고르고 설명의 범위와 분량을 조절하는 일이 중요했다.

이런 점을 돌아보며 직접 검증하는 과정에 참여했다. 앞서 소개한 채택 사례는 팀원이 처음 발견한 취약점에서 시작했다. 나도 여러 팀원과 함께 해당 취약점의 검증에 참여했고, 팀이 정리한 결과를 바탕으로 최종 보고서를 작성해 제출했다. LLM이 정리한 내용을 직접 이해하고 검증하는 데서 더 나아가, maintainer의 입장에서 필요한 정보를 골라 전달하는 것까지 보고서 작성의 일부라는 점을 배웠다.

3주간의 공동 연구를 마치며

2026년 9월 25일을 끝으로, 각자 대상을 탐색하고 유의미한 후보를 함께 집중 진단하는 공동 연구를 마무리했다. 오픈소스의 취약점 후보를 찾고 팀이 함께 검증해 제보한 뒤, maintainer의 수락을 확인한 경험을 이번 프로젝트의 결과로 남긴다.

각자의 자율적인 탐색과 버그바운티 도전은 개별 활동으로 이어가되, GitHub와 Discord를 통한 팀의 경험 공유는 계속하기로 했다.

2026-09-26 정정: maintainer의 응답에 맞춰 반려 사유를 고쳤다. 라이브러리 취약점으로 인정되지 않았다는 판단과 AI 생성 보고서에 대한 지적을 구분했다.