1. 왜 NIST SSDF인가 — 미 연방 조달 SW의 새 진입장벽
NIST SSDF(Secure Software Development Framework, NIST SP 800-218) — 보안 소프트웨어 개발 라이프사이클(SDLC) 프레임워크. v1.0(2022.2), v1.1(2022.2.4)이 현행. SP 800-218A(2024.4): GenAI Profile 추가.
왜 지금?
- EO 14028(2021.5) → OMB M-22-18(2022.9) → OMB M-23-16(2023.6): 모든 연방 조달 소프트웨어 공급자는 NIST SSDF 준수 자가증명서(Self-Attestation) 제출 의무
- CISA Attestation Form(2024.3 v1.0 발효): 표준 양식 도입, 미국 정부에 SW 판매 시 필수
- CMMC 2.0·FedRAMP: SSDF 통합 요구
- EU CRA(2024 발효): SSDF Practice 70%+ 매핑
- 한국 K-시큐어 소프트웨어 가이드: SSDF 기반 작성
오해 1 — “ISO 27001 받았으면 SSDF 자동 충족.” 부분 매핑(40~50%), Practice별 별도 증빙 필요. 오해 2 — “오픈소스만 쓰니 우리는 해당 없다.” Practice PS·PW가 사용자의 오픈소스 검증·통합 시 적용. 오해 3 — “스타트업은 면제.” SBOM·자가증명 의무 — 매출 무관, 미 연방 판매 시 적용.
2. SSDF 핵심 구조 — 4 Groups·19 Practices·42 Tasks
NIST SSDF v1.1
├── PO: Prepare the Organization (조직 준비) — 5 Practices, 14 Tasks
├── PS: Protect the Software (SW 보호) — 3 Practices, 6 Tasks
├── PW: Produce Well-Secured Software (안전한 생산) — 9 Practices, 18 Tasks
└── RV: Respond to Vulnerabilities (취약점 대응) — 3 Practices, 4 Tasks
합계 19 Practices, 42 Tasks각 Practice 구조:
- Practice: 무엇을(what) — 예: PO.1 보안 요구사항 정의
- Task: 어떻게(how) — 예: PO.1.1 외부·내부 요구사항 식별·문서화
- Notional Implementation Examples: 예시 도구·기법
- References: BSIMM·OWASP SAMM·ISO 27034·ISA/IEC 62443·SCAGILE·OWASP ASVS 매핑
3. PO·PS·PW·RV 19 Practices 전체 표
PO — Prepare the Organization (5)
| ID | Practice |
|---|---|
| PO.1 | 보안 요구사항 정의 (Security Requirements) |
| PO.2 | 역할·책임 정의 (Roles & Responsibilities) |
| PO.3 | 지원 도구 구현 (Supporting Toolchains) |
| PO.4 | 기준·결과 점검 (Criteria & Checks) |
| PO.5 | 보안 개발 환경 보호 (Secure Build Environment) |
PS — Protect the Software (3)
| ID | Practice |
|---|---|
| PS.1 | 코드 무단변경 방지 (Protect Code) |
| PS.2 | 무결성 검증 (Verify Integrity) |
| PS.3 | 출처·구성 정보 보존 (Archive & Provenance) |
PW — Produce Well-Secured Software (9)
| ID | Practice |
|---|---|
| PW.1 | 보안 요구사항 충족 설계 (Design to Meet Requirements) |
| PW.2 | 디자인 리뷰 (Design Review) |
| PW.3 | 검증된 컴포넌트 재사용 (Reuse Existing, Well-Secured Components) |
| PW.4 | 보안 코딩 (Source Code Adherence) — SAST·코딩 표준 |
| PW.5 | 안전 빌드·재현성 (Reusable Build Settings) |
| PW.6 | 의도된 빌드만 출하 (Configure for Security) |
| PW.7 | 코드 리뷰·분석 (Review & Analyze) |
| PW.8 | 실행 가능한 코드 테스트 (Test Executable Code) — DAST·Fuzzing |
| PW.9 | 시연·문서화 (Default Secure Settings) |
RV — Respond to Vulnerabilities (3)
| ID | Practice |
|---|---|
| RV.1 | 지속 식별·확인 (Identify & Confirm) |
| RV.2 | 평가·우선순위·계획 (Assess & Plan) |
| RV.3 | 근본원인 분석 (Root Cause Analysis) |
4. Stage 1 — 갭분석·조직 준비 (1~3개월)
자가 진단:
- 42 Tasks별 현재 충족도 — Not Implemented / Partially / Fully (3단계)
- 일반 중견 제조사 첫 점검: PO 40%·PS 30%·PW 50%·RV 30% 평균
- 가장 약한 영역: PO.5(빌드 환경 보호)·PS.2(서명 검증)·RV.3(근본원인)
조직 준비(PO):
- PO.1: 보안 요구사항 문서 — 회사 정책·고객 요구·법규(GDPR·EU CRA·HIPAA 등)·산업 표준(ISO 27001·PCI DSS) 통합
- PO.2: RACI 매트릭스 — 개발자·보안담당·DevOps·QA 역할
- PO.3: 보안 도구 표준화 — SAST(SonarQube·Checkmarx)·DAST(ZAP·Burp)·SCA(Snyk·Dependabot)·IaC(Checkov·Tfsec)·Container(Trivy)
- PO.4: 보안 KPI 정의 — Critical CVE 7일 SLA·SAST 차단 정책·코드 리뷰 비율
- PO.5: 빌드 환경 격리 — CI/CD 강화, 다중 인증, 임시 자격증명
5. Stage 2 — PW: 안전 코딩·디자인 (3~6개월)
PW.1·PW.2 디자인:
- 위협 모델링: STRIDE(Microsoft)·PASTA·OCTAVE·LINDDUN(Privacy)
- 도구: Microsoft Threat Modeling Tool·OWASP Threat Dragon·IriusRisk·Cairis
- 디자인 리뷰: 보안 아키텍트 + 시니어 개발자, Sprint 시작 시 의무
PW.3 컴포넌트 재사용:
- 승인 라이브러리 카탈로그 (Inner Source)
- 신규 의존성 도입 시 OpenSSF Scorecard 70+, 활성 유지 확인
- 라이선스·취약점·메인테이너 평가
PW.4 보안 코딩:
- 언어별 가이드: CERT C·CERT Java·MISRA·Google C++ Style·OWASP Cheat Sheets
- SAST 통합: PR 단위 자동 스캔, High+ 발견 시 차단
- 도구: SonarQube·Semgrep·CodeQL(GitHub Advanced Security)·Checkmarx
- AI 코딩 어시스턴트 사용 시 SP 800-218A GenAI Profile 추가 통제
PW.5·PW.6 빌드:
- IaC 코드로 빌드 환경 정의 (Ansible·Terraform)
- 빌드 결정론(Determinism): 동일 입력 → 동일 출력
- 의도된 컴파일러 플래그 (스택 보호·ASLR·DEP)
PW.7 코드 리뷰:
- Pull Request 의무 (최소 1명 승인)
- 보안 관련 변경 시 보안 담당 리뷰 추가
- 자동: SAST·SCA·Secret Scan·라이선스 체크
PW.8 동적 테스트:
- DAST: ZAP·Burp Suite·Acunetix
- Fuzzing: AFL++·libFuzzer·OSS-Fuzz·jazzer.js
- IAST: Contrast·HCL AppScan
- Penetration Testing: 연 1회+ 외부
PW.9 기본 보안 설정:
- 안전한 기본값(Secure by Default)
- 강한 암호 강제·기본 키 무사용·필수 인증
6. Stage 3 — PS: SW 보호·서명 (2~3개월)
PS.1 코드 보호:
- 소스 코드 저장소(GitHub·GitLab·Bitbucket) 접근 통제
- 보호 브랜치(main·release): 직접 푸시 금지, PR 필수
- 코드 서명 커밋(GPG·SSH·Sigstore gitsign)
- Force push 금지·삭제 금지
PS.2 무결성 검증:
- 빌드 아티팩트 서명(Cosign·GPG·X.509)
- 컨테이너 이미지·바이너리·인스톨러 서명
- 다운로드 사이트 hash·서명 공개 — 사용자 검증 가능
- 자동 검증 파이프라인
PS.3 출처·구성 보존:
- SBOM 자동 생성·게시
- SLSA Provenance 첨부
- 빌드 정보 영구 보관 — Provenance Archive
- 의존성 hash·소스 revision 기록
7. Stage 4 — RV: 취약점 대응 (지속 운영)
RV.1 식별:
- 정보 수집: KEV·NVD·OSV·GitHub Advisory·벤더 알림
- 자체 코드: SAST·DAST·Fuzzing 지속
- 외부 보고: VDP(Vulnerability Disclosure Policy) 운영 — security.txt·HackerOne·Bugcrowd
- Bug Bounty 검토
RV.2 평가·계획:
- CVSS·EPSS·KEV 통합 우선순위
- SLA: Critical 7일·High 30일·Medium 90일·Low 180일
- 패치 가용 시 즉시 적용 / 불가 시 보상 통제(WAF·격리)
RV.3 근본원인 분석:
- 5 Why·Fishbone·FMEA
- 동일 패턴 차단: 보안 코딩 가이드 업데이트·SAST 룰 추가·교육
- 보안 인시던트 회고 — 분기 1회
8. Stage 5 — 자가증명서·지속 개선 (지속)
자가증명서(Self-Attestation):
- CISA Attestation Form(2024.3 v1.0):
- Form A: 단일 제품
- Form B: 제품군
- 서명자: CEO 또는 COO·CISO (legally authorized representative)
- 제출처: 연방 기관 (CISO Council Repository)
- 허위 진술 시 False Claims Act 적용 — 매출 3배·벌금
구체적 증명 요구:
- “We follow the secure software development practices defined by NIST SP 800-218”
- 미준수 Practice는 POA&M(Plan of Action & Milestones) 작성·제출
3PAO(Third-Party Assessment): 자가증명 대신 인증된 평가기관 보고서 제출 가능 (FedRAMP 3PAO 활용).
지속 개선:
- 분기 자가진단 점수
- 보안 KPI: SAST·DAST 탐지율, CVE 평균 해결 시간(MTTR), 인시던트 수
- 분기 보안 회고
- 신규 위협 대응(예: 2025 LLM 보안·Confidential Computing)
SP 800-218A GenAI Profile:
- AI 코드 어시스턴트 활용 시 추가 통제
- AI 출력 검증(SAST·코드 리뷰)
- AI 모델 보안(RAG·Prompt Injection 차단)
9. 비용·ROI
| 항목 | 비용 (연간) |
|---|---|
| 보안 SDLC 도구(SAST·DAST·SCA·IaC) | 1~10억 |
| 위협 모델링·교육 | 3천~3억 |
| AppSec 인력(2~10명) | 4~20억 |
| 외부 펜테스트·취약점 진단 | 5천~3억 |
| Bug Bounty(HackerOne·Bugcrowd) | 1~10억 |
| 거버넌스·문서화·자가증명 준비 | 5천~5억 |
| 합계 (중견 제조사) | 8~50억 |
ROI:
- 미 연방 조달 진입 — 자가증명 없으면 입찰 불가, 미국 시장 잠재 손실
- 침해사고 평균 비용 38억(IBM 2024 한국) 예방
- 보안 부채(Tech Debt) 감소 — 후순위 수정 비용 → 사전 차단 시 10~100배 절감
- 사이버보험 SSDF 인증 시 15~25% 할인
- 매출 증가 — 정부·금융·헬스케어 RFP 통과
10. 자가 점검 — SSDF 19 Practices
PO (5): 보안 요구사항·R&R·도구·점검·빌드환경
- PO.1 외부·내부 보안 요구 문서
- PO.2 RACI 명확
- PO.3 SAST·DAST·SCA 표준 도구
- PO.4 보안 KPI·차단 정책
- PO.5 빌드 환경 격리·MFA
PS (3): 코드 보호·무결성·출처
- PS.1 보호 브랜치·코드 서명
- PS.2 아티팩트 서명·검증
- PS.3 SBOM·Provenance 보관
PW (9): 디자인·재사용·코딩·빌드·리뷰·테스트·기본값
- PW.1·2 위협 모델링·디자인 리뷰
- PW.3 컴포넌트 카탈로그
- PW.4 SAST PR 차단
- PW.5·6 IaC 빌드·결정론
- PW.7 코드 리뷰 의무
- PW.8 DAST·Fuzzing·펜테스트
- PW.9 Secure by Default
RV (3): 식별·평가·근본원인
- RV.1 KEV·NVD·VDP
- RV.2 SLA(7/30/90/180)
- RV.3 5 Why·SAST 룰 추가
자가증명: CISA Attestation Form 준비, CEO/CISO 서명
11. 마무리 — 보안 SDLC가 시장 진입의 기본
NIST SSDF는 ① 조직 준비(PO), ② SW 보호(PS), ③ 안전한 생산(PW), ④ 취약점 대응(RV) — 19 Practices·42 Tasks를 SDLC에 녹이는 것이다. 1차로 자가증명 가능 수준(80%+)에 도달, 2차로 모든 Practice Fully Implemented, 3차로 SP 800-218A GenAI Profile까지 확장하면 미 연방 조달 진입·EU CRA·사이버보험 모두 동시 충족된다.