AppSec 도구가 만능 해결책이라면, 왜 많은 기업이 이를 제대로 활용하지 못하고 있을까요?

이 기사는 SC Magazine에 게재되었던 내용을 바탕으로 업데이트하여 재게재한 것입니다.

‍

오늘날 보안 전문가들이 직면한 여러 난제 중 하나는 사이버 위험을 관리하기 위해 어떤 솔루션을 조합할지 결정하는 것입니다. 도구와 인력에 예산을 어떻게 배분해야 할까요? 기존 기술 스택에 가장 적합한 도구 모음은 무엇일까요? 선택지가 너무 많아 정답을 찾기 어렵고, 잘못된 선택은 결국 시간과 비용의 낭비로 이어집니다.

최근 보고서에 따르면 애플리케이션 보안 도구 시장은 2025년까지 '폭발적인' 성장을 기록할 것으로 전망됩니다. 이는 성공적인 DevSecOps 실무에서 보안 도구가 차지하는 독보적인 역할과, 잠재적 보안 취약점을 가진 코드의 양이 급증함에 따라 업계 내 중요성이 커지고 있음을 강력하게 시사합니다.

하지만 다소 의아한 문제가 있습니다. 조직의 절반 가까이가 취약점이 있는 코드를 알고도 배포하고 있습니다. 바로 그 문제를 막기 위해 설계된 다양한 AppSec 도구를 사용하고 있음에도 말이죠. 시장 수요가 확실하고 빠르게 성장하는 제품군에서 이는 납득하기 어려운 일입니다. 왜 많은 기업이 정교한 보안 도구를 구매하고도 그 결과를 무시하거나 아예 사용하지 않는 걸까요? 이는 마치 해변가에 집을 사놓고 정작 숲속 텐트에서 잠을 자는 것과 같습니다.

AppSec 도구가 기대만큼 활용되지 않는 데에는 몇 가지 이유가 있습니다. 이는 도구 자체나 그 기능의 문제라기보다는, 보안 프로그램 전체와 도구가 어떻게 통합되느냐의 문제입니다.

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

기업이 소프트웨어 개발 프로세스를 Agile에서 DevOps로, 그리고 DevSecOps라는 이상향(현재로서는 최선의 방법이죠)으로 발전시켜 나가는 과정에서, 수많은 스캐너, 모니터링 도구, 방화벽 등 온갖 AppSec 도구를 도입하는 것은 필연적입니다. '다다익선'처럼 보일 수 있지만, 이는 종종 프랑켄슈타인의 괴물처럼 예측 불가능한 기술 스택을 만드는 결과를 초래합니다.

필요한 업무 범위에 비해 예산과 전문 인력은 점점 제한되는 상황에서, 엉망이 된 시스템을 바로잡고 최선의 도구 도입 경로를 찾는 것은 벅찬 과제입니다. 스캔과 수정이 필요한 코드는 계속해서 쏟아져 나옵니다. 많은 조직이 위험을 감수하면서도 코드를 계속 배포할 수밖에 없는 현실은 매우 우려스러우며, 여전히 우리의 데이터와 개인정보에 엄청난 위협이 되고 있습니다.

스캔 도구는 속도가 느리며, 이는 릴리스 민첩성에 영향을 줍니다.

소프트웨어 개발에서 보안과 속도를 동시에 잡는 것은 마치 '흰 고래'를 쫓는 것처럼 어려운 일입니다. 사실 우리는 조직이 DevSecOps 접근 방식을 채택하도록 이끌면서도 여전히 그 균형을 맞추기 위해 고군분투하고 있습니다. 90년대에는 꼼꼼한 수동 코드 검토가 보안의 안전장치로 작동했을지 모르지만, 수천억 줄의 코드가 쏟아져 나오는 지금, 이는 손톱깎이로 축구장 잔디를 깎으려는 것만큼이나 비효율적인 계획입니다.

스캔 도구는 잠재적 문제를 찾는 과정을 자동화하여 우리 대신 꼼꼼한 코드 검토를 수행합니다. 문제는 CI/CD 파이프라인이 최고 속도로 돌아가는 상황에서 스캔 도구는 여전히 느리고, 단 하나의 도구로 모든 취약점을 찾아낼 수는 없다는 점입니다. 또한 스캔 후 보안 팀에 전달되는 결과물에는 다음과 같은 몇 가지 치명적인 문제가 있습니다.

1. 오탐(및 미탐)이 너무 많습니다.
2. 여전히 보안 전문가가 직접 수동으로 검토하여 진짜 버그와 가짜 버그를 가려내야 합니다.
3. 배포 전에 걸러졌어야 할 흔한 취약점들이 너무 많이 발견되곤 합니다. 정말로 비싼 몸값을 자랑하는 보안 전문가들이 사소한 문제 때문에 정작 중요하고 복잡한 보안 문제를 놓치길 원하시나요?
4. 스캐너는 발견만 할 뿐, 수정은 하지 않습니다.

사이버 보안 모범 사례를 따르고 프로세스의 모든 단계에 보안을 포함하기 위해 최선을 다하는 조직이라 할지라도, 스캐너가 주된 보호 수단이라면 위와 같은 문제는 여전히 발목을 잡습니다. 너무 많은 일반적인 버그가 안전한 코드 배포를 방해하기 때문입니다. 결국 편법을 쓰게 되고, 이는 솔루션 제품군을 구매했음에도 불구하고 모든 잠재적 위험을 커버할 수 없는 최소한의 도구에만 의존하는 형태로 나타나기 마련입니다.

일부 기술 주도형 자동화는 코드 품질을 저하시킬 수 있습니다.

스캔과 테스트는 AppSec 도구의 자동화된 프로세스에서 큰 비중을 차지하며, 방화벽이나 모니터링 같은 필수 요소와 함께 작동하지만, 다른 일반적인 도구들은 의도치 않게 시간이 지남에 따라 실무적인 보안 기반을 약화시킬 수 있습니다.

예를 들어, RASP(런타임 애플리케이션 자가 보호) 기술은 코딩 속도를 희생하지 않으면서 보안 태세를 강화하기 위해 자주 적용됩니다. 이 기술은 애플리케이션의 런타임 환경에서 작동하며 악성 코드 입력이나 실시간 공격을 방어하고, 비정상적인 실행 동작을 탐지합니다.

물론 추가적인 보호 계층이 되는 것은 사실이지만, 이를 코드베이스의 잠재적 약점에 대한 만능 안전장치로 생각하면 개발자들은 안일해질 수 있습니다. 특히 새로운 기능을 출시해야 하는 불가능에 가까운 마감 기한에 직면했을 때는 더욱 그렇습니다. 런타임 자가 보호 기능이 실수를 잡아줄 것이라는 가정하에 보안 코딩 관행을 따르지 않게 될 수 있습니다. 개발자가 의도적으로 보안에 취약한 코드를 만드는 것은 아니지만, 자동화된 보호 장치가 있다는 생각 때문에 기능 구현을 우선시하여 보안이 뒷전으로 밀리는 경우가 많습니다.

도구는 실패할 수 있습니다(RASP의 경우 오탐을 피하기 위해 모니터링 모드로 실행되는 경우가 많아 공격에 대한 가시성만 제공할 뿐 보호 기능은 제공하지 못합니다). 그럴 때마다 믿을 수 있는 것은 고품질의 안전한 코드뿐입니다. 코드를 다루는 모든 역할에서 보안 인식을 갖추는 것은 DevSecOps의 핵심이며, 개발자가 안전한 코드를 작성하기 위한 교육을 받지 않거나 안전한 코드를 생산하지 않는 것은 큰 실수입니다. 안전한 코드와 안전하지 않은 코드를 작성하는 데 드는 노력은 동일합니다. 진정한 에너지가 필요한 부분은 안전하게 코딩하는 지식을 습득하는 것입니다. RASP를 구현하고 최적화하는 데 들이는 시간은 개발자가 애초에 실수를 하지 않도록 역량을 강화하는 데 사용하는 것이 훨씬 더 효과적입니다.

도구와 사람 사이의 균형: 이것이 만능 해결책은 아니지만, (현재로서는) 우리가 가진 가장 최선의 방법입니다.

DevSecOps의 핵심 정신은 보안을 공동의 책임으로 만드는 것입니다. 전력망부터 초인종에 이르기까지 우리 삶을 움직이는 소프트웨어를 만드는 조직이라면, 더 높은 수준의 안전을 보장하기 위해 모든 구성원이 이 여정에 동참하도록 이끌어야 합니다.

도구만으로는 모든 것을 해결할 수 없으며, 비용 면에서도 가장 효율적인 방법이 아닙니다. 가장 좋은 결과를 얻는 방법은 코드를 다루는 모든 사람에게 적절한 보안 교육을 우선시하고, 개발 팀이 항상 보안을 염두에 두도록 적극적으로 노력하며, 도구는 보조적인 역할을 수행하는 가운데 사람이 주도하는 긍정적인 보안 문화를 구축하는 것입니다.

시간적 제약이나 지름길을 택해야 하는 상황 등 보안 전문가들의 잠을 설치게 하는 요소들이 있더라도, 개발자가 애초에 일반적인 보안 결함을 만들지 않는다면 그러한 도구의 사용 여부는 위험 요소로서의 비중이 훨씬 낮아집니다.

‍