< 로그4j가 뼈아프게 지적한 소프트웨어 생태계의 약점, 고쳐질까? > 연말에 터진 로그4j(Log4j) 사태는 여전히 보안 담당자들의 악몽으로 남아 있다. 2021년도가 시작되기 직전에 터져 2021년 초반을 보안 담당자들의 지옥으로 만들어 버린 솔라윈즈(SolarWinds) 사태가 떠오른다. 로그4j 사태가 각 기업의 IT 관련 조직들에 미친 영향과 준 교훈은 이루 다 세기가 힘들다. 하지만 가장 중요한 건 현재 각종 조직 내에서 실행되고 있는 소프트웨어 코드를 그 누구도 전부 다 알고 있지 못하다는 것만큼 중요한 교훈은 없어 보인다. 소프트웨어 생태계는 각종 디펜던시들로 이미 너무나 복잡하게 얽히고 있어 이제 그 밑바닥까지 훤히 들여다보고 이해한다는 건 불가능한 일이 되었다. 그러므로 그 깊숙한 곳에서부터 오류가 샘솟기 시작하면 그 누구도 그 근본에까지 이르는 조치를 취할 수 없게 됐다. 가장 밑바닥에서 떠받치고 있는 것도 소프트웨어니 결국 언젠가 취약점이 나오기 마련인데 말이다. 사태가 이렇게까지 퍼진 데에는 현대 기술의 발전 과정이라는 이유가 있다. 특히 마이크로서비스라든가 소프트웨어의 컴포넌트화가 이 현상을 과속화했다. 소프트웨어를 텍스트 파일로 한 줄 한 줄 써내려가는 게 아니라, 미리 만들어져 기성상품화 되다시피 한 ‘조각 소프트웨어들’을 끼워 맞추는 방식으로 만들다 보니 소프트웨어가 소프트웨어에 의존하고, 그 소프트웨어가 또 다른 소프트웨어에 의존하는 식의 ‘디펜던시의 망’이 만들어지게 된 것이다. 최근 구글의 오픈소스 통찰팀(Open Source Insights Team)은 조사를 통해 자바 패키지의 80%가 로그4j에서 나온 취약점의 영향을 받으며, 심지어 직접 업데이트를 할 수도 없다는 사실을 알아냈다. 아마 자바 생태계에서 로그4j의 리스크가 완전히 사라질 때까지는 수년이 족히 걸릴 것이라고 한다. 때문에 구글만이 아니라 보안 업계의 전문가들은 차라리 로그4j 사태가 더 커져서 디펜던시 관계에 있는 소프트웨어의 추적을 보다 용이하게 하는 법안이나 제도, 표준이 나오기를 고대하고 있다. 특히 ‘소프트웨어 재료 명시’ 제도가 생기기를 바라는 전문가들이 많다. ‘소프트웨어 재료 명시’ 제도(SBoM)란, 마치 시장에서 식료품의 원재료와 원산지 등을 표기한 채로 유통하는 것과 비슷한 방식으로 소프트웨어가 거래되도록 하는 것을 말한다. “어떤 디펜던시들을 내포하고 있는지 분명하고 투명하게 밝힘으로써 특정 구성 요소에서 취약점이 발견됐을 때 사용자들이 최대한 빠르고 정확하게 패치를 적용할 수 있도록 하자는 것이죠.” 보안 업체 리버싱랩스(ReversingLabs)의 수석 소프트웨어 아키텍트인 토미슬라브 페리신(Tomislav Pericin)의 설명이다. “소프트웨어 재료를 명시하는 제도는, 현 소프트웨어 개발 및 유통 체제에서는 반드시 있어야 합니다. 취약점 소식이 나왔을 때, ‘나에게 해당이 되는가’와 ‘어디서 업데이트를 구하는가’에 대한 답을 가장 빨리 스스로 확인할 수 있는 방법이기 때문이죠. 다만 소프트웨어 재료 명시라는 게 실제 상황에서 ‘수동 작업’으로 이뤄지고, 따라서 실현하는 게 상당히 어려울 수 있다는 한계가 있긴 합니다. 소프트웨어가 얼마나 많이, 자주 바뀌는지 생각해 보면 수동 작업 문제가 반드시 해결해야 된다는 걸 알 수 있을 겁니다.” 작년 바이든 행정부는 사이버 보안 관련 행정명령을 발표하면서 소프트웨어 개발자들이 재료들을 명시해야 한다는 내용을 담은 바 있다. 물론 모든 소프트웨어가 아니라, 연방 정부 기관에 판매되는 소프트웨어에 한해서였다. 이 행정명령을 받고 미국의 정보 통신 관련 기관이 ‘재료 명시의 최소 기준’ 가이드라인을 발표하기도 했었다. 즉, 어려워 보이긴 하지만 소프트웨어의 구성 요소들을 공개한다는 것의 필요성이 널리 인정받고 있다는 것이다. “미국 정부에서 움직이기 시작했으니 가까운 미래에 볼 수 있지 않을까 합니다.”