Claude Code의 보안을 강화하는 'nah', 개발자들의 평가는?

Claude Code의 권한 관리 시스템(Permission System)의 한계를 극복하기 위해 개발된 'nah'에 대한 소개

nah는 명령어의 액션 타입(Action Type)을 기반으로 권한을 제어하며, LLM을 선택적으로 활용

컨텍스트 인식(Context-Aware) 기능과 유연한 설정 옵션을 제공하여 사용자 정의 가능성을 높임

커뮤니티에서는 보안 취약점(Security Vulnerability), DSL 부재, 그리고 샌드박스(Sandbox) 필요성에 대한 논의가 진행됨

액션 타입 기반의 권한 제어 방식

nah는 명령어 자체보다는 액션 타입(Action Type), 즉 파일 시스템 접근, Git 히스토리 조작 등 행위의 종류를 기준으로 권한을 부여한다. 이는 명령어 이름 기반의 허용/거부 방식보다 유연하고, 잠재적인 위험을 더 효과적으로 관리할 수 있게 해준다. Kave0ne은 이러한 접근 방식이 올바른 추상화 수준이라고 평가하며, 특히 컨텍스트에 따라 달라지는 권한 처리에 대한 중요성을 강조했다.

컨텍스트 인식 및 LLM 활용의 장단점

nah는 명령어의 실행 컨텍스트를 분석하여 권한을 다르게 적용하는 기능을 제공한다. 예를 들어, 프로젝트 내부에서의 `rm` 명령어는 허용하고, 외부에서의 실행은 거부하는 식이다. 또한, 불확실한 경우 LLM을 활용하여 판단을 보조할 수 있다. 하지만, ramoz는 LLM 기반의 판단이 완벽한 보호를 제공하지 못하며, 샌드박스(Sandbox)와 같은 보다 강력한 보안 메커니즘의 필요성을 제기했다.

보안 취약점 및 공격 가능성

커뮤니티에서는 nah의 보안 취약점에 대한 우려가 제기되었다. gruez는 `npm test`와 같이 허용된 명령어를 악용하여 악성 코드를 실행하는 공격 가능성을 지적했다. 또한, nah가 모든 공격 시나리오를 커버하지 못할 수 있으며, 특히 Bash와 같은 쉘 환경의 비결정성(Non-Determinism)으로 인해 완벽한 보호가 어렵다는 점을 강조했다.

DSL 부재 및 설정의 복잡성

m4r71n은 nah의 컨텍스트 구현 방식이 하드코딩된 가정에 의존하고 있어, 유지보수가 어려워질 수 있다고 지적했다. 특히, 특정 디렉토리 삭제와 같이 간단한 규칙을 표현하기 위해 복잡한 설정을 거쳐야 하는 점을 문제로 삼았다. 이러한 DSL(Domain Specific Language)의 부재는 설정의 복잡성을 증가시키고, 사용자 편의성을 저해할 수 있다.