AI 지원 빌더(AI-assisted builders)는 주말 만에 프롬프트에서 프로덕션(production) 단계까지 아이디어를 구현할 수 있습니다. 이러한 속도는 유용하지만, 누군가가 배포 설정, 브라우저에 노출되는 비밀 정보(secrets), 권한 경계(authorization boundaries), 그리고 복구 계획(recovery plans)을 검토하는 프로세스를 압축시켜 버리기도 합니다.

공개 보안 스캐너(public security scanner)는 이 문제에 대한 좋은 첫 번째 단계입니다. 하지만 오해하기도 쉽습니다. 깨끗한 공개 스캔 결과가 애플리케이션이 안전하다는 것을 의미하지는 않으며, 경고가 나타난다고 해서 항상 취약점(vulnerability)이 공격 가능한 것은 아닙니다.

유용한 질문은 "스캐너가 내 앱을 통과시켰는가?"가 아니라, "이 스캐너가 실제로 관찰할 수 있는 증거는 무엇인가?"입니다.

레이어 1: 공개 배포 표면 (the public deployment surface)

수동적 스캐너(passive scanner)는 일반 방문자가 접근할 수 있는 것과 동일한 리소스를 요청할 수 있습니다. 스캔 범위에 따라 다음 사항을 검사할 수 있습니다:

• Content-Security-Policy 및 Strict-Transport-Security와 같은 HTTP 보안 헤더
• HTTPS 동작 및 리다이렉트(redirect) 일관성
• 자격 증명 형태의 문자열이 포함된 공개 JavaScript 번들(bundles)
• 원본 소스 구조를 노출하는 공개 소스 맵(source maps)
• 환경 파일(environment files) 또는 리포지토리 메타데이터와 같은 일반적인 민감한 경로
• 쿠키(Cookie) 속성 및 기타 응답 수준의 배포 신호

이러한 점검은 당신이 배포하려고 의도한 설정이 아니라, 실제로 배포된 결과를 테스트하기 때문에 가치가 있습니다.

예를 들어, 리포지토리에는 CSP 설정이 포함되어 있지만 CDN 응답에는 포함되어 있지 않을 수 있습니다. 소스 맵(source map)이 한 빌드 구성에서는 비활성화되어 있지만 프로덕션(production) 환경에는 여전히 나타날 수 있습니다. 대부분의 코드 경로에서는 서버에 키(key)가 안전하게 저장되어 있지만, 하나의 클라이언트 번들(client bundle)에 실수로 권한이 있는 토큰(privileged token)이 포함될 수 있습니다.

배포된 표면은 이러한 실수들이 관찰 가능해지는 지점입니다.

레이어 2: 소스 코드 리뷰 (source-code review)

공개 URL은 애플리케이션 뒤에 숨겨진 모든 제어 요소를 드러낼 수 없습니다. 소스 리뷰 또는 SAST(정적 애플리케이션 보안 테스트)는 일반적인 응답에는 절대 나타나지 않는 코드 경로, 설정, 데이터 흐름 및 위험한 구현 패턴을 검사할 수 있습니다.

이 단계에서 다음과 같은 질문에 답할 수 있습니다:

• 서버에서 권한 부여 (Authorization)가 강제되고 있는가?
• 사용자가 객체 ID (Object ID)를 변경하여 다른 테넌트 (Tenant)의 데이터를 읽을 수 있는가?
• 데이터베이스 쿼리 (Database queries)가 매개변수화 (Parameterized)되어 있는가?
• 업로드된 파일이 저장되기 전에 검증 (Validated)되는가?
• 관리자 작업 (Administrative actions) 시 역할 (Roles)을 일관되게 확인하는가?

공개 스캐닝 (Public scanning)과 소스 리뷰 (Source review)는 상호 보완적입니다. 하나는 실제로 배포된 것을 확인하고, 다른 하나는 외부에서 보이지 않을 수 있는 로직을 확인합니다.

레이어 3: 의존성 및 공급망 (Dependencies and supply chain)

의존성 스캐너 (Dependency scanners)는 또 다른 질문에 답합니다. 이들은 패키지 매니페스트 (Package manifests), 락파일 (Lockfiles), 컨테이너 (Containers) 또는 소프트웨어 자재 명세서 (SBOM, Software Bills of Materials)를 알려진 취약점 데이터와 비교합니다.

이를 통해 취약한 라이브러리 버전을 식별할 수 있지만, 귀하의 커스텀 권한 부여 (Custom authorization)가 올바른지, 또는 CDN이 예상한 헤더 (Headers)를 제공하고 있는지는 증명할 수 없습니다.

AI로 구축된 애플리케이션의 경우, 의존성 스캐닝 (Dependency scanning)을 새로 도입된 패키지에 대한 수동 리뷰 (Manual review)와 결합하는 것이 가치가 있습니다. 생성된 코드 (Generated code)는 불필요한 라이브러리, 오래된 예제, 또는 이름이 검증되지 않은 패키지를 추가할 수 있습니다.

비밀 정보 스캐닝 (Secret scanning)에 관한 GitHub의 문서와 OWASP AI를 활용한 보안 코딩 치트 시트 (OWASP Secure Coding with AI Cheat Sheet)는 유용한 시작점입니다.

레이어 4: 인증된 평가 (Authenticated assessment)

가장 깊은 애플리케이션 위험은 종종 테스트 계정과 합의된 범위 (Scope)를 필요로 합니다.

인증된 평가 (Authenticated assessment)는 사용자 역할 (User roles), 테넌트 경계 (Tenant boundaries), 보호된 워크플로우 (Protected workflows), 결제 상태 (Payment states) 및 비즈니스 로직 (Business-logic) 동작을 비교할 수 있습니다. 공개 스캐너 (Public scanner)는 명시적인 권한 부여 없이 로그인을 시도하거나, 양식을 제출하거나, 액세스 제어 (Access controls)를 우회하거나, 익스플로잇 (Exploits)을 시뮬레이션해서는 안 됩니다.

애플리케이션이 결제, 건강 정보, 개인 고객 데이터 또는 특권 워크플로우 (Privileged workflows)를 처리한다면, 이 레이어는 선택 사항이 아닙니다.

주의 깊은 해석이 필요한 세 가지 결과

“Content-Security-Policy가 준수되지 않았습니다”

이는 검사된 응답에서 중요한 브라우저 측 완화 조치 (mitigation)가 누락되었음을 의미합니다. 이것이 교차 사이트 스크립팅 (Cross-Site Scripting, XSS)이 존재한다는 것을 증명하는 것은 아닙니다.

다음 단계는 필요한 스크립트, 스타일, 프레임 및 연결 목록을 작성한 다음, 강제 적용 (enforcement) 전에 보고 전용 모드 (report-only mode)로 제한적인 정책을 도입하는 것입니다. Mozilla의 HTTP Observatory는 헤더 상태 (header posture)를 검토하는 데 유용합니다.

“소스 맵 (source map)에 공개적으로 접근할 수 있습니다”

프로덕션 소스 맵은 원래의 파일 이름, 소스 구조 및 구현 세부 정보를 드러낼 수 있습니다. 이는 노출 신호 (exposure signal)이지, 자동으로 보안 취약점 (security vulnerability)인 것은 아닙니다.

만약 해당 맵이 공개적으로 필요하지 않다면, 이를 비활성화하거나 에러 모니터링 서비스에 비공개로 업로드하십시오.

“자격 증명 형태의 문자열이 발견되었습니다”

일부 브라우저 키는 의도적으로 공개되어 있습니다. 하지만 서비스 역할 토큰 (service-role tokens) 및 개인 자격 증명 (private credentials)을 포함한 다른 것들은 그렇지 않습니다.

스캐너는 해당 패턴을 식별하고 마스킹 (redact)할 수 있지만, 제공업체와 권한 수준 (privilege level)을 확인하는 것은 여전히 사람의 몫입니다. 만약 자격 증명이 비공개라면, 이를 교체 (rotate)하고 서버 측 경계 (server-side boundary) 뒤로 이동시키십시오.

실질적인 출시 전 시퀀스 (pre-launch sequence)

AI로 구축된 소규모 애플리케이션의 경우, 합리적인 최소 프로세스는 다음과 같습니다:

1. 배포된 URL에 대해 수동적 검사 (passive check)를 실행합니다.
2. 저장소 (repository)를 검토하여 비밀 정보 (secrets), 권한 부여 (authorization), 입력 유효성 검사 (input validation) 및 안전하지 않은 기본값 (unsafe defaults)을 확인합니다.
3. 매니페스트 (manifests) 및 락파일 (lockfiles)을 스캔하여 알려진 취약한 의존성 (vulnerable dependencies)을 찾습니다.
4. 별도의 낮은 권한을 가진 테스트 계정으로 데이터베이스 정책을 검증합니다.
5. 깨끗한 브라우저와 모바일 기기에서 프로덕션 빌드를 테스트합니다.
6. 무엇이 검사되었고 무엇이 범위 외 (outside scope)로 남아 있는지 기록합니다.

저는 첫 번째 단계의 무료, 무계정 구현체로 Check My Vibe를 만들었습니다. 이 도구는 의도적으로 제한된 공개 표면을 검사하며, 자동화된 결과를 36개 항목의 수동 체크리스트와 분리하여 유지합니다. 이 도구는 소스 검토, 인증된 테스트 또는 전문적인 평가를 대체한다고 주장하지 않습니다.

그 경계가 바로 제가 빌더(builders)들이 얻어가길 바라는 핵심입니다. 보안 도구는 그 증거와 한계가 명확할 때 가장 유용합니다.

스캐너는 시작 신호일 뿐입니다. 보안이 확보된 릴리스(release)를 위해서는 스캐너가 볼 수 없는 계층 전반에 걸쳐 여전히 인간의 판단이 필요합니다.