개발자는 "보안 코딩"을 어떻게 정의합니까?
이 기사의 버전은 TechRepublic에 나타났습니다. 여기에서 업데이트되고 신디케이트되었습니다.
보안 팀과 개발자 팀의 목표가 일치하는 환경을 조성하기 위한 오르막길이지만 필수적인 전투였습니다. 우리는 갈 길이 멀지만, 소프트웨어 보안에 대한 공동 책임의 문을 여는 데 필요한 시너지 효과를 방해하는 장애물은 매우 분명 해지고 있습니다. 똑똑한 기업은 이러한 함정을 피하고, 생산적인 방법을 찾고, DevSecOps를 인력 중심의 잠재력을 최대한 발휘할 수 있도록 전략을 발전시키고자 합니다.
내가 예상하지 못했던 것은 보안 코딩 행위를 구성하는 것에 대한 인식이 논쟁의 여지가 있다는 것입니다. Evans Data와의 공동 연구에 따르면이 감정은 흑백으로 밝혀졌습니다. 개발자 주도 보안 현황 2022 설문조사에서는 1200 명의 활성 개발자의 주요 통찰력과 경험을 조사하여 보안 영역에서의 태도와 도전 과제를 조명합니다.
헤드 라인 결과 중 하나는 개발자의 14 %만이 코딩 할 때 보안을 우선 순위로 간주한다는 것입니다. 이것은 개선의 여지가 엄청나다는 것을 보여 주지만, 우리가 이미 알고있는 것을 확인합니다 : 기능 구축은 개발자의 세계에서 왕이며, 보안은 DNA의 일부로 만들기 위해 제대로 갖추어져 있지 않습니다. 그러나 보안 코딩이 무엇을 의미하는지에 대한 개발자 정의에 대한 데이터와 결합되면 우려의 원인이됩니다.
이러한 인식은 근무일의 개발자 경험에 의해 주도되며, 많은 조직의 환경에 대해 말하며, 이는 개발자가 일반적인 취약점과의 싸움에서 초점이 아니라는 것입니다. 그들의 활성화는 중요하지만, 그 동안 우리는 "보안 코딩"의 범위와 보안 숙련 된 개발자에게 기대해야하는 것을 가지고 동일한 페이지에 신속하게 도달해야합니다.
우리는 개발자의 세계에서 보안을 신비화해야합니다.
사이버 보안은 최고의 시간에 다각적이고 다루기 힘든 짐승이며, 보안 코딩은 전체 환경의 한 부분 일 뿐이지 만 전문가의 관심이 필요한 시스템의 복잡한 톱니바퀴입니다.
설문 조사에 따르면 보안 코드로 작업하는 개념은 일반 개발자에게는 상당히 사일로화되었으며, 그 범위는 기본 사항 및 그 이상에 대한 전체적인 견해와는 달리 단일 범주로 제한되는 경우가 많습니다. 개발자는 취약점이없는 새로운 코드를 작성하는 관행보다는 기존 (또는 사전 승인 된) 코드를 사용하는 데 의존한다고 지적했습니다. 타사 구성 요소(특히 패치 적용 및 Log4Shell debacle에 대한 보안 인식이 좋은 예입니다: 인스턴스의 30%가 12월 이후 패치되지 않은 상태로 유지됨)는 기존 코드를 테스트하는 것과 마찬가지로 매우 중요하지만 이것만으로는 기능 수준의 보안 코딩 기능을 충족하지 못합니다.
코드 수준 취약점은 불량한 코딩 패턴을 학습한 개발자에 의해 도입되며, KPI에 보안 코드를 작성하는 데 중점을 두지 않고(보안 문화가 부족한 경우) 이를 허용 가능한 표준으로 강화할 뿐입니다.
보안 리더는 먼저 개발 코호트에 보안 코딩이 수반하는 것에 대한 완전한 그림을 표시하도록 보장함으로써 초기 인식을 개선하고 가장 시급한 지식 격차의 영역을 식별하는 데 많은 노력을 기울일 수 있습니다. 사전 승인된 코드를 테스트하고 스캔하는 것은 하나의 기능이지만, 취약성을 줄이려면 활발히 사용되고 있는 언어 및 프레임워크에서 훌륭하고 안전한 코딩 패턴에 대한 실습 교육이 필요합니다.
컨텍스트는 개발자 업스킬링에서 매우 중요하며, 비즈니스의 보안 목표와 관련하여 이러한 여정을 진행해야 합니다.
많은 조직에서 보안 프로그램을 업그레이드해야 합니다.
지난 십 년 동안 사이버 보안 사고의 급속한 성장을 위해 소프트웨어 기반 기술이 폭발적으로 증가함에 따라, 우리는 모두 귀중한 시스템에서 악용 사례를 발견하기 위해 쉬지 않고 일하는 위협 행위자를 따라 잡기 위해 노력하고 있습니다.
DevSecOps 방법론은 개발자를 포함한 모든 사람이 보안에 대한 책임을 공유한다는 생각에 기반하고 있으며 SDLC의 처음부터 가장 중요한 고려 사항입니다. 문제는 특히 대기업에서 DevSecOps를 표준으로 구현하는 데 매우 멀리 떨어져있을 수 있다는 것입니다. 2017 년 프로젝트 관리 연구소 (Project Management Institute)의 연구에 따르면 조직의 51 %가 여전히 소프트웨어 개발에 Waterfall을 사용하고 있습니다. 이 연구는 이제 다섯 살이 되었지만, 대기업에서 점진적인 변화가 어떻게 일어날 수 있는지를 알면 최신 보안 지향 방법론으로의 급격한 전환이 있었을 가능성은 거의 없다. 이러한 레거시 프로세스는 사이버 위협으로부터 보호하기위한 포괄적 인 전략으로 모든 기반을 커버하려는 보안 전문가에게 힘든 싸움을 일으킬 수 있으며, 개발자와 요구 사항을이 환경에 맞게 조정하는 것은 어려운 일입니다.
그러나 우리는 이것을 변명으로 사용할 수 없습니다. 비즈니스의 보안 전문가는 개발자를 고양 된 전략으로 활용할 수 있습니다. 그들은 단지 그들의 필요에 익숙해지고 그들을 방어 플레이의 일부로 간주해야합니다. 그들은 포괄적 인 교육이 필요하며 보안에 대한 모든 책임은 기술 스택 및 워크 플로우와 관련하여 구현되어야합니다.
보안 코딩 = "너무 어려운"바구니?
Evans Data 연구에 따르면 개발자의 86%가 보안 코딩을 연습하는 것이 어렵다고 답했으며, 개발자 관리자의 92%는 팀이 보안 프레임워크에 대한 더 많은 교육이 필요하다고 인정했습니다. 걱정스럽게도 응답자의 48 %는 고의로 코드에 취약점을 남긴다는 것을 인정했습니다.
이것은 매우 중요한 그림을 그립니다. 일반적으로 개발자는 빈번하고 적절한 교육을받지 못하고 있으며 좋은 보안 관행 및 위생에 충분히 노출되지 않는 것으로 보입니다. 라인 사이를 읽으면 문제의 핵심이 강화됩니다 : 개발자가 작업에서 보안을 고려하는 것이 우선 순위가 아닙니다. 그것과 그들이받는 훈련은 자신감이나 실용적인 기술을 구축하지 못하며, 취약한 코드를 제공하기로 한 결정의 영향을 이해하는 데 도움이되지 않습니다.
식민지 파이프 라인 랜섬웨어 공격은 작년에 가장 파괴적인 공급망 보안 사건 중 하나였으며, 미국 동부 해안의 가스 공급의 절반이 불확실한 기간 동안 차단 될 것이라는 두려움을 불러 일으켰습니다. 고맙게도, 그들은 신속하게 백업하고 운영되었지만 지역 사회에서 큰 걱정이없는 것은 아닙니다. 그것은 일반 대중이 사이버 사건이 반드시 소프트웨어 중심이나 사이버 공격의 위험으로 생각되지 않는 물리적 세계의 요소에 심각한 영향을 미칠 것이라는 전망에 직면 한 도가니의 순간 중 하나였습니다. 그리고 그 모든 혼란은 패치되지 않은 두 가지 오래된 취약점에 의해 가능해졌으며, 그 중 하나는 교활하지만 널리 알려진 SQL 주입이었습니다. 개발자가 취약한 코드를 제공하기로 결정했을 때 실제로 무엇이 위험에 처해 있는지 알고 있다면 수용 가능한 비즈니스 위험 인 시나리오가 없다는 것을 빨리 알게 될 것입니다.
기능적인 "P-P-T"는 개발자의 몫이 아닙니다.
사람, 프로세스 및 도구의 유명한 "황금 삼각형"은 신중하게 고려 된 전략 없이는 달성 할 수 없으며 개발자는 필요와 도전을 고려하지 않고 작업 보안 프로세스에 동화 될 수있는 위치에 있지 않습니다.
개발자 중심의 보안을 강화하기 위해서는 상당한 문화 전환이 필요하며 엔지니어와 보안 팀 모두를 더욱 명확하게 만드는 교육 경로로 시작됩니다.
무엇이 보안 코딩 행위를 구성하는지에 대한 인식은 논쟁의 여지가 있습니다. 에반스 데이터와 공동으로 실시한 최근 조사에 따르면 이러한 인식은 흑백으로 뚜렷하게 드러났습니다. 2022 개발자 주도 보안 현황 설문조사에서는 1200명의 현직 개발자의 주요 인사이트와 경험을 조사하여 보안 영역에서 개발자의 태도와 과제를 조명합니다.
최고 경영자, 회장 겸 공동 설립자
Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약
최고 경영자, 회장 겸 공동 설립자
피터 댄히외는 보안 컨설턴트로 12년 이상 경력을 쌓았으며, 조직, 시스템 및 개인의 보안 취약점을 타겟팅하고 평가하는 방법에 대한 공격 기법을 가르치는 SANS의 수석 강사로 8년 이상 활동한 세계적으로 인정받는 보안 전문가입니다. 2016년에는 호주에서 가장 멋진 기술자 중 한 명으로 선정(비즈니스 인사이더)되었고, 올해의 사이버 보안 전문가(AISA - 호주 정보 보안 협회)로 선정되었으며, GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA 자격증을 보유하고 있습니다.
이 기사의 버전은 TechRepublic에 나타났습니다. 여기에서 업데이트되고 신디케이트되었습니다.
보안 팀과 개발자 팀의 목표가 일치하는 환경을 조성하기 위한 오르막길이지만 필수적인 전투였습니다. 우리는 갈 길이 멀지만, 소프트웨어 보안에 대한 공동 책임의 문을 여는 데 필요한 시너지 효과를 방해하는 장애물은 매우 분명 해지고 있습니다. 똑똑한 기업은 이러한 함정을 피하고, 생산적인 방법을 찾고, DevSecOps를 인력 중심의 잠재력을 최대한 발휘할 수 있도록 전략을 발전시키고자 합니다.
내가 예상하지 못했던 것은 보안 코딩 행위를 구성하는 것에 대한 인식이 논쟁의 여지가 있다는 것입니다. Evans Data와의 공동 연구에 따르면이 감정은 흑백으로 밝혀졌습니다. 개발자 주도 보안 현황 2022 설문조사에서는 1200 명의 활성 개발자의 주요 통찰력과 경험을 조사하여 보안 영역에서의 태도와 도전 과제를 조명합니다.
헤드 라인 결과 중 하나는 개발자의 14 %만이 코딩 할 때 보안을 우선 순위로 간주한다는 것입니다. 이것은 개선의 여지가 엄청나다는 것을 보여 주지만, 우리가 이미 알고있는 것을 확인합니다 : 기능 구축은 개발자의 세계에서 왕이며, 보안은 DNA의 일부로 만들기 위해 제대로 갖추어져 있지 않습니다. 그러나 보안 코딩이 무엇을 의미하는지에 대한 개발자 정의에 대한 데이터와 결합되면 우려의 원인이됩니다.
이러한 인식은 근무일의 개발자 경험에 의해 주도되며, 많은 조직의 환경에 대해 말하며, 이는 개발자가 일반적인 취약점과의 싸움에서 초점이 아니라는 것입니다. 그들의 활성화는 중요하지만, 그 동안 우리는 "보안 코딩"의 범위와 보안 숙련 된 개발자에게 기대해야하는 것을 가지고 동일한 페이지에 신속하게 도달해야합니다.
우리는 개발자의 세계에서 보안을 신비화해야합니다.
사이버 보안은 최고의 시간에 다각적이고 다루기 힘든 짐승이며, 보안 코딩은 전체 환경의 한 부분 일 뿐이지 만 전문가의 관심이 필요한 시스템의 복잡한 톱니바퀴입니다.
설문 조사에 따르면 보안 코드로 작업하는 개념은 일반 개발자에게는 상당히 사일로화되었으며, 그 범위는 기본 사항 및 그 이상에 대한 전체적인 견해와는 달리 단일 범주로 제한되는 경우가 많습니다. 개발자는 취약점이없는 새로운 코드를 작성하는 관행보다는 기존 (또는 사전 승인 된) 코드를 사용하는 데 의존한다고 지적했습니다. 타사 구성 요소(특히 패치 적용 및 Log4Shell debacle에 대한 보안 인식이 좋은 예입니다: 인스턴스의 30%가 12월 이후 패치되지 않은 상태로 유지됨)는 기존 코드를 테스트하는 것과 마찬가지로 매우 중요하지만 이것만으로는 기능 수준의 보안 코딩 기능을 충족하지 못합니다.
코드 수준 취약점은 불량한 코딩 패턴을 학습한 개발자에 의해 도입되며, KPI에 보안 코드를 작성하는 데 중점을 두지 않고(보안 문화가 부족한 경우) 이를 허용 가능한 표준으로 강화할 뿐입니다.
보안 리더는 먼저 개발 코호트에 보안 코딩이 수반하는 것에 대한 완전한 그림을 표시하도록 보장함으로써 초기 인식을 개선하고 가장 시급한 지식 격차의 영역을 식별하는 데 많은 노력을 기울일 수 있습니다. 사전 승인된 코드를 테스트하고 스캔하는 것은 하나의 기능이지만, 취약성을 줄이려면 활발히 사용되고 있는 언어 및 프레임워크에서 훌륭하고 안전한 코딩 패턴에 대한 실습 교육이 필요합니다.
컨텍스트는 개발자 업스킬링에서 매우 중요하며, 비즈니스의 보안 목표와 관련하여 이러한 여정을 진행해야 합니다.
많은 조직에서 보안 프로그램을 업그레이드해야 합니다.
지난 십 년 동안 사이버 보안 사고의 급속한 성장을 위해 소프트웨어 기반 기술이 폭발적으로 증가함에 따라, 우리는 모두 귀중한 시스템에서 악용 사례를 발견하기 위해 쉬지 않고 일하는 위협 행위자를 따라 잡기 위해 노력하고 있습니다.
DevSecOps 방법론은 개발자를 포함한 모든 사람이 보안에 대한 책임을 공유한다는 생각에 기반하고 있으며 SDLC의 처음부터 가장 중요한 고려 사항입니다. 문제는 특히 대기업에서 DevSecOps를 표준으로 구현하는 데 매우 멀리 떨어져있을 수 있다는 것입니다. 2017 년 프로젝트 관리 연구소 (Project Management Institute)의 연구에 따르면 조직의 51 %가 여전히 소프트웨어 개발에 Waterfall을 사용하고 있습니다. 이 연구는 이제 다섯 살이 되었지만, 대기업에서 점진적인 변화가 어떻게 일어날 수 있는지를 알면 최신 보안 지향 방법론으로의 급격한 전환이 있었을 가능성은 거의 없다. 이러한 레거시 프로세스는 사이버 위협으로부터 보호하기위한 포괄적 인 전략으로 모든 기반을 커버하려는 보안 전문가에게 힘든 싸움을 일으킬 수 있으며, 개발자와 요구 사항을이 환경에 맞게 조정하는 것은 어려운 일입니다.
그러나 우리는 이것을 변명으로 사용할 수 없습니다. 비즈니스의 보안 전문가는 개발자를 고양 된 전략으로 활용할 수 있습니다. 그들은 단지 그들의 필요에 익숙해지고 그들을 방어 플레이의 일부로 간주해야합니다. 그들은 포괄적 인 교육이 필요하며 보안에 대한 모든 책임은 기술 스택 및 워크 플로우와 관련하여 구현되어야합니다.
보안 코딩 = "너무 어려운"바구니?
Evans Data 연구에 따르면 개발자의 86%가 보안 코딩을 연습하는 것이 어렵다고 답했으며, 개발자 관리자의 92%는 팀이 보안 프레임워크에 대한 더 많은 교육이 필요하다고 인정했습니다. 걱정스럽게도 응답자의 48 %는 고의로 코드에 취약점을 남긴다는 것을 인정했습니다.
이것은 매우 중요한 그림을 그립니다. 일반적으로 개발자는 빈번하고 적절한 교육을받지 못하고 있으며 좋은 보안 관행 및 위생에 충분히 노출되지 않는 것으로 보입니다. 라인 사이를 읽으면 문제의 핵심이 강화됩니다 : 개발자가 작업에서 보안을 고려하는 것이 우선 순위가 아닙니다. 그것과 그들이받는 훈련은 자신감이나 실용적인 기술을 구축하지 못하며, 취약한 코드를 제공하기로 한 결정의 영향을 이해하는 데 도움이되지 않습니다.
식민지 파이프 라인 랜섬웨어 공격은 작년에 가장 파괴적인 공급망 보안 사건 중 하나였으며, 미국 동부 해안의 가스 공급의 절반이 불확실한 기간 동안 차단 될 것이라는 두려움을 불러 일으켰습니다. 고맙게도, 그들은 신속하게 백업하고 운영되었지만 지역 사회에서 큰 걱정이없는 것은 아닙니다. 그것은 일반 대중이 사이버 사건이 반드시 소프트웨어 중심이나 사이버 공격의 위험으로 생각되지 않는 물리적 세계의 요소에 심각한 영향을 미칠 것이라는 전망에 직면 한 도가니의 순간 중 하나였습니다. 그리고 그 모든 혼란은 패치되지 않은 두 가지 오래된 취약점에 의해 가능해졌으며, 그 중 하나는 교활하지만 널리 알려진 SQL 주입이었습니다. 개발자가 취약한 코드를 제공하기로 결정했을 때 실제로 무엇이 위험에 처해 있는지 알고 있다면 수용 가능한 비즈니스 위험 인 시나리오가 없다는 것을 빨리 알게 될 것입니다.
기능적인 "P-P-T"는 개발자의 몫이 아닙니다.
사람, 프로세스 및 도구의 유명한 "황금 삼각형"은 신중하게 고려 된 전략 없이는 달성 할 수 없으며 개발자는 필요와 도전을 고려하지 않고 작업 보안 프로세스에 동화 될 수있는 위치에 있지 않습니다.
개발자 중심의 보안을 강화하기 위해서는 상당한 문화 전환이 필요하며 엔지니어와 보안 팀 모두를 더욱 명확하게 만드는 교육 경로로 시작됩니다.
이 기사의 버전은 TechRepublic에 나타났습니다. 여기에서 업데이트되고 신디케이트되었습니다.
보안 팀과 개발자 팀의 목표가 일치하는 환경을 조성하기 위한 오르막길이지만 필수적인 전투였습니다. 우리는 갈 길이 멀지만, 소프트웨어 보안에 대한 공동 책임의 문을 여는 데 필요한 시너지 효과를 방해하는 장애물은 매우 분명 해지고 있습니다. 똑똑한 기업은 이러한 함정을 피하고, 생산적인 방법을 찾고, DevSecOps를 인력 중심의 잠재력을 최대한 발휘할 수 있도록 전략을 발전시키고자 합니다.
내가 예상하지 못했던 것은 보안 코딩 행위를 구성하는 것에 대한 인식이 논쟁의 여지가 있다는 것입니다. Evans Data와의 공동 연구에 따르면이 감정은 흑백으로 밝혀졌습니다. 개발자 주도 보안 현황 2022 설문조사에서는 1200 명의 활성 개발자의 주요 통찰력과 경험을 조사하여 보안 영역에서의 태도와 도전 과제를 조명합니다.
헤드 라인 결과 중 하나는 개발자의 14 %만이 코딩 할 때 보안을 우선 순위로 간주한다는 것입니다. 이것은 개선의 여지가 엄청나다는 것을 보여 주지만, 우리가 이미 알고있는 것을 확인합니다 : 기능 구축은 개발자의 세계에서 왕이며, 보안은 DNA의 일부로 만들기 위해 제대로 갖추어져 있지 않습니다. 그러나 보안 코딩이 무엇을 의미하는지에 대한 개발자 정의에 대한 데이터와 결합되면 우려의 원인이됩니다.
이러한 인식은 근무일의 개발자 경험에 의해 주도되며, 많은 조직의 환경에 대해 말하며, 이는 개발자가 일반적인 취약점과의 싸움에서 초점이 아니라는 것입니다. 그들의 활성화는 중요하지만, 그 동안 우리는 "보안 코딩"의 범위와 보안 숙련 된 개발자에게 기대해야하는 것을 가지고 동일한 페이지에 신속하게 도달해야합니다.
우리는 개발자의 세계에서 보안을 신비화해야합니다.
사이버 보안은 최고의 시간에 다각적이고 다루기 힘든 짐승이며, 보안 코딩은 전체 환경의 한 부분 일 뿐이지 만 전문가의 관심이 필요한 시스템의 복잡한 톱니바퀴입니다.
설문 조사에 따르면 보안 코드로 작업하는 개념은 일반 개발자에게는 상당히 사일로화되었으며, 그 범위는 기본 사항 및 그 이상에 대한 전체적인 견해와는 달리 단일 범주로 제한되는 경우가 많습니다. 개발자는 취약점이없는 새로운 코드를 작성하는 관행보다는 기존 (또는 사전 승인 된) 코드를 사용하는 데 의존한다고 지적했습니다. 타사 구성 요소(특히 패치 적용 및 Log4Shell debacle에 대한 보안 인식이 좋은 예입니다: 인스턴스의 30%가 12월 이후 패치되지 않은 상태로 유지됨)는 기존 코드를 테스트하는 것과 마찬가지로 매우 중요하지만 이것만으로는 기능 수준의 보안 코딩 기능을 충족하지 못합니다.
코드 수준 취약점은 불량한 코딩 패턴을 학습한 개발자에 의해 도입되며, KPI에 보안 코드를 작성하는 데 중점을 두지 않고(보안 문화가 부족한 경우) 이를 허용 가능한 표준으로 강화할 뿐입니다.
보안 리더는 먼저 개발 코호트에 보안 코딩이 수반하는 것에 대한 완전한 그림을 표시하도록 보장함으로써 초기 인식을 개선하고 가장 시급한 지식 격차의 영역을 식별하는 데 많은 노력을 기울일 수 있습니다. 사전 승인된 코드를 테스트하고 스캔하는 것은 하나의 기능이지만, 취약성을 줄이려면 활발히 사용되고 있는 언어 및 프레임워크에서 훌륭하고 안전한 코딩 패턴에 대한 실습 교육이 필요합니다.
컨텍스트는 개발자 업스킬링에서 매우 중요하며, 비즈니스의 보안 목표와 관련하여 이러한 여정을 진행해야 합니다.
많은 조직에서 보안 프로그램을 업그레이드해야 합니다.
지난 십 년 동안 사이버 보안 사고의 급속한 성장을 위해 소프트웨어 기반 기술이 폭발적으로 증가함에 따라, 우리는 모두 귀중한 시스템에서 악용 사례를 발견하기 위해 쉬지 않고 일하는 위협 행위자를 따라 잡기 위해 노력하고 있습니다.
DevSecOps 방법론은 개발자를 포함한 모든 사람이 보안에 대한 책임을 공유한다는 생각에 기반하고 있으며 SDLC의 처음부터 가장 중요한 고려 사항입니다. 문제는 특히 대기업에서 DevSecOps를 표준으로 구현하는 데 매우 멀리 떨어져있을 수 있다는 것입니다. 2017 년 프로젝트 관리 연구소 (Project Management Institute)의 연구에 따르면 조직의 51 %가 여전히 소프트웨어 개발에 Waterfall을 사용하고 있습니다. 이 연구는 이제 다섯 살이 되었지만, 대기업에서 점진적인 변화가 어떻게 일어날 수 있는지를 알면 최신 보안 지향 방법론으로의 급격한 전환이 있었을 가능성은 거의 없다. 이러한 레거시 프로세스는 사이버 위협으로부터 보호하기위한 포괄적 인 전략으로 모든 기반을 커버하려는 보안 전문가에게 힘든 싸움을 일으킬 수 있으며, 개발자와 요구 사항을이 환경에 맞게 조정하는 것은 어려운 일입니다.
그러나 우리는 이것을 변명으로 사용할 수 없습니다. 비즈니스의 보안 전문가는 개발자를 고양 된 전략으로 활용할 수 있습니다. 그들은 단지 그들의 필요에 익숙해지고 그들을 방어 플레이의 일부로 간주해야합니다. 그들은 포괄적 인 교육이 필요하며 보안에 대한 모든 책임은 기술 스택 및 워크 플로우와 관련하여 구현되어야합니다.
보안 코딩 = "너무 어려운"바구니?
Evans Data 연구에 따르면 개발자의 86%가 보안 코딩을 연습하는 것이 어렵다고 답했으며, 개발자 관리자의 92%는 팀이 보안 프레임워크에 대한 더 많은 교육이 필요하다고 인정했습니다. 걱정스럽게도 응답자의 48 %는 고의로 코드에 취약점을 남긴다는 것을 인정했습니다.
이것은 매우 중요한 그림을 그립니다. 일반적으로 개발자는 빈번하고 적절한 교육을받지 못하고 있으며 좋은 보안 관행 및 위생에 충분히 노출되지 않는 것으로 보입니다. 라인 사이를 읽으면 문제의 핵심이 강화됩니다 : 개발자가 작업에서 보안을 고려하는 것이 우선 순위가 아닙니다. 그것과 그들이받는 훈련은 자신감이나 실용적인 기술을 구축하지 못하며, 취약한 코드를 제공하기로 한 결정의 영향을 이해하는 데 도움이되지 않습니다.
식민지 파이프 라인 랜섬웨어 공격은 작년에 가장 파괴적인 공급망 보안 사건 중 하나였으며, 미국 동부 해안의 가스 공급의 절반이 불확실한 기간 동안 차단 될 것이라는 두려움을 불러 일으켰습니다. 고맙게도, 그들은 신속하게 백업하고 운영되었지만 지역 사회에서 큰 걱정이없는 것은 아닙니다. 그것은 일반 대중이 사이버 사건이 반드시 소프트웨어 중심이나 사이버 공격의 위험으로 생각되지 않는 물리적 세계의 요소에 심각한 영향을 미칠 것이라는 전망에 직면 한 도가니의 순간 중 하나였습니다. 그리고 그 모든 혼란은 패치되지 않은 두 가지 오래된 취약점에 의해 가능해졌으며, 그 중 하나는 교활하지만 널리 알려진 SQL 주입이었습니다. 개발자가 취약한 코드를 제공하기로 결정했을 때 실제로 무엇이 위험에 처해 있는지 알고 있다면 수용 가능한 비즈니스 위험 인 시나리오가 없다는 것을 빨리 알게 될 것입니다.
기능적인 "P-P-T"는 개발자의 몫이 아닙니다.
사람, 프로세스 및 도구의 유명한 "황금 삼각형"은 신중하게 고려 된 전략 없이는 달성 할 수 없으며 개발자는 필요와 도전을 고려하지 않고 작업 보안 프로세스에 동화 될 수있는 위치에 있지 않습니다.
개발자 중심의 보안을 강화하기 위해서는 상당한 문화 전환이 필요하며 엔지니어와 보안 팀 모두를 더욱 명확하게 만드는 교육 경로로 시작됩니다.
아래 링크를 클릭하여 이 자료의 PDF를 다운로드하세요.
Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
보고서 보기데모 예약
최고 경영자, 회장 겸 공동 설립자
피터 댄히외는 보안 컨설턴트로 12년 이상 경력을 쌓았으며, 조직, 시스템 및 개인의 보안 취약점을 타겟팅하고 평가하는 방법에 대한 공격 기법을 가르치는 SANS의 수석 강사로 8년 이상 활동한 세계적으로 인정받는 보안 전문가입니다. 2016년에는 호주에서 가장 멋진 기술자 중 한 명으로 선정(비즈니스 인사이더)되었고, 올해의 사이버 보안 전문가(AISA - 호주 정보 보안 협회)로 선정되었으며, GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA 자격증을 보유하고 있습니다.
이 기사의 버전은 TechRepublic에 나타났습니다. 여기에서 업데이트되고 신디케이트되었습니다.
보안 팀과 개발자 팀의 목표가 일치하는 환경을 조성하기 위한 오르막길이지만 필수적인 전투였습니다. 우리는 갈 길이 멀지만, 소프트웨어 보안에 대한 공동 책임의 문을 여는 데 필요한 시너지 효과를 방해하는 장애물은 매우 분명 해지고 있습니다. 똑똑한 기업은 이러한 함정을 피하고, 생산적인 방법을 찾고, DevSecOps를 인력 중심의 잠재력을 최대한 발휘할 수 있도록 전략을 발전시키고자 합니다.
내가 예상하지 못했던 것은 보안 코딩 행위를 구성하는 것에 대한 인식이 논쟁의 여지가 있다는 것입니다. Evans Data와의 공동 연구에 따르면이 감정은 흑백으로 밝혀졌습니다. 개발자 주도 보안 현황 2022 설문조사에서는 1200 명의 활성 개발자의 주요 통찰력과 경험을 조사하여 보안 영역에서의 태도와 도전 과제를 조명합니다.
헤드 라인 결과 중 하나는 개발자의 14 %만이 코딩 할 때 보안을 우선 순위로 간주한다는 것입니다. 이것은 개선의 여지가 엄청나다는 것을 보여 주지만, 우리가 이미 알고있는 것을 확인합니다 : 기능 구축은 개발자의 세계에서 왕이며, 보안은 DNA의 일부로 만들기 위해 제대로 갖추어져 있지 않습니다. 그러나 보안 코딩이 무엇을 의미하는지에 대한 개발자 정의에 대한 데이터와 결합되면 우려의 원인이됩니다.
이러한 인식은 근무일의 개발자 경험에 의해 주도되며, 많은 조직의 환경에 대해 말하며, 이는 개발자가 일반적인 취약점과의 싸움에서 초점이 아니라는 것입니다. 그들의 활성화는 중요하지만, 그 동안 우리는 "보안 코딩"의 범위와 보안 숙련 된 개발자에게 기대해야하는 것을 가지고 동일한 페이지에 신속하게 도달해야합니다.
우리는 개발자의 세계에서 보안을 신비화해야합니다.
사이버 보안은 최고의 시간에 다각적이고 다루기 힘든 짐승이며, 보안 코딩은 전체 환경의 한 부분 일 뿐이지 만 전문가의 관심이 필요한 시스템의 복잡한 톱니바퀴입니다.
설문 조사에 따르면 보안 코드로 작업하는 개념은 일반 개발자에게는 상당히 사일로화되었으며, 그 범위는 기본 사항 및 그 이상에 대한 전체적인 견해와는 달리 단일 범주로 제한되는 경우가 많습니다. 개발자는 취약점이없는 새로운 코드를 작성하는 관행보다는 기존 (또는 사전 승인 된) 코드를 사용하는 데 의존한다고 지적했습니다. 타사 구성 요소(특히 패치 적용 및 Log4Shell debacle에 대한 보안 인식이 좋은 예입니다: 인스턴스의 30%가 12월 이후 패치되지 않은 상태로 유지됨)는 기존 코드를 테스트하는 것과 마찬가지로 매우 중요하지만 이것만으로는 기능 수준의 보안 코딩 기능을 충족하지 못합니다.
코드 수준 취약점은 불량한 코딩 패턴을 학습한 개발자에 의해 도입되며, KPI에 보안 코드를 작성하는 데 중점을 두지 않고(보안 문화가 부족한 경우) 이를 허용 가능한 표준으로 강화할 뿐입니다.
보안 리더는 먼저 개발 코호트에 보안 코딩이 수반하는 것에 대한 완전한 그림을 표시하도록 보장함으로써 초기 인식을 개선하고 가장 시급한 지식 격차의 영역을 식별하는 데 많은 노력을 기울일 수 있습니다. 사전 승인된 코드를 테스트하고 스캔하는 것은 하나의 기능이지만, 취약성을 줄이려면 활발히 사용되고 있는 언어 및 프레임워크에서 훌륭하고 안전한 코딩 패턴에 대한 실습 교육이 필요합니다.
컨텍스트는 개발자 업스킬링에서 매우 중요하며, 비즈니스의 보안 목표와 관련하여 이러한 여정을 진행해야 합니다.
많은 조직에서 보안 프로그램을 업그레이드해야 합니다.
지난 십 년 동안 사이버 보안 사고의 급속한 성장을 위해 소프트웨어 기반 기술이 폭발적으로 증가함에 따라, 우리는 모두 귀중한 시스템에서 악용 사례를 발견하기 위해 쉬지 않고 일하는 위협 행위자를 따라 잡기 위해 노력하고 있습니다.
DevSecOps 방법론은 개발자를 포함한 모든 사람이 보안에 대한 책임을 공유한다는 생각에 기반하고 있으며 SDLC의 처음부터 가장 중요한 고려 사항입니다. 문제는 특히 대기업에서 DevSecOps를 표준으로 구현하는 데 매우 멀리 떨어져있을 수 있다는 것입니다. 2017 년 프로젝트 관리 연구소 (Project Management Institute)의 연구에 따르면 조직의 51 %가 여전히 소프트웨어 개발에 Waterfall을 사용하고 있습니다. 이 연구는 이제 다섯 살이 되었지만, 대기업에서 점진적인 변화가 어떻게 일어날 수 있는지를 알면 최신 보안 지향 방법론으로의 급격한 전환이 있었을 가능성은 거의 없다. 이러한 레거시 프로세스는 사이버 위협으로부터 보호하기위한 포괄적 인 전략으로 모든 기반을 커버하려는 보안 전문가에게 힘든 싸움을 일으킬 수 있으며, 개발자와 요구 사항을이 환경에 맞게 조정하는 것은 어려운 일입니다.
그러나 우리는 이것을 변명으로 사용할 수 없습니다. 비즈니스의 보안 전문가는 개발자를 고양 된 전략으로 활용할 수 있습니다. 그들은 단지 그들의 필요에 익숙해지고 그들을 방어 플레이의 일부로 간주해야합니다. 그들은 포괄적 인 교육이 필요하며 보안에 대한 모든 책임은 기술 스택 및 워크 플로우와 관련하여 구현되어야합니다.
보안 코딩 = "너무 어려운"바구니?
Evans Data 연구에 따르면 개발자의 86%가 보안 코딩을 연습하는 것이 어렵다고 답했으며, 개발자 관리자의 92%는 팀이 보안 프레임워크에 대한 더 많은 교육이 필요하다고 인정했습니다. 걱정스럽게도 응답자의 48 %는 고의로 코드에 취약점을 남긴다는 것을 인정했습니다.
이것은 매우 중요한 그림을 그립니다. 일반적으로 개발자는 빈번하고 적절한 교육을받지 못하고 있으며 좋은 보안 관행 및 위생에 충분히 노출되지 않는 것으로 보입니다. 라인 사이를 읽으면 문제의 핵심이 강화됩니다 : 개발자가 작업에서 보안을 고려하는 것이 우선 순위가 아닙니다. 그것과 그들이받는 훈련은 자신감이나 실용적인 기술을 구축하지 못하며, 취약한 코드를 제공하기로 한 결정의 영향을 이해하는 데 도움이되지 않습니다.
식민지 파이프 라인 랜섬웨어 공격은 작년에 가장 파괴적인 공급망 보안 사건 중 하나였으며, 미국 동부 해안의 가스 공급의 절반이 불확실한 기간 동안 차단 될 것이라는 두려움을 불러 일으켰습니다. 고맙게도, 그들은 신속하게 백업하고 운영되었지만 지역 사회에서 큰 걱정이없는 것은 아닙니다. 그것은 일반 대중이 사이버 사건이 반드시 소프트웨어 중심이나 사이버 공격의 위험으로 생각되지 않는 물리적 세계의 요소에 심각한 영향을 미칠 것이라는 전망에 직면 한 도가니의 순간 중 하나였습니다. 그리고 그 모든 혼란은 패치되지 않은 두 가지 오래된 취약점에 의해 가능해졌으며, 그 중 하나는 교활하지만 널리 알려진 SQL 주입이었습니다. 개발자가 취약한 코드를 제공하기로 결정했을 때 실제로 무엇이 위험에 처해 있는지 알고 있다면 수용 가능한 비즈니스 위험 인 시나리오가 없다는 것을 빨리 알게 될 것입니다.
기능적인 "P-P-T"는 개발자의 몫이 아닙니다.
사람, 프로세스 및 도구의 유명한 "황금 삼각형"은 신중하게 고려 된 전략 없이는 달성 할 수 없으며 개발자는 필요와 도전을 고려하지 않고 작업 보안 프로세스에 동화 될 수있는 위치에 있지 않습니다.
개발자 중심의 보안을 강화하기 위해서는 상당한 문화 전환이 필요하며 엔지니어와 보안 팀 모두를 더욱 명확하게 만드는 교육 경로로 시작됩니다.
.png)
