> For the complete documentation index, see [llms.txt](https://docs.medcrypt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.medcrypt.com/ko/helm/get-started-with-helm/dont-have-an-sbom/why-sboms-are-critical-to-your-present-and-future.md).
# 현재와 미래에 SBOM이 중요한 이유
제품의 현재 상태를 나타내는 SBOM을 보유하면 모든 “구성 요소 목록”을 확인할 수 있어 소프트웨어 보안 공급망 전반의 가시성과 투명성을 확보하고, 소프트웨어를 정기적으로 업데이트하고 패치할 수 있습니다. 그러면 평가하고 완화해야 할 잠재적 악용 가능 취약점을 신속하게 식별할 수 있습니다.
## SBOM이란 무엇인가요?
SBOM은 소프트웨어 공급망 보안을 운영하는 데 필수적인 요소이며, 소프트웨어 공급망 사이버 보안 프로그램의 핵심 구성 요소입니다. SBOM은 애플리케이션을 구성하는 소프트웨어의 구성 요소 목록과 같습니다. 이러한 개별 소프트웨어를 “구성 요소” 또는 “종속성”이라고 부를 수 있습니다. Helm을 사용하면 회사 정책에 따라 자사, 감사 담당자, 심지어 고객에게도 소프트웨어 공급망 정보를 투명하게 공개할 수 있습니다. 이를 통해 이해관계자는 독점, 오픈 소스, 라이선스가 적용된 상용 기성품(COTS) 라이브러리의 종속성처럼 그렇지 않으면 보이지 않는 항목도 파악할 수 있습니다.
SBOM에 포함되는 일반적인 요소는 다음과 같습니다.
* 오픈 소스 라이브러리
* 플러그인, 확장 기능 및 추가 기능
* 사내에서 개발한 맞춤형 소스 코드
* 구성 요소의 버전, 라이선스 상태 및 패치 상태 정보
* SaaS: SaaS 애플리케이션을 실행하는 데 필요한 타사 서비스 및 API 정보
## 현재와 미래를 보호하는 데 필수적인 SBOM
SBOM은 회사와 고객, 그리고 고객의 환자를 위해 더 나은 보안을 갖춘 미래를 실현하는 데 필수적입니다. 소프트웨어 종속성을 가시화하여 해당 소프트웨어의 취약점을 관리하고, 위험도가 가장 높고 가장 중요한 취약점부터 우선적으로 대응할 수 있도록 하는 최신 단계입니다. FDA에 따르면 더 이상 “보안 정보를 감추는 방식의 보안”에 의존하는 것만으로는 충분하지 않습니다. 의료기기 제조업체는 책임을 지고 다음에 대한 책임을 인식해야 합니다. [시판 전](#pre-market-dependency-and-vulnerability-tracking) 및 [시판 후](#post-market-dependency-and-vulnerability-tracking) 기기와 시스템에 사용되는 안전하지 않은 소프트웨어에 대한 책임은 고객과 환자에게도 이어집니다.
{% hint style="info" %}
Gartner에 따르면 2026년까지 업무 핵심 소프트웨어 솔루션을 보유한 기업의 최소 60%가 라이선스 및 지원 계약에 SBOM 공개를 의무화할 것입니다.
{% endhint %}
### 최근의 사이버 보안 공격과 변화하는 경제 상황
지난 몇 년 동안 소프트웨어 공급망을 겨냥한 여러 차례의 대규모 공격이 발생했습니다. 오늘날의 연결형 기기는 자체 개발, 타사 및 오픈 소스 프로젝트를 비롯한 많은 소프트웨어 라이브러리에 의존합니다. 팬데믹으로 인해 사업에 중요한 공급망에서 여러 차례 공급 부족이 발생했고, 이에 따라 기기 및 제품 제조업체는 신뢰할 수 있는 공급업체 네트워크를 벗어나야 했으며, 소프트웨어 공급망에 또 다른 위험 요소가 추가되었습니다. 최근 발생한 영향력 큰 공격 사례를 몇 가지 소개합니다. 이 밖에도 많은 사례가 있습니다.
#### **SolarWinds**
2020년 SolarWinds 공급망 공격은 미국 정부 인프라와 미국, 유럽, 아시아, 중동 전역의 여러 기업에 심각하고 지속적인 영향을 미쳤습니다. 해커들은 수개월에 걸쳐 SolarWinds를 공격해 IT 네트워크에 침입했습니다. SolarWinds는 공격 대상 기업에 네트워크 모니터링 및 관리 플랫폼을 공급했습니다. 이 사건은 의료기기 제조업체가 기기에 사용되는 소프트웨어에 대해 얼마나 알고 있는지를 엄중하게 되돌아보게 했습니다.
#### **Log4Shell (Log4j)**
2021년, 널리 사용되는 Apache Log4j 오픈 소스 Java 로깅 라이브러리에서 심각한 원격 코드 실행 취약점이 발견되었습니다. 광범위한 사용 범위에 더해 초보 해커도 쉽게 악용할 수 있어 특히 위험하며, 사용자 인터페이스가 있는 Java 애플리케이션은 모두 Log4Shell 공격의 위험에 노출됩니다. 이 사건은 기기에서 오픈 소스 구성 요소를 사용할 때 내재하는 위험을 명확히 드러냈습니다. Log4j 라이브러리를 사용하는 시스템과 서비스에는 Twitter, Tesla, Apple, Minecraft 등이 있습니다.
#### WannaCry
2017년, [WannaCry](https://en.wikipedia.org/wiki/WannaCry_ransomware_attack) (WannaCrypt라고도 함) 랜섬웨어 공격은 EternalBlue 익스플로잇을 사용해 Microsoft Windows 운영 체제를 실행하는 컴퓨터를 표적으로 삼았습니다. 공격자는 데이터를 암호화하고 DoublePulsar 도구를 사용해 복제본을 설치 및 실행한 다음, 데이터를 복호화하는 대가로 암호화폐를 요구했습니다. Microsoft는 익스플로잇을 차단하는 패치를 배포했지만, 많은 조직이 패치를 적용하지 않았거나 지원 종료된 구형 Windows 운영 체제를 사용하고 있었습니다. Europol에 따르면 WannaCry는 150개국에서 20만 대가 넘는 컴퓨터를 감염시켜 영국 국민보건서비스(NHS)와 수많은 기업에 피해를 입혔습니다.
***우리 회사도 Log4j 또는 WannaCry의 영향을 받았나요?***
SBOM을 [생성하고](https://docs.google.com/document/d/1tw34xkKUOJd0Xlo1p67h5Obio5t6dZHRKqM2SWWBruk/edit#heading=h.beg6wplcxva) Helm에 [업로드한](https://docs.google.com/document/d/1tw34xkKUOJd0Xlo1p67h5Obio5t6dZHRKqM2SWWBruk/edit#heading=h.sc55nidpf6zz) 후 쉽게 확인할 수 있습니다!
Log4j의 경우, 전역 검색에서 “log4j”를 [검색하면](/ko/helm/manage-vulnerabilities/check-whether-a-particular-vulnerability-impacts-your-products.md) 영향을 받았을 가능성이 있는 모든 구성 요소를 확인할 수 있습니다. 또는 취약점 ID CVE-2021-44228을 검색할 수 있습니다. 영향을 받았다고 생각되면 자세한 내용은 CISA의 [Log4j 취약점 지침](https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance) 을 참조하세요.
WannaCry의 경우, 구형 Windows 운영 체제(예: Windows XP 이상)를 검색해 패치가 적용되었는지 확인할 수 있습니다. 관련 취약점 ID인 CVE-2017-0143, CVE-2017-0144, CVE-2017-0145, CVE-2017-0146, CVE-2017-0147 및 CVE-2017-0148도 검색할 수 있습니다. 영향을 받았을 가능성이 있다고 생각되면 자세한 내용은 CISA의 [WannaCry 팩트 시트](https://www.cisa.gov/sites/default/files/FactSheets/NCCIC%20ICS_FactSheet_WannaCry_Ransomware_S508C.pdf) 를 참조하세요.
### 정부 요구사항 충족
Gartner에 따르면 2026년까지 업무 핵심 소프트웨어 솔루션을 보유한 기업의 최소 60%가 라이선스 및 지원 계약에 SBOM 공개를 의무화할 것입니다.
제품의 현재 상태를 나타내는 SBOM을 보유하면 모든 “구성 요소 목록”을 확인할 수 있어 소프트웨어 보안 공급망 전반의 가시성과 투명성을 확보하고, 소프트웨어를 정기적으로 업데이트하고 패치할 수 있습니다. 그러면 평가하고 완화해야 할 잠재적 악용 가능 취약점을 신속하게 식별할 수 있습니다.
### 회사의 현재와 미래를 보호하세요
SBOM은 회사와 고객, 그리고 고객의 환자를 위해 더 나은 보안을 갖춘 미래를 실현하는 데 필수적입니다. 소프트웨어 종속성을 가시화하여 해당 소프트웨어의 취약점을 관리하고, 위험도가 가장 높고 가장 중요한 취약점부터 우선적으로 대응할 수 있도록 하는 최신 단계입니다. FDA에 따르면 더 이상 “보안 정보를 감추는 방식의 보안”에 의존하는 것만으로는 충분하지 않습니다. 의료기기 제조업체는 책임을 지고 다음에 대한 책임을 인식해야 합니다. [시판 전](https://docs.google.com/document/d/1tw34xkKUOJd0Xlo1p67h5Obio5t6dZHRKqM2SWWBruk/edit#heading=h.xh1la7td7wpl) 및 [시판 후](https://docs.google.com/document/d/1tw34xkKUOJd0Xlo1p67h5Obio5t6dZHRKqM2SWWBruk/edit#heading=h.pyfniwwcs9nl) 기기와 시스템에 사용되는 안전하지 않은 소프트웨어에 대한 책임은 고객과 환자에게도 이어집니다.
미국 정부는 2021년 사이버 보안 강화를 위한 [행정명령 14028](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/) 을 발표했습니다. 이후 연방 기관은 NIST의 보안 소프트웨어 개발 관행에 부합하도록 SBOM 사용을 포함한 NIST 지침을 채택해야 했습니다.
### 병원 요구사항 충족
의료기기의 소비자인 병원은 비즈니스 제휴 계약(예: [Mayo Clinic](https://www.mayoclinic.org/about-mayo-clinic/supplier-information/resources))의 일부로 상세한 SBOM을 점점 더 많이 요청하고 있습니다. 여기에는 기기 또는 애플리케이션 이름, NIST CPE 사전을 기준으로 한 공급업체 및 제품 이름과 버전, 소프트웨어 업데이트 제공 및 적용 책임자, 소프트웨어 업데이트 주기, 보안 패치 적용 주기(특히 알려진 취약점이 있는 경우), 기기 작동에 해당 소프트웨어가 필수적인지 여부, 업데이트 발생 시 MDM이 Mayo Clinic에 알리는 방식, 기기 또는 애플리케이션의 예상 지원 종료일 등이 포함됩니다. 의료 서비스의 최고 품질을 유지하면서 운영 비용을 절감해야 하는 필요성 때문에 Mayo Clinic과 같은 의료 시스템은 [앞으로도 계속 거부할 것입니다.](https://www.mayoclinic.org/documents/supplier-briefings-pdf/doc-20079748) 공급업체 가격 인상, 전가 세금(예: 의료기기세) 또는 기타 가치 손실이 발생할 수 있습니다. 이들은 MDM이 프로세스를 지속적으로 간소화하고 효율성을 높일 것을 요청했습니다.
## SBOM은 어떤 용도로 사용할 수 있나요?
SBOM을 활용하면 위험을 선제적으로 파악하고 예방하거나 줄일 수 있으며, 사고가 발생했을 때 대응할 수도 있습니다.
제품의 현재 상태를 나타내는 SBOM을 보유하면 모든 ‘구성 요소 목록’을 카탈로그화하여 소프트웨어 보안 공급망 전반의 가시성과 투명성을 확보할 수 있습니다. 또한 평가하고 완화해야 할 잠재적 악용 가능 취약점을 식별할 수 있습니다.
### **Mayo Clinic 요구사항 충족**
다음 기관과 거래하는 경우 [Mayo Clinic](https://www.mayoclinic.org/about-mayo-clinic/supplier-information/resources), Business Associate Agreement의 일부로 상세한 SBOM을 요청하는 경우가 많습니다. 여기에는 기기 또는 애플리케이션 이름, NIST CPE 사전을 기준으로 한 공급업체 및 제품 이름과 버전, 소프트웨어 업데이트 제공 및 적용 책임자, 소프트웨어 업데이트 주기, 보안 패치 적용 주기(특히 알려진 취약점이 있는 경우), 기기의 기능에 해당 소프트웨어가 필수적인지 여부, 업데이트가 있을 때 MDM이 Mayo Clinic에 통지하는 방법, 기기 또는 애플리케이션의 예상 수명 종료일 등이 포함됩니다. 최고 수준의 의료 품질을 유지하면서 운영 비용을 줄여야 하는 Mayo Clinic은 [계속해서 거부할 것입니다](https://www.mayoclinic.org/documents/supplier-briefings-pdf/doc-20079748) 공급업체 가격 인상, 전가 세금(예: 의료기기세) 또는 기타 가치 손실을 이유로 한 요청을 말합니다. 이들은 MDM이 프로세스를 지속적으로 간소화하고 효율성을 높일 것을 요청했습니다.
### 시판 전 구성 요소 및 취약점 추적
FDA 지침에 따라 [의료기기의 사이버 보안 관리를 위한 시판 전 제출 자료의 내용](http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf), 제조업체는 의료기기의 설계 및 개발 과정에서 사이버 보안을 다루어야 합니다. 이를 통해 환자와 작업자의 위험을 더욱 견고하고 효율적으로 완화할 수 있는 경우가 많습니다. 또한 의료기기 제조업체는 기기의 사이버 보안 관련 설계 입력을 수립하고, 다음에서 요구하는 소프트웨어 검증 및 위험 분석의 일부로 사이버 보안 취약점 관리 접근법을 마련해야 합니다. [21 CFR 820.30(g)](https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?fr=820.30). 이 접근법은 다음 사항을 다루어야 합니다.
* 자산, 위협 및 취약점 식별
* 위협 및 취약점이 기기 기능과 작업자/환자에게 미치는 영향 평가
* 위협이 발생할 가능성과 취약점이 악용될 가능성 평가
* 위험 수준 및 적절한 완화 전략 결정
* 잔여 위험 및 위험 수용 기준 평가
다른 기기, 인터넷, 다른 네트워크 또는 휴대용 미디어(예: USB 또는 CD)에 유선 또는 무선으로 연결할 수 있는 의료기기는 연결되지 않은 기기보다 사이버 보안 위협에 더 취약합니다. 필요한 보안 통제의 범위는 기기의 사용 목적, 전자 데이터 인터페이스의 존재 여부와 용도, 사용 환경, 존재하는 사이버 보안 취약점의 유형, 취약점이 악용될 가능성, 사이버 보안 침해로 환자에게 피해가 발생할 개연성에 따라 달라집니다. 기기가 사이버 기기로 간주되는지 확인하려면 다음을 참조하세요. [FDA는 무엇을 사이버 기기로 분류하나요?](https://docs.google.com/document/d/1tw34xkKUOJd0Xlo1p67h5Obio5t6dZHRKqM2SWWBruk/edit#heading=h.iuaf0u3xzfna) 섹션.
### 시판 후 구성 요소 및 취약점 추적
FDA 지침에 따르면 [의료기기 사이버 보안의 시판 후 관리](https://www.fda.gov/files/medical%20devices/published/Postmarket-Management-of-Cybersecurity-in-Medical-Devices---Guidance-for-Industry-and-Food-and-Drug-Administration-Staff.pdf), 의료기기에 대한 사이버 보안 위험은 끊임없이 변화하므로 제조업체는 시판 전 통제만으로 위험을 완전히 완화할 수 없습니다. 따라서 제조업체는 불만 처리, 품질 감사, 시정 및 예방 조치, 소프트웨어 검증 및 위험 분석, 서비스 활동을 포함하여 품질 시스템 규정([21 CFR part 820](https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=820))에 부합하는 포괄적인 사이버 보안 관리 프로그램과 문서화를 구현하는 것이 중요합니다.
사이버 보안 위험 관리 프로그램은 의료기기에 저장되거나 의료기기에서 접근 또는 전송되는 정보에 대한 무단 접근, 변경, 오용 또는 사용 거부, 무단 사용을 허용하여 환자에게 피해를 초래할 가능성이 있는 취약점을 다루어야 합니다. 이 프로그램에는 다음이 포함되어야 합니다.
* 사이버 보안 취약점과 위험을 식별하고 탐지하기 위해 사이버 보안 정보 출처를 모니터링합니다.
* 다음을 포함한 견고한 소프트웨어 수명주기 프로세스를 유지합니다.
* 기기의 수명주기 전반에 걸쳐 새로운 취약점이 있는지 타사 소프트웨어 구성 요소를 모니터링합니다.
* 기성 소프트웨어를 포함하여 취약점 해결에 사용되는 소프트웨어 업데이트 및 패치의 설계를 검증하고 유효성을 확인합니다.
* 취약점의 존재와 영향을 파악하고 평가하며 탐지합니다.
* 취약점 접수 및 처리 프로세스를 수립하고 이를 전달합니다.
* 위험 완화 조치를 마련하는 위협 모델링을 통해 사이버 보안 위험으로부터 기기를 보호하고, 이에 대응하며 복구할 수 있도록 하여 기기의 안전성과 필수 성능을 유지하는 방법을 명확히 정의합니다.
* 취약점 조정 공개 정책 및 관행을 채택합니다.
* 사이버 보안 위험을 조기에, 악용되기 전에 해결하는 완화 조치를 배포합니다.
### 취약점 및 위협 정보를 공유하기 위해 ISAO에 참여합니다.
FDA 지침에 따르면 [의료기기 사이버 보안의 시판 후 관리](https://www.fda.gov/files/medical%20devices/published/Postmarket-Management-of-Cybersecurity-in-Medical-Devices---Guidance-for-Industry-and-Food-and-Drug-Administration-Staff.pdf), 의료기기에 영향을 미치는 취약점과 위협을 공유하는 ISAO에 의료기기 제조업체가 참여할 것을 적극 권장합니다. 여러 부문에 걸쳐 취약점 및 위협에 관한 사이버 보안 정보와 인텔리전스를 공유하고 전파하는 것은 성공적인 시판 후 사이버 보안 감시 프로그램의 핵심입니다.
혹시 모르셨다면 Medcrypt는 ISAO인 [MedISAO](https://www.medisao.com/) 를 운영하고 있습니다. 정보를 함께 공유할 여러분의 참여를 환영합니다!
### 위협 모델링
사이버 보안 프로그램의 일환으로, [FDA 시판 후 지침](https://www.fda.gov/files/medical%20devices/published/Postmarket-Management-of-Cybersecurity-in-Medical-Devices---Guidance-for-Industry-and-Food-and-Drug-Administration-Staff.pdf) 제조업체는 기기의 안전성과 필수 성능, 기기가 침해될 경우 환자에게 발생할 수 있는 피해의 가능성과 심각도, 그리고 위험 허용 기준을 정의해야 합니다. 이를 통해 취약점을 신속하게 분류하여 수정 및 완화 조치를 취할 수 있습니다. 위협 모델링은 취약점의 악용 가능성을 이해하고 평가하는 데 중요하며, 취약점 수정으로 환자 피해 위험을 합리적으로 통제할 수 있도록 하는 데에도 필수적입니다. 허용 가능한 완화 조치는 환자에게 발생할 수 있는 피해의 심각도에 따라 달라집니다.
### 데이터 침해 대응
완전한 SBOM을 보유하는 것은 데이터 침해가 발생했을 때 매우 중요합니다. 이를 통해 영향을 받은 소프트웨어를 신속하게 탐지하고 분석할 수 있으며, 데이터 침해의 영향과 영향을 받을 수 있는 다른 구성 요소를 파악하여 회사와 고객, 환자에 미치는 영향을 빠르게 제한할 수 있습니다. 또한 사이버보안 계획에서 해결해야 할 중요 영역과 우선순위를 정하는 데도 도움이 됩니다.
### **탐지 및 분석**
SBOM은 탐지 및 분석 단계에서 매우 유용합니다. 소프트웨어에 포함된 항목을 파악할 수 있도록 가시성을 제공하고, 분석에 필요한 맥락과 세부 정보를 제공합니다. 이를 통해 바이너리 파일에서 정보를 수집하느라 낭비되는 시간을 크게 줄일 수 있으며, 이는 특히 데이터 침해가 발생했을 때 중요합니다.
### **대응 및 복구**
소프트웨어 공급망 전체에 투명성을 제공하는 절차를 앞당기면, 공급업체와 제3자로부터 필요한 정보를 확보하여 해당 요소가 특정 기기 환경에 미치는 영향을 파악할 수 있습니다. 또한 공격이 발생하기 전에 필요한 패치를 선제적으로 식별하고 고객에게 알릴 수 있습니다.
SBOM이 완전하고 정확하면 사고 대응팀은 애플리케이션이나 API의 작동 방식을 더 쉽게 파악하여 공격을 맥락에 맞게 이해할 수 있습니다. 또한 저장소와 프로젝트 참여자를 추적하는 데 도움을 주어 대응 시간을 단축할 수 있습니다. SBOM에 데이터베이스, 큐, API, 디렉터리로의 백엔드 연결과 같은 서비스 정보가 포함되어 있다면, 침해가 진행되는 동안 그 영향을 계산하는 데 활용할 수 있습니다. 아직 조사를 시작하지 않은 영역에서도 영향을 받은 구성 요소나 종속성을 찾아 특정 공격이 제거되었는지 더 신속하게 확인할 수 있습니다.
### **사고 후 대응**
취약점 악용에 대응한 후에는 사후 분석에서 SBOM을 활용하여 해결해야 할 중요 영역과 단기 및 장기적으로 우선순위를 정해야 할 사항을 파악할 수 있습니다.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.medcrypt.com/ko/helm/get-started-with-helm/dont-have-an-sbom/why-sboms-are-critical-to-your-present-and-future.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.