공급망
NIST SSDF(SP 800-218)
SSDF(Secure Software Development Framework, 보안 소프트웨어 개발 프레임워크)는 안전한 소프트웨어를 만들기 위한 NIST의 관행 모음입니다. SP 800-218로 발행되었으며, 성숙한 개발 프로그램이 하는 일을 4개 그룹으로 설명할 뿐 어떤 도구를 써야 하는지는 정하지 않습니다. 미국 연방 소프트웨어 규정을 통해 널리 알려졌고, 지금은 보안 개발 전반에서 흔히 참조하는 기준입니다.
업데이트
4개 관행 그룹
SSDF는 관행을 4개 그룹으로 구성합니다. 각 관행은 결과를 기술하며, NIST는 이것이 체크리스트가 아니라 위험에 기반한 계획 수립의 토대라고 분명히 밝힙니다.
| 그룹 | 목표 | 예시 |
|---|---|---|
| 조직 준비(PO) | 사람, 프로세스, 도구가 준비되어 있음 | 보안 요구 사항 정의, 역할 지정, 개발 환경 보호 |
| 소프트웨어 보호(PS) | 코드와 릴리스가 변조로부터 안전함 | 모든 형태의 코드 보호, 릴리스 무결성 검증, 각 릴리스 보관 |
| 안전한 소프트웨어 생산(PW) | 릴리스하는 소프트웨어에 취약점이 적음 | 보안을 고려한 설계, 안전한 소프트웨어 재사용, 코드 검토 및 테스트 |
| 취약점 대응(RV) | 남아 있는 결함을 찾아 처리함 | 취약점의 지속적인 식별, 우선순위 지정 및 수정, 근본 원인 분석 |
공급망과 관련된 관행
- PO.3 지원 툴체인, PO.5 안전한 환경. CI 시스템도 보호해야 할 대상의 일부입니다. CI/CD 파이프라인 보안 체크리스트를 참고하세요.
- PS.3 각 릴리스 보관 및 보호. 여기에는 각 릴리스 구성 요소의 출처 증명 데이터 수집이 포함되며, SSDF는 그 방법으로 SBOM을 명시합니다.
- PW.4 안전한 소프트웨어 재사용. 서드파티 구성 요소는 검증하고 최신 상태로 유지해야 하며, 소프트웨어 구성 분석이 여기에 해당합니다.
- RV.1 지속적인 취약점 식별. 릴리스 게이트가 아니라 지속적인 의무이므로, 이미 출시한 소프트웨어를 모니터링해야 합니다.
- RV.2 평가, 우선순위 지정, 개선 조치. 취약점 우선순위 지정 방법을 참고하세요.
SSDF는 의무인가요?
그 자체로는 아닙니다. 법률이 아니라 NIST 간행물입니다. 몇 년 동안은 미국 연방 공급업체에 직접적인 의미가 있었습니다. OMB 메모 M-22-18과 M-23-16이 SSDF에서 가져온 관행을 준수한다고 증명하도록 요구했기 때문입니다. 이는 2026년 1월 23일에 바뀌었습니다. OMB 메모 M-26-05가 두 메모를 모두 폐지하고 위험 기반 접근 방식으로 전환했습니다. 기관은 여전히 공통 증명 양식과 NIST 표준을 사용할 수 있지만 더 이상 의무는 아니므로, 공급업체는 기관마다 요구 사항이 다를 것으로 예상해야 합니다.
연방 조달 밖에서도 SSDF는 공통 언어로서 여전히 유용합니다. 고객은 보안 설문에 SSDF를 차용하며, 다른 표준과도 매핑됩니다.
SSDF 버전
- 버전 1.1(SP 800-218)은 2022년 2월에 발행되었으며 현재 최종 버전입니다.
- 버전 1.2(SP 800-218 Revision 1)는 2025년 12월에 초안으로 발행되었습니다.
- SP 800-218A는 SSDF를 생성형 AI와 이중 용도 파운데이션 모델로 확장하는 커뮤니티 프로필입니다.
SSDF 도입 방법
- 현재 하고 있는 일을 매핑합니다. 관행을 하나씩 살펴보고 이미 충족하는 부분과 그 증거를 기록합니다.
- 위험에 따라 공백의 순위를 매깁니다. SSDF는 각자의 위험에 맞춰 적용하도록 되어 있으므로, 모든 관행을 같은 깊이로 다룰 필요는 없습니다.
- 증거를 자동화합니다. 파이프라인에서 나오는 증거는 추가 작업 없이 최신 상태를 유지합니다. 수작업으로 작성한 증거는 금세 낡습니다.
- 책임자를 지정합니다. 각 관행에는 책임자가 필요합니다. 대부분은 보안 팀보다 엔지니어링 팀이 맡게 됩니다.
- 정해진 주기로 검토합니다. 도구가 바뀌고 버전 1.2가 진행됨에 따라 매핑을 업데이트합니다.
SSDF, SLSA, CRA
SSDF는 보안 개발 프로그램이 달성해야 할 것을 말합니다. SLSA는 그중 한 부분인 빌드 무결성을 깊이 다룹니다. EU Cyber Resilience Act는 고유한 의무가 있는 법률입니다. 모두 소프트웨어에 무엇이 들어 있는지 알고 그 취약점을 처리하기를 기대하므로, 하나를 위해 한 작업이 다른 것에도 이어집니다.
CRACI의 역할
SSDF는 폭넓은 프로그램이며, 어떤 도구도 이를 모두 다루지는 못합니다. CRACI는 빌드와 출시된 소프트웨어에 달린 관행에 대한 증거를 제공합니다. 각 GitHub Actions 작업의 SBOM, 빌드 환경의 격리된 작업과 이그레스 통제, 출시된 소프트웨어의 지속적인 모니터링, 발견 사항의 분류입니다. CRACI가 SSDF 준수를 보장하지는 않으며, 매핑과 증명은 여전히 귀사의 몫입니다. CRACI로 구현하는 소프트웨어 공급망 보안을 참고하세요.
NIST SSDF: 자주 묻는 질문
NIST SSDF란 무엇인가요?
NIST SP 800-218로 발행된 보안 소프트웨어 개발 프레임워크(Secure Software Development Framework)입니다. 안전한 소프트웨어를 만들기 위한 관행 모음으로, 조직 준비, 소프트웨어 보호, 안전한 소프트웨어 생산, 취약점 대응의 4개 그룹으로 구성됩니다.
SSDF는 무엇의 약자인가요?
Secure Software Development Framework(보안 소프트웨어 개발 프레임워크)입니다.
SSDF는 의무인가요?
아닙니다. 법률이 아니라 지침입니다. 미국 연방 공급업체는 과거 SSDF의 관행을 준수한다고 증명해야 했지만, 2026년 1월 OMB 메모 M-26-05가 그 요구 사항을 폐지했습니다. 기관은 여전히 증명을 요청할 수 있습니다.
SSDF의 최신 버전은 무엇인가요?
버전 1.1(SP 800-218, 2022년 2월)이 현재 최종 버전입니다. 버전 1.2는 2025년 12월에 초안으로 발행되었으므로, 상태는 NIST 사이트에서 확인하세요.
SSDF와 SLSA의 차이는 무엇인가요?
SSDF는 사람, 프로세스, 기술 전반에 걸쳐 보안 개발 전체를 다룹니다. SLSA는 빌드 무결성과 출처 증명을 깊이 다룹니다. 둘은 함께 잘 작동합니다.
SSDF는 SBOM을 요구하나요?
각 릴리스 구성 요소의 출처 증명 데이터를 수집하고 공유하도록 요구하며, 그 방법 중 하나로 SBOM을 명시합니다. 특정 도구를 강제하기보다는 결과를 기술합니다.