내 펜트레스터, 내 원수? 개발자는 펜테스트 및 정적 분석 결과에 대해 실제로 어떻게 생각하는지 공개합니다.
자연 서식지의 개발자는 종종 깊은 농도의 상태에서 발견, 꽉 마감에 멋진 기능을 코딩. 기능 구축은 종종 우리가 가장 좋아하는 부분이며, 실제로 는 소프트웨어 개발 수명 주기 (SDLC)의 기본 결과입니다.
그러나 이전에 설명한 것처럼 많은 사람들이 여전히 보안 모범 사례보다 기능의 우선 순위를 지정하고 있습니다. 결국, 대부분의 조직에서는 다른 사람의 직업으로 설정되어 있으며 우리를 위한 적절한 보안 교육은 제한적입니다. 침투 테스트 및 정적 분석 스캐닝 도구(SAST라고 더 잘 알려진)는 보안 위험을 완화하기 위한 전체 프로세스의 일부에 불과하며, 우리가 하는 일과 는 독립적으로 작동합니다... 물론 핫픽스를 위해 코드가 반송될 때까지.
그리고 많은 개발자들이 생각하는 순간입니다:"펜테스터들이 저를 미워합니까?"
이러한 상호 작용은 종종 팀, 문화를 정의합니다. 중요한 것은, 의사 소통, 이해 및 전반적인 협력의 부족은 적어도 개발자의 측면에 긴장을 만들었습니다. 생각해 보십시오: 당신이 놀라운 동상을 조각하는 데 몇 백 시간을 보냈다고 상상해보십시오, 그리고 누군가가 망치와 함께 와서 그 기초가 긁히지 않는다고 말한 후 비트를 부수기 시작합니다. 테스터와 개발자 사이의 인식 된 역학입니다 - 후자는 그들과 함께 과정을 통해 노력하지 않은 외부인에 의해 도살 자신의 소프트웨어 달링을 가지고; 대신 워크로드를 확장하고 배송 코드의 만족도를 지연시켰습니다.
오래 전에 보안 공간으로 이동한 후 이야기의 양면을 볼 수 있습니다. 그리고 아니, 펜테어는 개발자를 싫어하지 않습니다. 펜트터는 모든 가능성에, 과로및 많은 압력을 받고있다. 따라서 코드 수준에서 쉽게 수정할 수 있는 일반적인 보안 버그의 일정한 흐름은 정말 심각한 문제로부터 시간, 리소스 및 헤드스페이스를 차지합니다.
나는 항상 펜테어를 부모처럼 보았다. 그들은 당신이 잘하기를 원하고, 당신이하지 않을 때 ... 그들은 화가 아니에요, 그냥 실망.
이제 그 (아마도 약간 불공평한) 이미지를 마음 속에 넣었으니, 좀 더 깊이 살펴보겠습니다. 개발자들 사이에서 이 세계관을 일으킨 원인은 무엇입니까?
"물론 저는 방어적입니다. 그들은 내 일을하는 방법을 말해거야!"
아무도 그들이 나쁜 일을 한 것처럼 느끼는 것을 좋아하지 않는다, 또는 누군가가 자신의 일을 좋아하지 않는. 슬프게도 개발자에게는 정적 분석과 펜테스트 결과가 다시 나올 때 보고서 카드처럼 느껴질 수 있습니다. 그들은 낮은 성적을 부여했습니다,하지만 하루의 끝에서, 그들의 상사는 그들이 구축 한 기능과 그들이 그들을 전달 한 시간에 그들을 평가, 소프트웨어에 취약한 요소가 있는지 여부.
가난한 펜트테르의 경우,이 "메신저를 촬영하지 마십시오"의 경우입니다. 그것은 개인적인 것이 아닙니다 - 그들은 버그를 찾는 임무를 맡고 있으며, 그들은 그들을 발견했습니다. 부여, 사람 - 투 - 사람 수준에서, 어쩌면 일부 pentesters는 다른 사람보다 불평, 하지만 그들은 (또는 해서는 안) 밖으로 개발 팀을 십자가에 못 박는. 보안 모범 사례를 구성하는 것과 같은 페이지에 있다면 양 팀이 훨씬 쉬울 것입니다. 그리고 개발자는 완벽 할 것으로 예상되지 않습니다; 현실적으로 테스트 팀은 취약한 코드를 배송하지 못하도록 보호합니다.
"그들은 이 모든 사소한 문제를 해결하라고 말했습니다, 더 높은 우선 순위가 있다는 것을 알지 못합니까? 그리고 왜 그들은 그들이 너무 많은 관심을 가지고 있다면 그들을 고칠 수 있도록 도와주지 않습니까?"
그것은 사실이다 - 개발자의 가장 높은 우선 순위는 항상 기능의 구축이 될 것입니다, 그리고 빠른 디지털화의이 미친 세계에서, 그것은 속도로 수행해야합니다. 일부 코더는 보안 및 보안 코딩에 개인적인 관심을 가지고 있지만, 일반적인 감정은 보안이 필연적으로 펜테어를 포함하는 "다른 사람의 문제"라는 것입니다.
가장 일반적인 취약점은 실제로 해결해야 할 사소한 문제입니다 - 일단 알려진, 수정 사항은 교차 사이트 스크립팅 (XSS) 및 SQL 주입 같은 것들에 대해 실행하는 것이 간단합니다 ... 문제는 많은 개발자가 처음에 도입하고 있다는 것을 깨닫지 못하며, 이러한 사소한 문제는 공격자가 회사에 치명적인 문제를 야기할 수 있는 작은 기회의 창이라는 것입니다. Akamai에 따르면 2017년 11월부터 2019년 3월까지 SQL 주입 취약점이 모든 웹 기반 공격 벡터의 65%를 차지했습니다. 20년 이상 알려진 수정 사항이 있는 취약점의 경우 이는 냉정한 통계입니다.
일부 펜테스트 팀은 보안 버그 의 해결을 지원하지만, 다른 팀은 나쁜 소식에 대한 보고서를 제공하고 개발자가 핫픽스를 통해 작동 할 것으로 예상합니다, 그들은이 일이 발생할 때까지 다른 프로젝트에 이동한 경우에도. 그리고 어떤 경우에는 개발 팀이 수정할 수 없거나 예상해서는 안 되는 버그를 포함하는 보고서에 직면할 수 있습니다 - 그것은 여전히 결과의 일부가 되어야 하며, 다시 개인적으로 촬영하지 않아야 합니다.
이에 대한 "행복한 매체"는 팀이 효과적인 교육 및 도구 측면에서 필요한 것을 가지고 있는지 확인하기 위해 멘토 역할을 하는 펜테어, 보안 인력 및 개발 관리자가 되어 개별 코더에게 SDLC 의 처음부터 안전하게 성공하고 코드를 안전하게 할 수 있는 최고의 기회를 제공합니다. 양 팀 모두 건전한 DevSecOps 연습의 일환으로 처음부터 보안을 고려하도록 반쯤 충족해야 합니다.
"나는 내가 신용을 얻는 것보다 훨씬 더 나은 보안 지식을 가지고있다; 이러한 보고서는 대부분 거짓 긍정, 또는 중요 하지".
정적 분석은 SDLC의 보안 프로세스의 요소이며 정적 분석 검색 도구(SAST)는 기본 역할을 합니다. 그리고 네, 거짓 긍정은 스캐너의 이러한 및 기타 유형 (DAST / IAST / RAST)의 문제입니다. 그것은 이미 느린 프로세스에 성가신, 수동 코드 검토를 필요로 하 고 개발자와 pentesters 모두에 압력을 넣어. Pentesting 직원은 부정확한 판독값을 피하기 위해 사용자 지정 규칙을 꼼꼼하게 설정하고 회사 별 지침을 제공했지만 일부 거짓 판독값은 머리 긁힘 개발자 앞에서 미끄러지고 끝납니다.
이 프로세스는 완벽하지 않지만 다른 문제는 많은 개발자가 일관된 방식으로 많은 일반적인 취약점을 완화하기에 충분한 지식이 부족하다는 것입니다. 고등 교육에서 드문 보안 교육, 그리고 그 효과에 따라 작업 교육, 그것은 뿐만 아니라 놀이에 약간의 과신이있을 수 있다는 것을 추론 스탠드 (그리고 그것은 그들의 잘못이 아니다 - 우리는 업계로 그들이 필요로하는 것을 장착에 더 나은 얻을 필요가).
"이 응용 프로그램이 테스트될 줄은 몰랐지만 지금은 교정 작업에 갇혀 있습니다."
때로는 과로 한 엔지니어가 펜스터가 날개에 매달려 응용 프로그램을 테스트하고 개발 팀의 퍼레이드에 비가 내리는 순간을 기다리고 있다는 가정이 있습니다. 그들은 과잉 테스트, 그들은 nitpicking, 그들은 여분의 작업을 만들고있어.
그 유일한 문제는 그들도 과로 (더 많은, 사실 - 사이버 보안 기술 부족은 끔찍한 수준에 있고 악화되고있다) 그리고 단순히 이유없이 테스트 할 시간이 없다는 것입니다. 테스트우선 순위 지정에 있어 유일한 의사 결정자가 아닙니다. 보안 감사의 일환으로 고위 경영진, 고객의 요청이 있었거나 버그 현상금 프로그램의 결과로 결정되었을 수도 있습니다.
개발자의 경우 보안 수정 작업을 위해 현재 기능 구축 스프린트에서 벗어나는 것은 성가신 일입니다 . 아마도 이전 팀은 마지막 업데이트, 또는 다른 공급 업체를했다. 그러나 보안은 모두의 문제입니다. 그렇다고 해서 모든 개발자가 보안 버그를 소유해야 하는 것처럼 모든 개발자가 보안 버그를 소유해야 한다는 의미는 아니지만, 보안이 공동책임이라는 측면에서 당에 와야 합니다.
여기에서 어디로?
때로는 사고 방식의 변화가 문제를 해결하는 데 상당한 변화를 만드는 데 필요한 모든 것일 수 있습니다. 우리는 개발자가 유리한 페널티 결과보다 덜해야 오히려 서리가 내린 반응에 대해 이야기했지만, 그들이 도전으로 바꿀 수 있다면 어떨까요? 아마도 그들은 펜테터를 우호적인 경쟁자로 생각할 수 있었을 것입니다. 그들은 자신의 게임에서 이길 수있는 사람. 결국, 코드를 작성할 때 일반적인 버그를 제거할 수 있는 보안 인식 개발자는 작업을 훨씬 더 어렵게 만듭니다. 대조적으로, 보안에 초점을 맞추지 않는 개발자는 쉽게 소프트웨어를 깰 수있을 때 펜트스터 대응에 의해 포괄적으로 최고가 될 것입니다.
Pentesters와 개발자는 100%의 시간을 조화롭게 결합하지 못할 수 있지만, 조직이 보안을 주요 우선 순위로 해결하고 성공할 수 있는 올바른 지식과 도구를 갖춘 팀(특히 개발자)에게 권한을 부여할 때 관계가 크게 개선될 수 있습니다. 이는 전사적이고 긍정적인 보안 문화가 우선순위인지, 그리고 우리가 (현재) 일반적인 취약점에 맞서 싸우는 것을 원한다면 절대적으로 해야 합니다.
마티아스 마두, Ph.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
블로그에서 최신 보안 코딩 인사이트에 대해 자세히 알아보세요.
Atlassian의 광범위한 리소스 라이브러리는 안전한 코딩 숙련도를 확보하기 위한 인적 접근 방식을 강화하는 것을 목표로 합니다.
개발자 중심 보안에 대한 최신 연구 보기
광범위한 리소스 라이브러리에는 개발자 중심의 보안 코딩을 시작하는 데 도움이 되는 백서부터 웨비나까지 유용한 리소스가 가득합니다. 지금 살펴보세요.
내 펜트레스터, 내 원수? 개발자는 펜테스트 및 정적 분석 결과에 대해 실제로 어떻게 생각하는지 공개합니다.
자연 서식지의 개발자는 종종 깊은 농도의 상태에서 발견, 꽉 마감에 멋진 기능을 코딩. 기능 구축은 종종 우리가 가장 좋아하는 부분이며, 실제로 는 소프트웨어 개발 수명 주기 (SDLC)의 기본 결과입니다.
그러나 이전에 설명한 것처럼 많은 사람들이 여전히 보안 모범 사례보다 기능의 우선 순위를 지정하고 있습니다. 결국, 대부분의 조직에서는 다른 사람의 직업으로 설정되어 있으며 우리를 위한 적절한 보안 교육은 제한적입니다. 침투 테스트 및 정적 분석 스캐닝 도구(SAST라고 더 잘 알려진)는 보안 위험을 완화하기 위한 전체 프로세스의 일부에 불과하며, 우리가 하는 일과 는 독립적으로 작동합니다... 물론 핫픽스를 위해 코드가 반송될 때까지.
그리고 많은 개발자들이 생각하는 순간입니다:"펜테스터들이 저를 미워합니까?"
이러한 상호 작용은 종종 팀, 문화를 정의합니다. 중요한 것은, 의사 소통, 이해 및 전반적인 협력의 부족은 적어도 개발자의 측면에 긴장을 만들었습니다. 생각해 보십시오: 당신이 놀라운 동상을 조각하는 데 몇 백 시간을 보냈다고 상상해보십시오, 그리고 누군가가 망치와 함께 와서 그 기초가 긁히지 않는다고 말한 후 비트를 부수기 시작합니다. 테스터와 개발자 사이의 인식 된 역학입니다 - 후자는 그들과 함께 과정을 통해 노력하지 않은 외부인에 의해 도살 자신의 소프트웨어 달링을 가지고; 대신 워크로드를 확장하고 배송 코드의 만족도를 지연시켰습니다.
오래 전에 보안 공간으로 이동한 후 이야기의 양면을 볼 수 있습니다. 그리고 아니, 펜테어는 개발자를 싫어하지 않습니다. 펜트터는 모든 가능성에, 과로및 많은 압력을 받고있다. 따라서 코드 수준에서 쉽게 수정할 수 있는 일반적인 보안 버그의 일정한 흐름은 정말 심각한 문제로부터 시간, 리소스 및 헤드스페이스를 차지합니다.
나는 항상 펜테어를 부모처럼 보았다. 그들은 당신이 잘하기를 원하고, 당신이하지 않을 때 ... 그들은 화가 아니에요, 그냥 실망.
이제 그 (아마도 약간 불공평한) 이미지를 마음 속에 넣었으니, 좀 더 깊이 살펴보겠습니다. 개발자들 사이에서 이 세계관을 일으킨 원인은 무엇입니까?
"물론 저는 방어적입니다. 그들은 내 일을하는 방법을 말해거야!"
아무도 그들이 나쁜 일을 한 것처럼 느끼는 것을 좋아하지 않는다, 또는 누군가가 자신의 일을 좋아하지 않는. 슬프게도 개발자에게는 정적 분석과 펜테스트 결과가 다시 나올 때 보고서 카드처럼 느껴질 수 있습니다. 그들은 낮은 성적을 부여했습니다,하지만 하루의 끝에서, 그들의 상사는 그들이 구축 한 기능과 그들이 그들을 전달 한 시간에 그들을 평가, 소프트웨어에 취약한 요소가 있는지 여부.
가난한 펜트테르의 경우,이 "메신저를 촬영하지 마십시오"의 경우입니다. 그것은 개인적인 것이 아닙니다 - 그들은 버그를 찾는 임무를 맡고 있으며, 그들은 그들을 발견했습니다. 부여, 사람 - 투 - 사람 수준에서, 어쩌면 일부 pentesters는 다른 사람보다 불평, 하지만 그들은 (또는 해서는 안) 밖으로 개발 팀을 십자가에 못 박는. 보안 모범 사례를 구성하는 것과 같은 페이지에 있다면 양 팀이 훨씬 쉬울 것입니다. 그리고 개발자는 완벽 할 것으로 예상되지 않습니다; 현실적으로 테스트 팀은 취약한 코드를 배송하지 못하도록 보호합니다.
"그들은 이 모든 사소한 문제를 해결하라고 말했습니다, 더 높은 우선 순위가 있다는 것을 알지 못합니까? 그리고 왜 그들은 그들이 너무 많은 관심을 가지고 있다면 그들을 고칠 수 있도록 도와주지 않습니까?"
그것은 사실이다 - 개발자의 가장 높은 우선 순위는 항상 기능의 구축이 될 것입니다, 그리고 빠른 디지털화의이 미친 세계에서, 그것은 속도로 수행해야합니다. 일부 코더는 보안 및 보안 코딩에 개인적인 관심을 가지고 있지만, 일반적인 감정은 보안이 필연적으로 펜테어를 포함하는 "다른 사람의 문제"라는 것입니다.
가장 일반적인 취약점은 실제로 해결해야 할 사소한 문제입니다 - 일단 알려진, 수정 사항은 교차 사이트 스크립팅 (XSS) 및 SQL 주입 같은 것들에 대해 실행하는 것이 간단합니다 ... 문제는 많은 개발자가 처음에 도입하고 있다는 것을 깨닫지 못하며, 이러한 사소한 문제는 공격자가 회사에 치명적인 문제를 야기할 수 있는 작은 기회의 창이라는 것입니다. Akamai에 따르면 2017년 11월부터 2019년 3월까지 SQL 주입 취약점이 모든 웹 기반 공격 벡터의 65%를 차지했습니다. 20년 이상 알려진 수정 사항이 있는 취약점의 경우 이는 냉정한 통계입니다.
일부 펜테스트 팀은 보안 버그 의 해결을 지원하지만, 다른 팀은 나쁜 소식에 대한 보고서를 제공하고 개발자가 핫픽스를 통해 작동 할 것으로 예상합니다, 그들은이 일이 발생할 때까지 다른 프로젝트에 이동한 경우에도. 그리고 어떤 경우에는 개발 팀이 수정할 수 없거나 예상해서는 안 되는 버그를 포함하는 보고서에 직면할 수 있습니다 - 그것은 여전히 결과의 일부가 되어야 하며, 다시 개인적으로 촬영하지 않아야 합니다.
이에 대한 "행복한 매체"는 팀이 효과적인 교육 및 도구 측면에서 필요한 것을 가지고 있는지 확인하기 위해 멘토 역할을 하는 펜테어, 보안 인력 및 개발 관리자가 되어 개별 코더에게 SDLC 의 처음부터 안전하게 성공하고 코드를 안전하게 할 수 있는 최고의 기회를 제공합니다. 양 팀 모두 건전한 DevSecOps 연습의 일환으로 처음부터 보안을 고려하도록 반쯤 충족해야 합니다.
"나는 내가 신용을 얻는 것보다 훨씬 더 나은 보안 지식을 가지고있다; 이러한 보고서는 대부분 거짓 긍정, 또는 중요 하지".
정적 분석은 SDLC의 보안 프로세스의 요소이며 정적 분석 검색 도구(SAST)는 기본 역할을 합니다. 그리고 네, 거짓 긍정은 스캐너의 이러한 및 기타 유형 (DAST / IAST / RAST)의 문제입니다. 그것은 이미 느린 프로세스에 성가신, 수동 코드 검토를 필요로 하 고 개발자와 pentesters 모두에 압력을 넣어. Pentesting 직원은 부정확한 판독값을 피하기 위해 사용자 지정 규칙을 꼼꼼하게 설정하고 회사 별 지침을 제공했지만 일부 거짓 판독값은 머리 긁힘 개발자 앞에서 미끄러지고 끝납니다.
이 프로세스는 완벽하지 않지만 다른 문제는 많은 개발자가 일관된 방식으로 많은 일반적인 취약점을 완화하기에 충분한 지식이 부족하다는 것입니다. 고등 교육에서 드문 보안 교육, 그리고 그 효과에 따라 작업 교육, 그것은 뿐만 아니라 놀이에 약간의 과신이있을 수 있다는 것을 추론 스탠드 (그리고 그것은 그들의 잘못이 아니다 - 우리는 업계로 그들이 필요로하는 것을 장착에 더 나은 얻을 필요가).
"이 응용 프로그램이 테스트될 줄은 몰랐지만 지금은 교정 작업에 갇혀 있습니다."
때로는 과로 한 엔지니어가 펜스터가 날개에 매달려 응용 프로그램을 테스트하고 개발 팀의 퍼레이드에 비가 내리는 순간을 기다리고 있다는 가정이 있습니다. 그들은 과잉 테스트, 그들은 nitpicking, 그들은 여분의 작업을 만들고있어.
그 유일한 문제는 그들도 과로 (더 많은, 사실 - 사이버 보안 기술 부족은 끔찍한 수준에 있고 악화되고있다) 그리고 단순히 이유없이 테스트 할 시간이 없다는 것입니다. 테스트우선 순위 지정에 있어 유일한 의사 결정자가 아닙니다. 보안 감사의 일환으로 고위 경영진, 고객의 요청이 있었거나 버그 현상금 프로그램의 결과로 결정되었을 수도 있습니다.
개발자의 경우 보안 수정 작업을 위해 현재 기능 구축 스프린트에서 벗어나는 것은 성가신 일입니다 . 아마도 이전 팀은 마지막 업데이트, 또는 다른 공급 업체를했다. 그러나 보안은 모두의 문제입니다. 그렇다고 해서 모든 개발자가 보안 버그를 소유해야 하는 것처럼 모든 개발자가 보안 버그를 소유해야 한다는 의미는 아니지만, 보안이 공동책임이라는 측면에서 당에 와야 합니다.
여기에서 어디로?
때로는 사고 방식의 변화가 문제를 해결하는 데 상당한 변화를 만드는 데 필요한 모든 것일 수 있습니다. 우리는 개발자가 유리한 페널티 결과보다 덜해야 오히려 서리가 내린 반응에 대해 이야기했지만, 그들이 도전으로 바꿀 수 있다면 어떨까요? 아마도 그들은 펜테터를 우호적인 경쟁자로 생각할 수 있었을 것입니다. 그들은 자신의 게임에서 이길 수있는 사람. 결국, 코드를 작성할 때 일반적인 버그를 제거할 수 있는 보안 인식 개발자는 작업을 훨씬 더 어렵게 만듭니다. 대조적으로, 보안에 초점을 맞추지 않는 개발자는 쉽게 소프트웨어를 깰 수있을 때 펜트스터 대응에 의해 포괄적으로 최고가 될 것입니다.
Pentesters와 개발자는 100%의 시간을 조화롭게 결합하지 못할 수 있지만, 조직이 보안을 주요 우선 순위로 해결하고 성공할 수 있는 올바른 지식과 도구를 갖춘 팀(특히 개발자)에게 권한을 부여할 때 관계가 크게 개선될 수 있습니다. 이는 전사적이고 긍정적인 보안 문화가 우선순위인지, 그리고 우리가 (현재) 일반적인 취약점에 맞서 싸우는 것을 원한다면 절대적으로 해야 합니다.
