소프트웨어 품질의 시대인가, 타조의 시대인가?

• 작은 실수가 사용자에게 심각한 결과를 초래할 수 있고, 흔한 GLib 프로그래밍 오류도 반복됨
• GUADEC 2024년과 2025년 발표 당시에는 인간의 실패를 피하기 어렵고 AI가 더 잘하리라고도 기대하기 어려웠지만, 이후 AI의 취약점 탐지 능력이 크게 향상됨

• GLib과 fwupd에서 발견된 대규모 결함은 AI 취약점 스캔 없이 품질을 유지하기 어렵다는 판단의 근거임
• Linux 사용자가 공격 대상으로 삼을 만큼 늘어난 가운데, AI는 실제로 작동하는 익스플로잇 제작도 이전보다 쉽게 만듦

• GNOME 코드는 과거보다 전반적으로 좋아졌지만 개선 여지가 크며, AI는 이전에는 현실적으로 불가능했던 수준의 품질 향상 기회를 열어줌

• Daniel Stenberg도 curl에서 같은 변화를 확인함

• 지나치게 장황하고 불필요하게 상세하며, 심각도를 과장하거나 오해를 부르는 무관한 내용을 넣기도 함
• 틀린 보고서도 있고, 가짜 스택 추적처럼 데이터를 조작하는 사례도 일반적이지는 않지만 드물지도 않음
• 숙련된 인간 검토자는 제출 전에 대부분을 바로잡을 수 있지만, 경험이 부족한 제보자는 내용을 이해하지 못한 채 그대로 복사해 제출하기도 함

• 위 문제를 모두 피한 좋은 보고서는 드물며, 수정용 병합 요청까지 제출하는 경우도 드묾
• 병합 요청이 있더라도 검토 자체가 이미 과중한 업무를 맡은 유지보수자에게 추가 부담임

• 4개월 전 요청과 같이 AI 생성 취약점 보고서를 허용하도록 정책을 수정해야 함
• 계속 금지하는 프로젝트는 GNOME의 의존성으로 적합하지 않으며, GNOME GitLab 밖에서 개발해야 함

• 취약점 제보는 의무가 아닌 공익적 활동이므로, 추가 작업을 요구하면 제보자가 다른 프로젝트로 떠나거나 다른 곳에 취약점을 공개할 가능성이 더 큼
• 실제 스캔 결과와 비슷한 규모인 보안 버그 100개를 발견했다면, 검증과 상위 프로젝트 제출, 수정안 작성만으로도 상당한 작업이 됨
• 보고서를 전부 다시 쓰는 데 수개월을 쓰도록 요구하면 나머지 작업을 합친 것보다 부담이 커질 수 있음
• 버그가 적어도 전면 재작성보다는 다른 작업을 우선할 수 있으며, 간단한 요약만으로는 전체 보고서만큼 유용한 정보를 전달하기 어려움

• 유지보수자가 보안 추적 대상 이슈를 더 잘 표시하게 된 영향도 있지만, 증가의 주된 원인은 AI임

• 따라서 일부 CVE-2026 이슈는 2025년에 포함됨
• 2026년에 보고됐지만 아직 CVE가 없는 취약점은 제외되어, 데이터는 대략 9월 1일까지의 상황을 반영함
• 이전 연도와 비교하려면 2026년 수치에 4/3을 곱해야 하며, GNOME Security에 보고된 이슈만 집계함

• 기존 CVE는 추적 담당자가 직접 요청해 발급받았으므로, 앞으로 발급 수가 크게 줄어들 것으로 예상됨

• 두 라이브러리는 시스템 라이브러리로 설치하도록 설계되지 않아 WebKit이 번들로 포함하며, 이들의 취약점도 WebKit 자체 코드의 취약점과 동일하게 계산해야 함
• 이를 제외한 2026년 WebKitGTK CVE는 현재까지 21개로 크게 감소했지만, 번들 코드의 CVE를 제외하는 것은 공정하지 않음

• Apple은 대체로 외부 연구자가 찾은 결함에 CVE를 발급하고, WebKit 개발자가 발견한 결함에는 자주 발급하지 않음
• 따라서 WebKit 취약점 중 일부만 CVE를 받음

• 정확한 개시 시점은 불확실하지만, 첫 취약점 보고일인 2024년 6월 27일 직전에 시작한 것으로 추정됨
• 첫 버그 바운티였기 때문에 GLib, glib-networking, libsoup만 대상으로 삼아 작게 시작함
• GNOME 전체로 확대하려 했지만 GLib과 libsoup 보고서가 폭증하면서 실현하지 못함

• 2026년 보고량은 두 달도 안 되는 기간에 쌓인 규모임
• 종료 후에도 적체가 남아 9월에야 2월 접수분의 마지막 수락 처리를 마쳤고, 마지막 보상은 10월 2일 지급됨
• YesWeHack의 전문 분류 담당자가 먼저 분석했어도 후속 검토 부담이 컸음

• 취약점은 libsoup 45개, GLib 23개, glib-networking 3개였음
• 보상액은 500유로 16건부터 7,500유로 2건까지였고, 산술평균 지급액은 2,662.99유로였음
• 수락하지 않은 보고서는 모두 거절 처리함

• 중복으로 닫은 30건을 제외해도 197건이 거절됐으며, 접수 대비 수락 비율이 낮았음
• 금전적 유인이 있으면 품질이 낮은 보고서도 제출되며, 수락된 보고서 중에도 품질이 좋지 않은 것이 많았음
• 수락된 보고서뿐 아니라 거절된 보고서 중에서도 실제 보안 문제를 찾은 경우가 많았지만, 여러 차례 수정과 정정이 필요했음

• 금전적 보상을 기대하지 않는 AI 보고서는 대체로 훨씬 좋음
• 나쁜 보고서도 간혹 들어오지만 빈도와 수량이 많지 않아 더는 큰 문제가 아님

• 보고량을 줄이고 GNOME 사용자의 실제 위험을 반영하려고 서비스 거부 버그를 먼저 제외함
• 이후 요청 스머글링 취약점이 너무 많아 SoupServer도 제외함
• 이 HTTP 요청 파싱 버그들은 GNOME 사용자에게 위협이 되지 않지만, 범위를 줄여도 libsoup 보고서는 계속 들어옴
• libsoup은 이전보다 훨씬 안전해졌고, 일반 이슈 추적기를 통한 AI 보고가 이어져 보상 종료 후에도 개선이 계속될 수 있음

• GLib 보고서는 보통 개념 증명 프로그램이 유효하지만 드물게 쓰이는 값으로 API를 호출해 문제를 일으키는 가상적 상황을 다루므로, 심각도를 평가하기 더 어려움

• 많은 소프트웨어 프로젝트에도 이런 문제가 있을 가능성이 있으며, 컴파일러 옵션 조정으로 상당수를 잡을 수 있을 것으로 기대함
• -Wconversion 또는 -Wint-conversion, 그리고 -Wsign-compare가 도움이 될 수 있음
• 일부 GNOME 프로젝트는 -Wsign-compare를 쓰지만 대다수는 쓰지 않는 것으로 추정하며, 앞의 두 옵션을 쓰는 프로젝트는 거의 없을 것으로 봄

• 정기적으로 자체 AI 스캔을 수행하는 프로젝트만 대상으로 제한해야 함
• 모든 취약점이 아니라 실제 작동하는 익스플로잇에만 보상하는 방안도 유력함
• 현재 GNOME 코드 품질로는 모든 취약점에 계속 비용을 지급하기 어렵고, AI 스캐너로 찾을 수 있는 문제에 보상금을 지급하는 것도 더는 타당하지 않음

• GLib이 전체 발견 사항의 40% 이상을 차지해 예상보다 큰 비중을 보임
• 이유는 확실하지 않지만, 공개 API가 많고 API 입력을 잠재적으로 신뢰할 수 없어 공격 표면이 넓기 때문일 수 있음

• 스캔 실행 방식 때문에 불필요한 중복이 생겼고 아직 완전히 제거하지 못함
• 46개는 gobject-introspection의 버그로, 대부분 typelib 지원과 관련됨

• 악성 typelib은 구현 버그가 없어도 취약한 동작을 유도할 수 있음
• 따라서 유지보수자들은 해당 46개를 수정할 가치가 있는 실제 버그이지만 보안 취약점은 아닌 오탐으로 판단함
• 이 단일 오해만으로 약 40%의 오탐률이 발생함

• 오탐도 대부분 같은 신뢰 경계 오해에서 비롯됐으며, 비보안 버그 보고서로서 가치가 있음
• 나머지 발견 사항에는 앞으로 다수의 CVE가 부여될 것으로 예상함

• 여러 GNOME 프로젝트에서 많은 문제를 찾았으며, 범위에 Flatpak과 xdg-desktop-portal도 포함됨
• 특히 파일 열기와 관련된 문제와 Yelp를 통한 Flatpak 샌드박스 탈출 등 중대한 발견이 있었음

• 따라서 AI에만 의존해서는 안 됨

• 글쓰기와 사고를 언어 모델에 맡기는 것이 자신의 대외적 이미지에 도움이 되는지 고려해야 함
• GitLab의 모든 글을 AI로 작성하는 듯한 숙련된 GNOME 개발자 사례도 있지만, 그 방식의 가치는 불분명함

• 초보 개발자는 AI 코드 작성에 신중해야 하며, 일을 대신 맡기기보다 학습을 우선해야 함
• 2026년 AI의 코드 주석 작성 능력은 좋지 않으므로, 불필요한 AI 주석은 삭제하고 꼭 필요한 주석은 자신의 말로 작성해야 함
• AI가 커밋 메시지를 인간보다 잘 쓸 수도 있지만, 제출한 코드에 대한 개발자 자신의 생각을 전달해야 함
• AI 생성 댓글을 이슈 추적기나 병합 요청에 자신의 글인 것처럼 올려서는 안 됨

• 보안 버그도 버그이며, 항상 다른 버그보다 중요한 것은 아님
• 긴급한 경우도 있지만 대체로 평범한 결함이며, 사용자가 직면하는 더 큰 디지털 보안 위협은 피싱과 트로이 목마임
• CVE를 아무리 수정해도 이런 위협까지 막을 수는 없음

• 심각도 판단은 어렵고 처음에는 사소해 보였던 문제가 더 위험한 것으로 드러나기도 함
• 가능한 한 많은 문제를 빨리 수정하는 것이 이상적이며, 특히 객체 수명 문제와 범위 밖 쓰기는 중요함
• AI 기반 익스플로잇 생성이 훨씬 쉬워지면서, 2년 전의 “메모리 안전성 취약점 위협이 줄어든다”는 평가는 더는 유효하지 않음

• 요구하는 것은 보고서 접수 금지 철회이지 모든 문제의 개인적 해결이 아님
• 보고서의 기한은 수정 완료 요구가 아니라 공개 시한이며, 이슈를 무기한 비공개로 유지해서는 안 됨
• 기여 없이 소프트웨어에 의존하는 대형 기술기업을 위해 보안 문제를 해결하는 일은 사실상 무상 노동이며, 자원봉사 시간을 거기에 쓸지는 각자가 결정해야 함

Rust 프로젝트도 AI 취약점 보고서를 허용하고 스캔해야 함

• Rust는 unsafe 블록의 예외를 제외하면 대부분의 메모리 안전성 문제를 없앰
• 비슷한 C, C++, Vala 프로젝트보다 취약점이 약 10분의 1 수준일 것으로 합리적으로 기대할 수 있음
• 그러나 모든 취약점이 메모리 안전성 문제는 아님
• Cargo로 의존성을 내려받으면 공급망 보안 위험이 크게 늘어남
• 악성 코드가 심어진 의존성을 번들로 포함할 위험이 메모리 안전성 확보의 이점보다 클 가능성이 높음
• 이 문제는 모든 프로그래밍 언어 패키지 관리자에 내재하며, 현재 최선의 대응은 이를 사용하지 않는 것임
• GNOME의 Rust 코드는 Cargo에 크게 의존하므로, GNOME 소프트웨어 작성에 Rust를 사용하지 않을 것을 권고함