제조사가 사람에게 해를 끼치거나 그럴 위험이 있는 것으로 입증된 -제품을 설계하고 배송하는 경우, 일반적으로 제조사는 해당 제품을 신속히 회수합니다. 이런 공장 리콜은 모든 산업 분야에서 흔히 발생하지만, 세 가지 예를 들자면 어린이 장난감, 자동차 및 산업 기계와 같은 영역에서 특히 두드러지게 나타납니다.      그러나 소프트웨어 퍼블리셔는 사이버보안 결함으로 사람과 시스템을 위험에 빠뜨리는 제품을 제공해도 책임을 지지 않습니다. 오늘날 우리의 삶이 의존하는 시스템 대부분이 소프트웨어 기반으로 운영된다는 점을 고려하면 이러한 상황은 정상이라고 볼 수 없습니다.

데이터 유출이 점점 흔해지고 그 피해가 증가함에 따라 이러한 상황은 조사하기도 쉽지 않습니다. 예를 들어 수백만 명에 대한 전력을 공급하는 제품에 결함이 있을 경우 소프트웨어 공급사에 책임을 물을 수 있을까요? 또한, 그들이 책임을 저야 할까요?

Brian Fox, co-founder and CTO of Sonatype. Source: Sonatype

Sonatype의 공동 창립자이자 CTO인 Brian Fox의대답은 ‘그렇다’입니다. 이런 책임을 지는 것이 소프트웨어 산업의 필연적인 진화일 뿐만 아니라 미국 연방거래위원회 산하 소비자보호위원회(US Federal Trade Commission’s Consumer Protection Board)는 이미 퍼블리셔에게 과실 책임을 물을 수 있는 권한을 갖고 있기 때문입니다. 그는 Tech HQ와의 독점 인터뷰에서 소프트웨어 개발사가 본질적으로 안전하지 않은 제품을 출시하는 경우 “그 자체가 이미 규정 위반일 잠재적인 가능성이 있으며, 피해가 합리적으로 예측 가능한 경우 책임을 져야 할 수 있습니다[…] 지금까지 다른 모든 산업은 이러한 변화를 겪었습니다. 믿기 어렵겠지만, 불과 100년 전만 해도 식품 제조사가 제품안에해충이 들어가서 사람들이 질병에 걸리는 것에 대해 책임을 지지 않던 시절이 있었습니다 […] 자동차 바퀴가 분리되어 사람이 다쳐도 자동차 제조사가 책임을 지지 않던 시절이 있었습니다. 소프트웨어 개발사에게 어떤 형태로든 책임과 의무가 부과되지 않을 것이라고 믿는 것은 […] 말 그대로 다른 산업의 역사상 한 번도 일어나지 않은 일이 일어날 것이라고 내기하는 것과 마찬가지입니다. 당신은 어떨지 몰라도 저는 그런 내기를 하지 않을 것입니다.”라고 밝혔습니다.

소프트웨어 업계는 아직 책임과 의무의 형태에 대해 그 어떤 합의도 이루지 못했습니다. 오히려 수십 년 전 독자적인 제품을 CD에 담아 배송했을 때 책임 소재가 더 명확했을 것입니다. 하지만 빠르게 반복되는 오늘날의 프로덕션 주기와 오픈 소스 라이브러리 사용, 프레임워크 및 구성요소로 인해 상황은 훨씬 더 모호해 졌습니다. 현재 검색 엔진에서 SBoM(소프트웨어 구성요소 목록)이라는 개념의 검색 빈도가 증가하고 있는데, 이는 작년 Apache Log4j 결함 등 잘 알려진 소프트웨어 공급망 취약점이 드러난 이후 이 개념에 대한 관심이 높아졌기 때문입니다.

소프트웨어 조직, 기업, 재단, 커뮤니티가 의견을 모아 거버넌스 및 법률 제정이 시작되고 있습니다. 유럽에서는 현재 사이버 복원력 법안의 일부로 구성된 리콜 및 규제에 초점을 맞추고 있습니다. 하지만 Brian은 이것이 올바른 방향이기는 하지만, EU가 오픈 소스 구분 기준을 명확하게 정하지 못해 목표를 달성하지 못했다고 합니다.

미국에서는 행정명령이 SBoM에 집중하면서 일종의 ‘실행 후 잊어버리는’ 법안이 되고 있는 것으로 보입니다. “리콜을 […] 강제하는 것은 […] 제가 항상 주장해온 것 중 하나입니다. 초기 SBoM 명령에서 마음에 들지 않았던 점은 문제의 엉뚱한 부분에 너무 집중하고 있다는 점이었습니다. 소프트웨어를 판매할 때 구성요소 목록을 작성해서 우리[최종 사용자]에게 제공해야 하는 필요성에 집중했습니다. 제가 보기에는 자동차 제조사에게 더 이상 리콜을 할 필요가 없다고 하는 것과 마찬가지입니다. 자동차를 판매할 때 부품 명세서를 출력해서 글러브박스에 붙이기만 한다고 될까요? 제가 이 말을 하면 사람들은 항상 어처구니 없으니까 웃습니다. 하지만 SBoM에 대한 행정명령은 이와 다를 바가 없습니다. 기업들이 실제로 SBoM에 신경 쓰도록 하고, 향후 취약점이 발견되었을 때 이에 대한 조치를 취하도록 장려하는 데 아무런 도움이 되지 않습니다. 결국은 책임을 최종 사용자에게 전가한다는 의미입니다.”

논리적으로 봤을 때 소프트웨어 개발 속도를 늦추고 제품 출시 주기가 늘어나면 최종 제품이 최종 사용자에게 더 안전할 것이라고 생각할 수 있습니다. 하지만 Brian은 그렇지 않다고 말합니다. Sonatype이 최근 조사한 기업에 대해 이렇게 말합니다. “빠르고 안전한 개발 프로세스라는 두 마리 토끼를 모두 잡은 기업만이 오직 보안에만 집중하는 기업이나 속도에만 집중하는 기업보다 더 안전하고 빠르다는 사실을 발견했습니다. 그래서 역설적이죠.” 그는 소프트웨어를 빠르고 안전하게 개발하는 기업은 올바른 DevSecOps 중심 CI/CD 프로세스를 갖추고 있으며, 이러한 기업이 가장 성공적이라고 설명합니다.

“공급망을 더 잘 관리한다는 것이 속도를 늦춰야 한다는 것일까요? 아닙니다. 오히려 예상하지 못한 수정과 재작업이 줄어들기 때문에 더 안전하고 빨라집니다.  종속성을 관리하는 효율적인 방법이 있다는 것은 개발자가 안전하게 혁신할 수도 있다는 것을 의미합니다. 이것은 제대로 수행된다면 윈-윈할 수 있는 드문 시나리오 중 하나입니다. [보안]이 시스템에 걸림돌이 될 필요는 없습니다.”

완벽한 보안을 갖춘 소프트웨어를 출시하는 것은 불가능에 가깝습니다. 종속성, 업데이트, 새로운 취약점 공격 방법 등이 복합적으로 작용하기 때문에 완벽한 보안은 존재하지 않습니다. 하지만 Fox는 현재 또는 미래에 발생할 수 있는 대부분의 잠재적 취약점은 이론적인 구성으로만 남아 있을 수 있다는 점이 중요하다고 지적합니다. 악의적인 공격자가 취약점을 활용할 수 있는 소프트웨어의 사용 모드가 분명히 존재한다는 것입니다. 그는 “취약점은 상한 상추와 같아서 상한 상추를 팔아서는 안 된다는 식으로 이 문제를 생각하는 것”이 잘못된 사고방식이라고 합니다. “그렇지 않습니다. 악의적인 공격은 오염된 상추와 같아서 리포지토리에서 서둘러 삭제해야 하지만, 일반적인 취약점은 땅콩버터와 비슷합니다. 누군가에게는 치명적인 알레르기를 일으킬 수 있지만, 대부분의 사람들에게는 아무 문제가 되지 않아요.”

Brian Fox는 전 세계 정부 및 조직의 자문 역할을 맡아왔으며, 가장 최근에는 사이버보안 및 소프트웨어 문제에 대해 바이든 행정부와 협력하고 있습니다. 예를 들어, 사전 심사를 거쳐 안전한 구성요소만 담긴 리포지토리와 같은 쉬운 해답은 없습니다. “세상에는 수백만 개의 구성요소가 있으며, 모든 구성요소를 충분히 검사하는 것은 불가능합니다. 절대 불가능합니다. 그렇게 검사하는 기업은 이것을 골든 리포지토리라고 부릅니다. 문제는 개발자가 (골든) 리포지토리 외부의 구성요소는 사용하지 못하게 됨으로써 혁신을 저해하게 된다는 점입니다.  그리고 최악의 문제는 대부분의 프로세스가 실제로 리포지토리의 내용물을 백업하거나 검사하지 않는다는 것입니다.”

그리고 이 경우 최종 사용자의 관점에서 볼 때 ‘안전한 구성요소 리포지토리’를 보유한 소프트웨어 개발사, 즉 골든 리포지토리의 소유자는 여전히 소프트웨어를 사용해서 발생하는 모든 손해에 대해 책임이 있습니다.

소프트웨어에 대한 법적 책임 추적 문제를 빠르게 해결할 방법은 없지만, Fox처럼 소프트웨어 산업(및 사이버보안 산업)에 깊이 관여하고 있는 전문가들이 일관된 정책 수립에 중요한 역할을 할 수 있습니다. 이런 정책이 동일한 문제에 대해 관점이 다른 여러 단체가 만든 가이드라인 이상의 규정으로 자리잡기 까지는 시간이 조금 더 걸릴 것입니다. 향후 몇 년 동안은 소프트웨어를 안전하게 사용하기 위한 ‘주의 사항’만이 있을 것입니다. 그리고 개발사는 DevSecOps를 일시적인 유행어로 취급하지 않고 이를 위해 더 많은 노력을 기울여야 할 것입니다.