시큐어 코딩과 SDL: 설계·코드·의존성·배포를 연결하는 방법

1장 개념과 보호 목표#

시큐어 코딩은 개발자가 특정 위험한 함수만 피하는 활동보다 넓습니다. 설계에서 신뢰 경계를 정하고, 구현에서 입력·권한·상태를 검증하며, 배포와 운영에서 취약점과 비밀을 관리하는 과정입니다.

2장 원리와 구분#

SAST는 코드나 정적 산출물에서 결함 후보를, DAST는 실행 중인 서비스에서 응답과 동작을, SCA는 의존성과 알려진 취약점을 분석합니다. 각각 탐지 범위와 오탐·미탐이 있으므로 결과 검토가 필요합니다. 오류는 민감정보를 노출하지 않으면서 조사 가능한 상관 ID를 남겨야 하며 예외를 무조건 삼키는 방식은 정상 처리를 보장하지 않습니다.

TOCTOU는 권한이나 파일 상태를 검사한 뒤 사용하기 전에 상태가 바뀌는 경쟁 문제입니다. 검사와 실행 사이에 다른 요청이 개입할 수 있는지 확인하고 원자적 연산이나 안전한 핸들 사용을 검토합니다. 코드 리뷰에서는 성공 경로뿐 아니라 중단·실패·동시 실행의 상태 전이를 확인해야 합니다.

3장 비교와 판단 기준#

활동	확인하는 문제	연결할 증거
위협 모델링	설계·신뢰 경계	요구사항·실패 시나리오
SAST	정적 코드 결함	검토·수정·재검사
DAST	실행 응답과 노출	테스트 환경·재현
SCA	의존성 위험	버전·취약점·갱신
운영 대응	출시 후 결함	패치·관찰·재발 검증

4장 보안 요구를 코드의 결과로 연결한다#

사용자가 타인 데이터에 접근할 수 없어야 한다는 요구는 서버의 실제 요청 시험으로, 빌드의 비밀이 노출되지 않아야 한다는 요구는 CI·로그·산출물 점검으로 연결합니다. 문서·코드·설정·운영이 같은 목적을 갖는지 확인합니다.

SDL은 설계·구현·검증·출시·운영을 연결하는 과정입니다. 보안 도구를 구매하거나 출시 직전에 스캔하는 활동만으로 이 과정을 대신하지 않습니다.

flowchart LR
 R["보안 요구"] --> T["위협과 신뢰 경계"]
 T --> D["설계·구현"]
 D --> V["리뷰·도구·동작 검증"]
 V --> P["출시 조건과 증거"]
 P --> O["운영·패치·재발 검증"]

5장 위협 모델은 성공 기능의 반대편을 본다#

누가 어떤 입력을 제어하고 어느 자원에 접근하는지 그립니다. 외부 데이터가 명령이 되는지, 사용자가 다른 조직의 자원을 지정하는지, 실패가 권한을 여는지 확인합니다. 필요한 통제와 시험이 여기서 나와야 합니다.

모든 공격 이름을 나열하기보다 중요한 데이터·상태·신뢰 경계를 중심으로 작성합니다. 신규 기능·외부 연동·권한 변경 때 모델과 검증을 갱신합니다.

6장 SAST·DAST·SCA의 다른 관측#

SAST는 실행 없이 코드나 산출물의 결함 후보를, DAST는 실행한 서비스의 응답·동작을, SCA는 의존성·알려진 위험을 확인합니다. 도구가 업무의 모든 권한·상태를 이해하지는 않습니다. 결과의 재현·오탐·미탐과 사용 범위를 검토합니다.

활동	유용한 근거	별도로 필요한 검토
SAST	코드 경로와 위험한 사용	실제 실행·업무 의미
DAST	노출 응답·실행 결과	미관측 경로·인가
SCA	버전·의존성 위험	배포 여부·악용 경로
수동 리뷰	신뢰·상태·업무 판단	실동작과 회귀 검증

7장 검사 결과를 담당자와 기한에 연결한다#

발견한 결함에는 대상·재현·영향·담당자·기한·조치·재검증을 둡니다. 예외는 위험 수용 권한과 만료·보완 계획을 연결합니다. 높은 심각도도 실제 노출·데이터·경로에 맞춰 우선순위를 판단하되 근거 없이 낮추지 않습니다.

스캐너 결과가 줄어든 이유가 코드 수정인지 검사 범위 축소인지 구분합니다. 출시된 실제 버전과 검사한 산출물이 같은지 확인해야 증거가 유효합니다.

8장 TOCTOU의 검사와 사용 사이#

파일·잔액·권한을 확인한 뒤 실행하기 전에 다른 요청이 상태를 바꿀 수 있습니다. 처음 검사가 통과해도 실제 사용 조건이 달라질 수 있습니다. 원자적 상태 변경·안전한 핸들·트랜잭션 등의 적절한 구조를 검토합니다.

요청 A: 잔액 확인
요청 B: 같은 잔액 확인
요청 A: 지급
요청 B: 지급
필요한 보장: 검사와 지급의 상태를 원자적으로 연결

9장 멱등성 키는 저장과 결과까지 설계한다#

재시도한 요청이 중복 작업을 하지 않도록 키의 사용자·기능·인자 범위와 수명을 정합니다. 키가 같지만 인자가 다르면 어떻게 처리하는지, 동시 요청과 작업 실패·중단 때 결과가 무엇인지 정의합니다. 헤더 하나를 추가하는 것으로 멱등성이 자동 완성되지 않습니다.

업무 상태·외부 호출·DB의 결과를 연결하고 반복 요청이 같은 완료 결과를 읽을 수 있는지 시험합니다. 부분 성공과 보상·재시도도 설계해야 합니다.

10장 오류 처리는 비밀 보호와 상태 일관성#

민감한 원문·스택·비밀을 사용자에게 노출하지 않되 내부에는 사건 식별자와 필요한 근거를 남깁니다. 예외를 모두 삼켜 정상 성공을 반환하면 상태가 잘못될 수 있습니다. 실패 시 권한·거래·자원 정리를 명시합니다.

성공 경로와 시간 초과·취소·중단·자원 부족의 흐름을 각각 리뷰합니다. 로그 자체의 입력·변조·보존·접근도 보안 대상입니다.

11장 SBOM과 빌드 출처#

SBOM은 어떤 구성 요소가 들어 있는지 파악하는 자료입니다. 구성의 취약점 조치·빌드 권한·산출물 진본·업데이트 경로는 추가 통제입니다. 잠금된 의존성·허용 출처·서명·실제 배포 버전을 연결합니다.

flowchart TB
 S["소스와 의존성"] --> B["제한된 빌드 권한"]
 B --> A["산출물과 구성 목록"]
 A --> V["출처·검증·출시 승인"]
 V --> D["실제 배포와 버전 추적"]

12장 비밀과 배포 권한을 제한한다#

CI·운영 키·서비스 계정은 필요한 작업과 환경에만 권한을 둡니다. 개발자가 읽는 소스에 운영 비밀을 넣거나 모든 배포를 하나의 관리자 자격증명으로 처리하지 않습니다. 누가 빌드·승인·배포를 바꿀 수 있는지 기록합니다.

노출 키를 지우는 것과 회수·교체·사용 흔적 조사는 별도입니다. 장애 시 긴급 예외에도 범위·시간·기록·사후 검토가 필요합니다.

13장 출시 후에도 검증은 이어진다#

새 취약점·의존성 변경·외부 서비스 변화·사고를 자산과 실제 버전에 연결합니다. 패치·회귀·재발 시험과 관측으로 조치 효과를 확인합니다. 도구의 통과를 영구적인 안전성 보증으로 취급하지 않습니다.

보안 요구와 출시·운영의 증거가 연결되면 개발팀과 운영팀이 같은 실패를 반복하지 않고 실제 위험을 설명할 수 있습니다.

14장 적용 사례와 운영 방법#

잔액 변경 API에서는 인증·인가뿐 아니라 동시 요청에서 이중 지급이 생기지 않는지 검토합니다. 트랜잭션·원자적 상태 전이·멱등성 키를 사용하고 실패 경로를 테스트합니다. 빌드에서는 의존성 목록, 업데이트 정책과 배포 산출물의 출처를 관리합니다.

15장 SDL은 결함을 발견한 뒤의 처리까지 포함한다#

설계에서 보안 요구와 위협을 정의하고 구현에서 검토·테스트로 검증하며 출시 후 패치와 사고 대응으로 이어져야 합니다. 도구를 설치한 상태와 이 과정이 실제로 작동하는 상태는 다릅니다. 발견한 결함에는 담당자·우선순위·기한·예외 승인·재검증을 연결합니다.

SAST는 실행 없이 볼 수 있는 코드 경로, DAST는 실행 상태의 응답·설정, SCA는 의존성 구성과 알려진 위험을 중심으로 봅니다. SBOM은 구성 요소 목록이며 목록이 있다는 사실만으로 취약점이 수정되거나 산출물의 출처가 증명되지는 않습니다. 사용 버전과 배포 산출물을 대응시키는 운영이 필요합니다.

16장 동시 요청과 실패 상태를 리뷰에 넣기#

포인트 지급이나 재고 차감은 같은 요청의 재시도·동시 실행에서 중복 반영될 수 있습니다. 멱등성 키의 범위·유효기간·저장과 원자적 상태 변경을 설계하고, 중간 실패 때 이미 반영한 작업을 어떻게 처리할지 정의합니다. 입력 검증만으로 업무 무결성이 완성되지는 않습니다.

배포 파이프라인은 비밀 노출, 의존성 출처, 빌드 권한과 산출물 검증을 포함합니다. 보안 게이트에는 실제 악용 가능성과 업무 영향을 반영하고, 긴급 예외도 만료·보완 계획을 남깁니다. 검증이 실패해도 무조건 계속 배포하는 경로는 별도 정책으로 통제합니다.

17장 적용 전 확인할 사항#

설계 요구사항을 코드 리뷰와 테스트에 연결한다
검사 결과에 담당자·기한·재검증을 둔다
비밀·의존성·배포 권한을 함께 관리한다

18장 자주 묻는 질문#

보안 도구에서 문제가 없으면 코드는 안전한가요?#

도구가 이해하지 못하는 업무 인가와 논리 오류가 남을 수 있습니다. 위협 모델과 수동 검토, 의미 있는 동작 검증을 함께 수행해야 합니다.

SBOM을 제출하면 공급망 보안 검증이 끝나나요?#

구성 요소를 파악하는 출발점입니다. 취약점 처리·빌드 출처·권한·서명·업데이트 경로의 검증이 추가로 필요합니다.

스캐너의 높은 심각도는 모두 같은 순서로 수정하나요?#

자산 노출·실행 경로·데이터 영향·보완 통제를 함께 평가합니다. 조정 근거와 잔여 위험 승인도 기록해야 합니다.