소프트웨어 보안은 오랫동안 '취약점을 하나씩 찾아 고치는' 방식에 기대어 왔다. 하지만 이 접근은 확장성이 떨어진다. 치명적인 결함 하나를 패치했다고 해서 남아 있는 다른 결함들에 대해 알 수 있는 것은 아무것도 없기 때문이다. 앤트로픽이 공개한 연구는 다른 각도를 제시한다. 개별 취약점을 찾는 대신, 공격자가 애초에 도달할 수 있는 코드의 범위, 즉 공격 표면(attack surface) 자체를 줄이자는 것이다. 코드의 도달 가능성을 낮추면 아직 발견되지 않은 취약점은 물론, 이미 조용히 악용되고 있을지 모르는 결함까지 포함해 그 심각도를 한꺼번에 떨어뜨릴 수 있다. 결함을 제거하는 것은 아니지만, 결함에 닿기 어렵게 만드는 전략이다.
이 방법이 필요한 이유는 소프트웨어가 시간이 지날수록 복잡해지는 경향 때문이다. 새로운 추상화 계층, 의존성, 기능이 기존 코드 위에 계속 쌓이면서, 코드는 원래 개발자가 의도한 것과 상당히 다르게 동작하게 된다. 공격자들이 자주 성공하는 이유도 여기에 있다. 그들은 코드가 '어떻게 설계되었는가'가 아니라 '실제로 어떻게 동작하는가'를 연구한다. 공격 표면 축소는 바로 이 간극을 노린다. 불필요하게 노출된 코드를 찾아 적절한 관문 뒤로 옮기는 것이다. 인증 전 단계에서 인증 후 단계로, 0-클릭에서 1-클릭으로, 기본 활성화에서 명시적 옵트인으로, 혹은 프로토콜 첫 메시지에서 세션 상태 기계의 더 깊은 안쪽으로 코드를 이동시키는 식이다.
25개 프로젝트, 493건의 문제
앤트로픽은 C, C++, 자바, PHP, 파이썬 등으로 작성된 25개 오픈소스 프로젝트, 총 500만 줄이 넘는 코드에 클로드를 적용했다. 클로드는 1만 7,000개가 넘는 설정 옵션의 인벤토리를 만들었고, 그중 3,842개가 보안과 관련된 제어나 기능에 해당했다. 세 가지 축소 기법을 적용한 결과 모두 493건의 문제를 발견했다. 프로젝트는 성격에 따라 공개형(Public), 게이티드(Gated) 등으로 분류됐는데, 누구에게나 서비스를 제공하도록 설계된 공개형은 기본 설정에서도 상당 부분이 도달 가능한 반면 게이티드형은 그 반대여야 정상이다.
그런데 분석 대상이던 게이티드 프로젝트 11개 전부에서 의도치 않게 도달 가능한 코드가 발견됐다. 구체적으로 기본 설정에서 불필요한 인증 전 표면 93곳, 인증 이전에 코드가 실행되거나 상태가 기록되는 지점 37곳, 관리자가 설정한 인증 전 제어를 조용히 약화시키는 설정 조합 61건이 드러났다. 이들 각각이 즉시 악용 가능한 것은 아니었지만, 필요 이상으로 넓은 공격 표면을 만들어 두고 있었다.
조용히 꺼지는 보안 장치
가장 흥미로운 발견은 설정 간 상호작용에서 나왔다. 클로드는 오류나 경고 없이, 그리고 동작 방식에 대한 문서화도 없이 받아들여지는 보안 민감 설정 조합 162건을 찾아냈다. 이 중 94건은 두 설정을 함께 켜면 보안 제어가 조용히 비활성화되는 경우였다. 나머지 68건은 같은 보안 메커니즘 내부의 불일치였다. 설정상으로는 비활성화됐다고 표시되지만 실제 리스너나 로그인 경로는 여전히 열려 있거나, 두 설정이 충돌할 때 어느 쪽이 우선하는지가 설정 파일의 순서에 좌우되는 식이다.
특히 서로 무관한 네 개 프로젝트에서 독립적으로 같은 패턴이 나타났다. 관리자가 IP 주소 대신 호스트명이나 와일드카드 패턴으로 접근 규칙을 작성하면, 서버는 클라이언트 연결 시 그 규칙을 호스트명과 비교한다. 그러나 서버가 호스트명을 알아내는지는 역방향 DNS 조회를 켜는 별도 옵션에 달려 있고, 대부분 이 옵션은 꺼져 있었다. 조회가 꺼지면 서버는 IP 주소만 알게 되는데, 호스트명 패턴은 IP 주소와 결코 일치하지 않는다. 결국 차단(deny) 규칙은 발동하지 않고 목록은 열린 채로 실패(fail open)한다. 일부 프로젝트는 호스트명 규칙이 DNS 조회에 의존한다고 문서에 적어 두었지만, 이렇게 작성된 차단 목록이 fail open 동작을 한다는 점을 명시한 곳은 없었다. 또 다른 사례에서는 모든 클라이언트에 인증서 제출을 요구하도록 설정했음에도, 검사를 '지연'만 시키려던 코드가 실제로는 검사를 완전히 비활성화시켜, 신뢰된 클라이언트만 받도록 구성된 서버가 누구의 연결이든 수락했다. 이 충돌하는 설정 조합은 무려 21년간 소프트웨어에 존재해 왔다.
OpenSSH에서도 살아남은 도달 범위
코드 대비 비율로 가장 큰 축소 성과가 나온 프로젝트는 뜻밖에도 OpenSSH였다. 세계에서 가장 철저하게 감사받은 C 코드베이스 중 하나다. 클로드는 10.4 릴리스의 SSH 데몬 입력 경로를 추적해, 후양자 서명 알고리즘인 ML-DSA-44용 신규·실험 코드 약 4,500줄이 기본 설정에서 인증받지 않은 클라이언트에게 도달 가능하다는 사실을 발견했다. ML-DSA는 기본적으로 켜져 있지 않고, 관리자가 명시적으로 이 알고리즘을 배제해도 코드에는 여전히 닿을 수 있었다. 데몬은 클라이언트가 보낸 키 유형을 먼저 파싱하고(인증서라면 내장 CA 서명까지 검증한 뒤), 그제서야 해당 키 유형이 허용되는지를 확인했기 때문이다. 이 4,500줄은 기본 sshd의 인증 전 코드 중 약 16%에 해당한다. 앤트로픽은 이를 OpenSSH 개발진에 패치와 함께 보고했고, 10.5 릴리스는 검사를 파싱 이전으로 옮겼다.
하지만 클로드는 10.5 검사에서 두 가지 허점을 다시 짚어냈다. 하나는 클라이언트가 광고한 알고리즘 이름과 실제로 보낸 키 블롭 내부의 유형 문자열이 어긋날 수 있다는 점이었다. 클라이언트가 ssh-ed25519를 내세워 검사를 통과한 뒤 ML-DSA 키를 보내 파싱시킬 수 있었다. 다른 하나는 인증서 경로였다. 인증서 키 유형이 기본 활성화되어 있어, 공격자가 제공한 인증서가 주어지면 sshd는 설정을 확인하기도 전에 내장 CA 공개키를 역직렬화하고 전체 서명 검증을 수행했다. 사용자 키 서명 경로는 허용 목록 뒤에 제대로 가려져 있었지만 CA 서명 경로는 그렇지 않았다. 유지보수진과 여러 차례 수정을 거친 끝에, 이제 검사는 파서 내부로 들어가 역직렬화나 서명 검증 전에 허용 목록과 비교된다. 이 변경은 10.6 버전에 반영됐고, 기본 빌드에서 인증받지 않은 클라이언트가 도달할 수 있던 코드의 약 5분의 1을 제거했다.
실무자 입장에서 이 연구가 주는 메시지는 분명하다. 코드베이스에 숨은 미지의 취약점 수를 정확히 세는 일은 사실상 불가능하지만, 불필요한 공격 표면을 줄이는 작업은 그 모든 미지의 위험을 동시에 낮춘다. 세계에서 가장 많이 감사받은 OpenSSH조차 어떤 설정 검사보다 앞서 공격자가 닿을 수 있는 실험적 서명 파싱 코드 4,500줄을 출시했다는 사실은, 불필요한 도달 가능성이 어디에나 살아남을 수 있음을 시사한다. 다만 이 기법이 취약점 자체를 없애지는 않는다는 점, 그리고 비표준적이거나 드물게 쓰이는 설정 조합이 다수 포함된다는 점은 함께 기억해 둘 한계다. 그럼에도 설정 인벤토리 작성과 도달 경로 추적처럼 사람이 수작업으로 감당하기 어려운 영역에서, AI를 방어 도구로 활용하는 구체적 사례를 제시했다는 데 의미가 있다.