Hacker News 의견들 거의 모든 버그 수정에 CVE를 부여하므로 숫자가 커진다는 점을 감안해야 함. 커널 문서에서도 “Linux 커널이 시스템에서 차지하는 계층 특성상 거의 모든 버그가 커널 보안을 침해하는 데 악용될 수 있어, CVE 부여 팀은 매우 보수적으로 접근하며 식별한 모든 버그 수정에 CVE 번호를 부여한다”고 밝히고 있음. https://docs.kernel.org/process/cve.html 특히 커널에서는 CVE 개수 자체는 쓸모없는 지표임. 모든 버그는 어떤 기능이 의도대로 작동하지 못하게 하므로, 논리를 따라가면 모든 버그에 CVE를 부여할 수 있음. 이를 서비스 거부로 보면 CVSS를 사용하는 CVE 체계상 모든 버그가 최소한 CVSS v4.0의 1점/낮음 등급 취약점이 됨. 더 억지를 부리면 계획만 하고 아직 구현하지 않은 기능도 사용을 막고 있으니 같은 등급의 취약점으로 볼 수 있음. 보안 연구자가 이력서에 넣을 실적을 쌓기 이보다 쉬운 때도 없을 듯함! 투명성을 위해 모든 버그 수정에 CVE를 부여한다는 점은 흥미롭지만, 숫자가 너무 커지면 CVE를 무시하거나 가볍게 여기는 습관이 생겨 결국 보안이 더 나빠질 수 있음. 이런 과잉 보고는 역효과를 낼 위험이 있어 보임. 몇 년간 이런 공지를 지켜봤는데, 이번에는 단일 공지에 담긴 CVE 수가 압도적으로 많음. Chromium이나 OpenSSL에서도 대규모 묶음이 나오기는 했지만, 맥락 없이는 숫자에 별 의미가 없다는 데 동의함. 그렇다면 이번 맥락은 무엇이며, 누가 혹은 무엇이 이 버그들을 전부 찾아낸 것인가? 특히 “거의 모든 버그가 악용될 가능성이 있다”는 부분에 주목해야 함. 접근성이 높아지면서 문제를 살펴보는 눈이 늘어난 것은 좋은 일임. 다만 이제야 이 취약점들이 발견되는 현상은 오픈소스 모델 자체보다 사람이 보안 문제를 찾아내는 능력에 의문을 던지는 것 아닌가? 오랫동안 숨어 있던 취약점들을 AI가 찾기 전까지 수천 명의 사람이 놓친 것은 아닌가? Microsoft와 Apple의 취약점 공개 기준은 Linux나 오픈소스 전반보다 훨씬 높음. 대체로 Windows와 macOS에서 심각하고 영향이 큰 문제만 공개함. 반면 Linux는 정상적인 설정으로 컴파일하고 실행하는 실제 운영 배포판에서 악용 가능한 버그인지조차 불분명한 수준까지 공개하는 편임. AI 이전부터 버그 없는 C 코드를 작성할 만큼 똑똑한 사람은 없다는 ...
Related
AnyPS5 - 에뮬레이션 없이 PS5 바이너리를 PC로 포팅하는 도구(시스템 라이브러리 87% 매핑)
17 minutes ago
0
Show GN: 추천링크·UTM으로 오프라인 소개의 성과를 추적하는 구조
1 hour ago
2
소프트웨어 팩토리 패턴 시도하기
1 hour ago
2
Show GN: 웹 변경 모니터링하는 크롬 확장프로그램
2 hours ago
3
OpenAI, 확률·선택지·점수를 반환하는 Decisions API 공개 베타 시작
2 hours ago
3
제프리 카첸버그 - 세상이 바뀌고 있다: 창의성을 위한 AI
2 hours ago
3
이 모든 것이 지나간 뒤를 위한 지속 가능한 웹 커리어
2 hours ago
3
여러 팀의 시스템을 이해하기 위한 AI 집단 지성 구축하기
2 hours ago
3
Tips
click
Popular
프로들도 줄지어 샷 점검… KLPGA 스타 사랑방 된 더헤븐CC 연습장
2 weeks ago
73
iOS 27, iPadOS 27, macOS 27
3 weeks ago
69
손흥민 선제골 발판·골대 불운…LAFC, 7경기 만에 승리
3 weeks ago
65
영림원소프트랩, 나람 통합 ERP 구축…사료 제조·물류·회계 데이터 하나로
2 weeks ago
62
'이 악문' 김영범, 자유형 50m '대회 신기록' 금메달
2 weeks ago
55
© Clint IT 2026. All rights are reserved

5 days ago
11








English (US) ·