귀사는 정말 DevSec을 사용할 준비가 되어 있습니까?테스트해 보세요.
2020년도 겨우 절반이 지났지만, 우리는 이미 암울한 데이터 침해 기록을 세울 것으로 예상됩니다. 도난당한 데이터 273% 증가 2019년 상반기와 비교했을 때요즘에는 데이터의 양을 묻는 것이 더 정확합니다. 하지 않았어 아직 도난당했습니다.COVID-19 팬데믹과 같은 세계적 사건으로 인해 이러한 공격의 빈도와 위력이 증가했을 뿐 아니라 공격 대상도 점점 더 취약해지고 있습니다.
보안은 더 이상 선택 사항이 아니며 선제 공격에 초점을 맞춰야 한다는 것은 우리 모두가 오래전부터 알고 있었던 사실입니다.이것이 효과적이려면, 모두들 SDLC에서는 특히 개발자가 보안을 인식해야 합니다.이 부분은 의 “DevSec” 부분입니다. 데브섹옵스기후에 맞는 이상적인 소프트웨어 개발 방법론이지만 많은 조직이 이를 효과적으로 실행할 준비가 되어 있지 않습니다.
조직을 염두에 두고 역할의 맥락에서 이러한 질문에 대해 생각해 보십시오.DevSec 테스트에 적용하면 어떤 결과가 나올까요?
DevSec 자체 평가: SDLC 가든은 보안을 잘 아는 엔지니어를 양성할 준비가 되었나요?
- 내부 개발 프로세스에서 보안을 최우선으로 생각하나요?
다양한 사이버 보안 위험 요인으로 인해 평균적인 CISO는 밤을 지새울 수 있지만 우려되는 현실은 많은 기업이 보안을 최우선 과제로 삼고 있지만 내부 접근 방식이 잠재적 재해 (또는 적어도 AppSec 팀의 엄청난 골칫거리와 소프트웨어 배송 지연) 를 완화할 만큼 강력하지 않을 수 있다는 것입니다.
DevSecOps는 현재 보안 요충지일 수 있지만 이 방법론을 사용하는 회사는 거의 없습니다.아직 애자일 (또는 워터폴) 을 사용하고 있다면 보안은 여전히 전문가의 영역으로 여겨지는데, 이들은 프로세스에서 멀리 떨어져 SDLC 후반부에 활성화되어 코드에 대한 핫픽스로 개발자의 하루를 망치게 됩니다.이런 환경에서는 개발자들이 기능 구축을 좋아하고 우선순위를 정하기 때문에 DevSec 문화를 주도하는 것은 어려울 것입니다. 개발자들은 기능 구축을 선호하고 우선순위를 정하며, 단순히 보안에 대한 충분한 실무 경험이 없었기 때문에 바람직한 기술 향상 경로로 볼 수 없을 것입니다.사실, 개발자들이 접하는 접점은 좌절과 부정적일 수 있습니다.이 문제를 신속히 해결하여 소프트웨어 개발 프로세스에 관련된 모든 사람이 한 눈에 파악할 수 있도록 해야 합니다.
- 위협 모델링과 관련하여 조직이 여전히 따라잡고 있습니까?
정말 놀라운 통계입니다. 중소기업의 60% 가 사이버 공격 성공 후 6개월 이내에 사업을 중단합니다.다른 재해와 마찬가지로 적절한 계획 없이는 그 영향이 훨씬 더 커집니다.
위협 모델링은 AppSec 전문가가 공격 표면의 전체 범위를 평가하고 적절한 방어, 대책 및 계획을 구성할 수 있도록 하는 보안 모범 사례의 중요한 요소입니다.DevSecOps를 완전히 수용한 기업에서는 CI/CD 파이프라인 초기에 보안을 구현하여 과거처럼 생산 속도를 늦추지 않도록 할 수 있습니다.보안, 보안 코딩, 지속적 배포는 모두 프로세스의 일부이며, 개발 팀에게는 빈틈없는 코드를 내보내는 엔진의 주요 구성 요소가 되는 데 필요한 리소스와 노출을 제공합니다.
- 개발 관리자가 보안 모범 사례에 우선 순위를 두나요?
좋든 싫든 개발 관리자는 팀의 역할 모델입니다.사무실에서 슬리퍼를 신고 출근할 때나 직원들이 “좋은 성과를 내는” 방법 등 문화와 분위기에 관련된 것만은 아닙니다.팀의 업무 우선순위는 불가피하게 팀원들에게 흡수될 수밖에 없습니다. 보안이 핵심 목표의 일부가 아니거나 교육 및 지원 측면에서 계획된 것이 아니라면 그 밑에 있는 엔지니어들이 기회를 놓치고 비즈니스는 예상보다 더 큰 위험에 처하게 될 것입니다.
- 개발자들이 보안에 신경을 써야 할 이유가 있나요?
제 경험상 누군가를 화나게 하는 가장 빠른 방법은 이유를 말하지 않고 현재의 접근 방식과는 다른 일을 해야 한다고 말하는 것입니다.
“변경하라”는 말은 이전 접근 방식이 잘못되었다는 것을 의미하지만, 대부분의 경우 나중에 작업을 더 쉽고 효율적으로 만들 수 있는 개선 사항일 뿐입니다.DevSec 운동을 진정으로 받아들이려면 개발자들이 처음부터 보안에 관심을 가져야 할 이유가 있어야 합니다. 결국 대부분의 조직에서 보안은 여전히 “다른 사람의 문제”입니다 (예: AppSec 마법사가 멀리, 멀리, 멀리, 멀리 다른 방에 갇혀 있음).
보안이 공동 책임이 아닌 경우 DevSecOps는 제대로 작동하지 않습니다.개발자가 각자의 역할을 수행하려면 적절한 도구, 지원 및 교육이 필요합니다... 그리고 이를 도입하고 전체 보안 프로그램의 일부로 완벽하게 구현하려면 시간이 필요합니다.최악의 접근 방식은 압도하고 소외감을 주는 접근 방식입니다. 개발자들이 경쟁하는 우선 순위가 너무 많아서 미쳐버리지 않고 관리할 수 있는 도움이 없는 경우가 이런 경우일 수 있습니다.이는 문화적 변화이며 하룻밤 사이에 일어날 수 있는 일이 아닙니다.
- 마법의 보안 유니콘 몇 개만 있으면 많은 임무를 맡을 수 있으신가요?
보안 전문가가 참여합니다. 매우 부족한 공급, 현재 사용 가능한 것보다 훨씬 더 많은 것이 필요합니다.당연한 일이지만, 보안에 초점을 맞춘 역할로 옮기는 개발자의 수가 점점 더 많아지고 있습니다.일반적으로 이들은 “보안 엔지니어” 또는 “DevOps 엔지니어”와 같은 직함을 가질 수 있습니다 (천천히 이 제목이 다음과 같이 바뀌는 것을 보게 될 것입니다). 데브섹옵스 엔지니어, 운이 좋으면!).Gun DevOps 엔지니어는 실제 CI/CD 파이프라인을 사용하여 배포하면서 거의 모든 애플리케이션을 위한 기능을 개발할 수 있습니다.이들은 모든 것을 처음부터 끝까지 수행하며 일반적으로 충분한 보안 인식을 갖추고 있습니다.그런 면에서 보면 마법과도 같고, 그 결과 희귀합니다.
그러나 일부 회사는 이러한 전문 엔지니어를 고용하여 팀으로 구성한 다음 개발 프로세스의 모든 단계에서 모든 보안 문제를 해결할 것으로 예상하는 실수를 저지르는데, 이것만으로도 만병통치약입니다.DevSecOps 마술사들에게 과부하를 주면 처음부터 시작하던 곳에서 끝나게 됩니다. 애초에 고용된 점검, 균형, 보안 정밀도 없이 안전하지 않은 코드를 배포하는 셈이죠.개발 팀이 전반적으로 숙련되고 긍정적인 보안 환경에서 육성되어 의미 있는 방식으로 부하를 분담할 수 있는 역량을 갖추는 것이 무엇보다 중요합니다.
조직에서 보고 싶은 변경 사항을 찾아보세요.
보안 프로그램의 일환으로 강력한 교육을 구현하면 개발 코호트의 숨겨진 요소를 발견할 수 있습니다.이들은 일상 업무에서 겪었을 수 있는 부정적인 경험에도 불구하고 보안 코딩 및 보안 모범 사례에 대한 열정을 갖고 있는 사람들입니다.이러한 사람들은 팀 내 보안 챔피언의 주요 후보입니다. 즉, 다른 사람들에게 좋은 본보기가 되고 인지도를 높이며 참여 이니셔티브를 지원하는 보안과 엔지니어링 간의 접점입니다.이들의 대인 관계 기술은 보안의 즐거움을 널리 퍼뜨리고 경영진과 보안 팀에 개발자의 요구를 대변하는 데에도 매우 중요합니다.
“나에게 무슨 소용이 있니?”대화는 긍정적인 진전입니다.
아무리 고귀한 인간이라도 익숙하지 않은 영역에 발을 담글 수 있는 “당근” 같은 것이 필요하거나 배움이 그다지 즐겁지 않을 수도 있는 활동을 할 수 있습니다.
“dev”에서 “DevSec”으로 도약하는 것은 개발자 경력에 큰 도움이 됩니다.보안을 잘 아는 개발자들은 보안을 이해하고, 자신이 제어할 수 있는 영역에서 보안을 책임지고, 유일한 품질 코드는 보안 코드라는 점을 이해하고 운영하기 위해 열심히 노력해 왔습니다.일반적으로 개발자는 개선하고, 새로운 문제를 해결하고, 동료들 사이에서 돋보일 수 있는 부러워할 만한 기능을 만들고자 합니다.더 높은 수준의 소프트웨어 개발에 도달할 수 있는 경로를 제공하면 모두가 윈윈할 수 있습니다.
DevSec 드림 팀을 구성하기에 너무 늦은 때는 없습니다.
개발자를 관리하거나, AppSec 인식 팀을 이끌거나, 보안 프로그램 전략을 고안하는 데 열심히 노력하는 많은 사람 중 한 명이라면 지금이 바로 왼쪽으로 “이동”하는 것보다 한 가지 더 나은 방향으로 나아가야 할 때입니다.적절한 교육, 도구 및 환경을 갖추면 개발자를 위한 보안 인큐베이터를 만들어 모든 당사자에게 큰 이익을 줄 수 있습니다.이 체크리스트에서 개선해야 할 몇 가지 영역을 강조했다면 SDLC를 시작할 때부터 위험을 줄일 수 있는 DevSec 주도 엔지니어링 부서에 대비할 수 있는 좋은 기회가 된 것입니다.
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
2020년도 겨우 절반이 지났지만, 우리는 이미 암울한 데이터 침해 기록을 세울 것으로 예상됩니다. 도난당한 데이터 273% 증가 2019년 상반기와 비교했을 때요즘에는 데이터의 양을 묻는 것이 더 정확합니다. 하지 않았어 아직 도난당했습니다.COVID-19 팬데믹과 같은 세계적 사건으로 인해 이러한 공격의 빈도와 위력이 증가했을 뿐 아니라 공격 대상도 점점 더 취약해지고 있습니다.
보안은 더 이상 선택 사항이 아니며 선제 공격에 초점을 맞춰야 한다는 것은 우리 모두가 오래전부터 알고 있었던 사실입니다.이것이 효과적이려면, 모두들 SDLC에서는 특히 개발자가 보안을 인식해야 합니다.이 부분은 의 “DevSec” 부분입니다. 데브섹옵스기후에 맞는 이상적인 소프트웨어 개발 방법론이지만 많은 조직이 이를 효과적으로 실행할 준비가 되어 있지 않습니다.
조직을 염두에 두고 역할의 맥락에서 이러한 질문에 대해 생각해 보십시오.DevSec 테스트에 적용하면 어떤 결과가 나올까요?
DevSec 자체 평가: SDLC 가든은 보안을 잘 아는 엔지니어를 양성할 준비가 되었나요?
- 내부 개발 프로세스에서 보안을 최우선으로 생각하나요?
다양한 사이버 보안 위험 요인으로 인해 평균적인 CISO는 밤을 지새울 수 있지만 우려되는 현실은 많은 기업이 보안을 최우선 과제로 삼고 있지만 내부 접근 방식이 잠재적 재해 (또는 적어도 AppSec 팀의 엄청난 골칫거리와 소프트웨어 배송 지연) 를 완화할 만큼 강력하지 않을 수 있다는 것입니다.
DevSecOps는 현재 보안 요충지일 수 있지만 이 방법론을 사용하는 회사는 거의 없습니다.아직 애자일 (또는 워터폴) 을 사용하고 있다면 보안은 여전히 전문가의 영역으로 여겨지는데, 이들은 프로세스에서 멀리 떨어져 SDLC 후반부에 활성화되어 코드에 대한 핫픽스로 개발자의 하루를 망치게 됩니다.이런 환경에서는 개발자들이 기능 구축을 좋아하고 우선순위를 정하기 때문에 DevSec 문화를 주도하는 것은 어려울 것입니다. 개발자들은 기능 구축을 선호하고 우선순위를 정하며, 단순히 보안에 대한 충분한 실무 경험이 없었기 때문에 바람직한 기술 향상 경로로 볼 수 없을 것입니다.사실, 개발자들이 접하는 접점은 좌절과 부정적일 수 있습니다.이 문제를 신속히 해결하여 소프트웨어 개발 프로세스에 관련된 모든 사람이 한 눈에 파악할 수 있도록 해야 합니다.
- 위협 모델링과 관련하여 조직이 여전히 따라잡고 있습니까?
정말 놀라운 통계입니다. 중소기업의 60% 가 사이버 공격 성공 후 6개월 이내에 사업을 중단합니다.다른 재해와 마찬가지로 적절한 계획 없이는 그 영향이 훨씬 더 커집니다.
위협 모델링은 AppSec 전문가가 공격 표면의 전체 범위를 평가하고 적절한 방어, 대책 및 계획을 구성할 수 있도록 하는 보안 모범 사례의 중요한 요소입니다.DevSecOps를 완전히 수용한 기업에서는 CI/CD 파이프라인 초기에 보안을 구현하여 과거처럼 생산 속도를 늦추지 않도록 할 수 있습니다.보안, 보안 코딩, 지속적 배포는 모두 프로세스의 일부이며, 개발 팀에게는 빈틈없는 코드를 내보내는 엔진의 주요 구성 요소가 되는 데 필요한 리소스와 노출을 제공합니다.
- 개발 관리자가 보안 모범 사례에 우선 순위를 두나요?
좋든 싫든 개발 관리자는 팀의 역할 모델입니다.사무실에서 슬리퍼를 신고 출근할 때나 직원들이 “좋은 성과를 내는” 방법 등 문화와 분위기에 관련된 것만은 아닙니다.팀의 업무 우선순위는 불가피하게 팀원들에게 흡수될 수밖에 없습니다. 보안이 핵심 목표의 일부가 아니거나 교육 및 지원 측면에서 계획된 것이 아니라면 그 밑에 있는 엔지니어들이 기회를 놓치고 비즈니스는 예상보다 더 큰 위험에 처하게 될 것입니다.
- 개발자들이 보안에 신경을 써야 할 이유가 있나요?
제 경험상 누군가를 화나게 하는 가장 빠른 방법은 이유를 말하지 않고 현재의 접근 방식과는 다른 일을 해야 한다고 말하는 것입니다.
“변경하라”는 말은 이전 접근 방식이 잘못되었다는 것을 의미하지만, 대부분의 경우 나중에 작업을 더 쉽고 효율적으로 만들 수 있는 개선 사항일 뿐입니다.DevSec 운동을 진정으로 받아들이려면 개발자들이 처음부터 보안에 관심을 가져야 할 이유가 있어야 합니다. 결국 대부분의 조직에서 보안은 여전히 “다른 사람의 문제”입니다 (예: AppSec 마법사가 멀리, 멀리, 멀리, 멀리 다른 방에 갇혀 있음).
보안이 공동 책임이 아닌 경우 DevSecOps는 제대로 작동하지 않습니다.개발자가 각자의 역할을 수행하려면 적절한 도구, 지원 및 교육이 필요합니다... 그리고 이를 도입하고 전체 보안 프로그램의 일부로 완벽하게 구현하려면 시간이 필요합니다.최악의 접근 방식은 압도하고 소외감을 주는 접근 방식입니다. 개발자들이 경쟁하는 우선 순위가 너무 많아서 미쳐버리지 않고 관리할 수 있는 도움이 없는 경우가 이런 경우일 수 있습니다.이는 문화적 변화이며 하룻밤 사이에 일어날 수 있는 일이 아닙니다.
- 마법의 보안 유니콘 몇 개만 있으면 많은 임무를 맡을 수 있으신가요?
보안 전문가가 참여합니다. 매우 부족한 공급, 현재 사용 가능한 것보다 훨씬 더 많은 것이 필요합니다.당연한 일이지만, 보안에 초점을 맞춘 역할로 옮기는 개발자의 수가 점점 더 많아지고 있습니다.일반적으로 이들은 “보안 엔지니어” 또는 “DevOps 엔지니어”와 같은 직함을 가질 수 있습니다 (천천히 이 제목이 다음과 같이 바뀌는 것을 보게 될 것입니다). 데브섹옵스 엔지니어, 운이 좋으면!).Gun DevOps 엔지니어는 실제 CI/CD 파이프라인을 사용하여 배포하면서 거의 모든 애플리케이션을 위한 기능을 개발할 수 있습니다.이들은 모든 것을 처음부터 끝까지 수행하며 일반적으로 충분한 보안 인식을 갖추고 있습니다.그런 면에서 보면 마법과도 같고, 그 결과 희귀합니다.
그러나 일부 회사는 이러한 전문 엔지니어를 고용하여 팀으로 구성한 다음 개발 프로세스의 모든 단계에서 모든 보안 문제를 해결할 것으로 예상하는 실수를 저지르는데, 이것만으로도 만병통치약입니다.DevSecOps 마술사들에게 과부하를 주면 처음부터 시작하던 곳에서 끝나게 됩니다. 애초에 고용된 점검, 균형, 보안 정밀도 없이 안전하지 않은 코드를 배포하는 셈이죠.개발 팀이 전반적으로 숙련되고 긍정적인 보안 환경에서 육성되어 의미 있는 방식으로 부하를 분담할 수 있는 역량을 갖추는 것이 무엇보다 중요합니다.
조직에서 보고 싶은 변경 사항을 찾아보세요.
보안 프로그램의 일환으로 강력한 교육을 구현하면 개발 코호트의 숨겨진 요소를 발견할 수 있습니다.이들은 일상 업무에서 겪었을 수 있는 부정적인 경험에도 불구하고 보안 코딩 및 보안 모범 사례에 대한 열정을 갖고 있는 사람들입니다.이러한 사람들은 팀 내 보안 챔피언의 주요 후보입니다. 즉, 다른 사람들에게 좋은 본보기가 되고 인지도를 높이며 참여 이니셔티브를 지원하는 보안과 엔지니어링 간의 접점입니다.이들의 대인 관계 기술은 보안의 즐거움을 널리 퍼뜨리고 경영진과 보안 팀에 개발자의 요구를 대변하는 데에도 매우 중요합니다.
“나에게 무슨 소용이 있니?”대화는 긍정적인 진전입니다.
아무리 고귀한 인간이라도 익숙하지 않은 영역에 발을 담글 수 있는 “당근” 같은 것이 필요하거나 배움이 그다지 즐겁지 않을 수도 있는 활동을 할 수 있습니다.
“dev”에서 “DevSec”으로 도약하는 것은 개발자 경력에 큰 도움이 됩니다.보안을 잘 아는 개발자들은 보안을 이해하고, 자신이 제어할 수 있는 영역에서 보안을 책임지고, 유일한 품질 코드는 보안 코드라는 점을 이해하고 운영하기 위해 열심히 노력해 왔습니다.일반적으로 개발자는 개선하고, 새로운 문제를 해결하고, 동료들 사이에서 돋보일 수 있는 부러워할 만한 기능을 만들고자 합니다.더 높은 수준의 소프트웨어 개발에 도달할 수 있는 경로를 제공하면 모두가 윈윈할 수 있습니다.
DevSec 드림 팀을 구성하기에 너무 늦은 때는 없습니다.
개발자를 관리하거나, AppSec 인식 팀을 이끌거나, 보안 프로그램 전략을 고안하는 데 열심히 노력하는 많은 사람 중 한 명이라면 지금이 바로 왼쪽으로 “이동”하는 것보다 한 가지 더 나은 방향으로 나아가야 할 때입니다.적절한 교육, 도구 및 환경을 갖추면 개발자를 위한 보안 인큐베이터를 만들어 모든 당사자에게 큰 이익을 줄 수 있습니다.이 체크리스트에서 개선해야 할 몇 가지 영역을 강조했다면 SDLC를 시작할 때부터 위험을 줄일 수 있는 DevSec 주도 엔지니어링 부서에 대비할 수 있는 좋은 기회가 된 것입니다.
2020년도 겨우 절반이 지났지만, 우리는 이미 암울한 데이터 침해 기록을 세울 것으로 예상됩니다. 도난당한 데이터 273% 증가 2019년 상반기와 비교했을 때요즘에는 데이터의 양을 묻는 것이 더 정확합니다. 하지 않았어 아직 도난당했습니다.COVID-19 팬데믹과 같은 세계적 사건으로 인해 이러한 공격의 빈도와 위력이 증가했을 뿐 아니라 공격 대상도 점점 더 취약해지고 있습니다.
보안은 더 이상 선택 사항이 아니며 선제 공격에 초점을 맞춰야 한다는 것은 우리 모두가 오래전부터 알고 있었던 사실입니다.이것이 효과적이려면, 모두들 SDLC에서는 특히 개발자가 보안을 인식해야 합니다.이 부분은 의 “DevSec” 부분입니다. 데브섹옵스기후에 맞는 이상적인 소프트웨어 개발 방법론이지만 많은 조직이 이를 효과적으로 실행할 준비가 되어 있지 않습니다.
조직을 염두에 두고 역할의 맥락에서 이러한 질문에 대해 생각해 보십시오.DevSec 테스트에 적용하면 어떤 결과가 나올까요?
DevSec 자체 평가: SDLC 가든은 보안을 잘 아는 엔지니어를 양성할 준비가 되었나요?
- 내부 개발 프로세스에서 보안을 최우선으로 생각하나요?
다양한 사이버 보안 위험 요인으로 인해 평균적인 CISO는 밤을 지새울 수 있지만 우려되는 현실은 많은 기업이 보안을 최우선 과제로 삼고 있지만 내부 접근 방식이 잠재적 재해 (또는 적어도 AppSec 팀의 엄청난 골칫거리와 소프트웨어 배송 지연) 를 완화할 만큼 강력하지 않을 수 있다는 것입니다.
DevSecOps는 현재 보안 요충지일 수 있지만 이 방법론을 사용하는 회사는 거의 없습니다.아직 애자일 (또는 워터폴) 을 사용하고 있다면 보안은 여전히 전문가의 영역으로 여겨지는데, 이들은 프로세스에서 멀리 떨어져 SDLC 후반부에 활성화되어 코드에 대한 핫픽스로 개발자의 하루를 망치게 됩니다.이런 환경에서는 개발자들이 기능 구축을 좋아하고 우선순위를 정하기 때문에 DevSec 문화를 주도하는 것은 어려울 것입니다. 개발자들은 기능 구축을 선호하고 우선순위를 정하며, 단순히 보안에 대한 충분한 실무 경험이 없었기 때문에 바람직한 기술 향상 경로로 볼 수 없을 것입니다.사실, 개발자들이 접하는 접점은 좌절과 부정적일 수 있습니다.이 문제를 신속히 해결하여 소프트웨어 개발 프로세스에 관련된 모든 사람이 한 눈에 파악할 수 있도록 해야 합니다.
- 위협 모델링과 관련하여 조직이 여전히 따라잡고 있습니까?
정말 놀라운 통계입니다. 중소기업의 60% 가 사이버 공격 성공 후 6개월 이내에 사업을 중단합니다.다른 재해와 마찬가지로 적절한 계획 없이는 그 영향이 훨씬 더 커집니다.
위협 모델링은 AppSec 전문가가 공격 표면의 전체 범위를 평가하고 적절한 방어, 대책 및 계획을 구성할 수 있도록 하는 보안 모범 사례의 중요한 요소입니다.DevSecOps를 완전히 수용한 기업에서는 CI/CD 파이프라인 초기에 보안을 구현하여 과거처럼 생산 속도를 늦추지 않도록 할 수 있습니다.보안, 보안 코딩, 지속적 배포는 모두 프로세스의 일부이며, 개발 팀에게는 빈틈없는 코드를 내보내는 엔진의 주요 구성 요소가 되는 데 필요한 리소스와 노출을 제공합니다.
- 개발 관리자가 보안 모범 사례에 우선 순위를 두나요?
좋든 싫든 개발 관리자는 팀의 역할 모델입니다.사무실에서 슬리퍼를 신고 출근할 때나 직원들이 “좋은 성과를 내는” 방법 등 문화와 분위기에 관련된 것만은 아닙니다.팀의 업무 우선순위는 불가피하게 팀원들에게 흡수될 수밖에 없습니다. 보안이 핵심 목표의 일부가 아니거나 교육 및 지원 측면에서 계획된 것이 아니라면 그 밑에 있는 엔지니어들이 기회를 놓치고 비즈니스는 예상보다 더 큰 위험에 처하게 될 것입니다.
- 개발자들이 보안에 신경을 써야 할 이유가 있나요?
제 경험상 누군가를 화나게 하는 가장 빠른 방법은 이유를 말하지 않고 현재의 접근 방식과는 다른 일을 해야 한다고 말하는 것입니다.
“변경하라”는 말은 이전 접근 방식이 잘못되었다는 것을 의미하지만, 대부분의 경우 나중에 작업을 더 쉽고 효율적으로 만들 수 있는 개선 사항일 뿐입니다.DevSec 운동을 진정으로 받아들이려면 개발자들이 처음부터 보안에 관심을 가져야 할 이유가 있어야 합니다. 결국 대부분의 조직에서 보안은 여전히 “다른 사람의 문제”입니다 (예: AppSec 마법사가 멀리, 멀리, 멀리, 멀리 다른 방에 갇혀 있음).
보안이 공동 책임이 아닌 경우 DevSecOps는 제대로 작동하지 않습니다.개발자가 각자의 역할을 수행하려면 적절한 도구, 지원 및 교육이 필요합니다... 그리고 이를 도입하고 전체 보안 프로그램의 일부로 완벽하게 구현하려면 시간이 필요합니다.최악의 접근 방식은 압도하고 소외감을 주는 접근 방식입니다. 개발자들이 경쟁하는 우선 순위가 너무 많아서 미쳐버리지 않고 관리할 수 있는 도움이 없는 경우가 이런 경우일 수 있습니다.이는 문화적 변화이며 하룻밤 사이에 일어날 수 있는 일이 아닙니다.
- 마법의 보안 유니콘 몇 개만 있으면 많은 임무를 맡을 수 있으신가요?
보안 전문가가 참여합니다. 매우 부족한 공급, 현재 사용 가능한 것보다 훨씬 더 많은 것이 필요합니다.당연한 일이지만, 보안에 초점을 맞춘 역할로 옮기는 개발자의 수가 점점 더 많아지고 있습니다.일반적으로 이들은 “보안 엔지니어” 또는 “DevOps 엔지니어”와 같은 직함을 가질 수 있습니다 (천천히 이 제목이 다음과 같이 바뀌는 것을 보게 될 것입니다). 데브섹옵스 엔지니어, 운이 좋으면!).Gun DevOps 엔지니어는 실제 CI/CD 파이프라인을 사용하여 배포하면서 거의 모든 애플리케이션을 위한 기능을 개발할 수 있습니다.이들은 모든 것을 처음부터 끝까지 수행하며 일반적으로 충분한 보안 인식을 갖추고 있습니다.그런 면에서 보면 마법과도 같고, 그 결과 희귀합니다.
그러나 일부 회사는 이러한 전문 엔지니어를 고용하여 팀으로 구성한 다음 개발 프로세스의 모든 단계에서 모든 보안 문제를 해결할 것으로 예상하는 실수를 저지르는데, 이것만으로도 만병통치약입니다.DevSecOps 마술사들에게 과부하를 주면 처음부터 시작하던 곳에서 끝나게 됩니다. 애초에 고용된 점검, 균형, 보안 정밀도 없이 안전하지 않은 코드를 배포하는 셈이죠.개발 팀이 전반적으로 숙련되고 긍정적인 보안 환경에서 육성되어 의미 있는 방식으로 부하를 분담할 수 있는 역량을 갖추는 것이 무엇보다 중요합니다.
조직에서 보고 싶은 변경 사항을 찾아보세요.
보안 프로그램의 일환으로 강력한 교육을 구현하면 개발 코호트의 숨겨진 요소를 발견할 수 있습니다.이들은 일상 업무에서 겪었을 수 있는 부정적인 경험에도 불구하고 보안 코딩 및 보안 모범 사례에 대한 열정을 갖고 있는 사람들입니다.이러한 사람들은 팀 내 보안 챔피언의 주요 후보입니다. 즉, 다른 사람들에게 좋은 본보기가 되고 인지도를 높이며 참여 이니셔티브를 지원하는 보안과 엔지니어링 간의 접점입니다.이들의 대인 관계 기술은 보안의 즐거움을 널리 퍼뜨리고 경영진과 보안 팀에 개발자의 요구를 대변하는 데에도 매우 중요합니다.
“나에게 무슨 소용이 있니?”대화는 긍정적인 진전입니다.
아무리 고귀한 인간이라도 익숙하지 않은 영역에 발을 담글 수 있는 “당근” 같은 것이 필요하거나 배움이 그다지 즐겁지 않을 수도 있는 활동을 할 수 있습니다.
“dev”에서 “DevSec”으로 도약하는 것은 개발자 경력에 큰 도움이 됩니다.보안을 잘 아는 개발자들은 보안을 이해하고, 자신이 제어할 수 있는 영역에서 보안을 책임지고, 유일한 품질 코드는 보안 코드라는 점을 이해하고 운영하기 위해 열심히 노력해 왔습니다.일반적으로 개발자는 개선하고, 새로운 문제를 해결하고, 동료들 사이에서 돋보일 수 있는 부러워할 만한 기능을 만들고자 합니다.더 높은 수준의 소프트웨어 개발에 도달할 수 있는 경로를 제공하면 모두가 윈윈할 수 있습니다.
DevSec 드림 팀을 구성하기에 너무 늦은 때는 없습니다.
개발자를 관리하거나, AppSec 인식 팀을 이끌거나, 보안 프로그램 전략을 고안하는 데 열심히 노력하는 많은 사람 중 한 명이라면 지금이 바로 왼쪽으로 “이동”하는 것보다 한 가지 더 나은 방향으로 나아가야 할 때입니다.적절한 교육, 도구 및 환경을 갖추면 개발자를 위한 보안 인큐베이터를 만들어 모든 당사자에게 큰 이익을 줄 수 있습니다.이 체크리스트에서 개선해야 할 몇 가지 영역을 강조했다면 SDLC를 시작할 때부터 위험을 줄일 수 있는 DevSec 주도 엔지니어링 부서에 대비할 수 있는 좋은 기회가 된 것입니다.
아래 링크를 클릭하고 이 리소스의 PDF를 다운로드하십시오.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
보고서 보기데모 예약
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
2020년도 겨우 절반이 지났지만, 우리는 이미 암울한 데이터 침해 기록을 세울 것으로 예상됩니다. 도난당한 데이터 273% 증가 2019년 상반기와 비교했을 때요즘에는 데이터의 양을 묻는 것이 더 정확합니다. 하지 않았어 아직 도난당했습니다.COVID-19 팬데믹과 같은 세계적 사건으로 인해 이러한 공격의 빈도와 위력이 증가했을 뿐 아니라 공격 대상도 점점 더 취약해지고 있습니다.
보안은 더 이상 선택 사항이 아니며 선제 공격에 초점을 맞춰야 한다는 것은 우리 모두가 오래전부터 알고 있었던 사실입니다.이것이 효과적이려면, 모두들 SDLC에서는 특히 개발자가 보안을 인식해야 합니다.이 부분은 의 “DevSec” 부분입니다. 데브섹옵스기후에 맞는 이상적인 소프트웨어 개발 방법론이지만 많은 조직이 이를 효과적으로 실행할 준비가 되어 있지 않습니다.
조직을 염두에 두고 역할의 맥락에서 이러한 질문에 대해 생각해 보십시오.DevSec 테스트에 적용하면 어떤 결과가 나올까요?
DevSec 자체 평가: SDLC 가든은 보안을 잘 아는 엔지니어를 양성할 준비가 되었나요?
- 내부 개발 프로세스에서 보안을 최우선으로 생각하나요?
다양한 사이버 보안 위험 요인으로 인해 평균적인 CISO는 밤을 지새울 수 있지만 우려되는 현실은 많은 기업이 보안을 최우선 과제로 삼고 있지만 내부 접근 방식이 잠재적 재해 (또는 적어도 AppSec 팀의 엄청난 골칫거리와 소프트웨어 배송 지연) 를 완화할 만큼 강력하지 않을 수 있다는 것입니다.
DevSecOps는 현재 보안 요충지일 수 있지만 이 방법론을 사용하는 회사는 거의 없습니다.아직 애자일 (또는 워터폴) 을 사용하고 있다면 보안은 여전히 전문가의 영역으로 여겨지는데, 이들은 프로세스에서 멀리 떨어져 SDLC 후반부에 활성화되어 코드에 대한 핫픽스로 개발자의 하루를 망치게 됩니다.이런 환경에서는 개발자들이 기능 구축을 좋아하고 우선순위를 정하기 때문에 DevSec 문화를 주도하는 것은 어려울 것입니다. 개발자들은 기능 구축을 선호하고 우선순위를 정하며, 단순히 보안에 대한 충분한 실무 경험이 없었기 때문에 바람직한 기술 향상 경로로 볼 수 없을 것입니다.사실, 개발자들이 접하는 접점은 좌절과 부정적일 수 있습니다.이 문제를 신속히 해결하여 소프트웨어 개발 프로세스에 관련된 모든 사람이 한 눈에 파악할 수 있도록 해야 합니다.
- 위협 모델링과 관련하여 조직이 여전히 따라잡고 있습니까?
정말 놀라운 통계입니다. 중소기업의 60% 가 사이버 공격 성공 후 6개월 이내에 사업을 중단합니다.다른 재해와 마찬가지로 적절한 계획 없이는 그 영향이 훨씬 더 커집니다.
위협 모델링은 AppSec 전문가가 공격 표면의 전체 범위를 평가하고 적절한 방어, 대책 및 계획을 구성할 수 있도록 하는 보안 모범 사례의 중요한 요소입니다.DevSecOps를 완전히 수용한 기업에서는 CI/CD 파이프라인 초기에 보안을 구현하여 과거처럼 생산 속도를 늦추지 않도록 할 수 있습니다.보안, 보안 코딩, 지속적 배포는 모두 프로세스의 일부이며, 개발 팀에게는 빈틈없는 코드를 내보내는 엔진의 주요 구성 요소가 되는 데 필요한 리소스와 노출을 제공합니다.
- 개발 관리자가 보안 모범 사례에 우선 순위를 두나요?
좋든 싫든 개발 관리자는 팀의 역할 모델입니다.사무실에서 슬리퍼를 신고 출근할 때나 직원들이 “좋은 성과를 내는” 방법 등 문화와 분위기에 관련된 것만은 아닙니다.팀의 업무 우선순위는 불가피하게 팀원들에게 흡수될 수밖에 없습니다. 보안이 핵심 목표의 일부가 아니거나 교육 및 지원 측면에서 계획된 것이 아니라면 그 밑에 있는 엔지니어들이 기회를 놓치고 비즈니스는 예상보다 더 큰 위험에 처하게 될 것입니다.
- 개발자들이 보안에 신경을 써야 할 이유가 있나요?
제 경험상 누군가를 화나게 하는 가장 빠른 방법은 이유를 말하지 않고 현재의 접근 방식과는 다른 일을 해야 한다고 말하는 것입니다.
“변경하라”는 말은 이전 접근 방식이 잘못되었다는 것을 의미하지만, 대부분의 경우 나중에 작업을 더 쉽고 효율적으로 만들 수 있는 개선 사항일 뿐입니다.DevSec 운동을 진정으로 받아들이려면 개발자들이 처음부터 보안에 관심을 가져야 할 이유가 있어야 합니다. 결국 대부분의 조직에서 보안은 여전히 “다른 사람의 문제”입니다 (예: AppSec 마법사가 멀리, 멀리, 멀리, 멀리 다른 방에 갇혀 있음).
보안이 공동 책임이 아닌 경우 DevSecOps는 제대로 작동하지 않습니다.개발자가 각자의 역할을 수행하려면 적절한 도구, 지원 및 교육이 필요합니다... 그리고 이를 도입하고 전체 보안 프로그램의 일부로 완벽하게 구현하려면 시간이 필요합니다.최악의 접근 방식은 압도하고 소외감을 주는 접근 방식입니다. 개발자들이 경쟁하는 우선 순위가 너무 많아서 미쳐버리지 않고 관리할 수 있는 도움이 없는 경우가 이런 경우일 수 있습니다.이는 문화적 변화이며 하룻밤 사이에 일어날 수 있는 일이 아닙니다.
- 마법의 보안 유니콘 몇 개만 있으면 많은 임무를 맡을 수 있으신가요?
보안 전문가가 참여합니다. 매우 부족한 공급, 현재 사용 가능한 것보다 훨씬 더 많은 것이 필요합니다.당연한 일이지만, 보안에 초점을 맞춘 역할로 옮기는 개발자의 수가 점점 더 많아지고 있습니다.일반적으로 이들은 “보안 엔지니어” 또는 “DevOps 엔지니어”와 같은 직함을 가질 수 있습니다 (천천히 이 제목이 다음과 같이 바뀌는 것을 보게 될 것입니다). 데브섹옵스 엔지니어, 운이 좋으면!).Gun DevOps 엔지니어는 실제 CI/CD 파이프라인을 사용하여 배포하면서 거의 모든 애플리케이션을 위한 기능을 개발할 수 있습니다.이들은 모든 것을 처음부터 끝까지 수행하며 일반적으로 충분한 보안 인식을 갖추고 있습니다.그런 면에서 보면 마법과도 같고, 그 결과 희귀합니다.
그러나 일부 회사는 이러한 전문 엔지니어를 고용하여 팀으로 구성한 다음 개발 프로세스의 모든 단계에서 모든 보안 문제를 해결할 것으로 예상하는 실수를 저지르는데, 이것만으로도 만병통치약입니다.DevSecOps 마술사들에게 과부하를 주면 처음부터 시작하던 곳에서 끝나게 됩니다. 애초에 고용된 점검, 균형, 보안 정밀도 없이 안전하지 않은 코드를 배포하는 셈이죠.개발 팀이 전반적으로 숙련되고 긍정적인 보안 환경에서 육성되어 의미 있는 방식으로 부하를 분담할 수 있는 역량을 갖추는 것이 무엇보다 중요합니다.
조직에서 보고 싶은 변경 사항을 찾아보세요.
보안 프로그램의 일환으로 강력한 교육을 구현하면 개발 코호트의 숨겨진 요소를 발견할 수 있습니다.이들은 일상 업무에서 겪었을 수 있는 부정적인 경험에도 불구하고 보안 코딩 및 보안 모범 사례에 대한 열정을 갖고 있는 사람들입니다.이러한 사람들은 팀 내 보안 챔피언의 주요 후보입니다. 즉, 다른 사람들에게 좋은 본보기가 되고 인지도를 높이며 참여 이니셔티브를 지원하는 보안과 엔지니어링 간의 접점입니다.이들의 대인 관계 기술은 보안의 즐거움을 널리 퍼뜨리고 경영진과 보안 팀에 개발자의 요구를 대변하는 데에도 매우 중요합니다.
“나에게 무슨 소용이 있니?”대화는 긍정적인 진전입니다.
아무리 고귀한 인간이라도 익숙하지 않은 영역에 발을 담글 수 있는 “당근” 같은 것이 필요하거나 배움이 그다지 즐겁지 않을 수도 있는 활동을 할 수 있습니다.
“dev”에서 “DevSec”으로 도약하는 것은 개발자 경력에 큰 도움이 됩니다.보안을 잘 아는 개발자들은 보안을 이해하고, 자신이 제어할 수 있는 영역에서 보안을 책임지고, 유일한 품질 코드는 보안 코드라는 점을 이해하고 운영하기 위해 열심히 노력해 왔습니다.일반적으로 개발자는 개선하고, 새로운 문제를 해결하고, 동료들 사이에서 돋보일 수 있는 부러워할 만한 기능을 만들고자 합니다.더 높은 수준의 소프트웨어 개발에 도달할 수 있는 경로를 제공하면 모두가 윈윈할 수 있습니다.
DevSec 드림 팀을 구성하기에 너무 늦은 때는 없습니다.
개발자를 관리하거나, AppSec 인식 팀을 이끌거나, 보안 프로그램 전략을 고안하는 데 열심히 노력하는 많은 사람 중 한 명이라면 지금이 바로 왼쪽으로 “이동”하는 것보다 한 가지 더 나은 방향으로 나아가야 할 때입니다.적절한 교육, 도구 및 환경을 갖추면 개발자를 위한 보안 인큐베이터를 만들어 모든 당사자에게 큰 이익을 줄 수 있습니다.이 체크리스트에서 개선해야 할 몇 가지 영역을 강조했다면 SDLC를 시작할 때부터 위험을 줄일 수 있는 DevSec 주도 엔지니어링 부서에 대비할 수 있는 좋은 기회가 된 것입니다.
목차
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약다운로드
%20(1).avif)
.avif)
