
AISLE은 2026년 10월 14일 공개된 curl 8.23.0에서 수정된 보안 취약점 24건 가운데 18건을 발견했다고 밝혔다. 프라하의 AI 보안 연구팀은 지난 1년 동안 100개가 넘는 코드베이스에서 CVE가 부여된 미공개 취약점 500건 이상을 찾아냈으며, 회사는 다음 목표를 취약점이 제품에 출시되기 전에 찾아 수정하는 일이라고 설명했다.
AISLE은 curl에서 2025년 말 처음 작업해 CVE 5건과 기여가 인정된 풀 리퀘스트 24건을 만들었다. 2026년 2월에는 curl이 AISLE의 AI를 코드 검토에 활용하기 시작했다. 6월에는 curl 8.21.0에서 수정된 CVE 18건 중 6건을 발견했고, 8월에는 AISLE이 추가로 찾은 취약점 가운데 6건이 curl 8.22.0에 반영됐다. 이번 8.23.0에서는 추가 발견 18건이 공개됐다.
AISLE은 curl 창립자이자 수석 개발자인 다니엘 스텐버그(Daniel Stenberg)가 이번 작업을 curl의 다섯 번째 공식 외부 보안 감사로 소개했다고 전했다. 스텐버그는 AISLE의 상세한 발견과 인력 검토가 취약점을 더 빠르게 확인하고 수정하는 데 도움이 됐다고 밝혔다.
회사는 CVE 건수만으로 보안 연구를 완전히 평가할 수는 없지만, 실제 프로젝트 유지관리자가 보고를 검토하고 취약점을 재현·수정한 뒤 CVE 부여 여부를 결정한다는 점에서 외부 검증의 근거가 된다고 주장한다. UC Berkeley Vulnerability Initiative의 공개 집계에서는 AISLE이 AI가 발견한 취약점 관련 8개 지표 중 5개에서 1위 또는 공동 1위에 올랐다. 다만 치명적 취약점 건수에서는 Anthropic이 앞섰고, 평균 심각도와 추정 악용 가능성에서는 다른 팀이 선두라고 AISLE은 덧붙였다. 이 집계는 2026년 10월 12일 기준이다.
AISLE은 OpenSSL에서 2025년 9월부터 2026년 4월 사이 공개된 제로데이 23건 중 20건을 찾아냈고, 이 가운데 10건에 대해 수정이 받아들여졌다고 밝혔다. FreeBSD에서는 Anthropic과 Mythos가 소개한 취약점이 포함된 공개 비교 기간에 양측이 각각 3건씩 발견했다. AISLE은 이 사례가 통제된 실험이나 어느 시스템이 보편적으로 더 뛰어나다는 증거는 아니며, 같은 보안 강화 코드베이스에서 독립적으로 확인된 취약점을 반복해서 찾았다는 점을 보여준다고 설명했다.
다른 사례로 AISLE은 NASA의 CryptoLib에서 우주선과 지상국 간 통신을 보호하는 소프트웨어의 명령 삽입 취약점을 발견했다. 유지관리자는 4일 안에 이를 수정했다. 의료 소프트웨어 OpenEMR에서는 CVE 38건을 찾았으며, 이 가운데 두 건은 CVSS 10.0이었다고 회사는 밝혔다. AISLE은 Cursor, VS Code, Google Antigravity에 걸친 원클릭 원격 코드 실행 취약점도 발견해 악용 과정을 시연했고, 세 업체가 모두 수정했다고 전했다.
AISLE은 성과가 특정 모델 하나의 우위보다 시스템 구성에 달렸다고 주장한다. 모델의 추론 능력 외에도 코드베이스 범위, 병렬 탐색, 모델 선택, 오탐 필터링, 재현과 수정, 유지관리자의 피드백이 결과에 영향을 준다는 설명이다. 회사가 공개한 nano-analyzer는 단일 Python 파일로 만든 저장소 스캐너로, 약 3만5000개 파일과 750만 줄 규모의 FreeBSD 커널에서 유지관리자가 확인한 새 버그를 찾아냈다고 한다. AISLE은 소형 모델이 모든 사이버 보안 작업에서 Mythos나 Astra와 동등하다고 주장하지 않으며, 자율적인 악용 코드 작성은 최첨단 모델에 더 크게 의존할 수 있다고 선을 그었다.
회사는 취약점 발견이 늘면서 유지관리자의 검증·수정 역량이 병목이 되고 있다고 지적했다. curl의 스텐버그는 2026년 5월 당시 보안 보고를 확인하고 패치와 공지를 작성하는 데 업무 시간 대부분을 쓴다고 밝혔다. AISLE은 오탐이 방어자의 시간을 낭비하면 도구에 대한 신뢰가 떨어질 수 있다며, 발견 결과를 선별하고 수정까지 연결해야 한다고 강조했다. 회사는 제품 배포 사례에서 Productboard의 경보 잡음을 99.9% 줄였다고 주장했다.
AISLE은 OpenSSL의 코드 검토 과정에서 제안된 변경의 잠재적 보안 문제 네 건을 지적하고 수정안을 제시했으며, OpenSSL 팀은 3일 뒤 수정했다고 밝혔다. 취약 코드가 출시 전에 막혀 CVE가 필요하지 않았다는 설명이다. AISLE은 다음 목표를 CVE 1000건 달성이 아니라 개발 단계에서 취약점을 찾아 고쳐 취약한 코드가 사용자에게 배포되지 않도록 하는 것으로 제시했다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요