개인 블로그와 기록 앱도 계정, 데이터, 배포 자격 증명을 다룬다. 기능을 빨리 만드는 데 집중하다 보면 어느 서비스에 어떤 토큰을 부여했는지, 오래된 의존성이 운영 환경에도 남아 있는지 확인하는 일이 뒤로 밀린다. AI로 코드를 작성해도 운영자가 확인할 항목은 사라지지 않는다.
Anthropic은 AI가 공격자의 취약점 분석을 돕는 환경에서 패치 지연을 줄이고 방어 절차를 준비하라고 권고했다. 나는 이 권고를 작은 서비스를 운영하는 관점에서 읽었다. 아래 내용은 적용할 절차와 시험 설계다. 기존 원고에 있던 “SAST를 도입해 수백 개 경고를 처리했다”, “보안 검사를 이미 적용했다” 같은 검증되지 않은 도입 성과는 사용하지 않는다. Anthropic의 보안 프로그램 준비 권고
자산 목록에는 내가 고칠 수 있는 범위를 적는다
취약점 보고서를 받았을 때 패키지 이름만 알아서는 대응하기 어렵다. 어떤 버전을 운영하는지, 외부에서 접근할 수 있는지, 누가 바꿀 권한을 갖는지 알아야 한다. 처음 만드는 목록에는 서비스 이름, 실행 환경, 데이터 종류, 배포 담당, 복원 방법을 넣겠다. 관리형 서비스의 내부 구성까지 내가 운영하는 것처럼 적지 않는다.
예를 들어 웹 호스팅 업체가 운영하는 기반 서버와 내가 배포하는 애플리케이션 의존성은 책임 범위가 다르다. 플랫폼 내부 패치는 공급자의 공지와 대응을 확인하고, 앱의 라이브러리 업데이트는 내 테스트와 배포 절차로 처리한다. 공급자가 고친 기반 서버와 오래된 앱 패키지를 혼동하면 수정 완료를 잘못 보고할 수 있다.
데이터 목록도 간단히 만든다. 공개 게시물, 비공개 초안, 사용자 식별자, 운동 기록처럼 구분한다. 공개 페이지의 목록 API가 초안을 함께 반환하거나 다른 사용자 기록을 읽을 수 있다면 단순 화면 오류보다 위험하다. 백엔드에 관리자 자격 증명을 넣는 경우에는 브라우저 번들로 넘어가지 않는지도 검사한다.
| 대상 | 먼저 확인할 내용 | 완료 증거 |
|---|---|---|
| 웹 애플리케이션 | 운영 버전과 외부 입력 경로 | 배포 식별자·의존성 목록 |
| 데이터베이스 | 사용자별 읽기·쓰기 범위 | 권한 테스트 결과 |
| 자동화 작업 | 토큰 권한과 실행 주체 | 승인된 권한 목록 |
| 파일·이미지 저장소 | 공개 범위와 업로드 제한 | 비공개 샘플 접근 거부 |
| 계정과 복구 수단 | 관리자 보호·복원 접근 | 복구 절차 점검 기록 |
목록을 만드는 동안 실제 비밀값을 문서에 복사하지 않는다. 토큰 이름과 용도, 보관 위치의 종류, 교체 담당만 기록한다. 작업 로그나 캡처에 비밀값이 들어갔다면 문서를 지우는 것만으로 대응이 끝나지 않는다. 노출된 자격 증명을 폐기·재발급하고 사용 기록을 확인할 절차가 필요하다.
패치 순서는 악용 사실과 서비스 영향을 함께 본다
CISA KEV는 실제 악용 사실이 확인된 취약점을 모은 자료다. 목록에 내 제품과 버전이 해당한다면 어떤 실행 경로에 영향을 주는지 우선 확인할 이유가 있다. 다만 CVE가 있다는 사실만으로 내 서비스가 침해됐다고 단정하지 않는다. 제품 매칭, 영향을 받는 버전, 노출 경로를 대조한다. CISA KEV 카탈로그
FIRST의 EPSS는 공개된 CVE가 앞으로 30일 안에 실제 환경에서 악용될 확률을 추정한다. 이는 내 회사가 침해될 확률이나 피해 금액을 뜻하지 않는다. 점수가 낮아도 이미 악용 증거가 있거나 핵심 인증 경로에 영향을 준다면 우선순위를 낮출 근거로 쓰기 어렵다. 점수와 백분위도 다른 값이므로 혼동하지 않는다. FIRST EPSS
원고의 이전 예제는 EPSS 0.5를 기준으로 분류했다. 이 값을 보편적인 안전선처럼 사용할 근거는 없다. 팀은 처리할 수 있는 작업량, 자산 중요도, 외부 노출을 보고 기준을 정하고 실제 놓친 위험이 있는지 돌아봐야 한다. 점수가 없다는 경우도 0으로 바꾸지 말고 정보 미확인으로 남긴다.
내가 제안하는 분류 절차는 다음과 같다. 운영 코드가 아닌 판단 순서 예시다. 자동화하더라도 최종 긴급도와 변경 승인 책임은 운영자에게 남는다.
제품과 버전이 해당하지 않음 → 근거를 남기고 대상에서 제외
영향 여부를 확인하지 못함 → 확인 필요로 분리
영향 있음 + 악용 증거 또는 심각한 외부 노출 → 긴급 대응 검토
영향 있음 + 패치 제공 → 시험·배포 담당과 완료 시점 지정
패치 없음 → 접근 제한 등 임시 대응과 재검토 시점 기록
취약점을 늦게 고치는 위험과 서둘러 업데이트해서 서비스를 중단시키는 위험을 함께 다뤄야 한다. 긴급한 경우에도 수정 전 버전과 복원 절차를 기록하고 핵심 기능을 확인한다. 공급자가 패치를 제공하지 않았거나 업데이트에 호환성 문제가 있다면 완화 조치를 정하고 남은 노출을 추적한다. 임시 조치를 영구적인 해결로 기록하지 않는다.
취약점 보고서에는 재현 근거가 필요하다
AI가 보고서를 많이 작성하면 검토할 일도 늘어난다. 실제 문제와 가능성만 제기한 경고를 구별하지 못하면 담당자가 제목만 보고 긴급도를 정하게 된다. 취약점 티켓에는 영향을 받는 파일·버전, 입력 경로, 재현 조건, 예상 피해, 제안 수정과 검사 방법을 넣는 형식이 좋다.
모델에게 “이 코드는 안전한가”라고 묻는 요청은 범위가 넓다. 내가 확인하려는 동작을 좁혀주는 편이 낫다. 예를 들어 “다른 사용자의 기록 ID를 넣어도 서버가 요청자 소유인지 검사하는가”라고 묻고, 인증 주체를 얻는 위치와 DB 질의 조건을 근거로 제시하게 한다. 추측한 파일이나 존재하지 않는 함수는 근거로 받지 않는다.
보고서에 공격 단계가 등장하더라도 시험 범위는 내가 소유하거나 명시적으로 허가받은 시스템으로 한정한다. 운영 사용자 데이터로 재현하지 않고 별도 테스트 계정과 가상 기록을 사용한다. 외부 서비스를 스캔하거나 실제 이용자의 데이터를 읽는 행위를 보안 점검이라는 이유로 확대하지 않는다.
AI가 소스 코드를 읽을 때 데이터 반출 범위를 확인한다. 비밀정보, 고객 자료, 전체 로그를 외부 모델에 보내지 않고 필요한 코드와 정제한 오류만 제공한다. 보안 경고를 설명하는 문서도 신뢰하지 않는 입력이다. 문서에 적힌 셸 명령이나 URL을 자동으로 실행하게 두지 않는다.
중복 보고서는 CVE 번호뿐 아니라 원인과 영향 경로로 묶는다. 같은 원인으로 여러 화면에서 경고가 나와도 수정은 공통 접근 제어 한 곳에서 할 수 있다. 반대로 같은 라이브러리 이름이 나와도 다른 버전이나 다른 배포를 사용한다면 한 번 고쳤다고 모두 해결한 것으로 처리하지 않는다.
AI가 만든 수정은 실패하는 테스트에서 출발한다
보안 수정 전에는 문제가 있는 동작을 보여주는 테스트를 먼저 마련한다. 권한이 없는 테스트 계정이 다른 계정의 가상 기록을 요청했을 때 거부해야 한다는 식이다. 수정 후에는 그 시험이 통과하는지 확인하고 정상 사용자의 작업도 유지되는지 검사한다. 모델이 “수정했다”고 말하는 것은 테스트 결과가 아니다.
OWASP ASVS는 애플리케이션 보안 검증 요구사항을 정리한다. 내가 운영하는 기능에 맞는 요구사항을 골라 점검표로 쓰는 것이 목적이다. AI 스캐너를 한 번 실행했다고 ASVS를 충족했다거나 제품 인증을 받았다고 설명하지 않는다. 버전과 적용 범위를 기록해야 다음 검토에서 무엇을 확인했는지 알 수 있다. OWASP ASVS
작은 기록 앱이라면 로그인하지 않은 요청, 다른 계정의 기록 접근, 허용하지 않은 필드 변경, 지나치게 큰 입력을 먼저 시험하겠다. 블로그에는 비공개 글 노출, HTML 처리, 업로드 파일, 관리자 기능의 서버 측 권한을 추가한다. 화면에서 버튼을 숨기는 것과 서버가 요청을 거부하는 것은 별도 검사다.
의존성 검사도 운영과 개발 환경을 구분한다. 개발 전용 도구가 만드는 경고를 운영 노출과 동일하게 처리하면 우선순위가 흔들린다. 그렇다고 개발 의존성은 무조건 무해하다고 보면 안 된다. 빌드 과정에서 실행되는 도구와 배포 자격 증명이 같은 환경에 있는지 살펴야 한다.
CI에는 비밀정보 탐지, 의존성 검사, 정적 분석과 중요한 회귀 테스트를 단계별로 추가하는 설계를 제안한다. 처음부터 경고를 모두 병합 차단으로 만들기보다 재현 가능하고 영향이 확인된 항목을 우선 차단한다. 제외한 경고에는 이유와 재검토 시점을 남긴다. 아무 근거 없이 검사 전체를 끄는 방식은 오류를 숨길 뿐이다.
NIST SSDF도 보안 활동을 개발 생명주기에 통합하는 틀을 제공한다. 내 적용 범위에서는 누가 수정하고 무엇으로 검증하며 어떤 배포에 들어갔는지를 연결하는 데 사용하겠다. 문서 이름을 나열하는 것보다 수정 티켓 하나가 운영 확인까지 이어지는지 보는 편이 실용적이다. NIST SSDF 1.1
권한은 실행 주체와 데이터 경로로 나눈다
빌드 작업, 운영 애플리케이션, 글 발행 자동화가 같은 관리자 토큰을 사용할 필요는 없다. 각 작업에 필요한 범위를 따로 정하면 한 작업이 잘못돼도 다른 데이터까지 영향을 주는 경로를 줄인다. 사용하지 않는 자격 증명을 회수하고 교체 가능한 토큰의 만료·재발급 절차를 기록한다.
모든 작은 서비스에 직접 mTLS나 하드웨어 ID 체계를 구축하는 방식부터 권하고 싶지는 않다. 관리형 플랫폼의 인증·권한·네트워크 기능을 먼저 이해하고 내가 설정할 수 있는 경계를 확인해야 한다. 구체적인 실행 환경 없이 일반 YAML을 붙여넣어 네트워크 정책이 적용됐다고 생각하는 것은 위험하다. 기존 원고의 가상 정책은 실제 제품 설정으로 사용할 수 없으므로 이번 글에서는 판단 항목으로 바꿨다.
검사할 질문은 구체적이어야 한다. 빌드 과정에서 운영 DB의 전체 데이터를 읽을 수 있는가. 읽기 전용 보고 작업이 게시물 삭제 기능도 호출할 수 있는가. 메시지를 받은 에이전트가 외부 문서의 지시로 토큰을 전송할 수 있는가. 답을 설정과 테스트로 확인하고 불필요한 경로를 닫는다.
관리자 계정에는 사용하는 공급자가 지원하는 강한 인증 수단을 적용한다. 복구 코드와 보조 접근 수단도 안전하게 보관한다. 보안을 강화한 뒤 담당자 자신도 접근하지 못하는 상황이 생기면 운영 중단으로 이어진다. 복구 시험은 비밀값을 공유 채팅에 올리지 않는 절차 안에서 진행한다.
이상 징후가 생겼을 때 할 일을 한 장으로 만든다
침해가 의심되는 순간에 계정과 배포 구조를 처음 조사하면 시간이 걸린다. 내가 준비할 대응 메모에는 서비스 담당, 공급자 연락 경로, 배포 중단 방법, 자격 증명 폐기 절차, 로그 보존 위치를 적겠다. 개별 법적 신고 의무와 기한은 서비스·데이터·관할에 따라 별도로 확인하며 이 글에서 일괄 기한을 제시하지 않는다.
사고 대응에서는 원인과 영향 범위를 확인하기 전에 데이터를 대량 삭제하지 않는다. 로그와 시점 기록을 보존하고 노출된 자격 증명의 사용을 중단한다. 필요한 격리와 서비스 중단은 영향 범위를 확인해 수행한다. 자동화에는 확인되지 않은 의심만으로 운영 DB를 지우는 권한을 부여하지 않는다.
복원은 백업 파일이 있다는 확인에서 끝나지 않는다. 시험 환경에 복원한 뒤 핵심 데이터가 읽히는지, 접근 제어와 설정도 돌아왔는지 확인한다. 데이터가 복원됐어도 노출된 토큰을 그대로 쓰면 같은 문제가 반복될 수 있다. 어떤 상태로 돌아갈지와 어떤 비밀정보를 다시 발급할지는 구분한다.
운영 사고가 아니라도 작은 복구 시험을 할 수 있다. 비밀정보가 없는 샘플 기록과 시험 배포로 되돌리기 절차를 연습하고 결과를 남긴다. 실제 서비스 이용자에게 영향을 주는 조작은 승인한 범위에서만 수행한다. 시험 날짜, 복구에 필요한 접근, 실패한 단계를 기록하면 다음 점검에서 개선할 대상을 찾기 쉽다.
첫 적용 범위는 패치 한 건과 권한 시험 하나로 잡는다
내가 시작할 단위는 새 보안 제품 도입보다 작다. 운영 자산 목록을 만든 뒤 의존성 경고 한 건을 골라 영향 확인, 수정, 테스트, 배포, 운영 확인까지 연결한다. 그 과정에서 버전 정보나 담당자를 찾느라 막힌 지점을 기록한다. 자동화는 이 병목을 줄이는 데 사용하겠다.
다음으로 사용자별 데이터 접근 시험 하나를 작성한다. 정상 계정은 자신의 가상 기록을 읽고 다른 계정은 거부되는지 확인한다. 이 시험을 CI에 넣으면 기능을 바꿀 때도 같은 경계를 다시 확인할 수 있다. 모델이 만든 코드의 양보다 재현 가능한 검사 하나를 남기는 편이 내 서비스에는 더 직접적인 개선이다.
완료 지표에는 발견한 경고 수만 넣지 않는다. 영향 확인까지 걸린 시간, 수정 후 운영 반영 여부, 재발 방지 테스트, 복구 시험 결과를 함께 기록한다. 경고가 줄었어도 검사를 껐기 때문이면 개선이 아니다. AI는 자료 정리와 후보 수정에 활용하고, 어떤 위험을 받아들일지는 운영자가 근거를 남겨 결정한다.