정부, 공공 SW 납품에 SBOM 단계 적용…취약점 방치하면 조달 제한까지

공공 SW에도 ‘성분표’ 제출 흐름이 온다

• 정부가 공공기관에 납품되는 일부 소프트웨어에 SBOM 제출을 단계적으로 적용하기로 함

  • 과학기술정보통신부와 국가정보원이 ‘SW 공급망 보안 강화 로드맵’을 공개
  • 내년부터 공공 정보화사업과 보안 검증 절차에 SBOM 제출과 취약점 대응 절차를 반영할 계획
  • SBOM은 소프트웨어 안에 어떤 오픈소스, 외부 라이브러리, 상용 부품이 들어갔는지 적은 목록임

• 비유하자면 소프트웨어 성분표를 받겠다는 얘기임

  • 특정 오픈소스나 라이브러리에서 취약점이 터졌을 때, 어떤 제품과 기관이 영향을 받는지 빠르게 찾기 위한 장치
  • 요즘 소프트웨어는 자체 코드만으로 만들어지지 않고, 오픈소스·상용 라이브러리·외주 코드·클라우드 서비스가 섞여 있음
  • 이 중 하나만 뚫려도 같은 부품을 쓴 여러 기관으로 피해가 번질 수 있음

• 로드맵의 핵심은 보안 점검 범위를 완성품에서 개발·공급 단계로 넓히는 것임
  • 기존에는 공공기관이 제품을 도입할 때 보안 기능과 적합성을 주로 확인
  • 앞으로는 어떤 코드와 부품으로 만들어졌는지, 취약점이 나오면 누가 어떻게 고칠지도 같이 보겠다는 뜻

단계 적용 방식

• 정부는 올해부터 공공 분야 SBOM 관리체계를 개발함

  • 국가·공공기관이 도입하는 소프트웨어 제품의 SBOM을 등록·관리할 통합 관리 시스템을 구축할 계획
  • 기업 부담을 줄이기 위해 SBOM 항목은 최소화하겠다는 방침
  • 미국·유럽 등 주요국 요구사항과 표준화 동향을 고려해 이중 규제를 피하겠다고 설명

• 국정원은 내년부터 보안기능 시험 신청 SW를 대상으로 실증을 시작함

  • SBOM 생성·검증체계를 먼저 실증
  • 이후 하드웨어 제품 펌웨어, 클라우드 서비스 등 다양한 제품군으로 범위를 넓힐 예정
  • 공공 분야 취약점 관리를 위해 SBOM 제출과 SW 보안취약점 관리 담당관 지정도 관련 지침에 반영됨

• 공공기관용 위험관리 절차서도 마련됨

  • ‘공급망 사이버보안 위험관리 절차서’를 내년부터 적용
  • 기관마다 제각각이던 제품 도입·운영 절차를 정리하려는 목적
  • 취약점 발견 시 대응 주체와 조치 절차를 분명히 하려는 흐름임

sequenceDiagram
    participant 공급업체 as 공급업체
    participant 공공기관 as 공공기관
    participant 국정원 as 국정원
    participant 관리시스템 as SBOM 관리시스템
    공급업체->>공공기관: 제품과 SBOM 제출
    공공기관->>관리시스템: SBOM 등록과 관리
    국정원->>공급업체: 생성·검증체계 실증
    관리시스템->>공공기관: 취약점 영향 제품 식별
    공공기관->>공급업체: 패치와 대응 절차 요구

취약점 방치하면 조달 제한까지 간다

• 공공 납품 정보통신제품의 안보 위해 검증도 강화됨

  • 안보 위해 제품은 해외에서 위해성이 제기됐거나, 국가 배후 해킹조직 관여 가능성 또는 해킹 사고 가능성이 있는 제품을 말함
  • 국정원은 민간·군 전문가 등이 참여하는 안보 위해 평가 협의체를 구성할 계획
  • 대상 제품 선정과 대응 조치 방안을 논의하는 구조

• 2028년부터는 주요 기관 납품 제품에 체크리스트 제출이 우선 적용됨

  • 외교, 안보, 국방 등 주요 기관 제품 납품 시 먼저 적용
  • 이후 단계적으로 확대할 예정
  • 내년에는 개발·공급업체 대상 체크리스트를 개발·보급함

• 후속 조치가 미흡한 기업이나 제품에는 제재도 들어감

  • 침해사고나 중대 취약점 발견 이후 보안 패치 등 조치가 부족한 경우가 대상
  • 국정원은 중대한 취약점이 확인된 SW 제품에 대해 조치가 끝날 때까지 공공 조달을 일시 제한하는 방안을 마련하겠다고 밝힘

보안 검증 대상도 넓어진다

• 내년부터 보안적합성 검증 제도 요구사항도 바뀜

  • 공공기관 도입 제품이 국가 보안 기준에 맞는지 확인하는 제도
  • 현재는 보안 기능이 있는 정보통신기기가 중심
  • 앞으로는 해킹 사고가 잦거나, 중대한 취약점 발견 시 국가기관 전산망에 큰 피해를 줄 수 있는 IT제품까지 검증 대상이 넓어짐

• 검증 요건에는 공급망 위험 자체 점검도 들어감

  • 올해부터 기업이 공급망 위험을 자체 확인하고 증명할 수 있는 세부 기준을 마련
  • 내년부터는 SBOM 제출과 ‘안전한 SW 개발 방법론’ 준수 여부 등을 검증 요건으로 확인할 예정
  • 2028년부터는 국내외 상용·공개 SW 취약점 정보를 모으는 국가 데이터베이스도 구축함

기술 맥락

• 이번 로드맵의 핵심은 공공 SW 보안을 제품 검사에서 공급망 관리로 옮기는 거예요. 완성품이 보안 기능을 갖췄는지만 보는 방식으론, 내부에 어떤 오픈소스와 외부 라이브러리가 들어갔는지 알기 어렵거든요.

• SBOM을 요구하는 이유는 취약점 대응 시간을 줄이기 위해서예요. 특정 라이브러리에서 문제가 터졌을 때 “우리 기관 어디에 쓰였지?”를 사람 기억과 엑셀로 찾으면 이미 늦어요.

• 단계 적용을 택한 것도 현실적인 선택이에요. 모든 공공 납품 SW에 한 번에 의무화하면 공급업체 부담이 너무 커질 수 있어서, 보안기능 시험과 주요 기관 납품 제품부터 검증체계를 실증하려는 흐름이에요.

• 조달 제한까지 언급된 건 꽤 강한 신호예요. SBOM 제출 자체보다 중요한 건 취약점이 나왔을 때 패치 담당자, 대응 절차, 완료 기준이 명확해야 한다는 점이에요.

• 개발 조직 입장에선 이제 오픈소스 목록 관리, 취약점 추적, 릴리스별 SBOM 생성이 빌드와 배포 파이프라인의 일부가 되어야 해요. 공공 시장을 노린다면 보안팀만의 일이 아니라 개발 프로세스 문제로 봐야 해요.