AI가 curl에 29건을 올렸고 6건이 CVE가 됐습니다 — 오픈AI와 앤스로픽은 0건이었습니다

AI가 curl에 29건을 올렸고 6건이 CVE가 됐습니다 — 오픈AI와 앤스로픽은 0건이었습니다

오픈소스 메인테이너들이 요 몇 년 가장 지겨워한 것이 AI가 자동으로 만들어 보낸 취약점 신고였습니다. 그럴듯한 문장으로 길게 쓰여 있는데 열어 보면 실제 결함이 아닌 것들이었습니다. 사람이 읽고 아니라고 판단하는 시간만 쌓였습니다.

그런데 9월 2일 나온 curl 8.22.0에는 그 반대 방향의 기록이 붙었습니다. 한 회사의 자율 시스템이 curl에 29건을 올렸고, 그중 6건이 정식 CVE 번호를 받았습니다. 판정은 curl 보안팀이 직접 했습니다.

거대한 어두운 정육면체 표면에 가느다란 청록빛 균열 여섯 줄이 나 있는 개념 이미지 — 정식 등록된 여섯 건의 결함을 표현했습니다

29건을 올렸고 6건이 CVE가 됐습니다

AISLE이라는 회사가 자사의 자율 취약점 탐지 시스템을 curl에 돌려 29건의 리포트를 제출했습니다.

그중 6건이 curl 보안팀의 검토를 거쳐 정식 CVE로 등록됐습니다. 나머지는 CVE 기준에 이르지 않은 것으로 정리됐습니다.

비율로 보면 다섯 중 하나가 조금 넘습니다. 자동 생성 리포트치고는 상당히 높은 채택률입니다.

미토스 0, 아일 29

시스템을 돌린 다음 날, 검토가 끝나기도 전에 curl 쪽에서 짧은 대조 문장 하나가 올라왔습니다. 미토스는 0, 아일은 29라는 내용이었습니다.

미토스는 같은 대상에 돌아간 다른 자동 탐지 시스템을 가리킵니다. 그 시스템이 올린 건수가 0이었다는 뜻입니다.

같은 코드베이스에 서로 다른 도구를 돌렸을 때 결과가 이렇게까지 갈릴 수 있다는 점을 보여 주는 대목입니다.

텅 빈 어두운 사각 윤곽 옆에 작은 청록빛 정육면체가 빽빽이 들어찬 사각 윤곽이 놓인 개념 이미지 — 0건과 29건의 대조를 표현했습니다

curl 창시자가 직접 쓴 문장입니다

이 대조를 적은 사람은 curl을 만든 다니엘 스텐베리입니다.

그는 그동안 AI가 만들어 보낸 저품질 취약점 신고에 대해 공개적으로 여러 차례 문제를 제기해 온 인물입니다. 신고를 걸러 내는 데 드는 시간이 개발에 쓸 시간을 잡아먹는다는 이야기였습니다.

그런 입장에 있던 사람이 특정 시스템의 성적을 그대로 적었다는 점이 이번 건에서 눈에 띄는 부분입니다.

여섯 개의 번호가 붙었습니다

채택된 여섯 건에는 각각 CVE 번호가 부여됐습니다. CVE-2026-80229, 80230, 80231, 80255, 82208, 82209입니다.

공개된 설명을 보면 OpenSSL 프로바이더 관련 해제 후 사용 문제, OpenSSL 인증서 고정 우회, 네이티브 인증서 저장소 연결 재사용 문제 등이 포함돼 있습니다.

전부 통신 보안과 인증서 처리에 관련된 영역입니다. curl이 하는 일의 핵심에 가까운 부분입니다.

똑같은 청록빛 정육면체 여섯이 세 개씩 두 줄로 가지런히 놓여 고르게 빛나는 개념 이미지 — 여섯 개의 CVE 번호를 표현했습니다

curl 8.22.0에서 함께 고쳐졌습니다

이 여섯 건은 9월 2일 공개된 curl 8.22.0에서 모두 수정됐습니다.

이 릴리스에는 총 열 개의 CVE가 함께 발행됐습니다. curl과 libcurl에 아홉 개, wcurl에 한 개입니다.

즉 이번 릴리스의 보안 수정 가운데 상당 부분이 한 자율 시스템에서 나온 셈입니다.

보고자로 사람 이름이 올라갔습니다

보안 권고에 기재된 보고자는 AISLE의 스타니슬라프 포르트입니다.

시스템이 찾았지만 제출과 소통은 사람이 했다는 뜻입니다. 자율이라는 말이 사람이 전혀 개입하지 않았다는 의미가 아니라는 점을 보여 줍니다.

릴리스 블로그 글 자체에는 보고 주체에 대한 설명이 따로 실리지 않았고, 자율 시스템으로 찾았다는 내용은 회사 쪽 발표에서 나왔습니다.

거대한 어두운 정육면체 바로 앞에 작은 청록빛 사면체 하나가 놓인 개념 이미지 — 방대한 코드 앞에 선 보고자를 표현했습니다

8월 24일부터 사흘에 걸쳐 올라갔습니다

여섯 건의 신고 날짜는 8월 24일에 세 건, 26일에 두 건, 27일에 한 건입니다.

사흘 안에 몰려 들어왔고, 그로부터 일주일이 채 되지 않아 수정본이 나왔습니다.

발견부터 배포까지의 간격이 짧다는 점은 이런 도구가 실제 운영에 붙었을 때 어떤 속도가 나오는지를 보여 줍니다.

300억 대 기기가 쓰는 코드입니다

curl은 명령줄 도구이면서 동시에 libcurl이라는 라이브러리로 수많은 소프트웨어에 들어가 있습니다.

자동차와 텔레비전과 라우터, 휴대전화와 서버까지 폭넓게 쓰입니다. 흔히 수백억 대 규모의 기기에서 동작한다고 이야기됩니다.

이렇게 널리 퍼진 코드에서는 등급이 낮은 결함이라도 영향 범위가 넓어집니다.

수많은 작은 어두운 육각형이 화면을 빈틈없이 덮고 경계마다 옅은 청록빛이 도는 개념 이미지 — 널리 퍼져 쓰이는 코드의 범위를 표현했습니다

전부 Low 등급입니다

여섯 건의 심각도는 모두 Low로 매겨졌습니다. 긴급 대응이 필요한 수준은 아니라는 뜻입니다.

오늘 당장 서버가 뚫린다는 이야기가 아닙니다. 특정 조건이 맞아야 문제가 되는 종류에 가깝습니다.

이 부분을 빼고 전하면 실제보다 위협적으로 들립니다. 숫자와 함께 등급을 같이 봐야 합니다.

등급이 낮다는 것이 뜻하는 것

다만 낮은 등급이 의미 없는 결함이라는 뜻은 아닙니다. CVE 번호를 받았다는 것은 실재하는 결함으로 인정됐다는 것입니다.

보안 문제는 낮은 등급 여러 개가 겹쳤을 때 경로가 만들어지는 경우가 적지 않습니다.

그리고 이번 건에서 중요한 것은 결함의 무게보다 그것을 찾아낸 방식입니다.

작은 청록빛 정육면체 여섯이 어둠 속에 한 줄로 떠 있는 개념 이미지 — 낮은 등급이지만 여러 건인 상황을 표현했습니다

사람이 검토해서 인정했습니다

29건 가운데 6건만 통과했다는 사실이 오히려 이 결과의 신뢰도를 높입니다. 자동으로 다 받아 준 것이 아니기 때문입니다.

curl 보안팀은 자체 기준으로 각 건을 읽고 CVE를 부여할 만한지 판단했습니다.

AI가 찾았다는 주장과 사람이 확인했다는 사실은 다릅니다. 이번 건은 후자가 붙어 있습니다.

며칠 만에 결론이 났습니다

신고가 들어온 뒤 며칠 안에 검토가 끝나고 CVE 지정까지 이어졌습니다.

오픈소스 프로젝트의 보안 검토가 이 속도로 도는 것은 흔한 일이 아닙니다. 대개 인력이 부족합니다.

리포트의 품질이 좋으면 검토 시간이 줄어든다는 당연한 이야기가 이번에 수치로 드러난 셈입니다.

청록빛 구 하나가 긴 잔상을 남기며 어둠을 가로질러 빠르게 지나가는 개념 이미지 — 며칠 만에 끝난 검토 속도를 표현했습니다

오픈AI와 앤스로픽은 0건이었습니다

AISLE은 자사 블로그에서 오픈AI와 앤스로픽의 모델이 같은 대상에서 CVE급 결함을 찾지 못했다고 밝혔습니다.

비교 조건과 방식은 회사 쪽 설명에 의존하고 있으므로, 이 대조를 그대로 성능 순위로 읽는 것은 조심스럽습니다.

다만 범용 대형 모델을 그냥 돌리는 것과 이 작업에 맞춰 만든 시스템 사이에 차이가 있다는 점은 시사합니다.

같은 대상, 다른 결과

같은 코드에 서로 다른 시스템을 돌렸는데 한쪽은 0건이고 한쪽은 29건이었습니다.

이 차이는 모델의 크기보다 작업 구조에서 나올 가능성이 큽니다. 어디를 어떤 순서로 볼지, 찾은 것을 어떻게 검증할지가 설계에 포함돼 있느냐입니다.

취약점 탐지는 답을 잘 쓰는 일이 아니라 재현되는 결함을 확인하는 일입니다. 그 차이가 결과를 갈랐다고 보는 편이 자연스럽습니다.

똑같은 어두운 정육면체 둘 중 하나만 청록빛 균열로 갈라져 있는 개념 이미지 — 같은 대상에서 갈린 결과를 표현했습니다

이번이 두 번째입니다

AISLE이 curl에서 성과를 낸 것은 이번이 처음이 아닙니다.

앞선 사례가 한 번 더 있었고, 그 결과로 curl 쪽이 이 회사의 시스템을 도입해 쓰게 됐다는 내용이 회사 블로그에 남아 있습니다.

한 번은 우연일 수 있지만 두 번째는 다르게 읽힙니다.

6월에는 18건 중 6건이었습니다

앞선 라운드는 6월에 나온 curl 8.21.0 시점입니다. 그 릴리스에는 18건의 CVE가 실렸고, 그중 6건이 이 회사 몫이었습니다.

이번 8.22.0 건과는 CVE 번호대가 전혀 다른 별개의 사안입니다. 두 사건을 하나로 합쳐 읽으면 숫자가 어긋납니다.

같은 프로젝트에서 두 차례에 걸쳐 각각 6건씩 채택됐다는 것이 정확한 정리입니다.

흐릿한 어두운 청록 정육면체들이 넓은 어둠에 흩어져 있고 그중 하나만 밝게 빛나는 개념 이미지 — 대량의 저품질 신고 속 소수의 유효 건을 표현했습니다

그중 하나는 25년을 넘긴 것이었습니다

6월 라운드에서 나온 것 중 하나는 2001년 3월에 배포된 curl 7.7에서 들어온 결함이었습니다. 25년이 넘은 것입니다.

회사는 이를 지금까지 보고된 curl 취약점 가운데 가장 오래된 것이라고 설명했습니다.

오랫동안 수많은 사람이 읽어 온 코드에도 이런 것이 남아 있다는 사실이, 이런 도구가 주목받는 이유이기도 합니다.

무엇이 달랐나

기존의 AI 취약점 신고가 문제였던 것은 그럴듯한 서술을 만들어 냈기 때문입니다. 읽기에는 그럴듯한데 확인하면 재현되지 않았습니다.

반면 채택되는 리포트는 어디에서 어떤 조건으로 문제가 생기는지가 특정돼 있습니다. 검토자가 그대로 따라가 볼 수 있습니다.

같은 AI라는 이름이 붙어도 결과물의 성격이 이렇게 갈립니다.

가느다란 청록 광선이 큰 어두운 정육면체의 한 지점을 정확히 때려 그 자리가 강하게 빛나는 개념 이미지 — 재현 조건이 특정된 리포트를 표현했습니다

225건, 30여 개 프로젝트

회사는 지금까지 30개가 넘는 널리 쓰이는 오픈소스 프로젝트에서 225건 이상의 취약점을 찾아 책임 있게 공개했다고 밝혔습니다.

OpenSSL과 curl, FreeBSD 등이 대상에 포함돼 있습니다. 인터넷 기반에 해당하는 코드들입니다.

이 수치 역시 회사 발표이므로, 각 건이 어떤 등급으로 인정됐는지는 따로 확인이 필요합니다.

오픈SSL에서는 12건 중 12건이었습니다

회사가 내세우는 사례 가운데 하나는 OpenSSL에서 12건 중 12건을 찾아냈다는 것입니다.

이런 형태의 수치는 대개 정해진 목록을 두고 몇 개를 재현했는지를 재는 평가입니다. 야생에서 새 결함을 찾는 것과는 조건이 다릅니다.

그래도 놓치지 않았다는 사실 자체는 도구의 일관성을 보여 주는 지표가 됩니다.

똑같은 청록빛 고리들이 가지런히 놓여 모두 같은 밝기로 빛나는 개념 이미지 — 열두 건을 모두 찾아낸 결과를 표현했습니다

자율이라는 말의 범위

자율이라는 표현이 붙었지만 사람이 빠진 것은 아닙니다. 제출과 소통은 사람이 했고, 판정은 프로젝트 쪽 사람이 했습니다.

자동화된 것은 코드를 훑고 후보를 만들어 내는 부분입니다. 그 뒤의 검증 절차는 기존과 같습니다.

이 구분을 흐리면 AI가 알아서 보안을 해결한다는 이야기가 되는데, 이번 건이 보여 준 것은 그것이 아닙니다.

실제 사례 — 오픈소스 메인테이너에게 무엇이 바뀌나

소규모 오픈소스 프로젝트를 혼자 유지하는 분을 생각해 보겠습니다. 취약점 신고함에 자동 생성된 글이 쌓이면 그것을 읽는 일이 곧 부담이 됩니다.

실제로 여러 프로젝트가 이 부담 때문에 신고 창구 정책을 바꿨습니다. AI 사용 여부를 밝히게 하거나 아예 받지 않는 곳도 생겼습니다.

이번 건이 그 흐름을 뒤집지는 않습니다. 다만 리포트의 품질이 일정 수준을 넘으면 판단 기준이 도구 종류가 아니라 내용이 된다는 것을 보여 줍니다.

실무적으로는 신고를 받을 때 재현 조건이 적혀 있는지를 먼저 보는 방식이 여전히 가장 효율적입니다.

거대한 어두운 정육면체가 화면 위쪽 높이 떠 있고 아주 작은 청록빛 구가 저 아래에 놓여 사이에 넓은 어둠이 벌어진 개념 이미지 — 메인테이너의 검토 부담이 덜어지는 상황을 표현했습니다

실제 사례 — 내 서버에 있는 curl은 어떻게 하나

집이나 회사 서버에서 curl을 쓰고 계신다면, 이번 건으로 급히 무언가를 해야 하는 상황은 아닙니다. 여섯 건 모두 Low 등급입니다.

다만 8.22.0에는 이 여섯 건 외에도 다른 수정이 함께 들어 있습니다. 평소 업데이트 주기에 맞춰 올려 두시면 됩니다.

직접 설치한 경우가 아니라면 대개 배포판 패키지 관리자를 통해 올라옵니다. 시스템 업데이트를 미뤄 두셨다면 이번 기회에 한 번 돌려 두시는 정도가 적당합니다.

라이브러리로 들어가 있는 경우는 조금 다릅니다. 어떤 프로그램이 libcurl을 쓰고 있는지는 눈에 잘 띄지 않으므로, 소프트웨어 전체를 최신으로 유지하는 편이 안전합니다.

무엇을 경계해야 하나

첫째, 등급을 함께 봅니다. CVE 여섯 건이라는 숫자만 떼어 놓으면 실제보다 심각하게 들립니다.

둘째, 회사 발표와 프로젝트 기록을 구분합니다. 자율 시스템이 찾았다는 서술은 회사 쪽에서, 결함 인정은 프로젝트 쪽에서 나왔습니다.

셋째, 두 라운드를 섞지 않습니다. 25년 된 결함은 6월 건이고 이번 여섯 건과는 별개입니다.

넷째, 같은 AI라는 이름이 붙어도 결과가 크게 갈린다는 점을 전제합니다. 도구 이름이 아니라 재현 가능한 리포트가 기준입니다.

매끈한 어두운 육각형의 한 모서리에만 가느다란 청록 쐐기가 빛나고 나머지는 어둠에 남은 개념 이미지 — 아직 확인되지 않은 영역을 표현했습니다

핵심 정리

AISLE의 자율 취약점 탐지 시스템이 curl에 29건을 신고했고 그중 6건이 CVE로 등록됐습니다. 번호는 CVE-2026-80229, 80230, 80231, 80255, 82208, 82209입니다.

여섯 건 모두 9월 2일 나온 curl 8.22.0에서 수정됐으며 심각도는 전부 Low입니다. 신고는 8월 24일부터 27일 사이에 이뤄졌고 보고자로 회사 소속 인물이 기재됐습니다.

curl 창시자 다니엘 스텐베리는 같은 대상에 돌아간 다른 자동 탐지 시스템의 건수가 0이었다는 대조를 남겼습니다. 회사는 오픈AI와 앤스로픽 모델도 이 대상에서 CVE급 결함을 찾지 못했다고 밝혔습니다.

앞선 6월 curl 8.21.0 라운드에서도 18건 중 6건이 이 회사 몫이었고, 그중 하나는 2001년부터 남아 있던 25년 넘은 결함이었습니다. 이번 건과는 별개 사안입니다.

참고하실 만한 것

보안 뉴스를 보실 때 CVE 건수와 함께 심각도 등급을 같이 확인하시기 바랍니다. 건수만 보면 대부분의 소식이 실제보다 위급하게 들립니다.

그리고 AI가 찾았다는 문장 뒤에 사람이 확인했는가가 붙어 있는지도 함께 보시면 좋겠습니다. 이번 건에서 신뢰를 만든 것은 바로 그 부분이었습니다.

SVIL은 이런 소식을 큰 글자와 쉬운 설명으로 정리해 전해 드리고 있습니다. 저시력 환경에서도 부담 없이 읽히도록 만드는 것이 저희 작업의 기준입니다.

출처


협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://svil.dev/