
원문: arXiv:2610.00977v1 · PDF
저자: Duarte, André V., Oke, Aditya, Melo, Rui, Gandhi, Shubham, Kotalwar, Nachiket, Khandor, Charmi, Wang, Danqing, Oliveira, Arlindo L., Rosé, Carolyn, Li, Lei
발표: 2026-10-01 · 분석 대상: v1 · 공개 자료 확인: 2026-10-03
Tags: 접근제어, 인가취약점, 소스코드감사, 웹보안, IDOR, 보안불변조건, 언어모델, 정적분석, BACBench, ABSENTIA
본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.
한눈에 보기
ABSENTIA는 웹 애플리케이션의 소스 코드를 읽고, 각 요청 경로에 필요한 접근 권한과 실제 검사 코드를 대조하는 언어모델 기반 감사 방법입니다. 핵심은 위험한 함수 하나를 찾는 데서 멈추지 않고, “이 사용자가 이 객체에 이 작업을 해도 되는가”라는 애플리케이션별 보안 불변조건을 먼저 세우는 데 있습니다.
공개된 접근제어 취약점 30건에서 취약 버전의 문제를 19건 발견했고, 수정 버전에서는 같은 문제를 더 이상 보고하지 않는 조건까지 충족한 것은 17건이었습니다. 이 수치는 새로운 취약점 19건을 발견했다는 뜻이 아니며, 현재 공개 저장소에는 벤치마크 데이터만 있고 분석 도구 구현은 공개 예정입니다.
연구 배경
로그인 검사는 있어도 객체 소유권, 조직 경계, 역할, 공유 범위와 작업 종류에 대한 검사가 빠질 수 있습니다. 이러한 정책은 함수 이름이나 위험한 데이터 흐름만으로 결정하기 어렵고, 여러 파일의 라우팅·미들웨어·서비스 로직에 나뉘어 있습니다.
기존 패턴 중심 정적 분석이 이 문제를 잘 잡지 못하는 이유를 애플리케이션별 정책의 부재에서 찾습니다. 연구는 언어모델이 코드의 의미를 추론하는 능력을 활용하되, 경로 추출·정책 수립·반례 검토·보고 단계를 분리해 감사를 체계화합니다.
공격 모델 / 전제 조건
분석자는 전체 저장소를 읽을 수 있는 유지보수자 또는 승인된 감사자입니다. 시스템은 애플리케이션을 실행하거나 실제 서버에 요청을 보내지 않으며, 사용자 자격 증명도 필요하지 않습니다.
점검 대상의 위협 모델은 주로 낮은 권한의 인증된 사용자가 다른 사용자의 객체나 더 높은 권한의 작업에 접근하는 상황입니다. 인증 체계 자체의 탈취, 네트워크 중간자, 운영체제 침해를 실험한 것은 아니며, 해당 경로의 정책과 입력에서 사용자가 실제로 통제할 수 있는 부분을 코드로 판단합니다.
핵심 Root Cause
깨지는 불변조건은 “인증된 주체의 권한을 요청한 객체와 작업 종류에 함께 묶어 검증해야 한다”는 것입니다. 객체가 공유되어 있다는 사실, 특정 역할의 존재, 요청을 처리하는 함수에 도달했다는 사실만으로 현재 요청자의 권한이 성립하지 않습니다.
정책 선언과 실제 강제 지점이 분산되거나, 경로 일부가 공통 검사에서 빠지거나, 조회한 객체와 검사한 객체의 식별자가 다르면 인증을 통과한 요청에도 인가 공백이 남습니다. ABSENTIA는 이런 관계를 경로별 불변조건으로 표현하고 그 조건이 모든 관련 흐름에 적용되는지 검토합니다.
핵심 공격 원리
논문이 다루는 취약점의 공통 구조는 서버가 사용자 입력으로 고른 객체를 처리하면서, 그 객체에 대한 해당 주체의 작업 권한을 충분히 확인하지 않는 것입니다. 보호해야 할 대상과 권한 검사의 대상이 어긋나거나, 읽기 권한이 수정·삭제 권한으로 확대 해석되는 경우도 포함합니다.
탐지 방법은 정책을 추론하는 단계와 정책 위반을 입증하려는 단계를 분리합니다. 보고서가 만들어졌다는 사실만으로 공격 가능성이 확정되는 것은 아니며, 실제 입력 통제 가능성과 배포 정책은 사람이 확인해야 합니다.
공격 흐름
감사 흐름은 애플리케이션 구조 파악, 요청 경로 수집, 경로와 구현의 연결, 기대 권한 조건 도출, 강제 로직 검토, 후보 보고 순서입니다. 경로 수집에는 온도가 다른 두 에이전트의 결과를 합쳐 누락을 줄이고, 이후 경로별 분석을 병렬로 수행합니다.
후보 검토자는 추론된 불변조건이 코드에서 유지되는지 확인하고, 다른 검사나 호출 조건이 해당 의심을 반박하는지도 살핍니다. 추가 합성 단계는 공유 파일에 나온 후보들의 연결 가능성을 검토하며, 변경되지 않은 의존 코드 묶음의 판정은 재사용합니다.
성공 조건 / 실패 조건
탐지 성공에는 실제 취약 경로의 수집, 올바른 애플리케이션 정책 추론, 관련 호출과 객체 관계의 이해가 모두 필요합니다. 취약 커밋에서 해당 공지를 찾고 수정 커밋에서 그 공지를 지우는 paired 조건은 단순 탐지보다 강한 검증입니다.
경로가 누락되거나, 정책을 잘못 추론하거나, 검사 함수의 효과를 오해하면 실패합니다. 취약 경로는 30건 중 27건에서 수집했지만 최종 탐지는 19건이었으므로, 경로 수집만으로 탐지가 완성되지 않습니다.
연구진의 실험 환경
BAC-Bench는 공개 보안 공지 30건, 애플리케이션 25개, 프레임워크 9개로 구성됩니다. 언어별 사례는 Python 18건, TypeScript 9건, JavaScript 3건이며, CWE-639가 15건, CWE-862가 10건, 나머지가 5건입니다.
주요 모델은 MiniMax-M2.5이며 Strands Agents와 AWS Bedrock을 사용하는 소스 코드 감사 환경에서 평가했습니다. 저장소 크기는 중앙값 약 15만 1천 줄, 범위 약 1만 2천-120만 줄이고, 요청 경로 수는 중앙값 220개, 범위 17-999개입니다.
재현성 평가는 경로가 100개 미만인 8개 저장소에서 각각 5회 수행했습니다. 나머지 큰 저장소 22개는 1회 평가이므로 전체 30건의 결과를 반복 실험 평균으로 읽으면 안 됩니다.
주요 실험 결과
| 평가 | 결과 | 해석 범위 |
|---|---|---|
| 취약 커밋 탐지 | 19/30건 | 지정된 공개 공지의 결함을 찾은 횟수 |
| 수정 커밋까지 대조 | 17/30건 | 2건은 수정 후에도 같은 문제를 보고 |
| 같은 모델의 비구조화 에이전트 | 3/30건 | 비교 설정에서의 탐지 |
| CodeQL·Semgrep | 각각 0/30건 | 사용한 일반 규칙·구성의 결과 |
| 합성 등 일부 단계 제거 | 18/30건 | 전체 구성보다 1건 감소 |
| 소규모 반복 평가 | pass@1 0.68, pass@5 0.75, pass^5 0.50 | 8개 저장소 × 5회, 총 40회 |
전체 구성은 보고서 77개, 일부 단계 제거 구성은 119개를 만들었고 모델 판정의 정밀도는 각각 50.8%, 40.5%였습니다. 그러나 각 저장소·구성에서 최대 20개 보고서만 표본 검토했으며, 별도의 사람 검토에서는 이 정밀도 개선이 재확인되지 않았습니다.
정밀도 관련 사람 검토는 보고서 100개에서 인가 문제 여부에 85%의 일치와 κ=0.70을 보였습니다. 알려진 공지 탐지 판정에 대한 사람과 모델의 일치는 85개 중 81개, κ=0.91이므로 두 검증의 강도를 구분해야 합니다.
일반 취약점 범주를 포함한 OWASP Python 평가 677건에서는 참양성률 0.85, 거짓양성률 0.42였고, Java 평가 1,572건에서는 각각 1.00, 0.62였습니다. 이 별도 평가의 높은 거짓양성률은 BAC-Bench에서의 인가 탐지 결과를 모든 취약점 종류로 확대할 근거가 없음을 보여줍니다.
평가 시점의 분석 비용은 저장소당 중앙값 44달러, 범위 2-316달러였습니다. 변경 전후 분석에서 코드 묶음 재사용 비율 중앙값은 37%였으나 저장소 8개는 재사용이 전혀 없었으며, 이 비용을 현재 요금이나 모든 지속적 통합 환경의 비용으로 일반화할 수 없습니다.
실제 발견된 취약점 / 사례
실험은 이미 공개된 GitHub 보안 공지와 취약·수정 커밋을 사용했습니다. 예를 들어 Open WebUI 공지 GHSA-26g9-27vm-x3q8는 공유 채팅을 통한 파일 접근에서 현재 요청자의 공유 범위와 작업 종류를 충분히 묶어 검사하지 않는 문제입니다.
여기서 중요한 검토점은 공유 객체의 존재와 현재 사용자에게 허용된 접근이 서로 다른 조건이라는 것입니다. 공식 공지는 CVE-2026-45671, 영향 버전 0.8.12 이하, 수정 버전 0.9.0 이상과 시험 버전 0.8.3을 명시하며, 공유 상태가 전제인 통제된 사례입니다. 논문은 후보 보고서의 추가 문제 가능성을 논의하지만, 신규 제로데이 발견과 책임 있는 공개 절차를 완료한 결과로 제시하지 않습니다.
기존 공격 / 기존 점검 방식과의 차이
공통 위험 함수나 데이터 흐름에 고정된 규칙 대신 애플리케이션별 인가 조건을 경로 단위로 도출합니다. 비구조화 에이전트와 비교하면 요청 표면을 체계적으로 수집하고, 정책 추론과 반박 검토에 명시적인 역할을 부여한다는 차이가 있습니다.
CodeQL과 Semgrep의 0/30 결과는 해당 평가 설정에서 이 공지들을 잡지 못했다는 뜻입니다. 애플리케이션 정책을 구현한 맞춤 규칙이나 다른 구성까지 모두 불가능하다고 입증한 결과는 아닙니다.
공개 PoC / Exploit / Tool / Artifact 분석
2026-10-03에 확인한 저자 공식 저장소는 README와 BAC-Bench 데이터를 공개합니다. 자료는 공지, 대상 저장소, 취약·수정 커밋, 영향 경로, 기대 불변조건과 일치 판정 기준을 연결하며 애플리케이션 원본 코드는 각 upstream에 남겨 둡니다.
현재 자료는 인가 감사 평가 집합을 검토하는 데 사용할 수 있습니다. 실행 가능한 ABSENTIA 구현과 전체 재현 지침은 아직 없고, 저장소는 구현을 2026년 말까지 공개할 계획이라고 밝히므로 현재 공개 도구로 논문 결과를 그대로 재현할 수 있다고 표현하면 안 됩니다.
데이터가 연결한 공지 30개 중 29개는 실행 시점에 원래 URL의 접근을 확인했습니다. Askbot의 GHSA-r2jv-fwfr-4j8c 공지는 HTTP 404였으므로 해당 공지의 현재 공개 내용은 검증하지 못했습니다.
비판적 검토 및 연구의 한계
가장 먼저 구분할 것은 알려진 문제의 탐지율과 미지의 문제에 대한 정밀도입니다. 저자도 BAC-Bench가 알려진 양성 사례 중심임을 설명하며, 다른 보고서의 진위를 포괄적으로 라벨링한 집합이 아니므로 19/30만으로 실제 조직에서의 경보 품질을 평가할 수 없습니다. 독립적인 신규 저장소 감사와 사람에 의한 전체 후보 판정이 필요합니다.
정밀도 개선 주장은 모델 평가와 사람 평가 사이에 불확실성이 남습니다. 보고서 수가 119개에서 77개로 줄었다는 사실은 분명하지만, 사람 검토가 개선을 확인하지 못했으므로 “잘못된 보고가 확실히 줄었다”는 결론은 제한해야 합니다.
모델 기억과 데이터 누출의 배제도 완전하지 않습니다. 저자는 모델 계열의 학습 시점과 공지 발표 시점을 비교하지만 해당 모델 버전의 실제 학습 범위를 입증하지는 않으며, 학습에 포함되지 않은 사례나 비공개 검증 집합으로 보완할 수 있습니다.
합성 단계의 다단계 문제 검증은 별도 쟁점입니다. 후보 쌍 42개에서 일부가 확인됐으나 벤치마크 공지 30건에는 연결된 취약점이 필수인 사례가 없어, 복합 공격 탐지 능력을 독립적으로 측정했다고 볼 수 없습니다.
반복 평가가 작은 저장소 8개에 한정되고 큰 저장소는 한 번씩 실행됐습니다. 분석자의 추가 판단으로는 경로 규모, 정책 복잡도, 프레임워크별 편차와 운영 설정의 영향을 반복 실험으로 확인해야 실무 비용과 안정성을 예측할 수 있습니다. 공개 구현이 없는 현재 상태에서는 이 보완을 외부 연구자가 수행하기도 어렵습니다.
레드팀 / 모의해킹에서 어떻게 활용할까
승인된 소스 코드 감사에서 요청 경로, 주체, 객체, 작업 권한의 관계를 정리하는 분석 틀로 활용할 수 있습니다. 보고된 인가 공백을 평가할 때에는 사용자가 입력과 상태를 통제할 수 있는지, 공통 미들웨어가 이미 차단하는지, 조직·공유 정책이 무엇인지를 우선 확인합니다.
검증은 소유한 시험 데이터와 격리 환경에서 정책 허용·거부 결과를 대조하는 수준으로 제한합니다. 실제 사용자 데이터 접근이 필요하거나 정책 소유자가 확인되지 않은 경우에는 검증을 중단하고 코드 및 로그 기반 검토로 전환합니다.
실무 가치 평가
웹 서비스의 객체 권한 감사, 공통 미들웨어 적용 범위 검토, 수정 전후 인가 회귀 검토에 도움이 됩니다. 현재는 공개 벤치마크와 감사 설계가 실무 자산이며, 실행 도구를 즉시 도입할 수 있는 상태는 아닙니다.
결론
ABSENTIA는 접근제어를 경로별 보안 불변조건으로 풀어 소스 코드의 검사 관계와 대조한다는 점에서 유용한 연구입니다. 알려진 인가 결함 탐지 성과는 분명하지만, 신규 문제의 정밀도와 반복 실행 안정성, 공개 구현을 통한 재현 가능성은 별도로 평가해야 합니다.
댓글