AppSec 툴링이 특효약이라면 왜 그렇게 많은 기업들이 이를 활용하지 않는 것일까요?

이 기사의 한 버전이 에 게재되었습니다. SC 매거진.여기에서 업데이트 및 신디케이트되었습니다.

‍

오늘날 보안 전문가들이 직면한 많은 난제 중 하나는 직면한 사이버 위험을 처리하는 데 사용할 솔루션의 균형을 파악하는 것입니다.예산은 도구와 인력으로 어떻게 나눠야 할까요?기존 기술 스택에 가장 적합한 도구 모음은 무엇입니까?옵션이 너무 많기 때문에 쉽게 답을 찾을 수 없으며 잘못된 옵션을 선택하면 나중에 시간과 비용이 소모됩니다.

최근 보고서에 따르면 애플리케이션 보안 도구 시장은 다음을 추적하고 있습니다. 현재부터 2025년까지 '폭발적인' 성장이는 성공적인 DevSecOps 관행에서 이들의 확실한 역할을 잘 보여주고 있으며, 잠재적인 보안 취약점을 포함한 코드 양이 증가하는 상황에서 업계 관련성이 높아지고 있음을 보여줍니다.

하지만 조금 이상한 문제가 있습니다. 전체 조직의 거의 절반이 취약한 코드를 고의로 배포합니다., 에도 불구하고 이러한 문제를 해결하도록 설계된 일련의 AppSec 도구를 사용합니다.부정할 수 없는 시장 수요가 급증하고 있는 제품의 경우 이는 거의 의미가 없습니다.왜 그렇게 많은 사람들이 정교한 보안 도구를 구매하다가 발견한 내용을 무시하거나 아예 사용하지 않는 걸까요?해변가의 집을 사는 것과 약간 비슷한데 숲 속 텐트에서 잠을 청하는 것과 비슷합니다.

AppSec 도구가 예상대로 활용되지 않는 데에는 몇 가지 이유가 있습니다. 도구 및 기능보다는 전체 보안 프로그램과 통합되는 방식에 관한 것입니다.

도구가 많다고 해서 문제가 줄어드는 것은 아닙니다.

기업이 소프트웨어 개발 프로세스를 발전시켜 애자일에서 DevOps로, 성스러운 천국인 DevSecOps (현재로서는 최고입니다) 로 이동함에 따라 여러 대의 스캐너, 모니터, 방화벽 및 모든 종류의 AppSec 도구를 구매하는 것이 불가피합니다.'더 많이, 더 좋은 것'으로 보일 수 있지만, 이는 종종 프랑켄슈타인의 괴물과 유사한 기술 스택으로 이어지며, 이것이 의미하는 모든 예측 불가능성을 내포하고 있습니다.

필요한 작업 범위에 비해 예산과 전문가 리소스가 점점 더 제한되고 있는 상황에서 혼란을 해결하고 앞으로 나아갈 최상의 툴링 경로를 찾는 것은 어려운 일이며 스캐닝과 수정이 필요한 코드는 계속 등장하고 있습니다.많은 조직에서 배송 코드를 보관해야 했던 것은 전혀 놀라운 일이 아닙니다. 하지만 이는 다소 우려스러운 일이며 여전히 우리의 데이터와 개인 정보 보호에 엄청난 위험을 초래하고 있습니다.

스캐닝 도구는 속도가 느리고 릴리스 민첩성에 영향을 미칩니다.

빠른 속도로 보안을 달성하는 것은 소프트웨어 개발에서 흰고래와 같습니다. 사실 우리는 조직에 DevSecOps 지향 접근 방식을 채택하도록 안내하면서도 여전히 이를 바로잡기 위해 노력하고 있습니다.90년대에는 꼼꼼한 수동 코드 검토가 보안 안전 장치 역할을 했을지 모르지만, 수천억 개의 코드가 쏟아지는 시대에는 손톱 가위로 축구 경기장을 준비하는 것만큼이나 효과적인 계획입니다.

스캐닝 도구는 잠재적 문제를 찾는 프로세스를 자동화하여 세심한 코드 검토 부분을 대신 수행합니다.문제는 CI/CD 파이프라인이 모든 실린더에서 실행되는 상황에서 여전히 속도가 느리고 어떤 도구로도 모든 취약점을 찾아내지 못한다는 것입니다.검사 후 보안 팀에서 드러내는 결과에는 몇 가지 눈에 띄는 문제도 있습니다.

1. 가 있습니다 제비 오탐 (및 네거티브)
2. 일부 형편없는 보안 전문가는 여전히 앉아서 수동 검토를 통해 팬텀 버그와 실제 버그를 분류해야 합니다.
3. 코드를 배포하기 전에 발견했어야 하는 일반적인 취약점이 너무 많이 드러나는 경우가 많습니다.비용이 많이 드는 보안 전문가들이 작은 것에서 발생하는 크고 복잡한 보안 문제로부터 주의를 돌리는 것을 정말로 원하시나요?
4. 스캐너는 찾아내지만 고칠 수는 없습니다.

사이버 보안 모범 사례에 따라 작업하고 시대와 함께 프로세스의 모든 단계에 보안을 포함하기 위해 최선을 다하는 조직에서도 스캐너가 주요 보호 수단이라면 위의 프로세스는 여전히 눈에 띄고 안전한 코드를 배포하는 데 너무 많은 일반적인 버그가 팀을 방해합니다.이 과정에서 문제가 발생할 수 있다는 것은 당연한 일이며, 이는 솔루션 세트를 구입했더라도 모든 잠재적 위험을 감당할 수 없는 최소한의 도구에만 의존하는 형태로 나타나는 것이 보통입니다.

일부 기술 주도 자동화는 코드 품질 저하로 이어질 수 있습니다.

스캐닝과 테스트는 방화벽 및 모니터링과 같은 필수 요소와 함께 AppSec 도구의 자동화된 프로세스의 부하를 감당하지만 시간이 지남에 따라 다른 일반적인 도구로 인해 실무 보안 기반이 손상될 수 있습니다.

예를 들어, RASP (런타임 애플리케이션 자체 보호) 기술은 코딩 속도를 저하시키지 않으면서 보안 태세를 강화하기 위해 종종 적용됩니다.애플리케이션의 런타임 환경에서 작동하여 악성 코드 입력, 실시간 공격으로부터 보호하고 이상한 실행 동작을 표시합니다.

확실히 추가 보호 기능이긴 하지만, 코드베이스의 잠재적 약점에 대한 안전 장치라고 생각하면 개발자는 안주할 수 있습니다. 특히 새로운 기능을 출시하는 데 있어 시장 출시 기한이 점점 더 어려워지는 상황에 직면했을 때 더욱 그렇습니다.런타임 시 자체 보호가 실수를 감지한다는 가정 하에 보안 코딩 관행은 따르지 않을 수 있습니다.개발자는 안전하지 않은 코딩 패턴을 만들기 위해 최선을 다하지는 않지만, 특히 자동화된 보호 장치가 있다는 전제하에 기능 제공을 위해 보안의 우선 순위가 낮아지는 경우가 많습니다.

도구에 장애가 발생할 수 있으며 (RASP의 경우 오탐을 방지하기 위해 모니터링 모드에서 실행되는 경우가 많으며, 이는 공격에 대한 보호가 아닌 가시성만 제공합니다), 그럴 경우 항상 신뢰할 수 있는 고품질의 안전한 코드입니다.코드를 다루는 모든 역할에 대한 보안 인식은 DevSecOps의 기본이며, 개발자가 보안 코드에 대한 교육을 받지 않거나 제작하지 않는 것은 실수입니다.안전한 코드와 안전하지 않은 코드를 작성하는 데에도 동일한 노력이 필요합니다. 즉, 안전한 코딩을 위한 지식을 얻는 데 실제 에너지가 필요합니다.RASP를 구현하고 최적화하는 데 소요되는 시간은 애초에 실수를 저지르지 않도록 개발자의 기술을 향상시키는 데 훨씬 더 잘 활용할 수 있습니다.

도구와 사람의 균형을 맞추는 것: 은총알은 아니지만 (현재로서는) 현존하는 가장 근접한 기술입니다.

DevSecOps의 주요 정신은 보안을 공동 책임으로 만드는 것입니다. 전력망에서 초인종에 이르기까지 우리의 삶에 동력을 공급하는 소프트웨어를 만드는 조직의 경우 더 높은 수준의 안전을 보장하기 위해 모든 사람이 여정에 참여해야 합니다.

도구로는 모든 것을 할 수 없으며 가장 저렴한 방법도 아닙니다.코드를 다루는 모든 사람에게 관련 보안 교육을 우선시하고, 개발 팀이 보안을 최우선으로 생각하도록 적극적으로 노력하며, 지원 역할을 하는 도구 모음을 통해 사람이 주도하는 긍정적인 보안 문화를 구축하면 단연 최고의 결과를 얻을 수 있습니다.

시간 제약, 절벽 등 보안 전문가가 밤에 잠을 못 이루게 하는 여러 가지 상황에도 불구하고 개발자들이 애초에 일반적인 보안 결함을 도입하지 않는다면 그러한 도구 (및 사용 여부에 관계없이) 는 위험 요소가 훨씬 적습니다.

‍