CVE 한 건에서 AI의 설명과 실행 결과를 나눠 기록했다

8월 10일, 첫 분석 대상으로 CVE-2021-41773을 골랐다. 공개 자료를 읽고 내 로컬 환경에서 시험했다.

여러 도구를 엮기 전에 한 가지가 걸렸다. 며칠 뒤 다시 읽어도 AI의 설명과 내가 직접 본 결과를 구분할 수 있을까.

보고서는 잘 나왔는데 출처를 알 수 없었다

첫 버전은 CVE 정보를 받아 분석 보고서를 만들었다. 그런데 다음 날 다시 읽으니 어느 문장이 어디서 왔는지 알 수 없었다.

공식 자료나 코드에서 확인한 사실, 그 사실을 바탕으로 한 추론, 아직 확인하지 못한 내용을 나눠 적었다. 출처와 실행 기록에는 번호를 붙여 문장에서 원본 파일까지 찾아갈 수 있게 했다.

처음에는 재현에 실패한 실행을 지웠다. 그러자 다음 세션의 에이전트가 이미 기각한 가설을 새 아이디어처럼 다시 꺼냈다. 이후에는 실패한 실행과 기각한 이유도 함께 넘겼다.

GO가 무엇을 승인하는지 나도 헷갈렸다

강사님이 주신 기본 하네스에는 사람이 GO를 입력하면 다음 단계로 넘어가는 규칙이 있었다. 대화를 한참 주고받고 나니 그 GO가 무엇을 승인했는지 나도 바로 답할 수 없었다.

승인할 때 대상과 작업, 실행 횟수를 함께 적고 실행 직전에 다시 비교하게 했다. 허가 범위를 벗어나거나 실패한 요청을 이유 없이 반복하면 멈췄다. 첫 주에는 이 규칙에 자주 걸렸다. 특히 에이전트가 한 번 유력하다고 판단한 경로를 계속 시도하려 했다.

결과를 비교할 때는 같은 환경에서 조건 하나만 바꿔 두 번 실행했다. 취약한 조건에서 보인 현상이 비교 조건에서도 나타나는지 살피고, 두 결과를 보고서에 함께 남겼다.

두 번째 CVE를 붙이자 코드를 복사하고 있었다

첫 구현에는 특정 CVE 이름과 파일 구조가 곳곳에 박혀 있었다. 두 번째 사례를 붙이다 보니 첫 사례를 복사해 이름만 바꾸고 있었다.

입력 처리와 공통 분석 부분을 나눴다. CVE 번호나 저장소 주소를 받아도 결과는 같은 형식으로 저장하게 했다. 분석에 쓴 코드와 컨테이너 버전도 고정해, 나중에 같은 환경을 다시 찾을 수 있게 했다.

모델이 바뀌어도 승인 규칙과 기록 방식은 유지하고 싶었다. 그래서 모델이 맡는 분석과 파일·프로세스를 다루는 코드를 분리했다.

파일을 건드리지 않았는데 해시가 달라졌다

가장 작아 보이면서 오래 걸린 문제는 파일의 해시값이었다. 증거 파일을 열어 보면 내용은 똑같았지만, 기록해 둔 해시값과 달랐다.

증거 수집 코드를 의심해 파서를 고치고 저장 순서와 인코딩도 맞췄다. 그래도 값은 달랐다.

원인은 Git의 줄바꿈 변환이었다. core.autocrlf 설정과 증거 디렉터리의 처리 규칙을 정리하고 나서야 같은 파일에서 같은 해시가 나왔다. 파일을 직접 고치지 않아도 도구를 거치면서 내용이 바뀔 수 있었다.

같은 코드로 두 CVE 사례의 테스트와 자동 검사를 통과했다. 여기까지 확인한 것은 개인용 하네스다.