최근 공급망 공격의 부상과 그 배경
최근 몇 년간 사이버 공격의 양상은 직접적인 시스템 공격에서 벗어나, 소프트웨어 공급망을 노리는 공급망 공격으로 진화하고 있다. 이러한 공급망 공격 은 신뢰할 수 있는 소프트웨어나 업데이트 또는 패키지 배포 과정에 악성 코드를 삽입하여 다수의 사용자나 기업에 피해를 주는 방식이다.
공급망 이란?
- 판매 제품의 생산, 유통, 유지에 요구되는 모든 부품과 서비스를 공급하는 개별 기업들의 집합을 의미한다.
- 사용되는 하드웨어 및 소프트웨어는 제조·유통의 과정을 거쳐 기업에 공급된다.
- 공급 과정 데이터 위변조 및 각 종 보안 위협에 노출될 수 있어 공급망 보안의 필요성이 지속적으로 제기되고 있다.
소프트웨어 공급망의 구성 요소에 해당하는 위험은 해당 구성 요소를 사용하는 모든 소프트웨어에 잠재적 위험이 있을 수 있음을 나타낸다.
이는 해커가 멀웨어나 백도어 또는 악성코드를 삽입하여 구성 요소와 연결된 공급망을 손상시킬 가능성을 야기한다.
이러한 공급망 보안 위협에 대응하도록
- 소프트웨어 위변조 방지 기술
- 소프트웨어자료명세서(SBOM) : 소프트웨어 공급망의 신뢰성과 투명성을 높일 수 있는 취약점 관리 기술이 등장 했다.
SBOM 이란?
제조업에 사용되는 자재명세서(Bill Of Materials, BOM)의 개념을 소프트웨어 분야에 적용한 것으로 소프트웨어의
구성요소를 메타데이터로 나타낸 것이다.
- 소프트웨어 애플리케이션을 구성하는 모든 구성 요소, 라이브러리 및 종속성에 대한 자세한 목록
- 이름, 버전, 라이센스 유형, 설치된 소스 등 구성 요소
SCA
소프트웨어 구성 분석(SCA) 으로 애플리케이션 내의 종속성을 자동으로 식별하는 것을 말한다.
보안 문제, 오래되었거나 더 이상 사용되지 않는 라이브러리/구성 요소의 사용, 오픈 소스 라이센스 준수 필요성을 위해서
SCA를 수행하면 조직에서 써드파티 코드 사용에 대한 가시성을 유지하고 해당 코드에서 취약성 또는 잠재적 백도어를 모니터 하는 것을 말한다.
- 오픈소스 구성 요소를 식별해서 취약점 탐지하는 검사 및 분석
- 오픈소스나 바이너리를 분석해 하위 구성 요소를 감지, 식별하는 DevSecOps 도구 또는 그 과정을 의미.
- SCA는 취약점, 잠재적인 라이선스 충돌, 오래된 라이브러리와 관련된 위험 측정 기준을 제공 하는 것.
| 미국 바이든 정부는 SW공급망 보안 강화를 위해 연방정부에서 조달한 SW제품에 대해 SW구성요소 정보를 기술한 문서, SBOM(Software Bill of Materials)을 제출하도록 요구하는 행정명령을 2021년 5월에 발표했다. 솔라윈즈, Kaseya, Log4J 등 SW공급망을 통한 보안 위협 사례가 증가함에 따라 연방정부 차원에서 이를 관리하기 시작한 것을 의미한다. 행정명령에 기반해 백악관과 OMB(Office of Management and Budget)를 중심으로 범부처적인 추진체계를 구축하고 민관협력을 추진하였다. 미국의 SBOM 정책은 개념 정립부터 제도화까지 단계적인 추진을 통해 민간 확산을 유도하고 있다. 우선 SBOM 범주·효과를 정의하고 준수 기준이 되는 최소요소(Minimum Elements)를 발표하였으며, 의료·에너지 등 실제 산업에서의 실증을 수행하였다. 표준화된 SBOM 활용과 정보 공유를 위해 SBOM 생성, SW공급망 관리, 산업별 보안 강화 등에 대한 가이드를 각각 배포하였다. SW공급망 보안 강화를 위해 행정명령으로 조달 규정 개정을 담당 부처에 지시하였고, 의료기기 등 개별적인 법안 발의를 통해 SBOM 확산을 위한 법적 기반을 마련하였다. |
https://spri.kr/posts/view/23537?code=data_all&study_type=issue_reports
이를 보고 미국 바이든 정부는 소프트웨어 공급망 보안을 강화하기 위해 SBOM(Sofware Bill of Materials) 도입을 적극적으로 추진하고 있다는 것을 느꼈다.
하지만 우리나라의 공급망 보안은 이제 시작이다.
최근 기사를 보면 ' 2025년에는 기업들이 제품 무결성과 공급망 복원력에 초점을 맞출 것으로 예상된다.' 라는 식으로 기사가 종종 나오곤 한다.
이에 따라 SBOM 활용이 더욱 확대되고 보안 규제 준수의 필수 요소로 자리 잡을 것으로 보인다.
KISIA ‘국내 SBOM 툴을 활용한 실증 조사 결과보고서’ 문제점과 개선사항
| 취약점 탐지 오류 (오탐, 정탐률 문제) | 오탐률 개선 및 취약점 데이터 정확성 향상 |
| 용량 제한 및 분석 속도 저하 | 대용량 파일 및 바이너리 점검 지원 |
| Debug/Release 빌드 구분 어려움 | 빌드 후 포함되지 않는 코드 필터링 기능 추가 |
| 상용 라이브러리 분석 부족 | 오픈소스뿐만 아니라 상용 라이브러리도 분석 가능해야 함 |
| 취약점 리스트 공유 어려움 | 취약점 정보 공유 플랫폼 필요 |
| 자동화된 CI/CD 통합 부족 | SBOM 점검을 개발 프로세스에 자동으로 포함 (GitHub Actions 지원) |
| 운영환경 제약 (폐쇄망 지원 부족) | 폐쇄망(온프레미스)에서도 SBOM 분석 가능해야 함 |
| 패키지 의존성 및 업데이트 문제 | 의존성 그래프 분석 및 자동 업데이트 권장 기능 필요 |
| 가독성 좋은 SBOM 문서화 부족 | 웹 대시보드에서 SBOM 분석 결과 시각화 |
| 취약점 상세 내역 확인 어려움 | 패키지 취약점 및 영향도를 명확하게 표시하는 기능 필요 |
위 결과 보고서를 토대로 오픈소스 패키지 공급망 보안 도구를 만들예정 이다.