CISA 보안 소프트웨어 개발 확인서에 서명하는 사람은 누구인가요?

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

제3자 평가가 없는 경우, CEO 또는 회사를 대표하여 서명할 권한이 있는 직원이 지정된 사람이 해당 양식에 서명합니다.
서명자는 자신이 아는 한, 해당 제작사가 현재 이 양식에 명시된 관행을 일관되게 준수하고 있음을 확인합니다.
OMB 메모 M-26-05에 따라, 이제 각 연방 기관이 해당 양식 제출을 요청할지 여부를 자체적으로 결정하므로, 귀사가 제품을 판매하는 기관에서는 여전히 해당 양식을 요구할 수 있습니다.
타사의 오픈 소스는 해당 양식의 직접적인 적용 범위를 벗어나지만, 생산자들은 여전히 이와 관련된 위험을 관리하고 있음을 입증하고 있다.

연방 기관이 보안 소프트웨어 개발 확인서를 요청했을 때, 귀사가 제3자 평가서를 첨부하지 않고 자체 확인을 하는 경우, 서명자는 귀사의 최고경영자(CEO)이거나, 귀사 직원으로서 법인을 대표할 권한을 가진 지정된 대리인이어야 합니다. 2026년 1월 23일자 행정관리예산국(OMB) 메모 M-26-05에 따라, 해당 기관이 이를 요청할지 여부는 이제 전적으로 해당 기관의 재량에 달려 있습니다.

그 서명자는 오픈소스 종속성이 빌드에 어떻게 포함되는지 한 번도 살펴보지 않았을지 모르지만, 결국 팀이 직접 작성하지 않은 코드의 위험을 회사가 어떻게 관리하는지에 대한 성명서 아래에 그 사람의 이름이 기재되게 됩니다.

이 양식은 한 사람이 여러 팀이 수행하는 관행을 증명하도록 요구하고 있습니다. 이러한 증명에는 몇 가지 제한 조건이 따르며, 그 중 일부 용어는 어떤 경우가 해당 조건에 부합하는지 제작자가 판단해야 합니다. 제한 조건과 해석의 여지가 있는 용어 모두를 이해하는 서명자는 훨씬 더 정확한 내용에 서명할 수 있습니다.

‘보안 소프트웨어 개발 확인서’가 어떻게 선택 사항이 되었는가

사이버보안 및 인프라 보안국(CISA)은 2024년 3월 11일 해당 양식을 공개했습니다. 소프트웨어 제작사, 즉 소프트웨어를 개발하거나 컴파일하는 기업들은 이 양식을 사용하여 자사가 출시하는 제품이 지정된 보안 개발 관행에 따라 개발되었음을 증명합니다.

지난 몇 년간 OMB는 이러한 인증을 의무화해 왔습니다. 2022년 9월 14일에 발간되고 2023년 6월 9일자 메모 M-23-16을 통해 개정된 메모 M-22-18에 따르면, 기관은 해당 소프트웨어 제작사가 ‘보안 소프트웨어 개발 프레임워크(SSDF)’에 부합하는 보안 개발 관행을 준수한다는 사실을 인증한 후에야 해당 소프트웨어를 사용할 수 있습니다.

그 후, 2026년 1월 23일, M-26-05에 따라 두 메모가 모두 철회되었습니다. 이제 각 기관은 CISA 양식을 사용할지 여부를 선택할 수 있습니다. 또한, 요청 시 제작사가 최신 소프트웨어 부품 목록(SBOM) 을 제공하도록 요구하는 계약 조항을 포함할 수도 있습니다. 양식 자체는 개정되지 않았으며 여전히 철회된 두 메모를 근거로 삼고 있으므로, 양식에 포함된 지침 중 일부는 더 이상 적용되지 않습니다.

모든 관행을 입증할 수 없는 생산자의 경우에도, 이 양식에는 OMB의 연장 승인이나 면제 조치를 바탕으로 격차를 해소하기 위한 실행 계획 및 주요 단계(POA&M)가 여전히 명시되어 있습니다. M-26-05는 해당 절차를 대체할 방안을 제시하지 않으므로, 이러한 상황에 처한 생산자는 요청 기관에 대신 어떤 조치를 수용하는지 문의해야 합니다.

‘Signer’에서 운영하는 매장과 영업이 계속되는 매장

양식의 제3절인 “확인 및 서명” 항목에서는 한 사람이 제작자를 대신하여 해당 소프트웨어가 나열된 관행에 따라 개발되었음을 진술하도록 요구합니다. 이 절에는 번호가 매겨진 네 가지 진술이 제시되어 있으며, 각 진술의 시작 부분에는 두 가지 전제 조건이 명시되어 있습니다. 서명자는 “제가 아는 한” 제작자가 제1항에 명시된 소프트웨어를 개발함에 있어 해당 관행을 “현재 일관되게 적용하고 있다”는 사실을 증명합니다. 이러한 관행에는 빌드 환경, 코드 공급망, 출처(코드의 출처 및 빌드 방식에 대한 기록), 그리고 제작자가 취약점을 발견하고 처리하는 방식이 포함됩니다. 제3항의 어떤 내용도 서명자로 하여금 해당 소프트웨어에 취약점이 전혀 없다고 진술하도록 요구하지 않습니다.

이 두 가지 제한 조건은 주장의 범위를 좁혀줍니다. “현재”는 양식에 서명할 당시 시행 중인 관행을 의미하며, “제가 아는 한”은 서명자가 알고 있는 사실로만 진술의 범위를 제한합니다. 지침이나 제3절 어디에도 서명자가 해당 관행이 실제로 시행되고 있음을 확인하기 위해 무엇을 해야 하는지 명시되어 있지 않으며, 지정된 담당자에게는 특별한 직함이 필요하지도 않습니다. 따라서 서명자가 서명하기 전에, 빌드를 운영하는 팀과 같이 해당 관행을 보증할 주체를 담당자가 결정합니다. 이러한 근거에 따른 서명은 해당 팀이 가지고 있는 정보의 범위 내에서만 유효합니다.

도식: 빌드 및 보안 팀이 서명자(CEO 또는 그 대리인)에게 해당 관행을 확인시켜 주면, 서명자는 이에 대한 확인서에 서명합니다. 서명의 신뢰성은 이를 뒷받침하는 팀의 정보 수준에 따라 결정됩니다.

표 1. 양식에서 서명에 대해 명시한 사항

항목	양식에 적힌 내용	기초
서명자	해당 소프트웨어 제작사의 대표이사 또는 회사를 법적으로 구속할 권한을 가진 임직원 중 지정된 자	양식 작성 안내
범위	전사적, 개별 제품, 여러 제품 또는 특정 제품 버전	양식, 제1절
대안	양식에 제3자 평가서가 첨부된 경우에는 생산자가 서명하지 않습니다.	작성 지침 및 제3절

제작자는 서명 대신 제3자 평가서를 첨부할 수 있습니다. 평가 기관은 연방 위험 및 승인 관리 프로그램(FedRAMP)에 따라 인증받았거나 해당 기관 담당자로부터 서면 승인을 받은 제3자 평가 기관(3PAO)이어야 합니다. 또한 양식에 포함된 모든 요소를 다루는 미국 국립표준기술연구소(NIST)의 관련 지침에 따라 평가를 수행해야 합니다. 현재 FedRAMP는 이러한 기관을 ‘독립 평가자’로 지칭하고 있으나, CISA 양식에서는 여전히 3PAO라는 용어를 사용하고 있습니다. 평가서를 사용하려면 제작자는 제3절의 해당 항목에 체크한 후 평가서를 첨부해야 합니다.

명세서에서 타사 구성 요소의 위치

제1절에는 이 양식이 다루지 않는 네 가지 범주가 나열되어 있습니다. 그중 하나는 ‘제3자 오픈소스 및 독점 구성 요소’로, 기관이 사용하는 소프트웨어 최종 제품에 통합된 구성 요소를 의미합니다. 같은 절에 있는 주석에 따르면, 서명자는 제작자가 개발한 코드에 대해 제3절에 명시된 관행을 준수함을 증명해야 합니다. 그러나 지침에 따르면, 제3자 구성 요소를 사용하는 제작자는 해당 구성 요소에 의존함으로써 발생하는 위험을 최소화하기 위해 제3절에 명시된 구체적인 조치를 취했음을 증명해야 합니다. 이 제외 조항과 지침을 종합해 보면, 서명자는 제3자 코드 자체에 대해서는 보증하지 않고, 해당 위험을 관리하기 위한 제작자의 조치에 대해서만 보증한다는 것을 의미합니다.

도표: 팀이 작성한 코드는 해당 양식의 적용 범위에 포함되며, 타사 구성 요소는 적용 범위 외부에 위치하지만, 제작자는 여전히 해당 구성 요소에 의존할 때 발생하는 위험을 최소화하기 위한 조치를 이행했음을 증명합니다.

명시사항 2와 3에서는 제3자 구성 요소가 명시적으로 언급됩니다. 명시사항 2는 내부 코드 및 제3자 구성 요소의 보안을 확보하고 관련 취약점을 관리하기 위해 “자동화 도구 또는 이에 상응하는 프로세스”를 활용하여 신뢰할 수 있는 소스 코드 공급망을 유지하기 위한 “성실한 노력”을 요구합니다. 명시사항 3은 제작자가 내부 코드 및 제3자 구성 요소에 대한 출처 정보를 “가능한 한 최대한” 유지할 것을 요구합니다. 참고로, 이 양식의 부록에는 오픈 소스 구성 요소 검증 작업을 포함하여 SSDF 작업들이 모두 명시되어 있습니다.

두 진술 모두 판단의 여지를 남깁니다. 이 양식에서는 “신뢰할 수 있는 소스 코드 공급망”이나 “이에 상응하는 프로세스”를 정의하지 않으며, 어느 정도의 출처 추적성이 타당하다고 간주되는지도 명시하지 않습니다. 각 제작자는 해당 용어들이 자사 소프트웨어에 있어 어떤 의미를 지니는지 스스로 파악해야 하며, 서명자는 자신이 아는 한도 내에서 그 결과를 증명할 뿐입니다.

또한 빌드에 어떤 타사 코드가 포함되어 있는지 파악하는 데도 달려 있으며, 해당 양식은 그 방법을 제작자에게 맡기고 있습니다. 해당 코드를 나열할 수 없는 제작자는 두 가지 기준 중 어느 하나라도 충족하는지 알 방법이 없습니다.

제3절에는 업스트림 유지보수가 종료된 구성 요소에 대해서도 아무런 언급이 없습니다. 명제 4는 여전히 릴리스 전에 발견된 취약점을 해결하기 위한 정책이나 절차를 요구하고 있습니다. 유지보수 담당자가 수정 프로그램 제공을 중단한 구성 요소의 경우, 해당 정책은 업스트림 릴리스에 의존할 수 없습니다. 따라서 해당 구성 요소를 교체하거나, 사내에서 직접 또는 수정 프로그램을 백포트해 주는 공급업체를 통해 사용 중인 버전에 패치를 적용하는 등의 대안이 남게 됩니다.

서명 뒤에 이어지는 것

이 양식에 서명하면 서명일 이후에도 지속되는 의무가 발생합니다. 제3항에는 제조사가 해당 관행을 일관되게 적용하지 않게 되는 “경우가 발생하면” 양식을 접수한 모든 기관에 이를 통보하겠다는 확인서가 포함되어 있습니다. 각주에는 해당 진술이 생산자가 해당 기관들에 개발 관행이 더 이상 준수되지 않는다고 알릴 때까지, 명시된 제품의 향후 버전에도 구속력을 갖는다고 덧붙여져 있습니다. 통지 약속은 생산자에서 해당 기관들로 향하는 것이며, 양식에는 관행 미준수 사실이 서명자에게 어떻게 전달되는지에 대한 내용은 명시되어 있지 않습니다. 해당 관행을 운영하는 팀들이 가장 먼저 미준수 사실을 파악할 가능성이 높습니다. 따라서 생산자는 해당 팀들이 서명자에게 이를 보고할 수 있는 절차를 마련해야 합니다.

도표: 인증서에 서명이 완료되면, 이는 해당 제품의 향후 버전에도 적용되며, 제조사는 관련 관행이 준수되지 않을 경우 관련 기관에 이를 통보해야 합니다.

국토안보부를 위해 작성된 이 양식의 개인정보보호법 고지문에는 두 가지 결과가 명시되어 있습니다. 요청된 정보를 제공하지 않을 경우, 해당 기관이 소프트웨어 사용을 중단할 수 있습니다. 고의로 허위 또는 오해의 소지가 있는 정보를 제공할 경우, 연방 형법 제18편 제1001조( 18 U.S.C. § 1001)를 위반할 수 있습니다.

참고: 이 양식을 사용하는 각 기관은 자체적인 개인정보보호법 고지문을 제공해야 하므로, 서명자가 확인하게 되는 결과 관련 문구는 기관마다 다를 수 있습니다.

인증 내용이 정확하게 유지되기를 원하는 서명자는 서명 전에, 각 실무에 대해 어떤 팀이 보증하는지, 제작자가 “비슷한 프로세스”나 “실현 가능”과 같은 용어를 어떻게 정의했는지, 그리고 해당 팀들이 인증 유효기간 만료 시 이를 어떻게 보고할지 확인해야 합니다.

빌드에 무엇이 포함되는지 파악하기

TuxCare의 SecureChain은 각 오픈소스 패키지의 코드를 검사하여 숨겨진 악성코드를 탐지하고, 보안이 강화된 격리된 환경 내에서 소스 코드를 기반으로 패키지를 재컴파일합니다. 검사를 통과하지 못한 패키지는 사용자의 환경에 배포되지 않습니다. 사용자가 수신하는 각 패키지에는 구성 요소를 나열한 SBOM과 출처 기록이 함께 제공됩니다. 업스트림에서 패키지를 계속 유지 관리하는 동안 SecureChain은 서비스 수준 계약(SLA)에 따라 패치를 적용하며, 업스트림 유지 관리가 종료된 후에도 Endless Lifecycle Support(ELS) 를 통해 계속해서 수정 사항을 제공합니다. SecureChain은 JavaScript, Python, Java, Go 및 PHP에 걸친 오픈 소스 종속성을 지원합니다.

빌드에 포함되는 오픈소스 종속성 내에 무엇이 들어 있는지, 또는 업스트림 개발이 중단된 후 누가 패치를 적용하는지 팀이 파악하지 못한다면, SecureChain이 이 두 가지 질문에 모두 답해 드립니다.

자주 묻는 질문

CISA 보안 소프트웨어 개발 확인 양식이란 무엇인가요?

이 양식은 소프트웨어 제작사가 자사 소프트웨어가 ‘보안 소프트웨어 개발 프레임워크(SSDF)’에서 제시한 관행에 따라 개발되었음을 증명하기 위해 사용하는 것입니다. 사이버보안 및 인프라 보안국(CISA)은 2024년 3월 11일에 이 양식을 발표했습니다. 제조사가 자체 인증을 할 경우, 최고경영자(CEO) 또는 회사를 법적으로 구속할 권한을 가진 임직원이 서명합니다. 제조사는 대신 제3자 평가서를 첨부할 수도 있습니다.

‘보안 소프트웨어 개발 확인서’는 선택 사항인가요, 아니면 여전히 필수 사항인가요?

이는 더 이상 정부 전체에 적용되는 요건이 아닙니다. 2026년 1월 23일자 행정관리예산국(OMB)의 M-26-05호 메모는, 제작사의 확인을 받은 후에만 해당 소프트웨어를 사용할 수 있도록 허용했던 M-22-18호(2022년 9월 14일) 및 M-23-16호(2023년 6월 9일) 메모를 폐지했습니다. 이제 각 기관이 해당 양식 사용 여부를 자체적으로 결정하므로, 특정 기관에서는 여전히 귀하에게 이를 요청할 수 있습니다.

이 양식은 어떤 소프트웨어를 다루나요?

이 지침은 2022년 9월 14일(OMB 메모 M-22-18 발령일) 이후에 개발된 소프트웨어, 해당 날짜 이후 주요 버전 변경을 거친 구형 소프트웨어, 그리고 SaaS(서비스형 소프트웨어)와 같이 제작사가 지속적으로 변경 사항을 제공하는 소프트웨어를 다룹니다. 이러한 규칙은 M-22-18 및 M-23-16에서 비롯된 것이었으나, M-26-05에 의해 폐지되었으므로 현재 해당 양식을 요청하는 기관은 자체적으로 적용 범위를 설정할 수 있습니다. 요청 기관의 지침 및 계약 조건을 확인해야 합니다. 또한 양식의 제1절에는 제품에 내장된 제3자 구성 요소를 포함하여 이 양식이 적용되지 않는 4가지 범주가 나열되어 있습니다.

이 양식은 타사 및 오픈 소스 구성 요소를 어떻게 다루나요?

이 정책은 제품에 내장된 제3자 오픈소스 및 독점 구성 요소는 보장 대상에서 제외합니다. 또한 지침에 따르면, 제3자 구성 요소를 사용하는 제조사는 해당 구성 요소에 의존함으로써 발생하는 위험을 최소화하기 위해 양식의 ‘확인’ 섹션(제III절)에 명시된 조치를 취했음을 확인해야 합니다. 공급망 보안 및 출처 확인과 관련된 두 가지 조치에서는 해당 구성 요소를 직접 명시하고 있습니다.

양식에는 허위 정보나 누락된 정보에 대해 어떻게 명시되어 있나요?

국토안보부를 위해 작성된 이 개인정보보호법 고지문에는, 요청된 정보를 제공하지 않을 경우 해당 기관이 소프트웨어 사용을 중단할 수 있다고 명시되어 있습니다. 고의로 허위 또는 오해의 소지가 있는 정보를 제공하는 행위는 형법인 미국 연방법전 제18편 제1001조를 위반할 수 있습니다. 이 양식을 사용하는 각 기관은 자체적인 개인정보보호법 고지문을 제공합니다.

제3자 평가로 서명을 대체할 수 있을까요?

네. 제작자는 연방 위험 및 승인 관리 프로그램(FedRAMP)에 따라 인증받았거나 해당 기관 담당자의 서면 승인을 받은 제3자 평가 기관(3PAO)의 평가서를 첨부할 수 있습니다. 3PAO는 해당 양식의 모든 항목을 관련 NIST 지침에 따라 평가해야 합니다. 그런 다음 제작자는 제3절의 해당 체크박스를 선택하고, 평가서를 첨부하며, 서명은 하지 않습니다.

소프트웨어가 새 버전으로 업데이트되면 인증서는 어떻게 되나요?

인증서는 제조사가 해당 개발 관행이 더 이상 준수되지 않는다고 기관들에 통보할 때까지, 명시된 제품의 향후 버전에도 구속력을 가집니다. 이는 서명란에 명시된 약속과도 일치하는데, 제조사는 해당 관행을 일관되게 적용하지 않게 될 경우 이 양식을 접수한 모든 기관에 이를 통보하기로 동의하고 있습니다.

요약