오픈 소스: 오픈 소스를 통한 엔터프라이즈급 보안?

조직은 오픈 소스 코드 솔루션에 점점 더 많이 의존하고 있으며, 이를 인지하지 못하는 경우도 많습니다. 하지만 오픈 소스 코드 보안은 안정적으로 처리되고 있을까요? 대규모 조직은 신뢰할 수 있고 안전한 소프트웨어 솔루션을 활용하는 데 중점을 두는 것이 당연합니다. 가장 유능하고 실제로 가장 안전한 소프트웨어 솔루션은 무료 오픈 소스 소프트웨어인 경우가 많습니다.

조직이 항상 소프트웨어 비용을 지불하는 경우에도 상업적으로 라이선스가 부여된 소프트웨어는 일부 기능을 오픈 소스 라이브러리에 의존하는 경우가 많습니다. 이 XKCD 만화는 이러한 종속성이 어떻게 작동하는지에 대한 강력한 요약입니다..

그러나 오픈 소스 솔루션의 보안을 최종적으로 책임지는 주체가 없는 경우가 많기 때문에 오픈 소스 소프트웨어의 보안에 대한 우려는 타당합니다.

그렇다면 2020년 Linux 재단 설문조사 에서 오픈소스 소프트웨어 보안에 대해 조사한 것은 놀라운 일이 아닙니다. 이 글에서는 해당 설문조사 결과 중 일부를 살펴보겠습니다. 오픈 소스 솔루션이 엔터프라이즈 환경에서 안전한 운영을 제공할 수 있는지 여부라는 중요한 질문의 맥락에서 이러한 결과를 살펴볼 것입니다.

내용:
1. 오픈소스 개발의 원동력은 무엇인가?
2. 오픈소스 개발의 이면에 있는 상업적 필요성
3. 인센티브는 중요하지만, 인센티브를 줄 사람이 없을 수도 있습니다...
4. 오픈소스가 기업에 중요한가?
5. 기업 환경에서의 오픈소스 보급률
6. 보안은 소스 모델에 의해 결정되지 않는다
7. 오픈소스 보안 격차 메우기
8. 소프트웨어 보안을 개선하기 위한 실용적인 방법
9. 오픈소스 보안 강화를 위한 실시간 자동 패치 고려하기
10. 오픈소스 코드를 다른 코드와 마찬가지로 취급하기

오픈소스 개발의 원동력은 무엇인가요?

저희는 상용 비공개 소스 소프트웨어의 개발 원동력이 무엇인지 잘 알고 있습니다. 그것은 순수하고 단순한 이익입니다. 이론적으로 상용 소프트웨어 공급업체는 출시 시 소프트웨어 보안에 시간과 노력을 투자합니다.

또한 공급업체는 일반적으로 코드 릴리스 이후에 발견된 IT 보안 문제에 신속하게 대응합니다. 다시 말하지만, 동기는 간단합니다. 안전한 소프트웨어는 수익성 있는 소프트웨어이며, 소프트웨어 보안이 평판 손상과 수익 감소로 이어질 수 있기 때문에 어떤 상업적 공급업체도 소프트웨어 보안을 소홀히 하고 싶어하지 않습니다.

오픈 소스 소프트웨어의 경우 문제는 조금 더 복잡합니다. 오픈소스 소프트웨어 개발은 일반적으로 상업적 필요에 의해 주도되지 않으며, 오픈소스 리포지토리에 제출한다고 해서 일반적으로 제출에 대한 직접적인 대가가 지급되는 것은 아닙니다.

기여의 동기가 중요한 이유는 소프트웨어 보안에 대한 관리 수준을 보여주기 때문입니다. Linux 재단의 보고서에서는 개발자가 오픈 소스 코드에 기여하는 세 가지 일반적인 이유를 제시했습니다:

• 개발자가 사용하던 오픈 소스 솔루션에서 수정해야 할 문제를 발견했습니다. 또는 개발자가 사용하는 오픈 소스 솔루션에 특정 기능을 추가해야 하는 경우.
• 개발자는 학습 연습으로 오픈소스 코드에 기여하여 자신의 역량을 연습하고 오픈소스 프로젝트에 대해 자세히 알아볼 수 있습니다.
• 일부 개발자에게는 오픈소스 프로젝트에 기여하는 것이 도전적이고 성취감 있는 프로그래밍 작업이라는 단순한 매력이 있습니다.

오픈소스 소프트웨어 보안에 기여하는 것은 목록에서 눈에 띄지 않습니다. 실제로 기여자들은 오픈소스 코드 보안 문제를 해결하는 일이 피곤하고 감사할 줄 모르는 작업.

오픈소스 개발의 이면에 있는 상업적 필요성

Linux 재단의 설문조사에서는 오픈소스 개발의 또 다른 중요한 동인인 상업적 요구사항도 강조했습니다. 설문조사에 따르면 오픈소스 코드에 기여하는 개발자는 대가를 받는 것이 일반적이며, 설문조사에 응답한 개발자의 52%가 오픈소스 프로젝트에 기여한 대가로 돈을 받았다고 답했습니다.

즉, 설문조사에 참여한 응답자의 약 절반이 기관이나 영리 기업 등 어떤 성격의 고용주가 작업 완료에 대한 비용을 지불한다고 답했습니다. 이는 응답자의 많은 비율로, 오픈소스 기여를 주도하는 것은 때때로 상업적 필요라는 사실을 반영합니다.

이러한 요구는 새로운 기능일 수도 있지만, 상업적 조직에서 오픈 소스 코드의 결함을 발견하고 개발자에게 비용을 지불하여 이를 수정하는 경우도 있습니다.

이는 오픈소스 보안에 좋은 징조이지만, 상업적 운영자가 결함을 발견하고 이를 수정할 동기가 없다면 오픈소스 개발자가 오픈소스 소프트웨어 보안을 위해 노력할 동기가 크지 않다는 점을 고려할 때 결함이 수정되지 않을 수도 있음을 시사하기도 합니다.

인센티브는 중요하지만 인센티브를 제공할 사람이 없을 수도 있습니다...

섣부른 판단을 내리려는 것은 아닙니다. 수십억 줄의 오픈 소스 코드가 존재하며, 그 중 상당수는 많은 개발자가 오픈 소스 모델을 좋아해서 순수하게 분석, 코딩, 수정하는 과정에서 아무런 보수 없이 작성된 것입니다.

그럼에도 불구하고 상업적이든 그렇지 않든 인센티브는 보안 버그의 탐지 및 해결을 가속화하는 데 유용하다는 것은 분명합니다.. 하지만 인센티브만으로는 충분하지 않을 수도 있습니다.

일부 오픈소스 결함은 아주 오래된 코드에서 발견될 수 있다는 것을 알고 있습니다. 최근에 발견된 버그는 libcurl 에서 발견된 버그는 수십 년 전의. 문제는 코드를 수정할 적절한 인센티브가 있더라도 이를 수행할 개발자를 찾는 것이 쉽지 않다는 것입니다.

오픈소스 프로젝트는 시간이 지남에 따라 성숙해지며 프로젝트의 기반이 되는 코드가 여전히 일상적으로 사용되더라도 배경에서 사라지게 됩니다. 원래 개발자들이 다른 프로젝트로 옮겨가면서 프로젝트에 기여한 코드의 정확성과 가치를 측정할 수 있는 개발자가 제한되어 개발자를 찾는 데 문제가 생깁니다.

이는 많은 유명 프로젝트가 기여할 수 있는 자격을 갖춘 개발자를 찾는 데 어려움을 겪고 있는 일반적인 문제입니다. Linux Kernel에서도 마찬가지입니다.. 이는 일부 프로젝트가 유료 개발자에게 점점 더 의존하고 있습니다. 보안 문제를 포함한 프로젝트의 주요 측면을 진행하기 위해 점점 더 유료 개발자에게 의존하고 있습니다.

엔터프라이즈에 오픈소스가 중요할까요?

오픈 소스 소프트웨어 보안에는 분명 어느 정도 미묘한 차이가 있지만, 기업 사용자에게는 정말 중요한 문제일까요? 결국 대기업은 보안 소프트웨어에 비용을 지불할 여유가 있습니다.

다시 말하지만, 복잡합니다. 우선, 오픈 소스 소프트웨어의 기능은 상용 소프트웨어의 기능을 능가할 수 있으며, 이러한 이유로 기업은 해당 솔루션이 상용 조건으로 제공되더라도 오픈 소스 솔루션을 선택할 수 있습니다.

또한 상용 소프트웨어에는 라이브러리 등 오픈 소스 소프트웨어의 요소가 포함되어 있는 경우가 많습니다. 예를 들어 상용 솔루션에 종종 포함되는 일반적으로 사용되는 도구이지만 그 자체로 최근에 발견된 버그의 피해자였던 의 희생양이 되었습니다.

또는 보안 결함이 발견되어 큰 파장을 일으켰던 개방형 SSL 솔루션인 OpenSSL도 있습니다. 좀처럼 사라지지 않는 보안 결함.

엔터프라이즈 환경에서의 오픈소스 보급률

요점은 상업적으로 라이선스가 부여된 소프트웨어에만 의존하는 회사도 어딘가에 오픈 소스 코드에 의존하고 있을 가능성이 높다는 것입니다.

이는 단순한 주장이 아닙니다. 널리 인용되는 Gartner 연구에 따르면 다음과 같은 결과가 나옵니다. 기업 운영의 95%가 오픈 소스 소프트웨어를 사용하고 있습니다. 오픈 소스 소프트웨어를 사용하고 있다고 합니다. 여기에는 여러 가지 이유가 있겠지만, 비용을 절감하려는 노력 때문인 경우는 거의 없습니다.

예, 오픈 소스 소프트웨어는 원칙적으로 무료이지만, 대규모 조직은 일반적으로 집중적인 개발 노력의 일환으로 오픈 소스 솔루션에 의존하고 오픈 소스 소프트웨어를 값비싼 지원 계약에 묶어두는 경우가 많기 때문에 엔터프라이즈급 솔루션이 무료인 경우는 거의 없습니다.

기업이 명시적으로 '무료' 오픈 소스 소프트웨어를 선택하는 이유는 많은 경우 오픈 소스 코드가 가장 뛰어난 솔루션을 제공할 수 있기 때문입니다.

마지막으로, 이전 섹션에서 설명한 것처럼 오픈 소스 코드는 상용 폐쇄형 소스 솔루션에도 뿌리내리고 있습니다. 실제로 오픈 소스 코드는 조직이 배포된 솔루션의 소스에 관계없이 솔루션에 오픈 코드가 사용되었다고 기본적으로 간주할 수 있을 정도로 널리 퍼져 있다고 할 수 있습니다.

보안은 소스 모델에 의해 결정되지 않습니다.

오픈 소스 코드는 공개되어 있으므로 이론적으로는 더 많은 사람들이 이 코드를 볼 수 있고 볼 것이므로 결함을 발견할 기회가 더 많습니다. 그러나 위에서 지적한 OpenSSL 버그와 같은 결함은 발견되기까지 수년이 걸리기 때문에 현실은 다를 수 있습니다.

그리고 앞서 설명한 것처럼 오픈소스 개발자가 오픈소스 코드의 결함을 찾아내려는 동기가 제한적일 수 있습니다.

동시에, 비공개 소스 상용 소프트웨어가 영리 동기에 의해 개발되었다고 해서 오픈 소스 코드보다 더 안전하다는 의미는 아닙니다. 공급업체가 보안 연구원을 배치하여 코드에 결함이 있는지 검사한다는 보장이 없으며, 프로젝트 팀이 마감일까지 프로젝트를 완료하기 위해 코딩을 서두를 위험이 항상 존재합니다. 게다가 일단 코드가 완성되면 다시는 검토되지 않을 수도 있습니다.

따라서 이론적으로는 오픈 소스 코드가 더 많은 조사를 받을 수 있고 따라서 더 안전하지만, 올바른 사람이 코드를 검토하고 있다는 보장은 없습니다. 반대로 상용 소프트웨어 공급업체가 보안 책임을 진지하게 받아들인다는 보장도 없습니다.

무엇보다도 개발자는 대가를 받든 받지 않든, 개발자에게 대가를 지불하는 주체가 누구든 항상 간과하고 실수를 저지르기 마련입니다.

오픈소스 보안 격차 해소

조직에서 오픈소스 보안이 상용 라이선스 소프트웨어의 보안보다 더 나쁘다고 생각하든, 더 좋다고 생각하든 상관없습니다. 사실 오픈 소스 소프트웨어 보안에는 공백이 존재하며 대부분의 조직이 어떤 식으로든 오픈 소스 소프트웨어에 의존하고 있습니다. 따라서 오픈 소스 소프트웨어 보안은 중요합니다.

예, 소프트웨어 보안은 조직의 책임이며, 다음 섹션에서 몇 가지 검증된 방법을 다룰 것입니다. 하지만 오픈소스 커뮤니티와 오픈소스 소프트웨어 사용자는 오픈소스 보안의 첫 번째 단계를 밟아야 합니다. Linux 재단 보고서에서는 이와 관련하여 몇 가지 중요한 제안을 했습니다:

• 개발자가 가장 중요한 오픈 소스 코드에 대한 정기적인 감사를 포함하여 오픈 소스 소프트웨어 보안을 위해 노력할 동기를 가질 수 있도록 자금이 우선적으로 지원되어야 합니다.
• Linux 재단에서는 반복적으로 취약한 것으로 드러난 오픈 소스 코드는 처음부터 다시 작성해야 한다고 제안합니다. 예를 들어, 메모리 안전하지 않은 언어(예: C 또는 C++)에서 메모리 안전 언어(예: Python 또는 JavaScript)로 코드를 변환하는 것이 좋습니다.
• 자금 지원 외에도 개발자에게는 배지 프로그램과 및 멘토링을 통해 오픈소스 커뮤니티에서 소프트웨어 보안의 중요성을 높이는 데 도움을 주어야 합니다.
• 마지막으로 Linux 재단은 상용 공급업체가 오픈소스 개발자를 고용할 때 소프트웨어 보안 지식을 전제 조건으로 삼고, 개발자를 교육하는 지속적인 교육을 제공하여 안전한 소프트웨어 개발을 위한 지원 기반을 제공해야 한다고 제안했습니다.

장기적으로 오픈 소스 소프트웨어가 지금보다 더 안전해지려면 모든 당사자가 보안에 다시 집중하는 동시에 코드 작업을 하는 개발자에게 적절한 인센티브를 제공하는 것이 유일한 방법입니다. 현재와 같은 인센티브만으로는 충분하지 않습니다.

소프트웨어 보안을 개선하기 위한 실용적인 방법

오픈 소스 소프트웨어 보안에는 공백이 있지만 이러한 공백을 해결하는 데 도움이 되는 여러 도구가 있습니다. 또한 궁극적으로 소프트웨어 보안은 조직의 책임입니다. 다음 사항을 참고하시기 바랍니다:

• 다단계 인증(MFA) 및 강력한 비밀번호 보안을 포함한 모범 사례를 일관되게 적용하세요. 자격증명 관리와 엄격한 권한 관리도 중요합니다.
• 모니터링과 테스트는 침입자와 보안 프로필의 결함을 식별하는 데 도움이 되므로 심각한 결과로 이어지기 전에 침입을 차단할 수 있습니다.
• 어떤 도구에 의존하고 있는지 파악하고, 실제 위험은 눈에 보이지 않는 경우가 많으므로 라이브러리 및 종속성을 포함한 기본 구성 요소도 파악하세요.

그러나 소프트웨어 보안에서 가장 중요한 요소는 단연 패치입니다. 지속적이고 포괄적인 패치는 알려진 취약성으로부터 솔루션을 보호하며, 무료 소프트웨어를 사용하든 상용 라이선스 소프트웨어를 사용하든 동일하게 효과적입니다.

하지만 지속적으로 패치를 적용하는 것은 쉽지 않습니다. 패치 작업은 시간이 많이 소요될 수 있으며, 우선순위가 가장 높은 취약점만 패치하는 경우가 많아 다른 많은 결함이 노출될 수 있습니다. 패치를 적용하려면 시스템을 재시작하거나 재부팅해야 하는 경우가 많기 때문에 가용성을 위해 일정에 맞춰 패치를 적용하지 않고 중요한 취약점이 있는 경우에만 패치를 적용하는 경우가 많습니다.

오픈소스 보안을 강화하기 위해 실시간 자동 패치 적용 고려하기

패치는 매우 중요하지만 효과적이지 않은 경우가 많습니다. TuxCare의 자동화된 실시간 Kernel 패치는 서비스 중단 없이 서버가 취약성에 대해 지속적으로 패치되도록 보장하여 오픈 소스 보안의 큰 격차를 메워줍니다.

오픈소스 개발팀과 개인이 기여하는 소프트웨어에는 자신이 기여한 소프트웨어를 완벽하게 보호하려는 동기부여와 인센티브가 부족합니다. 그리고 우리가 알다시피 실수는 사람이 하는 것이기 때문에 실수는 항상 발생합니다.

Linux 재단은 오픈소스 보안 문제를 개선할 수 있는 몇 가지 확실한 권장 사항을 발표했지만, 당분간은 계속해서 결함이 코드에 기록되어 발견되고 패치되어야 할 것입니다. 패치가 중요합니다.

다른 코드와 마찬가지로 오픈 소스 코드 다루기

결론적으로, 기업 사용자는 거의 항상 라이브러리를 통해 직접 또는 간접적으로 오픈 소스 코드에 의존하고 있습니다. 오픈 소스 코드가 본질적으로 안전하지 않은 것은 아니지만, 오픈 소스 코드에는 고유한 보안 고려 사항이 있습니다.

인식이 첫 번째 단계이며, 실시간 패치는 유용한 지원 조치가 될 수 있습니다. 다시 말해, 오픈 소스 코드는 상용 공급업체의 비공개 소스 코드만큼이나 안전할 수 있습니다. 이는 모두 조직의 보안 태세에 달려 있습니다.