Secure SDLC·SSDF·위협 모델링
Secure SDLC가 요구·설계·구현·시험·운영에 보안을 통합하는 접근임을 이해한다. 대표 보안 개발 방법, 입력·오류·코드·캡슐화·API 약점 범주를 구분하고 SSDF와 STRIDE는 위협 분석의 보조 개념으로 연결한다.
핵심 요약
Secure SDLC는 요구사항·설계·구현·시험·운영 등 소프트웨어 생명주기 전반에 보안을 반영하는 접근이다. 제품이 완성된 뒤 보안 도구를 한 번 실행하는 활동과는 다르다. 보안 요구를 정하고 설계·코드에 반영한 뒤 실제 통제가 동작하는지 검증해야 한다.
SSDF는 안전한 개발을 위한 고수준 실천 체계이고, 위협 모델링은 설계와 데이터 흐름에서 어떤 위협이 가능한지 찾아 대응하는 활동이다. 모두 기존 개발 방법과 함께 적용할 수 있다.
1. 생명주기별 보안 활동
| 단계 | 핵심 활동 | 확인할 질문 |
|---|---|---|
| 요구사항 | 보호 자산·보안 목표·인증·권한·기밀성 요구 정의 | 누구의 어떤 데이터를 보호해야 하는가? |
| 설계 | 위협 분석, 신뢰 경계, 접근통제·암호·오류 처리 구조 설계 | 설계 자체에 우회·노출 경로가 없는가? |
| 구현 | 입력 검증, 안전한 API, 메모리·자원·예외 처리 적용 | 설계한 통제가 코드에 반영되었는가? |
| 시험 | 정적·동적 분석, 보안 기능 시험, 취약점 확인 | 비정상 입력과 허용되지 않은 접근을 막는가? |
| 배포·운영 | 안전한 설정, 로그·점검, 패치와 취약점 대응 | 운영 중 드러난 문제를 수정·재검증하는가? |
보안을 개발 초기에 반영하면 잘못된 구조가 굳어지기 전에 수정할 기회가 생긴다. 그러나 초기에 검토했다는 이유로 운영 중 탐지·대응을 생략해서는 안 된다. 새로운 취약점과 환경 변화는 계속 발생할 수 있다.
2. 보안 요구사항의 표현
보안 요구는 ‘안전하게 개발한다’처럼 추상적인 구호가 아니라 검증할 수 있는 조건으로 작성한다.
예를 들어 “지원자는 자신의 지원서만 조회할 수 있어야 하며, 다른 사람의 지원서에 대한 요청은 서버에서 거부해야 한다”는 주체·객체·허용 조건이 드러난다. 이 요구는 객체별 접근통제 설계와 허용·거부 시험에 연결할 수 있다.
| 보호 속성 | 요구의 예 |
|---|---|
| 인증 | 계정 소유자임을 확인한 뒤 보호 기능 제공 |
| 인가 | 역할·소유권에 맞는 객체와 기능만 허용 |
| 기밀성 | 민감정보의 저장·전송 시 적절한 보호 |
| 무결성 | 승인되지 않은 데이터 변경 방지·검출 |
| 가용성 | 잘못된 요청과 장애로 자원이 무제한 소진되지 않도록 제한 |
| 책임추적 | 중요한 행위의 주체·시각·대상·결과 기록 |
인증 성공과 인가 성공은 별개의 판단이다. 로그인된 사용자도 다른 사람의 데이터나 관리자 기능에 접근해서는 안 될 수 있다.
3. 개발보안의 주요 점검 범주
입력 데이터 처리뿐 아니라 시간·상태, 오류, 메모리·자원, 내부 데이터 노출과 API 사용까지 함께 확인한다.
| 범주 | 대표 약점·점검 대상 |
|---|---|
| 입력데이터 검증 및 표현 | SQL 삽입, XSS, 경로 조작, 부적절한 입력 처리 |
| 보안기능 | 부적절한 인증·인가·암호 처리, 하드코딩된 비밀정보 |
| 시간 및 상태 | 경쟁 상태, 검사와 사용 사이 상태 변경 |
| 에러처리 | 내부 정보가 포함된 오류 메시지, 처리 누락 |
| 코드오류 | 널 참조, 경계 오류, 해제 후 사용, 자원 누수 |
| 캡슐화 | 내부 가변 데이터·민감정보의 노출 |
| API 오용 | 보안상 위험하거나 계약에 맞지 않는 API 사용 |
이 분류는 약점을 빠짐없이 검토하기 위한 관점이다. 특정 약점이 여러 범주와 연결될 수 있으며, 표만 갖춰 놓았다고 실제 점검이 완료되는 것은 아니다.
4. 보안 개발 접근의 구분
| 접근 | 핵심 특징 |
|---|---|
| Microsoft SDL | 개발 생명주기에 교육·보안 요구·위협 모델링·검증 등을 통합 |
| Seven Touchpoints | 코드 검토·아키텍처 위험 분석·침투시험 등 핵심 보안 활동을 개발 산출물과 연결 |
| CLASP | 역할과 활동을 중심으로 보안을 개발 과정에 반영하는 경량 프로세스 |
| SQUARE | 보안 요구사항의 도출·분석·우선순위·명세에 초점 |
공통점은 보안을 최종 단계의 부가 작업으로만 취급하지 않는다는 것이다. 요구 분석에 초점을 둔 접근과 코드·설계·운영 전반의 활동을 묶는 접근의 차이를 읽는다.
SSDF의 위치
NIST SSDF 1.1은 안전한 개발을 위한 고수준 실천을 다음 네 묶음으로 설명한다.
| 묶음 | 의미 |
|---|---|
| PO | 안전한 개발을 수행할 조직·사람·기술 준비 |
| PS | 소프트웨어와 관련 구성요소의 변조·무단 접근 방지 |
| PW | 보안 요구를 반영한 소프트웨어 생산 |
| RV | 발견된 취약점 대응과 재발 방지 |
이는 한 번씩 끝내는 네 개의 고정 개발 단계가 아니다. 각 개발 과정에 맞춰 반복·통합하는 실천 묶음이다. Secure SDLC의 전체 취지를 이해하는 비교 개념으로 연결한다.
5. 위협 모델링
위협 모델링은 무엇을 보호하는지 → 어디로 데이터가 흐르는지 → 무엇이 잘못될 수 있는지 → 어떻게 막고 확인할지를 설계 단계에서 살펴보는 활동이다.
자산은 보호할 데이터·기능·자원, 위협은 손해를 일으킬 수 있는 사건이나 행위, 취약점은 그 위협에 악용될 수 있는 약점, 위험은 발생 가능성과 영향을 함께 고려한 판단이다. 보완 통제 후에도 남는 위험을 잔여 위험이라고 한다.
데이터 흐름도에는 외부 개체·프로세스·저장소·데이터 흐름 등을 나타낸다. 신뢰 경계는 신뢰 수준이나 권한의 전제가 바뀌는 지점이다. 인터넷과 내부망의 경계뿐 아니라 사용자 입력이 서버의 권한 있는 처리로 들어오는 지점도 중요하다.
STRIDE는 위협을 떠올리는 데 사용하는 분류다.
| 범주 | 의미 | 연결되는 보호 관심사 |
|---|---|---|
| Spoofing | 다른 주체로 위장 | 인증 |
| Tampering | 데이터·설정 변조 | 무결성 |
| Repudiation | 행위 사실 부인 | 책임추적·부인방지 |
| Information Disclosure | 정보 노출 | 기밀성 |
| Denial of Service | 서비스 거부 | 가용성 |
| Elevation of Privilege | 권한 상승 | 인가 |
STRIDE는 위협의 분류이지 위험 점수를 계산하는 공식이 아니다. 모든 프로젝트에 동일한 위협 수와 동일한 대응을 강제하지도 않는다.
6. 분석 도구와 보안 검증
SAST(정적 분석)는 프로그램을 실행하지 않고 소스·코드 구조에서 약점을 찾고, DAST(동적 분석)는 실행되는 시스템의 반응을 살펴본다. SCA는 사용하는 외부 구성요소와 알려진 취약점 등의 정보를 확인한다.
도구마다 볼 수 있는 대상이 다르다. 정적 분석 결과가 없다고 업무 권한의 누락까지 없다고 결론 내릴 수는 없다. 위협 모델링, 코드 검토, 기능·보안 시험, 운영 점검은 상호 보완적이다.
통합 예
온라인 접수 시스템에서 ‘다른 사람의 지원서 조회’를 위협으로 식별했다고 하자. 보안 요구는 ‘본인 소유 자료만 허용’, 설계·구현은 ‘서버에서 요청자와 자료 소유자를 검사’, 시험은 ‘본인 자료는 허용하고 타인 자료는 거부’로 연결된다. 화면에서 버튼만 숨기는 방식으로는 이 요구가 충족되지 않는다.
보안 요구·위협 모델·검사 결과의 연결
범주는 위협을 빠뜨리지 않도록 돕는 분류이며 그 순서가 위험 순위나 숫자 점수를 뜻하지 않는다. 실제 우선순위는 자산·공격 가능성·영향·통제 등을 따로 검토한다. 동일 시나리오가 여러 범주와 연결될 수 있으므로 문제에서 주된 행위를 확인한다.
신뢰 경계는 인증·권한·관리 주체 등 신뢰 조건이 달라지는 곳이다. 동일 서버 내부라도 높은 권한의 프로세스로 요청이 넘어간다면 경계가 될 수 있다. 다이어그램에 네트워크 선이 있다는 이유만으로 모든 선을 같은 위험으로 취급하지 않는다.
도구 경고는 실제 입력 도달성·보호 코드·운영 조건을 대조하여 확인한다. 경고 한 건이 곧 확정된 침해 사건이라는 뜻도, 오탐 가능성이 있으니 전부 무시해도 된다는 뜻도 아니다.