우리는 오픈소스 소프트웨어 보안 동원 계획을 받아들일 만큼 성숙해졌을까요?

현재의 경제 상황과 위협 환경 속에서, 저는 평범한 CISO(최고정보보호책임자)들의 처지를 결코 부러워하지 않습니다. 그들은 예산은 줄어들고 감시는 심해지는 어려운 상황 속에서 안전, 규정 준수, 혁신, 그리고 비즈니스 가치를 모두 실현해야 하는 과제를 안고 있습니다. 더 시급한 문제는 모든 조직(및 각 개발 팀)이 서로 다른 보안 성숙도 단계에 머물러 있으며, 모든 조직이 사이버 방어 측면에서 최선의 역량을 발휘할 준비가 되어 있지는 않다는 사실입니다.

지난 몇 년간 사이버 보안 사고가 급증하면서 보안 리더들이 한발 앞서 대응하기가 매우 어려워졌습니다. 커지는 위기 상황에 대한 데이터 기반 통찰을 살펴보면 마치 화약고와 같은 현실이 드러납니다. 2023년에만 330억 건 이상의 기록이 사이버 범죄자들에 의해 탈취될 것이며, 이는 2018년 대비 175% 증가한 수치입니다. 사이버 범죄 비용은 2025년까지 10조 5천억 달러에 이를 것으로 예상되며, 데이터 유출 사고의 평균 비용은 424만 달러까지 치솟았습니다(에퀴팩스나 솔라윈즈와 같은 사례를 보면 이보다 훨씬 더 심각할 수 있음을 알 수 있습니다).

업계 전체가 10년 전만 해도 상상할 수 없었던 강력한 사이버 보안 위협으로부터 우리를 구원해 줄 영웅을 오랫동안 기다려 왔습니다. 우리는 더 많은 보안 전문가가 합류하여 보안 프로그램의 수준을 높여주기를 기다리지만, 이 격차는 쉽게 좁혀지지 않습니다. 우리는 증가하는 위험을 자동화로 해결해 줄 '마법의 탄환' 같은 도구를 기다리지만, 그런 것은 존재하지 않으며 앞으로도 존재할 가능성은 매우 낮습니다. 우리는 다크 사이드와 싸워줄 루크 스카이워커를 기다리고 있는 셈입니다.

다행히도 오픈소스 소프트웨어 보안 동원 계획이라는 형태로 도움(과 희망)이 오고 있습니다. 하지만 우리 모두는 잠시 멈춰 서서, 과연 우리 조직이 최신 방어 전략을 구현할 만큼 충분히 성숙한지, 특히 개발 팀의 지원과 실행이 필수적인 상황에서 우리 개발 팀이 그에 걸맞은 보안 인식과 기술을 갖추고 있는지 솔직하게 평가해 보아야 합니다.

오픈소스 소프트웨어 보안 동원 계획이란 무엇인가?

이 10개 항목으로 구성된 계획은 오픈소스 소프트웨어 재단(OpenSSF)과 리눅스 재단이 백악관 관계자, 최고 CISO들, 그리고 37개 민간 기술 기업의 고위 리더들과 협력하여 주도했습니다. 실행과 자금 지원 양면에서 이루어진 이러한 공동의 지원을 통해 오픈소스 소프트웨어의 보안 표준은 한층 더 강화될 것입니다.

특히 흥미로운 점은 개발자 수준의 기본 교육 및 인증에 집중하고, 내부 소프트웨어 자재 명세서(SBOM) 활동을 간소화하기 위한 조치를 마련했다는 것입니다. 이러한 조치들은 지속적인 효과를 내도록 구현하기가 매우 어렵기로 유명한데, 이는 조직 보안 프로그램의 성장통과 개발자 집단 전반의 보안 성숙도 부족(개발자들의 잘못은 아닙니다) 때문입니다. 개발자들은 더욱 무리해지는 마감 기한 속에서 속도와 코드 양이 최우선시되는 압박감 가득한 환경에 놓여 있습니다. 보안 요구 사항이나 SBOM 유지 관리와 같은 작업을 추가하면서 정작 이를 위한 시간은 늘려주지 않는 것은 시작하기도 전에 실패할 수밖에 없는 방식이며, 안타깝게도 이는 우리가 생각하는 것보다 훨씬 흔한 일입니다.

그럼, 자세히 들여다보겠습니다.

개발자를 위한 보안 인증: 우리는 준비되었는가?

한 가지 확실한 사실은 보안 기술을 갖춘 개발자는 여전히 귀한 인재라는 점입니다. 이는 여러 이유 때문인데, 무엇보다 최근까지도 조직 내 소프트웨어 보안 전략에서 개발자는 고려 대상이 아니었습니다. 여기에 개발자들이 보안을 우선시할 이유가 부족하다는 점(교육이 부적절하거나 전무하고, 시간이 더 걸리며, KPI에 포함되지 않고, 그들의 주된 관심사는 기능 구현이라는 점)까지 더해지면, 개발 팀은 코드 수준에서 보안을 다루거나 현대화된 DevSecOps 중심의 소프트웨어 개발 수명 주기(SDLC)에서 제 역할을 수행할 준비가 되어 있지 않게 됩니다.

오픈소스 소프트웨어 보안 동원 계획의 첫 번째 항목은 개발자 보안 기술을 다루는 것으로, 개발 팀의 보안 성숙도를 높이기 위해 필수적인 “모두를 위한 기본 보안 소프트웨어 개발 교육 및 인증 제공”을 목표로 합니다. 그들은 대학 수준의 소프트웨어 공학 과정에서 보안 코딩이 빠져 있다는 사실을 포함하여 우리가 오랫동안 논의해 온 문제들을 강조합니다. 업계의 현 상태를 바꿀 수 있는 개인과 부서들이 이를 지원하는 것은 매우 고무적인 일이며, 전 세계 소프트웨어의 99%가 최소한 일부 오픈소스 코드를 포함하고 있다는 점을 고려할 때, 이 분야는 개발자 보안 교육을 시작하기에 아주 좋은 출발점입니다.

이 계획은 OpenSSF 보안 소프트웨어 기초 과정과 OWASP 재단의 방대하고 오랜 역사를 지닌 리소스와 같은 권위 있는 자료들을 인용합니다. 이러한 정보 허브는 매우 귀중합니다. 개발자 역량 강화를 위해 이 자료들을 보급하려는 계획에는 공공 및 민간 부문의 광범위한 파트너 네트워크를 결집하고, 교육 기관과 협력하여 오픈소스 보안 개발을 커리큘럼의 핵심 요소로 만드는 작업이 포함됩니다.

보안을 자신의 업무나 우선순위가 아니라고 인식해 온 전 세계 소프트웨어 엔지니어들의 마음을 어떻게 얻을 것인가에 대해, 이 계획은 오픈소스 라이브러리를 유지 관리하는 개발자와 보안 인증의 가치를 깨달아야 하는 현업 엔지니어 모두를 대상으로 하는 보상 및 인정 전략을 상세히 다루고 있습니다.

우리는 경험을 통해 개발자들이 인센티브에 잘 반응하며, 학습 환경에서 진행 상황과 기술 수준을 보여주는 단계별 배지 시스템이 Steam이나 Xbox에서와 마찬가지로 효과적이라는 것을 알고 있습니다.

However, what is of concern is that we’re not addressing one of the core issues, and that is the delivery of learning modules within an organization’s security program. Having worked closely with developers for much of my career, I know how skeptical they are when it comes to tools and training, not to mention anything that looks like it might disrupt work that is priority numero uno. Developer enablement requires them to continually engage with course material, and for this to be successful, it has to make sense in the context of their day-to-day work.

If we consider an established maturity model like the Software Assurance Maturity Model (SAMM), “Education & Guidance” is a core component of the Governace layer, and there is a key focus on developer education. The model in its entirety is vast, and there are progressive steps in reaching higher levels of maturity. However, the initial stages recommend just 1-2 days of formal training for developers, which is hardly enough to scratch the surface of security awareness. Even then, a recent report by the Enterprise Strategy Group (ESG) revealed that less than half of organizations require developers to engage in formal security training more than once a year. Our own research in conjunction with Evans Data revealed that only 29% of developers believe the active practice of writing code free of vulnerabilities should be prioritized. There is a clear disconnect between how education is delivered and received, and how useful it truly is in bringing about security maturity, especially if developers are not seeing value.

소프트웨어 자재 명세서(SBOM): 이 계획은 도입 장벽을 허물 수 있을까?

이 계획이 해결하고자 하는 또 다른 영역은 소프트웨어 자재명세서(SBOM) 생성 및 유지 관리와 관련된 혼란입니다. '모든 곳에 SBOM 적용 — SBOM 도구 및 교육 개선을 통한 도입 촉진'이라는 스트림을 통해 개발자와 조직이 SBOM을 더 쉽게 생성, 업데이트 및 활용하여 보안 성과를 높일 수 있는 방법을 모색하고 있습니다.

현재 대부분의 산업 분야에서 SBOM은 널리 도입되지 않아 보안 위험을 줄이는 잠재력을 충분히 발휘하기 어렵습니다. 이 계획은 SBOM 구성을 위한 핵심 표준을 정의하고, 개발자의 작업 방식에 맞춰 쉽게 생성할 수 있는 도구를 제공하는 훌륭한 전략을 담고 있습니다. 이는 이미 빠른 속도로 소프트웨어를 개발해야 하는 개발자들에게 또 하나의 SDLC 업무 부담을 크게 덜어줄 것입니다.

하지만 우려되는 점은 일반적인 조직에서 보안 책임이 개발자에게 모호하게 다가올 수 있다는 것입니다. 보안의 최종 책임은 보안 팀에 있지만, 개발자의 협력을 얻으려면 그들을 이 여정에 동참시켜야 합니다. 업무와 기대치를 명확히 정의하고, 개발자가 이러한 추가적인 성공 지표를 달성할 수 있도록 충분한 시간을 제공해야 합니다.

오픈소스 소프트웨어(OSS)에서 소프트웨어 생태계 전반으로

오픈소스 소프트웨어 보안 동원 계획은 야심 차고 대담하며, 개발자의 보안 책임을 강화하는 데 꼭 필요한 조치입니다. 강력한 기업들이 '반란군 연합'처럼 힘을 합쳤다는 사실은 우리가 올바른 방향으로 나아가고 있으며, 사이버 보안 인력 부족 문제가 저절로 해결될 것이라는 안일한 생각을 버렸음을 증명합니다.

이 계획은 우리의 새로운 희망이며, 이 체계를 OSS를 넘어 확장하려면 우리 모두의 노력이 필요합니다. 보안 전문가들은 스스로를 돌아보고 자신이 보호해야 할 코드를 작성하는 개발 팀을 면밀히 분석해야 합니다. 현재의 역량과 부족한 점을 솔직하게 평가하고, 철저하고 선제적이며 개발자들에게 실질적인 보안 기술을 전수하는 성숙한 보안 프로그램을 구축해야 합니다. 개발자들이 의미 있게 역량을 갖추기 전까지는 코드 수준의 취약점에 대한 우리의 접근 방식은 여전히 미성숙할 수밖에 없습니다.

‍

>> 실습형 인터랙티브 XSS 챌린지로 팀의 보안 성숙도를 테스트해보세요!