현재의 경제 환경과 위협 환경에서 나는 평균 CISO를 부러워하지 않습니다. 그들은 안전, 규정 준수, 혁신 및 비즈니스 가치를 제공하는 동시에 예산 축소와 조사 증가로 힘든 싸움에 직면 해 있습니다. 아마도 더 시급한 것은 모든 조직 (및 해당 개발 팀)이 다양한 보안 성숙 단계에 있으며 모든 조직이 사이버 방어 측면에서 최선의 발걸음을 내딛을 수있는 것은 아니라는 사실입니다. 

지난 몇 년 동안 사이버 보안 사고가 증가함에 따라 보안 리더가 한 걸음 앞서 나가기가 매우 어려워졌습니다. 우리의 증가하는 곤경에 대한 데이터 중심의 통찰력 중 일부를 살펴보면 파우더 통의 무언가가 드러납니다 : 2023 년에만 330 억 개 이상의 기록이 사이버 범죄자에 의해 도난 당할 것이며 이는 2018 년에 비해 175 % 증가한 것입니다. 사이버 범죄의 비용은 2025 년까지 10.5 조 달러에 달할 것으로 예측되며, 데이터 유출의 평균 비용은 4.24 백만 달러로 급증했습니다 (Equifax 또는 Solar Winds와 같은 사건 만 봐도 훨씬 더 나쁠 수 있습니다). 

산업으로서, 우리는 영웅이 와서 십 년 전에도 우리가 생각했던 것보다 더 많은 힘을 가진 사이버 보안 악당들로부터 우리를 구출하기를 기다리는 데 오랜 시간을 보냈습니다. 우리는 더 많은 사이버 보안 전문가들이 승선하여 더 높은 수준의 보안 프로그램으로 우리를 끌어 올리기를 기다리고 있지만 우리가 닫을 수없는 격차입니다. 우리는 증가하는 위험으로부터 우리를 자동화 할 것을 약속하는 은색 총알 툴링 솔루션을 기다리고 있지만 존재하지 않으며 존재할 가능성은 거의 없습니다. 우리는 루크 스카이워커가 다크 사이드와 싸울 수 있도록 도와주기를 기다리고 있습니다.

그것이 밝혀 지면서, 도움 (그리고 희망) 은 오픈 소스 소프트웨어 보안 동원 계획의 형태로 진행되고 있습니다. 그러나 우리 모두는 재고를 가지고 정직하게 우리 조직에서 충분히 성숙했는지, 그리고 개발 팀이 적절한 수준의 보안 인식 및 기술을 보유하고 있는지 정직하게 평가하여 최신의 가장 훌륭한 방어 전략을 구현해야하며, 특히 개발 팀의 지원과 실행이 필요할 때 특히 그렇습니다.

오픈 소스 소프트웨어 보안 동원 계획이란 무엇입니까?

이 열 가지 계획은 오픈 소스 소프트웨어 재단 (OpenSSF)과 리눅스 재단 (Linux Foundation)이 백악관 관계자, CISO 및 37 민간 기술 회사의 다른 고위 지도자들과 함께 주도했습니다. 행동과 자금 조달 모두에서 이러한 지원이 결합됨에 따라 오픈 소스 소프트웨어의 보안 표준이 훨씬 더 강해질 것입니다. 

특히 흥미로운 점은 개발자 수준의 기본 교육 및 인증에 중점을두고 내부 SBOM (Software Bill of Materials) 활동을 간소화하기 위해 고안된 조치입니다. 이것들은 둘 다 지속적인 영향을 미치는 방식으로 구현하기가 매우 어려우며, 이는 부분적으로 조직 보안 프로그램 내에서 고통이 커지고 개발 코호트 간의 보안 성숙도가 전반적으로 부족하기 때문에 자신의 잘못이 없기 때문일 수 있습니다. 그들은 점점 더 불합리한 마감 기한에 직면하여 속도의 코드 볼륨이 최고로 군림하는 압력 밥솥 환경에 있습니다. 사용 가능한 시간을 늘리지 않고 보안 요청 및 SBOM 유지 관리의 형태로 더 많은 작업을 추가하는 것은 시작하기 전에 실패한 레시피이며 슬프게도 예상보다 더 일반적입니다.

자, 후드 아래를 살펴 보겠습니다.

개발자를 위한 보안 인증: 아직 없습니까?

우리가 확실히 알고있는 한 가지가 있다면, 보안 숙련 된 개발자는 여전히 희귀 한 상품이라는 것입니다. 이것은 여러 가지 이유, 즉 최근까지 개발자가 조직 내의 소프트웨어 보안 전략에 관해서는 방정식의 일부가 아니 었기 때문에 현실입니다. 개발자가 보안의 우선 순위를 정할 이유가 많지 않은 경우(교육이 부적절하거나 존재하지 않으며, 시간이 오래 걸리고, KPI의 일부가 아니며, 가장 중요한 관심사는 최선을 다하는 것, 즉 기능 구축)과 코드 수준에서 보안을 진정으로 처리하거나 현대화된 역할을 수행할 준비가 되어 있지 않은 개발 팀이 있다는 점을 결합해 보십시오. DevSecOps 중심의 SDLC(소프트웨어 개발 수명 주기). 

오픈 소스 소프트웨어 보안 동원 계획을 살펴보면 열 가지 계획의 첫 번째 흐름은 개발자 보안 기술을 다루는 것이며, 개발 팀에서 보안 성숙도를 구축하는 데 필수적인 "기본 보안 소프트웨어 개발 교육 및 인증을 모두에게 제공"하는 것입니다. 그들은 보안 코딩이 대부분의 소프트웨어 엔지니어링의 MIA라는 사실을 포함하여 우리가 얼마 동안 논의 한 문제를 강조합니다. courses 삼차 수준에서. 업계 현상 유지를 바꿀 수있는 개인 및 부서가 지원하는 것을 보는 것은 매우 고무적이며, 전 세계 소프트웨어의 99 %에 적어도 일부 오픈 소스 코드가 포함되어 있기 때문에이 개발 영역은 보안 분야의 개발자 교육에 집중할 수있는 좋은 장소입니다.

이 계획은 OpenSSF 보안 소프트웨어 기본 사항과 같은 존경받는 리소스를 인용합니다. courses, 그리고 OWASP 재단의 광범위하고 오랜 자원. 이러한 정보 허브는 매우 중요합니다. 업스킬링 개발자를 위해 이러한 자료를 제공하기 위해 제안 된 롤아웃은 공공 및 민간 부문의 광범위한 파트너 네트워크를 모으는 것 외에도 교육 기관과의 파트너십을 통해 오픈 소스 보안 개발을 커리큘럼의 핵심 기능으로 만드는 것입니다. 

전 세계 소프트웨어 엔지니어들의 마음과 마음을 어떻게 이겨낼 것인지에 관해서는, 그들 중 많은 사람들이 자신의 직업이나 우선 순위가 아닌 것으로 보안을 강화했으며, 이 계획은 오픈 소스 라이브러리를 유지 관리하는 개발자와 보안 인증의 가치를 확인해야 하는 실무 엔지니어 모두를 대상으로 하는 보상 및 인정 전략을 자세히 설명합니다. 

우리는 경험을 통해 개발자가 인센티브에 잘 반응하고 진보와 기술을 보여주는 계층화 된 불량 시스템이 Steam 또는 Xbox와 같은 학습 환경에서와 마찬가지로 학습 환경에서도 작동한다는 것을 알고 있습니다.

그러나 우려되는 것은 핵심 문제 중 하나를 다루지 않고 있으며 이는 조직의 보안 프로그램 내에서 학습 모듈을 제공하는 것입니다. 내 경력의 많은 부분을 위해 개발자와 긴밀히 협력 한 결과, 도구와 교육에 관해서는 그들이 얼마나 회의적인지 알고 있으며, 우선 순위 numero uno 인 작업을 방해 할 수있는 것처럼 보이는 것은 말할 것도 없습니다. 개발자 활성화를 위해서는 코스 자료에 지속적으로 참여해야하며,이를 성공적으로 수행하려면 일상 업무의 맥락에서 의미가 있어야합니다.

SAMM( Software Assurance Maturity Model )과 같은 확립된 성숙도 모델을 고려한다면, "교육 및 지침"은 Governace 계층의 핵심 구성 요소이며 개발자 교육에 중점을 두고 있습니다. 모델 전체가 방대하며 더 높은 수준의 성숙도에 도달하는 점진적인 단계가 있습니다. 그러나 초기 단계에서는 개발자를 위한 1-2일의 공식 교육만 권장하며, 이는 보안 인식의 표면을 긁어내기에는 충분하지 않습니다. 그럼에도 불구하고 ESG(Enterprise Strategy Group)의 최근 보고서에 따르면 조직의 절반 미만이 개발자가 일년에 한 번 이상 공식 보안 교육에 참여하도록 요구하고 있는 것으로 나타났습니다. Evans Data와 함께 진행한 자체 연구에 따르면 개발자의 29%만이 취약점이 없는 코드를 작성하는 적극적인 관행이 우선시되어야 한다고 생각합니다. 교육이 어떻게 전달되고 수신되는지, 그리고 특히 개발자가 가치를 못하는 경우 보안 성숙도를 가져 오는 데 실제로 얼마나 유용한지 사이에는 분명한 단절이 있습니다.

소프트웨어 자재 명세서: 이 계획이 채택 장벽을 무너뜨리는가?

이 계획이 해결하고자 하는 또 다른 영역은 SBOM(Software Bill of Materials) 생성 및 유지 관리와 관련하여 종종 존재하는 재앙이며, "SBOM Everywhere - SBOM Tooling and Training to Drive Adoption" 스트림은 개발자와 조직이 SBOM을 더 쉽게 생성, 업데이트 및 사용하여 더 나은 보안 결과를 도출할 수 있는 방법을 모색합니다.

현재로서는 SBOM이 대부분의 수직에서 널리 채택되지 않아 보안 위험을 줄이는 잠재력을 실현하기가 어렵습니다. 이 계획에는 SBOM 공식화에 대한 핵심 표준을 정의하는 훌륭한 전략과 개발자 작업 방식에 맞는 쉽게 만들 수있는 도구가 있습니다. 이것만으로도 이미 많은 플레이트를 회전시켜 수요의 속도로 소프트웨어를 만드는 개발자를위한 또 다른 SDLC 작업의 부담을 줄이는 데 큰 도움이 될 것입니다. 

그러나 내가 두려워하는 것은 평균적인 조직에서 보안 책임이 개발자에게 진정한 회색 영역이 될 수 있다는 것입니다. 보안에 대한 책임은 누구에게 있습니까? 궁극적으로, 그것은 보안 팀이지만, 우리가 그들의 도움을 원한다면 개발자를 데려 와야합니다. 과제와 기대치를 명확하게 정의해야 하며, 성공에 대한 이러한 추가적인 조치를 취할 시간이 필요합니다. 

OSS에서 나머지 소프트웨어 세계로

오픈 소스 소프트웨어 보안 동원 계획은 야심적이고 대담하며 보안에 대한 개발자의 책임을 유도하는 데 필요한 것입니다. 일부 강력한 플레이어들이 함께 모이는 "반란군 동맹"이 필요했지만, 이것은 우리가 올바른 방향으로 나아가고 있으며 사이버 보안 기술 격차가 마술처럼 스스로를 고칠 것이라는 생각을 남기고 있다는 증거로 작용합니다. 

그것은 우리의 새로운 희망이며, OSS를 넘어서서이 구조를 발전시키는 데 우리 모두가 필요할 것입니다. 그러나 보안 전문가는 자체 내부를 살펴보고 보호해야 하는 코드를 작업하는 개발 팀을 분석해야 합니다. 그들은 정직해야합니다. assessment 그들의 현재 능력, 격차가있는 곳, 그리고 개발 코호트에 진정한 보안 기술을 부여하는 프로그램을 포함하는 기밀, 사전 대응 및 포괄적 인 성숙한 후기 단계 상태를 만들기 위해 노력합니다. 의미 있게 활성화될 때까지는 코드 수준 취약성에 대한 접근 방식이 아직 미숙할 수 있습니다.

‍

>> 실습 인터랙티브 XSS 챌린지로 팀의 보안 성숙도를 테스트하십시오!