TL;DR

  • 2026년 한 분기 81건, 다음 분기 92건의 보안 보고가 접수되면서 MariaDB Server의 일부 릴리스가 예상보다 늦어졌으며, 이는 AI 지원 도구를 활용한 보안 연구 증가와 그에 따른 조사·수정 작업 때문임.
  • 접수된 보고 173건이 취약점 173개를 뜻하지는 않으며, 각 보고는 재현과 영향 평가를 거쳐 유효한 문제인지 확인됨.
  • 보고된 문제는 검토·테스트·수정됐으며, 영향을 받는 지원 버전의 유지보수 릴리스에 수정 사항이 포함되고 보안 권고 27건이 공개됨.
  • 커넥터와 서버에서 여러 연구자가 취약점을 찾아 책임 있게 제보했으며, 과거 코드도 새 도구와 시각으로 점검할 가치가 있음.
  • 보안 연구자는 취약점 의심 사례를 공개하기 전에 비공개 보안 채널로 제보하고, 가능한 경우 재현 가능한 테스트 사례를 제공해야 함.

AI도 버그를 찾고 있음

  • AI가 개발자의 코드 작성 방식을 바꾸는 동시에, 보안 연구자가 버그를 찾는 방식도 바꾸고 있음.
  • 최신 AI 지원 도구는 대규모 코드베이스를 분석하고, 코드 경로를 추적하며, 의심스러운 패턴을 찾아 테스트 사례를 생성하고, 이전에는 상당한 수작업이 필요했던 조사를 지원함.
  • MariaDB Server는 수많은 기능·프로토콜·스토리지 엔진·플랫폼과 이들의 이례적인 조합을 다루는 크고 성숙한 프로젝트임.
  • 새로운 도구를 갖춘 연구자들이 이전에는 실용적이지 않았던 방식으로 코드 전반을 살피기 시작했으며, 보고 건수 그래프에 나타난 급증으로 이어짐.

AI가 만든 허위 보고였나?

  • 보고가 급증했을 때는 AI가 존재하지 않는 버그에 대해 설득력 있는 설명과 코드, 스택 추적을 만들어내는 이른바 AI 슬롭에 대한 우려가 있었음.
  • 그러나 접수된 보고는 거의 모두 실제 문제를 담은 양질의 보고였으며, 모든 문제를 수정함.

보고를 조사하고 수정함

  • 엔지니어링 팀은 보고를 검토하고 발견 사항을 재현해 영향을 평가했으며, 필요한 경우 수정 사항을 개발·검토·테스트하고 여러 유지보수 브랜치로 백포트함.
  • 확인된 취약점의 수정 사항은 영향을 받는 지원 대상 Community 및 Enterprise Server 버전의 최신 유지보수 릴리스에 포함됨.
  • CVE 배정 절차가 완료될 때까지 몇 주를 기다리지 않고 확인된 취약점과 수정 사항을 알릴 수 있도록 MariaDB 자체 보안 권고(MariaDB Security Advisories) 발행도 시작함.
  • 작성 시점에 보안 권고 27건이 공개됐으며 수정도 완료됨.
  • 커넥터에는 별도의 보안 권고가 있음: [1][2][3].
  • 2026년에 접수된 전례 없는 수의 보고를 조사하고 수정하는 데 필요한 작업량이 일부 릴리스 지연의 원인임.

보고 증가가 MariaDB 보안 저하를 뜻하지는 않음

  • 그래프가 보여주는 것은 접수된 보고 수이지 확인된 취약점 수가 아님.
  • 일부 보고는 커넥터처럼 서버와 무관한 문제이며, 일부는 수정됐지만 보안 권고나 CVE로 이어지지 않거나 중복 보고임. 이 점이 보고 81건과 보안 권고 27건 사이의 차이를 설명함.
  • 따라서 급증을 MariaDB가 2026년에 갑자기 덜 안전해졌다는 그래프로 해석해서는 안 됨.
  • 극적으로 달라진 것은 MariaDB를 비롯한 여러 오픈소스 프로젝트를 대상으로 수행되는 보안 연구의 양과 연구자들이 이용할 수 있는 도구임.
  • 이전에는 발견하기 어렵거나 시간이 오래 걸렸던 문제와 예외 사례를 이제 훨씬 효율적으로 탐색할 수 있음.
  • 실제 문제를 식별하는 보고는 이를 수정할 기회를 제공하며, 접수된 유효한 보안 문제는 모두 조사하고 수정함.
  • 보안 문제 수정은 코드 몇 줄을 바꾸고 GitHub에 푸시하는 일만으로 끝나지 않음.
  • 문제 재현, 이해, 영향을 받는 버전 확인, 수정, 수정 사항 검토와 테스트가 필요하며, 여러 유지보수 버전으로 백포트하고 보안 권고 작성, 점수 산정, CVE ID 요청을 진행하는 경우도 많음.
  • 보고 몇 건을 처리하는 일은 일반적이지만, 81건에 이어 92건을 처리하는 일은 전혀 다른 규모임.

해커들에게 감사함

  • 그래프에서 가장 많은 보고를 제출한 연구자는 fg0x0이며, 보고 건수는 51건임.
  • fg0x0은 MariaDB Server 자체가 아니라 MariaDB 커넥터에 집중함.
  • 이 작업은 구체적인 수정으로 이어짐. 예를 들어 Connector/Node.js에서 보고된 문제는 PAM 인증과 안전하지 않은 전송을 통한 자격 증명 전송 방지에 관한 것이며, R2DBC를 비롯한 다른 커넥터에서도 비슷한 작업이 이뤄짐.
  • 서버에서는 letchu_pkt가 13건, vortfu가 12건, muhammaddaffa가 10건을 보고했으며, 그 밖에도 여러 연구자가 참여함.
  • vortfu는 Automattic 소속임.
  • 일부 발견 사항은 상당히 중요함. letchu_pkt는 셸 명령에 전달되는 값과 관련된 문제를 포함해 Galera/wsrep 처리의 여러 문제를 보고했으며, 해당 문제는 영향을 받는 유지보수 릴리스에서 수정됨.
  • 그래프 상위에 표시된 연구자뿐 아니라 MariaDB를 살펴보고 의심스러운 점을 발견해 책임 있게 제보한 모든 사람에게 감사함.
  • 이것이 오픈소스 보안이 작동해야 하는 방식임.

오래된 코드에도 새로운 시각이 필요함

  • 개발자는 새 코드를 주의 깊게 살피는 경향이 있음. 새 기능은 검토와 테스트를 거치고, 사람들이 사용해 보며 문제를 찾음.
  • 오래된 코드라고 해서 문제가 없다는 뜻은 아님. 코드가 오래됐다는 사실은 이전까지 아무도 문제를 찾지 못했다는 뜻일 뿐임.
  • AI를 소프트웨어 개발에 활용하는 좋은 방법 중 하나는 새 코드를 더 많이 생성하는 데 그치지 않고 이미 보유한 코드를 다시 살펴보는 것임.
  • 대규모 오픈소스 프로젝트에는 오래된 코드가 많으며, 보안 연구자들이 새로운 도구로 계속 흥미로운 문제를 찾아낼 것으로 예상됨. 이는 긍정적인 일임.

계속 살펴보기

  • 퍼징(fuzzing), 정적 분석(static analysis), AI, 자체 스크립트 또는 새로 만든 도구를 사용하는 보안 연구자는 계속 조사할 수 있음.
  • 보안 문제로 보이는 항목을 발견하면 익스플로잇을 즉시 공개하는 대신 적절한 비공개 보안 채널로 제보해야 함.
  • 가능한 경우 재현 가능한 테스트 사례를 제공해야 하며, 이는 조사에 큰 차이를 만듦.
  • 바쁜 기간에 기여한 연구자와 평소 업무에 갑자기 많은 보안 보고를 더해 처리한 개발자에게 감사를 전함.
  • 릴리스가 예상보다 늦어져 의문을 품었던 사용자에게도 지연의 배경을 알림.
  • MariaDB Server를 즐겁게 사용하기 바람.