내 펜테스터, 내 적?개발자가 펜테스팅 및 정적 분석 결과에 대해 실제로 어떻게 생각하는지 밝힙니다.

자연 서식지에 사는 개발자는 촉박한 마감일에 멋진 기능을 코딩하는 등 집중도가 높은 상태를 자주 볼 수 있습니다.기능 구축은 우리가 이 일에서 가장 좋아하는 부분인 경우가 많은데, 사실 기능 구축은 소프트웨어 개발 라이프 사이클 (SDLC) 의 근본적인 결과물입니다.

그러나 앞서 논의한 바와 같이 많은 사람들이 여전히 보안 모범 사례보다 기능을 우선시하고 있습니다.결국 대부분의 조직에서는 업무가 다른 사람의 업무로 설정되어 있고 우리를 위한 적절한 보안 교육도 제한되어 있습니다.침투 테스트 및 정적 분석 스캐닝 도구 (SAST라고도 함) 는 보안 위험을 완화하기 위한 전체 프로세스의 일부에 불과합니다. 물론 핫픽스를 위해 코드가 우리에게 돌아오기 전까지는 우리가 하는 작업과는 별개로 작동합니다.

바로 그 순간 많은 개발자들이 이렇게 생각합니다.”펜테스터들이 나를 싫어하니?”

이러한 상호 작용은 종종 팀, 문화를 정의합니다.걱정되는 점은 커뮤니케이션과 이해, 전반적인 협업의 부재로 인해 적어도 개발자 측에서는 긴장감이 생겼다는 것입니다.생각해 보세요. 멋진 조각상을 만드는 데 몇 백 시간을 보냈는데, 어떤 사람이 망치를 들고 와서 그 기초가 엉망이라는 말을 듣고 조각을 부수기 시작한다고 상상해 보세요.이것이 바로 테스터와 개발자 사이의 인식된 역학 관계입니다. 개발자의 경우 프로세스를 진행하지 않은 외부인이 소프트웨어 애호가를 학살하고 대신 워크로드를 늘리고 배송 코드의 만족도를 지연시켰습니다.

오래 전에 보안 분야로 옮겨 왔기 때문에 이야기의 양면을 모두 볼 수 있습니다.그리고 아니요, 펜테스터는 그렇지 않습니다. 미움 개발자.펜테스터는 아마도 과로하고 많은 압박을 받고 있을 것입니다.따라서 코드 수준에서 쉽게 고칠 수 있는 일반적인 보안 버그가 끊이지 않고 쏟아져 나오더라도 심각한 문제를 해결하느라 시간, 리소스 및 헤드스페이스를 소모하게 됩니다.

저는 항상 펜테스터를 일종의 부모 같은 존재로 여겼어요.그들은 당신이 잘하길 바라는데, 그렇지 않을 때는... 화가 난 게 아니라 실망할 뿐이죠.

이제 (약간 불공평한) 이미지를 머릿속에 담았으니 좀 더 깊이 탐구해 보겠습니다.개발자들 사이에 이런 세계관이 생긴 이유는 무엇일까요?

“당연히 방어적인 태도로 변해가고 있어요. 그들이 제 일을 어떻게 해야 하는지 알려주고 있으니까요!”

자신이 나쁜 일을 했거나 누군가가 자신의 일을 좋아하지 않는 것처럼 느끼는 것을 좋아하는 사람은 아무도 없습니다.안타깝게도 개발자 입장에서는 정적 분석과 Pentest 결과가 돌아오면 성적표처럼 느껴질 수 있습니다.낮은 점수를 받았지만 결국에는 그들의 상사는 소프트웨어에 취약한 요소가 있었는지 여부가 아니라 구축한 기능과 제공 시간을 기준으로 평가합니다.

불쌍한 펜테스터에게는 “메신저를 쏘지 말라”는 경우입니다.개인적인 일은 아니에요. 그들은 버그를 찾아내는 임무를 맡았는데, 버그를 찾아냈죠.물론 개인 대 개인 차원에서는 일부 펜테스터가 다른 사람들보다 심술궂을 수도 있지만 개발팀을 십자가에 못 박으려는 것은 아닙니다 (또는 그렇게 해서는 안 됩니다).두 팀이 보안 모범 사례를 구성하는 요소에 대해 동일한 이해를 가지고 있다면 훨씬 더 쉬울 것입니다.개발자가 완벽할 것으로 기대되지는 않습니다. 현실적으로 테스트 팀은 취약한 코드가 유출되지 않도록 보호하기 위해 존재합니다.

“이 모든 사소한 문제를 해결하라고 하던데, 더 높은 우선 순위가 있다는 걸 모르나요?그리고 애들이 그렇게 신경을 쓰는데 왜 제가 고칠 수 있게 도와주지 않는 거죠?”

사실입니다. 개발자의 최우선 과제는 항상 기능 구축이며, 빠르게 디지털화되는 이 미친 세상에서는 빠른 속도로 완료되어야 합니다.보안과 보안 코딩에 개인적인 관심이 있는 코더도 있지만, 일반적으로 보안은 “다른 사람의 문제”라고 생각하는데, 여기에는 필연적으로 펜테스터도 포함됩니다.

대부분의 일반적인 취약점은 수정해야 할 사소한 문제입니다. 일단 알려지면 XSS (Cross-Site Scriptting) 및 SQL 삽입과 같은 수정 프로그램을 간단하게 실행할 수 있습니다... 문제는 많은 개발자들이 애초에 취약점을 도입했다는 사실을 깨닫지 못한다는 것입니다. 그리고 겉보기에 사소해 보이는 이러한 문제는 공격자가 회사에 치명적인 문제를 일으킬 수 있는 작은 기회입니다.아카마이에 따르면 2017년 11월부터 2019년 3월 사이에 SQL 인젝션 취약점이 발생했습니다. 전체 웹 기반 공격 벡터의 65%.이미 20년 넘게 해결된 것으로 알려진 취약점에 대한 통계는 냉정한 수치입니다.

일부 펜테스트 팀은 보안 버그 수정을 지원하지만, 다른 팀은 나쁜 소식에 대한 보고서를 제공하고 개발자가 핫픽스가 발생할 때 다른 프로젝트로 이동했더라도 핫픽스를 해결하기를 기대합니다.그리고 경우에 따라 개발팀은 수정할 수 없는 (또는 예상하지 못한) 버그가 포함된 보고서를 받게 될 수도 있습니다. 이 보고서는 여전히 발견의 일부여야 하며, 개인적으로 받아들여서는 안 됩니다.

이를 위한 “행복한 매개체”는 펜테스터, 보안 담당자 및 개발 관리자가 멘토 역할을 더 많이 맡아 팀이 효과적인 교육 및 도구 측면에서 필요한 것을 확보할 수 있도록 하여 개별 코더에게 SDLC 초기부터 성공하고 안전하게 코딩할 수 있는 최고의 기회를 제공하는 것입니다.건전한 DevSecOps 관행의 일환으로 처음부터 보안이 고려되도록 양 팀 모두 중간에 만나야 합니다.

“저는 제가 인정하는 것보다 훨씬 더 나은 보안 지식을 가지고 있습니다. 이러한 보고서는 대부분 오탐이거나 중요하지 않습니다.”

정적 분석은 SDLC의 보안 프로세스의 한 요소이며 정적 분석 스캐닝 도구 (SAST) 는 기본적인 역할을 합니다.그리고 네, 오탐지는 문제입니다 이러한 스캐너와 다른 유형의 스캐너 (DAST/IAST/RAST) 를 사용합니다.수동 코드 검토가 필요하고 개발자와 펜테스터 모두에게 압력을 가하기 때문에 이미 프로세스가 느리다는 점에서 성가신 일입니다.펜테스팅 담당자들은 부정확한 판독을 방지하기 위해 시간을 들여 사용자 지정 규칙을 세심하게 설정하고 회사별 지침을 제공했지만, 일부 잘못된 판독은 결국 머리를 긁는 개발자 앞에 놓이게 됩니다.

이 프로세스는 완벽하지는 않지만 또 다른 문제는 많은 개발자들이 많은 일반적인 취약점을 일관되게 완화할 수 있는 충분한 지식이 부족하다는 것입니다.고등 교육에서는 보기 드문 보안 교육과 실무 교육의 효과도 다양하기 때문에 일부 과신이 작용하고 있는 것은 당연합니다 (그리고 그건 그들의 잘못이 아닙니다. 업계로서 우리는 개발자들에게 필요한 것을 더 잘 제공할 필요가 있습니다).

“이 애플리케이션을 테스트하게 될 줄은 몰랐지만 이제는 수정 작업에 몰두하고 있습니다.”

때로 과로한 엔지니어들은 펜테스터가 애플리케이션을 테스트하고 개발팀의 퍼레이드에 비를 내리며 그저 날개에 매달려 있을 때를 기다리고 있을 뿐이라고 추측하기도 합니다.그들은 과잉 테스트하고, 빈약하고, 추가 작업을 만들고 있습니다.

유일한 문제는 그들 역시 과로하다는 것입니다 (사실 사이버 보안 기술 부족은 심각한 수준이고 점점 더 악화되고 있습니다) 그리고 단순히 이유 없이 테스트할 시간이 없습니다.테스트의 우선 순위를 결정하는 유일한 의사 결정자는 아닙니다. 고위 경영진이나 고객이 보안 감사의 일환으로 요청했거나 버그 바운티 프로그램의 결과로 확인되었을 수도 있습니다.

개발자의 경우 보안 수정 작업을 위해 현재 기능 구축 스프린트에서 제외되는 것은 성가신 일입니다. 특히 개발자의 작업이 아닌 경우에는 더욱 그렇습니다.아마도 이전 팀이 마지막 업데이트를 했거나 다른 공급업체가 진행했을 수도 있습니다.하지만 보안은 모두의 문제입니다.그렇다고 모든 개발자가 보안 버그를 자신이 직접 만든 것처럼 책임져야 한다는 뜻은 아닙니다. 하지만 보안이 공동 책임이라는 측면에서 각자 참여해야 한다는 뜻입니다.

여기서 어디로 갈까요?

때로는 사고 방식의 변화만으로도 문제를 해결하는 데 상당한 진전을 이룰 수 있습니다.펜테스트 결과가 좋지 않을 경우 개발자가 보이는 다소 냉담한 반응에 대해 이야기한 적이 있습니다. 하지만 개발자가 이를 도전으로 바꿀 수 있다면 어떨까요?아마도 그들은 펜테스터를 친근한 경쟁자, 즉 자신의 게임에서 이길 수 있는 사람으로 생각할 수도 있습니다.결국, 코드를 작성할 때 흔히 발생하는 버그를 제거할 수 있는 보안을 잘 아는 개발자는 작업을 훨씬 더 어렵게 만들 것입니다.반대로 보안에 초점을 두지 않는 개발자는 소프트웨어를 쉽게 망가뜨릴 수 있을 때 펜테스터 개발자에게 종합적으로 패배하게 됩니다.

펜테스터와 개발자가 100% 조화를 이루지는 못할 수도 있지만, 조직이 보안을 주요 우선 순위로 삼고 팀, 특히 개발자의 성공을 위한 올바른 지식과 도구를 제공할 때 관계가 크게 개선될 수 있습니다.결국 전사적 차원의 긍정적인 보안 문화가 우선 순위인지 여부가 관건이며, 일반적인 취약점을 상대로 (현재) 지고 있는 싸움에서 싸우고 싶다면 반드시 그래야 합니다.