NIST SP 800-218

NIST SP 800-218(Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities)은 미국 국립표준기술연구소(NIST)가 소프트웨어 개발 전 과정에 보안 활동을 통합하여 취약점의 발생과 악용 위험을 줄이기 위해 발행한 보안 소프트웨어 개발 프레임워크 지침이다.

개요

NIST SP 800-218은 소프트웨어 개발 수명주기(Software Development Life Cycle, SDLC)에 보안 개발 실무를 통합하기 위한 보안 소프트웨어 개발 프레임워크(Secure Software Development Framework, SSDF)를 정의한다.

특정 개발 방법론이나 기술을 강제하는 대신, 조직이 달성해야 할 보안 목표와 실무를 공통 체계로 정리한다. 소프트웨어 개발사뿐 아니라 소프트웨어를 구매·도입하는 조직도 공급업체의 보안 개발 수준을 평가하고 요구사항을 전달하는 데 활용할 수 있다.

주요 목적은 다음과 같다.

• 출시되는 소프트웨어의 취약점 수 감소.
• 발견되지 않았거나 해결되지 않은 취약점의 악용에 따른 피해 완화.
• 취약점의 근본 원인을 제거하여 동일한 유형의 취약점 재발 방지.
• 개발 조직과 소프트웨어 구매자 사이의 보안 요구사항 및 이행 상태에 관한 의사소통 개선.

2022년 2월 3일 발행된 SSDF 1.1이 2026년 10월 기준 최신 확정판이다. 2025년 12월 17일에는 SSDF 1.2에 해당하는 NIST SP 800-218 Revision 1 최초 공개 초안이 발표되었으나 아직 확정판으로 전환되지 않았다.

항목	내용
문서 번호	NIST SP 800-218
정식 명칭	Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities
한국어 명칭	보안 소프트웨어 개발 프레임워크 1.1: 소프트웨어 취약점 위험 완화를 위한 권고사항
발행기관	미국 국립표준기술연구소(NIST)
저자	Murugiah Souppaya, Karen Scarfone, Donna Dodson
발행일	2022년 2월 3일
최신 확정판	SSDF 1.1
개정 초안	SSDF 1.2, SP 800-218 Rev. 1
주요 분야	소프트웨어 보안, 보안 개발 수명주기, 소프트웨어 공급망 보안
구성	4개 실무 그룹, 19개 실무
주요 적용 대상	소프트웨어 개발사, 내부 개발 조직, 소프트웨어 구매·도입 조직
이전 문서	NIST CSWP 13, SSDF 1.0
관련 문서	NIST SP 800-218A, SP 800-204D, SP 800-161
공식 페이지	NIST CSRC
원문	PDF

제정 배경

기존 개발 방법론의 한계

소프트웨어 개발에는 폭포수 모델, 나선형 모델, 애자일, 데브옵스 등 다양한 개발 방법론이 사용된다.

그러나 일반적인 SDLC 모델은 보안 활동을 충분히 구체적으로 다루지 않는 경우가 많다. 개발 과정에서 보안 요구사항을 별도로 고려하지 않으면 다음 문제가 발생할 수 있다.

• 설계 단계에서 위협과 공격 표면을 충분히 검토하지 않음.
• 개발자가 취약한 코딩 관행을 반복적으로 사용.
• 외부 라이브러리와 소프트웨어 구성요소의 취약점을 파악하지 못함.
• 개발 및 빌드 환경이 침해되어 정상 소프트웨어에 악성코드가 삽입됨.
• 출시 직전에 취약점이 발견되어 수정 비용과 일정 지연이 증가.
• 출시 이후 취약점이 발견되어도 신속한 대응과 원인 분석이 어려움.

NIST는 이러한 문제를 해결하기 위해 기존 개발 방법론에 독립적으로 통합할 수 있는 보안 개발 실무를 정리하였다.

시프트 레프트

시프트 레프트(Shift Left)는 소프트웨어 개발의 초기 단계부터 보안을 고려하는 접근법이다.

일반적으로 취약점이 개발 후반이나 운영 단계에서 발견되면 설계 변경, 코드 수정, 재시험, 재배포 등의 추가 작업이 발생한다.

따라서 개발 초기부터 다음 활동을 수행하도록 권고한다.

• 보안 요구사항 정의.
• 위협 모델링.
• 보안 아키텍처 검토.
• 시큐어 코딩.
• 코드 검토 및 정적 분석.
• 개발 과정의 자동화된 보안 검사.

다만 시프트 레프트가 출시 이후의 보안 활동을 생략한다는 의미는 아니다. SSDF는 출시 이후의 취약점 탐지·대응·근본 원인 분석까지 포함한다.

미국 연방정부의 소프트웨어 공급망 보안 강화

2021년 5월 12일 미국은 행정명령 EO 14028(Improving the Nation's Cybersecurity)을 발표하였다.

이 행정명령의 제4절은 소프트웨어 공급망 보안 강화를 다루며, 연방정부에 공급되는 소프트웨어의 보안 개발 관행과 관련된 지침 수립을 요구하였다.

NIST는 이에 대응하여 SSDF 1.1을 발행하고, 부록 A에 EO 14028 제4절의 세부 요구사항과 SSDF 실무 사이의 대응 관계를 수록하였다.

SSDF는 행정명령과 연계되어 개발되었지만, 그 자체가 모든 소프트웨어 개발사에 직접적인 법적 의무를 부과하는 규정은 아니다. 실제 준수 의무는 적용되는 법령·정책·계약에 따라 달라진다.

목적 및 적용 범위

적용 대상

SSDF는 조직의 규모, 산업, 개발 방법론과 관계없이 활용할 수 있도록 설계되었다.

주요 대상은 다음과 같다.

• 상용 소프트웨어 개발사.
• 정부용 소프트웨어 개발 조직.
• 기업 내부 개발팀.
• 외부 개발 용역업체.
• 오픈소스 소프트웨어 개발 조직.
• 소프트웨어를 구매하거나 도입하는 공공기관 및 민간기업.
• 소프트웨어 개발·배포 플랫폼 제공업체.

소프트웨어 개발 조직과 구매 조직은 SSDF를 서로 다른 목적으로 활용한다.

구분	활용 목적
개발 조직	보안 개발 활동을 정의하고 실제 개발 과정에 통합
개발 조직의 관리자	역할·책임·교육·도구·보안 기준 관리
보안 담당자	보안 요구사항 수립, 개발환경 보호, 보안 검증
구매 조직	공급업체의 보안 개발 관행 확인 및 계약 요구사항 정의
운영 조직	소프트웨어 구성요소와 취약점 정보 확보, 출시 이후 대응

적용 가능한 소프트웨어

SSDF는 특정 기술이나 프로그래밍 언어에 종속되지 않는다.

다음 소프트웨어에 적용할 수 있다.

• 웹 애플리케이션.
• 모바일 애플리케이션.
• 데스크톱 소프트웨어.
• 서버 및 클라우드 애플리케이션.
• 운영체제와 시스템 소프트웨어.
• 펌웨어.
• 사물인터넷(IoT) 소프트웨어.
• 산업제어시스템(ICS) 소프트웨어.
• 사이버물리시스템(CPS) 소프트웨어.

컴파일러를 사용하지 않는 개발 환경에서는 컴파일러 보안 설정에 관한 실무가 적용되지 않을 수 있다.

이처럼 조직은 개발 환경과 위험을 고려하여 관련성이 있는 실무를 선정하고 구현해야 한다.

결과 중심의 프레임워크

SSDF는 특정 보안 도구의 사용을 일률적으로 요구하지 않는다.

예를 들어 소스코드의 취약점을 식별해야 한다는 목표는 제시하지만, 특정 상용 정적 분석 도구를 구매하도록 요구하지는 않는다.

조직은 다음 요소를 고려하여 구현 방법을 결정한다.

• 소프트웨어의 위험 수준.
• 조직의 보안 목표.
• 개발 기술과 운영 환경.
• 비용과 구현 가능성.
• 보유 인력과 기술 역량.
• 자동화 가능성.
• 적용되는 법적·계약상 요구사항.

NIST는 SSDF를 모든 항목을 기계적으로 확인하는 체크리스트가 아니라 위험 기반 보안 개발체계를 수립하고 개선하기 위한 기반으로 설명한다.

프레임워크 구조

SSDF 1.1은 보안 개발 실무를 4개 그룹으로 분류한다.

그룹	영문	한국어	주요 목적
PO	Prepare the Organization	조직 준비	인력·프로세스·기술을 보안 개발에 적합하게 준비
PS	Protect the Software	소프트웨어 보호	소프트웨어 구성요소의 무단 접근 및 변조 방지
PW	Produce Well-Secured Software	안전한 소프트웨어 생산	취약점이 최소화된 소프트웨어 개발
RV	Respond to Vulnerabilities	취약점 대응	잔존 취약점 식별·조치 및 재발 방지

각 그룹에는 여러 실무(Practice)가 포함되며, 실무는 다시 세부 작업(Task)으로 구성된다.

실무의 구성 요소

SSDF의 각 실무는 다음 요소로 정의된다.

요소	영문	설명
실무	Practice	수행해야 할 보안 개발 활동과 목적
작업	Task	실무를 수행하기 위해 필요한 구체적인 활동
구현 예시	Notional Implementation Example	작업을 구현할 수 있는 도구·절차·기술의 예시
참고자료	Reference	관련 보안 개발 표준·지침과 대응 관계

구현 예시는 규범적인 필수 요구사항이 아니다.

예를 들어 NIST가 특정 작업의 구현 예시로 도구나 기술을 제시하더라도 모든 조직이 해당 도구를 반드시 사용해야 하는 것은 아니다.

또한 표에 나열된 실무의 순서는 구현 순서나 상대적인 중요도를 나타내지 않는다.

전체 실무 목록

SSDF 1.1은 4개 그룹에 걸쳐 19개 실무를 정의한다.

그룹	번호	영문 명칭	주요 내용
PO	PO.1	Define Security Requirements for Software Development	소프트웨어 개발 보안 요구사항 정의
PO	PO.2	Implement Roles and Responsibilities	보안 개발 역할과 책임 수립
PO	PO.3	Implement Supporting Toolchains	보안 개발 도구 체계 구축
PO	PO.4	Define and Use Criteria for Software Security Checks	소프트웨어 보안 검사 기준 정의 및 적용
PO	PO.5	Implement and Maintain Secure Environments for Software Development	안전한 개발환경 구축 및 유지
PS	PS.1	Protect All Forms of Code from Unauthorized Access and Tampering	코드의 무단 접근 및 변조 방지
PS	PS.2	Provide a Mechanism for Verifying Software Release Integrity	소프트웨어 배포본의 무결성 검증 수단 제공
PS	PS.3	Archive and Protect Each Software Release	배포본과 관련 정보의 안전한 보관
PW	PW.1	Design Software to Meet Security Requirements and Mitigate Security Risks	보안 요구사항과 위험을 고려한 설계
PW	PW.2	Review the Software Design to Verify Compliance with Security Requirements and Risk Information	소프트웨어 설계 보안 검토
PW	PW.4	Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality	검증된 소프트웨어 구성요소 재사용
PW	PW.5	Create Source Code by Adhering to Secure Coding Practices	시큐어 코딩 실무 적용
PW	PW.6	Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security	컴파일·인터프리터·빌드 보안 강화
PW	PW.7	Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements	소스코드 검토 및 분석
PW	PW.8	Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements	실행 가능한 코드의 보안 시험
PW	PW.9	Configure Software to Have Secure Settings by Default	안전한 기본 보안 설정
RV	RV.1	Identify and Confirm Vulnerabilities on an Ongoing Basis	지속적인 취약점 식별 및 확인
RV	RV.2	Assess, Prioritize, and Remediate Vulnerabilities	취약점 평가·우선순위 결정·조치
RV	RV.3	Analyze Vulnerabilities to Identify Their Root Causes	취약점 근본 원인 분석

PW.3은 이전 초안에서 PW.4로 통합되었기 때문에 SSDF 1.1에는 독립적인 PW.3 실무가 존재하지 않는다.

조직 준비(PO)

보안 요구사항 정의(PO.1)

PO.1은 소프트웨어 개발에 필요한 보안 요구사항을 식별·문서화하고 지속적으로 유지하는 실무이다.

주요 작업은 다음과 같다.

• PO.1.1: 조직의 소프트웨어 개발 인프라와 프로세스에 적용되는 보안 요구사항 식별·문서화.
• PO.1.2: 조직이 개발하는 소프트웨어에 적용되는 보안 요구사항 식별·문서화.
• PO.1.3: 외부 소프트웨어 구성요소 공급업체에 보안 요구사항 전달.

보안 요구사항에는 조직 내부의 보안 정책뿐 아니라 법률·규정·계약상 의무도 포함될 수 있다.

개발 조직은 요구사항을 프로젝트별로 반복해서 작성하기보다 공통 요구사항을 관리하고 필요한 부분을 재사용할 수 있다.

역할과 책임(PO.2)

PO.2는 소프트웨어 개발 과정에 참여하는 인력의 보안 관련 역할과 책임을 정의한다.

주요 작업은 다음과 같다.

• PO.2.1: 보안 개발에 필요한 역할과 책임 정의 및 정기적인 검토.
• PO.2.2: 역할별 보안 교육 제공과 역량 평가.
• PO.2.3: 경영진의 보안 개발에 대한 책임과 지원 확보.

역할에는 개발자, 설계자, 보안 담당자, 코드 소유자, 빌드·배포 관리자 등이 포함될 수 있다.

예를 들어 코드 소유자를 지정하고 해당 소유자가 코드 변경을 검토·승인하도록 할 수 있다.

보안 개발의 책임을 특정 보안 부서에만 집중시키지 않고 개발 과정에 참여하는 조직 전체에 분배하는 것이 중요하다.

지원 도구 체계(PO.3)

PO.3은 개발 과정에 자동화 도구를 통합하여 보안 활동의 정확성·재현성·추적성을 높이는 실무이다.

주요 작업은 다음과 같다.

• PO.3.1: 필요한 도구와 도구 유형, 도구 사이의 연계 방법 정의.
• PO.3.2: 도구와 도구 체계의 안전한 배포·운영·유지.
• PO.3.3: 보안 개발 활동의 수행을 입증하는 산출물을 생성하도록 도구 구성.

대표적인 도구는 다음과 같다.

• 소스코드 형상관리 시스템.
• 정적 애플리케이션 보안 테스트(SAST).
• 동적 애플리케이션 보안 테스트(DAST).
• 소프트웨어 구성 분석(SCA).
• 취약점 및 이슈 관리 시스템.
• CI/CD 파이프라인.
• 코드 서명 및 무결성 검증 도구.
• 빌드 산출물 저장소.

NIST는 자동화 도구 자체도 보안 위협의 대상이 될 수 있으므로 도구의 무결성, 접근 권한, 운영 로그 등을 관리하도록 권고한다.

보안 검사 기준(PO.4)

PO.4는 소프트웨어가 조직의 보안 요구사항을 충족하는지 판단하기 위한 기준을 정의한다.

주요 작업은 다음과 같다.

• PO.4.1: 소프트웨어 보안 검사 기준 정의.
• PO.4.2: 기준 적용에 필요한 정보를 수집하고 보호하는 절차 구현.

보안 검사 기준에는 다음 사항이 포함될 수 있다.

• 허용 가능한 취약점 심각도.
• 보안 요구사항 충족 여부.
• 코드 검토 완료 여부.
• 보안 시험 결과.
• 외부 구성요소의 취약점 상태.
• 보안 위험에 대한 예외 승인 여부.

이러한 기준은 CI/CD 파이프라인의 품질 게이트(Quality Gate)로 구현할 수 있다.

예를 들어 조직이 정의한 수준 이상의 취약점이 발견되면 자동으로 배포를 중단하고, 승인된 예외사항은 별도의 기록과 함께 처리할 수 있다.

안전한 개발환경(PO.5)

PO.5는 소프트웨어 개발·빌드·시험·배포 환경을 내부 및 외부 위협으로부터 보호하는 실무이다.

주요 작업은 다음과 같다.

• PO.5.1: 개발에 사용되는 각 환경을 분리하고 보호.
• PO.5.2: 개발자 단말과 개발용 엔드포인트의 보안 강화.

대표적인 보호조치는 다음과 같다.

• 개발·시험·운영 환경 분리.
• 다중 인증(MFA) 적용.
• 최소 권한 접근통제.
• 개발 서버와 빌드 서버의 네트워크 분리.
• 개발 도구와 구성요소의 무결성 검증.
• 개발환경의 취약점 점검 및 패치.
• 개발자 단말의 보안 상태 모니터링.
• 개발·빌드 환경의 감사 기록 수집.

특히 개발환경이 침해되면 정상적인 소프트웨어 배포 경로를 이용하여 악성코드가 배포될 수 있다.

따라서 소프트웨어 자체의 취약점 검사뿐 아니라 소프트웨어를 생산하는 환경의 보호도 필요하다.

소프트웨어 보호(PS)

코드 보호(PS.1)

PS.1은 소스코드, 실행 파일, 설정 코드 등 모든 형태의 코드를 무단 접근과 변조로부터 보호한다.

주요 작업은 다음과 같다.

• PS.1.1: 모든 형태의 코드를 최소 권한 원칙에 따라 저장하고 접근 제한.

대표적인 구현 방법은 다음과 같다.

• 소스코드 저장소 접근 권한 관리.
• 코드 변경 이력과 변경자 추적.
• 승인되지 않은 코드 변경 차단.
• 코드 소유자의 변경 검토 및 승인.
• 커밋 서명.
• 실행 파일의 코드 서명.
• 암호학적 해시를 이용한 무결성 확인.

공개 소스코드는 기밀성 보호가 필요하지 않을 수 있지만, 무결성과 가용성 보호는 여전히 중요하다.

배포본 무결성 검증(PS.2)

PS.2는 소프트웨어 구매자가 배포받은 소프트웨어의 정당성과 무결성을 검증할 수 있도록 하는 실무이다.

주요 작업은 다음과 같다.

• PS.2.1: 소프트웨어 배포본의 무결성 검증 정보 제공.

대표적인 구현 방법은 다음과 같다.

• 배포 파일의 암호학적 해시 제공.
• 코드 서명 및 디지털 서명 검증.
• 신뢰할 수 있는 인증서를 이용한 서명.
• 코드 서명 인증서의 갱신·교체·폐기 관리.

예를 들어 소프트웨어 개발사가 배포 파일에 디지털 서명을 적용하면 사용자는 해당 파일이 배포 이후 변조되었는지 확인할 수 있다.

다만 디지털 서명은 소프트웨어에 취약점이 없음을 보증하지 않는다. 서명된 소프트웨어라도 개발 과정에서 취약점이나 악성 기능이 포함될 수 있다.

배포본 보관 및 보호(PS.3)

PS.3은 출시 이후 취약점이 발견되었을 때 조사와 대응에 필요한 정보를 확보하기 위해 배포본을 안전하게 보관하는 실무이다.

주요 작업은 다음과 같다.

• PS.3.1: 각 배포본과 관련 무결성·출처 정보를 안전하게 보관.
• PS.3.2: 배포본을 구성하는 모든 구성요소의 출처 정보 수집·보호·유지·공유.

보관 대상에는 다음 정보가 포함될 수 있다.

• 소프트웨어 배포 파일.
• 배포 버전.
• 빌드 산출물.
• 무결성 검증 정보.
• 소프트웨어 구성요소 정보.
• 구성요소의 출처 및 변경 이력.
• 소프트웨어 자재명세서(SBOM).

이러한 정보는 취약점이 발견되었을 때 영향을 받는 배포본과 구성요소를 식별하는 데 활용된다.

소프트웨어 자재명세서와 출처 증명

SBOM

SBOM(Software Bill of Materials)은 소프트웨어를 구성하는 패키지·라이브러리·모듈 등 구성요소에 관한 목록이다.

SSDF 1.1의 PS.3.2는 각 배포본의 구성요소에 대한 출처 정보(Provenance Data)를 수집·보호·유지·공유하도록 권고한다.

SBOM은 이러한 출처 정보를 관리하는 수단의 하나로 활용할 수 있다.

대표적인 정보는 다음과 같다.

• 구성요소 이름.
• 구성요소 버전.
• 구성요소 공급자.
• 구성요소 사이의 의존 관계.
• 구성요소 식별자.
• 관련 라이선스 및 기타 메타데이터.

SBOM을 이용하면 특정 라이브러리에서 취약점이 발견되었을 때 해당 라이브러리를 사용하는 소프트웨어를 신속하게 식별할 수 있다.

그러나 SBOM을 생성했다는 사실만으로 소프트웨어가 안전하다고 판단할 수는 없다.

SBOM의 정확성, 최신성 및 구성요소의 실제 취약점 상태를 별도로 검토해야 한다.

출처 정보

출처 정보(Provenance Data)는 소프트웨어나 구성요소의 생성·변경·소유·이동 등에 관한 이력을 의미한다.

예를 들어 다음 정보를 포함할 수 있다.

• 소스코드의 출처.
• 빌드에 사용된 구성요소.
• 빌드 환경과 도구.
• 배포본 생성 과정.
• 구성요소 변경 이력.
• 소프트웨어 공급업체와 관련 정보.

SBOM과 출처 증명은 서로 관련되지만 동일한 개념은 아니다.

SBOM은 주로 소프트웨어를 구성하는 요소의 목록과 관계를 설명한다.

출처 증명은 해당 구성요소나 산출물이 어떤 과정을 거쳐 생성·변경되었는지를 설명한다.

출처 정보의 보호

SSDF는 출처 정보를 수집하는 것뿐 아니라 해당 정보의 무결성을 보호하도록 권고한다.

대표적인 방법은 다음과 같다.

• 출처 정보에 디지털 서명 적용.
• 배포 파일과 출처 정보의 무결성 검증.
• 출처 정보에 대한 접근통제.
• 구성요소 변경 시 출처 정보 갱신.
• 구매 조직 및 운영 조직에 필요한 정보 제공.

출처 정보 자체가 변조되면 취약점 조사와 공급망 보안 평가의 신뢰성이 저하될 수 있다.

안전한 소프트웨어 생산(PW)

보안 설계(PW.1)

PW.1은 보안 요구사항과 예상 위험을 고려하여 소프트웨어를 설계하는 실무이다.

주요 작업은 다음과 같다.

• PW.1.1: 위협 모델링, 공격 모델링, 공격 표면 분석 등 위험 모델링 수행.
• PW.1.2: 보안 요구사항·위험·설계 결정의 추적 및 유지.
• PW.1.3: 표준화된 보안 기능과 서비스의 활용을 고려한 설계.

위협 모델링에서는 다음 사항을 검토할 수 있다.

• 보호해야 할 자산.
• 시스템의 신뢰 경계.
• 외부 입력과 데이터 흐름.
• 인증 및 권한 관리 구조.
• 예상 공격자와 공격 경로.
• 위험 완화조치.

설계 과정에서 수용한 위험이나 보안 요구사항의 예외사항은 근거를 문서화해야 한다.

설계 검토(PW.2)

PW.2는 소프트웨어 설계가 보안 요구사항을 충족하고 식별된 위험을 적절히 처리하는지 검토한다.

주요 작업은 다음과 같다.

• PW.2.1: 설계에 참여하지 않은 적격 인력 또는 자동화된 절차를 이용한 보안 설계 검토.

검토 결과에는 다음 정보가 포함될 수 있다.

• 발견된 설계상 취약점.
• 보안 요구사항 미충족 사항.
• 위험 대응의 적절성.
• 설계 변경 필요성.
• 승인된 예외사항.

설계 검토는 구현된 소스코드의 오류를 찾는 코드 검토와 구분된다.

예를 들어 인증 우회가 가능한 시스템 구조는 개별 코드가 정상적으로 작성되었더라도 설계 검토에서 발견될 수 있다.

안전한 구성요소 재사용(PW.4)

PW.4는 이미 검증된 소프트웨어 구성요소를 재사용하여 새로운 취약점의 발생 가능성을 줄이는 실무이다.

주요 작업은 다음과 같다.

• PW.4.1: 상용·오픈소스 등 외부 소프트웨어 구성요소를 평가하고 안전하게 확보·유지.
• PW.4.2: 자체 개발한 구성요소를 안전하게 재사용.
• PW.4.4: 외부 소프트웨어 구성요소가 조직의 보안 요구사항을 충족하는지 확인.

PW.4.3은 이전 초안에서 PW.1.3으로 이동하였으며, PW.4.5는 PW.4.4에 통합되었다.

대표적인 검토사항은 다음과 같다.

• 구성요소의 알려진 취약점.
• 공급업체의 유지보수 상태.
• 지원 종료 여부.
• 구성요소의 출처와 무결성.
• 보안 업데이트 제공 여부.
• 실제 사용 목적에 따른 위험.

외부 구성요소는 도입 시점뿐 아니라 사용 기간 전체에 걸쳐 관리해야 한다.

시큐어 코딩(PW.5)

PW.5는 프로그래밍 언어와 개발 환경에 적합한 시큐어 코딩 관행을 적용하는 실무이다.

주요 작업은 다음과 같다.

• PW.5.1: 조직의 보안 요구사항에 적합한 시큐어 코딩 실무 적용.

대표적인 구현 예시는 다음과 같다.

• 입력값 검증.
• 출력값의 적절한 인코딩.
• 안전하지 않은 함수 사용 방지.
• 오류와 예외의 안전한 처리.
• 보안 관련 로깅과 추적 기능.
• 언어별 주요 취약점 예방.
• 정적 분석 도구와 린터 활용.
• 개발자 자신의 코드 검토.

예를 들어 사용자 입력을 데이터베이스 질의에 직접 연결하지 않고 매개변수화된 질의를 사용하면 SQL 인젝션 위험을 줄일 수 있다.

다만 이러한 개별 기술은 SSDF의 구현 예시이며, SSDF 자체가 특정 프로그래밍 언어나 코딩 표준을 지정하는 것은 아니다.

컴파일 및 빌드 보안(PW.6)

PW.6은 컴파일러·인터프리터·빌드 도구의 보안 기능을 활용하여 실행 파일의 취약점을 줄이는 실무이다.

주요 작업은 다음과 같다.

• PW.6.1: 실행 파일의 보안을 강화하는 기능을 제공하는 컴파일러·인터프리터·빌드 도구 사용.
• PW.6.2: 해당 도구의 보안 기능과 설정을 선정하고 승인된 구성을 적용.

대표적인 구현 방법은 다음과 같다.

• 최신 컴파일러 및 빌드 도구 사용.
• 컴파일러의 보안 경고 기능 활성화.
• 메모리 보호 기능 활용.
• 실행 파일 보안 강화 옵션 적용.
• 빌드 설정의 변경관리.
• 빌드 과정의 오류 및 경고 확인.

컴파일러의 보안 기능은 소프트웨어 취약점을 완전히 제거하지는 못하지만 일부 취약점의 발생과 악용 가능성을 줄일 수 있다.

코드 검토 및 분석(PW.7)

PW.7은 사람이 읽을 수 있는 코드를 검토·분석하여 취약점을 식별하는 실무이다.

주요 작업은 다음과 같다.

• PW.7.1: 코드 검토 또는 코드 분석의 필요성과 적용 방법 결정.
• PW.7.2: 코드 검토·분석 수행, 발견된 문제 기록 및 분류.

대표적인 방법은 다음과 같다.

• 동료 코드 검토.
• 보안 전문가의 코드 검토.
• 정적 애플리케이션 보안 테스트(SAST).
• 자동화된 코드 분석.
• 시큐어 코딩 표준 준수 여부 확인.

코드 검토와 코드 분석은 서로 다른 활동이다.

• 코드 검토(Code Review): 사람이 코드를 직접 확인하여 문제를 찾는 활동.
• 코드 분석(Code Analysis): 도구를 이용하여 코드의 잠재적 문제를 탐지하는 활동.

자동화 도구는 반복적인 검사를 수행하는 데 유용하지만 오탐과 미탐이 발생할 수 있으므로 결과를 적절히 검토해야 한다.

실행 코드 보안 시험(PW.8)

PW.8은 실행 가능한 코드를 시험하여 앞선 검토에서 발견하지 못한 취약점을 식별하는 실무이다.

주요 작업은 다음과 같다.

• PW.8.1: 실행 코드 시험의 필요성과 시험 유형 결정.
• PW.8.2: 시험 범위·시험 방법 설계, 시험 수행, 결과 기록 및 조치.

대표적인 시험 방법은 다음과 같다.

• 동적 애플리케이션 보안 테스트(DAST).
• 퍼징(Fuzzing).
• 침투 테스트.
• 보안 기능 시험.
• 취약점 재현 시험.
• 자동화된 보안 회귀시험.

PW.7과 PW.8은 다음과 같이 구분된다.

구분	PW.7	PW.8
주요 대상	사람이 읽을 수 있는 코드	실행 가능한 코드
주요 방법	코드 검토, 정적 분석	실행 기반 시험, 동적 분석
대표적인 도구	SAST, 코드 검토 도구	DAST, 퍼저
주요 목적	코드 수준의 취약점 식별	실행 과정에서 나타나는 취약점 식별

두 실무는 상호 보완적이다.

정적 분석에서 발견되지 않은 취약점이 실행 중 시험에서 발견될 수 있으며, 반대로 실행 시험만으로 확인하기 어려운 코드상의 문제를 정적 분석에서 발견할 수도 있다.

안전한 기본 설정(PW.9)

PW.9는 소프트웨어가 최초 설치 또는 실행될 때 안전한 설정을 기본값으로 사용하도록 하는 실무이다.

주요 작업은 다음과 같다.

• PW.9.1: 보안 관련 설정의 안전한 기준선 정의.
• PW.9.2: 기본 설정을 구현하고 관리자에게 필요한 설정 정보를 문서화.

대표적인 구현 예시는 다음과 같다.

• 불필요한 기능의 기본 비활성화.
• 안전한 인증 및 접근통제 설정.
• 안전한 통신 설정.
• 디버그 기능의 운영 환경 비활성화.
• 보안 설정 변경의 추적.
• 기본 설정의 자동화된 검증.

기본 설정이 안전하지 않으면 소프트웨어를 도입하는 조직이 별도로 보안 설정을 변경해야 한다.

따라서 개발사가 안전한 기본값을 제공하면 배포 이후 발생할 수 있는 설정 오류를 줄일 수 있다.

취약점 대응(RV)

지속적인 취약점 식별(RV.1)

RV.1은 출시 이후에도 소프트웨어와 외부 구성요소의 취약점을 지속적으로 식별하고 확인하는 실무이다.

주요 작업은 다음과 같다.

• RV.1.1: 사용자·구매자·공개 정보원 등으로부터 취약점 정보를 수집하고 신뢰할 수 있는 보고를 조사.
• RV.1.2: 코드 검토·분석·시험을 통해 기존에 발견되지 않은 취약점 식별.
• RV.1.3: 취약점 공개 및 조치 정책 수립과 운영.

대표적인 정보원은 다음과 같다.

• 취약점 데이터베이스.
• 보안 권고문.
• 소프트웨어 공급업체의 보안 공지.
• 보안 연구자의 취약점 제보.
• 사용자와 고객의 오류 보고.
• 자체 보안 시험 결과.

취약점 신고 절차는 외부 연구자가 쉽게 확인할 수 있도록 제공하는 것이 바람직하다.

취약점 평가 및 조치(RV.2)

RV.2는 발견된 취약점의 위험을 평가하고 우선순위를 결정하여 적절히 조치하는 실무이다.

주요 작업은 다음과 같다.

• RV.2.1: 취약점의 위험을 분석하고 대응 계획 수립.
• RV.2.2: 위험에 적합한 대응조치 계획 및 실행.

취약점 대응에서는 다음 요소를 고려할 수 있다.

• 취약점의 기술적 심각도.
• 실제 악용 가능성.
• 영향을 받는 소프트웨어 버전.
• 노출된 공격 표면.
• 취약점 악용 시 예상 피해.
• 수정 및 완화조치의 가능성.

대응 방법에는 취약점 수정뿐 아니라 위험 수용, 위험 이전 및 다른 완화조치도 포함될 수 있다.

다만 위험을 수용하거나 다른 방식으로 처리하는 경우에는 해당 결정의 근거를 기록하고 적절한 승인 절차를 거쳐야 한다.

근본 원인 분석(RV.3)

RV.3은 발견된 취약점의 근본 원인을 분석하여 동일한 유형의 취약점이 반복적으로 발생하지 않도록 하는 실무이다.

주요 작업은 다음과 같다.

• RV.3.1: 발견된 취약점의 근본 원인 분석.
• RV.3.2: 여러 취약점의 근본 원인을 분석하여 반복적인 패턴 식별.
• RV.3.3: 동일한 유형의 취약점이 다른 코드에도 존재하는지 검토하고 선제적으로 수정.
• RV.3.4: 재발 방지를 위해 개발 수명주기와 관련 절차 개선.

예를 들어 SQL 인젝션 취약점이 발견되었을 때 해당 취약점만 수정하는 것으로 대응을 종료하지 않는다.

다음 사항을 추가로 검토할 수 있다.

• 동일한 코딩 방식이 다른 부분에도 사용되었는가?
• 시큐어 코딩 기준이 적절하게 수립되어 있는가?
• 정적 분석 도구가 해당 취약점을 탐지할 수 있었는가?
• 코드 검토 과정에서 취약점을 발견하지 못한 이유는 무엇인가?
• 개발 도구나 검토 절차를 변경하면 재발을 방지할 수 있는가?

이러한 활동은 개별 취약점의 수정에서 나아가 취약점 유형 전체를 줄이는 데 목적이 있다.

개발 수명주기별 적용

SSDF의 실무는 특정 개발 단계에만 적용되는 것이 아니라 전체 개발 수명주기에 걸쳐 수행된다.

다음 표는 일반적인 개발 단계와 SSDF 실무를 대응시킨 예시이다.

개발 단계	주요 보안 활동	관련 SSDF 실무
기획	보안 요구사항 정의, 역할과 책임 지정	PO.1, PO.2
설계	위협 모델링, 보안 아키텍처 검토	PW.1, PW.2
개발	시큐어 코딩, 안전한 구성요소 사용	PW.4, PW.5
빌드	빌드 환경 보호, 보안 컴파일 설정	PO.5, PW.6
검토	코드 검토, 정적 분석	PW.7
시험	동적 분석, 퍼징, 보안 기능 검증	PW.8
배포	배포본 무결성 검증, 안전한 기본 설정	PS.2, PW.9
운영	취약점 모니터링 및 대응	RV.1, RV.2
개선	근본 원인 분석, 개발 절차 개선	RV.3

이 표는 이해를 돕기 위한 예시이며, NIST가 규정한 필수적인 구현 순서를 의미하지 않는다.

예를 들어 코드 분석은 개발 중에도 수행할 수 있고, 취약점 정보는 설계 단계의 위험 분석에도 활용할 수 있다.

데브섹옵스와의 관계

데브섹옵스(DevSecOps)는 개발·보안·운영 활동을 통합하고 보안 검사를 자동화하여 지속적인 개발과 배포 과정에 반영하는 접근법이다.

SSDF와 데브섹옵스는 밀접하게 관련되어 있지만 동일한 개념은 아니다.

구분	SSDF	데브섹옵스
주요 성격	보안 개발 실무 프레임워크	개발·보안·운영 통합 방법론
주요 목적	보안 개발에서 달성해야 할 실무와 결과 정의	보안 활동을 개발·운영 흐름에 지속적으로 통합
기술 종속성	특정 도구와 기술에 독립적	CI/CD와 자동화 도구를 적극적으로 활용
적용 범위	다양한 SDLC 모델	주로 지속적 개발·배포 환경
주요 결과	보안 개발 실무의 체계적 구현	자동화된 보안 검사와 빠른 피드백

예를 들어 SSDF의 PW.7은 코드 검토 및 분석을 수행하도록 권고한다.

데브섹옵스 환경에서는 이를 CI/CD 파이프라인에 SAST를 통합하는 방식으로 구현할 수 있다.

또한 SSDF의 PO.5는 개발환경을 보호하도록 권고하며, 데브섹옵스 환경에서는 빌드 서버 격리, 개발자 계정의 다중 인증, 파이프라인 접근통제 등으로 구현할 수 있다.

따라서 SSDF는 보안 개발에서 수행해야 할 활동을 정의하고, 데브섹옵스는 이를 지속적으로 수행하는 운영 방식의 하나로 활용할 수 있다.

소프트웨어 공급망 보안과의 관계

SSDF는 개발 조직 내부의 코드 보안뿐 아니라 외부 소프트웨어 구성요소와 개발·배포 과정의 무결성도 다룬다.

특히 다음 실무가 공급망 보안과 밀접하게 관련된다.

• PO.1.3: 외부 공급업체에 보안 요구사항 전달.
• PO.5: 개발·빌드·배포 환경 보호.
• PS.1: 코드의 무단 접근 및 변조 방지.
• PS.2: 배포본의 무결성 검증.
• PS.3: 배포본 및 출처 정보의 보호.
• PW.4: 외부 소프트웨어 구성요소의 보안 검증.
• RV.1: 외부 구성요소의 취약점 정보 수집.

소프트웨어 공급망 공격은 정상적인 개발·빌드·배포 경로를 악용할 수 있으므로 완성된 소프트웨어의 취약점 검사만으로는 충분하지 않다.

개발에 사용되는 구성요소와 도구, 빌드 환경, 배포본 및 출처 정보까지 보호해야 한다.

소프트웨어 구매 및 공급업체 평가

SSDF는 소프트웨어 개발사뿐 아니라 구매 조직을 위한 공통 언어를 제공한다.

구매 조직은 공급업체가 어떤 보안 개발 실무를 수행하는지 확인하고 계약에 필요한 요구사항을 반영할 수 있다.

대표적인 확인사항은 다음과 같다.

• 보안 개발 정책이 수립되어 있는가?
• 개발자의 보안 역할과 책임이 정의되어 있는가?
• 보안 개발 교육이 이루어지는가?
• 개발환경과 코드 저장소에 접근통제가 적용되는가?
• 코드 검토와 보안 시험을 수행하는가?
• 외부 소프트웨어 구성요소를 관리하는가?
• 배포본의 무결성을 검증할 수 있는가?
• SBOM 등 구성요소 정보를 제공할 수 있는가?
• 취약점 신고 및 조치 절차가 존재하는가?
• 발견된 취약점의 근본 원인을 분석하는가?

이행 증빙

공급업체의 SSDF 이행 여부를 확인하기 위해 다음 자료를 활용할 수 있다.

평가 영역	증빙 자료 예시
보안 요구사항	보안 요구사항 명세서, 보안 정책
역할과 책임	역할 정의서, 교육 기록
개발환경 보호	접근통제 설정, 개발환경 구성 기록
코드 보호	코드 저장소 권한, 변경 승인 기록
보안 설계	위협 모델, 설계 검토 기록
코드 분석	코드 검토 결과, 정적 분석 보고서
보안 시험	동적 분석 결과, 퍼징 결과
구성요소 관리	SBOM, 구성요소 취약점 분석 결과
배포 무결성	코드 서명, 해시, 출처 증명
취약점 대응	취약점 관리 기록, 수정 이력
재발 방지	근본 원인 분석 보고서, 개발 절차 개선 기록

이 표는 SSDF 실무를 평가하기 위한 증빙 예시이며, NIST SP 800-218이 모든 항목에 대해 동일한 증빙 문서 제출을 의무화한 것은 아니다.

관련 NIST 문서와의 차이

NIST SP 800-204D

NIST SP 800-204D는 Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines라는 제목으로 2024년 2월 12일 발행되었다.

두 문서는 다음과 같이 구분된다.

• SP 800-218: 소프트웨어 개발 전반에 적용할 보안 개발 실무를 정의.
• SP 800-204D: 데브섹옵스 CI/CD 파이프라인에 소프트웨어 공급망 보안을 통합하는 전략을 설명.

SP 800-204D는 소프트웨어 공급망의 산출물, 출처 증명, 빌드·배포 과정 등의 보호를 보다 구체적으로 다룬다.

NIST SP 800-161

NIST SP 800-161은 조직과 정보시스템의 사이버보안 공급망 위험관리(Cybersecurity Supply Chain Risk Management, C-SCRM)를 다룬다.

2026년 10월 기준 현행 확정판은 2024년 11월 갱신사항을 반영한 Revision 1이다.

두 문서는 다음과 같이 구분된다.

• SP 800-161: 조직 차원의 공급망 위험 식별·평가·관리.
• SP 800-218: 소프트웨어 개발 과정에 적용하는 보안 개발 실무.

SP 800-161은 소프트웨어뿐 아니라 하드웨어와 서비스 등 보다 넓은 공급망 위험을 다룬다.

NIST SP 800-218A

NIST SP 800-218A는 Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile이라는 제목으로 2024년 7월 26일 발행되었다.

이 문서는 SSDF 1.1을 기반으로 생성형 인공지능과 이중용도 기반모델(Dual-Use Foundation Model)의 개발에 특화된 보안 실무를 추가한다.

주요 대상은 다음과 같다.

• 인공지능 모델 개발사.
• 인공지능 모델을 사용하는 시스템 개발사.
• 인공지능 시스템 구매·도입 조직.

기존 SSDF에 인공지능 모델 개발과 관련된 추가 실무, 작업, 권고사항, 고려사항 및 참고자료를 제공한다.

예를 들어 다음과 같은 영역을 고려할 수 있다.

• 학습 데이터와 모델의 보호.
• 모델 개발환경의 보안.
• 외부 모델과 데이터의 출처 관리.
• 인공지능 모델의 취약점 식별.
• 모델 개발 과정의 보안 검증.

SP 800-218A는 SP 800-218을 대체하는 문서가 아니라 함께 활용하는 보완 문서이다.

개정 및 현행 상태

발행 이력

날짜	문서	주요 내용
2020년 4월 23일	NIST CSWP 13	SSDF 1.0 최초 발표
2021년 9월 30일	SP 800-218 공개 초안	SSDF 1.1 개정안 공개
2022년 2월 3일	SP 800-218 확정판	SSDF 1.1 확정
2024년 7월 26일	SP 800-218A 확정판	생성형 AI 및 이중용도 기반모델을 위한 커뮤니티 프로파일 발표
2025년 12월 17일	SP 800-218 Revision 1 최초 공개 초안	SSDF 1.2 개정안 공개
2026년 1월 30일	Revision 1 의견 수렴 종료	공개 초안에 대한 의견 수렴 마감

2026년 10월 기준 NIST CSRC의 공식 간행물 목록에는 SSDF 1.1이 Final, SSDF 1.2가 Draft로 표시되어 있다.

SSDF 1.0과 1.1의 차이

SSDF 1.1에서는 기존 실무를 보완하고 새로운 작업을 추가하였다.

대표적인 변경사항은 다음과 같다.

• PO.5 추가: 안전한 개발환경의 구축 및 유지.
• PO.1.2 추가: 조직이 개발하는 소프트웨어의 보안 요구사항 정의.
• PS.3.2 추가: 소프트웨어 구성요소의 출처 정보 수집·보호·공유.
• PW.1.2 추가: 보안 요구사항·위험·설계 결정의 추적.
• 기존 실무와 작업의 통합 및 재배치.
• 구현 예시와 참고자료 확대.
• EO 14028과 SSDF 실무 사이의 대응표 추가.

특히 PO.5와 PS.3.2는 개발환경 및 소프트웨어 공급망 보안의 중요성을 반영한다.

SSDF 1.2 개정 초안

NIST는 2025년 12월 17일 SSDF 1.2에 해당하는 SP 800-218 Revision 1 최초 공개 초안을 발표하였다.

정식 명칭은 Secure Software Development Framework (SSDF) Version 1.2: Recommendations for Mitigating the Risk of Software Vulnerabilities이다.

개정 초안의 주요 특징은 다음과 같다.

• 안전하고 신뢰할 수 있는 소프트웨어 개발·전달에 관한 실무 보강.
• 개발환경과 보안 개발 프로세스의 지속적 개선 강조.
• 소프트웨어 업데이트의 신뢰성과 복원력 강화.
• 기존 실무의 일부 작업과 구현 예시 수정.

특히 다음 두 실무가 새롭게 추가되었다.

번호	영문 명칭	주요 내용
PO.6	Define and Implement a Continuous Process Improvement Plan	보안 개발 프로세스의 지속적 개선 계획 수립 및 실행
PS.4	Ensure Software Updates Are Robust and Reliable	소프트웨어 업데이트의 안정성과 신뢰성 확보

PO.6

PO.6은 개발 과정에서 발견된 문제와 새로운 위협을 반영하여 보안 개발 실무를 지속적으로 개선하는 것을 목적으로 한다.

초안의 주요 작업은 다음과 같다.

• PO.6.1: 새로운 위협과 개발 도구 변화에 대응하여 개발환경 개선.
• PO.6.2: 소프트웨어 오류를 줄이기 위한 새로운 절차·도구·기술 식별.
• PO.6.3: 취약점 대응 절차 개선 및 기존 위험 대응 결정의 정기적인 재검토.

PS.4

PS.4는 소프트웨어 업데이트 과정에서 발생할 수 있는 장애와 보안 위험을 줄이는 것을 목적으로 한다.

초안의 주요 작업은 다음과 같다.

• PS.4.1: 소프트웨어 배포본에 대한 충분한 시험 수행.
• PS.4.2: 카나리 배포, 단계적 배포 등 계층화된 업데이트 전략 활용.
• PS.4.3: 업데이트 실패에 대비한 안정적인 롤백 기능 제공.
• PS.4.4: 업데이트 전달을 위한 엔진과 인프라의 신뢰성 확보.

예를 들어 일부 사용자에게 먼저 업데이트를 배포하고 문제가 없는지 확인한 뒤 전체 사용자에게 확대하는 방식이 포함된다.

또한 업데이트 실패 시 이전의 정상 상태로 복구할 수 있도록 하는 방법을 권고한다.

다만 취약한 과거 버전으로 무단 롤백하는 공격은 방지해야 한다.

PO.6과 PS.4는 2026년 10월 기준 확정판인 SSDF 1.1의 실무가 아니라 SSDF 1.2 개정 초안의 추가 실무이다.

따라서 SSDF 1.1을 기준으로 평가하거나 문서를 작성할 때 두 실무를 현행 확정 요구사항으로 혼동해서는 안 된다.

문서 구성

NIST SP 800-218은 본문 2개 장과 부록 3개로 구성된다.

구분	영문 제목	주요 내용
제1장	Introduction	SSDF의 목적, 적용 대상, 개발 방법론과의 관계
제2장	The Secure Software Development Framework	4개 그룹의 보안 개발 실무와 세부 작업
참고문헌	References	관련 표준과 보안 개발 지침
부록 A	The SSDF and Executive Order 14028	EO 14028과 SSDF 실무 사이의 대응 관계
부록 B	Acronyms	약어
부록 C	Change Log	SSDF 개정 내역

제2장의 표 1은 SSDF 1.1의 19개 실무와 세부 작업, 구현 예시 및 참고자료를 제시한다.

부록 A의 표 2는 EO 14028 제4절의 세부 조항과 관련 SSDF 실무를 연결한다.

부록 C에는 2020년 최초 발표 이후 추가·수정·통합된 실무와 작업의 변경 이력이 기록되어 있다.

같이 보기

• 데브섹옵스
• Secure SDLC
• 개발 환경 보안
• 애플리케이션 보안 테스트
• 시큐어 코딩
• 소프트웨어 구성 분석
• SBOM
• OWASP SAMM