얼마 전에 Discord MCP 서버를 클로드 코드에 붙여서 쓰고 있었는데요. 봇 토큰을 설정 파일에 평문으로 박아두기는 찜찜해서, 1Password CLI로 토큰을 주입하도록 바꿔뒀습니다. 그런데 그날부터 클로드 코드를 켤 때마다 화면 한가운데 "1Password Access Requested" 창이 뜨면서 Touch ID를 요구하기 시작했어요. 😅 하루에도 몇 번씩 터미널을 새로 여는데, 그때마다 손가락을 갖다 대는 건 생각보다 거슬립니다. 게다가 cron으로 돌리는 스크립트라면 아예 사람이 없으니 인증 자체가 불가능하죠. 이
CLI 도구를 쓰다 보면 인증 토큰을 어디에 둘지가 늘 고민입니다. GitHub CLI는 GH_TOKEN, Cloudflare Wrangler는 CLOUDFLARE_API_TOKEN 같은 환경 변수를 지원하는데요. 편하다고 셸 설정 파일이나 .env 파일에 토큰을 넣어두면 어느 순간 평문 시크릿이 로컬 디스크 여기저기에 흩어집니다. 1Password에는 이런 문제를 줄여주는 Shell Plugins 기능이 있습니다. CLI가 인증 정보를 필요로 할 때 1Password가 토큰을 꺼내 환경 변수로 주입하고, 사용자는 지문이나 Appl
GitHub Actions로 배포나 테스트를 자동화하다 보면 API 키, 데이터베이스 비밀번호, 배포 토큰 같은 시크릿을 다루게 됩니다. 처음에는 GitHub Secrets에 하나씩 넣어두면 충분해 보이는데요. 프로젝트가 늘어나고, 시크릿을 여러 저장소에서 공유하고, 키를 주기적으로 교체해야 하는 순간부터 관리가 조금씩 복잡해집니다. 이럴 때 1Password를 시크릿의 원천 저장소로 두고, GitHub Actions에서는 실행 시점에 필요한 값만 읽어오게 만들 수 있습니다. GitHub에는 1Password에 접근하기 위한 서비스
GitHub Actions는 무료로 시작할 수 있고 워크플로우 한두 줄이면 배포까지 굴러가니 정말 편하죠. 그런데 편한 만큼 위험도 가까이에 있는데요. 워크플로우 한 줄을 잘못 쓰면 저장소의 모든 비밀이 외부로 흘러나가거나, 누군가의 PR 제목이 곧바로 러너에서 셸 명령으로 실행되는 일도 일어납니다. 실제로 PR 제목에 백틱과 셸 명령을 끼워 넣어 러너의 환경 변수와 토큰을 탈취한 사례가 종종 보고되고 있고, 인기 액션의 메인 브랜치가 손상되어 수많은 저장소에서 비밀이 유출되는 사고도 잊을 만하면 한 번씩 터집니다. 다행히 깃허브가
소스 코드 저장소에 API 키나 토큰이 실수로 들어간 적, 한 번쯤 있으시죠? 당장 git rm으로 지우고 강제 푸시를 해도 깃 히스토리에는 흔적이 남고, 공개 저장소라면 봇이 몇 분 안에 그 키를 긁어가 버립니다. 악의적인 사용자가 발견하기 전에 깃허브가 먼저 찾아서 알려주면 좋겠다는 생각이 절로 들죠. 이번 글에서는 깃허브가 무료로 제공하는 Secret Scanning 기능이 어떻게 동작하고, 푸시 시점부터 사후 알림까지 어떤 방어선을 쌓아주는지 정리해 보겠습니다. Secret Scanning이 푸는 문제 비밀 정보가 저장소로
개발하다 보면 API 키, 데이터베이스 비밀번호, 토큰 같은 시크릿(secret)을 다룰 일이 정말 많죠. .env 파일에 평문으로 저장하자니 불안하고, 팀원이랑 공유하려고 슬랙으로 보내자니 그것도 영 찝찝합니다 😅 1Password는 이미 많은 개발자가 비밀번호 관리 도구로 사용하고 있는데요. 사실 1Password에는 op라는 공식 CLI 도구가 있어서 터미널에서도 1Password 볼트에 저장된 시크릿을 자유롭게 다룰 수 있습니다. 환경 변수에 시크릿을 주입하거나, 스크립트에서 비밀번호를 안전하게 참조하거나, SSH 키 관리
소프트웨어 보안은 늘 개발자들의 골칫거리입니다. 코드 리뷰를 하고, 정적 분석 도구를 돌리고, 보안 감사를 받아도 취약점은 끊임없이 발견되죠. 특히 비즈니스 로직 결함이나 복잡한 접근 제어 문제는 기존 도구로는 잡아내기가 정말 어렵습니다. Anthropic이 최근 발표한 Claude Code Security는 이 문제에 완전히 다른 방식으로 접근합니다. 패턴을 매칭하는 게 아니라 코드를 읽고 추론해서 취약점을 찾아내는 거죠. 보안 취약점, 왜 이렇게 잡기 어려울까 소프트웨어 업계에서 보안 취약점은 만성적인 문제입니다. 취약점은 너무
클로드 코드를 써보셨다면 "이 명령어를 실행해도 될까요?"라는 팝업이 익숙하실 겁니다. 처음엔 안전장치니까 반갑지만 반복되면 점점 피로해지죠. 결국 내용을 대충 훑고 승인 버튼을 누르게 되는데 이러면 오히려 보안에 취약해집니다. Claude Code의 샌드박스는 이 문제를 해결합니다. 명령어를 일일이 검사하는 대신 OS 레벨에서 실행 환경 자체를 격리해서 안전한 경계 안에서는 자유롭게, 경계 밖으로는 절대 못 나가게 만드는 거죠. 왜 샌드박스가 필요한가 클로드 코드 권한 설정에서 다뤘던 권한 시스템은 "이 도구를 써도 되는가?"를
클로드 코드를 쓰다 보면 "이 파일을 수정해도 될까요?", "이 명령어를 실행해도 될까요?" 하는 승인 팝업이 끊임없이 뜹니다. 한두 번이면 괜찮지만 리팩토링처럼 파일을 수십 개씩 고치는 작업에서는 클릭 노동이 되죠. 반대로 CI/CD 파이프라인에서는 묻더라도 답할 사람이 없습니다. 😅 이처럼 상황마다 필요한 자율성이 다릅니다. 탐색만 할 때는 코드를 건드리지 못하게 막고 싶고, 빌드를 돌릴 때는 편하게 허용하고 싶죠. 클로드 코드의 권한 모드가 이 스펙트럼을 조절해 줍니다. 권한 설정이 "무엇을 허용/차단할까"를 정한다면, 권한
클로드 코드를 쓰다 보면 가장 자주 마주치는 것이 "이 명령어를 실행해도 될까요?"라는 권한 요청 팝업입니다. 처음에는 안전장치로 느껴지지만 매번 답하다 보면 꽤 성가시죠. 이 글에서는 클로드 코드의 권한 시스템을 속속들이 파헤쳐서 안전하면서도 흐름이 끊기지 않는 환경을 만드는 방법을 알아보겠습니다. 권한 시스템의 기본 구조 클로드 코드는 도구 종류에 따라 세 단계의 기본 권한 정책을 적용합니다. | 도구 유형 | 예시 | 승인 필요 | "다시 묻지 않기" 범위 | | ----------- | ---------------------
웹 개발자라면 한 번쯤은 CORS 문제 때문에 골치아팠던 적이 있으시죠? Cross-Origin Resource Sharing, 줄여서 CORS는 웹 페이지가 다른 도메인의 리소스에 안전하게 접근할 수 도와주는 브라우저의 기능입니다. 이번 포스팅에서는 CORS의 기본 개념부터 작동 원리, 요청 흐름 그리고 실제 구현 방법까지 자세히 다루도록 하겠습니다. 동일 출처 정책 CORS를 제대로 이해하려면 우선 브라우저의 기본 보안 기능인 Same-Origin Policy, 즉 동일 출저 정책에 대해서 알고 있어야 합니다. 브라우저는 현재
오픈소스를 운영하다 보면 스타가 늘거나 이슈가 쌓이는 일에는 어느새 익숙해지는데요. 그러던 어느 날 저장소 Security and quality 탭에 처음 보는 빨간 알림이 뜨고 "당신의 패키지에서 보안 취약점을 발견했습니다"라는 제보가 들어오면 이야기가 달라집니다. 머릿속이 하얗게 변하면서 "이걸 이슈로 답해야 하나? 일단 코드부터 고쳐서 푸시할까?" 하는 생각이 먼저 떠오르죠. 😅 이건 결코 남의 일이 아닌데요. 2021년 전 세계 서버를 떨게 한 Log4j의 Log4Shell 같은 대형 사건도 있었지만, 멀리 갈 것도 없이
개발하다 보면 API 키, 데이터베이스 비밀번호, 토큰 같은 민감한 정보를 다룰 일이 많은데요. 이런 값들을 .env 파일이나 설정 파일에 평문으로 저장해두면 실수로 Git에 커밋하거나 다른 사람에게 노출될 위험이 있습니다. macOS에는 이런 민감한 정보를 안전하게 보관할 수 있는 **키체인(Keychain)**이라는 시스템이 내장되어 있는데요. 보통은 키체인 접근(Keychain Access) 앱을 통해 GUI로 사용하지만, 터미널에서 security 명령어를 사용하면 키체인을 훨씬 효율적으로 다룰 수 있습니다. 이번 글에서는