SolarWinds에서 배울 점 – 타사 라이브러리 평가

2020년 12월, SolarWinds는 자사의 Orion 제품이 대규모 공격을 받았다고 밝혔으며, 이는 여러 정부 기관을 비롯한 많은 SolarWinds 고객의 인프라 보안에 구멍이 뚫린 사건이었습니다. 이러한 침해의 범위는 공급망의 취약성과 소프트웨어 시스템 보안에 있어서 제3자 의존성에 대해 많은 관심을 불러일으켰습니다. 이러한 위협 요소 중 새로운 것은 없지만, 각 조직은 이 사건으로 실시한 해당 영역에 대한 추가 조사를 통해 다음 표적이 되지 않기 위해 보안 태세를 개선하고자 하는 강한 욕구가 생겼습니다. 소프트웨어 엔지니어링 팀으로서 공급망과 가장 일반적으로 하는 상호 작용은 애플리케이션에 통합할 외부 라이브러리를 선택하는 것입니다. 잘 유지 관리된 외부 라이브러리는 개발 노력에 큰 도움이 될 수 있으며, 공통 기능을 재구현할 필요 없이 자체 제품의 핵심 차별화 요소에 집중할 수 있도록 함으로써 엔지니어링에 소요되는 시간을 크게 절약할 수 있습니다. 반면, 제대로 구현되지 않은 라이브러리는 사용이 어려울 수 있으며, 조직과 고객에게 위험을 초래하는 보안 취약점이 발생할 수 있으며, 극단적인 경우 서비스의 관련 없는 부분의 작동을 방해하거나 전체 아키텍처를 손상시킬 수도 있습니다. Mindmeld 팀의 수석 엔지니어가 엔지니어링 관행의 건전성과 잠재적으로 보안에 미치는 영향과 관련하여 라이브러리를 평가하는 데 사용한 다양한 고려 사항에 대한 간략한 설명입니다. 이러한 접근 방식은 최종 처방이 아니라 출발점으로 제시하는 것이며, 자신의 필요에 맞는 접근 방식을 찾으시길 바랍니다. 여기에 제시된 방법으로 단번에 모든 것을 해결할 수는 없지만, 프로젝트가 고품질 종속성에만 의존하도록 하면 공격 영역을 크게 줄이고, 보다 쉽게 제품을 확장하고 유지 관리할 수 있습니다.

라이브러리 범위

이 초기 고려 사항은 얼마나 평가가 얼마나 철저한지 또는 적절한지를 결정해주는 중요한 항목입니다. 라이브러리는 얼마나 많은 기능을 제공합니까? 해당 기능이 제품이 작동하는 데 있어 얼마나 중요합니까? 설치 공간이 작은 단순한 라이브러리는 자체 코드에 긴밀하게 통합되는 대규모 프레임워크보다는 훨씬 적은 정밀 조사를 필요로 합니다. 또한 간헐적 업데이트와 일부 지표는 주요 기능에는 중대한 위험이 되지만, 극히 제한된 작업만 수행하는 소규모 라이브러리의 경우 문제 되지 않거나 예상되는 수준일 수 있습니다. 이와 관련하여 필요한 질문은 라이브러리를 어떻게 사용할 것인가입니다. 정적 분석 도구 또는 유닛 테스트 프레임워크의 구성 요소와 같은 개발 의존성은 런타임 의존성에 비해 위험도가 훨씬 낮습니다. 빌드 파이프라인의 장애는 릴리스가 지연시키거나 개발자에게 기타 단기적인 문제를 유발할 수 있지만, 사용자에게는 직접적인 영향을 미치지 않으며 일반적으로 응용프로그램 자체의 보안에는 영향을 미치지 않습니다.

유지 보수 기록

프로젝트의 전반적인 상태를 파악하는 가장 빠른 방법은 소스 제어 기록을 살펴보는 것입니다. 마지막 릴리스는 언제였나요? 릴리스 빈도와 소스 코드 저장소에 대한 커밋 비율은 얼마인가요? 프로젝트가 자주 업데이트하는 것이 좋습니다. 라이브러리가 앞으로도 계속 유지 관리될 것이라는 확신이 강해지기 때문입니다. 반면 장기 휴면 상태인 프로젝트는 해결되지 않은 버그를 포함하거나 공통 종속성의 신규 버전 또는 언어 런타임 자체에 호환성 문제가 발생할 수 있습니다. 라이브러리의 변경 로그를 살펴보는 것 또한 매우 중요합니다. 때로는 각 릴리스에서 도입된 변경 사항이 릴리스 페이지에 설명되어 있는 경우도 있으며 변경 로그가 소스 코드 저장소의 최상위 수준에 있는 파일인 경우도 있습니다. 이러한 정보를 쉽게 사용할 수 없다면 이는 중대한 위험 신호입니다. 어떤 릴리스에서 다음 릴리스로 갈 때 변경된 사항과 이전 버전과의 하위 호환성에 대한 명확한 설명을 문서화해야 합니다. 단, 이전 버전과 호환되는 변경 사항이나 핵심 기능에 대한 버그에 대한 빈번한 수정 자체도 문제의 원인이 됩니다. 이는 개발자가 릴리스 전에 변경 사항을 계획하고 디버깅하는 작업을 제대로 수행하지 않다는 의미이기 때문입니다.

유지 관리자와의 관계

보다 심층적인 평가에는 프로젝트의 이슈 트래커 및 기타 공개 커뮤니케이션 채널을 살펴보는 작업이 포함될 수 있습니다. 유지 관리자는 사용자에게 얼마나 잘 대응하나요? 유지 관리자가 친절한 태도로 피드백을 잘 수용하나요, 아니면 공격적인 말투를 자주 사용하나요? 제기된 문제와 해결된 문제의 비율은 어떻게 되나요? 유지 관리자가 사용자의 문제를 적극적으로 해결하고 있나요, 아니면 버그 리포트가 장기간 중단되어 있나요? 문서가 얼마나 광범위하며, 얼마나 효과적으로 사용자에게 구현 모범 사례를 제시하나요? 해당 프로젝트와 관련하여 역동적인 커뮤니티가 조성되었다는 증거가 있나요? 예를 들어, 사용자 지원에 대한 책임은 전적으로 기본 유지 관리자에게 있나요, 아니면 부족한 부분을 보완할 의지와 능력이 있는 다른 커뮤니티 구성원이 있나요? 커뮤니티와 건전한 관계를 유지하는 프로젝트는 사용자의 특정 요구 사항을 충족하고 변화하는 환경에 빠르게 적응할 가능성이 훨씬 큽니다

전이 의존성

이 평가는 단순히 릴리스 빈도를 계산하는 것보다 다소 더 많은 노력이 필요하지만 정보의 보고를 제공해줍니다. 먼저 라이브러리가 얼마나 많은 추가 종속성에 의존하는지와 특히 불필요하게 종속성을 얼마나 많이 가져오는지에 관해 알아보겠습니다. 라이브러리에 핵심 기능을 제공하는 종속성은 관련 없는 작업을 위해 많은 추가 라이브러리를 가져오는 종속성과 비교할 때 그 중요도가 훨씬 낮습니다. 종속성이 추가된다는 것은 복잡성과 공급망 리스크가 가중된다는 것을 의미합니다. 확실하지 않은 경우, 간단한 평가 도구 중 하나는 도커 컨테이너에 라이브러리를 설치하고 프로세스에 추가되는 라이브러리 수를 기록하는 것입니다. 여기에서 관건은 새로운 취약점 발견 시 종속성을 얼마나 쉽게 업데이트할 수 있느냐는 겁니다. 이러한 이유로 평가의 중요한 부분은 종속성이 제한적(특정 버전의 라이브러리로만 충족 가능)인지 또는 허용적(다양한 버전으로 충족 가능)인지 확인하는 것입니다. 제한적인 종속성이 중대한 문제인 이유는 패치 작업을 어렵게 하거나 다른 기능을 위해 의존하는 라이브러리를 강제로 다운그레이드할 수 있기 때문입니다. 또한 이러한 전이 의존성이 얼마나 최신 상태인지도 관련이 있습니다. 2개월 된 릴리스를 지정하는 버전 종속성보다는 2년 된 릴리스에 대한 종속성이 훨씬 중요합니다. 이와 유사한 맥락에서 프로젝트가 잘 실행되고 있다는 징후 중 하나는 종속성을 최신 상태로 유지하는 빈번한 업데이트 기록입니다.

언어 간 의존성

특정 언어로 작성된 패키지에 다른 언어로 된 추가 종속성이 있는 경우(예: 컴파일된 C 확장으로 구성된 파이썬 라이브러리)에 특히 주의해야 합니다. 2차 종속성에 익숙하지 않은 언어 또는 프로그래밍 환경이 포함될 경우 전반적인 품질을 평가하기가 더 어려워집니다. 또한, 언어마다 패키징 규칙이 다른 경우가 많으며, 혼합 언어 프로젝트의 유지 관리자가 운영 중인 모든 프로그래밍 언어에 대한 모범 사례를 잘 알지 못하는 경우가 많아 패치 및 업데이트가 훨씬 더 어렵습니다.

암호화 라이브러리

암호화 라이브러리는 관련 알고리즘 복잡성과 해당 잠재적인 취약성이 커다란 영향을 미칠 수 있기 때문에 특별히 고려할 필요가 있습니다. 이러한 라이브러리는 특히 주의 깊게 살펴보고 오랜 추적 기록을 보유한 철저하게 검토된 라이브러리에만 의존해야 합니다. OpenSSL(C 및 C++), BouncyCastle(Java), PyCA 암호화 라이브러리(Python)는 안전한 이브러리의 몇 가지 예입니다. 조직의 보안 정책 또는 규정 준수 요구 사항에 따라 옵션이 제한될 수 있습니다. 아울러 암호화 라이브러리의 이미 알려진 취약점을 파악하고, 항상 새 릴리스에 대한 최신 정보를 확보하세요. 이는 제3자 종속성 중에서 보안에 가장 큰 영향을 미칩니다.

코드 및 문서 품질

이번과 다음 섹션은 고강도 평가이지만, 고위험 사례에 대해서는 이러한 수준의 정밀 조사가 필요하기도 합니다. 저 같은 경우에는 프로젝트의 전반적인 코드 품질을 파악하고자 할 때, 이미 충분히 숙지한 기능을 사용하는 소스 코드를 찾고 해당 코드베이스의 작은 영역을 얼마나 잘 작성했는지 평가합니다. 복잡한 개념을 효과적으로 전달할 수 있는 작성자의 명확성과 능력에 초점을 맞춰 프로젝트 문서의 품질을 검토하는 경우도 있습니다. 두 경우 모두 목표는 유지 관리자가 세부 사항에 신경을 쓰는지, 아니면 절차를 무시하는 경향이 있는지 확인하고자 하는 것인데, 이는 프로젝트 일부의 관리 수준이 전체 프로젝트의 상태를 대표적으로 보여줄 수 있다는 가능성을 전제로 한 조사입니다. 구체적인 예로, 파이썬 프로젝트의 SSL 처리를 살펴보면 다음을 알 수 있습니다.

기본 SSL 연결 매개 변수를 사용하거나 보다 안전한 설정으로 사용자 지정을 시도하는가?
사용자 정의를 하는 경우 변경 사항은 얼마나 합리적인가?
사용자가 추가 사용자 정의를 할 수 있는가?
사용자 정의를 허용하는 경우 파이썬의 표준 라이브러리 SSLContext 객체를 재사용하는가, 아니면 처음부터 다시 시도하는가?

이와 같은 평가에서 기대하는 것은 건전한 설계 원칙과 표준 관용구의 재사용, 그리고 작성자가 잠재적인 사용자 요구를 예측하고 이를 해결할 수 있는 적절한 확장성을 제공을 제공하는가입니다.

취약점 처리

본 항목을 마지막 순서에 소개하는 이유는 이는 일반적으로 시간이 지남에 따라 축적되는 것으로 초기 평가에 유용하지 않을 수 있기 때문입니다. 또한 특정 라이브러리가 얼마나 널리 사용되고 보안과 관련이 있는지에 따라 크게 달라집니다. 그러나 기존 라이브러리를 계속 사용할지 아니면 대체 라이브러리로 마이그레이션을 시도할지 여부를 결정하는 데는 이 항목이 중요한 요소가 될 수 있습니다. 간단히 말하자면 취약점 패치에 대한 프로젝트 유지 관리자의 대응력과 자체 배포에서 이러한 패치의 혜택을 얼마나 쉽게 얻을 수 있는지 평가하고자 합니다. 취약점이 자주 공개되는 프로젝트의 경우 다소 우려되는 측면이 있기는 하지만, 전반적인 코드 품질 및 유지 관리 방식보다는 광범위한 사용 및 보안 관련한 중요한 요인이 될 수 있습니다. 취약점이 알려진 후 발생하는 작업은 보다 훌륭한 지표가 될 수 있습니다. 패치가 새로운 릴리스에 신속하게 통합되는가? 패치 버전이 출시될 경우 얼마나 쉽게 업그레이드할 수 있는가? 프로젝트의 전면적인 변경이 잦은 경우, 특히 이전 버전과의 호환성이 정기적으로 깨지는 경우에 수정 사항을 이전 버전으로 백포트하는가? 라이브러리가 Linux 배포의 일부인 경우, 패치 백포트에 대한 책임은 일반적으로 원래 개발자가 아닌 배포 유지 관리자에게 있지만, 패키지 작성자가 라이브러리를 처리하는 방식에도 동일한 질문을 적용할 수 있습니다. (배포판은 종종 활성 유지 관리가 있는 핵심 패키지와 일반적으로 최소한의 변경 사항이 적용된 업스트림 릴리스를 추적하는 더 많은 주변 패키지를 구분합니다.) 제 경우에는 라이브러리가 취약점을 제대로 처리하지 못하는 명백한 기록을 보이거나, 보안 패치를 활용하기 어려운 방식으로 작동하는 경우, 팀원들에게 대체 패치로 마이그레이션할 것을 권장합니다.

결론

소프트웨어 프로젝트와 주변 커뮤니티의 전반적인 품질에 대한 평가 기법은 소프트웨어 프로젝트의 상호 의존도가 높아짐에 따라 그 중요성이 더욱 증대되고 있는 필수적인 기술입니다. 그것은 또한 매우 개별적인 기술이기도 해서, 여러분의 전문 분야에서 라이브러리 유지 관리자가 내리는 결정을 조사할 때 그 이점을 최대한 누릴 수 있습니다. 잠재적인 공급업체의 모든 세부 사항을 완벽하게 검증하는 것은 기능을 직접 구축하는 것보다 훨씬 더 어려운 작업이기 때문에, 평가 과정은 신뢰 수준을 설정하고 잘못 배치되지 않도록 하는 조치의 일부가 되었습니다. 궁극적으로 제3자 종속성 평가 방법에 대한 학습은 제품의 보안과 안정성을 책임지는 엔지니어링 문화를 구축하는 데 있어 중요한 요소입니다.

작성자 정보

제이콥 에머트 애런슨(Jacob Emmert-Aronson)은 Webex Intelligence 조직의 일부인 Mindmeld 팀의 수석 엔지니어로서, 정보 보안, DevOps 및 소프트웨어 유지 관리 분야의 지식 리더이며, 이러한 것들이 어떻게 교차하는지 이해하는 것이 전문 분야입니다.