기술 지원
문서
로그인
문의하기
이 블로그 글의 AI 요약으로 바로 가기 
주요 내용
- NIST(미국 국립표준기술연구소)의 보안 소프트웨어 개발 프레임워크(SSDF)는 오픈 소스 구성 요소를 포함한 타사 구성 요소에 대해 자체 요구 사항에 부합하는지 지속적으로 검증할 것을 요구합니다.
- 취약점 스캔은 검증 과정의 일부에 불과하며, SSDF의 예시에는 유지 관리 상태와 무결성도 포함됩니다.
- 오픈 소스의 경우, 일반적으로 구성 요소가 사용자의 요구 사항을 충족한다는 사실을 입증할 의무가 있는 공급업체가 없으므로, 해당 증거를 수집하는 일은 팀에서 직접 수행해야 합니다.
- 이러한 증거에는 각 구성 요소의 출처와 변경 내역을 기록한 ‘출처 정보’가 포함됩니다. 구성 요소 목록만으로는 이를 모두 파악할 수 없습니다.
- 검증은 요구사항, 증거, 구축 전 안전 조치, 그리고 유지보수가 이루어지지 않는 구성 요소에 대한 계획이라는 네 가지 결정 사항으로 귀결됩니다. 요구사항부터 시작하세요.
고객이 제품에 포함된 오픈소스 라이브러리를 어떻게 검증하는지 묻는다면, 그 질문은 아마도 NIST 보안 소프트웨어 개발 프레임워크(SSDF)의 영향으로 제기된 것일 가능성이 높습니다. SSDF의 ‘안전한 소프트웨어 제작(Produce Well-Secured Software)’ 그룹에 속한 과제 중 하나인 PW.4.4는 제작자가 오픈소스 구성 요소를 포함한 타사 구성 요소를 자체적으로 정의한 요구 사항에 따라 검증할 것을 요구하고 있습니다.
정상적인 스캔 보고서는 알려진 취약점을 다루지만, PW.4.4의 예시들은 해당 구성 요소가 여전히 유지 관리되고 있는지, 그리고 그 무결성을 확인할 수 있는지 여부도 지적하고 있습니다. 이 작업 자체는 “확인”의 정의를 내리거나, 특정 도구를 명시하거나, 어떤 증거를 보관해야 하는지 명시하지는 않습니다.
그러면 요구 사항을 작성하고 증명을 제시하는 일은 여러분에게 맡겨지게 됩니다. 또한 오픈 소스 구성 요소의 경우, 일반적으로 라이브러리에 대한 계약이 체결되어 있지 않으므로, 어떤 공급자도 여러분에게 그 증명을 제공할 의무가 없습니다.
2026년 현재 NIST SSDF의 현황
NIST는 SSDF를 특별 간행물(SP) 800-218로 발간합니다. 현재 최종 버전은 2022년 2월 발간된 ‘보안 소프트웨어 개발 프레임워크(SSDF) 버전 1.1: 소프트웨어 취약점 위험 완화를 위한 권고 사항’입니다. 이 프레임워크는 모범 사례를 네 가지 그룹으로 분류하며, 각 그룹에는 두 글자 코드(PO, PS, PW, RV)가 부여됩니다. 이 그룹들은 각각 ‘조직 준비(Prepare the Organization)’, ‘소프트웨어 보호(Protect the Software)’, ‘보안성이 뛰어난 소프트웨어 제작(Produce Well-Secured Software)’, ‘취약점 대응(Respond to Vulnerabilities)’을 의미합니다. 각 모범 사례에는 PW.4와 같은 고유 ID가 부여되며, 해당 사례의 세부 작업에는 PW.4.4와 같이 추가 번호가 붙습니다.
버전 1.1은 소프트웨어 제작자와 구매자를 대상으로 작성되었으며, 비정부 기관도 자발적으로 이를 사용할 수 있다고 명시하고 있습니다. 이 문서는 위험 기반 계획 수립의 기초가 되는 실무 지침을 설명하고 있으며, 이는 단순한 체크리스트로 의도된 것이 아니라고 밝히고 있습니다. NIST는 SSDF를 구매자가 공급업체와 소통할 때 사용할 수 있는 공통 용어집으로 제시하고 있으므로, 일반적으로 구매자의 정책이나 이를 참조하는 계약서를 통해 해당 요구 사항이 전달됩니다.
참고: NIST는 행정명령 14306호에 따라 2025년 12월 17일 , SP 800-218 개정판 1호인 ‘보안 소프트웨어 개발 프레임워크(SSDF) 버전 1.2’의 초기 공개 초안을 발표했습니다. 2026년 10월 현재, 버전 1.1이 여전히 최종 버전입니다. 이 초안은 PW.4.4와 출처 추적(provenance) 작업인 PS.3.2를 기존과 동일한 번호 체계와 문구로 유지하면서, PW.4.4 항목 아래에 예시 문구와 함께 두 가지 새로운 실천 방법을 추가했습니다. 이 기사는 버전 1.1을 기준으로 작성되었습니다.
PW.4.4의 명시적 내용과 해석의 여지가 남는 부분
PW.4.4는 개발자에게 도입한 상용 소프트웨어, 오픈 소스 및 기타 제3자 소프트웨어 구성 요소가 해당 조직이 정의한 요구 사항을 수명 주기 전반에 걸쳐 준수하는지 확인하도록 요구합니다. 이러한 문구로 보아 요구 사항의 구체적 내용은 귀하에게 맡겨져 있으며, 오픈 소스 구성 요소는 명시적으로 언급되어 있습니다. 또한, 해당 구성 요소를 사용하는 동안 지속적으로 점검이 이루어지도록 규정하고 있어, 도입 시 한 번의 검토에 그치지 않고 그 이후에도 점검이 지속됩니다.
이 외에도 NIST는 7가지 가상의 구현 사례를 제시하고 있습니다.
| PW.4.4 예시 | 다루는 내용 | 기초 |
|---|---|---|
| 예시 1 및 2: 공급업체가 아직 수정하지 않은 공개된 취약점을 확인하며, 여기에는 툴체인 내 자동 탐지 기능도 포함됩니다. | 해당 구성 요소의 알려진 결함 | SP 800-218 버전 1.1, 개념적 |
| 예 3: 상용 검증 서비스의 기존 결과 활용 | 외부 심사 결과 | SP 800-218 버전 1.1, 개념적 |
| 예 4: 해당 구성 요소가 여전히 적극적으로 유지보수되고 있으며 수명 종료(EOL) 단계에 이르지 않았는지, 또한 새로 발견된 취약점이 적절히 해결되고 있는지 확인합니다. | 새로운 결함의 지원 현황 및 수정 조치 | SP 800-218 버전 1.1, 개념적 |
| 예 5: 더 이상 유지보수되지 않거나 조만간 사용이 중단될 구성 요소에 대한 대응 계획을 수립한다 | 지원 종료 시 귀하의 대응 | SP 800-218 버전 1.1, 개념적 |
| 예 6: 디지털 서명 또는 기타 메커니즘을 통해 무결성을 확인한다 | 유물의 완전성 | SP 800-218 버전 1.1, 개념적 |
| 예 7: 코드를 검토, 분석 또는 테스트하기 | 코드 자체 | SP 800-218 버전 1.1, 개념적 |
알려진 취약점을 확인하는 작업은 이 일곱 가지 예시 중 두 가지를 다루므로, 스캔 보고서만으로도 과제의 일부를 해결할 수 있습니다. 알려진 결함에 대한 스캔만으로는 일반적으로 해당 아티팩트가 온전한지, 또는 누군가가 여전히 해당 구성 요소를 유지 관리하고 있는지 여부를 알 수 없으며, 예시 4와 6은 이러한 질문들을 다룹니다.
SSDF 1.2 초안에는 PW.4.4 항목에 여덟 번째 예시가 추가되었습니다. 바로 제3자 라이브러리의 소유권 변경 사항을 정기적으로 검토하고, 각 변경 사항이 미치는 영향을 평가하는 것입니다. 알려진 취약점 스캔은 일반적으로 소유권 변경을 감지하지 못하므로, 이 예시에 대해서는 별도의 점검 절차가 필요합니다.
유지보수가 중단된 구성 요소의 경우, 예제 5의 대응 방안은 대개 세 가지 형태 중 하나를 취합니다. 바로 해당 구성 요소를 교체하거나, 사용 중인 버전에 패치를 적용하거나, 위험을 감수하겠다는 사실을 문서화하는 것입니다. 중간 옵션은 누군가가 수정 코드를 작성하고 테스트해야 함을 의미하며, 다른 사람에게 그 일을 맡기지 않았다면 그 누군가는 바로 여러분입니다.
오픈 소스의 경우, 증거를 제시해 줄 공급업체가 없는 경우가 많습니다.
SSDF의 공급업체 대응 업무인 PO.1.3은 상용 구성 요소를 제공하는 제3자에게 요구 사항을 전달하는 내용을 다룹니다. 여기에는 계약서에 요구 사항을 추가하거나, 공급업체가 자사 소프트웨어가 해당 요구 사항을 충족함을 증명하도록 요구하거나, 소프트웨어의 모든 구성 요소에 대한 출처 정보 및 무결성 검증 메커니즘을 요구하는 것 등이 예시로 포함됩니다.
배포하는 오픈 소스 코드는 PW.4.4의 적용 대상이지만 PO.1.3의 적용 대상은 아니므로, SSDF는 해당 코드의 작성자와 조건을 협의하는 과제를 부여하지 않고 이를 직접 확인하도록 요구합니다. 실제로 라이브러리는 대개 별도의 계약 없이 제공되므로, 일반적으로 출처나 무결성 증거를 제공해야 할 의무가 있는 상대방이 없습니다. 따라서 귀사 측의 누군가가 이를 직접 생성하거나 수집해야 합니다.
사용자의 요구사항이 최우선이며, PO.1.1은 SSDF가 이러한 요구사항을 작성할 때 삼는 출발점입니다. 이 문서의 두 번째 예시는 오픈 소스 및 기타 타사 구성 요소를 포함한 개발 프로세스의 보안을 위한 정책을 정의하는 것입니다. 어떤 도구를 평가하기 전에 먼저 이러한 정책을 작성해야 합니다. PW.4.4는 구성 요소를 사용자의 요구사항에照해 평가하는 단계이며, 이 단계를 생략할 경우 도구의 기본 검사 기능이 그 역할을 대신하게 되는 경향이 있습니다.
간결한 요구사항 문서를 통해 어떤 유지보수 활동이 허용되는지, 구성 요소가 상류 지원이 중단될 경우 어떻게 처리되는지, 예외 사항을 누가 승인하는지, 그리고 무결성을 어떻게 확인하는지 등을 다룰 수 있습니다. PO.1.3의 다섯 번째 예시는 승인된 예외 사항에 대한 정기적인 검토를 포함하여, 구성 요소가 충족하지 못하는 요구사항을 처리하는 절차를 설명합니다. 오픈 소스 구성 요소에 대해서도 동일한 절차를 적용할 수 있습니다.
SSDF: PW.4.1에 따르면, SSDF의 구성 요소 확보 과제는 공급업체 없이 팀이 취할 수 있는 조치를 설명하는 두 가지 사례를 포함하고 있습니다. 하나는 각 구성 요소에 대한 소프트웨어 자재 명세서(SBOM) 나 구성 분석과 같은 출처 정보를 확보하는 것입니다. 다른 하나는 승인되고 검증된 오픈 소스 구성 요소를 하나 이상의 저장소에 호스팅하는 것입니다.
중간 공급자가 없는 경우, 별도의 안전 장치를 추가하지 않는 한 유지보수자가 릴리스한 내용과 사용자의 빌드 사이에는 대개 아무런 단계가 없습니다. 가능한 방법으로는 게시자가 제공하는 서명을 확인하거나, 소스 코드에서 다시 빌드하거나, 빌드 환경에 도달하기 전에 수신된 내용을 검토하는 것 등이 있습니다. SSDF의 개념적 예시에는 PW.4.4의 서명 확인과 PW.4.1의 소스 코드 기반 빌드 등 이러한 방법 중 일부가 언급되어 있습니다.
PS.3.2에 따른 출처 정보는 단순한 구성 요소 목록 그 이상입니다
PS.3.2는 SSDF의 ‘Protect the Software’ 그룹에 속합니다. 이 지침은 제작자에게 각 릴리스의 모든 구성 요소에 대한 출처 데이터를 수집, 보호, 유지 관리 및 공유할 것을 요구하며, 해당 데이터를 저장할 수 있는 예시 중 하나로 SBOM을 언급하고 있습니다. 오픈 소스 구성 요소의 경우, 일반적으로 해당 데이터를 제공해야 할 의무가 있는 공급업체는 없습니다.
NIST는 특별 간행물 800-53을 인용하여, 프로비넌스를 구성 요소의 기원, 개발, 소유권, 위치 및 변경 내역에 대한 연대기로 정의합니다. 이 정의에 따르면, 이름과 버전 목록은 릴리스에 무엇이 포함되어 있는지를 알려주는 반면, 연대기는 각 구성 요소가 어디에서 왔으며 어떤 과정을 거쳤는지를 알려줍니다. 구성 요소 목록만으로는 후자의 정보를 자동으로 알 수 없으므로, 귀하의 SBOM이 해당 이력을 기록하고 있는지, 아니면 단순히 목록만 기록하고 있는지 확인해야 합니다.
PS.3.2에 제시된 예시에는 데이터 수취업체 및 자체 대응팀과의 데이터 공유, 수신자가 데이터를 검증할 수 있도록 데이터의 무결성을 보호하는 것, 그리고 구성 요소가 업데이트될 때마다 데이터를 갱신하는 것이 포함됩니다. PS.3.2는 “모든 구성 요소”라고 명시하고 있으며 “전달적”이라는 단어를 사용하지 않습니다. 이를 직접 선택하지 않은 종속성에 적용하는 것은 추론에 해당하지만, “모든”이라는 단어에서 자연스럽게 도출되는 결론입니다. 요구 사항에 따라 전이적 종속성이 적용 범위에 포함되는지 여부를 결정하고, 그 결정을 기록하십시오.
SBOM과 함께 자주 언급되는 두 가지 용어가 더 있습니다. SLSA(Supply-chain Levels for Software Artifacts)는 별도의 공급망 보안 사양이며, 이 중 ‘빌드 레벨 3(Build Level 3 )’은 빌드 과정에서 발생하는 변조로부터 보호하는 강화된 빌드 플랫폼을 설명합니다. 사이버보안 및 인프라 보안국(CISA)이 설명한 바와 같이, VEX(Vulnerability Exploitability eXchange) 문서는 특정 취약점에 대해 제품이 ‘영향을 받음’, ‘영향을 받지 않음’ 또는 ‘수정됨’과 같은 상태를 나타냅니다. 이 두 가지 모두 SSDF 과제를 수행하는 데 필요한 근거를 제공합니다. SLSA 출처 기록은 누가, 어떤 프로세스를 통해, 어떤 입력 자료를 사용하여 패키지를 빌드했는지를 기록하며, 이는 PS.3.2에서 유지하도록 요구하는 이력의 일부입니다. VEX 기록은 알려진 취약점이 구성 요소에 영향을 미치는지 여부를 보여주며, 이는 PW.4.4의 첫 번째 예시에서 요구하는 사항입니다.
연방 인증 양식에서 구성 요소에 대해 어떤 내용을 묻는가
과거 연방 정부 구매 담당자들은 제3자 구성 요소에 대해 직접 문의하곤 했습니다. 관리예산국(OMB)의 M-22-18 및 M-23-16 호 공문에 따라, 각 기관은 소프트웨어 제작사로부터 확인서를 받아야 했으며, 이에 따라 CISA와 OMB는 2024년 3월 11일 해당 목적을 위한 ‘안전한 소프트웨어 개발 확인서 양식’을 발표했습니다.
양식의 제3절에서는 제작자가 제3자 구성 요소의 보안을 확보하고 관련 취약점을 관리하기 위한 자동화 도구 또는 이에 상응하는 프로세스를 활용하여, 신뢰할 수 있는 소스 코드 공급망을 유지하기 위해 성실히 노력했음을 확인하도록 하고 있습니다. 또한 제3자 구성 요소의 출처 정보를 “가능한 한 최대한” 유지하고 있음을 확인하도록 하고 있습니다. 양식의 부록에는 이러한 항목들이 PW.4.4 및 PS.3.2를 포함한 SSDF 과제와 연계되어 있습니다.
이 양식에는 대행사가 사용하는 제품에 내장된 제3자 오픈소스 및 독점 구성 요소는 포함되지 않습니다. 그러나 해당 구성 요소를 사용하는 제작사는 여전히 이러한 구성 요소에 의존함으로써 발생하는 위험을 줄이기 위해 제3절에 명시된 조치를 취했음을 확인합니다.
2026년 1월 23일, OMB 메모 M-26-05는 M-22-18 및 M-23-16을 폐지했습니다. 각 기관은 여전히 해당 양식을 사용할 수 있으며, 계약을 통해 SBOM 제출을 요구할 수 있고, 이 메모에는 참고 자료로 SP 800-218이 명시되어 있습니다. 또한 이 메모는 기관이 운영하는 소프트웨어 및 하드웨어를 보호하기 위한 “보편적이고 일률적인 방법”은 없다고 밝히며, 각 기관이 자체 위험 프로필에 맞는 보증 정책을 수립하도록 하고 있습니다.
| 문서 | 내용 | 현재 현황 | 기초 |
|---|---|---|---|
| SP 800-218 버전 1.1 | PW.4.4 및 PS.3.2를 정의합니다. | 최종, 2022년 2월 | NIST 지침 |
| SP 800-218 개정판 1 초안 (SSDF 1.2) | 두 작업을 모두 유지하고, 새로운 내용을 추가합니다 | 초안 | NIST 지침 초안 |
| OMB M-22-18 및 M-23-16 | 관련 기관에 확인서 제출을 의무화했다 | 2026년 1월 23일 폐지됨 | OMB 정책 |
| 확인서 양식 | 제작자들은 SSDF에서 차용한 관행을 인정하고 있다 | 대행사에게는 선택 사항입니다 | 대리인 양식 (CISA 및 OMB) |
| OMB M-26-05 | 기관들은 자체적인 보증 정책을 수립한다 | 현재 | OMB 정책 |
M-22-18 및 M-23-16이 폐지됨에 따라, 구매자가 부품의 검증 방법이나 출처 추적 방식을 문의할지 여부는 해당 구매자의 정책 및 계약에 따라 달라집니다.
의존성에 있어 ‘검증’이 무엇을 의미하는지 결정하기
실제로 검증 작업은 네 가지 결정 사항으로 귀결됩니다. 즉, 구성 요소가 충족해야 할 요구사항이 무엇인지, 어떤 증빙 자료를 보관할지, 업스트림 릴리스와 자체 빌드 사이에 어떤 과정이 있는지, 그리고 업스트림 유지보수자가 해당 구성 요소에 대한 지원을 중단할 경우 어떻게 대응할지입니다. 처음 두 가지는 해당 팀만이 수행할 수 있는 정책 수립 작업입니다. 마지막 두 가지는 도구를 활용하여 반복적인 작업을 대체할 수 있는 부분입니다.
TuxCare의 SecureChain은 업스트림 릴리스와 사용자의 빌드 사이에 위치합니다. 이 솔루션은 오픈소스 패키지의 소스 코드를 검사하여 악성코드 및 의심스러운 패턴을 탐지하고, 강화되고 격리된 환경에서 해당 소스 코드를 기반으로 패키지를 재빌드하며, 업스트림이 활성화된 동안 서비스 수준 계약(SLA)에 따라 지속적으로 패치를 적용합니다. ‘무한 라이프사이클 지원(ELS)’은 업스트림 유지보수가 종료된 후에도 수정 사항을 지속적으로 제공하며, 앞서 설명한 “실행 중인 버전에 대한 패치 적용” 옵션을 지원합니다. 지원 범위는 JavaScript, Python, Java, Go, Rust 및 PHP를 아우릅니다. 또한 TuxCare는 각 패키지에 대해 SBOM, VEX 레코드 및 SLSA 레벨 3 출처 정보를 제공합니다.
검토되지 않았거나 유지보수가 중단된 오픈소스 패키지를 어떻게 처리할지 고민 중이시라면, SecureChain이 어떤 부분을 다루는지 저희에게 문의해 주십시오.
자주 묻는 질문
NIST SSDF란 무엇인가요?
NIST SSDF는 ‘보안 소프트웨어 개발 프레임워크(Secure Software Development Framework)’로, 미국 표준 기관인 NIST가 특별 간행물(SP) 800-218로 발간하고 있습니다. 이 프레임워크는 보안 개발 관행을 ‘조직 준비’, ‘소프트웨어 보호’, ‘보안성이 뛰어난 소프트웨어 제작’, ‘취약점 대응’의 네 가지 범주로 분류합니다. 현재 최종 버전은 2022년 2월 발간된 1.1판입니다.
NIST SSDF는 누구를 대상으로 작성되었나요?
상업용 벤더 및 내부 개발 팀과 같은 소프트웨어 제작자와 연방 기관 및 기타 조직을 포함한 소프트웨어 구매자가 두 가지 주요 대상입니다. 미국 표준 기관인 NIST는 비정부 기관도 ‘보안 소프트웨어 개발 프레임워크(SSDF)’를 자발적으로 사용할 수 있다고 밝혔습니다. 오픈 소스 구성 요소를 기반으로 소프트웨어를 개발하는 기업도 제작자에 포함됩니다.
SSDF는 오픈 소스 소프트웨어도 지원하나요?
일부 그렇습니다. 보안 소프트웨어 개발 프레임워크(SSDF)에서 타사 구성 요소 검증 작업(PW.4.4)과 획득 작업(PW.4.1) 모두 오픈 소스 구성 요소를 명시하고 있습니다. 반면, 공급업체에 요구 사항을 전달하는 작업(PO.1.3)에서는 상용 구성 요소만 명시하고 있습니다. 미국 표준 기관인 NIST는 검토 중인 조치 중 하나로 오픈 소스 소프트웨어에 대한 SSDF 기준선을 포함하고 있으나, 2026년 10월 현재 아직 이를 발표하지는 않았습니다.
SSDF에서 ‘가상 구현 예시’란 무엇인가요?
보안 소프트웨어 개발 프레임워크(SSDF)에서 ‘개념적 구현 예시’란 특정 작업을 수행하는 데 도움이 될 수 있는 도구, 프로세스 또는 방법의 예시를 의미합니다. 미국 표준 기관인 NIST는 어떠한 예시나 조합도 필수 사항이 아니며, 이것이 유일한 선택지가 아니라고 밝히고 있습니다.
NIST는 SSDF에 따라 어떤 것을 인증하나요?
미국 표준 기관인 NIST는 ‘안전한 소프트웨어 개발 프레임워크(SSDF)’를 지침으로 발표하고 있으며, SSDF 관련 자료에는 어떠한 인증 프로그램도 명시되어 있지 않습니다. 연방 인증 양식은 제작자의 자체 인증 또는 제3자 평가를 모두 인정하며, 행정관리예산국(OMB)은 더 이상 정부 전반에 걸쳐 이 양식의 제출을 의무화하지 않습니다.
