보안 규정 준수를 위한 개발자 가이드

요약

예전에는 규정 준수가 다른 누군가의 문제였습니다. 거버넌스, 리스크 관리, 규정 준수(GRC) 팀이 설문지를 작성하고, 감사관이 일 년에 한 번씩 방문하며, 개발자들은 계속해서 제품을 출시하기만 하면 됐습니다. 하지만 그런 시대는 끝났습니다. 전 세계적으로 규제 당국과 표준 기구들은 보안과 관련된 일련의 의무 사항에 합의했으며, 이러한 의무는 코드를 작성하고 애플리케이션을 출시하는 팀, 즉 엔지니어링 팀에게 직접적으로 부과되고 있습니다. 

‍

거의 모든 주요 프레임워크와 규정에서 공통적으로 나타나는 원칙들이 있습니다:

1. 소프트웨어 구성 요소에 대한 정확한 재고 목록을 관리하며, 이는 점차 소프트웨어 자재 명세서(SBOM)의 형태로 이루어지고 있습니다.
2. 알려진 취약점은 정해진 기한 내에 해결해야 하며, 심각도가 ‘중대’인 경우 대개 30일 이내로 해결해야 합니다.
3. 취약점을 식별, 우선순위 지정 및 수정하기 위한 문서화되고 반복 가능한 프로세스를 제시하십시오.

‍

수명 종료(EOL) 소프트웨어는 정의상 이 세 가지 기준을 모두 충족하지 못합니다. 프레임워크 버전, 런타임 또는 라이브러리에 대한 보안 패치 제공이 중단되면, 이후 발생하는 모든 CVE는 정상적인 경로를 통해 영구적으로 수정되지 않게 됩니다. 더 이상 패치가 제공되지 않는 것입니다. 바로 이 사실 하나만으로도 AngularJS 사용 중입니다” 또는 “아직 Node.js 16을 사용 중입니다”라는 말이 단순한 기술적 부채 논의에서 규정 준수 문제로 전환됩니다.

‍

이 백서는 개발자가 실제로 관리할 수 있는 네 가지 요소, 즉 취약점 처리, 오픈 소스 소프트웨어, 지원 버전, 지원 종료 소프트웨어에 초점을 맞춰 주요 표준, 프레임워크, 지침 및 규정을 하나씩 살펴봅니다. 각 항목에 대해 구체적인 사례와 실용적인 권장 사항을 제시합니다.

‍

미합중국

PCI DSS 4.x (지불 카드 산업 데이터 보안 표준)

적용 대상: 결제 카드 데이터를 저장, 처리 또는 전송하는 모든 기관. 계약상 의무 사항이며, 카드 브랜드 및 가맹점 결제 대행 은행에 의해 이행이 강제됩니다.

‍

요구 사항. 요구 사항 6.3.1은 조직이 업계에서 인정받는 출처를 활용하여 새로운 보안 취약점을 식별하고 위험 등급을 부여할 것을 요구합니다. 요구 사항 6.3.2는 맞춤형 및 주문 제작 소프트웨어에 대한 목록을 작성할 것을 요구하며, 여기에는 해당 소프트웨어에 통합된 타사 및 오픈 소스 구성 요소도 포함됩니다. 요구사항 6.3.3은 중대하거나 심각도가 높은 취약점에 대한 패치를 출시 후 1개월 이내에 설치하고, 그 외 적용 가능한 모든 패치는 해당 조직이 정한 기간(일반적으로 3개월) 내에 설치하도록 요구합니다. 요구사항 11.3.1은 최소 분기별로 내부 취약점 스캔을 수행하도록 규정하며, 11.3.1.1은 중대하거나 심각도가 높은 취약점이 아닌 경우에 대해 표적 위험 분석을 수행하도록 요구합니다. 이러한 모든 요구 사항을 종합하면, 요구 사항 12.3.4는 사용 중인 모든 하드웨어 및 소프트웨어에 대한 연례 검토를 의무화하며, 해당 기술에 대해 공급업체의 보안 수정 프로그램이 여전히 제공되는지, 지속적인 규정 준수를 지원하는지, 수명 종료 공지가 있는지 확인해야 하며, 구형 및 수명 종료 기술에 대한 시정 조치를 위한 고위 경영진이 승인한 계획을 수립해야 합니다.

‍

EOL 소프트웨어가 문제를 일으키는 이유입니다. 6.3.3항에 명시된 ‘1개월’ 기한은 패치가 존재한다는 전제를 바탕으로 합니다. EOL 프레임워크에 대한 중대한 CVE가 공개될 경우, 어떤 벤더나 오픈소스 프로젝트에서도 패치를 제공하지 않으므로, 해당 요건을 충족하는 것은 구조적으로 불가능해집니다. 카드 소지자 데이터 환경에서 알려진 중대한 CVE가 있는 EOL 구성 요소를 발견한 평가자는, 협상할 여지가 있는 사항이 아닌 규정 미준수 사항을 발견한 것입니다.

‍

예시. 한 결제 플랫폼이 2022년 1월에 지원이 종료된 AngularJS .x 기반으로 결제 프론트엔드를 운영하고 있다. AngularJS 대한 새로운 중대한 CVE가 공개되었습니다. 6.3.3항에 따라, 해당 조직은 아직 존재하지 않는 패치를 설치하기 위해 한 달의 기간을 부여받습니다. 현실적으로 가능한 선택지는 긴급 마이그레이션(실제 운영 중인 결제 흐름의 경우 30일 내에 완료하기 어려운 경우가 많음), 평가자가 승인해야 하는 문서화된 보완 통제 조치, 또는 백포트된 패치를 제공하고 타당한 시정 경로를 복원해 주는 상용 확장 지원 서비스입니다.

‍

개발자를 위한 권장 사항:

• 6.3.2 구성 요소 목록을 스프레드시트가 아닌 빌드 아티팩트로 관리하십시오. 목록이 항상 최신 상태를 유지할 수 있도록 매 릴리스 시 CI에서 SBOM을 생성하십시오.
• 프로덕션 환경에 있는 모든 프레임워크와 런타임의 EOL 날짜를 추적하고, 다가오는 EOL 날짜를 미처리 항목이 아닌 규정 준수 마감일로 간주하십시오.
• 이미 EOL(제품 수명 종료) 시점을 지난 구성 요소의 경우, 이를 생산 환경 밖으로 분리하거나, 마이그레이션하거나, 상용 연장 지원 계약을 체결하여 중요한 CVE에 대해 30일 이내에 패치를 적용할 수 있도록 해야 합니다.

‍

건강보험 이동성 및 책임법(HIPAA) 보안 규정

적용 대상: 미국 내에서 전자 보호 건강 정보(ePHI)를 취급하는 적용 대상 기관 및 업무 협력업체. 의무적인 연방법.

‍

요구 사항. 보안 규칙(Security Rule)은 ePHI에 대한 위험 및 취약점에 대한 정확하고 철저한 평가(45 CFR 164.308(a)(1)(ii)(A))와, 이러한 위험을 합리적이고 적절한 수준으로 낮출 수 있는 충분한 보안 조치를 요구합니다. HHS 지침은 위험 분석과 취약점 관리를 기초적인 요소로 간주하며, 시민권 보호국(OCR)의 2026년 1월 사이버 보안 뉴스레터는 위험 분석을 통해 패치가 적용되지 않은 소프트웨어와 같은 취약점을 식별하고, 이를 적극적인 시정 조치와 연계해야 한다고 명시하고 있습니다. 2024년 12월 발표된 규칙 제정 예고안(NPRM)은 한 걸음 더 나아가, 명확한 취약점 관리 및 패치 관리 기준, 최소 6개월마다 실시하는 취약점 스캔, 연례 침투 테스트, 그리고 중대한 취약점에 대해 15일 이내로 단축된 패치 적용 기한을 제안하고 있습니다. 2026년 중반 현재 이 규정 제정 예고안은 아직 확정되지 않았고 최종 조치가 지연되고 있으나, OCR은 기존 규정을 적극적으로 집행하고 있으며, 이미 위험을 문서화했음에도 이에 대한 조치를 취하지 않는 기관들을 대상으로 단속을 강화하고 있다.

‍

EOL 소프트웨어가 왜 문제가 되는가. HIPAA는 결코 “EOL 소프트웨어 사용을 금지한다”고 명시하지 않는다. 대신 안전 조치가 합리적이고 적절해야 한다고 규정하고 있다. 정보 유출 사고 발생 후, ePHI에 접근하는 시스템에서 패치할 수 없는 것으로 알려진 CVE가 존재하는 지원 종료된 구성 요소를 계속 운영하는 행위는 합리적이라고 방어하기가 극히 어렵다. OCR의 조사 결과, 매년 위험 평가에 동일한 취약점이 반복적으로 등장하지만, 악용될 때까지 아무런 완화 조치가 취해지지 않는 경우가 빈번히 발견되는데, 바로 이러한 패턴이 ‘고의적 방치’ 판정을 초래하는 원인이다.

‍

예시. 환자 포털이 지원 종료(EOL)된 Drupal v7) 버전에서 운영되고 있다. 연례 위험 분석에서 이 문제가 지적되고, 그 결과가 문서화되었으나 마이그레이션 비용이 많이 든다는 이유로 2년 동안 아무런 조치가 취해지지 않았다. 그러던 중 알려진 CVE를 통해 보안 침해 사고가 발생했다. 문서화되었으나 무시되었던 이 문제가 OCR 조사의 핵심 쟁점이 되었고, 기술적인 편법이 방치의 증거로 전락하고 말았다.

‍

개발자를 위한 권장 사항:

• ePHI와 관련된 모든 EOL 구성 요소가 시정 조치 계획 및 책임자와 함께 공식적인 위험 분석에 포함되도록 해야 합니다. 패치가 적용되지 않은 소프트웨어를 누락한 위험 분석은 이제 OCR 지침에 따라 명백히 미흡한 것으로 간주됩니다.
• 조치 과정을 완결하십시오: 확인된 각 취약점에 대해 취한 시정 조치(패치, 업그레이드, 격리, 지원 연장)를 기록하십시오. 현재 OCR 집행은 조직이 확인된 위험에 대해 어떤 조치를 취했는지에 중점을 두고 있기 때문입니다.
• NPRM이 최종 확정될 때까지 기다리지 마십시오. 이 초안에 제시된 통제 조치(스캔 주기, 패치 적용 일정, 자산 목록)는 규제 당국이 2026년에 이미 합리적인 보안 수준으로 간주하는 내용을 담고 있습니다.

‍

FedRAMP 및 NIST SP 800-53 SI-2 (결함 시정)

적용 대상: 미국 연방 기관에 판매되는 모든 클라우드 서비스. 필수 사항.

‍

요구 사항. FedRAMP 기준은 NIST SP 800-53 통제 항목을 바탕으로 수립됩니다. 통제 항목 SI-2는 조직이 시스템 결함을 식별, 보고 및 시정하고, 정해진 기간 내에 보안 관련 소프트웨어 업데이트를 설치할 것을 요구합니다. FedRAMP는 이를 심각도 기반의 시정 기한으로 구체화합니다. 즉, 심각도가 ‘높음’인 경우 30일, ‘중간’인 경우 90일, ‘낮음’인 경우 180일 이내에 시정해야 하며, 이는 월간 ‘조치 계획 및 이정표(POA&M)’ 프로세스와 지속적인 모니터링 스캔을 통해 추적됩니다.

‍

EOL 소프트웨어가 문제를 일으키는 이유. 보안 스캔 도구는 CVE를 식별합니다. 심각도가 높은 CVE가 있는 EOL 구성 요소는 30일의 기한이 부여된 POA&M 항목을 생성하지만, 적용할 패치는 없습니다. 기한이 지나도 시정 조치가 이루어지지 않은 발견 사항은 운영 승인(ATO)을 위험에 빠뜨립니다. 상업용 감사와 달리, 이는 연 1회 실시되는 행사가 아닙니다. 스캔은 매월 또는 그보다 더 자주 수행되므로, EOL 소프트웨어는 기한이 지난 발견 사항을 끊임없이 다시 생성해 냅니다.

‍

예시. FedRAMP 인증을 받은 SaaS 제공업체가 자사의 보고 서비스가 Express 지원 종료(EOL) 버전에 의존하고 있음을 발견했습니다. 보안 스캔이 수행될 때마다 해당 구성 요소가 다시 문제로 표시되고, 새로운 CVE가 발생할 때마다 30일 또는 90일 기한의 POA&M 항목이 생성되며, 제3자 평가 기관(3PAO)의 평가자는 지원이 중단된 종속성을 지속적인 취약점으로 분류합니다. 해당 제공업체는 신뢰할 수 있는 마이그레이션 단계별 계획을 제시하거나, 패치 제공을 재개할 수 있는 공급업체의 지원을 입증해야 합니다.

‍

개발자를 위한 권장 사항:

• FedRAMP의 30일/90일/180일 기한을 엔지니어링 SLA로 간주하고, 이를 이슈 트래커에 연동하여 취약점 티켓에 마감일이 자동으로 반영되도록 하십시오.
• 초기 평가 전에 단종(EOL) 부품에 대한 보장을 제거하거나 지원 범위를 확보하십시오. 이는 이후 매달 반복되는 POA&M 항목을 처리하는 것보다 훨씬 비용이 적게 듭니다.
• 편차 요청과 위험 조정은 정직하게 처리하고 빈도를 최소화해야 합니다. 평가자들은 패턴을 추적하며, 근거가 부족한 동일한 구성 요소에 대해 반복적으로 편차 요청이 제기될 경우 이는 관리가 제대로 이루어지지 않은 위험을 시사합니다.

‍

NIST 사이버보안 프레임워크(CSF) 2.0

적용 대상: 대부분의 민간 기관의 경우 자발적으로 적용되며, 미국 연방 기관의 경우 의무적으로 적용되고 해당 기관의 계약업체에도 광범위하게 요구됩니다. 또한 사이버 보험 및 이사회 보고를 위한 사실상의 기준 모델이기도 합니다.

‍

요구 사항. CSF 2.0의 하위 범주 PR.PS-02는 소프트웨어를 “위험 수준에 상응하는 방식으로 유지 관리, 교체 및 제거”해야 한다고 명시하고 있습니다. ID.RA 하위 범주는 자산의 취약점을 식별, 검증 및 기록할 것을 요구합니다. 이 프레임워크는 결과 중심적입니다. 즉, 패치 적용 기간을 규정하지는 않지만, 환경 내의 모든 소프트웨어가 위험 수준에 따라 적극적으로 유지 관리되거나 의도적으로 폐기되어야 한다는 기대치를 설정합니다.

‍

EOL 소프트웨어가 문제를 일으키는 이유. EOL 소프트웨어는 정의상 더 이상 유지보수되지 않습니다. PR.PS-02에 따르면, 조직은 이러한 소프트웨어에 대해 ‘교체’, ‘제거’, ‘유지보수 재개’라는 딱 세 가지 정당화 가능한 상태만을 가질 수 있습니다. 아무런 조치 없이 계속 실행하는 것은 이 프레임워크에서 허용하지 않는 유일한 상태입니다. 또한 이 프레임워크는 상용 확장 지원이 가장 명확하게 부합하는 곳이기도 한데, 이는 공급업체가 지원하는 EOL 구성 요소에 대한 패치 적용이 말 그대로 ‘유지보수 중인’ 상태를 구성하기 때문입니다.

‍

예시. 사이버 보험 갱신을 위해 CSF 2.0 기준을 준수하려는 한 제조업체가 공장 현장의 애플리케이션을 점검하던 중, Vue 2 종료(EOL) Vue 2 지원 종료된 Node.js 런타임 버전으로 구축된 스케줄링 도구를 발견했습니다. 보험사의 설문지에는 모든 소프트웨어가 지원되고 패치가 적용되었는지 묻는 항목이 있습니다. 정직하게 답변하려면 구체적인 일정이 명시된 마이그레이션 계획이나 지원 계약이 필요하며, 부정직하게 답변할 경우 사고 발생 후 보험금 청구 주장이 무효화됩니다.

‍

개발자를 위한 권장 사항:

• 모든 애플리케이션을 다음 세 가지 상태 중 하나로 분류하십시오: 업스트림 프로젝트에서 적극적으로 유지 관리 중인 상태, 상용 확장 지원을 통해 유지 관리 중인 상태, 또는 교체/제거 일정이 정해진 상태. 분류되지 않은 항목은 모두 PR.PS-02의 미비 사항으로 간주됩니다.
• EOL 및 지원 상태 데이터를 CSF 프로파일링에 사용되는 동일한 자산 목록에 반영하여, 위험 책임자가 중요도 정보와 함께 소프트웨어 수명 주기 상태를 확인할 수 있도록 한다.
• 위험 관련 결정을 기록하십시오. CSF는 증거에 기반합니다. “3분기 마이그레이션 때까지는 이 위험을 수용한다”는 입장과 “아무도 검토하지 않았다”는 입장의 차이는 바로 문서화 여부에 있습니다.

‍

NIST SSDF (SP 800-218, 보안 소프트웨어 개발 프레임워크)

적용 대상: 자발적 지침. OMB 각서 M-26-05는 이전에 행정명령 14028호 및 OMB 각서 M-22-18/M-23-16에 따라 미국 연방 기관에 제품을 판매하는 소프트웨어 공급업체에 의무화되었던 자체 인증 요건을 철회했습니다. 각 기관은 자체 위험 평가를 바탕으로 여전히 인증서 또는 SBOM 제출을 요구할 수 있습니다.

‍

요구 사항. SSDF는 보안을 ‘좌측으로 이동(shift left)’하는 데 중점을 둔 유연한 프레임워크로, 이는 보안이 소프트웨어 제작 전 과정에 내재되어 있음을 의미합니다. 이에 따라 조직은 안전한 개발 정책(PO 관행)을 정의하고 유지하며, 소프트웨어를 보호(PS)하고, 보안이 철저히 확보된 소프트웨어를 생산(PW)하며, 취약점에 대응(RV)해야 합니다. PW.4 관행은 보안이 철저히 확보된 소프트웨어의 재사용을 다루며, 조직이 타사 및 오픈소스 구성 요소를 평가하고 모니터링할 것을 요구합니다. RV 관행 그룹은 출시된 소프트웨어의 취약점을 지속적으로 식별, 평가 및 수정할 것을 요구하며, 이는 관련된 구성 요소가 여전히 수정 패치를 받을 수 있음을 전제로 합니다.

‍

EOL 소프트웨어가 문제를 일으키는 이유. 공급업체는 더 이상 보안 업데이트를 제공받지 않는 구성 요소로 구축된 제품에 대해 SSDF 준수 취약점 대응을 보장할 수 없습니다. PW.4가 요구하는 ‘유지 관리되는 출처에서 구성 요소를 확보해야 한다’는 기준과 RV가 요구하는 ‘지속적인 수정 조치’는, 기반이 되는 오픈소스 프로젝트의 지원이 종료되면 모두 무의미해집니다.

‍

예시. 연방 기관에 제품을 판매하는 한 소프트웨어 회사가 자발적으로 CISA 보안 소프트웨어 개발 확인서에 서명했다. 그러나 이 회사의 주력 제품에는 여전히 jQuery .x와 지원 종료(EOL)된 Bootstrap 포함되어 있다. 법무팀은 엔지니어링 팀에 해당 확인서의 내용이 정확한지 문의한다. 엔지니어링 팀은 서둘러 수정 프로그램을 마련하거나, 의존성 구조와 모순되는 내용을 확인서에 기재해야 하는데, 이는 단순한 보안 위험이 아닌 허위 진술의 위험을 초래한다.

‍

개발자를 위한 권장 사항:

• 도입 후가 아니라 도입 전에 모든 새로운 종속 요소의 지원 현황과 EOL 시점을 기록하는 오픈소스 도입 정책을 수립한다.
• CVE뿐만 아니라 라이프사이클 이벤트(유지보수 모드, 아카이브된 저장소, 발표된 EOL 날짜)에 대해서도 종속성을 모니터링해야 합니다. 프로젝트의 지원 종료는 보안 사건입니다.
• 연방 인증을 진행하기 전에, 종속성 수명 주기 감사를 실시하고, 제품에 포함된 모든 EOL(지원 종료) 구성 요소에 대해 문제를 해결하거나 지원 범위를 확보해야 합니다.

‍

NIST SP 800-171 및 사이버보안 성숙도 모델 인증(CMMC)

적용 대상: 통제 대상 비기밀 정보(CUI)를 취급하는 국방부(DoD) 계약업체 및 연방 공급업체. 의무 사항이며, 현재 CMMC 평가가 국방부 계약에 단계적으로 도입되고 있습니다.

‍

요구 사항. 요구 사항 3.14.1(Rev 3에서 03.14.01로 번호가 변경됨)은 시스템 결함을 적시에 식별, 보고 및 시정할 것을 요구합니다. 평가 지침은 시정의 증거로 설치된 패치, 서비스 팩 및 핫픽스를 직접 언급하고 있습니다. 관련 요구 사항으로는 취약점 스캔 및 시정 조치가 포함됩니다(3.11.2, 3.11.3).

‍

EOL 소프트웨어가 문제를 일으키는 이유. “결함을 적시에 수정한다”는 원칙에는 공급업체나 오픈소스 프로젝트가 수정본 제공을 중단한 소프트웨어에 대한 예외가 없습니다. CUI 엔클레이브 내에 알려진 CVE가 포함된 EOL 구성 요소는 3.14.1 조항을 지속적으로 위반하는 것으로 간주되며, CMMC 평가관은 이를 계약업체에 불이익으로 반영할 것입니다. 단 한 가지 실천 사항만 미준수되어도 인증을 취득하지 못하게 되어, 결과적으로 계약 자격을 상실할 수 있습니다.

‍

예시. 한 방위산업체 공급업체의 엔지니어링 문서 포털이 단종된(EOL) 웹 프레임워크에서 운영되고 있다. CMMC 레벨 2 평가 과정에서 평가관은 포털의 결함이 적시에 수정되었음을 입증할 증거를 요청한다. 공급업체는 CVE를 식별한 스캔 보고서를 제시할 수는 있지만, 상류 단계에서 수정 조치가 이루어지지 않았기 때문에 수정 내역은 제시할 수 없다. 이로 인해 해당 항목은 ‘미달’로 평가되어, 회사가 국방부(DoD) 계약을 유지하는 데 필요한 인증 획득이 위태로워진다.

‍

개발자를 위한 권장 사항:

• 범위를 적극적으로 설정하십시오: 가능한 한 EOL 소프트웨어를 CUI 경계 밖으로 완전히 배제하십시오. 경계 내의 모든 항목은 평가 대상이 되기 때문입니다.
• EOL(제품 수명 종료) 구성 요소가 적용 범위 내에 남아 있어야 하는 경우, 보완 통제 조치를 문서화하고 이를 지원되는 패치 출처와 연계하여 “적시 수정”이 입증될 수 있도록 해야 합니다.
• 패치 관련 증거 자료(티켓, 배포 로그, 스캔 전후 결과)를 요구사항별로 체계적으로 정리해 두십시오. CMMC 평가는 증거 자료를 바탕으로 진행되며, 문서화되지 않은 수정 사항은 수정 조치가 전혀 없는 경우와 동일한 점수를 받습니다.

‍

SEC 사이버보안 공시 규정

적용 대상: 미국의 모든 상장 기업. 의무 사항이며, 2023년 12월부터 시행됩니다.

‍

요구 사항. 등록 기업은 중대성이 확인된 날로부터 4영업일 이내에 양식 8-K를 통해 중대한 사이버 보안 사고를 공시해야 하며, 매년 연차 보고서(양식 10-K)를 통해 사이버 보안 위험 관리, 전략 및 거버넌스에 대한 이사회 감독을 포함하여 중대한 사이버 보안 위험을 평가, 식별 및 관리하는 절차를 공시해야 합니다(규정 S-K 항목 106).

‍

여기서 EOL 소프트웨어가 중요한 이유는 무엇일까요? 규정에는 패치나 EOL 소프트웨어에 대한 언급이 없습니다. 하지만 ‘중대성’ 기준에는 포함되어 있습니다. 기업이 의존하는 구성 요소에 알려진 패치되지 않은 중대한 취약점이 존재하는 것 자체가 공시가 필요한 중대한 위험을 구성할 수 있으며, EOL로 알려진 시스템에서 비롯된 사고는 바로 보안 침해 사건을 증권 소송으로 전환시키는 전형적인 사례입니다. 원고 측은 해당 위험이 알려져 있었음에도 불구하고 시정되지 않았고, 공시도 부적절했다고 주장할 것이기 때문입니다.

‍

예시. 한 금융 서비스 기업이 EOL(지원 종료) 상태인 Spring 사용하는 Java 기반 앱을 통해 보안 침해 사고를 겪었다. 사고 대응 과정에서 변호사는 6개월 전에 이미 EOL 상태를 지적한 내부 티켓이 있었다는 사실을 발견했다. 이제 4일 이내의 공개 기한을 지키는 것은 쉬운 문제다. 어려운 점은, 이사회 감독 절차가 직접적인 감시를 받는 상황에서, 문서화되어 있고 이미 알려진 위험이 왜 전혀 시정되지 않았는지를 8-K 보고서 및 후속 제출 서류에서 설명해야 한다는 것이다.

‍

개발자를 위한 권장 사항:

• EOL 소프트웨어와 관련된 내부 엔지니어링 기록(티켓, 슬랙 스레드, 위험 등록부 항목 등)은 정보 공개 대상이 될 수 있으며, 사고 발생 시 공개된 정보와 대조하여 검토될 것임을 인지해야 합니다.
• 보안 및 법무 팀에 정확한 라이프사이클 데이터를 제공하십시오. EOL(제품 수명 종료) 관련 노출 현황을 솔직하게 파악함으로써, 기업은 항목 106 공시에서 자사의 위험 관리 프로세스를 사실에 입각하여 설명할 수 있습니다.
• 매출에 결정적인 영향을 미치는 경로에서 수명이 종료된(EOL) 구성 요소의 수정 조치를 최우선으로 처리해야 합니다. 바로 그곳이 “중요”와 “패치 미적용”이 교차하는 지점이기 때문입니다.

‍

캐나다

CCSPA (중요 사이버 시스템 보호법, 법안 C-8)

적용 대상: 연방 정부가 규제하는 핵심 인프라(통신, 은행, 에너지, 교통) 분야의 지정 운영자. 의무 사항. C-8 법안은 2026년 6월 15일에 왕실 승인을 받았으며, CCSPA의 의무 사항은 각료회의 명령에 따라 단계적으로 시행될 예정입니다.

‍

요구 사항. 지정 사업자는 사이버 보안 프로그램을 수립 및 이행하고, 공급망 및 제3자 관련 위험을 완화하며, 정해진 기한 내에 사이버 보안 사고를 보고하고, 사이버 보안 지침을 준수하며, 관련 기록을 보관해야 합니다. 조직에 부과되는 벌금은 최대 1,500만 캐나다 달러에 달하며, 위반 상태가 지속될 경우 매일 별도로 과태료가 부과될 수 있습니다. 이사회 이사 및 임원은 조직의 규정 미준수를 지시, 승인하거나 묵인한 경우 개인적으로 책임을 질 수 있습니다.

‍

EOL 소프트웨어가 문제를 일으키는 이유. 공급망 리스크 관리 의무는 소프트웨어 스택 내부까지 직접 미칩니다. 중요한 사이버 시스템 내에 패치가 적용되지 않은 오픈 소스 라이브러리나 EOL 프레임워크가 존재하는 것은 바로 해당 프로그램이 식별하고 완화해야 할 제3자 리스크의 전형적인 사례이며, 일일 과태료가 부과되는 상황에서 “알고도 아무 조치도 취하지 않았다”는 태도는 막대한 비용을 초래할 수 있습니다. CCSPA는 취약점이 악용되기 전에 이를 패치하거나 격리하기 위한 정기적인 취약점 평가, 시스템 스캔 및 적극적인 완화 계획을 포함하는 프로그램을 요구합니다.

‍

예시. 연방 정부의 규제를 받는 한 에너지 사업자의 정전 관리 포털이 Angular 운영되고 Angular . CCSPA에 따라 지정된 사업자는 사이버 보안 프로그램에서 공급망 위험을 문서화해야 한다. 평가 과정에서 지원 종료된 프론트엔드가 확인되면, 해당 사업자는 완화 조치를 제시해야 하며, 실제로는 정해진 일정에 따른 마이그레이션, 격리 조치, 또는 패치 SLA를 포함한 공급업체 지원 복원을 의미한다.

‍

개발자를 위한 권장 사항:

• 귀사의 고용주가 캐나다의 통신, 금융, 에너지 또는 운송 산업 분야에서 사업을 영위하고 있다면, 지금 바로 소프트웨어 수명 주기 현황 조사를 시작하십시오. 관련 지정 및 규제가 단계적으로 도입되고 있으며, 지정 이후에 프로그램을 구축하게 되면 서둘러 진행해야 할 수밖에 없습니다.
• CCSPA 목적상 오픈 소스 종속성을 공급업체로 간주하십시오. 각 핵심 구성 요소를 누가 유지 관리하는지, 지원 상태는 어떠한지, 보안 수정 사항이 어떻게 전달되는지를 기록하십시오.
• 엔지니어링 업무 절차에 사고 보고 대비 체계를 구축(로그 보존, 구성 요소 수준의 영향 범위 매핑 등)하여, 보고서를 통해 영향을 받은 시스템과 구성 요소를 신속하게 파악할 수 있도록 해야 합니다.

‍

유럽 연합

DORA(디지털 운영 복원력 법)

적용 대상: EU 금융 기관(은행, 보험사, 투자 회사, 결제 기관, 암호자산 제공업체) 및 핵심 ICT 제3자 제공업체. 의무 사항이며, 2025년 1월 17일부터 시행됩니다.

‍

요구 사항. DORA의 ICT 위험 관리 프레임워크는 금융 기관이 신뢰할 수 있고, 충분한 용량을 갖추며, 기술적으로 복원력이 뛰어난 ICT 시스템을 사용하도록 요구합니다. 또한 모든 ICT 자산에 대한 최신 목록을 유지 관리하고(수명 종료 시점이 임박한 자산의 추적 포함), 패치 관리를 이행하며, 레거시 ICT 시스템을 파악하고 문서화하여 이를 단계적으로 폐지하거나 체계적으로 관리하도록 규정하고 있습니다.

‍

EOL 소프트웨어가 왜 문제를 일으키는가. DORA는 유난히 직설적이다. 지원이 중단된 시스템은 운영 복원력의 근본적인 결함으로 간주되며, 자산 목록 작성 의무는 특히 EOL 추적을 전제로 하고 있다. 결제 또는 거래 경로에서 EOL 소프트웨어를 운영하는 금융 기관은 문서화된 복원력 결함을 안고 있는 것이며, 감독 당국과 감사인은 이를 반드시 점검하도록 지시받고 있다.

‍

예시. 한 EU 결제 기관의 거래 대시보드는 2023년 12월부로 지원 종료(EOL)된 Vue 2 기반으로 운영되고 있습니다. DORA 자산 목록에는 이 사실과 중요도, 그리고 관련 계획이 반드시 기록되어야 합니다. 감독 당국의 검토 과정에서 “계획 없음”은 문제점으로 지적되며, “2027년으로 마이그레이션이 예정되어 있고, 그간 상용 보안 패치를 통해 보안을 유지할 예정”인 경우는 관리 중인 레거시 시스템으로 간주됩니다.

‍

개발자를 위한 권장 사항:

• ICT 자산 목록에 사용 종료일(EOL) 및 지원 상태를 필수 입력 항목으로 추가하고, 종속성 매니페스트에서 해당 정보를 자동으로 가져오도록 설정하십시오.
• 중요하거나 핵심적인 기능을 수행하는 레거시 또는 EOL 구성 요소에 대해서는, ‘지정된 날짜까지 마이그레이션’, ‘지정된 날짜까지 사용 중단’, 또는 ‘앞의 두 가지 중 하나가 이루어질 때까지 패치를 적용하여 유지’라는 세 가지 계획 중 하나를 문서화해야 합니다.
• 복원력 가정에 대한 검증: DORA는 디지털 운영 복원력에 대한 테스트를 요구하며, 취약점이 확인된 단종(EOL) 구성 요소는 위협 중심의 침투 테스트에서 가장 먼저 악용되는 대상이 됩니다.

‍

GDPR(일반 데이터 보호 규정), 제32조

적용 대상: 소재지에 관계없이 EU 개인 데이터를 처리하는 모든 조직. 필수 사항.

‍

요구 사항. 제32조는 위험에 상응하는 보안 수준을 보장하기 위해 “적절한 기술적·조직적 조치”를 취할 것을 요구하며, 이때 “최신 기술 수준”을 명시적으로 고려해야 한다고 규정하고 있습니다. 다만, 이 조항은 패치 적용, 이행 기한 또는 특정 기술을 의무화하지는 않습니다.

‍

EOL 소프트웨어가 문제를 일으키는 이유. 여기서 중요한 표현은 “최신 기술 수준”입니다. 개인 정보 유출 사고가 발생한 후, 감독 당국은 당시 이용 가능한 기술 수준을 고려했을 때 시행된 조치가 적절했는지 여부를 묻습니다. 공개된 CVE가 있고, 패치가 제공되지 않으며, 지원 기간이 오래 전에 만료된 소프트웨어를 계속 사용하는 것은 ‘최신 기술 수준’에 부합한다고 주장하기 매우 어렵습니다. 실제로 유럽 규제 당국은 알려진 패치되지 않은 취약점을 통해 정보 유출 사고가 발생한 조직에 대해 반복적으로 과징금을 부과해 왔습니다.

‍

예시. EU 고객 데이터를 처리하는 마케팅 SaaS 업체가, 지원이 종료된(EOL) jQuery 체인의 알려진 CVE를 통해 보안 침해를 당했다. 제32조에 따른 분석은 해당 기업이 불운했는지 여부가 아니라, 공개된 악용 코드가 존재하는 지원이 중단된 구성 요소를 계속 사용한 것이 “적절했는지”에 관한 것입니다. GDPR에 따른 과징금은 기본 원칙 위반 사항이 함께 발견될 경우 전 세계 연간 매출액의 최대 4%에 달할 수 있으며, 알려진 취약점을 통한 정보 유출은 전형적인 가중 사유(과실 및 기술적 조치의 미비)에 해당합니다.

‍

개발자를 위한 권장 사항:

• 개인 정보를 처리하는 시스템의 취약점 완화를 우선순위로 삼고, 그 우선순위 결정 논리를 입증할 수 있어야 합니다.
• 부품이 EOL(생산 종료) 상태가 되면, 당시의 위험 대응 결정(이전, 격리, 지원 계약)을 기록해 두어야 합니다. 당시 상황을 반영한 문서화가 제32조에 따른 가장 강력한 방어 수단이 되기 때문입니다.
• 레거시 시스템에서 데이터 최소화를 실천하십시오. 수명 종료(EOL) 시스템이 처리하는 개인 데이터가 적을수록, 마이그레이션이 진행되는 동안 제32조에 따른 위험 노출 정도도 줄어듭니다.

‍

NIS2 지침

적용 대상: EU 내 18개 부문(에너지, 교통, 보건, 디지털 인프라, 핵심 제품 제조, 디지털 서비스 제공업체 등)에 걸친 필수 및 중요 기관. 의무 사항이며, 회원국 법으로의 이관은 2024년 10월까지 완료되어야 했으며, 현재 각 회원국에서 자체 일정에 따라 시행이 본격화되고 있다.

‍

요구 사항. 제21조 제2항은 (e) “취약점 처리 및 공개를 포함한 네트워크 및 정보 시스템의 조달, 개발 및 유지보수 시 보안”과 (d) 직접 공급업체 및 서비스 제공업체와의 관계를 포괄하는 공급망 보안을 포함하여 10가지 최소 위험 관리 조치를 의무화하고 있다. 제21조 제3항은 해당 기관이 각 공급업체별 고유한 취약점과 공급업체 제품의 전반적인 품질 및 안전한 개발 관행을 고려할 것을 요구한다. 제23조는 사고 보고 기한을 24시간(조기 경보), 72시간(통지), 1개월(최종 보고서)로 정하고 있다. 필수 기관에 대한 과태료는 1,000만 유로 또는 전 세계 매출액의 2%에 달하며, NIS2는 경영진의 개인적 책임도 추가하고 있다.

‍

EOL 소프트웨어가 왜 문제를 일으키는가. 제21조(2)(e)항은 개발 및 유지보수 단계에서의 취약점 처리를 법적 의무로 규정하고 있으며, EOL 소프트웨어란 취약점 처리가 구조적으로 종료된 소프트웨어를 의미한다. 제21조(2)(d)항 및 제21조(3)항에 따른 공급망 조치는 동일한 논리를 오픈소스 구성 요소로까지 확대 적용한다. 즉, 사업자는 자사가 의존하는 소프트웨어의 보안 관행을 고려해야 하는데, 중단된 업스트림 프로젝트에는 그러한 보안 관행이 존재하지 않는다.

‍

예시. 한 병원 그룹(핵심 기관)이 EOL(지원 종료) 상태인 Nuxt 애플리케이션에서 직원 근무 일정 관리 시스템을 운영하고 있다. 해당 스택의 알려진 CVE를 통해 랜섬웨어 사고가 발생합니다. 24시간 보고 기한이 지난 후, 국가 당국의 조사에서는 제21조에 따른 조치가 마련되어 있었는지 여부를 검토합니다. 문서화된 대응 방안이 없는, EOL이 확정되고 취약점이 알려진 시스템은 제21조(2)(e)항 위반에 해당하며, NIS2에 따라 경영진은 위험 관리 조치를 승인한 데 대한 개인적 책임을 집니다.

‍

개발자를 위한 권장 사항:

• 오픈 소스 종속성을 명시적으로 포함하는 취약점 처리 프로세스를 구축하십시오. 여기에는 식별(SCA 스캔), 우선순위 분류, 수정 조치 SLA, 공개 처리 등이 포함됩니다.
• 필수적이거나 중요한 서비스를 지원하는 시스템에 대한 SBOM을 관리하여, 공급망 관련 문의에 데이터를 바탕으로 답변할 수 있도록 해야 합니다.
• EOL(제품 수명 종료) 관련 사항을 경영진에 서면으로 보고하십시오. NIS2의 개인 책임 조항에 따라 경영진은 이를 반드시 파악해야 하며, 정확한 수명 주기 데이터를 제공하는 것은 엔지니어의 업무 중 하나입니다.

‍

사이버 복원력법(CRA)

적용 대상: 제조업체의 소재지와 관계없이, EU 시장에 출시된 “디지털 요소가 포함된 제품”(하드웨어 및 소프트웨어 모두 포함)의 제조업체, 수입업체 및 유통업체. 의무 사항. 악용 중인 취약점 및 중대한 사고에 대한 보고 의무는 2026년 9월 11일부터 적용되며, 전체 필수 요건, 적합성 평가 및 CE 마킹은 2027년 12월 11일부터 적용됩니다. 과태료는 1,500만 유로 또는 전 세계 매출액의 2.5%에 달합니다.

‍

요구 사항. 이 법은 제품의 전체 수명 주기에 걸쳐 제품 자체를 규제하기 때문에, 이 목록에 포함된 법안 중 개발자에게 가장 중대한 영향을 미치는 법입니다. 부속서 I 제1부에서는 제품에 알려진 악용 가능한 취약점이 없어야 한다고 규정하고 있습니다. 부속서 I 제2부에서는 취약점 처리 요건을 규정하고 있습니다. 제조사는 취약점과 구성 요소를 식별하고 문서화해야 하며, 여기에는 최소한 최상위 종속성을 포함하는 기계 판독 가능 형식의 SBOM 작성이 포함됩니다. 또한 무료 보안 업데이트를 통해 지체 없이 취약점을 해결하고, 효과적이고 정기적인 보안 테스트를 실시하며, 수정된 취약점을 공개해야 합니다. 이러한 의무는 지원 기간 동안 지속되며, 대부분의 경우 지원 기간은 최소 5년이어야 합니다. 제14조는 적극적으로 악용되고 있는 취약점에 대해 ENISA 및 국가 CSIRT에 수정 프로그램이 제공된 후 24시간 이내(조기 경보), 72시간 이내(전체 통지), 14일 이내(최종 보고서)에 보고할 것을 요구합니다. 특히, 2026년 9월의 보고 의무는 수년 전에 출하된 레거시 제품을 포함하여 이미 시장에 출시된 제품에도 적용됩니다.

‍

바로 이 점에서 오픈 소스와 EOL(지원 종료) 소프트웨어가 지대한 중요성을 띱니다. 오픈 소스 구성 요소를 제공하는 상용 벤더는 해당 구성 요소의 취약점에 대해 법적 책임을 집니다. 출시된 제품 내의 오픈 소스 라이브러리에서 실제로 악용되고 있는 취약점이 발견될 경우, 업스트림 프로젝트가 여전히 존재하는지 여부와 관계없이 귀사에 보고 기한이 적용되며, “지체 없이” 이를 시정해야 할 의무가 귀사에 부과됩니다. EOL(지원 종료) 프레임워크를 기반으로 구축된 제품을 출시한다는 것은, 법적으로 해당 컴포넌트의 업스트림 측에서 더 이상 처리하지 않을 취약점을 처리해야 할 책임을 지는 것을 의미합니다. CRA(사이버 보안 책임법)는 “오래된 종속성 내의 무시된 CVE”를 기술적 부채에서 기술 규제 중 가장 높은 벌금 상한선이 적용되는 법적 책임으로 전환시킵니다.

‍

예시. 한 ISV가 EU 시장에 문서 관리 제품을 판매하고 있다. 이 제품 Bootstrap Express Bootstrap . 2026년 10월, Express CVE가 실제로 악용되는 사례가 발생했다. 제14조에 따라 공급업체는 24시간 이내에 조기 경보를 제출하고, 72시간 이내에 완전한 통지를 제공하며, 수정 프로그램이 마련된 후 14일 이내에 최종 보고서를 제출해야 한다. 업스트림 수정 패치가 없는 경우, 공급업체는 자체적으로 백포트된 패치를 제작하거나, 확장된 상용 지원을 통해 패치를 구매하거나, 여전히 판매 중인 제품에 대한 수정 패치가 제공되지 않는 이유를 규제 당국에 설명해야 합니다.

‍

개발자를 위한 권장 사항:

• 지금부터 출하되는 모든 제품에 대해 기계 판독 가능한 SBOM(CycloneDX 또는 SPDX)을 생성하고 관리하십시오. 각 제품 버전에 어떤 구성품이 포함되어 있는지 미리 파악해 두지 않으면, 2026년 9월에 24시간 내 보고 기한을 준수할 수 없습니다.
• 모든 제품 라인을 대상으로 단종 예정(EOL) 부품을 점검하고, 2027년 12월 이전에 각 항목을 해결하십시오. 즉, 업그레이드하거나, 제거하거나, 또는 지정된 지원 기간 동안 패치를 제공할 수 있는 지원 계약을 체결하십시오.
• 제품별로 현실적인 지원 기간을 정의하고 공개하며, 해당 약속에 따른 패치 비용(타사 구성 요소 포함)을 제품 계획에 반영해야 합니다. 지원 기간은 이제 단순한 마케팅 문구가 아닌 법적 약속입니다.
• 24시간 및 72시간 단위를 기준으로 시뮬레이션한, 체계적인 취약점 공개 정책과 접수-선별-보고 워크플로를 수립하십시오.

‍

영국

영국 GDPR

적용 대상: 영국 개인 데이터를 처리하는 조직. 의무 사항이며, 정보위원회(ICO)에서 이를 집행합니다.

‍

요구 사항. 브렉시트 이후에도 EU GDPR에서 계승된 영국 GDPR은 제32조에 명시된 “적절한 기술적·조직적 조치”라는 동일한 의무를 규정하고 있습니다. ICO의 집행 실적을 통해 이 조항의 해석이 명확해집니다. 알려진 취약점에 대한 패치를 적용하지 않는 행위는 적절한 보안 조치 미이행으로 간주되며, 지원이 중단되었거나 오랫동안 패치가 적용되지 않은 소프트웨어로 인해 발생한 정보 유출 사고는 단순한 불운이 아닌 과실로 간주됩니다.

‍

예시. ICO는 영국 증권투자협회(CISI)가 지원 종료(EOL)된 웹사이트 소프트웨어를 운영함으로써 제32조를 위반한 사실을 확인했다. 게다가 공격자들은 2017년부터 패치가 제공되었음에도 불구하고 적용되지 않았던 중대한 취약점을 악용했다.

‍

개발자를 위한 권장 사항:

• EU GDPR과 동일한 기준을 적용해야 합니다. 즉, 자산 목록 작성, 개인 데이터와 관련된 시스템에 대한 우선순위 기반 패치 적용, 그리고 수명 종료(EOL) 구성 요소에 대한 위험 결정 사항을 실시간으로 문서화해야 합니다.
• 레거시 시스템을 신속하게 마이그레이션할 수 없는 경우에는, 해당 시스템에 저장된 개인 데이터의 양을 줄이고 시스템을 격리한 뒤, 두 가지 조치에 대한 증거를 모두 보관해야 합니다.
• ICO 지침 및 집행 공지를 주시하십시오. 이러한 자료들은 실무에서 ‘적절한’이 무엇을 의미하는지에 대한 지속적인 판례 기록의 역할을 합니다.

‍

2018년 영국 국가정보보안 규정

적용 대상: 필수 서비스(수도, 에너지, 교통, 보건) 운영자 및 관련 디지털 서비스 제공업체(클라우드, 온라인 마켓플레이스, 검색). 의무적이며 법적 구속력이 있습니다.

‍

요구 사항. 운영자는 네트워크 및 정보 시스템에 대한 위험을 관리하고, 사고의 영향을 예방 및 최소화하기 위해 적절하고 비례적인 조치를 취해야 하며, 중대한 사고 발생 시 72시간 이내에 보고해야 합니다. 영국 규제 당국이 규정 준수 여부를 평가하는 데 사용하는 NCSC의 사이버 평가 프레임워크(CAF)에는 취약점 관리 및 시스템 유지 관리에 관한 목표가 포함되어 있습니다. 실제로, 패치 적용 시의 적시성에 대한 기대치는 대개 14일 이내에 중요 업데이트를 적용해야 한다는 ‘사이버 에센셜(Cyber Essentials)’의 기준과 일치하는 경우가 많습니다.

‍

EOL 소프트웨어가 문제를 일으키는 이유. 필수 서비스를 중단시키는 사고가 패치가 적용되지 않은 EOL 시스템에서 비롯된 것으로 밝혀질 경우, 규제 당국은 서비스 연속성 유지 의무 위반으로 판단할 가능성이 높으며, 72시간 내 제출해야 하는 보고서는 제재 조치의 첫 번째 근거 자료가 됩니다. 패치 소스가 없는 소프트웨어의 경우, 14일 이내에 패치를 적용해야 한다는 기대치는 달성할 수 없습니다.

‍

예시. 영국 한 수도 사업자의 원격 측정 대시보드가 AngularJS 실행되고 있다. 알려진 CVE가 악용되어 하루 동안 운영 가시성을 상실했다. 이 사고는 72시간 이내에 보고해야 하며, 이후 진행되는 CAF 평가에서는 취약점 관리 현황을 검토한다. 공개된 CVE가 있고 패치 경로가 없는 지원 종료된 구성 요소는 여러 CAF 평가 항목에서 낮은 점수를 받게 된다.

‍

개발자를 위한 권장 사항:

• CAF를 기준으로 필수 서비스 시스템을 대조 분석하고, 지원되지 않는 모든 구성 요소를 표시하십시오. CAF는 시스템이 지원되는지 여부와 취약점이 적절히 관리되고 있는지 여부를 명시적으로 검토합니다.
• 필수 서비스 환경에 속한 모든 항목에 대해 14일 이내에 중요 패치를 제공할 수 있는 패치 공급원(업스트림 또는 상용)을 구축한다.
• 엔지니어링 팀과 함께 72시간 보고 절차를 미리 연습하여, 구성 요소 수준의 사실 정보(어떤 부분이 취약했는지, 언제부터 취약했는지, 어떤 조치가 취해졌는지)를 신속하게 파악할 수 있도록 하십시오.

‍

아시아·태평양

APPI (일본, 개인정보보호법)

적용 대상: 일본 내 개인의 개인정보를 취급하는 조직. 필수 사항.

‍

요구 사항. APPI는 사업자에게 개인정보의 보안 관리를 위해 유출, 분실 또는 훼손을 방지할 수 있는 필요하고 적절한 조치를 취할 것을 요구합니다. 개인정보보호위원회의 지침은 이를 조직적, 인적, 물리적, 기술적 보안 조치로 구체화하고 있으며, 기술적 보안 조치에는 소프트웨어 유지보수, 정기적인 보안 패치 적용, 취약점 모니터링 등이 포함됩니다.

‍

EOL 소프트웨어가 문제가 되는 이유. GDPR과 마찬가지로, 이 법률은 EOL 소프트웨어를 명시적으로 언급하지는 않지만, 규제 당국은 지원 및 유지보수가 이루어지는 소프트웨어의 사용을 분명히 기대하고 있습니다. 지원이 중단된 소프트웨어의 알려진 취약점을 통해 개인 데이터가 유출되는 것은 “필요하고 적절한” 보안 관리 기준과 양립하기 어렵으며, (2022년 개정안에서 도입된) 의무적인 침해 사고 신고 제도로 인해 이러한 사고는 반드시 규제 당국에 보고됩니다.

‍

예시. 일본의 한 전자상거래 사업자가 자사 계정 포털에 사용 중인 자바스크립트 프레임워크의 지원 종료(EOL) 버전을 통해 데이터 유출 사고를 겪었다. PPC에 의무적으로 제출된 보고서를 계기로 기술적 보안 조치에 대한 조사가 진행되었고, “해당 구성 요소가 3년 동안 지원이 중단된 상태였다”는 사실이 핵심 조사 결과로 드러났다.

‍

개발자를 위한 권장 사항:

• 기술적 보호 조치에 관한 PPC 지침을 운영상의 기본 기준으로 삼아야 합니다. 즉, 일본 내 개인의 개인정보를 보유한 모든 시스템에 대해 정기적인 패치 적용, 취약점 모니터링 및 지원되는 소프트웨어를 사용해야 합니다.
• 일본 시장용 시스템을 별도의, 기준이 낮은 표준을 적용하여 관리하기보다는, EU/미국 규정 준수에 적용되는 것과 동일한 수명주기 현황 파악 및 시정 조치 SLA에 포함시켜야 합니다.
• 이제 통보가 의무화되었고 후속 질문도 예측 가능하므로, 침해 보고서를 뒷받침할 수 있는 형식으로 보안 조치 결정을 문서화하십시오.

‍

능동적 사이버 방어법 (일본, “ACD법” 또는 “ACDA”)

적용 대상: 일본의 ‘경제안보증진법’에 따라 지정된 특정 핵심 인프라 제공업체 및 이들에게 서비스를 공급하는 IT 공급업체. 의무 사항. 2025년 5월 16일 제정되었으며, 단계적 시행을 거쳐 2027년까지 전면 시행된다.

‍

요구 사항. ACDA는 민관 협력, 위협 탐지를 위한 통신 데이터 활용, 공격자 인프라에 대한 정부의 무력화 조치, 조직 개편이라는 네 가지 축을 중심으로 일본의 사이버 방어 체계를 재편합니다. 지정된 서비스 제공업체는 사이버 보안 사고를 관할 당국에 보고해야 하며, 이 의무는 2026년 10월 1일부터 발효됩니다(아직 공식적으로 확정되지 않음). 중요 시스템에 영향을 미치는 취약점의 경우, 정부는 IT 공급업체에 이를 통보할 수 있으며, 관할 장관은 시정 조치를 요청할 수 있다. 이러한 요청은 구속력이 없으나, 공급업체는 이에 대응하기 위해 합리적인 노력을 기울여야 한다. 또한 이 체계는 정부가 운영자에게 제로데이 취약점을 신속히 해결하도록 요청할 수 있도록 한다.

‍

EOL 소프트웨어가 문제를 일으키는 이유. ACDA는 규제 당국과 핵심 인프라 내부의 소프트웨어 사이에 직접적인 소통 채널을 구축하지만, EOL 소프트웨어는 양쪽 모두에서 문제를 일으킵니다. 사전 통지를 통해 규제 당국은 배포 전에 핵심 시스템의 구성을 파악할 수 있으므로, 지원이 중단된 프레임워크는 문서화된 취약점으로 해당 검토 과정에 포함됩니다. 시정 메커니즘은 수정이 가능하다는 전제를 바탕으로 합니다. 장관이 EOL 구성 요소의 CVE에 대한 시정 조치를 요청할 때, 상류 단계의 수정 사항이 존재하지 않으므로 “합리적인 노력”이란 결국 자체적으로 패치를 제작하거나 수정 사항이 제공되지 않을 것임을 인정하는 것으로 귀결됩니다. 또한 의무적인 사고 보고 제도를 통해 지원이 중단된 소프트웨어의 알려진 CVE를 통한 침해 사고가 정해진 기한 내에 당국에 보고되도록 보장합니다.

‍

예시. 특정 전력 사업자가 지원 종료 .NET EOL) .NET 기반으로 정전 신고 포털을 운영하고 있다. 국가사이버보안센터(NCO)가 해당 .NET CVE에 대한 활발한 악용 사례를 확인하자, 관할 부처 장관은 해당 사업자의 IT 공급업체에 시정 조치를 요청한다. 상류 패치는 존재하지 않습니다. 공급업체의 선택지는 긴급 마이그레이션이나 패치 소스를 복원해 주는 상용 확장 지원뿐입니다. “해당 구성 요소는 지원 종료 상태이므로 수정할 수 없음”이라는 사실이 향후 사고 보고에 앞서 이미 해당 부처에 공식 기록으로 남게 되었습니다.

‍

개발자를 위한 권장 사항:

• 귀사의 시스템이 지정된 일본 인프라 운영업체에 서비스를 제공하는 경우, 지금 당장 모든 프레임워크와 런타임을 파악하고, 2026년 11월에 통지 및 보고 의무가 본격적으로 적용되기 전에 지원 종료(EOL)된 구성 요소를 해결하십시오.
• 중요 시스템에 포함된 모든 구성 요소에 대해, 업스트림, 사내 개발, 상용 확장 지원 등 그 출처에 관계없이 패치 소스를 관리하여, 정부의 수정 요청에 신속하게 대응할 수 있도록 해야 합니다.
• ACDA와 APPI를 상호 보완적인 규제 체계로 간주해야 합니다. APPI는 개인정보 유출을, ACDA는 중요 서비스 중단을 규제하며, 일본 시장 내 시스템에서 발생하는 단일 사고만으로도 두 규제가 모두 발동될 수 있습니다.

‍

SOCI법 (호주, 2018년 중요 인프라 보안법)

적용 대상: 호주 내 11개 부문의 중요 인프라 자산 소유주 및 운영자. 의무 사항.

‍

요구 사항. SOCI 법 및 이에 따른 핵심 인프라 위험 관리 프로그램(CIRMP) 규정은 책임 기관이 중대한 위험(사이버 및 공급망 위험 포함)을 파악하고 이를 최소화하거나 완화하기 위한 통제 조치를 시행하며, 매년 이사회 승인을 받은 보고서를 제출할 것을 요구합니다. 많은 기관은 ACSC Essential Eight을 채택하여 사이버 프레임워크 의무를 이행하고 있는데, 이 프레임워크의 패치 성숙도 수준은 정의된 짧은 기간 내에 중요 패치를 적용할 것을 요구하며, 지원이 중단된 소프트웨어를 제거하거나 교체해야 할 취약점으로 명시적으로 규정하고 있습니다.

‍

EOL 소프트웨어가 왜 문제가 되는가. EOL 소프트웨어는 법안에서 명시적으로 언급되지는 않았지만, 위험 관리 의무를 통해 그 적용 범위에 분명히 포함된다. 즉, 중요 시스템 내의 지원이 중단된 구성 요소는 문서화된 통제 조치나 시정 조치가 필요한 중대한 사이버 위험이며, 이사회는 이를 해결하기 위한 프로그램에 대해 매년 확인서를 제출해야 한다.

‍

예시. 호주의 한 항만 운영사의 물류 애플리케이션이 지원 종료(EOL)된 Node.js 버전에서 실행되고 있다. 이사회가 서명한 CIRMP 연례 보고서에는 중대한 위험 요소와 이에 대한 완화 조치가 명시되어야 한다. 지원 종료된 런타임에 대해서는 신뢰할 수 있는 완화 조치(마이그레이션 일정, 격리 조치, 또는 패치 제공을 통한 지원 연장 등)가 제시되어야 하며, 그렇지 않을 경우 사고나 감사 과정에서 해당 문제가 드러날 때 이를 문제점으로 지적받게 된다.

‍

개발자를 위한 권장 사항:

• 패치 및 라이프사이클 관행을 ‘Essential Eight’ 성숙도 모델에 부합하도록 조정하십시오. 이 모델은 대부분의 호주 규제 기관과 이사회가 “합리적”을 나타내는 약어로 사용하고 있습니다.
• Surface EOL 문제를 CIRMP 위험 등록부에 등재하고 제안된 대응 방안을 포함시켜야 합니다. 이사회 승인을 통해 보고되지 않은 엔지니어링 위험이 거버넌스 문제로 전환되기 때문입니다.
• 정말로 업그레이드가 불가능한 운영 기술(OT) 관련 시스템의 경우, 세분화 및 모니터링 통제 조치를 위험 대응 방안으로 명시적으로 문서화해야 합니다.

‍

글로벌 표준

인터넷 보안 센터(CIS) 통제 기준 v8.1

적용 대상: 자발적으로 채택된 모범 사례 프레임워크로, 널리 활용되고 있으며 규제 당국과 보험사가 이를 참고하고, 일부 계약 상황에서는 의무적으로 적용됩니다.

‍

요구 사항. 통제 항목 2(소프트웨어 자산의 인벤토리 및 관리)는 조직이 승인되고 지원되는 소프트웨어만 설치 및 실행되도록 모든 소프트웨어를 적극적으로 관리할 것을 요구합니다. 통제 항목 2에 명시된 보호 조치에는 소프트웨어가 지원 대상인지 확인하고, 지원되지 않는 소프트웨어에 대한 조치를 취할 것을 명시적으로 요구하고 있습니다. 통제 항목 7(지속적인 취약점 관리)은 취약점을 지속적으로 평가 및 추적하고, 정해진 주기에 따라 시정 절차를 수립할 것을 요구합니다.

‍

EOL 소프트웨어가 문제를 일으키는 이유. CIS는 이 문제를 직접적으로 지적하는 몇 안 되는 프레임워크 중 하나입니다. 지원이 종료된 소프트웨어는 본질적으로 취약한 것으로 간주되며, 완화 조치를 포함한 예외 사항으로 문서화하거나 제거해야 합니다. CIS를 기준으로 삼는 조직(또는 고객이나 보험사가 CIS를 기준으로 삼는 조직)은 관리되지 않는 EOL 구성 요소가 있는 경우 내부 감사에서 불합격 판정을 받게 됩니다.

‍

예시. 중견 SaaS 기업이 기업 보안 설문지에 응답하기 위해 CIS Controls를 도입했습니다. Control 2를 통해 소프트웨어 목록을 확인한 결과, EOL(지원 종료) 프레임워크를 사용하는 애플리케이션 4개가 발견되었습니다. 각 애플리케이션은 보완 통제 조치와 지원 종료 일정을 명시한 문서화된 예외 항목으로 등록하거나, 지원 대상 상태로 전환해야 합니다. 이를 목록에 포함하지 않을 경우 해당 통제 항목을 충족하지 못하게 될 뿐만 아니라, 더 심각한 문제는 이를 바탕으로 작성된 설문지 답변의 정확성이 훼손된다는 점입니다.

‍

개발자를 위한 권장 사항:

• 패키지 매니페스트 및 배포 도구를 통해 Control 2 인벤토리를 자동화하고, 모든 프레임워크 및 런타임에 대해 “지원 종료일” 필드를 포함시키십시오.
• ‘통제 7’ 항목에서 심각도별로 시정 조치 SLA를 설정하고 이를 기준으로 성과를 측정하십시오. 이 통제 항목은 임시방편적인 대응이 아닌, 일정한 주기로 진행되는 프로세스를 요구합니다.
• 모든 EOL 구성 요소를, 해당 통제 조치가 의도하는 바와 정확히 일치하도록, 문서화, 완화 조치 및 만료일이 필요한 공식적인 예외 사항으로 취급해야 합니다.

‍

SOC 2 신뢰 서비스 기준

적용 대상: 자발적 인증이지만, 기업 고객들이 계약상 해당 보고서를 요구하기 때문에 B2B SaaS 및 클라우드 공급업체에게는 사실상 의무 사항입니다.

‍

요구 사항. 트러스트 서비스 기준(특히 CC7.1)은 새로운 취약점에 대한 모니터링, 정기적인 스캔, 적시적인 수정 조치, 그리고 제대로 작동하는 패치 및 변경 관리 프로세스를 요구합니다. 감사관은 감사 기간 동안 식별된 취약점이 해당 조직이 자체적으로 명시한 SLA 범위 내에서 수정되었는지, 그리고 해당 프로세스가 일관되게 운영되었는지 여부를 검증합니다.

‍

EOL 소프트웨어가 문제를 일으키는 이유. SOC 2 Type II 보고서는 수개월간의 기간을 다룹니다. CVE가 공개된 상태인 EOL 구성 요소는 해당 기간 동안 진행되는 모든 스캔에서 계속 발견되며, 이를 시정할 방법이 없어 보고서에 예외 사항으로 기재되거나 이에 대한 설명이 점점 더 억지스러워지게 됩니다. 기업 고객들은 이러한 예외 사항을 꼼꼼히 살펴봅니다. SaaS 공급업체 보고서에 취약점 관리 관련 예외 사항이 기재되는 것은 보안 문제일 뿐만 아니라 영업상의 문제이기도 합니다.

‍

예시. 한 SaaS 공급업체의 Type II 감사 기간은 1월부터 6월까지입니다. 2월에, 해당 공급업체의 빌드 파이프라인에 사용 중인 지원 종료(EOL) 오픈소스 툴과 내부 서비스의 Express (EOL) Express 대해 심각도가 높은 CVE가 공개되었습니다. 공급업체의 자체 정책에 따르면 심각도가 높은 취약점은 30일 이내에 시정되어야 합니다. 감사인은 7월에 해당 티켓을 표본 조사했습니다. 업스트림 또는 상용 패치가 제공되지 않아 120일째가 되어도 티켓은 미해결 상태로 남아 있었으며, 보고서는 예외 사항이 명시된 채로 제출되었습니다.

‍

개발자를 위한 권장 사항:

• 실제로 이행할 수 있는 시정 조치 SLA를 수립하고, 이를 반드시 준수하십시오. 감사관은 귀사의 자체 정책을 기준으로 검증하며, 기한을 지키지 못하는 과장된 정책은 소박하지만 꾸준히 지켜지는 정책보다 더 나쁩니다.
• 감사 기간이 시작되기 전에 감사 대상인 모든 구성 요소에 패치 소스가 마련되어 있는지 확인하십시오. 감사 기간 도중에 EOL(제품 수명 종료) 소프트웨어가 발견될 경우, 이는 수개월에 걸친 문서화된 실패 사례로 기록됩니다.
• 취약점 티켓은 감사 대상이므로, 해당 티켓을 정확하게 관리하고 모든 정보를 완벽하게 기재해야 합니다(발견 날짜, 심각도, 수정 조치, 종결 증빙 자료).

‍

ISO/IEC 27001:2022

적용 대상: 정보 보안 관리 시스템에 대한 자발적 국제 인증으로, 고객 계약 및 조달 요건을 통해 의무화되는 경우가 많습니다.

‍

요구 사항. 부록 A의 통제 항목 8.8(기술적 취약점 관리)은 기술적 취약점에 대한 정보를 적시에 확보하고, 노출 위험을 평가하며, 적절한 조치를 취할 것을 요구합니다. 통제 항목 8.9(구성 관리)는 하드웨어 및 소프트웨어에 대한 기준 템플릿을 포함하여 구성을 수립, 문서화, 구현 및 모니터링할 것을 요구합니다. 통제 항목 5.9는 정보 및 관련 자산에 대한 목록을 작성할 것을 요구합니다.

‍

EOL 소프트웨어가 이를 위반하는 이유. 8.8항에 따르면, EOL 구성 요소의 알려진 취약점에 대한 “적절한 조치”에는 제공되지 않을 패치를 기다리는 행위가 포함될 수 없으며, 조직은 업그레이드, 격리, 완화 또는 지원 복원을 수행해야 하며, 해당 의사결정 과정을 입증해야 합니다. 8.9항에 따르면, EOL 소프트웨어는 정의상 어떤 타당한 보안 기준선에서도 벗어난 것으로 간주됩니다. 수정 불가능한 CVE가 누적되는 구성 요소를 어떤 강화 템플릿으로도 보완할 수 없기 때문입니다. 인증 감사는 정기적으로 실시되므로(연간 감시 감사, 3년마다 재인증), 관리가 이루어지지 않는 EOL 구성 요소는 감사 때마다 부적합 사항으로 지적될 수밖에 없습니다.

‍

예시. 한 소프트웨어 컨설팅 회사는 정부 고객사가 요구하는 ISO 27001 인증을 보유하고 있다. 정기 감사 과정에서 감사관은 취약점 관리 기록을 표본 조사한 결과, 고객 포털에서 jQuery 종료(EOL) jQuery 대한 스캐너 탐지 결과가 반복적으로 발견되었으며, 이들 모두 완화 조치나 담당자 지정, 종료일 없이 “위험 수용”으로 처리된 것을 확인했다. 감사관은 8.8항에 대한 부적합 사항을 제기합니다. 평가, 조치 또는 기한이 정해진 검토 없이 위험을 수용하는 것은 “적절한 조치”가 아니기 때문입니다.

‍

개발자를 위한 권장 사항:

• 자산 인벤토리(5.9), 구성 기준선(8.9), 취약점 관리 프로세스(8.8)를 서로 연계하여 라이프사이클 상태가 이 세 가지 모두를 거치도록 해야 합니다. 감사관들은 통제 수단 간의 연계 지점을 점점 더 집중적으로 점검하고 있습니다.
• EOL 부품에 대한 위험 수용 결정은 기한을 정하고, 담당자를 지정하며, 실질적인 완화 조치와 연계하여 수립해야 하며, 정해진 주기에 따라 이를 재검토해야 합니다.
• SCA 및 EOL 스캔 결과를 ISMS의 시정 조치 프로세스에 직접 반영하여, “적시에” 식별하고 대응했다는 증거가 자동으로 축적되도록 한다.

‍

개발자들에게 이 모든 것이 의미하는 바: 통합 가이드북

20개의 프레임워크나 규정을 나란히 살펴보면 그 패턴이 뚜렷하게 드러납니다. 구체적인 기한은 서로 다르지만(PCI DSS 6.3.3 및 FedRAMP ‘고(High)’ 등급 판정 시 30일, 영국 Cyber Essentials 기준 14일, CRA 및 NIS2 보고 시 24/72시간), 근본적인 요구 사항은 동일하며, 이 모든 것이 기술적 요구 사항입니다:

‍

1. 자사가 출하하고 운영하는 제품을 정확히 파악하십시오. SBOM은 더 이상 선택 사항이 아닙니다. CRA는 EU 내 판매 제품에 대해 SBOM을 법적 요건으로 규정하고 있으며, PCI DSS 6.3.2는 구성 요소 목록을, DORA는 EOL(제품 수명 종료) 추적이 포함된 ICT 자산 목록을 요구합니다. 또한 CIS Control 2, ISO 27001 5.9, NIST CSF 역시 모두 SBOM의 존재를 전제로 합니다. CI 환경에서 릴리스별로 CycloneDX 또는 SPDX 형식의 SBOM을 생성하고, 언제든지 조회할 수 있도록 관리하십시오. 다음 Log4Shell급 사건이 발생하면, 이 목록에 포함된 모든 규제 기관은 귀사가 “영향을 받았는지, 어디에서, 언제부터인지”에 대한 답변을 몇 시간 내에 제공할 것을 기대할 것입니다.

‍

2. EOL 날짜를 준수 기한으로 간주하십시오. 오픈 소스 프로젝트의 공식 발표된 지원 종료일(EOL)은 그 날짜 이후부터 해당 프로젝트 내의 모든 새로운 CVE에 대해 일반적인 경로를 통해 영구적으로 수정할 수 없게 되는 날짜입니다. 모든 런타임, 프레임워크 및 주요 라이브러리(Node.js, Angular, AngularJS, Vue, React 툴링, Express, Nuxt, Bootstrap, jQuery, Drupal .NET, Spring 및 나머지 스택)에 대한 EOL 시한을 인증서 만료일만큼이나 심각하게 추적하십시오. 12개월 전에는 경고를 발령하고, 9개월 전에는 계획을 수립하며, EOL 당일이 되기 전에 조치를 취하십시오.

‍

3. 모든 구성 요소에 다음 세 가지 상태 중 정확히 하나를 부여하십시오. 업스트림에서 적극적으로 유지 관리되는 상태; 보안 패치를 제공하는 상용 확장 지원 계약을 통해 유지 관리되는 상태(이는 NIST CSF PR.PS-02에서 정의하는 “유지 관리됨” 요건을 충족하며, PCI의 30일 기한을 준수할 수 있게 하고, FedRAMP POA&M 일정을 준수할 수 있게 함); 또는 구체적인 일정이 확정된 교체/제거 예정 상태. 이 세 가지 상태 중 하나에 해당하지 않는 모든 항목은, 이 목록에 포함된 모든 감사관, 평가자 및 규제 당국이 발견하도록 훈련받은 취약점입니다.

‍

4. 문제 해결에 대한 SLA를 설정하고 이를 시스템에 반영하십시오. 심각도 기반의 마감일을 이슈 트래커에 연동하고, 문제 해결까지 걸리는 평균 시간을 측정하며, 해결 완료 증빙 자료를 보관하십시오. SOC 2, ISO 27001, CMMC, FedRAMP는 모두 근본적으로 증빙 자료 확보 과정입니다. 심사를 통과하는 조직은 일상적인 엔지니어링 워크플로우를 통해 감사 추적이 자연스럽게 생성되는 곳입니다.

‍

5. 사용자가 이미 해당 내용을 알고 있다고 가정하는 보고 시한에 대비하십시오. CRA의 24시간 사전 경고(2026년 9월 11일부터, 이미 시장에 출시된 제품 포함), NIS2의 24시간 사고 경고, 그리고 SEC의 4영업일 중요성 판단 기한은 모두 사고 발생 전에 시스템의 구성 요소 수준에 대한 지식이 이미 존재한다는 것을 전제로 합니다. 탐지, SBOM을 통한 구성 요소 식별, 영향 평가, 통지 초안 작성의 순서로 절차를 시뮬레이션해 보십시오.

‍

6. 수명 주기 관련 위험을 서면으로 상급 부서에 보고하십시오. NIS2는 경영진에게 개인적 책임을 부과하며, SEC 규정은 이사회가 감독 및 공시 의무를 지도록 하고, 호주의 CIRMP는 이사회의 확인을 요구합니다. 경영진은 파악할 수 있는 위험에 대해서만 관리할 수 있습니다. EOL(수명 종료) 노출 상황에 대한 솔직하고 최신의 현황과 대응 방안(마이그레이션, 격리, 지원 연장)을 담은 문서는 엔지니어링 팀이 작성할 수 있는 가장 영향력 있는 문서 중 하나입니다.

‍

이동 방향은 일방통행입니다. 2027년 12월 CRA의 전면 시행, 회원국 전반에 걸쳐 본격화되는 NIS2 적용, 국방부(DoD) 계약에 단계적으로 도입되는 CMMC, 왕실 승인을 거쳐 단계적으로 시행되는 캐나다의 CCSPA, 그리고 제안된 HIPAA 보안 규정 전면 개편 등은 모두 ‘자산 목록 관리’, ‘적시 시정 조치’, ‘문서화된 프로세스’라는 동일한 세 가지 요소를 강화합니다. 지금부터 파이프라인에 라이프사이클 인식을 반영하는 개발자들은 이러한 규제를 단순한 서류 작업으로 받아들일 수 있을 것입니다. 그렇지 않은 개발자들은 이를 긴급 상황으로 겪게 될 것입니다.

‍

HeroDevs의 Never-Ending Support (NES) ’이 EOL 규정 준수 격차를 어떻게 Never-Ending Support (NES)

NES는 AngularJS, Angular, Vue 2, Node.js, Spring, .NET, jQuery, Bootstrap, Express, Nuxt 등을 포함하여, 모든 규모의 조직에서 해결되지 않은 EOL(지원 종료) 취약점의 상당 부분을 차지하는 지원 종료된 오픈 소스 프레임워크, 런타임 및 라이브러리 포트폴리오를 포괄합니다. NES는 비공개 보안 레지스트리와 서명된 지원 계약서, 공개된 CVE 수정 로그, 릴리스 노트, SBOM 포함에 적합한 릴리스 버전 등 완벽한 규정 준수 아티팩트 세트를 통해 지속적인 CVE 수정 조치를 제공합니다.

앞서 설명한 의무 사항들과 대조해 볼 때, NES는 구조적으로 불가능한 것을 입증 가능한 보장 범위로 전환합니다:

• 수정 기한을 다시 충족할 수 있게 되었습니다. NES는 업스트림에서 더 이상 수정 사항을 제공하지 않을 구성 요소에 대한 상용 패치 소스를 복원하여, 해당 기한을 계속 충족할 수 있게 하고 발견된 문제를 종결할 수 있도록 합니다.
• “유지 관리됨”이 올바른 답변이 됩니다. NIST CSF 2.0 PR.PS-02에 따르면, 소프트웨어는 위험 수준에 상응하는 방식으로 유지 관리, 교체 또는 제거되어야 합니다. 공급업체가 지원하는 EOL 구성 요소에 대한 패치 적용은 ‘유지 관리됨’이라는 결과를 구성합니다. 
• 레거시 시스템은 관리 대상 시스템으로 전환됩니다. DORA와 NIS2는 레거시 소프트웨어 자체를 금지하는 것이 아니라, 관리가 이루어지지 않는 레거시 소프트웨어를 금지합니다. NES 계약 하에 있으며, 패치에 대한 SLA가 확약되고 시정 조치가 문서화된 EOL 구성 요소는 레거시 소프트웨어를 보안이 확보된 상태로 만들고 상용 지원 대상에 포함시킵니다. 
• 제품 수명 주기 전반에 걸친 지원 약속이 지속 가능해집니다. ‘사이버 복원력법(Cyber Resilience Act)’에 따라, 오픈 소스 구성 요소를 공급하는 제조사는 명시된 지원 기간 동안 해당 구성 요소의 취약점을 수정할 법적 책임을 집니다. NES는 업스트림 지원이 수년 전에 종료된 프레임워크를 기반으로 제작된 제품에 대해, 지원 약속의 신뢰성을 높여주는 백포트된 패치를 제공합니다.

마이그레이션이 올바른 해결책인 경우, NES는 마이그레이션을 대체할 수 있는 수단이 아닙니다. NES는 마이그레이션 일정을 투명하게 만드는 메커니즘입니다. 조직은 이사회, 감사인 및 규제 당국에 현실적인 현대화 일정을 서면으로 약속할 수 있으며, 그 과정에서 발생하는 모든 CVE는 제때에 시정되고 그 기록이 남게 됩니다.

‍

AI를 통해 발견되는 취약점의 빈도가 증가함에 따라, 지원 종료(EOL) 소프트웨어의 위험성도 기하급수적으로 높아지고 있습니다. NES를 도입함으로써 얻을 수 있는 운영상의 성과는, 생산 환경에서 지원 종료된 오픈소스 소프트웨어를 운영하는 기업이 감사관의 질문에 대한 답변을 ‘부적격 사항’으로 분류될 수 있는 공개 사항에서, 문서화되고 방어 가능한 통제 조치로 전환할 수 있다는 점입니다.

최신 기술 관련 소식, 릴리스 노트 및 CVE 대응 문서를 확인하시려면 herodevs.com 과 https://docs.herodevs.com/guide/getting-started을 방문해 주세요.

‍

‍

참고 문헌

1. PCI 보안 표준 위원회, 결제 카드 산업 데이터 보안 표준(PCI DSS) v4.0.1, 요구 사항 6.3.1, 6.3.2, 6.3.3 및 11.3.1, 2024년 6월. https://www.pcisecuritystandards.org/document_library/https://blog.basistheory.com/pci-dss-requirement-6
2. Risk Associates, “PCI DSS v4.0.1이 취약점 식별 및 수정 규칙을 어떻게 변화시키는가”, 2026년 4월. https://riskassociates.com/blogs/how-pci-dss-v4-0-1-shifts-the-rules-on-identifying-and-fixing-vulnerabilities/
3. Endor Labs (Schellman과 공동), “PCI DSS v4에 따른 OSS 취약점 대응에 대한 감사인의 관점”, 2026년 1월. https://www.endorlabs.com/learn/an-auditors-perspective-on-addressing-oss-vulnerabilities-for-pci-dss-v4
4. Angular , AngularJS에 대한 장기 지원 중단, Google, 2022년 1월. angularjs
5. 미국 연방규정집(U.S. Code of Federal Regulations), 45 CFR 제164편, C부 (HIPAA 보안 규정). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164
6. Medcurity, 2026년 HIPAA 보안 규정 업데이트: 대비해야 할 새로운 요구 사항 (위험 분석 및 패치되지 않은 소프트웨어에 관한 OCR 2026년 1월 사이버보안 뉴스레터 요약), 2026년 6월. https://medcurity.com/hipaa-security-rule-2026-update/
7. 미국 보건복지부(HHS) 민권국, 전자 보호 건강 정보(ePHI)의 사이버 보안을 강화하기 위한 HIPAA 보안 규정 제정안 공고. https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html
8. 연방관보, ‘전자 보호 건강 정보의 사이버 보안을 강화하기 위한 HIPAA 보안 규정’, 90 FR 898, 2025년 1월 6일. https://www.federalregister.gov/public-inspection/2024-30983/health-insurance-portability-and-accountability-act-security-rule-to-strengthen-the-cybersecurity-of
9. 클리어워터 시큐리티, HIPAA 보안 규정 시행: 2026년 현황, 2026년 7월. https://clearwatersecurity.com/blog/hipaa-security-rule-enforcement-2026/
10. 미국 국립표준기술연구소(NIST), NIST SP 800-53 Rev. 5: 정보 시스템 및 조직을 위한 보안 및 개인정보 보호 통제, 통제 항목 SI-2 (결함 수정). https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf
11. FedRAMP 지속적 모니터링 가이드북. https://www.fedramp.gov/resources/documents/Continuous_Monitoring_Playbook.pdf
12. 미국 국립표준기술연구소(NIST), 《NIST 사이버보안 프레임워크(CSF) 2.0》, NIST CSWP 29, 하위 범주 PR.PS-02, 2024년 2월. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
13. 미국 행정관리예산국(OMB), 행정부 각 부처 및 기관장에게 보내는 각서, M-26-05, 2026년 1월 23일. https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf
14. 미국 국립표준기술연구소(NIST), NIST SP 800-218: 보안 소프트웨어 개발 프레임워크(SSDF) 버전 1.1, 실천 지침 PW.4 및 RV.1–RV.3. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf
15. 사이버보안 및 인프라 보안국(CISA), 안전한 소프트웨어 개발 확인서. https://www.cisa.gov/secure-software-attestation-form
16. 연방관보, 행정명령 제14028호: 국가 사이버 보안 강화, 2021년 5월 12일. https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
17. 미국 국립표준기술연구소(NIST), NIST SP 800-171 Rev. 3: 비연방 시스템 및 조직 내 통제 대상 비기밀 정보 보호, 요구사항 3.14.1. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r3.pdf
18. 미국 증권거래위원회(SEC), ‘사이버보안 위험 관리, 전략, 거버넌스 및 사고 공시’, 공고 번호 33-11216; 34-97989, 2023년 7월. https://www.sec.gov/files/rules/final/2023/33-11216.pdf
19. 캐나다 의회, 법안 C-8: 사이버 보안에 관한 법률, ‘통신법’을 개정하고 기타 법률에 대한 부수적 개정을 규정하는 법률, 2026년 캐나다 법률집, 제9장, LEGISinfo. https://www.parl.ca/legisinfo/en/bill/45-1/c-8
20. 캐나다 정부 산하 캐나다 공공안전부, 2026년 6월 C-8 법안의 왕실 승인으로 사이버 보안 및 핵심 인프라 강화. https://www.canada.ca/en/public-safety-canada/news/2026/06/government-of-canada-strengthens-cyber-security-and-critical-infrastructure-with-royal-assent-of-bill-c8.html
21. Borden Ladner Gervais LLP, C-8 법안 통과: 중요 사이버 시스템 보호법, 2026년 6월. https://www.blg.com/en/insights/2025/07/bill-c-8-revives-canadian-cyber-security-reform-what-critical-infrastructure-sectors-need-to-know
22. 유럽연합, 금융 부문의 디지털 운영 복원력에 관한 규정(EU) 2022/2554(DORA), 제5조~제15조, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2022/2554/oj
23. 유럽연합, 규정 (EU) 2016/679(일반 데이터 보호 규정), 제32조, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2016/679/oj
24. 유럽연합, 지침 (EU) 2022/2555 (NIS2 지침), 제21조 및 제23조, EUR-Lex. https://eur-lex.europa.eu/eli/dir/2022/2555/oj
25. NIS-2-Directive.com, NIS 2 지침, 제21조: 사이버 보안 위험 관리 조치 (조문 전문). https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html
26. Glocert International, NIS2 제21조 위험 관리 조치 해설: 10가지 통제 조치 모두, 2025년 12월. https://www.glocertinternational.com/resources/guides/nis2-article-21-risk-management-measures-explained/
27. 유럽연합, 규정 (EU) 2024/2847(사이버 복원력법), 제14조 및 부속서 I, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/2847/oj
28. 유럽연합 집행위원회, 《사이버 복원력 법: 입법안 요약》, ‘유럽의 디지털 미래 조성’. https://digital-strategy.ec.europa.eu/en/policies/cra-summary
29. CyberResilienceAct.eu, ‘사이버 복원력법’ 해설: 적용 범위, 분류 및 기한, 2026년 6월. https://www.cyberresilienceact.eu/explained.html
30. 키사이트 테크놀로지스, EU CRA 규정 준수까지 1년 남았다: 2026년 9월 11일, 모든 것이 바뀐다, 2025년 9월. https://www.keysight.com/blogs/en/tech/nwvs/2025/09/11/one-year-countdown-to-eu-cra-compliance-september-11-2026-changes-everything
31. Mend (Security Boulevard를 통해), 《EU 사이버 복원력법: 2026년 및 그 이후를 위한 종합 준수 가이드》, 2026년 5월. https://securityboulevard.com/2026/05/the-eu-cyber-resilience-act-a-complete-compliance-guide-for-2026-and-beyond/
32. 정보위원회(Information Commissioner's Office), 사건 참조 번호 INV/0158/2020. https://ico.org.uk/media2/1kip5gw2/chartered-institiute-for-securities-and-investment-reprimand.pdf
33. 정보위원회(ICO), 《데이터 보안 가이드》(영국 GDPR 보안 이행 지침). https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/
34. 영국 정부, 「2018년 네트워크 및 정보 시스템 규정」(SI 2018/506). https://www.legislation.gov.uk/uksi/2018/506/contents
35. 영국 국가사이버보안센터(NCSC), 사이버 평가 프레임워크(CAF). https://www.ncsc.gov.uk/collection/cyber-assessment-framework
36. 영국 국가사이버보안센터(NCSC), ‘사이버 에센셜(Cyber Essentials): IT 인프라 요구사항’(14일마다 업데이트해야 함). https://www.ncsc.gov.uk/cyberessentials/overview
37. 일본 개인정보보호위원회, 개인정보보호법(APPI) 및 개인정보보호위원회 지침(영어 자료). https://www.ppc.go.jp/en/legal/
38. 일본 - 2026년 사이버 보안 법규. https://iclg.com/practice-areas/cybersecurity-laws-and-regulations/japan
39. 일본의 새로운 능동적 사이버 방어법: 기업에 미치는 영향. https://connectontech.bakermckenzie.com/japans-new-active-cyber-defense-law-impact-on-businesses/
40. 호주 정부, 2018년 중요 인프라 보안법 (중요 인프라 위험 관리 프로그램 규정 포함). https://www.legislation.gov.au/C2018A00029/latest
41. 호주 사이버 보안 센터(Australian Cyber Security Centre), ‘에센셜 에이트(Essential Eight)’ 성숙도 모델 (애플리케이션 및 운영 체제 패치 적용; 지원이 중단된 소프트웨어 제거). https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight
42. 인터넷 보안 센터(CIS), CIS 핵심 보안 통제 사항 v8.1, 통제 사항 2(소프트웨어 자산의 현황 파악 및 관리) 및 통제 사항 7(지속적인 취약점 관리). https://www.cisecurity.org/controls
43. AICPA, 신탁 서비스 기준(2017년, 2022년 개정 중점 사항 포함), 기준 CC7.1. https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
44. 국제표준화기구(ISO), ISO/IEC 27001:2022 정보보안 경영시스템, 부록 A 통제 항목 5.9, 8.8, 8.9. https://www.iso.org/standard/27001
45. CyberResilienceAct.eu, ‘사이버 복원력법’ 해설: 적용 범위, 분류 및 기한, 2026년 6월. https://www.cyberresilienceact.eu/explained.html
46. endoflife.date, 프레임워크, 런타임 및 데이터베이스의 지원 종료일 (커뮤니티에서 관리하는 참고 자료). https://endoflife.date/
47. Node.js 프로젝트 (OpenJS 재단), 이전 릴리스 및 지원 종료 일정. https://nodejs.org/en/about/previous-releases
48. Vue.js 팀, Vue 2 지원 Vue 2 (2023년 12월 31일). https://v2.vuejs.org/eol/