안전한 시스템 개발 규범 / Secure System Development

실행 환경에 글로벌 자산 금지 명령(특정 자산 공격/스캔 금지)이 있는 경우 글로벌 설정을 따르며, 이 스킬은 이를 대체하지 않습니다. 일반 템플릿이 필요한 경우 references/internal-policy.example.md를 참조하십시오(배포판에는 실제 내부 주소가 포함되지 않습니다).

사용 방법

코드를 작성하기 전에 '레드라인 목록'을 먼저 읽고, 작성 후 자체 점검하십시오. 설계 및 검토 시에는 '1단계'를 읽으십시오. 특정 모듈과 관련된 경우 포인터에 따라 references/ 아래 해당 파일을 여십시오. 제출 전에 '출시 전 검토'를 실행하고, 출시 후에는 '런타임 및 0day'를 확인하십시오.

작업이 한 부분만 관련된 경우(예: 로그인 인터페이스 하나만 작성, 주문 테이블 하나만 설계), 해당 섹션과 해당 참조 파일만 읽고, 전체를 암기하지 마십시오.

실행 가능한 자체 점검(먼저 실행 권장)

python scripts/scan_redlines.py <대상 디렉토리> --format text            # 사람이 읽음
python scripts/scan_redlines.py <대상 디렉토리> --format sarif --fail-on high   # CI 차단
python scripts/scan_redlines.py <대상 디렉토리> --code-only              # 문서 건너뛰고 코드만 스캔

순수 Python 표준 라이브러리, 별도 의존성 설치 불필요. SQL拼接, innerHTML/eval, CORS 와일드카드 및 반사, 전역 fallback to 홈페이지, 하드코딩된 비밀키, MD5 비밀번호 저장, 명령 주입, 인증서 검증 비활성화, 디버그 스위치, 로그 내 민감 필드, 업로드 경로 미검증 등 18가지 규칙을 포함합니다. 탐지 결과는 해당 참조 파일을 가리킵니다.

오탐 처리: 해당 라인 끝에 redline: ignore(전체 라인 무시) 또는 redline: ignore SQL001(특정 규칙만 무시) 주석을 추가하십시오. 경고를 없애기 위해 전체 규칙을 비활성화하지 마십시오. 이유를 기록하고 검토 시 설명하십시오.

두 가지 템플릿: assets/threat-model-template.md(설계 단계 위협 모델링), assets/review-checklist.md(프로젝트 유형별 출시 전 체크리스트).

먼저 프로젝트 유형 결정(적용 규칙 결정)

시나리오	일반적인 형태	보안 규칙	무결성 요구사항	색인(SEO)
공개 사이트	공식 홈페이지, 랜딩 페이지, 블로그, 문서, 쇼핑몰 프론트	전체	낮음(콘텐츠 공개)	필수: 실제 404, sitemap, canonical, 구조화된 데이터
로그인 후 제품	SaaS, 툴 사이트, 커뮤니티 사용자측	전체 + 완전한 계정 체계	중(민감 작업 서명)	공개 페이지만 제출(마케팅/도움말 센터); 비공개 페이지 noindex
관리 백오피스	admin, 운영 백오피스, 고객 지원/심사 시스템	전체 + 독립 진입점 + MFA + 감사 로그	높음(모든 쓰기 작업 서명 + 감사)	색인 금지: 전체 사이트 noindex + 강제 인증
내부/개인 시스템	내부 플랫폼, 개인 도구, 스크립트 패널, 홈 NAS	인증 + 최소 노출 + 속도 제한 + 적시 업데이트	중(노출 표면에 따라 다름)	색인 금지; 공용 네트워크 기본 경로에 배치하지 않음, '은폐'에 의존하지 않음
순수 API	REST / GraphQL / 서비스 간 호출	인증 + 입력 검증 + 속도 제한 + 버전 관리	비즈니스에 따라 다름(결제/자금 관련 반드시 높음)	해당 없음(페이지 생성 안 함)

판단 기준은 하나뿐입니다: 이 URL이 검색 엔진에 나타나야 합니까?

예 → 공개 사이트로 실행, SEO 섹션 전체 적용.
아니오 → '색인 금지' 실행: 전체 사이트 X-Robots-Tag: noindex, robots 크롤링 금지, 강제 인증. 백오피스나 개인 시스템에 SEO 최적화(sitemap, canonical, 구조화된 데이터)를 적용하지 마십시오. 이는 낭비이며 공격 표면을 노출시킵니다.
어떤 시나리오든, **'존재하지 않는 경로는 실제 404를 반환'**해야 합니다. 이는 HTTP 정확성이며, SEO와 관련이 없습니다.

다섯 가지 기본 원칙

모든 입력은 신뢰할 수 없음: URL, query, body, header, cookie, 업로드 파일, Webhook, 메시지 큐, 타사 API 반환값, 심지어 데이터베이스의 과거 더티 데이터까지.
기본 거부(fail closed): 인증/검증/구문 분석 오류 시 허용하지 않고 거부; 예외 경로가 '검증 건너뛰기' 분기로 이어지지 않아야 함.
최소 권한: 데이터베이스 계정은 기능별로 권한 분리(읽기/쓰기 분리, DDL 금지), 클라우드 IAM/객체 스토리지는 접두사별 권한 부여, 프로세스는 root가 아닌 사용자로 실행, 컨테이너는 읽기 전용 파일 시스템.
심층 방어: 한 계층이 막지 못하면 다음 계층이 막음. 프론트엔드 검증은 사용자 경험, 서버 측 검증이 보안; WAF는 백업이지 대체재가 아님.
폭발 반경 제한: 0day는 코드 규약으로 제거할 수 없음. 격리, 권한 제한, 아웃바운드 화이트리스트, 빠른 패치 채널을 통해 피해를 최소화.

레드라인 목록(필수, 항목별 자체 점검)

인증 및 세션

비밀번호는 Argon2id/bcrypt(cost≥12)/scrypt 해시 사용, MD5/SHA1/가역 암호화 금지
로그인 실패 시 '계정+IP' 이중 차원 속도 제한, 점진적 지연, 필요 시 CAPTCHA/임시 잠금
로그인/등록/비밀번호 찾기 응답 문구 및 소요 시간 일관성 유지, 계정 존재 여부 누출 금지
로그인 성공 후 세션 ID 교체(세션 고정 방지), Cookie에 HttpOnly + Secure + SameSite 포함
JWT는 서버 측 고정 알고리즘 화이트리스트 사용, alg:none 및 알고리즘 혼동 거부; 짧은 유효 기간 + refresh 교체 + 취소 가능
인증 ≠ 권한 부여: 각 인터페이스에서 '현재 사용자가 이 객체를 조작할 수 있는지' 명시적으로 검증(IDOR/권한 상승 방지)

인젝션 및 출력

모든 SQL은 매개변수화된 쿼리/ORM 바인딩 사용, 문자열 연결 금지; 테이블 이름/정렬 필드는 화이트리스트 매핑 사용
사용자 입력을 shell/명령어에 직접 연결 금지, 매개변수 배열의 execFile 계열 사용
출력은 컨텍스트에 따라 인코딩; dangerouslySetInnerHTML/v-html/innerHTML은 반드시 DOMPurify와 같은 sanitizer를 거쳐야 함
리치 텍스트, Markdown, URL 매개변수는 모두 화이트리스트 처리, 프론트엔드 필터링 신뢰 금지
아웃바운드 요청(SSRF)은 화이트리스트 사용, 임의 리디렉션 팔로우 금지, 내부 네트워크/메타데이터 주소 차단(169.254.169.254, 127.0.0.1, 10/8, 172.16/12, 192.168/16, ::1, file://, gopher://)
파일 경로는 path.resolve 후 접두사 검증, .. 거부; 업로드 파일은 무작위 이름, 유형 스니핑, 격리 저장, 실행 권한 없음

데이터 및 동시성

핵심 쓰기 작업은 멱등성(고유 인덱스/멱등 키), 주문, 결제, 콜백은 반드시 멱등
재고, 잔액, 횟수 같은 필드는 조건부 업데이트 UPDATE ... WHERE 잔여량 >= ? 사용, '먼저 조회 후 변경' 금지
트랜잭션은 짧게 유지, 트랜잭션 내 네트워크 호출, 메시지 전송, 템플릿 렌더링 금지
새 쿼리는 반드시 EXPLAIN 실행; 큰 offset 페이지네이션, SELECT *, N+1 쿼리 금지
금액은 정수(분) 또는 DECIMAL 사용, float/double 금지

비동기 및 안정성

모든 외부 호출(HTTP/DB/Redis/MQ)은 명시적 타임아웃 설정, 무한 대기 금지
재시도는 멱등 작업에만 사용, 지수 백오프 + 지터 + 최대 횟수 제한
메시지 소비는 멱등성(message_id 중복 제거 테이블), 실패 시 데드 레터 큐로 이동 및 알림
주요 상태 변경은 먼저 데이터베이스에 기록 후 메시지 전송(Outbox/트랜잭셔널 메시지), 이중 쓰기 금지

비즈니스 로직 및 경합 조건(가장 자주 누락되는 유형)

가격, 금액, 할인, 권한 수준은 모두 서버 측에서 계산, 클라이언트 제출 값은 표시용
쿠폰/교환 코드/초대 코드는 사용자 및 횟수에 바인딩, 원자적 소비(조건부 업데이트 또는 고유 제약 조건)
상태 기계는 명시적 검증: 잘못된 전이는 직접 거부(예: pending 상태가 결제 콜백을 우회하여 직접 paid로 변경)
자금/콜백 인터페이스는 서명 + 타임스탬프 + 멱등 키 검증, 재전송 및 위조 방지
구매 제한, 빈도 제어는 '사용자 + 장치 + IP' 조합으로 판단, 단일 차원 우회 금지
내보내기, 일괄 처리, 검색 인터페이스는 속도 제한 + 데이터 양 상한 + 감사

비밀 및 운영

비밀은 환경 변수 또는 비밀 관리 서비스에만 저장, 저장소, 이미지 레이어, 프론트엔드 번들, 로그, 오류 보고에 포함 금지
CI/CD 자격 증명은 최소 권한, 프로덕션 배포는 승인 필요; 타사 의존성은 버전 잠금 + 스캔
민감한 작업(로그인, 권한 변경, 내보내기, 삭제, 환불)은 감사 로그 기록, 비즈니스 코드가 변경 불가

인터페이스 무결성(패킷 캡처/변조/재전송/응답 위조 방지)

결제, 자금, 권한 부여, 비밀번호 변경 등 민감한 요청은 서명: HMAC(secret, method+path+sortedQuery+sha256(body)+timestamp+nonce), 서버 측 재계산
nonce 저장 중복 제거(TTL = 시간 창), 시간 창 ±300초, 만료 및 재전송 거부
민감한 응답(결제 결과, 권한 부여 결과, 잔액)은 서버 측 서명 포함, 클라이언트 검증; 하지만 진실은 항상 서버 측 재확인
클라이언트가 제출한 '이미 검증됨' 표시, 가격, 역할은 진실 공급원으로 신뢰 금지; 서버 측 재계산/재확인
모바일 인증서 고정; release 빌드는 사용자 인증서, 디버그 및 패킷 캡처 스위치 신뢰 금지
클라이언트 강화(난독화/강화/안티 디버깅)는 비용만 증가, 보안 경계로 간주 금지; 비밀은 클라이언트에 전달 금지

AI / LLM 애플리케이션

모델 출력은 신뢰할 수 없는 입력으로 간주: eval 금지, HTML/SQL/명령어에 직접 연결 금지, 도구 매개변수 직접 실행 금지
도구/함수 호출은 최소 권한 + 매개변수 스키마 검증 + 고위험 작업은 인간 확인 필요
RAG로 검색된 문서는 신뢰할 수 없는 콘텐츠로 간주, 시스템 프롬프트와 격리, 간접 프롬프트 인젝션 방지
시스템 프롬프트와 사용자 입력 분리; 비밀키, 내부 규칙을 유도 출력 가능한 위치에 배치 금지
사용자/테넌트별 비용 및 빈도 속도 제한; 로그는 민감 데이터 마스킹(전체 프롬프트의 민감 데이터 기록 금지)

모바일 / 미니프로그램

민감 데이터는 Keychain(iOS) / Keystore(Android)에 저장, 평문 SharedPreferences 금지
전송은 강제 TLS + 인증서 고정; InsecureSkipVerify/verify=False 완전 금지
WebView는 file 접근 및 JS 브릿지 노출 표면 차단, onShouldStartLoadWithRequest에서 도메인 화이트리스트 사용
미니프로그램 session_key는 서버 측에서만 사용, 클라이언트에 절대 전달 금지; code2session 후 자체 세션 발급
root/탈옥 감지는 위험 신호로만 사용, 인증 근거로 사용 금지

HTTP 및 라우팅(모든 시나리오)

존재하지 않는 경로는 실제 HTTP 404 + 404 페이지 반환, 302/200으로 홈페이지 리디렉션 금지
SPA의 history fallback은 '알려진 프론트엔드 라우트'에만 적용; /api, 확장자가 있는 정적 리소스는 모두 404
CORS는 정확한 Origin 화이트리스트 사용, Access-Control-Allow-Origin: *와 credentials 조합 금지, 임의 Origin 반사 금지
프로덕션에서 보안 응답 헤더 활성화: HSTS, CSP, X-Content-Type-Options, Referrer-Policy, frame-ancestors
인증/민감 인터페이스 응답에 Cache-Control: no-store 포함
오류 응답에 스택 트레이스, SQL, 프레임워크 버전, 내부 경로 반환 금지

색인(공개 사이트만 필요; 백오피스/내부 시스템은 반대로 적용)

공개 사이트: sitemap은 200 페이지만 나열, canonical 중복 제거, robots는 백오피스 경로 노출 금지, 스테이징 환경 전체 noindex
백오피스/내부/개인 시스템: 전체 사이트 X-Robots-Tag: noindex + robots Disallow: /, sitemap 생성 금지, 반드시 인증 필요(robots는 접근 제어가 아님)

1단계: 설계 시

코드를 작성하기 전에 5분 동안 간단한 위협 모델링을 수행하십시오:

시나리오 결정: 위의 프로젝트 유형 표를 참조하여 공개 사이트, 백오피스, 내부 시스템 또는 API인지 확인; 이에 따라 SEO 섹션 적용 여부와 노출 표면 크기 결정.
데이터 흐름 그리기: 사용자 → 게이트웨이 → 서비스 → 데이터베이스/캐시/MQ/타사, 각 신뢰 경계를 넘는 지점 표시.
자산 나열 및 등급 분류: 계정, 자격 증명, 결제, 개인 데이터, 관리 백오피스 각각에 대해 '누가 읽을 수 있는지, 누가 쓸 수 있는지, 변조 시 결과, 보존 기간' 질문.
각 경계에서 세 가지 질문: 누가 도달할 수 있나요? 입력이 검증되었나요? 실패 시 기본 거부합니까?
권한 모델 결정: 역할 → 리소스 → 작업, 서버 측에서 강제, 프론트엔드 버튼 숨기기는 안전으로 간주 금지; 멀티 테넌트 시스템은 추가 격리 정책 결정.
비동기 경계 결정: 어떤 작업이 동기적으로 반환되어야 하는지(로그인, 결제 확인), 어떤 작업이 비동기일 수 있는지(알림, 보고서, 내보내기)

설계 문서에는 최소한 다음을 명시해야 함: 프로젝트 유형 및 색인 전략, 인증 방식, 권한 부여 모델, 민감 데이터 등급 및 암호화, 속도 제한 전략, 멱등 키, 실패 시 성능 저하 방식, 로그 및 감사 범위.

2단계: 구현 시

인증 및 로그인(최우선 순위)

로그인은 무차별 대입, 자격 증명 스터핑, 우회에 가장 취약한 진입점입니다. 전체 규칙은 references/auth-and-session.md 참조, 핵심 양보 불가 사항:

속도 제한 계층화: 단일 IP, 단일 계정, 단일 장치 지문; 실패 횟수는 Redis 만료 키 사용, 메모리만 사용 금지.
오류 메시지는 "계정 또는 비밀번호 오류"로 통일, 소요 시간 일치(존재하지 않는 계정도 가짜 해시 한 번 실행, 타이밍 열거 방지).
로그인 성공 후 세션 식별자 재생성; 이전 세션 무효화.
민감한 작업(비밀번호 변경, 바인딩 변경, 출금, 삭제)은 2차 인증 또는 최근 인증 시간(re-auth 창) 필요.
비밀번호 재설정 토큰: 높은 엔트로피, 일회용, 짧은 유효 기간(≤15분), 사용자 및 용도에 바인딩.
관리 백오피스는 독립적인 진입점, 독립 도메인 또는 IP 화이트리스트, 사용자 측과 세션 공유 금지.

입력, 인젝션 및 출력

references/web-vulnerability-prevention.md 참조. 원칙: 진입점에서 통합 검증(schema), 종료점에서 컨텍스트에 따라 인코딩.

// 입력: schema를 사용하여 검증, 알 수 없는 필드는 거부, '필요한 것만 가져오기' 금지
const LoginBody = z.object({ email: z.string().email(), password: z.string().min(8).max(128) }).strict();

// SQL: 매개변수화, 절대 연결 금지
await db.query('SELECT id, password_hash FROM users WHERE email = $1', [email]);
// 정렬/테이블 이름 등 매개변수화할 수 없는 위치: 화이트리스트
const orderBy = { created_at: 'created_at', amount: 'amount_cents' }[sort] ?? 'created_at';

XSS: React/Vue는 기본 이스케이프로 충분, 위험한 API는 반드시 sanitizer 사용; CSP는 두 번째 방어선.
권한 상승: 쿼리 조건에 owner_id = $currentUser 포함, '조회 후 프론트엔드에서 판단' 금지.
역직렬화/템플릿 인젝션: eval 금지, 사용자 입력을 템플릿/표현식/정규식에 직접 연결 금지.
업로드: 크기 및 유형 제한(magic bytes 스니핑), 무작위 파일 이름, 객체 스토리지 저장, 이미지 재인코딩.

데이터베이스 및 고동시성

references/database-concurrency.md 참조. 주요 사항:

인덱스가 최적화보다 우선: 새 쿼리 출시 전 EXPLAIN, type=ALL, filesort, 임시 테이블 확인.
페이지네이션은 커서(keyset) 사용, 깊은 offset 사용 금지; 목록 인터페이스는 안정적인 정렬 + 상한 필수.
핫스팟 쓰기는 '조건부 업데이트 + 행 잠금' 사용, 재고 차감 예시:

UPDATE sku SET stock = stock - $1, version = version + 1
WHERE id = $2 AND stock >= $1;
-- 영향받은 행 0 → 재고 부족 또는 동시성 충돌, 비즈니스에 따라 재시도/실패

캐시 3종 세트: 관통 방지(널 값 캐시/블룸 필터), 붕괴 방지(뮤텍스 잠금/싱글 플라이어), 눈사태 방지(TTL + 랜덤 지터).
연결 풀 최대값은 데이터베이스 max_connections / 인스턴스 수보다 작아야 하며, 획득 타임아웃 구성.
규모가 커지면 샤딩/파티셔닝 논의; 먼저 인덱스, 캐시, 읽기/쓰기 분리, 핫/콜드 분리 수행.

비즈니스 로직 및 경합 조건

references/business-logic-and-race-conditions.md 참조. 이러한 취약점은 통합 스캐너가 없으며, 설계 시 각 사항을 명확히 생각해야만 방지 가능: 가격 및 금액 서버 측 계산, 쿠폰 원자적 소비, 상태 기계 검증, 재전송 방지, 구매 제한 차원, 내보내기 속도 제한. 동시성에서 '먼저 조회 후 변경'은 모두 조건부 업데이트 또는 잠금 + 멱등성으로 변경.

비동기 우선 아키텍처

references/async-architecture.md 참조. 시스템은 기본적으로 비동기 설계:

IO는 모두 비차단; Node에서 요청 경로에 동기 fs/crypto 및 CPU 집약적 계산 금지(worker_threads 사용).
모든 외부 호출에는 타임아웃 필수; 호출 체인에 trace id 전달.
큐 소비 = 최소 한 번 전달, 따라서 반드시 멱등; 재시도 상한, 초과 시 DLQ 및 알림.
서비스 간 일관성은 Outbox/CDC 사용, 이중 쓰기 금지.
긴 작업(내보내기, 일괄 처리, 심사)은 큐로 전달, 인터페이스는 즉시 task id 반환, 프론트엔드는 폴링 또는 SSE로 상태 푸시.
정상 종료: 새 요청 수신 중단 → 진행 중 완료 대기 → 큐 소비자 종료 → 연결 종료.

HTTP, 라우팅, CORS 및 SEO

references/http-routing-cors-seo.md 참조. 가장 흔한 세 가지 실수:

404는 반드시 404여야 함. 홈페이지로 전역 폴백 금지: SPA는 빌드 시 알려진 라우트에만 index.html 폴백, /api/* 및 확장자가 있는 경로는 직접 404.
CORS 정확한 화이트리스트, Origin과 설정 항목을 집합 동등 비교, includes 금지, 접두사 일치 금지, 요청 헤더 직접 에코 금지.
상태 코드 의미 정확: 401 인증되지 않음, 403 권한 없음, 404 존재하지 않음, 409 충돌, 422 검증 실패, 429 속도 제한.

SEO는 공개 사이트에만 적용; 백오피스와 내부 시스템은 위 시나리오 표의 '색인 금지'에 따라 실행, sitemap, canonical, 구조화된 데이터 추가 금지. 이는 크롤러에 공격 표면을 제공하는 것입니다.

비밀, 운영 및 메일

references/operations-and-secrets.md 참조. 주요 사항: 비밀 계층화 저장 및 순환 교체, CI/CD 최소 권한, 컨테이너 비-root, 객체 스토리지 및 클라우드 IAM 최소화, 감사 로그 변경 불가, 메일 도메인 SPF/DKIM/DMARC 구성으로 위조 방지, 데이터 보존 기간 및 삭제 프로세스.

인터페이스 무결성 및 변조 방지

references/api-integrity-and-tampering.md 참조. 패킷 캡처/변조 및 재전송은 모바일 및 공개 API의 주요 문제: 요청 서명(HMAC + timestamp + nonce + body hash), 서버 측 재계산, 민감 응답 서명, nonce 중복 제거, 시간 창, 인증서 고정. 기억: 클라이언트가 변경할 수 있는 모든 것은 신뢰할 수 없으며, 서명은门槛만 높일 뿐, 서버 측 재계산이 진실입니다.

AI / LLM 애플리케이션 보안

references/ai-llm-security.md 참조. 모델 출력은 외부 입력과 동일하게 취급: 실행 금지, 직접 연결 금지, SQL/명령어로 사용 금지; 도구 호출 최소 권한 + 스키마 검증 + 고위험 작업 인간 확인; RAG 콘텐츠 신뢰 불가; 테넌트별 속도 제한으로 비용 제어.

모바일 및 미니프로그램

references/mobile-and-miniprogram.md 참조. Keychain/Keystore, 인증서 고정, WebView 강화, 미니프로그램 session_key 미전송, root 감지는 신호로만 사용.

3단계: 출시 전 검토

순서대로 확인, '확실하지 않음'은 모두 통과 실패로 처리:

레드라인 목록 100% 체크; 프로젝트 유형별 확인: 공개 사이트는 SEO 항목 확인, 백오피스/내부 시스템은 noindex 및 진입점 격리 확인, 민감 비즈니스는 인터페이스 무결성 확인.
python scripts/scan_redlines.py <디렉토리> --fail-on high 실행, 고위험은 반드시 제거.
의존성 스캔(npm audit / pip-audit / govulncheck / OWASP Dependency-Check), 고위험은 반드시 처리.
비밀 확인: 저장소, 이미지, 로그, 프론트엔드 번들에 비밀 없음; .env는 버전 관리 제외; CI 로그도 확인.
컨테이너/호스트: 비-root, 읽기 전용 루트 파일 시스템, 최소 포트 노출, 아웃바운드 화이트리스트.
모니터링 및 알림: 로그인 실패율, 5xx, 큐 백로그, 느린 쿼리, 비정상 아웃바운드 요청.
백업 및 복구 테스트; 데이터베이스 계정 최소 권한.
부하 테스트 중요 경로(로그인, 주문, 목록)로 속도 제한 및 캐시 확인.
메일 도메인: SPF/DKIM/DMARC 구성, 발신 인터페이스 속도 제한, 피싱 메일 위조 방지 및 스팸 발신원 차단.
데이터 수명 주기: 수집 최소화, 보존 기간, 내보내기 및 삭제 프로세스 명확; 로그는 마스킹 후 보관.
보안 대응 계획: 담당자, 격리 방법, 사용자 통지 방법, 사후 분석 방법.
규정 준수 매핑(필요 시): references/compliance-mapping.md에서 OWASP/ASVS/등가/PIPL 항목 확인.

4단계: 런타임 및 0day 완화

코드 규약은 알려지지 않은 취약점을 막을 수 없으며, 다음 수단으로 영향을 제한:

아웃바운드 기본 거부 + 화이트리스트(SSRF, 공급망 역연결의 첫 번째 방어선).
중요 서비스 샌드박스/컨테이너 격리, 프로세스 권한 하향, seccomp/AppArmor 필요 시 활성화.
의존성 버전 잠금 + 빠르게 이미지 재구축 가능; 보안 공지 모니터링, 긴급 패치 채널 준비.
WAF/게이트웨이는 일반적인 특징 차단 및 속도 제한, 하지만 이것에만 의존 금지.
행동 모니터링: 비정상 로그인 지역/장치 점프, 대량 읽기/쓰기, 비정상 아웃바운드 트래픽.
데이터 등급: 민감 필드는 암호화 저장(AES-GCM/KMS), 로그 마스킹, 내보내기는 승인 필요.

references 인덱스

파일	언제 읽을까
`references/auth-and-session.md`	로그인, 등록, 비밀번호, JWT, 2FA, 비밀번호 찾기, CSRF, 권한 상승, 관리 백오피스
`references/web-vulnerability-prevention.md`	SQL 인젝션, XSS, SSRF, 업로드, 경로 탐색, 역직렬화, 응답 헤더, API 특수 위험
`references/business-logic-and-race-conditions.md`	가격/금액, 쿠폰, 재고, 상태 기계, TOCTOU 경합, 구매 제한, 내보내기 남용
`references/database-concurrency.md`	테이블 생성, 인덱스, 트랜잭션, 잠금, 멱등성, 캐시, 읽기/쓰기 분리, 샤딩/파티셔닝
`references/async-architecture.md`	타임아웃, 재시도, 큐 소비, Outbox, 백프레셔, 정상 종료, 관찰 가능성
`references/http-routing-cors-seo.md`	404, 상태 코드, CORS, 캐시, robots/sitemap, 공개 사이트와 백오피스 색인 분리
`references/operations-and-secrets.md`	비밀, CI/CD, 컨테이너/클라우드, 메일 도메인, 감사 로그, 데이터 수명 주기, 비상 대응
`references/api-integrity-and-tampering.md`	패킷 캡처/변조, 요청/응답 서명, 재전송 방지, 인증서 고정, 클라이언트 강화 경계
`references/ai-llm-security.md`	프롬프트 인젝션, 도구 호출 권한, RAG 중독, 모델 출력 처리, 비용 속도 제한
`references/mobile-and-miniprogram.md`	로컬 스토리지, 인증서 고정, WebView, 미니프로그램 로그인 상태, root 감지
`references/compliance-mapping.md`	OWASP Top 10 / ASVS / 등가 2.0 / PIPL 대조, 감사 또는 검토 보고에 사용
`references/internal-policy.example.md`	사용자 정의 자산 금지 템플릿이 필요할 때 (자리 표시자 도메인, 실제 주소 불포함)

인도 조건

코드를 인도할 때마다 응답에 3-6줄로 이번 작업과 관련된 보안 관련 결정(검증 지점, 인증 지점, 멱등 키, 속도 제한, 오류 처리)을 설명하고, 생략하지 마십시오.
먼저 프로젝트 유형을 명시하십시오: 백오피스나 내부 시스템을 인도하는 경우 'SEO 작업 안 함, 전체 사이트 noindex'를 명확히 밝히십시오. 공개 사이트에만 색인 관련 설정을 출력하십시오.
기존 코드가 레드라인을 위반하는 경우 위치를 직접 지적하고 수정 사항을 제공하십시오. '강화 권장'이라고만 말하지 마십시오.
검증할 수 없는 부분(예: 실제 공격 테스트를 수행하지 않은 경우)은 명시적으로 '미검증'이라고 쓰고, 보안 테스트를 통과했다고 주장하지 마십시오.

bucai2417/secure-system-development

secure-system-development란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

문서