최근 KrebsOnSecurity에서 사이버 보안 스타트업인 'Zero-Day Market'에 관한 기사를 보았습니다. 이 회사는 유죄 판결을 받은 범죄자와 음모론가 몇 명이 운영하는 것으로 알려져 있습니다. 그들은 인기 소프트웨어의 제로데이 취약점을 확보하기 위해 수백만 달러를 걸고 연구원들을 현혹하려 하고 있습니다. 처음 떠오른 생각은 관련된 특정 인물들(물론 이것 자체가 경고 신호이긴 합니다)에 대한 것이 아니라, 이 시스템을 구축하고 유지하는 우리 개발자들에게 미치는 더 광범위한 영향에 관한 것이었습니다. 이것은 단순히 보안팀의 문제가 아닙니다. 이는 개발자 문제입니다.

제로데이 시장의 매력과 위험성

모르는 분들을 위해 설명하자면, '제로데이(zero-day)'란 해당 취약점을 완화하는 데 관심이 있어야 하는 사람들(예: 대상 소프트웨어 공급업체)에게 알려지지 않았으며, 아직 패치나 수정 사항이 공개적으로 발표되지 않은 소프트웨어 취약점입니다. 제로데이가 발견되었고 공급업체에 즉시 _공개_되지 않는 경우, 다양한 시장에서 판매될 수 있습니다. 일부는 윤리적(책임 있는 공시 정책을 가진 버그 바운티 프로그램과 같은)이지만, 일부는... 그렇지 않은 곳도 있습니다.

보고서에 따르면 이 'Zero-Day Market' 스타트업은 바로 그 회색 영역에서 운영되고 있으며, 창립자들의 배경을 고려할 때 솔직히 말해 어두운 쪽에 크게 기울어져 있습니다. 그들은 본질적으로 익스플로잇(exploit)의 마켓플레이스를 만들고 있으며, 이는 다양한 행위자들에 의해 다양한 목적으로 사용될 수 있습니다. 일부는 잠재적으로 합법적일 수 있지만(이 무리에게서는 가능성이 낮지만 방어 보안 테스트와 같은), 다른 많은 것들은 공격적인 사이버 작전, 감시 또는 노골적인 범죄 활동을 위한 것입니다.

우리 같은 개발자들에게 이것이 의미하는 바

개발자인 우리는 종종 방어의 최전선에 있습니다. 우리가 코드를 작성하고, 라이브러리를 선택하며, 서비스를 구성합니다. 견고하고 그림자 같은 제로데이 시장의 존재는 우리의 일상적인 업무에 몇 가지 중요한 것을 의미합니다:

1. 침해 가정(Assume Compromise): 이는 '침해를 가정한다(assume breach)'는 사고방식을 강화합니다. 아무리 좋은 코드를 작성했거나, 많은 테스트를 작성했거나, 보안 스캐너를 많이 실행하더라도, 여러분의 의존성 중 하나 또는 심지어 자체 코드베이스에 존재하는 제로데이 취약점이 악용되기를 기다리고 있을 비제로(non-zero) 확률은 항상 존재합니다.
2. 공급망 보안이 가장 중요하다(Supply Chain Security is Paramount): 의존성이 깊어질수록, 제로데이가 발생할 수 있는 표면적(surface area)은 높아집니다. 이것은 직접적인 의존성에 관한 것만이 아닙니다. 전체 소프트웨어 공급망에 관한 것입니다. 우리는 우리의 코드가 어디서 왔는지, 그리고 그 안에 무엇이 들어있는지에 대해 경계심을 가져야 합니다.
3. 취약점 관리는 지속적인 과정이다(Vulnerability Management is a Continuous Process): 이것은 한 번 하고 끝나는 일이 아닙니다. 새로운 취약점들은 매일 발견됩니다. 우리는 CVE(Common Vulnerabilities and Exposures)를 모니터링하고, 의존성을 신속하게 패치하며, 보안 환경에 대한 정보를 얻기 위한 강력한 프로세스가 필요합니다.
4. 책임 있는 공개가 핵심이다(Responsible Disclosure is Key): 만약 여러분이 취약점을 발견했다면, 책임 있는 공개(vendor에게 비공개로 통지하고 대중 공개 전에 패치할 시간을 주는 것)는 윤리적인 경로입니다. 이러한 '제로데이 마켓'과 같은 플랫폼은 이를 적극적으로 저해하며, 즉각적이고 미공개된 판매를 추구합니다.

실질적인 단계: 코드와 프로세스

제가 제로데이가 발견되는 것을 막는 코드를 보여드릴 수는 없지만, 알려진 취약점의 *영향(impact)*과 *발견 시간(discovery time)*을 완화하고 의존성에 대해 경계심을 유지하는 방법을 통합할 수 있는 도구와 관행을 보여드릴 수는 있습니다.

다음은 Node.js 프로젝트의 package.json을 사용하여 CI/CD 파이프라인에 의존성 취약점 스캐너를 통합하는 방법에 대한 단순화된 예시입니다. 많은 도구들이 존재하며(예: Snyk, npm audit, GitHub Dependabot), 이들은 매우 중요합니다.

# .github/workflows/security-scan.yml
name: Security Scan
...```

이 스니펫은 기본적인 단계이지만 필수적인 첫걸음인 `npm audit`을 자동화하는 것을 보여줍니다. 더 강력한 공급망 보안(supply chain security)을 위해서는 직접 의존성뿐만 아니라 모든 전이적 의존성(transitive dependencies)까지 스캔하고 새로운 CVE를 지속적으로 모니터링하는 도구를 통합해야 합니다.

### 제 견해: 경계심을 늦추지 말고, 정보를 습득하세요

이 특정 뉴스가 업그레이드할 가치가 있을까요? 특정 기술 업그레이드의 측면에서는 그렇지 않지만, 이는 우리의 '보안 마인드셋(security mindset)' 자체를 업그레이드해야 한다는 강력한 상기시켜주는 계기가 됩니다. 이 이야기는 자원을 충분히 확보한 악의적인 행위자들이 소프트웨어를 악용하기 위해 적극적으로 노력하고 있다는 현실을 강조합니다.

실제 세계에서의 트레이드오프는 간단합니다. 지금 견고한 보안 관행(예: 의존성 스캐닝, 코드 리뷰, 위협 모델링(threat modeling), 책임 있는 공개 정책(responsible disclosure policies))에 시간과 자원을 투자할 것인가, 아니면 제로데이 취약점(합법적인 연구원으로부터 오든 수상한 시장에서 오든)이 시스템을 손상시키는 데 사용될 때 나중에 훨씬 더 높은 대가를 치를 것인가입니다. 개인적으로는 개발자들의 보안 실사(due diligence)가 더 이상 선택 사항이 아니라 핵심 역량이라고 생각합니다. 경계심을 늦추지 말고, 정보를 습득하며, 처음부터 안전하게 구축해야 합니다.