[보안뉴스] 로그4j가 뼈아프게 지적한 소프트웨어 생태계의 약점, 고쳐질까?

이미지 = utoimage

---

<뉴스 내용 요약>

(서론)
1. 연말에 터진 Log4j 사태는 여전히 보안 담당자들의 악몽
2. 2021년 초반 *솔라윈즈(SolarWinds) 사태가 떠오름
3. 소프트웨어 생태계는 각종 디펜던시들로 너무 복잡하게 얽혀있음
4. 사태의 심각성에는 현대 기술의 발전 과정이라는 이유가 있음
5. 특히 마이크로서비스와 소프트웨어 컴포넌트화가 이 현상을 과속화

(본론)
1. 전 세계 개발자들의 오픈소스 소프트웨어 다운로드 2020~2021년 사이 73% 증가 연구 결과
2. *소프트웨어 재료 명시 제도가 생기기를 바라는 전문가들이 많음
3. 해당 제도를 통해 '나에게 해당이 되는가'와 '어디서 업데이트를 구하는가'를 빠르게 확인 가능
4. 미국 정부 기관 판매 소프트웨어는 해당 제도를 이미 실행 중

(결론)
3줄 요약
1. 로그4j가 우리에게 알려준 것, 디펜던시의 복잡함
2. 소프트웨어들의 의존 관계가 얼마나 복잡한지, 이제 아무도 모든 관계를 다 파악할 수 없음
3. 그래서 필요한 게 소프트웨어 재료를 투명하게 공개하고 명시하는 제도

원문 : https://m.boannews.com/html/detail.html?tab_type=1&idx=103890

 

*솔라윈즈(SolarWinds) 사태 - 솔라윈즈라는 '기업용 소프트웨어 개발' 미국 회사에서 공급망 서버가 공격당해 악성 플러그인이 정식 제품과 동시에 배포

*소프트웨어 재료 명시 제도 - 시장에서 식료품의 원재료와 원산지 등을 표기한 채로 유통하는 것과 비슷한 방식으로 소프트웨어가 거래되도록 하는 것

---

(소감)

1. 솔라윈즈 사태에 대하여 처음 알게 되었음

2. 국내에서 소프트웨어 재료 명시 제도의 필요성을 확인

3. 가장 밑바닥의 소프트웨어도 결국 언젠가 취약점이 나올 수밖에 없음을 확인

4. 조직 내 소프트웨어 코드를 그 누구도 전부 다 알고 있지 못함을 깨달음

 

(의문점)

Q1. 소프트웨어 재료 명시 외에 벤치마킹할 국외 보안 제도

Q2. DevSecOps 관점에서 소프트웨어 디펜던시 복잡도를 낮추는 방법

Q3. 로그4j와 유사한 사태 발생 시 기업 보안담당자 측면에서의 대응책

Q4. '조립하는 방식'의 개발에서 변화해야 하는 소프트웨어 문화