시크릿 관리
이 태그가 달린 문서 23건
Fireworks AI 보안 사고(2026년 10월): 결제 정보와 일부 데이터셋·모델 가중치에 영향, 회사는 클라우드 업체 침해가 관련됐다고 설명. 고객이 해야 할 일
AI 모델 추론 인프라를 제공하는 Fireworks AI는 2026년 10월 9일에 처음 공개한 보안 사고에 대해 11월 9일 업데이트를 발표했습니다. 회사에 따르면 10월 6일에 발견한 최초 사고에서는 Fireworks에 저장된 비밀 정보(평가 작업에서 쓰는 것 등)만 영향을 받은 것으로 알려져 있었는데, 이후 계정·결제 정보에 영향이 있었고 한정된 계정에서는 비밀 정보, 데이터셋, 불완전한 모델 가중치에도 영향이 있었음을 확인했습니다. 회사의 설명으로는 연구개발용 머신을 호스팅하던 제3자 클라우드 업체에서 10월 23일 보안 사고가 있었고, 10월 24일 무단 제3자가 이를 이용해 Fireworks의 개발 머신에 닿아 무단 워크로드를 실행했으며 이로 인해 고객 데이터에 추가 영향이 생겼습니다. 회사는 같은 날 이를 탐지했고, 10월 25일 시점에 고객이 쓰는 플랫폼에 대한 추가적인 무단 접근 성공의 증거는 탐지하지 못했다고 합니다. 증거는 금전 목적의 사이버 범죄 조직과의 연관을 시사한다고 합니다. 결제 카드 번호는 회사가 저장하지 않으며 영향을 받지 않았습니다. 기본값이 데이터 보존 없음(zero data retention)인 Inference, Training SDK, Nexus에서는 영향이 탐지되지 않았습니다. 조사 중에는 셀프 서비스 데이터셋 업로드와 다운로드가 비활성화되어 있습니다. 우리의 견해: 고객은 플랫폼에 저장한 것을 목록으로 만들어 교체하고, 운영자는 개발 환경을 결제·고객 데이터 시스템과 분리하세요.
NEAR AI, 추론 엔진 결함으로 침해(사용자 약 100명의 계정 정보): 확인된 내용과 사용자·AI 인프라 운영자가 해야 할 일
AI 채팅과 에이전트를 제공하는 NEAR AI는 2026년 11월 9일자 공식 블로그 글에서 인프라 일부에 대한 무단 접근을 공개했습니다. 회사에 따르면 원인은 자사 서버에서 돌던 오픈 소스 추론 엔진 SGLang의 원격 코드 실행 결함이며, 공격자는 추론 서버 한 대에서 코드를 실행한 뒤 거기서 다른 인프라에 닿았습니다. 회사가 확인한 내용은 다음과 같습니다. 이전에 폐지된 Private Chat 뒤의 내부 시스템에서 사용자 약 100명의 계정 정보(이메일 주소, 이름, 일부 계정은 요금제와 잔액 정보)를 가져갔고, 기밀 컴퓨팅(TEE) 환경에서 실행되지 않던 레거시 에이전트 18개의 채팅 기록, 설정, 로그를 가져갔습니다. 이와 별도로 Cloud 고객 2곳의 NEAR AI Cloud API 키가 로그에 노출되었습니다(폐기됨. 가져갔다고는 적혀 있지 않음). 11월 8일에는 침해된 서버에서 처리되던 사용자 요청을 공격자가 볼 수 있었을 가능성이 있으며, 여기에는 기밀 모드 요청도 포함됩니다. 저장된 Private Chat 대화나 업로드된 파일에 접근한 징후는 없다고 합니다. 회사는 자격 증명을 교체하고 결함을 수정했으며 NEAR AI Cloud 접근을 복구했다고 밝혔습니다(Private Chat은 오프라인 상태). 공식 보고서에는 CVE 번호가 없습니다. 우리의 견해: AI 인프라 운영자에게 핵심은 추론 서버와 내부 시스템을 분리하고, 레거시 환경을 남기지 않고, 비밀 정보가 로그에 남지 않게 하는 것입니다.
Ethersphere bee-js 13.3.0과 Swarm Desktop 0.56.2에 악성코드가 배포됨(2026년 11월): 영향받는 버전과 사용자가 해야 할 일
분산 스토리지 네트워크 Swarm의 개발사 Ethersphere의 npm 패키지 @ethersphere/bee-js 13.3.0에 악성 코드가 들어 있었습니다. 2026년 11월 9일 공개된 GitHub 권고(GHSA-hh7j-5m3j-23pf)는 영향받는 버전이 13.3.0뿐이며 패치된 버전은 없다고 밝힙니다. 이 패키지가 설치되었거나 실행 중인 컴퓨터는 완전히 침해된 것으로 간주하고, 그 컴퓨터에 있던 모든 비밀 정보와 키를 다른 컴퓨터에서 즉시 교체하라고 합니다. 패키지를 삭제해도 설치로 생긴 악성 소프트웨어가 모두 지워지지 않을 수 있습니다. Swarm Desktop은 Ethersphere의 릴리스 노트에 따르면 11월 9일 공개된 0.56.3이 침해된 0.56.2를 대체합니다. 한 보안 업체의 분석에 따르면 bee-js 13.3.0은 11월 9일 UTC 00:09경(일본 시간 09:09) npm에 올라왔다가 약 75분 뒤 삭제되었습니다. Swarm Desktop 0.56.2는 약 8.5시간 공개되었고 Windows x64와 Apple Silicon에는 자동 업데이트로도 전달되었습니다. bee-js 13.2.0 이하와 Swarm Desktop 0.56.1은 영향이 없다고 보고되었습니다. 같은 분석은 Bee 노드의 설정 파일(평문 비밀번호가 들어 있음)과 지갑 키가 노렸고, 공식 릴리스 자동화가 쓰는 자격 증명이 악용되었다고 밝힙니다. 우리의 결론: 영향받는 버전을 설치한 머신과 CI 환경은 다시 구축하고, 지갑을 새 키로 옮겨 자금을 이동하며, 다른 머신에서 자격 증명을 교체하세요.
mittwald MCP 서버 결함 악용으로 고객 프로젝트 56건 침해(2026년 11월): 공개된 경과와 사용자·AI 연동 운영자가 해야 할 일
독일 웹 호스팅 업체 mittwald는 공식 블로그 글에서 고객의 AI 어시스턴트를 관리 화면 mStudio에 연결하는 MCP 서버의 결함이 악용되어 고객 프로젝트 56건이 침해되었다고 밝혔습니다. 회사에 따르면 공격자는 10월 21일 결함을 처음 시험했고, 10월 23일부터 테스트 계정으로 일반 사용자처럼 행동하기 시작했으며, 10월 27일 15시 03분 다른 계정으로 결함을 악용했습니다. 회사는 10월 27일 이후의 모든 데이터를 침해된 것으로 취급합니다. 11월 4일 이상 동작이 발견되었고 같은 날 MCP 서버를 침입 경로로 특정해 중지했습니다. 11월 6일에는 침해된 프로젝트 56건과 MCP 서버를 포렌식으로 조사해 추가로 침해된 프로젝트를 찾지 못했으며 현재 공격자의 활동은 탐지할 수 없다고 합니다. 비밀번호는 읽히지 않았고 읽힌 것은 사용자의 세션 토큰이며 모두 폐기했다고 합니다. 고객 센터와 거기서 관리되는 웹사이트는 영향이 없었습니다. MCP 서버는 오프라인이며 복귀 여부는 조사 후에 결정됩니다. 회사는 공격자의 속도로 보아 AI 도구를 썼을 것으로 의심한다고 밝혔으며, 이는 회사의 의심입니다. 다음 주에 상세한 경과를 공개할 예정입니다. 우리의 견해: AI 어시스턴트를 호스팅이나 운영 환경에 연결하는 MCP 서버에서는 범위를 좁힌 단기 토큰과 탐색 단계를 잡을 수 있는 감시가 핵심입니다.
Trigger.dev 보안 사고(2026년 11월): 고객의 0.66%에서 루트 API 키와 환경 변수에 접근, 키를 재생성하고 시크릿을 교체하세요
백그라운드 작업과 AI 에이전트를 실행하는 플랫폼 Trigger.dev는 2026년 11월 1일 보안 사고를 공개하고 11월 6일 후속 보고서를 게시했습니다. 회사는 11월 1일 인프라 경보가 비정상 활동을 포착했고, 악의적인 활동으로 판단해 공격자를 차단했다고 밝혔습니다. 영향을 받은 것은 전체 고객의 0.66%입니다. 공격자는 일부 고객 환경의 루트 API 키를 확보했고, 루트 키는 환경 변수를 포함한 환경 설정 전체에 접근할 수 있습니다. 일부 환경에서는 최근 실행, 배포, 스케줄 목록도 조회했으며, 그 결과로 ID, 작업 이름, 실행 멱등성 키, 실행 상태, 태그, 배포 메타데이터와 오류, 스케줄 외부 ID, 실행 메타데이터가 반환되었습니다. 회사는 그 밖의 고객 데이터, 다른 서비스, 자사 운영 데이터베이스, 고객 대시보드 계정에 접근한 증거는 찾지 못했다고 밝혔습니다. 조사와 고객을 보호하기 위해 공격 경로는 공개하지 않습니다. 영향을 받은 고객에게는 이메일(11월 1일과 2일)과 대시보드 배너(시점은 명시되지 않음)로 연락했고, 영향을 받았을 수 있는 API 키는 폐기했습니다. 영향을 받은 고객은 API 키를 재생성하고, 영향을 받은 환경의 데이터베이스 비밀번호나 서드파티 API 키 같은 자격 증명을 교체하면서 이전 것은 발급처에서 폐기해야 합니다. 회사는 영향 통지를 받지 않은 고객은 영향을 받지 않았고, 웹훅 서명 시크릿은 노출되지 않았으며, 셀프 호스팅 배포는 영향이 없다고 밝혔습니다. 이 사이트의 판단: 먼저 이메일과 대시보드 배너를 확인하고, 영향을 받았다면 회사의 안내대로 키를 재생성하고 자격 증명을 교체하세요.
Northflank 보안 사고(2026년 10월): 저장된 환경 변수가 복호화된 것으로 간주, AI API 키 부정 사용 보고
2026년 10월 30일(UTC), 클라우드 배포 플랫폼 Northflank는 상태 페이지에 보안 사고를 게시했습니다. 보안 업체의 위협 경보가 11:43 UTC에 들어왔고, 회사는 12:02 UTC부터 패치를 배포했으며, 13:40 UTC에 고객에게 환경 변수를 교체하라고 안내했고, 13:58 UTC에는 모든 환경 변수가 복호화된 것으로 가정하라고 안내했습니다. 15:12 UTC에 이미 여러 이용자가 자신의 AI 키가 사용되었다고 보고하고 있다고 상태 페이지에 적었고, 23:38 UTC에는 플랫폼에 저장된 AI API 키가 무단 사용되었다는 이용자 보고가 있다고 밝혔습니다. 10월 31일에는 모든 고객에게 감사 로그를 활성화하고, 애드온의 시크릿 교체 기능을 유형별로 하나씩 공개했습니다. 11월 2일 업데이트(11:09 UTC, 상태 Monitoring)에서 회사는 첫 경보로부터 1시간 안에 공격을 차단했다고 보고 있으며, 실행 중인 워크로드는 영향을 받지 않았고 워크로드나 그 데이터에 접근한 흔적은 보지 못했으며, 공격은 컨트롤 플레인의 시크릿에 집중된 것으로 보인다고 밝혔습니다. 독립된 포렌식 감사인이 검토 중이며, 회사는 액세스 토큰, 세션, VCS 연동, 계정 간 IAM 역할을 폐기했고(그래서 이용자는 다시 로그인하고 연동을 다시 연결해야 합니다), 조사 결과가 확인되면 근본 원인 분석을 공개하겠다고 약속했습니다. 11월 6일 업데이트(10:09 UTC)에서 회사는 시크릿이 처음으로 복호화된 것으로 파악되는 시점이 첫 경보(11:43 UTC)보다 앞선 10월 30일 02:39–03:08 UTC라고 밝혔고, 익스플로잇은 통보를 받고 60분 안에 패치했으며 고객에게는 2시간 안에 알렸고, 고객 워크로드나 그 데이터에 접근한 증거는 찾지 못했으며, 가능한 범위에서 상위 업체와 협력해 자격 증명을 폐기했다고 밝혔습니다. 포렌식 검토는 계속되고 있습니다. 영향을 받은 고객 수, 공격자의 침입 경로, 관련된 AI 업체는 공개되지 않았습니다. 이 사이트의 판단: Northflank에 저장한 모든 시크릿을 발급한 서비스에서 폐기하고, 각 AI 업체의 사용량과 청구를 살펴보고, 지출 한도를 설정하세요.
OpenCode Console 침해(2026년 10월, Console 이용자의 1.4%): AI 제공업체 API 키 노출 가능성과 해야 할 일
2026년 10월 17일, 오픈소스 AI 코딩 에이전트 OpenCode는 공식 X 계정에서 전날 밤 대규모 증류(distillation) 공격과 관련된 보안 침해가 있었으며 OpenCode Console 이용자의 1.4%가 영향을 받았다고 밝혔습니다. 회사는 그날 아침 영향을 받은 모든 이용자에게 이메일을 보냈고, 이메일을 받지 않은 이용자는 영향을 받지 않았으며, 영향을 받은 이용자는 외부 제공업체를 연결한 이용자의 일부라고 했습니다. 회사는 사고가 진행 중이라 더 자세한 내용은 공유할 수 없으며, 관련 AI 제공업체와 협력하고 있다고 밝혔습니다. 이메일 내용과 회사의 발언을 다룬 보도에 따르면, 이용자가 Console 워크스페이스에 저장한 외부 AI 제공업체의 API 키가 이전 시스템을 통해 노출되었을 수 있으며, 영향을 받은 이용자에게는 각 제공업체에서 직접 키를 폐기하고 교체하라는 안내가 있었습니다. 공동 창업자는 오픈소스 앱과 명령줄 도구는 영향을 받지 않았다고 말했습니다. 이 사이트의 견해: 이메일을 받았거나, OpenCode Console에 AI 제공업체 키를 연결해 두었는데 확신이 없다면, 오늘 각 제공업체의 대시보드에서 키를 폐기하고 10월 17일 이후의 사용량과 청구를 확인하세요.
Zeabur 보안 사고(2026년 10월, 환경 변수 322만 건 열람): 교체할 시크릿과 이용자가 해야 할 일
2026년 10월 19일, 앱 배포 플랫폼 Zeabur는 10월 14–15일(UTC)의 보안 사고에 관한 예비 보고서를 공개했습니다. 회사에 따르면 공격자는 유출된 Zeabur 내부 자격 증명으로 공유 클러스터, 일부 전용 서버(Dedicated Servers), 내부 시스템에 들어간 뒤, 10월 15일 16:10부터 16:47 UTC 사이에 플랫폼 데이터베이스를 열람했습니다. 회사는 환경 변수 3,218,965건(이름과 값)과 321,810개 계정의 데이터(이메일, 사용자 이름, 전화번호 등), 그리고 566개의 zSend API 키가 열람된 것을 확인했으며, zSend API 키는 폐기했습니다. 회사는 근본 원인이 Zeabur에 있다고 밝혔습니다. 장기간 유효한 관리자 자격 증명이 평문으로 저장되어 있었고 공용 인터넷에서 사용할 수 있었다는 것입니다. 회사는 8월의 별도 사고 뒤 이미 교체했더라도 Zeabur에 저장한 모든 비밀번호와 키를 교체하라고 모든 이용자에게 요청하고 있습니다. Zeabur는 10월 17일 2026년 12월 31일에 서비스를 종료한다고 발표했고, 10월 22일에는 사고로 인한 손해 청구 기한을 2026년 11월 30일로 정했습니다. 이 사이트의 견해: Zeabur 환경 변수에 넣은 적이 있는 모든 시크릿을 다른 누군가가 알고 있다고 보고, 먼저 발급한 서비스에서 폐기한 뒤 10월 14일 이후의 청구서와 로그를 확인하세요.
Railway 환경 변수 노출 가능성 (2026년 10월, 최대 1.85% 워크스페이스): 교체해야 할 시크릿과 사용자 조치
Railway는 2026년 10월 21일(UTC), 고객 환경 변수를 저장하는 시스템에서 이상 활동을 탐지했으며 권한 없는 제3자가 암호화된 환경 변수에 접근하고 그중 일부는 복호화된 내용을 확보했을 수 있다고 발표했습니다. 10월 22일자 예비 보고서(상태 페이지 기준 10월 23일 16:38 UTC 공개)에 따르면 공격은 10월 20일 13:58 UTC부터 10월 22일 03:32 UTC까지 이어졌습니다. 공격은 빌드 인프라에 대한 권한 상승 시도로 시작되었고, 10월 21일에 CI 환경 자격 증명이 사용되어 암호화된 환경 변수 일부가 복호화되었습니다. 전체 워크스페이스의 최대 1.85%(회사에 따르면 약 100,000개 워크스페이스)에서 일부 환경 변수가 유출되었을 가능성이 있습니다. 회사는 Railway 사용자 계정에는 접근이 없었다고 밝혔으며, 소스 코드 접근 가능성은 최종 보고서 전까지 배제하지 않았습니다. 공격자는 AI 제공업체 API 키를 노린 것으로 보입니다. Railway는 모든 사용자에게 10월 21일 이전에 저장한 시크릿을 교체하고, 데이터베이스의 공개 네트워크 접근을 제거하며, GitHub와 레지스트리(Docker Hub 등)의 감사 로그를 확인할 것을 권고합니다. 이 사이트의 결론: 연락을 받지 않았더라도 Railway에 저장한 시크릿은 노출된 것으로 간주하고, 원본에서 재발급한 뒤 재배포하고 나서 이전 값을 폐기하십시오.
LiteLLM 1.107.0에 자격 증명 탈취 악성코드 포함(2026년 10월): 영향받은 PyPI 릴리스와 Docker 이미지, 사용자가 해야 할 일
2026년 10월 21일(UTC), LiteLLM을 개발한 BerriAI는 릴리스 파이프라인이 침해되어 자격 증명을 탈취하고 원격 코드 실행 도구를 불러오는 악성코드가 담긴 v1.107.0이 배포되었다고 발표했습니다. 영향받은 대상은 PyPI의 litellm==1.107.0(11:39~13:23 UTC), Docker Hub의 v1.107.0, latest, main-latest, main-stable 태그(11:46~14:20 UTC), GHCR의 같은 태그(11:46 UTC부터 늦어도 13:51 UTC에 내려갈 때까지, 약 2시간)입니다. GitHub의 공식 v1.107.0 소스 태그에는 악성 파일이 들어 있지 않으며, 해당 아티팩트는 공격자가 통제하는 유사 저장소에서 빌드되었습니다. 이전 버전은 모두 이번 침해와 무관하며, 회사는 사용자에게 1.106.2 또는 그 이전의 명시적 버전으로 고정할 것을 요청합니다. 10월 24일(UTC) 회사는 1.103.8, 1.104.6, 1.105.4, 1.106.3을 공개했고, 이 릴리스부터 Docker 이미지와 Helm 차트는 새 cosign 키로 서명됩니다(이전 키로는 검증되지 않습니다). 10월 23일 회사는 근본 원인 분석을 공개하면서, 토큰이 내부 LiteLLM 배포 환경의 로그에서 유출되었다는 처음의 판단을 정정했습니다. 분석에 따르면 5월 27일 공개 저장소에 실수로 커밋된 설정 파일에 내부 에이전트 플랫폼의 마스터 키가 들어 있었고, 커밋은 덮어썼지만 키는 폐기되지 않았습니다. 10월 10일 공격자는 이 키로 플랫폼 API를 호출해 그곳에 설정된 GitHub 조직 소유자의 GitHub CLI 토큰을 얻었습니다. 이를 이용해 CI 시크릿을 빼내 다른 메인테이너 두 명의 토큰을 확보했고, 10월 21일 브랜치 보호를 해제하고 릴리스 워크플로를 변경한 뒤 릴리스를 승인했습니다. 이 사이트의 결론: 해당 시간대에 1.107.0을 설치했거나 실행한 환경은 다시 구축하고, LLM 제공업체 키, 프록시 마스터 키, 데이터베이스 비밀번호, 클라우드 역할 등 그 환경이 접근할 수 있던 모든 키를 교체하세요.
GitHub에 공개된 인증 정보 543,699건이 여전히 유효했다 (2026년 연구): 삭제가 아니라 폐기해야 하는 이유와 개발자가 할 일
비밀값 검사 도구를 판매하는 보안 회사가 LLM 학습용으로 수집된 약 2억 2,400만 개 공개 저장소의 스냅숏을 조사해, 2026년 7월 말 시점에 543,699건의 인증 정보가 여전히 인증에 성공했다고 보고했다. 노출 후 경과 기간의 중앙값은 784일이었다. npm과 GitHub 토큰은 거의 모두 무효화돼 있었던 반면, 데이터베이스 연결 문자열은 75~88%가 여전히 작동했다. 유효한 인증 정보 중 19만 9천 건 이상은 GitHub가 push protection을 기본으로 켠 뒤에 나타났고, 유효한 것의 절반 이상은 push protection이 기본으로 막지 않는 유형이었다. 이 사이트의 결론 = 공개 저장소에 push한 인증 정보는 파일 삭제나 이력 재작성으로 회수할 수 없으므로 먼저 폐기한다. 유출된 인증 정보가 자동으로 폐기되는지는 발급자에 달려 있으며, 연결 문자열과 많은 API 키는 내가 멈출 때까지 유효하다.
TanStack, Nx Console, GitHub로 이어진 침해 연쇄 (2026년 5월): 개발자가 확인할 것
2026년 5월 11일 TanStack의 Router/Start 저장소의 배포 파이프라인이 악용돼 npm 패키지 42개, 84개 버전에 인증 정보를 훔치는 코드가 실렸다. 그중 하나를 설치한 Nx 기여자의 GitHub CLI 토큰이 탈취됐고, 5월 18일 변조된 Nx Console 확장(v18.95.0)이 공개됐다. 같은 날 GitHub는 악성 VS Code 확장으로 직원 기기가 침해돼 GitHub 내부 저장소가 유출됐다고 밝혔다. 세 사건 모두 정상 계정과 정상 배포 경로를 거쳤으므로, 방어는 탈취된 배포 인증 정보(토큰) 하나만으로 새 버전을 낼 수 없게 하는 것, 그리고 설정해 둔 안전장치가 실제로 동작하는지 확인하는 것이다.
Trivy 공급망 침해 (2026년 3월): CI에서 Trivy를 쓰고 있다면 할 일
2026년 3월 19일 Aqua Security가 개발하는 오픈소스 취약점 스캐너 Trivy의 악성 v0.69.4가 배포됐고, GitHub Actions의 trivy-action(태그 77개 중 76개)과 setup-trivy(태그 7개 전부)가 악성 커밋을 가리키도록 바뀌었다. Aqua에 따르면 악성 코드는 CI 러너에서 비밀값을 수집해 외부로 보냈고, 원인은 2월 말에 시작된 침해에서 탈취된 인증 정보였으며, 3월 1일의 교체가 한꺼번에 이뤄지지 않아 공격자가 계속 쓸 수 있었다. 이 사이트의 결론 = 교훈은 액션을 태그가 아니라 커밋 ID(SHA)로 고정하라는 것만이 아니다. SHA로 고정한 액션도 내부에서 다른 구성 요소를 태그로 부를 수 있고, 그 경로로 악성 버전이 들어온다. 유출된 인증 정보는 한꺼번에 교체해야 하며, 그렇지 않으면 공격자가 계속 쓸 수 있다. 스캐너는 배포용 비밀값이 없는 잡에서 돌린다.
Vercel 보안 사고 (2026년 4월): 환경 변수가 노출됐을 때 개발자가 할 일
2026년 4월 19일 Vercel은 일부 내부 시스템에 대한 무단 접근을 공개했다. Vercel에 따르면 직원이 쓰던 서드파티 AI 도구가 침해되면서 공격자가 그 직원의 Google Workspace 계정을 탈취했고, 그 직원의 Vercel 계정과 Vercel 환경에 들어가, 일부 제한된 고객의 '민감'으로 표시되지 않은 환경 변수를 열거하고 복호화했다. Vercel은 영향받은 고객에게 직접 연락했고, 자사가 배포한 npm 패키지는 침해되지 않았음을 확인했다. 이 사이트의 결론 = 변수의 유출 여부는 그 분류, 즉 읽기 가능(저장 후 값을 다시 표시할 수 있음)인지 쓰기 전용(덮어쓸 수는 있지만 표시할 수 없음)인지에 달려 있었다. 다시 읽을 일이 없는 비밀값은 모두 쓰기 전용(현재 Vercel의 Secret)으로 저장하고, 직원이 OAuth(외부 앱이 회사 계정에 접근하도록 허용하는 방식)로 회사 계정에 연결하는 AI 도구도 의존성처럼 목록으로 관리한다.
npm 공급망 웜: 설치 순간에 자격 증명이 털리는 구조와 방어법
의존성 하나를 추가하는 것은 남이 쓴 코드를 내 권한으로 실행하는 일이므로, 방어는 설치 시점에 해야 합니다. 본 사이트의 견해: 이번 공격은 서명과 출처 증명을 통과했으므로 이것을 신뢰의 근거로 삼을 수 없습니다. 효과가 있는 것은 설치 스크립트를 기본으로 끄고, 새 버전은 며칠 기다렸다가 채택하고, 토큰을 짧은 수명과 좁은 범위로 유지하는 것입니다. 감염이 의심되면 자격 증명을 폐기하는 순서도 중요합니다.
gitleaks로 커밋 전에 시크릿을 막아라: push 전에 API 키 유출 잡기
시크릿은 '유출된 뒤 삭제'할 수 없다. 한 번 커밋되면 Git 히스토리에 남고, push되면 유출된 것으로 다뤄야 한다 — 키를 폐기/교체해야 한다. gitleaks는 정규식/엔트로피로 저장소 전체와 커밋 히스토리를 스캔해 API 키, 개인 키, 토큰을 찾는 무료 도구다. 방어의 핵심은 두 단계의 점검: push 전에 로컬에서 막는 pre-commit 훅과, 빠져나간 것을 잡는 CI/cron. .gitignore는 새 추적만 막을 뿐 탐지하지 못하므로, 스캐너가 여전히 필요하다.
비밀번호 관리자는 안전한가? 작동 원리, 클라우드 vs 로컬, 선택법
비밀번호 관리자는 서비스마다 강력하고 서로 다른 비밀번호를 쓰도록 돕는 도구입니다. 제로 지식 암호화는 제공자에서 암호화된 데이터가 유출되더라도 내용을 보호하기 위한 설계이지만, 안전성은 마스터 비밀번호 강도, 암호화 설정, 기기 보안에도 달려 있습니다. MFA로 무단 로그인을 방지하고 용도에 따라 클라우드나 로컬을 고르세요.
공개 디렉터리에 시크릿 파일을 남겨두지 않았나요? 웹루트를 점검하라
웹루트의 모든 것은 누구나 URL로 가져갈 수 있습니다. 남겨진 토큰/자격증명 JSON, .env, 백업은 즉각 노출을 뜻하며 — 공유 템플릿에서 왔다면 모든 사이트가 같은 파일을 갖습니다. 해법: 공개 디렉터리엔 공개해도 되는 것만, 시크릿은 웹루트 밖에 권한 600으로, 하나 찾으면 모든 사이트와 호스트를 점검하기.
1인 개발자와 소규모 운영자를 위한 보안 베이스라인: 표준 통제를 우선순위 순으로
베이스라인은 '모두 똑같이 중요'가 아닙니다. 본 사이트의 우선순위: 1) 관리자 계정·도메인·이메일(MFA), 2) 시크릿과 코드, 3) 앱 자체, 4) 패치·탐지·복구. 시간이 유한할 때 위에서부터 채우세요. 심각한 침해는 대부분 새로운 공격이 아니라 이 기본 통제의 빈틈에서 옵니다.
보안 인벤토리: 서버 여러 대를 운영하는 사람이 놓치는 7가지 점검
1인/소규모 운영자에게 사고는 통제의 부재보다 추적되지 않은 상태에서 옵니다. 경계는 키를 쥔 PC입니다. 다른 계정을 복구할 수 있는 계정 순서로(이메일 먼저) 2FA의 우선순위를 정하고, 어느 SSH 키가 어느 서버를 여는지 목록으로 만들어 중복·미사용 키와 남은 등록을 삭제하고, 클라우드의 평문 비밀번호를 제거하고, 한 번에 하나씩 되돌릴 수 있게 조치하고, 시크릿을 대장에 두지 마세요. 도구 추가 전에 인벤토리부터.
자체 호스팅 Git vs GitHub: 실제로 어느 쪽이 더 안전한가?
Git을 자체 호스팅한다고 '더 안전'해지지 않습니다 — 위험을 옮길 뿐입니다. 실수로 인한 공개 노출 부류는 사라지지만, 서버 패치·백업·커밋 전 시크릿 탐지가 당신에게 넘어옵니다. 그 일을 계속 해낸다면 옳은 선택이고, 방치하면 GitHub보다 나쁩니다. 본 사이트의 견해: 자체 호스팅은 보상 통제와 묶일 때만 작동합니다.
비밀번호를 Google Drive에 저장하면 안전한가? 제대로 보관하는 법
비밀번호를 평문 Google 문서/시트에 두는 것은 위험합니다: Google 계정 하나가 모든 비밀번호의 단일 실패 지점이 됩니다 — 계정 탈취, 악성 연결 앱, 피싱이 한꺼번에 누출시킵니다. 가장 안전한 선택은 전용 비밀번호 관리자입니다(동기화해도 내용은 암호화). Drive를 꼭 써야 한다면 암호화된 금고 파일만 저장하고 계정에 피싱 저항 MFA를 거세요.
Codecov 유출 사고(2021) — CI 도구가 변조되어 비밀 정보가 새어 나갔을 때
신뢰하던 CI 도구(curl|bash로 실행되는 Bash Uploader)가 상위에서 변조되었습니다. 여러분의 코드는 손대지 않았기 때문에 약 2개월간 알아채지 못한 채 CI 비밀 정보가 유출되었고, 체크섬 검사가 이를 잡아냈습니다. 여러분의 CI에서는 가져온 산출물 검증, 최소 권한 비밀 정보, 로테이션, 이그레스 모니터링이 핵심입니다.