OWASP Top 10: 더 나은 오픈소스 보안을 위한 가이드

XZ 유틸(XZ Utils)과 같은 사건들이 잇따라 발생하면서 오픈소스 소프트웨어(OSS)의 보안과 사용 방식을 개선해야 한다는 목소리가 커지고 있습니다. 그에 따라 OWASP의 10대 OSS 위험 등 사이버 보안 실무자를 위한 추가 리소스 및 지침도 발전하고 있습니다. OWASP는 오픈소스 웹 애플리케이션 보안 프로젝트입니다. 주로 웹에 관한 정보노출, 악성 파일 및 스크립트, 보안 취약점 등을 연구하고 있으며, 10대 OSS 위험을 발표했습니다. 그럼 지금부터 OSS 위험 요소 상위 10대 목록을 살펴보겠습니다.

■ OSS-RISK-1 알려진 취약점

이 섹션에서는 주로 소프트웨어 개발자와 유지 관리자가 실수로 도입한 후에 커뮤니티 보안 연구자들에 의해 공개되는 소프트웨어 결함들을 다룹니다. 이 문제를 해결하기 위한 노력에는 CISA의 KEV 카탈로그와 EPSS가 있습니다.

또한 조직은 사용하는 모든 OSS 구성 요소에서 취약점을 식별하고 알려진 익스플로잇, 익스플로잇 확률, 노이즈 발견을 최대 80% 줄일 수 있는 도달 가능성 분석 등의 방법에 기반해 발견 우선순위를 정해야 합니다.

■ OSS-RISK-2 합법적 패키지 손상

두번째 항목은 합법적 패키지의 손상입니다. 악의적 공격자들은 합법적인 패키지를 손상시켜 조직과 개인 모두에게 영향을 줄 수 있습니다.

이 공격 벡터에는 프로젝트 관리자의 계정 탈취, 패키지 리포지토리 취약점 이용 등이 있습니다.공격자는 추후에 악의적인 의도를 실현하기 위해 관리자가 되겠다고 자원하기도 합니다. 최근 발생한 XZ 유틸 사건에서도 누군가 오랜 시간 동안 합법적인 기여자로 가장한 뒤 코드에 백도어를 삽입했습니다.

이러한 위험을 완화하기 위한 지침으로는 마이크로소프트가 오픈SSF에 기증한 S2C2F가 있습니다.

■ OSS-RISK-3 이름 혼동 공격

이름 혼동 공격(name confusion attacks)에서 공격자는 잠재적 피해자가 실수로 다운로드나 사용하도록 유도하기 위해 합법적 OSS 패키지 또는 구성 요소와 이름이 유사한 악성 구성 요소를 만듭니다.

CNCF 소프트웨어 공급망 공격 목록에도 나와 있는 이런 공격에는 타이포스쿼팅과 브랜드 재킹이 포함됩니다. 손상된 패키지가 조직의 IT 환경에 유입되면 시스템과 데이터의 기밀성·무결성·가용성(CIA)에 영향을 미칠 수 있습니다.

■ OSS-RISK-4 유지 관리되지 않는 소프트웨어

OSS가 어려운 이유는 독점 소프트웨어와 달리 ‘공급업체’가 없기 때문입니다. 따라서 소프트웨어가 유지 관리 및 업데이트될 것이라는 보장이 없습니다.

OSS가 유지 관리되지 않는 또 다른 요인은 OSS 프로젝트의 94%가 10명 이하의 개발자에 의해 유지 관리된다는 점입니다. 코드에 기여하는 개발자가 단 한 명에 불과한 경우도 25%에 달한다고 합니다.

이런 위험에 대처하기 위해 보고서에 인용된 권장 사항으로는 유지 관리자와 기여자의 수, 릴리스 빈도, MTTR(평균 수정 시간) 취약점 등 프로젝트의 활성 상태와 건전성을 확인하는 방법이 있습니다.

■ OSS-RISK-5 오래된 소프트웨어

최신 버전과 업데이트가 존재함에도 불구하고 프로젝트에서 오래된 버전의 구성 요소를 사용하는 경우입니다. 시놉시스 보고서에서 의하면 이런 상황은 실제로 압도적으로 많은 코드베이스와 리포지토리에서 발생하고 있습니다.

물론 많은 최신 소프트웨어 애플리케이션과 프로젝트가 복잡하고 어지러울 정도로 많은 종속성을 갖고 있기 때문에 이 문제도 복잡할 수밖에 없습니다. 소나타입과 엔도르랩과 같은 기업의 보고서에서 이 문제가 특히 강조됐는데, 엔도르랩은 ‘종속성 관리 현황’을 발표해 취약점의 95%가 전이적 종속성(transitive dependency)과 연관돼 있다고 설명했습니다.

■ OSS-RISK-6 추적되지 않는 종속성

이는 개발자 및 조직이 특정 종속성 또는 구성 요소의 사용 여부를 전혀 인지하지 못하는 상황입니다. 조직이 소프트웨어 구성 분석(SCA) 같은 도구로 OSS 소비를 파악하지 않거나, 조직이 소비 및 배포하는 소프트웨어의 구성 요소에 대해 가시성을 제공하는 SBOM(software bills of materials) 같은 새로운 도구를 채택하지 않을 때 문제가 발생할 수 있습니다.

실제로 SBOM 및 소프트웨어 공급망 보안에 대한 광범위한 노력이 있었습니다. SBOM은 조직이 기업으로서 구성 요소 인벤토리를 관리하도록 하는 방식으로 문제에 대응합니다.

■ OSS-RISK-7 라이선스 및 규제

이 위험은 구성 요소 또는 프로젝트에 라이선스가 없거나 다운스트림 소비자의 의도된 사용을 라이선스가 방해하는 상황을 의미합니다. OWASP는 조직이 OSS 구성 요소를 사용할 때 해당 라이선스 약관을 준수해야 한다고 명시하고 있습니다.

이는 조직이 독점 제품, 서비스 및 오퍼링에 OSS 구성 요소를 광범위하게 사용할수록 비즈니스 목표, M&A 활동 등에 영향을 미칠 수 있습니다.

조직은 소프트웨어에 사용 중인 구성 요소의 라이선스와 용도를 파악해 위험을 완화하는 조치를 취할 수 있습니다. 또한 OWASP는 라이선스가 없는 구성 요소의 사용을 완전히 피하고, 서로 상충되는 라이선스가 적용된 구성 요소를 식별할 것을 권장합니다.

■ OSS-RISK-8 미성숙한 소프트웨어

모든 소프트웨어가 똑같이 만들어지는 것은 아니기 때문에 부분적으로 유지 관리자의 참여 수준에 따라 성숙도에 편차가 있을 수 있습니다.

많은 개발자가 보안에 관심이 없다는 것도 불편한 현실입니다. 리눅스 재단과 하버드 대학교 혁신 과학 연구소(LISH)의 연구에 따르면 무료 및 오픈소스 소프트웨어 개발자가 코드 보안을 개선하는 데 사용하는 시간은 전체 시간의 약 2.3%에 불과했습니다.

하지만 업계에서는 이를 지원하기 위해 노력하고 있다. 대표적으로 오픈SSF의 스코어카드가 있습니다. 이는 깃허브의 OSS 프로젝트에 대해 브랜치 보호 여부, 기여자 및 조직 수, CI 테스트, 퍼징, 유지 관리, 라이선싱 등 강력한 점검을 제공합니다.

■ OSS-RISK-9 승인되지 않은 변경

OWASP는 이를 개발자가 인지, 검토 또는 승인하지 않고 구성 요소가 변경될 수 있는 상황이라고 정의했습니다. 다운로드 링크가 변경되거나 버전이 바뀌지 않은 리소스를 가리키거나, 심지어 안전하지 않도록 변조된 데이터 전송을 가리킬 때 위험이 발생할 수 있습니다. OWASP는 보안 전송의 역할을 강조했습니다.

권장되는 조치 및 완화 방법으로는 보증을 위해 자원 ID(resource identifier)를 사용하고 변경 불가능한 아티팩트를 제시하는 것이 있습니다. 또한 구성 요소를 실제로 설치 및 사용하기 전에 서명과 다이제스트를 확인하는 방법도 있습니다. 전송 중 구성 요소가 손상될 위험을 줄이기 위해 조직은 네트워크 트래픽의 전송 및 통신에 보안 프로토콜을 사용해야 합니다.

■ OSS-RISK-10 과소 또는 과대 종속성

마지막으로 구성 요소가 제공하는 기능이 매우 적거나 많지만 실제로는 일부만 사용되는 상황입니다. 이를 흔히 ‘소프트웨어 블롯(software bloat)’이라고 부릅니다.

종속성 크기가 작으면 코드 줄이 제한돼 있기 때문에 구성 요소가 보안을 위해 업스트림 프로젝트에 종속되게 됩니다. 반대로 코드가 비대해지거나 코드 줄 수가 기하급수적으로 늘어나는 경우, 의도한 용도만큼 필요하지 않거나 사용되지 않음에도 불구하고 공격 표면이 증가할 수 있습니다.

OWASP 보고서는 이런 경우 내부적으로 필요한 기능을 재개발해 과소 또는 과대 종속성에 의존하는 위험을 완화할 것을 권장하고 있습니다.

지금까지 OWASP 상위 10대 OSS 위험을 알아보았습니다. SW 공급망 관리를 위한 오픈소스 관리 도구인 Sparrow SCA는 컴포넌트 분석으로 오픈소스 라이선스와 취약점을 식별합니다. 또한 SBOM 관리 기능을 제공해 국제 표준인 SPDX 및 CycloneDX, SWID tag의 형식으로 컴포넌트명과 버전, 공급업체 등의 정보를 포함한 SBOM을 생성할 수 있으며, 전달 받은 SBOM을 업로드하는 것도 가능합니다. 이제 오픈소스 보안도 스패로우와 함께하세요!