우리는 오픈소스 소프트웨어 보안 동원 계획에 충분히 성숙했는가?
현재의 경제 상황과 위협 환경에서 저는 확실히 평균적인 CISO가 부럽지 않습니다.이들은 안전, 규정 준수, 혁신 및 비즈니스 가치를 제공하는 동시에 예산 축소와 조사 강화로 힘겨운 싸움에 직면해 있습니다.아마도 더 시급한 것은 모든 조직 (및 해당 개발 팀) 이 각기 다른 보안 성숙도 단계에 있으며, 모든 조직이 사이버 방어 측면에서 최선을 다할 준비가 되어 있지는 않다는 사실일 것입니다.
지난 몇 년간 사이버 보안 사고가 심화되면서 보안 리더가 한 발 앞서 나가는 것이 상당히 어려워졌습니다.날로 커져가는 곤경에 대한 일부 데이터 기반 인사이트를 살펴보는 것만으로도 화약고 같은 것을 알 수 있습니다. 그 이상입니다. 2023년에만 330억 개의 기록이 사이버 범죄자에 의해 도난당할 것입니다., 2018년보다 175% 증가했습니다.더 사이버 범죄 비용은 2025년까지 10조 5천억 달러에 달할 것으로 예상됩니다, 데이터 침해로 인한 평균 비용은 다음과 같이 치솟았습니다. 424만 달러 (하지만 Equifax나 Solar Winds 같은 사건만 살펴봐야 가능하다는 것을 알 수 있습니다. 훨씬 더 나빠요).
업계에서는 10년 전만 해도 가능하다고 생각했던 것보다 더 강력한 힘을 가진 것처럼 보이는 사이버 보안 악당으로부터 우리를 구출해 줄 영웅을 기다리느라 오랜 시간을 보냈습니다.더 많은 사이버 보안 전문가들이 참여하여 우리를 더 높은 수준의 보안 프로그램으로 끌어올리기를 기다리고 있지만, 그 격차를 좁힐 수는 없습니다.날로 커지는 위험으로부터 우리를 자동화할 수 있는 은총알 툴링 솔루션을 기다리고 있습니다. 하지만 그런 솔루션은 그렇지 않으며 존재할 가능성도 거의 없습니다.다크 사이드에 맞서 싸울 수 있게 도와줄 루크 스카이워커를 기다리고 있습니다.
결과적으로 도움 (그리고 희망) 은 다음과 같은 형태로 다가오고 있습니다. 오픈소스 소프트웨어 보안 동원 계획.그러나 우리 모두는 특히 개발팀의 지원과 실행이 필요한 경우 가장 뛰어난 최신 방어 전략을 구현할 수 있을 만큼 조직의 성숙도가 높은지, 그리고 개발팀이 적절한 수준의 보안 인식과 기술을 갖추고 있는지 재고하고 정직하게 평가해야 합니다.
오픈 소스 소프트웨어 보안 동원 계획이란?
이 10개 항목의 계획은 오픈소스 소프트웨어 재단 (OpenSSF) 과 리눅스 재단이 백악관 관계자, 최고 CISO 및 37개 민간 기술 기업의 다른 고위 지도자들과 함께 주도했습니다.이러한 실천과 자금 지원 모두의 결합으로 오픈소스 소프트웨어의 보안 표준은 훨씬 더 강력해질 것입니다.
특히 흥미로운 점은 개발자 수준의 기본 교육 및 인증과 내부 소프트웨어 재료 명세서 (SBOM) 활동을 간소화하기 위한 조치에 초점을 맞추고 있다는 것입니다.이 두 가지 방법 모두 지속적인 영향을 미치는 방식으로 구현하기가 매우 어렵기로 악명이 높은데, 이는 부분적으로 조직 보안 프로그램 내에서의 골칫거리와 개발 집단 간의 전반적인 보안 성숙도 결여에 기인할 수 있습니다.이들은 날로 불합리한 마감 시한에 직면하여 빠른 속도로 코드 볼륨이 지배하는 압력 쿠커 환경에 처해 있습니다.사용 가능한 시간을 늘리지 않고 보안 요청 및 SBOM 유지 관리의 형태로 더 많은 작업을 추가하는 것은 시작하기도 전에 실패한 레시피이며 안타깝게도 예상보다 더 흔합니다.
자, 그럼 후드 아래를 살펴보죠.
개발자를 위한 보안 인증: 아직 완료되지 않았나요?
우리가 확실히 알고 있는 것이 하나 있다면 보안 숙련된 개발자 여전히 희귀한 상품입니다.이것이 현실인 데에는 여러 가지 이유가 있습니다. 즉, 최근까지 조직 내 소프트웨어 보안 전략에 있어 개발자는 고려의 대상이 아니었기 때문입니다.여기에 더해 개발자들은 보안에 우선순위를 둘 이유가 별로 없고 (교육이 부적절하거나 존재하지 않으며, 시간이 더 오래 걸리고, KPI에 포함되지 않으며, 주요 관심사는 자신이 가장 잘하는 일인 기능 구축입니다), 개발팀은 코드 수준에서 보안을 진정으로 다루거나 현대화된 DevSecops 중심의 SDLC (소프트웨어 개발 라이프사이클) 에서 역할을 수행할 준비가 제대로 되어 있지 않습니다.
오픈 소스 소프트웨어 보안 동원 계획을 살펴보면, 10개 항목 계획의 첫 번째 흐름은 개발 팀의 보안 성숙도를 구축하는 데 필수적인 “모두에게 기본 보안 소프트웨어 개발 교육 및 인증 제공”인 개발자 보안 기술을 다루는 것입니다.여기에서는 대부분의 고등 교육 과정 중 시큐어 코딩이 MIA라는 사실을 비롯하여 지금까지 논의한 문제들을 중점적으로 다룹니다.업계의 현상 유지를 바꿀 수 있는 개인과 부서가 이를 지원한다는 것은 매우 고무적인 일입니다. 그리고 적어도 다음을 포함하는 전세계 소프트웨어의 99% 약간 오픈 소스 코드, 이 개발 영역은 보안 분야의 개발자 교육에 집중하기 시작하기에 좋은 곳입니다.
이 계획은 다음과 같은 존경받는 자원을 인용합니다. OpenSSF 보안 소프트웨어 기초 교육 과정 및 에서 제공하는 광범위하고 오랜 리소스 OWASP 재단.이러한 정보 허브는 매우 중요합니다.개발자 역량 향상을 위해 이러한 자료를 제공하기 위해 제안된 출시에는 교육 기관과 협력하여 오픈 소스 보안 개발을 커리큘럼의 주요 특징으로 삼는 것 외에도 공공 부문과 민간 부문의 광범위한 파트너 네트워크를 통합하는 것이 포함됩니다.
보안 강화를 업무나 우선 순위가 아닌 것으로 간주한 전 세계 소프트웨어 엔지니어들의 마음을 사로잡을 수 있는 방법에 대해 이 계획에는 오픈 소스 라이브러리를 유지 관리하는 개발자와 보안 인증의 가치를 파악해야 하는 실무 엔지니어 모두를 대상으로 하는 보상 및 인정 전략이 자세히 설명되어 있습니다.
우리는 경험을 통해 개발자들이 인센티브에 잘 반응한다는 것을 알고 있으며, 진행 상황과 기술을 보여주는 계층화된 배지 시스템은 Steam이나 Xbox와 같은 제품에서와 마찬가지로 학습 환경에서도 잘 작동한다는 것을 알고 있습니다.
하지만 우려되는 점은 우리가 핵심 문제 중 하나를 다루고 있지 않다는 것입니다. 바로 조직의 보안 프로그램 내에서 학습 모듈을 제공하는 것입니다.커리어 대부분을 개발자들과 긴밀하게 협력해 왔기 때문에 개발자들이 툴과 교육에 대해 얼마나 회의적인지 잘 알고 있습니다. 최우선 과제인 작업에 지장을 줄 수 있는 것처럼 보이는 것은 말할 것도 없고요.개발자 지원을 위해서는 교육 과정 자료를 지속적으로 활용해야 하는데, 이 과정이 성공하려면 일상 업무의 맥락에서 이해가 되어야 합니다.
다음과 같은 확립된 성숙도 모델을 고려하면 소프트웨어 보증 성숙도 모델 (SAMM), “교육 및 지침”은 거버넌스 계층의 핵심 구성 요소이며 개발자 교육에 중점을 둡니다.이 모델은 전체적으로 방대하며, 성숙도를 높이기 위한 점진적인 단계들이 있습니다.그러나 초기 단계에서는 개발자에게 1~2일의 공식 교육만 권장하는데, 이는 보안 인식의 일면을 파헤치기에는 턱없이 부족합니다.그때도 최근 보고서 엔터프라이즈 전략 그룹 (ESG) 에 따르면 개발자에게 1년에 한 번 이상 정식 보안 교육에 참여하도록 요구하는 조직은 절반 미만인 것으로 나타났습니다.우리의 자체 연구 에반스 데이터 (Evans Data) 와 연계하여 개발자의 29% 만이 코드 작성의 능동적 관행을 믿고 있는 것으로 나타났습니다. 취약성이 있습니다 우선 순위를 정해야 합니다.교육을 제공하고 받는 방식과 교육이 보안 성숙도를 높이는 데 실제로 얼마나 유용한지 간에는 분명한 차이가 있습니다. 특히 개발자가 가치를 보지 못하는 경우에는 더욱 그렇습니다.
소프트웨어 BOM: 이 계획이 채택의 장벽을 허물고 있습니까?
계획에서 해결하고자 하는 또 다른 영역은 SBOM (Software Bill of Materials) 생성 및 유지 관리와 관련하여 자주 발생하는 재난입니다. “SBOM Everywhere — 채택을 촉진하기 위한 SBOM 도구 및 교육 개선” 스트림에서는 개발자와 조직이 SBOM을 보다 쉽게 생성, 업데이트 및 사용하여 더 나은 보안 결과를 도출할 수 있는 방법을 모색하고 있습니다.
현재 SBOM은 대부분의 업종에서 널리 채택되지 않아 보안 위험을 줄이는 데 있어 SBOM의 잠재력을 실현하기가 어렵습니다.이 계획에는 SBOM 공식화를 위한 주요 표준을 정의하는 훌륭한 전략과 개발자의 작업 방식에 맞게 쉽게 만들 수 있는 도구가 포함되어 있습니다.이러한 기능만으로도 이미 수요의 속도로 소프트웨어를 개발하기 위해 많은 시간을 투자하고 있는 개발자들이 또 다른 SDLC 작업을 수행해야 하는 부담을 줄이는 데 큰 도움이 될 것입니다.
하지만 제가 걱정하는 것은 일반적인 조직에서는 보안 책임이 개발자에게 매우 애매한 부분이 될 수 있다는 것입니다.보안 책임자는 누구인가요?궁극적으로는 보안팀의 몫이지만, 도움을 받으려면 개발자를 참여시켜야 합니다.작업과 기대치를 명확하게 정의해야 하며, 성공을 위한 이러한 추가 조치를 취할 시간이 필요합니다.
OSS에서 다른 소프트웨어 세계로
오픈 소스 소프트웨어 보안 동원 계획은 야심차고 대담하며 보안에 대한 개발자의 책임을 강화하는 데 꼭 필요한 것입니다.강력한 플레이어들이 한데 모인 “반란군 동맹”이 필요했지만, 이는 사이버 보안 기술 격차가 마법처럼 저절로 해결될 것이라는 생각을 뒤로하고 우리가 올바른 방향으로 나아가고 있다는 증거로 작용합니다.
이것이 우리의 새로운 희망이며, OSS를 넘어 이 구조를 발전시키려면 우리 모두가 필요할 것입니다.하지만 보안 전문가는 자신의 내면을 들여다보고 보호해야 하는 코드를 개발하는 개발 팀을 분석해야 합니다.이들은 현재 역량과 부족한 부분을 정직하게 평가해야 하며, 개발 집단에 진정한 보안 기술을 전수하는 프로그램을 철저하고 사전 예방적이며 포괄적으로 완성된 후기 단계 상태로 만들기 위해 노력해야 합니다.이러한 기능이 의미 있게 활성화되기 전까지는 코드 수준의 취약점에 대한 우리의 접근 방식이 아직 조금 미숙할 수 있습니다.
>> 실무 인터랙티브를 통해 팀의 보안 성숙도를 테스트하세요 XSS 챌린지!
오픈 소스 소프트웨어 보안 동원 계획은 개발자 주도 보안을 위한 긍정적인 단계입니다.하지만 우리 모두 최신의 가장 뛰어난 방어 전략을 구현할 수 있을 만큼 조직의 성숙도가 높은지, 그리고 개발 팀이 적절한 수준의 보안 인식과 기술을 갖추고 있는지 재고하고 정직하게 평가해야 합니다.
最高経営責任者（CEO）、会長、および共同設立者
セキュアコードウォリアーは、ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先とする文化を組織に根付かせるために存在します。AppSec管理者、開発者、CISO、あるいはセキュリティに関わるあらゆる立場の方々に対し、組織が安全でないコードに関連するリスクを軽減できるよう支援します。
デモ予約
最高経営責任者（CEO）、会長、および共同設立者
Pieter Danhieuxは、セキュリティコンサルタントとして12年以上の経験を持ち、SANSの主席講師として8年間、組織、システム、個人をターゲットにしてセキュリティの弱点を評価する方法に関する攻撃的なテクニックを教えている、世界的に有名なセキュリティエキスパートです。2016年には、オーストラリアで最もクールな技術者の一人として認められ（Business Insider）、Cyber Security Professional of the Yearを受賞（AISA - Australian Information Security Association）、GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA認定を保有している。
현재의 경제 상황과 위협 환경에서 저는 확실히 평균적인 CISO가 부럽지 않습니다.이들은 안전, 규정 준수, 혁신 및 비즈니스 가치를 제공하는 동시에 예산 축소와 조사 강화로 힘겨운 싸움에 직면해 있습니다.아마도 더 시급한 것은 모든 조직 (및 해당 개발 팀) 이 각기 다른 보안 성숙도 단계에 있으며, 모든 조직이 사이버 방어 측면에서 최선을 다할 준비가 되어 있지는 않다는 사실일 것입니다.
지난 몇 년간 사이버 보안 사고가 심화되면서 보안 리더가 한 발 앞서 나가는 것이 상당히 어려워졌습니다.날로 커져가는 곤경에 대한 일부 데이터 기반 인사이트를 살펴보는 것만으로도 화약고 같은 것을 알 수 있습니다. 그 이상입니다. 2023년에만 330억 개의 기록이 사이버 범죄자에 의해 도난당할 것입니다., 2018년보다 175% 증가했습니다.더 사이버 범죄 비용은 2025년까지 10조 5천억 달러에 달할 것으로 예상됩니다, 데이터 침해로 인한 평균 비용은 다음과 같이 치솟았습니다. 424만 달러 (하지만 Equifax나 Solar Winds 같은 사건만 살펴봐야 가능하다는 것을 알 수 있습니다. 훨씬 더 나빠요).
업계에서는 10년 전만 해도 가능하다고 생각했던 것보다 더 강력한 힘을 가진 것처럼 보이는 사이버 보안 악당으로부터 우리를 구출해 줄 영웅을 기다리느라 오랜 시간을 보냈습니다.더 많은 사이버 보안 전문가들이 참여하여 우리를 더 높은 수준의 보안 프로그램으로 끌어올리기를 기다리고 있지만, 그 격차를 좁힐 수는 없습니다.날로 커지는 위험으로부터 우리를 자동화할 수 있는 은총알 툴링 솔루션을 기다리고 있습니다. 하지만 그런 솔루션은 그렇지 않으며 존재할 가능성도 거의 없습니다.다크 사이드에 맞서 싸울 수 있게 도와줄 루크 스카이워커를 기다리고 있습니다.
결과적으로 도움 (그리고 희망) 은 다음과 같은 형태로 다가오고 있습니다. 오픈소스 소프트웨어 보안 동원 계획.그러나 우리 모두는 특히 개발팀의 지원과 실행이 필요한 경우 가장 뛰어난 최신 방어 전략을 구현할 수 있을 만큼 조직의 성숙도가 높은지, 그리고 개발팀이 적절한 수준의 보안 인식과 기술을 갖추고 있는지 재고하고 정직하게 평가해야 합니다.
오픈 소스 소프트웨어 보안 동원 계획이란?
이 10개 항목의 계획은 오픈소스 소프트웨어 재단 (OpenSSF) 과 리눅스 재단이 백악관 관계자, 최고 CISO 및 37개 민간 기술 기업의 다른 고위 지도자들과 함께 주도했습니다.이러한 실천과 자금 지원 모두의 결합으로 오픈소스 소프트웨어의 보안 표준은 훨씬 더 강력해질 것입니다.
특히 흥미로운 점은 개발자 수준의 기본 교육 및 인증과 내부 소프트웨어 재료 명세서 (SBOM) 활동을 간소화하기 위한 조치에 초점을 맞추고 있다는 것입니다.이 두 가지 방법 모두 지속적인 영향을 미치는 방식으로 구현하기가 매우 어렵기로 악명이 높은데, 이는 부분적으로 조직 보안 프로그램 내에서의 골칫거리와 개발 집단 간의 전반적인 보안 성숙도 결여에 기인할 수 있습니다.이들은 날로 불합리한 마감 시한에 직면하여 빠른 속도로 코드 볼륨이 지배하는 압력 쿠커 환경에 처해 있습니다.사용 가능한 시간을 늘리지 않고 보안 요청 및 SBOM 유지 관리의 형태로 더 많은 작업을 추가하는 것은 시작하기도 전에 실패한 레시피이며 안타깝게도 예상보다 더 흔합니다.
자, 그럼 후드 아래를 살펴보죠.
개발자를 위한 보안 인증: 아직 완료되지 않았나요?
우리가 확실히 알고 있는 것이 하나 있다면 보안 숙련된 개발자 여전히 희귀한 상품입니다.이것이 현실인 데에는 여러 가지 이유가 있습니다. 즉, 최근까지 조직 내 소프트웨어 보안 전략에 있어 개발자는 고려의 대상이 아니었기 때문입니다.여기에 더해 개발자들은 보안에 우선순위를 둘 이유가 별로 없고 (교육이 부적절하거나 존재하지 않으며, 시간이 더 오래 걸리고, KPI에 포함되지 않으며, 주요 관심사는 자신이 가장 잘하는 일인 기능 구축입니다), 개발팀은 코드 수준에서 보안을 진정으로 다루거나 현대화된 DevSecops 중심의 SDLC (소프트웨어 개발 라이프사이클) 에서 역할을 수행할 준비가 제대로 되어 있지 않습니다.
오픈 소스 소프트웨어 보안 동원 계획을 살펴보면, 10개 항목 계획의 첫 번째 흐름은 개발 팀의 보안 성숙도를 구축하는 데 필수적인 “모두에게 기본 보안 소프트웨어 개발 교육 및 인증 제공”인 개발자 보안 기술을 다루는 것입니다.여기에서는 대부분의 고등 교육 과정 중 시큐어 코딩이 MIA라는 사실을 비롯하여 지금까지 논의한 문제들을 중점적으로 다룹니다.업계의 현상 유지를 바꿀 수 있는 개인과 부서가 이를 지원한다는 것은 매우 고무적인 일입니다. 그리고 적어도 다음을 포함하는 전세계 소프트웨어의 99% 약간 오픈 소스 코드, 이 개발 영역은 보안 분야의 개발자 교육에 집중하기 시작하기에 좋은 곳입니다.
이 계획은 다음과 같은 존경받는 자원을 인용합니다. OpenSSF 보안 소프트웨어 기초 교육 과정 및 에서 제공하는 광범위하고 오랜 리소스 OWASP 재단.이러한 정보 허브는 매우 중요합니다.개발자 역량 향상을 위해 이러한 자료를 제공하기 위해 제안된 출시에는 교육 기관과 협력하여 오픈 소스 보안 개발을 커리큘럼의 주요 특징으로 삼는 것 외에도 공공 부문과 민간 부문의 광범위한 파트너 네트워크를 통합하는 것이 포함됩니다.
보안 강화를 업무나 우선 순위가 아닌 것으로 간주한 전 세계 소프트웨어 엔지니어들의 마음을 사로잡을 수 있는 방법에 대해 이 계획에는 오픈 소스 라이브러리를 유지 관리하는 개발자와 보안 인증의 가치를 파악해야 하는 실무 엔지니어 모두를 대상으로 하는 보상 및 인정 전략이 자세히 설명되어 있습니다.
우리는 경험을 통해 개발자들이 인센티브에 잘 반응한다는 것을 알고 있으며, 진행 상황과 기술을 보여주는 계층화된 배지 시스템은 Steam이나 Xbox와 같은 제품에서와 마찬가지로 학습 환경에서도 잘 작동한다는 것을 알고 있습니다.
하지만 우려되는 점은 우리가 핵심 문제 중 하나를 다루고 있지 않다는 것입니다. 바로 조직의 보안 프로그램 내에서 학습 모듈을 제공하는 것입니다.커리어 대부분을 개발자들과 긴밀하게 협력해 왔기 때문에 개발자들이 툴과 교육에 대해 얼마나 회의적인지 잘 알고 있습니다. 최우선 과제인 작업에 지장을 줄 수 있는 것처럼 보이는 것은 말할 것도 없고요.개발자 지원을 위해서는 교육 과정 자료를 지속적으로 활용해야 하는데, 이 과정이 성공하려면 일상 업무의 맥락에서 이해가 되어야 합니다.
다음과 같은 확립된 성숙도 모델을 고려하면 소프트웨어 보증 성숙도 모델 (SAMM), “교육 및 지침”은 거버넌스 계층의 핵심 구성 요소이며 개발자 교육에 중점을 둡니다.이 모델은 전체적으로 방대하며, 성숙도를 높이기 위한 점진적인 단계들이 있습니다.그러나 초기 단계에서는 개발자에게 1~2일의 공식 교육만 권장하는데, 이는 보안 인식의 일면을 파헤치기에는 턱없이 부족합니다.그때도 최근 보고서 엔터프라이즈 전략 그룹 (ESG) 에 따르면 개발자에게 1년에 한 번 이상 정식 보안 교육에 참여하도록 요구하는 조직은 절반 미만인 것으로 나타났습니다.우리의 자체 연구 에반스 데이터 (Evans Data) 와 연계하여 개발자의 29% 만이 코드 작성의 능동적 관행을 믿고 있는 것으로 나타났습니다. 취약성이 있습니다 우선 순위를 정해야 합니다.교육을 제공하고 받는 방식과 교육이 보안 성숙도를 높이는 데 실제로 얼마나 유용한지 간에는 분명한 차이가 있습니다. 특히 개발자가 가치를 보지 못하는 경우에는 더욱 그렇습니다.
소프트웨어 BOM: 이 계획이 채택의 장벽을 허물고 있습니까?
계획에서 해결하고자 하는 또 다른 영역은 SBOM (Software Bill of Materials) 생성 및 유지 관리와 관련하여 자주 발생하는 재난입니다. “SBOM Everywhere — 채택을 촉진하기 위한 SBOM 도구 및 교육 개선” 스트림에서는 개발자와 조직이 SBOM을 보다 쉽게 생성, 업데이트 및 사용하여 더 나은 보안 결과를 도출할 수 있는 방법을 모색하고 있습니다.
현재 SBOM은 대부분의 업종에서 널리 채택되지 않아 보안 위험을 줄이는 데 있어 SBOM의 잠재력을 실현하기가 어렵습니다.이 계획에는 SBOM 공식화를 위한 주요 표준을 정의하는 훌륭한 전략과 개발자의 작업 방식에 맞게 쉽게 만들 수 있는 도구가 포함되어 있습니다.이러한 기능만으로도 이미 수요의 속도로 소프트웨어를 개발하기 위해 많은 시간을 투자하고 있는 개발자들이 또 다른 SDLC 작업을 수행해야 하는 부담을 줄이는 데 큰 도움이 될 것입니다.
하지만 제가 걱정하는 것은 일반적인 조직에서는 보안 책임이 개발자에게 매우 애매한 부분이 될 수 있다는 것입니다.보안 책임자는 누구인가요?궁극적으로는 보안팀의 몫이지만, 도움을 받으려면 개발자를 참여시켜야 합니다.작업과 기대치를 명확하게 정의해야 하며, 성공을 위한 이러한 추가 조치를 취할 시간이 필요합니다.
OSS에서 다른 소프트웨어 세계로
오픈 소스 소프트웨어 보안 동원 계획은 야심차고 대담하며 보안에 대한 개발자의 책임을 강화하는 데 꼭 필요한 것입니다.강력한 플레이어들이 한데 모인 “반란군 동맹”이 필요했지만, 이는 사이버 보안 기술 격차가 마법처럼 저절로 해결될 것이라는 생각을 뒤로하고 우리가 올바른 방향으로 나아가고 있다는 증거로 작용합니다.
이것이 우리의 새로운 희망이며, OSS를 넘어 이 구조를 발전시키려면 우리 모두가 필요할 것입니다.하지만 보안 전문가는 자신의 내면을 들여다보고 보호해야 하는 코드를 개발하는 개발 팀을 분석해야 합니다.이들은 현재 역량과 부족한 부분을 정직하게 평가해야 하며, 개발 집단에 진정한 보안 기술을 전수하는 프로그램을 철저하고 사전 예방적이며 포괄적으로 완성된 후기 단계 상태로 만들기 위해 노력해야 합니다.이러한 기능이 의미 있게 활성화되기 전까지는 코드 수준의 취약점에 대한 우리의 접근 방식이 아직 조금 미숙할 수 있습니다.
>> 실무 인터랙티브를 통해 팀의 보안 성숙도를 테스트하세요 XSS 챌린지!
현재의 경제 상황과 위협 환경에서 저는 확실히 평균적인 CISO가 부럽지 않습니다.이들은 안전, 규정 준수, 혁신 및 비즈니스 가치를 제공하는 동시에 예산 축소와 조사 강화로 힘겨운 싸움에 직면해 있습니다.아마도 더 시급한 것은 모든 조직 (및 해당 개발 팀) 이 각기 다른 보안 성숙도 단계에 있으며, 모든 조직이 사이버 방어 측면에서 최선을 다할 준비가 되어 있지는 않다는 사실일 것입니다.
지난 몇 년간 사이버 보안 사고가 심화되면서 보안 리더가 한 발 앞서 나가는 것이 상당히 어려워졌습니다.날로 커져가는 곤경에 대한 일부 데이터 기반 인사이트를 살펴보는 것만으로도 화약고 같은 것을 알 수 있습니다. 그 이상입니다. 2023년에만 330억 개의 기록이 사이버 범죄자에 의해 도난당할 것입니다., 2018년보다 175% 증가했습니다.더 사이버 범죄 비용은 2025년까지 10조 5천억 달러에 달할 것으로 예상됩니다, 데이터 침해로 인한 평균 비용은 다음과 같이 치솟았습니다. 424만 달러 (하지만 Equifax나 Solar Winds 같은 사건만 살펴봐야 가능하다는 것을 알 수 있습니다. 훨씬 더 나빠요).
업계에서는 10년 전만 해도 가능하다고 생각했던 것보다 더 강력한 힘을 가진 것처럼 보이는 사이버 보안 악당으로부터 우리를 구출해 줄 영웅을 기다리느라 오랜 시간을 보냈습니다.더 많은 사이버 보안 전문가들이 참여하여 우리를 더 높은 수준의 보안 프로그램으로 끌어올리기를 기다리고 있지만, 그 격차를 좁힐 수는 없습니다.날로 커지는 위험으로부터 우리를 자동화할 수 있는 은총알 툴링 솔루션을 기다리고 있습니다. 하지만 그런 솔루션은 그렇지 않으며 존재할 가능성도 거의 없습니다.다크 사이드에 맞서 싸울 수 있게 도와줄 루크 스카이워커를 기다리고 있습니다.
결과적으로 도움 (그리고 희망) 은 다음과 같은 형태로 다가오고 있습니다. 오픈소스 소프트웨어 보안 동원 계획.그러나 우리 모두는 특히 개발팀의 지원과 실행이 필요한 경우 가장 뛰어난 최신 방어 전략을 구현할 수 있을 만큼 조직의 성숙도가 높은지, 그리고 개발팀이 적절한 수준의 보안 인식과 기술을 갖추고 있는지 재고하고 정직하게 평가해야 합니다.
오픈 소스 소프트웨어 보안 동원 계획이란?
이 10개 항목의 계획은 오픈소스 소프트웨어 재단 (OpenSSF) 과 리눅스 재단이 백악관 관계자, 최고 CISO 및 37개 민간 기술 기업의 다른 고위 지도자들과 함께 주도했습니다.이러한 실천과 자금 지원 모두의 결합으로 오픈소스 소프트웨어의 보안 표준은 훨씬 더 강력해질 것입니다.
특히 흥미로운 점은 개발자 수준의 기본 교육 및 인증과 내부 소프트웨어 재료 명세서 (SBOM) 활동을 간소화하기 위한 조치에 초점을 맞추고 있다는 것입니다.이 두 가지 방법 모두 지속적인 영향을 미치는 방식으로 구현하기가 매우 어렵기로 악명이 높은데, 이는 부분적으로 조직 보안 프로그램 내에서의 골칫거리와 개발 집단 간의 전반적인 보안 성숙도 결여에 기인할 수 있습니다.이들은 날로 불합리한 마감 시한에 직면하여 빠른 속도로 코드 볼륨이 지배하는 압력 쿠커 환경에 처해 있습니다.사용 가능한 시간을 늘리지 않고 보안 요청 및 SBOM 유지 관리의 형태로 더 많은 작업을 추가하는 것은 시작하기도 전에 실패한 레시피이며 안타깝게도 예상보다 더 흔합니다.
자, 그럼 후드 아래를 살펴보죠.
개발자를 위한 보안 인증: 아직 완료되지 않았나요?
우리가 확실히 알고 있는 것이 하나 있다면 보안 숙련된 개발자 여전히 희귀한 상품입니다.이것이 현실인 데에는 여러 가지 이유가 있습니다. 즉, 최근까지 조직 내 소프트웨어 보안 전략에 있어 개발자는 고려의 대상이 아니었기 때문입니다.여기에 더해 개발자들은 보안에 우선순위를 둘 이유가 별로 없고 (교육이 부적절하거나 존재하지 않으며, 시간이 더 오래 걸리고, KPI에 포함되지 않으며, 주요 관심사는 자신이 가장 잘하는 일인 기능 구축입니다), 개발팀은 코드 수준에서 보안을 진정으로 다루거나 현대화된 DevSecops 중심의 SDLC (소프트웨어 개발 라이프사이클) 에서 역할을 수행할 준비가 제대로 되어 있지 않습니다.
오픈 소스 소프트웨어 보안 동원 계획을 살펴보면, 10개 항목 계획의 첫 번째 흐름은 개발 팀의 보안 성숙도를 구축하는 데 필수적인 “모두에게 기본 보안 소프트웨어 개발 교육 및 인증 제공”인 개발자 보안 기술을 다루는 것입니다.여기에서는 대부분의 고등 교육 과정 중 시큐어 코딩이 MIA라는 사실을 비롯하여 지금까지 논의한 문제들을 중점적으로 다룹니다.업계의 현상 유지를 바꿀 수 있는 개인과 부서가 이를 지원한다는 것은 매우 고무적인 일입니다. 그리고 적어도 다음을 포함하는 전세계 소프트웨어의 99% 약간 오픈 소스 코드, 이 개발 영역은 보안 분야의 개발자 교육에 집중하기 시작하기에 좋은 곳입니다.
이 계획은 다음과 같은 존경받는 자원을 인용합니다. OpenSSF 보안 소프트웨어 기초 교육 과정 및 에서 제공하는 광범위하고 오랜 리소스 OWASP 재단.이러한 정보 허브는 매우 중요합니다.개발자 역량 향상을 위해 이러한 자료를 제공하기 위해 제안된 출시에는 교육 기관과 협력하여 오픈 소스 보안 개발을 커리큘럼의 주요 특징으로 삼는 것 외에도 공공 부문과 민간 부문의 광범위한 파트너 네트워크를 통합하는 것이 포함됩니다.
보안 강화를 업무나 우선 순위가 아닌 것으로 간주한 전 세계 소프트웨어 엔지니어들의 마음을 사로잡을 수 있는 방법에 대해 이 계획에는 오픈 소스 라이브러리를 유지 관리하는 개발자와 보안 인증의 가치를 파악해야 하는 실무 엔지니어 모두를 대상으로 하는 보상 및 인정 전략이 자세히 설명되어 있습니다.
우리는 경험을 통해 개발자들이 인센티브에 잘 반응한다는 것을 알고 있으며, 진행 상황과 기술을 보여주는 계층화된 배지 시스템은 Steam이나 Xbox와 같은 제품에서와 마찬가지로 학습 환경에서도 잘 작동한다는 것을 알고 있습니다.
하지만 우려되는 점은 우리가 핵심 문제 중 하나를 다루고 있지 않다는 것입니다. 바로 조직의 보안 프로그램 내에서 학습 모듈을 제공하는 것입니다.커리어 대부분을 개발자들과 긴밀하게 협력해 왔기 때문에 개발자들이 툴과 교육에 대해 얼마나 회의적인지 잘 알고 있습니다. 최우선 과제인 작업에 지장을 줄 수 있는 것처럼 보이는 것은 말할 것도 없고요.개발자 지원을 위해서는 교육 과정 자료를 지속적으로 활용해야 하는데, 이 과정이 성공하려면 일상 업무의 맥락에서 이해가 되어야 합니다.
다음과 같은 확립된 성숙도 모델을 고려하면 소프트웨어 보증 성숙도 모델 (SAMM), “교육 및 지침”은 거버넌스 계층의 핵심 구성 요소이며 개발자 교육에 중점을 둡니다.이 모델은 전체적으로 방대하며, 성숙도를 높이기 위한 점진적인 단계들이 있습니다.그러나 초기 단계에서는 개발자에게 1~2일의 공식 교육만 권장하는데, 이는 보안 인식의 일면을 파헤치기에는 턱없이 부족합니다.그때도 최근 보고서 엔터프라이즈 전략 그룹 (ESG) 에 따르면 개발자에게 1년에 한 번 이상 정식 보안 교육에 참여하도록 요구하는 조직은 절반 미만인 것으로 나타났습니다.우리의 자체 연구 에반스 데이터 (Evans Data) 와 연계하여 개발자의 29% 만이 코드 작성의 능동적 관행을 믿고 있는 것으로 나타났습니다. 취약성이 있습니다 우선 순위를 정해야 합니다.교육을 제공하고 받는 방식과 교육이 보안 성숙도를 높이는 데 실제로 얼마나 유용한지 간에는 분명한 차이가 있습니다. 특히 개발자가 가치를 보지 못하는 경우에는 더욱 그렇습니다.
소프트웨어 BOM: 이 계획이 채택의 장벽을 허물고 있습니까?
계획에서 해결하고자 하는 또 다른 영역은 SBOM (Software Bill of Materials) 생성 및 유지 관리와 관련하여 자주 발생하는 재난입니다. “SBOM Everywhere — 채택을 촉진하기 위한 SBOM 도구 및 교육 개선” 스트림에서는 개발자와 조직이 SBOM을 보다 쉽게 생성, 업데이트 및 사용하여 더 나은 보안 결과를 도출할 수 있는 방법을 모색하고 있습니다.
현재 SBOM은 대부분의 업종에서 널리 채택되지 않아 보안 위험을 줄이는 데 있어 SBOM의 잠재력을 실현하기가 어렵습니다.이 계획에는 SBOM 공식화를 위한 주요 표준을 정의하는 훌륭한 전략과 개발자의 작업 방식에 맞게 쉽게 만들 수 있는 도구가 포함되어 있습니다.이러한 기능만으로도 이미 수요의 속도로 소프트웨어를 개발하기 위해 많은 시간을 투자하고 있는 개발자들이 또 다른 SDLC 작업을 수행해야 하는 부담을 줄이는 데 큰 도움이 될 것입니다.
하지만 제가 걱정하는 것은 일반적인 조직에서는 보안 책임이 개발자에게 매우 애매한 부분이 될 수 있다는 것입니다.보안 책임자는 누구인가요?궁극적으로는 보안팀의 몫이지만, 도움을 받으려면 개발자를 참여시켜야 합니다.작업과 기대치를 명확하게 정의해야 하며, 성공을 위한 이러한 추가 조치를 취할 시간이 필요합니다.
OSS에서 다른 소프트웨어 세계로
오픈 소스 소프트웨어 보안 동원 계획은 야심차고 대담하며 보안에 대한 개발자의 책임을 강화하는 데 꼭 필요한 것입니다.강력한 플레이어들이 한데 모인 “반란군 동맹”이 필요했지만, 이는 사이버 보안 기술 격차가 마법처럼 저절로 해결될 것이라는 생각을 뒤로하고 우리가 올바른 방향으로 나아가고 있다는 증거로 작용합니다.
이것이 우리의 새로운 희망이며, OSS를 넘어 이 구조를 발전시키려면 우리 모두가 필요할 것입니다.하지만 보안 전문가는 자신의 내면을 들여다보고 보호해야 하는 코드를 개발하는 개발 팀을 분석해야 합니다.이들은 현재 역량과 부족한 부분을 정직하게 평가해야 하며, 개발 집단에 진정한 보안 기술을 전수하는 프로그램을 철저하고 사전 예방적이며 포괄적으로 완성된 후기 단계 상태로 만들기 위해 노력해야 합니다.이러한 기능이 의미 있게 활성화되기 전까지는 코드 수준의 취약점에 대한 우리의 접근 방식이 아직 조금 미숙할 수 있습니다.
>> 실무 인터랙티브를 통해 팀의 보안 성숙도를 테스트하세요 XSS 챌린지!
以下のリンクをクリックし、このリソースのPDFをダウンロードしてください。
セキュアコードウォリアーは、ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先とする文化を組織に根付かせるために存在します。AppSec管理者、開発者、CISO、あるいはセキュリティに関わるあらゆる立場の方々に対し、組織が安全でないコードに関連するリスクを軽減できるよう支援します。
レポートを見るデモ予約
最高経営責任者（CEO）、会長、および共同設立者
Pieter Danhieuxは、セキュリティコンサルタントとして12年以上の経験を持ち、SANSの主席講師として8年間、組織、システム、個人をターゲットにしてセキュリティの弱点を評価する方法に関する攻撃的なテクニックを教えている、世界的に有名なセキュリティエキスパートです。2016年には、オーストラリアで最もクールな技術者の一人として認められ（Business Insider）、Cyber Security Professional of the Yearを受賞（AISA - Australian Information Security Association）、GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA認定を保有している。
현재의 경제 상황과 위협 환경에서 저는 확실히 평균적인 CISO가 부럽지 않습니다.이들은 안전, 규정 준수, 혁신 및 비즈니스 가치를 제공하는 동시에 예산 축소와 조사 강화로 힘겨운 싸움에 직면해 있습니다.아마도 더 시급한 것은 모든 조직 (및 해당 개발 팀) 이 각기 다른 보안 성숙도 단계에 있으며, 모든 조직이 사이버 방어 측면에서 최선을 다할 준비가 되어 있지는 않다는 사실일 것입니다.
지난 몇 년간 사이버 보안 사고가 심화되면서 보안 리더가 한 발 앞서 나가는 것이 상당히 어려워졌습니다.날로 커져가는 곤경에 대한 일부 데이터 기반 인사이트를 살펴보는 것만으로도 화약고 같은 것을 알 수 있습니다. 그 이상입니다. 2023년에만 330억 개의 기록이 사이버 범죄자에 의해 도난당할 것입니다., 2018년보다 175% 증가했습니다.더 사이버 범죄 비용은 2025년까지 10조 5천억 달러에 달할 것으로 예상됩니다, 데이터 침해로 인한 평균 비용은 다음과 같이 치솟았습니다. 424만 달러 (하지만 Equifax나 Solar Winds 같은 사건만 살펴봐야 가능하다는 것을 알 수 있습니다. 훨씬 더 나빠요).
업계에서는 10년 전만 해도 가능하다고 생각했던 것보다 더 강력한 힘을 가진 것처럼 보이는 사이버 보안 악당으로부터 우리를 구출해 줄 영웅을 기다리느라 오랜 시간을 보냈습니다.더 많은 사이버 보안 전문가들이 참여하여 우리를 더 높은 수준의 보안 프로그램으로 끌어올리기를 기다리고 있지만, 그 격차를 좁힐 수는 없습니다.날로 커지는 위험으로부터 우리를 자동화할 수 있는 은총알 툴링 솔루션을 기다리고 있습니다. 하지만 그런 솔루션은 그렇지 않으며 존재할 가능성도 거의 없습니다.다크 사이드에 맞서 싸울 수 있게 도와줄 루크 스카이워커를 기다리고 있습니다.
결과적으로 도움 (그리고 희망) 은 다음과 같은 형태로 다가오고 있습니다. 오픈소스 소프트웨어 보안 동원 계획.그러나 우리 모두는 특히 개발팀의 지원과 실행이 필요한 경우 가장 뛰어난 최신 방어 전략을 구현할 수 있을 만큼 조직의 성숙도가 높은지, 그리고 개발팀이 적절한 수준의 보안 인식과 기술을 갖추고 있는지 재고하고 정직하게 평가해야 합니다.
오픈 소스 소프트웨어 보안 동원 계획이란?
이 10개 항목의 계획은 오픈소스 소프트웨어 재단 (OpenSSF) 과 리눅스 재단이 백악관 관계자, 최고 CISO 및 37개 민간 기술 기업의 다른 고위 지도자들과 함께 주도했습니다.이러한 실천과 자금 지원 모두의 결합으로 오픈소스 소프트웨어의 보안 표준은 훨씬 더 강력해질 것입니다.
특히 흥미로운 점은 개발자 수준의 기본 교육 및 인증과 내부 소프트웨어 재료 명세서 (SBOM) 활동을 간소화하기 위한 조치에 초점을 맞추고 있다는 것입니다.이 두 가지 방법 모두 지속적인 영향을 미치는 방식으로 구현하기가 매우 어렵기로 악명이 높은데, 이는 부분적으로 조직 보안 프로그램 내에서의 골칫거리와 개발 집단 간의 전반적인 보안 성숙도 결여에 기인할 수 있습니다.이들은 날로 불합리한 마감 시한에 직면하여 빠른 속도로 코드 볼륨이 지배하는 압력 쿠커 환경에 처해 있습니다.사용 가능한 시간을 늘리지 않고 보안 요청 및 SBOM 유지 관리의 형태로 더 많은 작업을 추가하는 것은 시작하기도 전에 실패한 레시피이며 안타깝게도 예상보다 더 흔합니다.
자, 그럼 후드 아래를 살펴보죠.
개발자를 위한 보안 인증: 아직 완료되지 않았나요?
우리가 확실히 알고 있는 것이 하나 있다면 보안 숙련된 개발자 여전히 희귀한 상품입니다.이것이 현실인 데에는 여러 가지 이유가 있습니다. 즉, 최근까지 조직 내 소프트웨어 보안 전략에 있어 개발자는 고려의 대상이 아니었기 때문입니다.여기에 더해 개발자들은 보안에 우선순위를 둘 이유가 별로 없고 (교육이 부적절하거나 존재하지 않으며, 시간이 더 오래 걸리고, KPI에 포함되지 않으며, 주요 관심사는 자신이 가장 잘하는 일인 기능 구축입니다), 개발팀은 코드 수준에서 보안을 진정으로 다루거나 현대화된 DevSecops 중심의 SDLC (소프트웨어 개발 라이프사이클) 에서 역할을 수행할 준비가 제대로 되어 있지 않습니다.
오픈 소스 소프트웨어 보안 동원 계획을 살펴보면, 10개 항목 계획의 첫 번째 흐름은 개발 팀의 보안 성숙도를 구축하는 데 필수적인 “모두에게 기본 보안 소프트웨어 개발 교육 및 인증 제공”인 개발자 보안 기술을 다루는 것입니다.여기에서는 대부분의 고등 교육 과정 중 시큐어 코딩이 MIA라는 사실을 비롯하여 지금까지 논의한 문제들을 중점적으로 다룹니다.업계의 현상 유지를 바꿀 수 있는 개인과 부서가 이를 지원한다는 것은 매우 고무적인 일입니다. 그리고 적어도 다음을 포함하는 전세계 소프트웨어의 99% 약간 오픈 소스 코드, 이 개발 영역은 보안 분야의 개발자 교육에 집중하기 시작하기에 좋은 곳입니다.
이 계획은 다음과 같은 존경받는 자원을 인용합니다. OpenSSF 보안 소프트웨어 기초 교육 과정 및 에서 제공하는 광범위하고 오랜 리소스 OWASP 재단.이러한 정보 허브는 매우 중요합니다.개발자 역량 향상을 위해 이러한 자료를 제공하기 위해 제안된 출시에는 교육 기관과 협력하여 오픈 소스 보안 개발을 커리큘럼의 주요 특징으로 삼는 것 외에도 공공 부문과 민간 부문의 광범위한 파트너 네트워크를 통합하는 것이 포함됩니다.
보안 강화를 업무나 우선 순위가 아닌 것으로 간주한 전 세계 소프트웨어 엔지니어들의 마음을 사로잡을 수 있는 방법에 대해 이 계획에는 오픈 소스 라이브러리를 유지 관리하는 개발자와 보안 인증의 가치를 파악해야 하는 실무 엔지니어 모두를 대상으로 하는 보상 및 인정 전략이 자세히 설명되어 있습니다.
우리는 경험을 통해 개발자들이 인센티브에 잘 반응한다는 것을 알고 있으며, 진행 상황과 기술을 보여주는 계층화된 배지 시스템은 Steam이나 Xbox와 같은 제품에서와 마찬가지로 학습 환경에서도 잘 작동한다는 것을 알고 있습니다.
하지만 우려되는 점은 우리가 핵심 문제 중 하나를 다루고 있지 않다는 것입니다. 바로 조직의 보안 프로그램 내에서 학습 모듈을 제공하는 것입니다.커리어 대부분을 개발자들과 긴밀하게 협력해 왔기 때문에 개발자들이 툴과 교육에 대해 얼마나 회의적인지 잘 알고 있습니다. 최우선 과제인 작업에 지장을 줄 수 있는 것처럼 보이는 것은 말할 것도 없고요.개발자 지원을 위해서는 교육 과정 자료를 지속적으로 활용해야 하는데, 이 과정이 성공하려면 일상 업무의 맥락에서 이해가 되어야 합니다.
다음과 같은 확립된 성숙도 모델을 고려하면 소프트웨어 보증 성숙도 모델 (SAMM), “교육 및 지침”은 거버넌스 계층의 핵심 구성 요소이며 개발자 교육에 중점을 둡니다.이 모델은 전체적으로 방대하며, 성숙도를 높이기 위한 점진적인 단계들이 있습니다.그러나 초기 단계에서는 개발자에게 1~2일의 공식 교육만 권장하는데, 이는 보안 인식의 일면을 파헤치기에는 턱없이 부족합니다.그때도 최근 보고서 엔터프라이즈 전략 그룹 (ESG) 에 따르면 개발자에게 1년에 한 번 이상 정식 보안 교육에 참여하도록 요구하는 조직은 절반 미만인 것으로 나타났습니다.우리의 자체 연구 에반스 데이터 (Evans Data) 와 연계하여 개발자의 29% 만이 코드 작성의 능동적 관행을 믿고 있는 것으로 나타났습니다. 취약성이 있습니다 우선 순위를 정해야 합니다.교육을 제공하고 받는 방식과 교육이 보안 성숙도를 높이는 데 실제로 얼마나 유용한지 간에는 분명한 차이가 있습니다. 특히 개발자가 가치를 보지 못하는 경우에는 더욱 그렇습니다.
소프트웨어 BOM: 이 계획이 채택의 장벽을 허물고 있습니까?
계획에서 해결하고자 하는 또 다른 영역은 SBOM (Software Bill of Materials) 생성 및 유지 관리와 관련하여 자주 발생하는 재난입니다. “SBOM Everywhere — 채택을 촉진하기 위한 SBOM 도구 및 교육 개선” 스트림에서는 개발자와 조직이 SBOM을 보다 쉽게 생성, 업데이트 및 사용하여 더 나은 보안 결과를 도출할 수 있는 방법을 모색하고 있습니다.
현재 SBOM은 대부분의 업종에서 널리 채택되지 않아 보안 위험을 줄이는 데 있어 SBOM의 잠재력을 실현하기가 어렵습니다.이 계획에는 SBOM 공식화를 위한 주요 표준을 정의하는 훌륭한 전략과 개발자의 작업 방식에 맞게 쉽게 만들 수 있는 도구가 포함되어 있습니다.이러한 기능만으로도 이미 수요의 속도로 소프트웨어를 개발하기 위해 많은 시간을 투자하고 있는 개발자들이 또 다른 SDLC 작업을 수행해야 하는 부담을 줄이는 데 큰 도움이 될 것입니다.
하지만 제가 걱정하는 것은 일반적인 조직에서는 보안 책임이 개발자에게 매우 애매한 부분이 될 수 있다는 것입니다.보안 책임자는 누구인가요?궁극적으로는 보안팀의 몫이지만, 도움을 받으려면 개발자를 참여시켜야 합니다.작업과 기대치를 명확하게 정의해야 하며, 성공을 위한 이러한 추가 조치를 취할 시간이 필요합니다.
OSS에서 다른 소프트웨어 세계로
오픈 소스 소프트웨어 보안 동원 계획은 야심차고 대담하며 보안에 대한 개발자의 책임을 강화하는 데 꼭 필요한 것입니다.강력한 플레이어들이 한데 모인 “반란군 동맹”이 필요했지만, 이는 사이버 보안 기술 격차가 마법처럼 저절로 해결될 것이라는 생각을 뒤로하고 우리가 올바른 방향으로 나아가고 있다는 증거로 작용합니다.
이것이 우리의 새로운 희망이며, OSS를 넘어 이 구조를 발전시키려면 우리 모두가 필요할 것입니다.하지만 보안 전문가는 자신의 내면을 들여다보고 보호해야 하는 코드를 개발하는 개발 팀을 분석해야 합니다.이들은 현재 역량과 부족한 부분을 정직하게 평가해야 하며, 개발 집단에 진정한 보안 기술을 전수하는 프로그램을 철저하고 사전 예방적이며 포괄적으로 완성된 후기 단계 상태로 만들기 위해 노력해야 합니다.이러한 기능이 의미 있게 활성화되기 전까지는 코드 수준의 취약점에 대한 우리의 접근 방식이 아직 조금 미숙할 수 있습니다.
>> 실무 인터랙티브를 통해 팀의 보안 성숙도를 테스트하세요 XSS 챌린지!
%20(1).avif)
.avif)
