앤스로픽, 클로드로 코드 공격면 493개 자동 탐지

클로드가 500만 줄 코드에서 찾아낸 것

앤스로픽이 자사 모델 클로드를 이용해 25개 오픈소스 프로젝트(약 500만 줄)를 분석했다. C, C++, 자바, PHP, 파이썬 등 다양한 언어가 섞여 있다. 클로드는 설정 옵션 1만 7천여 개를 목록화했고, 이 중 3,842개가 보안 관련 기능 제어였다. 거기서 493개 이슈를 뽑아냈다. (출처: 앤스로픽 연구 블로그)

핵심은 **'취약점을 고치는 것'이 아니라 '취약점이 닿을 수 있는 경로 자체를 줄이는 것'**이다. 패치는 알려진 구멍만 막는다. 공격면 축소는 알려지지 않은 구멍까지 도달하기 어렵게 만든다. 앤스로픽은 이 방식이 "알려지지 않은 취약점의 심각도를 낮춘다"고 설명한다.

세 가지 분석 방법과 발견된 패턴

연구팀은 세 가지 접근을 썼다. 인증 전 불필요 코드 노출, 설정 간 충돌로 인한 보호 약화, 기본값 대비 과도한 권한 부여다. 이 중 설정 상호작용 오류가 162건으로 가장 많았다. 관리자가 보안 옵션을 켜도 다른 설정과 충돌해 실제로는 작동하지 않는 경우다.

게이티드(인증 필요) 프로젝트 11개 모두에서 의도치 않은 인증 전 진입점이 나왔다. 93개 불필요한 인증 전 면, 37개 인증 전 실행·기록 지점, 61개 설정 조합으로 인한 보호 약화가 확인됐다. 단독으론 즉시 악용 어렵지만, 공격자가 발판으로 쓰기 좋은 '넓은 문'이다.

해커뉴스 반응: "실제 적용해 보니 된다" vs "JS 런타임도 넣어라"

해커뉴스 댓글 20개 중 눈에 띄는 건 두 갈래다. 한 개발자는 바이브 코딩 도구 '빅스 IDE'에 이 프롬프트를 넣고 기능을 플래그 단위 러스트 크레이트로 분리해 최소 빌드를 만들었다고 썼다. "실제 적용해 보니 효과 있다"는 현장 증언이다.

반면 "리액트 파이버 워크루프만 5천 줄, JS 런타임 전체도 공격면에 넣어야 한다"는 지적도 나왔다. 클로드 같은 대형 모델을 쓸 때 모델 서빙 인프라 자체가 새로운 공격면이 될 수 있다는 우려다. 파이어웍스·오픈라우터 같은 서드파티 추론 서비스를 거치면 데이터 흐름이 더 복잡해진다.

쉽게 풀어보면

앤스로픽이 클로드로 25개 오픈소스 프로젝트 500만 줄을 훑었습니다. 클로드는 설정 옵션 1만 7천 개를 읽고, 보안 관련 3,842개를 골라냈습니다. 거기서 '열려선 안 될 문' 493개를 찾아냈습니다.

비유하면 이렇습니다. 집(코드)에 문과 창문(함수·API)이 많습니다. 도둑(공격자)은 열려 있는 문만 노립니다. 기존 방식은 **'열린 문마다 자물쇠를 다는 것(패치)'**입니다. 이번 연구는 **'애초에 안 쓰는 문은 벽으로 막아버리는 것(공격면 축소)'**입니다.

클로드가 발견한 대표 사례 세 가지입니다. 첫째, 로그인 전에 접근 가능한 기능 93개. 둘째, 로그인 전에 코드가 실행되거나 기록되는 지점 37개. 셋째, 관리자가 보안 설정을 켜도 다른 설정과 부딪혀 아무 경고 없이 풀려버리는 조합 162개입니다.

이건 '버그'가 아닙니다. **'설계 의도와 실제 동작의 차이'**입니다. 수만 줄 코드가 쌓이면서 개발자도 모르는 사이 문이 열려 있던 겁니다. 클로드는 이걸 설정 파일과 코드 흐름을 교차 검증해 자동으로 잡아냈습니다.

나에게 미치는 영향

당장 쓸 수 있는 건 두 가지입니다.

1. 내 프로젝트 설정 파일 점검
깃허브에 공개된 클로드 프롬프트 패턴을 참고해 settings.yaml, config.php, application.properties 등 설정 파일을 클로드에 넣고 물어보세요. "보안 관련 설정 간 충돌이 있는지, 기본값이 과도하게 열려 있는지 찾아줘." 단, 민감 코드는 로컬 모델이나 온프레미스 환경에서 돌려야 합니다.

2. 신규 기능 추가 시 '기본 차단, 명시적 허용' 원칙 적용
새 API나 관리자 기능을 만들 때 인증 후, 옵트인, 1클릭 이후로만 열리게 설계하세요. "나중에 필요하면 열자"가 아니라 "지금은 막고, 요청 오면 검토 후 열자"가 기본이어야 합니다. 이 원칙만 지켜도 공격면 절반은 줄입니다.

남은 검증 과제

앤스로픽 논문은 '발견'까지만 보여준다. 자동 수정(패치 생성)까지 갔는지, 거짓 양성(false positive) 비율은 어떤지는 공개하지 않았다. 해커뉴스 댓글에서도 "클로드가 제안한 수정 사항이 실제 빌드에서 깨지지 않았나" 묻는 글이 있었다. (출처: 해커뉴스 52점 스레드)

국내 기업 환경에선 코드 기밀성이 걸림돌이다. 퍼블릭 클로드 API에 전체 코드베이스를 올리기 어려운 곳이 많다. 온프레미스 배포나 파이어웍스·딥시크 같은 대안 모델 서빙을 쓸 때 데이터 이탈 위험과 비용을 같이 계산해야 한다.

리서치 데스크 메모

이 기술이 제품에 들어가려면 '발견→검증→자동 수정→CI/CD 연동' 파이프라인이 완성돼야 한다. 지금은 1단계다. 2~3년 내 IDE 플러그인이나 깃허브 액션 형태로 '설정 충돌 경고' 기능부터 상용화될 가능성이 크다.

가장 먼저 영향받을 직무는 보안 검수자·데브옵스 엔지니어다. 수동 설정 리뷰 시간을 줄이고, '모르는 구멍'을 기계가 미리 짚어주면 리뷰 포인트가 '구현 검증'에서 '아키텍처 판단'으로 올라간다. 개발자는 '기본 차단' 습관을 지금부터 들이는 게 가장 현실적인 대비다.