AI 지원 취약점 리서치에는 화려한 "0-day를 찾았다"라는 말 이전에, 수수하지만 결정적인 공정이 있다. "이것이 정말로 신규이며, 실재하는 결함인가"를 확인하는 공정이다. 이 기사는 인가(authorization)에만 초점을 맞춘 검사 하네스(harness)를 성숙한 OSS 3개에 적용하여, 비자명한 측면에서 실재하는 CVE급 버그를 블랙박스 방식으로 재발견하고, 그리고——그것이 이미 수정된 공개 CVE임을 알고 보고를 보류했던, 그 모든 과정의 기록이다. exploit은 싣지 않는다. 싣는 것은 방법과, 이미 공개된 CVE 번호뿐이다.

1. 만든 것——인가를 주제로 한 검사 하네스

3개의 부품으로 구성되어 있다. (a) deny-by-default 방식의 egress scope-lock (허가된 목적지 이외로의 통신을 기구적으로 거부), (b) 인간의 승인을 데이터 계층에서 강제하는 append-only 기록 기반 (취약성의 "확정"은 LLM이 아닌 인간 게이트를 통함), (c) "자동화해도 좋은 공정 / 인간에게 남길 공정"을 나눈 협력적 취약점 공개(CVD) 파이프라인. 이 위에서, 자체 호스팅한 OSS를 자신의 2개 계정(self-A / self-B) 차이점을 이용해 블랙박스 테스트한다. 공격적인 정찰(무인가 스캔·피해자 찾기)은 일절 하지 않는다. 만지는 것은 자신이 단독 점유하는 자신의 실험실뿐이며, 데이터는 합성 데이터(synthetic data)만을 사용한다.

2. 우선, 솔직한 무성과

처음에 성숙한 OSS 3개 대상(태스크 관리 2종 + no-code DB)의 "주요 CRUD의 수평적 IDOR"——"B가 A의 object를 id로 읽을 수 있는가"——를 계통적으로 파헤쳤다. 결과는 전부 403, finding 제로. 이것은 실패가 아니라 올바른 결과다. 인기 있는 OSS가 가장 견고하게 방어하고 있는 부분이 바로 이 "전면"이기 때문이다. 중요한 것은 여기서 "아무것도 없었다"라고 솔직하게 기록할 수 있는 것이다. 녹색(테스트 통과)은 동작을 의미하지 않는다. A-control(정규 권한)로 매번 200 응답과 기지 데이터를 선취하여 위양성(false positive)을 제거한 후의 "무성과"이기에, 이후의 주장이 신뢰를 얻을 수 있다.

3. 조준을 바꾸다——표적 선정보다 "노리는 면"

가설은 이렇다. 실재하는 인가 버그는, per-object 권한 체크를 "통과하지 않는 별도의 코드 경로"에 있다. 집계(group by), 관계의 전개(linked records / lookup), 파생적인 read(export·알림·피드), 그리고 "의도된 공유"(shared view)의 누락. 전면이 견고하다면, 표적을 바꾸는 것이 아니라 노리는 "면"을 바꿔야 한다.

4. 재조준의 첫 시도에서 적중

no-code DB의 public shared-view에 조준을 맞춘 1사이클 만에, 블랙박스 차분 테스트가 2개의 over-exposure를 재현했다. 하나는 뷰에서 숨긴 열(column)의 값이 집계 endpoint를 통해 원본 그대로 반환되는 것. 다른 하나는 공유하지 않은 관련 테이블의 레코드가 관계 전개 endpoint를 통해 반환되는 것이다. 결정적인 요인은 불일치였다——주 경로(통상적인 행 취득 API)는 열 숨김을 엄격하게 강제하고 있었다. "주 경로는 보호하면서, 보조적인 endpoint는 보호하지 않는다". 이것은 사양상의 장식이 아니라, ACL 우회의 징표다.

5. 그리고, 자신의 발견을 버렸다

여기가 본론이다. "0-day를 찾았다"라고 외치기 전에, 공개 advisory를 대조했다(대상에는 언급하지 않고, 공개 정보만 읽는다). 결과, 재현한 2개는 이미 CVE-2026-47378(숨겨진 열의 집계를 통한 노출·관련 데이터 경계 침범)과 CVE-2026-47279(공개된 shared-view의 관계 endpoint가 열의 가시성을 검증하지 않음)로 공표되었으며, 수정 완료된 상태였다. 게다가 테스트한 instance는 배포 채널의 시차로 인해 수정 전의 코드를 실행하고 있었음을, 버전과 빌드의 차이를 통해 결정론적으로 확인했다. ∴ 이것은 신규 0-day가 아니라, 기지 CVE의 (업데이트되지 않은 버전에서의) 재현에 불과하다. 따라서 보고하지 않는다——이미 공표되고 수정된 CVE를 "신규 발견"으로서 보내는 것은 중복 노이즈이며, 규율 위반이다. dismissed로서 솔직하게 기록했다.

6. 교훈——bug count가 아닌 judgment

두 가지를 동시에 말할 수 있다. 첫째, 이 방법론은 실제 CVE 급의 권한 부여 버그(authorization bug)를 이론이 예측한 비자명한 측면(집계·관계 전개)에서 블랙박스(black-box) 방식으로 재발견할 수 있었다. 3번의 "전면(front)" 사이클에서는 아무것도 나오지 않았으나, 1번의 "재조준(re-aiming)" 사이클에서 CVE 급이 2건 발견되었다. 조준(judgment)이 효과를 발휘한 것이다. 둘째, 그리고 이것이 정말 중요한 것인데——"재현했다 ≠ 신규"임을 스스로 간파하고, 과도한 주장을 멈춘 규율이다. AI 지원 리서치(AI-assisted research)가 신뢰할 만한 이유는 화려함 때문이 아니라, 외치기 전에 확인하기 때문이다.

7. 공개하지 않는 것 (명시)

exploit(익스플로잇)도 PoC(Proof of Concept)도 게재하지 않는다. 대상이 되는 운영 환경에는 접촉하지 않았다(자체 호스트의 합성 연구실(synthetic lab) 내에서만 수행). 공개하는 것은 방법론과 이미 공개된 CVE 번호뿐이다. 수정되지 않았거나 공개되지 않은 취약성은 이 글에 일절 포함되지 않는다.

화려한 발견의 이야기는 어디에나 있다. 드문 것은 "찾은 것 같은 것을 확인하고, 버리는" 이야기다. 자동화가 강력해질수록, 이 규율의 가치는 올라간다.

Discussion