무슨 일이 밝혀졌나
2026년 1월 27일, OpenSSL 프로젝트가 보안 권고를 내고 12개 취약점을 고쳤습니다. 12개 모두 AI 보안 기업 AISLE의 자율 분석 시스템이 찾아 보고한 것입니다. OpenSSL 재단 CTO Tomáš Mráz도 "이번 릴리스가 고친 12개 보안 이슈는 모두 AISLE이 알려 준 것"이라고 밝혔습니다.
AISLE은 2025년 8월부터 OpenSSL 분석을 시작했습니다. OpenSSL 권고에 적힌 보고일은 2025년 9월 11일부터 2026년 1월 8일까지입니다. 10개는 CVE-2025, 2개는 CVE-2026 번호를 받았습니다. AISLE은 2025년 가을 릴리스에서 찾은 3개를 더하면 2025년에 배정된 OpenSSL CVE 14개 중 13개, 두 릴리스를 합쳐 15개가 자신들의 발견이라고 밝혔습니다.
Bruce Schneier는 블로그에서 AISLE의 글을 소개하며 "AI 취약점 탐색은 예상보다 빠르게 보안을 바꾸고 있고, 공격과 방어 양쪽이 이 능력을 쓸 것"이라고 평가했습니다.
가장 심각한 CVE-2025-15467은 CMS (Auth)EnvelopedData 파싱 과정의 스택 버퍼 오버플로입니다. AES-GCM 같은 AEAD 암호의 IV 길이를 확인하지 않고 고정 크기 버퍼에 복사합니다. 인증과 태그 검증 전에 넘침이 일어나므로 유효한 키 자료 없이도 건드릴 수 있습니다. OpenSSL은 이를 High로 분류했고, 원격 코드 실행까지 이어질지는 플랫폼과 툴체인의 방어 기법에 달려 있다고 설명했습니다. NVD에는 외부 기관이 매긴 CVSS 3.1 점수 9.8(Critical)과 8.8(High)이 함께 올라 있습니다.
| 항목 | 내용 |
|---|---|
| 공개일 | 2026년 1월 27일 |
| 발견 주체 | AISLE (AI 자율 분석 시스템) |
| 취약점 수 | 12개 (High 1, Moderate 1, Low 10) |
| 최고 심각도 | CVE-2025-15467, OpenSSL 등급 High |
| 보고 기간 | 2025년 9월 ~ 2026년 1월 |
| 수정 버전 | 3.6.1, 3.5.5, 3.4.4, 3.3.6, 3.0.19 |
AISLE은 어떻게 찾았나
AISLE은 사람 검토자와 기존 도구의 한계에서 출발합니다. 사람은 시간과 주의력에 한계가 있고, 전통적인 정적 분석은 정해진 버그 유형은 잘 잡지만 복잡한 논리 오류나 타이밍 문제에는 약하다는 설명입니다. AISLE은 자율 분석이 사람이라면 몇 달 걸릴 코드 경로와 경계 조건을 쉬지 않고 훑을 수 있다고 말합니다.
보고 방식도 달랐습니다. AISLE은 재현 절차, 원인 분석, 패치 제안을 함께 보냈고, 12개 중 5개는 AISLE이 제안한 수정이 그대로 반영됐습니다. CVE와 별개로 6건은 릴리스 전에 잡혀 번호 없이 고쳐졌습니다. AISLE은 발견을 검증하고 견고한 수정을 만드는 데 OpenSSL 메인테이너의 코드 이해가 꼭 필요했다고 덧붙였습니다.
대조적인 사례가 curl입니다. curl 창시자 Daniel Stenberg는 2019년부터 운영한 버그 바운티를 2026년 1월 31일부로 끝냈습니다. AI가 만든 엉터리 제보가 폭증하고 다른 제보의 질까지 떨어져, 이를 가려내는 데 드는 정신적 부담과 시간이 너무 컸다는 이유입니다. 한편 AISLE은 2025년 curl에서도 CVE 5개를 받았다고 밝혔습니다. 같은 AI라도 결과를 검증해서 보내느냐에 따라 메인테이너에게 짐이 되기도, 도움이 되기도 합니다.
27년 된 버그의 의미
AISLE에 따르면 12개 중 3개는 1998~2000년부터 코드에 있던 버그입니다. 그중 하나는 OpenSSL보다 먼저 나온 Eric Young의 SSLeay 구현에서 물려받은 것입니다.
AISLE은 OpenSSL이 수백만 CPU 시간의 퍼징을 거쳤고, Google을 포함한 여러 팀이 20년 넘게 감사해 온 코드라고 강조했습니다. 그런 코드에서도 25년 넘게 남아 있던 버그가 나온 셈입니다.
레거시 코드에 대한 가정을 다시 볼 때입니다. "오래된 코드는 충분히 검증되었다"는 믿음이 위험할 수 있습니다. 코드가 오래될수록 원래 맥락을 아는 사람이 줄고, 새로운 관점에서 검토될 기회도 줄어듭니다.
AI 보안 연구의 미래
AISLE의 성과는 방어 AI의 가능성을 구체적으로 보여 줍니다. AI가 공격에 쓰이는 사례는 이미 많지만, 방어 쪽에서도 메인테이너가 받아들이는 수준의 결과가 나오고 있습니다. AISLE은 현재 OpenSSL과 curl의 풀 리퀘스트에 분석기를 붙여 새 코드를 리뷰 단계에서 검사하고 있습니다.
소프트웨어 개발자에게
- 레거시 코드 감사: 오래된 코드일수록 AI 도구를 활용한 재검토가 필요합니다. "잘 작동하니까 괜찮다"는 가정을 버려야 합니다
- CI/CD 통합: 정적 분석 도구와 AI 코드 리뷰를 개발 파이프라인에 넣으면 배포 전에 취약점을 잡을 수 있습니다. AISLE의 6건처럼 릴리스 전에 막는 것이 가장 싸게 먹힙니다
- 메모리 안전성 검토: 이번 12개 중 9개가 버퍼 오버플로, 범위 밖 쓰기, 잘못된 포인터·NULL 역참조 같은 메모리 문제입니다. C/C++ 코드베이스라면 Rust 같은 메모리 안전 언어로의 점진적 전환도 검토할 만합니다
보안 관리자에게
- OpenSSL 업데이트: 3.6.1, 3.5.5, 3.4.4, 3.3.6, 3.0.19로 올립니다. 1.1.1과 1.0.2는 프리미엄 지원 고객용 1.1.1ze·1.0.2zn이 나왔습니다. 신뢰할 수 없는 CMS·PKCS#7(S/MIME 등) 메시지를 파싱하는 서비스는 CVE-2025-15467 때문에 우선 대상입니다
- 의존성 감사 확대: 직접 사용하는 라이브러리뿐 아니라, 의존성 체인 깊숙이 포함된 레거시 라이브러리도 점검 대상입니다
- AI 보안 도구 파일럿: curl 버그 바운티 사례에서 보듯 검증되지 않은 AI 결과는 오히려 짐이 됩니다. 실제 코드베이스로 파일럿 테스트를 거쳐 오탐이 적은 도구를 고릅니다
일반 사용자에게
- 소프트웨어 자동 업데이트를 켜 두세요: OpenSSL은 서버, VPN, 운영체제 패키지 등 수많은 소프트웨어에 들어 있습니다. 배포판·앱 업데이트가 가장 확실한 보호입니다
- HTTPS 연결 확인: 민감한 정보를 입력할 때 브라우저 주소창의 자물쇠 아이콘을 확인하는 습관을 유지하세요
참고 자료