AppSec 툴링이 실버 글머리 기호라면 왜 그렇게 많은 회사가 그것을 발사하지 않는이유는 무엇입니까?
이 문서의 버전은 SC 매거진에등장. 여기에 업데이트되고 신디케이트되었습니다.
오늘날의 보안 전문가가 직면한 많은 수수께끼 중 하나는 그들이 직면한 사이버 위험을 처리하는 데 사용할 솔루션의 균형을 파악하는 것입니다. 예산은 어떻게 도구와 사람들 로 나누어야 합니까? 기존 기술 스택에 가장 적합한 도구 제품군은 무엇입니까? 거기에 너무 많은 옵션으로, 쉬운 답변이 없으며 잘못된 옵션을 선택하면 나중에 시간과 비용이 듭니다.
최근 보고서에 따르면 응용 프로그램 보안 도구 시장은 현재와 2025년 사이에 '폭발적인' 성장을추적하고 있으며, 이는 DevSecOps 성공적인 관행에서 명백한 역할을 보여주고 잠재적인 보안 취약점이 있는 코드의 양이 증가함에 따라 업계 관련성이 증가하고 있음을 밝혔습니다.
그러나 다소 호기심이 많은 문제가 있습니다. 모든 조직의 거의 절반이 고의로 취약한 코드를 발송하고 있습니다. 부인할 수 없는 시장 수요가 빠른 견인력을 얻고 있는 제품의 경우, 그것은 거의 의미가 없습니다. 왜 그렇게 많은 사람들이 정교한 보안 도구로 구입, 단지 자신의 결과를 무시하거나 전혀 사용하지? 그것은 해변가 집을 구입하는 것과 조금 비슷하며 숲의 텐트에서 잠을 자게됩니다.
AppSec 도구가 우리가 기대했던 대로 활용되지 않는 몇 가지 이유가 있으며 도구와 기능에 대해서는 덜 하며 보안 프로그램 전체와 통합하는 방법에 대해 더 많이 설명합니다.
더 많은 도구는 적은 문제와 동일시하지 않습니다.
기업들이 Agile에서 DevOps로 이동하는 소프트웨어 개발 프로세스를 발전시키고, DevSecOps(hey, now, it's best)인 거룩한 열반으로 발전함에 따라 여러 스캐너, 모니터, 방화벽 및 모든 종류의 AppSec 도구를 구매할 수밖에 없습니다. 그것은 '더, 즐거운'의 경우처럼 보일 수 있지만, 매우 자주이 프랑켄슈타인의 괴물을 닮은 기술 스택에 이르게, 이 것을 의미하는 모든 예측 불가능.
필요한 작업 범위에 대해 점점 더 제한되는 예산과 전문가 리소스를 통해 혼란을 취소하고 앞으로 최고의 툴링 경로를 찾으려고 노력하는 것은 어려운 작업이며 스캔 및 수정이 필요한 코드는 계속 진행됩니다. 많은 조직이 배송 코드를 유지해야했지만 다소 놀랍지만 여전히 데이터와 개인 정보 보호에 엄청난 위험을 초래한다는 것은 놀라운 일이 아닙니다.
스캐닝 도구는 느리고 이러한 영향은 민첩성을 방출합니다.
빠른 속도로 보안을 달성하는 것은 소프트웨어 개발에서 백색 고래의 무언가이며, 진실은, 우리는 여전히 우리가 DevSecOps 지향 접근 방식을 채택로 조직을 안내로 그 권리를 얻기 위해 노력하고 있습니다. 세심한 수동 코드 검토는 90 년대에 보안 페일세이프로 작동했을 수도 있지만 수백 억 개의 코드 라인을 휘젓는 시대에 는 손톱 가위로 축구 경기장을 준비하는 것만큼 효과적인 계획입니다.
스캐닝 도구는 잠재적인 문제를 찾는 프로세스를 자동화하여 세심한 코드 검토 부분을 수행합니다. 문제는 모든 실린더에서 CI/CD 파이프라인 이 발사되는 컨텍스트에서 여전히 느리며, 하나의 도구가 모든 취약점을 찾지 못했다는 것입니다. 또한 스캔 후 보안 팀에서 스팻되는 결과에 대한 몇 가지 눈부신 문제가 있습니다.
- 거짓 긍정 (및 네거티브)이 많이 있습니다.
- 일부 가난한 보안 전문가는 여전히 거기에 앉아서 팬텀 버그에서 실제 버그를 정렬하기 위해 수동 검토를 수행해야합니다
- 코드를 배포하기 전에 선택되어야 하는 일반적인 취약점이 너무 많은 경우가 많습니다. 당신은 정말 작은 물건과 크고 털이 보안 문제에서 산만 매우 비싼 보안 전문가를 원하십니까?
- 스캐너는 고치지 않습니다.
사이버 보안 모범 사례에 최선을 다하고 있는 조직에서도 프로세스의 모든 단계에서 보안을 포함해야 하는 시대와 함께 이동하는 조직에서도 스캐너가 주요 보호 조치이고 너무 많은 일반적인 버그가 안전한 코드를 배포하는 데 있어 팀을 이동하면 위의 프로세스는 여전히 쇼스토퍼입니다. 그것은 모서리가 여기에 절단 될 수 있다는 것을 추론하기 위해 서, 그리고 그 일반적으로 가능성이 모든 잠재적 인 위험을 커버 할 수없는 도구의 맨 최소에 의존의 형태로 온다, 솔루션의 제품군을 구입한 경우에도.
일부 기술 주도 자동화는 코드 품질 저하로 이어질 수 있습니다.
스캔 및 테스트는 방화벽 및 모니터링과 같은 필수 요소와 함께 AppSec 툴링에서 자동화된 프로세스의 부하를 부담하지만 다른 일반적인 도구는 시간이 지남에 따라 실수로 실습 보안 기반을 침식시킬 수 있습니다.
예를 들어 RASP(런타임 응용 프로그램 자체 보호) 기술은 코딩 속도를 희생하지 않고 보안 태세를 강화하기 위해 종종 적용됩니다. 응용 프로그램의 런타임 환경에서 작동하여 악성 코드 입력, 실시간 공격 및 홀수 실행 동작으로부터 보호합니다.
그것은 확실히 추가 보호의 계층, 하지만 코드 베이스에서 잠재적인 약점에 대 한 페일 세이프로 생각 하는 경우, 개발자 는 만족 될 수 있습니다., 새로운 기능을 밀어 점점 불가능 한 시장 이동 마감에 직면 하는 경우에 특히. 런타임에 자체 보호가 실수를 감지할 것이라는 가정하에 보안 코딩 관행을 따르지 않을 수 있습니다. 개발자는 안전하지 않은 코딩 패턴을 만들기 위해 길을 벗어나지 않지만 특히 자동화된 보호 장치를 가정하여 기능 제공에 우선 순위가 더 많이 드는 경우가 많습니다.
도구는 실패할 수 있으며 RASP의 경우 거짓 긍정을 피하기 위해 모니터링 모드에서 실행되는 경우가 많으며, 이는 공격에 대한 보호가 아닌 가시성만 제공하며, 그럴 경우 매번 신뢰할 수 있는 고품질의 보안 코드입니다. 코드를 터치하는 모든 역할의 보안 인식은 DevSecOps의 기본이며 개발자는 보안 코드를 교육하거나 생성하지 않는 것은 실수입니다. 안전하고 안전하지 않은 코드는 작성에 동일한 노력이 필요합니다. 그것은 실제 에너지를 소요 안전하게 코딩하는 지식을 얻고있다. RASP를 구현하고 최적화하는 데 소요되는 시간은 개발자를 업스킬링하는 데 훨씬 더 활용되어 처음부터 실수를 하지 않도록 할 수 있습니다.
도구와 사람들의 균형: 은색 총알은 아니지만,이 가장 가까운 것입니다 (지금은).
DevSecOps의 주요 정신은 보안을 공동의 책임으로 만드는 것이며, 전기 그리드에서 초인종에 이르기까지 우리의 삶에 힘을 실어주는 소프트웨어를 만드는 조직에 대해 더 높은 수준의 안전을 보장하기 위해 모든 사람을 여행에 데려와야 합니다.
도구는 모든 것을 하지 않습니다., 그리고 그것은 심지어 가장 저렴 한 방법. 지금까지 최상의 결과는 코드를 터치하는 모든 사람을 위한 관련 보안 교육의 우선 순위를 정하고, 개발 팀의 보안을 최우선으로 유지하기 위해 적극적으로 노력하고, 지원 역할을 하는 툴링 제품군을 통해 인간이 주도하는 긍정적인 보안 문화를 구축함으로써 달성됩니다.
시간 제약, 잘라 코너 및 보안 전문가가 밤에 잠을 잃게 만드는 다른 것들에도 불구하고 개발자가 처음에 일반적인 보안 결함을 도입하지 않으면 이러한 도구 (및 사용 여부)는 위험 요소의 훨씬 적은 것을 나타냅니다.
마티아스 마두, Ph.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
블로그에서 최신 보안 코딩 인사이트에 대해 자세히 알아보세요.
Atlassian의 광범위한 리소스 라이브러리는 안전한 코딩 숙련도를 확보하기 위한 인적 접근 방식을 강화하는 것을 목표로 합니다.
개발자 중심 보안에 대한 최신 연구 보기
광범위한 리소스 라이브러리에는 개발자 중심의 보안 코딩을 시작하는 데 도움이 되는 백서부터 웨비나까지 유용한 리소스가 가득합니다. 지금 살펴보세요.
AppSec 툴링이 실버 글머리 기호라면 왜 그렇게 많은 회사가 그것을 발사하지 않는이유는 무엇입니까?
이 문서의 버전은 SC 매거진에등장. 여기에 업데이트되고 신디케이트되었습니다.
오늘날의 보안 전문가가 직면한 많은 수수께끼 중 하나는 그들이 직면한 사이버 위험을 처리하는 데 사용할 솔루션의 균형을 파악하는 것입니다. 예산은 어떻게 도구와 사람들 로 나누어야 합니까? 기존 기술 스택에 가장 적합한 도구 제품군은 무엇입니까? 거기에 너무 많은 옵션으로, 쉬운 답변이 없으며 잘못된 옵션을 선택하면 나중에 시간과 비용이 듭니다.
최근 보고서에 따르면 응용 프로그램 보안 도구 시장은 현재와 2025년 사이에 '폭발적인' 성장을추적하고 있으며, 이는 DevSecOps 성공적인 관행에서 명백한 역할을 보여주고 잠재적인 보안 취약점이 있는 코드의 양이 증가함에 따라 업계 관련성이 증가하고 있음을 밝혔습니다.
그러나 다소 호기심이 많은 문제가 있습니다. 모든 조직의 거의 절반이 고의로 취약한 코드를 발송하고 있습니다. 부인할 수 없는 시장 수요가 빠른 견인력을 얻고 있는 제품의 경우, 그것은 거의 의미가 없습니다. 왜 그렇게 많은 사람들이 정교한 보안 도구로 구입, 단지 자신의 결과를 무시하거나 전혀 사용하지? 그것은 해변가 집을 구입하는 것과 조금 비슷하며 숲의 텐트에서 잠을 자게됩니다.
AppSec 도구가 우리가 기대했던 대로 활용되지 않는 몇 가지 이유가 있으며 도구와 기능에 대해서는 덜 하며 보안 프로그램 전체와 통합하는 방법에 대해 더 많이 설명합니다.
더 많은 도구는 적은 문제와 동일시하지 않습니다.
기업들이 Agile에서 DevOps로 이동하는 소프트웨어 개발 프로세스를 발전시키고, DevSecOps(hey, now, it's best)인 거룩한 열반으로 발전함에 따라 여러 스캐너, 모니터, 방화벽 및 모든 종류의 AppSec 도구를 구매할 수밖에 없습니다. 그것은 '더, 즐거운'의 경우처럼 보일 수 있지만, 매우 자주이 프랑켄슈타인의 괴물을 닮은 기술 스택에 이르게, 이 것을 의미하는 모든 예측 불가능.
필요한 작업 범위에 대해 점점 더 제한되는 예산과 전문가 리소스를 통해 혼란을 취소하고 앞으로 최고의 툴링 경로를 찾으려고 노력하는 것은 어려운 작업이며 스캔 및 수정이 필요한 코드는 계속 진행됩니다. 많은 조직이 배송 코드를 유지해야했지만 다소 놀랍지만 여전히 데이터와 개인 정보 보호에 엄청난 위험을 초래한다는 것은 놀라운 일이 아닙니다.
스캐닝 도구는 느리고 이러한 영향은 민첩성을 방출합니다.
빠른 속도로 보안을 달성하는 것은 소프트웨어 개발에서 백색 고래의 무언가이며, 진실은, 우리는 여전히 우리가 DevSecOps 지향 접근 방식을 채택로 조직을 안내로 그 권리를 얻기 위해 노력하고 있습니다. 세심한 수동 코드 검토는 90 년대에 보안 페일세이프로 작동했을 수도 있지만 수백 억 개의 코드 라인을 휘젓는 시대에 는 손톱 가위로 축구 경기장을 준비하는 것만큼 효과적인 계획입니다.
스캐닝 도구는 잠재적인 문제를 찾는 프로세스를 자동화하여 세심한 코드 검토 부분을 수행합니다. 문제는 모든 실린더에서 CI/CD 파이프라인 이 발사되는 컨텍스트에서 여전히 느리며, 하나의 도구가 모든 취약점을 찾지 못했다는 것입니다. 또한 스캔 후 보안 팀에서 스팻되는 결과에 대한 몇 가지 눈부신 문제가 있습니다.
- 거짓 긍정 (및 네거티브)이 많이 있습니다.
- 일부 가난한 보안 전문가는 여전히 거기에 앉아서 팬텀 버그에서 실제 버그를 정렬하기 위해 수동 검토를 수행해야합니다
- 코드를 배포하기 전에 선택되어야 하는 일반적인 취약점이 너무 많은 경우가 많습니다. 당신은 정말 작은 물건과 크고 털이 보안 문제에서 산만 매우 비싼 보안 전문가를 원하십니까?
- 스캐너는 고치지 않습니다.
사이버 보안 모범 사례에 최선을 다하고 있는 조직에서도 프로세스의 모든 단계에서 보안을 포함해야 하는 시대와 함께 이동하는 조직에서도 스캐너가 주요 보호 조치이고 너무 많은 일반적인 버그가 안전한 코드를 배포하는 데 있어 팀을 이동하면 위의 프로세스는 여전히 쇼스토퍼입니다. 그것은 모서리가 여기에 절단 될 수 있다는 것을 추론하기 위해 서, 그리고 그 일반적으로 가능성이 모든 잠재적 인 위험을 커버 할 수없는 도구의 맨 최소에 의존의 형태로 온다, 솔루션의 제품군을 구입한 경우에도.
일부 기술 주도 자동화는 코드 품질 저하로 이어질 수 있습니다.
스캔 및 테스트는 방화벽 및 모니터링과 같은 필수 요소와 함께 AppSec 툴링에서 자동화된 프로세스의 부하를 부담하지만 다른 일반적인 도구는 시간이 지남에 따라 실수로 실습 보안 기반을 침식시킬 수 있습니다.
예를 들어 RASP(런타임 응용 프로그램 자체 보호) 기술은 코딩 속도를 희생하지 않고 보안 태세를 강화하기 위해 종종 적용됩니다. 응용 프로그램의 런타임 환경에서 작동하여 악성 코드 입력, 실시간 공격 및 홀수 실행 동작으로부터 보호합니다.
그것은 확실히 추가 보호의 계층, 하지만 코드 베이스에서 잠재적인 약점에 대 한 페일 세이프로 생각 하는 경우, 개발자 는 만족 될 수 있습니다., 새로운 기능을 밀어 점점 불가능 한 시장 이동 마감에 직면 하는 경우에 특히. 런타임에 자체 보호가 실수를 감지할 것이라는 가정하에 보안 코딩 관행을 따르지 않을 수 있습니다. 개발자는 안전하지 않은 코딩 패턴을 만들기 위해 길을 벗어나지 않지만 특히 자동화된 보호 장치를 가정하여 기능 제공에 우선 순위가 더 많이 드는 경우가 많습니다.
도구는 실패할 수 있으며 RASP의 경우 거짓 긍정을 피하기 위해 모니터링 모드에서 실행되는 경우가 많으며, 이는 공격에 대한 보호가 아닌 가시성만 제공하며, 그럴 경우 매번 신뢰할 수 있는 고품질의 보안 코드입니다. 코드를 터치하는 모든 역할의 보안 인식은 DevSecOps의 기본이며 개발자는 보안 코드를 교육하거나 생성하지 않는 것은 실수입니다. 안전하고 안전하지 않은 코드는 작성에 동일한 노력이 필요합니다. 그것은 실제 에너지를 소요 안전하게 코딩하는 지식을 얻고있다. RASP를 구현하고 최적화하는 데 소요되는 시간은 개발자를 업스킬링하는 데 훨씬 더 활용되어 처음부터 실수를 하지 않도록 할 수 있습니다.
도구와 사람들의 균형: 은색 총알은 아니지만,이 가장 가까운 것입니다 (지금은).
DevSecOps의 주요 정신은 보안을 공동의 책임으로 만드는 것이며, 전기 그리드에서 초인종에 이르기까지 우리의 삶에 힘을 실어주는 소프트웨어를 만드는 조직에 대해 더 높은 수준의 안전을 보장하기 위해 모든 사람을 여행에 데려와야 합니다.
도구는 모든 것을 하지 않습니다., 그리고 그것은 심지어 가장 저렴 한 방법. 지금까지 최상의 결과는 코드를 터치하는 모든 사람을 위한 관련 보안 교육의 우선 순위를 정하고, 개발 팀의 보안을 최우선으로 유지하기 위해 적극적으로 노력하고, 지원 역할을 하는 툴링 제품군을 통해 인간이 주도하는 긍정적인 보안 문화를 구축함으로써 달성됩니다.
시간 제약, 잘라 코너 및 보안 전문가가 밤에 잠을 잃게 만드는 다른 것들에도 불구하고 개발자가 처음에 일반적인 보안 결함을 도입하지 않으면 이러한 도구 (및 사용 여부)는 위험 요소의 훨씬 적은 것을 나타냅니다.
