45/ 50
＋ 노출도 중심 우선순위가 간결하고 균형 잡혔다.
－ node-fetch를 SSRF로 연결한 부분은 정확성이 낮다.
보안 경고 분석 프롬프트
저장소의 GHAS 경고를 입력하면 의존성·베이스 이미지 원인, 반복 취약점 패턴, 심각도와 노출도 기준 우선순위를 분석합니다.
| 분류 | 개발 › 배포·운영 |
|---|---|
| 태그 | 분석검토개발자코드 |
this is for repo Analyze code scanning security issues and dependency updates if vulnerable Analyze GHAS alerts across repositories Identify dependency vs base image root causes Detect repeated vulnerability patterns Prioritize remediation based on severity and exposure
어떤 프롬프트인가
여러 저장소의 코드 스캔 보안 이슈를 분류하는 데 쓰는 프롬프트다. 수정 코드보다 원인 구분과 취약점 패턴, 우선순위 산정에 초점이 있다.
모델 비교
ChatGPT가 정확성·간결성·요구 충족의 균형이 가장 좋다. Claude는 기술적으로 가장 깊지만 과도하게 길고 일부 노출 판단이 단정적이며, Gemini는 유용하나 추정과 장황함이 두드러진다.
43/ 50
＋ CVE 불일치를 짚고 검증 기준까지 가장 정밀하다.
－ OpenSSL 위험을 낮다고 단정하며 답이 지나치게 길다.
37/ 50
＋ 원인 분류와 항목별 조치가 폭넓고 구체적이다.
－ 근거 없는 결제 환경 가정과 과도한 분량이 아쉽다.
| 기준 | ChatGPT | Claude | Gemini | 앞선 모델 |
|---|---|---|---|---|
| 지시 준수 | 10 | 9 | 9 | ChatGPT +11% |
| 정확성 | 8 | 9 | 6 | Claude +13% |
| 구체성 | 9 | 10 | 8 | Claude +11% |
| 구성·가독성 | 9 | 9 | 8 | 동점 |
| 분량 적정성 | 9 | 6 | 6 | ChatGPT +50% |
gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-24). 측정값이 아니라 AI 심사 결과입니다.
답 전문 보기
같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.
[붙여 넣은 자료] 레포: witimcorp/payment-api (GitHub, private) 현재 열려있는 GHAS 알림 목록이야: - CodeQL: SQL Injection 가능성 (severity: high) — src/db/queryBuilder.ts:142, 사용자 입력값을 그대로 문자열 결합해서 쿼리 생성 - Dependabot: lodash 4.17.15 → 4.17.21 업데이트 필요 (Prototype Pollution, CVE-2021-23337, severity: high) - Dependabot: node-fetch 2.6.0 → 2.6.7 업데이트 필요 (severity: moderate) - Dependabot: 베이스 이미지 node:18-alpine에 포함된 openssl 패키지 취약점 (CVE-2023-0286, severity: critical) - CodeQL: 하드코딩된 API 키 노출 가능성 — src/config/legacy.ts:8 지난 3개월 alert 히스토리를 보면 lodash, node-fetch 관련 알림이 반복적으로 뜨고 있어. 심각도랑 실제 노출 가능성 기준으로 우선순위 매겨줘.
우선순위
| 순위 | 알림 | 우선도 | 판단 |
|---|---|---|---|
| 1 | 하드코딩된 API 키 — src/config/legacy.ts:8 |
긴급 | 실제 유효한 키라면 코드 공개 여부와 무관하게 탈취 가능성이 있으며, 저장소·커밋·빌드 로그에 남을 수 있음 |
| 2 | SQL Injection — src/db/queryBuilder.ts:142 |
긴급 | 사용자 입력이 문자열 결합으로 SQL에 포함되면 인증 우회, 데이터 유출·변조가 가능함. 외부 요청 경로에 노출됐을 가능성이 높음 |
| 3 | node:18-alpine의 OpenSSL 취약점, CVE-2023-0286 |
매우 높음 | 애플리케이션 코드가 아니라 베이스 이미지와 OS 패키지 문제. 인터넷 노출 서비스의 TLS/암호화 기능이 영향을 받는지 확인 후 즉시 이미지 교체·재배포 |
| 4 | lodash 4.17.15 → 4.17.21, CVE-2021-23337 |
높음 | 알려진 Prototype Pollution 취약점. 사용자 입력이 lodash 취약 함수까지 도달하는지와 런타임 의존성인지 확인. 반복 발생하므로 구조적 의존성 관리 문제로 판단 |
| 5 | node-fetch 2.6.0 → 2.6.7 |
중간 | lodash 및 OpenSSL보다 즉시 영향은 낮지만, 외부 URL·리다이렉트·사용자 제어 요청을 처리한다면 SSRF 등 실제 노출 가능성을 추가 평가해야 함 |
즉시 조치
legacy.ts의 키가 실제 키라면 즉시 폐기·재발급하고 사용처의 접근 로그를 확인합니다. 이후 환경변수 또는 Secret Manager로 이전하고 Git 이력에 키가 남아 있다면 이력 정리도 검토해야 합니다.- SQL을 파라미터 바인딩 또는 prepared statement 방식으로 변경합니다. 테이블명·컬럼명처럼 바인딩할 수 없는 값은 허용 목록 방식으로 제한해야 합니다.
node:18-alpine을 최신 패치 버전의 명시적 이미지 태그로 교체하고, 이미지 내부 OpenSSL 패키지를 업데이트한 뒤 새 이미지로 재배포합니다. 단순히 애플리케이션 패키지만 업데이트해서는 해결되지 않습니다.- lodash와 node-fetch를 lockfile까지 포함해 업데이트하고, 직접 의존성인지 transitive dependency인지 확인합니다.
- CI에서
npm audit만 의존하지 말고 Dependabot PR 자동 병합 기준, lockfile 재생성, 정기 베이스 이미지 rebuild를 운영합니다.
반복 패턴과 근본 원인
- lodash·node-fetch 알림 반복: 업데이트 자체보다 업데이트가 지속적으로 반영되지 않는 운영 문제가 핵심입니다. 오래된 lockfile, Dependabot PR 미처리, 여러 manifest의 버전 불일치, 이미지 내부에 별도 설치된 Node 의존성을 확인해야 합니다.
- OpenSSL 알림: 애플리케이션 의존성과 무관한 베이스 이미지 수명주기 문제입니다.
node:18-alpine같은 이동 태그 대신 패치 버전을 고정하고 정기적으로 이미지를 재빌드해야 합니다. - SQL Injection: 입력 검증만 추가하는 것으로는 부족하며 쿼리 생성 방식을 구조적으로 변경해야 합니다.
- 하드코딩 키: 비밀정보가 코드에 들어가는 개발·배포 프로세스 문제입니다. secret scanning 차단 규칙과 키 로테이션 절차가 필요합니다.
외부 노출 가능성과 실제 자격증명 유효성을 반영하면, critical/high 라벨만 기계적으로 따르기보다 API 키 로테이션과 SQL Injection 수정부터 즉시 병행하고, 그 다음 베이스 이미지와 반복 Dependabot 의존성을 정리하는 순서가 적절합니다.
현재 제공된 정보는 witimcorp/payment-api 한 저장소의 알림이므로, 여러 저장소 간 GHAS 공통 패턴까지 분석하려면 각 저장소의 alert 목록·경로·노출 서비스 여부가 추가로 필요합니다.
같은 분류의 프롬프트
| 프로덕션 AI 에이전트 설계 프롬프트 | |
| AI 에이전트 보안 점검 프롬프트 | |
| AI 제공자 요금 조사 프롬프트 | |
| 상자 탈출 AI 역할을 맡기는 프롬프트 | |
| Android AI 보안 설정 프롬프트 |