귀사는 정말 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 주도 엔지니어링 부서에 대비할 수 있는 좋은 기회가 된 것입니다.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Secure Code Warrior está aquí para ayudar a las organizaciones a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura que priorice la ciberseguridad. Ya seas administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudarte a reducir los riesgos asociados al código inseguro en tu organización.
Reserva de demostración
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
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 주도 엔지니어링 부서에 대비할 수 있는 좋은 기회가 된 것입니다.
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está aquí para ayudar a las organizaciones a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura que priorice la ciberseguridad. Ya seas administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudarte a reducir los riesgos asociados al código inseguro en tu organización.
Ver informeReserva de demostración
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
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 주도 엔지니어링 부서에 대비할 수 있는 좋은 기회가 된 것입니다.
Índice
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Secure Code Warrior está aquí para ayudar a las organizaciones a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura que priorice la ciberseguridad. Ya seas administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudarte a reducir los riesgos asociados al código inseguro en tu organización.
Reserva de demostraciónDescargarRecursos útiles para empezar
Temas y contenidos de la formación sobre códigos de seguridad
El mejor contenido del sector evoluciona constantemente para adaptarse al entorno de desarrollo de software en constante cambio, teniendo en cuenta el papel de los clientes. Se ofrecen temas que abarcan desde la inteligencia artificial hasta la inyección de XQuery, para diversas funciones, desde arquitectos e ingenieros hasta gestores de productos y control de calidad. Eche un vistazo al contenido que ofrece el catálogo por temas y funciones.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos útiles para empezar
Cybermon ha vuelto: la misión de IA para derrotar al jefe ahora está disponible bajo demanda.
Cybermon 2025 Bit the Boss ya está disponible en SCW durante todo el año. Implemente tareas de seguridad avanzadas de IA/LLM para impulsar el desarrollo de IA de seguridad a gran escala.
Explicación de la Ley de Resiliencia Cibernética: El significado del diseño de seguridad en el desarrollo de software
Descubra los requisitos y el ámbito de aplicación de la Ley de Resiliencia Cibernética (CRA) de la UE, y cómo el equipo de ingeniería puede prepararse de forma segura mediante el diseño, las prácticas, la prevención de vulnerabilidades y la creación de un entorno de desarrollo.
Factor de éxito 1: Criterios de éxito definidos y medibles
El habilitador 1 ofrece una serie de 10 partes sobre los habilitadores del éxito, mostrando cómo la codificación segura puede mejorar los resultados empresariales, como la reducción de riesgos y costes y la aceleración de la madurez de los programas a largo plazo.
