한 달 동안 12개의 코드 보안 도구를 테스트하며 깨달은 사실
요약
12개의 코드 보안 도구를 직접 테스트하며 얻은 인사이트를 공유합니다. Snyk, Semgrep, Trivy 등 주요 도구들의 장단점과 함께, 개발자들이 보안 도구 도입을 어려워하는 근본적인 원인인 비용, 복잡성, 노이즈 문제를 분석합니다.
핵심 포인트
- Snyk는 강력한 통합 기능을 제공하지만 높은 비용이 부담임
- Semgrep은 강력한 정적 분석 엔진이나 기능 범위가 제한적임
- Trivy는 훌륭한 오픈 소스 도구지만 결과물 분류의 노이즈가 심함
- Gitleaks는 비밀 정보 탐지에 필수적이나 단일 기능에 국한됨
- 도구의 파편화로 인한 인지적 부하가 보안 도입의 주요 장애물임
대부분의 개발자들은 자신의 코드를 스캔하지 않습니다. 보안에 관심이 없어서가 아닙니다. 도구들이 너무 비싸거나, 너무 복잡하거나, 혹은 너무 많은 노이즈(noisy)를 발생시키기 때문입니다.
저는 지난 한 달 동안 수십 개의 오픈 소스 리포지토리(open-source repositories)를 대상으로 12개의 보안 도구를 테스트했습니다. 어떤 것은 개발자당 수백 달러가 드는 엔터프라이즈 플랫폼이었고, 어떤 것은 한 가지 기능을 잘 수행하는 무료 오픈 소스 도구였습니다. 또 어떤 것은 온갖 것을 약속하는 AI 기반 플랫폼이었습니다. 제가 배운 점은 다음과 같습니다.
Snyk는 이유가 있는 업계 표준입니다. 이 플랫폼은 SAST(정적 애플리케이션 보안 테스트), SCA(소프트웨어 구성 분석), 컨테이너 스캐닝(container scanning), 그리고 IaC(Infrastructure-as-Code, 코드형 인프라)를 하나의 플랫폼에서 다룹니다. 개발자 경험(developer experience)이 세련되었고, 통합(integrations) 기능도 성숙해 있습니다. 하지만 개발자당 월 98달러라는 가격은 전담 보안 팀을 갖춘 엔터프라이즈를 겨냥한 것입니다. 5인 규모의 스타트업은 한 달에 490달러를 지불해야 합니다. 1인 개발자는 Snyk에 전체 클라우드 인프라 비용보다 더 많은 돈을 지불합니다. 무료 티어(free tier)는 개발자 한 명으로 제한되며 신용카드가 필요합니다.
Semgrep은 사용 가능한 가장 강력한 정적 분석(static analysis) 엔진입니다. Semgrep의 커스텀 규칙 언어는 타의 추종을 불허합니다. 보안 연구원들은 무엇이든 규칙을 작성할 수 있기 때문에 이 도구를 좋아합니다. 하지만 Semgrep은 정적 분석만 수행합니다. 의존성 스캐닝(dependency scanning)도, 비밀 정보 탐지(secrets detection)도, 컨테이너 보안(container security)도 지원하지 않습니다. Snyk가 다루는 범위를 맞추려면 Semgrep을 Trivy, Gitleaks, Checkov 및 다른 4개의 도구와 함께 실행해야 합니다. 각 도구는 자신만의 CLI, 설정, 출력 형식을 가지고 있습니다. 5개의 서로 다른 보안 도구를 관리해야 하는 인지적 부하(cognitive load)가 바로 대부분의 개발자가 시작조차 하지 않는 이유입니다.
Trivy는 최고의 오픈 소스 의존성 및 컨테이너 스캐너입니다. 빠르고 무료이며 CI/CD 파이프라인에 쉽게 통합됩니다. 하지만 필터링 없이 가공되지 않은 결과물(raw output)을 쏟아냅니다. 중간 규모의 리포지토리를 스캔하면 수백 개의 결과가 생성됩니다. 대부분은 테스트 파일, 빌드 아티팩트(build artifacts), 또는 프로덕션에 영향을 주지 않는 의존성에 포함된 내용입니다. Trivy의 결과물을 수동으로 분류(triaging)하는 데는 몇 시간이 걸립니다. 대부분의 개발자는 이를 한 번 실행해 보고, 텍스트의 벽을 마주한 뒤 다시는 실행하지 않습니다.
Gitleaks는 하드코딩된 비밀 정보(secrets)를 잡아내는 데 필수적입니다. 이 도구는 API 키, 토큰, 비밀번호가 프로덕션(production) 환경에 도달하기 전에 찾아냅니다. 하지만 Trivy와 마찬가지로, 한 가지 일만 수행합니다. 다른 모든 것을 위해서는 여전히 별도의 도구들이 필요합니다. Python 보안을 위한 Bandit, 코드형 인프라(Infrastructure-as-Code, IaC)를 위한 Checkov, JavaScript를 위한 ESLint, Dockerfile을 위한 Hadolint, 그리고 오픈 소스 취약점(open-source vulnerabilities)을 위한 OSV-Scanner도 마찬가지입니다. 각 도구는 특정 카테고리에서 매우 뛰어납니다. 하지만 그 어떤 것도 전체적인 그림을 보여주지는 못합니다.
노이즈(noise) 문제는 생각보다 더 심각합니다. 모든 보안 도구는 오탐(false positives)을 발생시킵니다. 테스트 파일이 프로덕션 코드로 분류되기도 하고, 빌드 아티팩트(build artifacts)가 애플리케이션 로직으로 취급되기도 합니다. 의도적으로 작성된 문서화된 패턴이 취약점으로 보고되기도 합니다. 중간 규모의 저장소(repository)를 일반적인 방식으로 스캔하면 100개에서 200개의 결과가 나옵니다. 수동으로 분류(triage)를 거치고 나면, 실제 문제는 아마 6개 정도일 것입니다. 나머지 194개는 노이즈입니다. 이것은 버그가 아닙니다. 보안 도구가 작동하는 방식 자체의 근본적인 문제입니다. 이 도구들은 문맥(context)을 이해하지 못한 채 패턴 매칭(pattern-match)을 수행합니다.
AI 솔루션은 주장하는 것만큼 똑똑하지 않습니다. 현재 여러 플랫폼이 AI 기반의 수정 사항 생성(fix generation) 기능을 제공하고 있습니다. 아이디어 자체는 매력적입니다. 취약점을 찾으면 AI가 패치(patch)를 작성한다는 것입니다. 하지만 실제로 수정 사항은 복불복입니다. 때로는 완벽하지만, 때로는 새로운 버그를 유발하기도 합니다. 때로는 컴파일조차 되지 않는 변경 사항을 제안하기도 합니다. AI 수정 사항 생성은 유용한 보조 도구일 뿐, 인간의 검토(human review)를 대체할 수는 없습니다. 이와 다르게 말하는 사람은 무엇인가를 팔려고 하는 것입니다.
보안 도구의 실제 비용은 라이선스 비용이 아닙니다. 그것은 오탐을 분류(triage)하는 데 소비되는 시간입니다. 개발자가 6개의 실제 문제를 찾기 위해 200개의 결과물을 분류하는 데 3시간을 쓴다면, 그 3시간은 새로운 기능을 개발하지 못한 시간이 됩니다. 빠르게 제품을 출시해야 하는 스타트업에게 그 시간은 월간 구독료보다 더 가치 있습니다. 성공하는 도구는 가장 많은 기능을 가진 도구가 아니라, 분류(triage) 시간을 줄여주는 도구입니다.
실제로 효과가 있는 것은 범위(breadth)와 지능(intelligence)의 결합입니다. 아무것도 놓치지 않도록 모든 엔진이 작동해야 합니다. 무엇이 의도된 것이고 무엇이 아닌지를 이해하기 위해 프로젝트 문서(documentation)를 읽는 AI가 필요합니다. 어디에 집중해야 할지 알 수 있도록 모든 탐지 결과(finding)에 대한 신뢰도 점수(confidence scores)가 필요합니다. 그리고 소규모 팀에게 합리적인 가격이어야 합니다.
모든 것을 테스트한 후, 저는 저만의 도구를 만들었습니다. 이름은 Debuggix입니다. 이 도구는 9개의 엔진을 병렬로 실행합니다. 정적 분석(static analysis)을 위한 Semgrep, Python을 위한 Bandit, 비밀 정보(secrets) 탐지를 위한 Gitleaks 및 TruffleHog, 의존성(dependencies)을 위한 Trivy 및 OSV-Scanner, JavaScript를 위한 ESLint, Dockerfile을 위한 Hadolint, 그리고 인프라(infrastructure)를 위한 Checkov가 포함됩니다. AI는 README와 SECURITY.md를 읽어 노이즈(noise)를 걸러냅니다. 134개의 가공되지 않은 탐지 결과(raw findings)가 있는 스캔을 수행하면 6개의 실제 이슈가 드러납니다. 공개 저장소(public repos)는 무료이며, 비공개 저장소(private ones)는 월 29달러입니다. 개발자당 과금 방식이 아닙니다. 무료 티어 사용 시 신용카드가 필요하지 않습니다.
Debuggix에서 직접 체험해 보실 수 있습니다. 아니면 계속해서 5개의 서로 다른 CLI 도구를 실행하며 오후 시간을 오탐(false positives)을 분류(triaging)하는 데 소비하셔도 됩니다. 어느 쪽이든 상관없습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기