백슬래시 보안의 Shahar Man 공동 창립자 및 CEO – 인터뷰 시리즈

Shahar Man, 백슬래시 보안의 공동 창립자 및 CEO는 클라우드 개발, 사이버 보안, 엔터프라이즈 소프트웨어에 대한 깊은 전문 지식을 갖춘 기술 리더입니다. 그는 현재 백슬래시 보안을 이끌고 있으며, 이 회사는 IDE, AI 에이전트, 생성된 코드 및 프롬프트 워크플로우를 포함한 AI 네이티브 소프트웨어 개발 환경을 보호하는 데 중점을 둡니다. इसस 전에, 그는 아쿠아 보안에서 제품 관리 및 연구 개발 부문 부사장을 역임하였으며, 개발 라이프사이클 전반에 걸쳐 컨테이너 보안을 위한 선도적인 플랫폼 중 하나를 구축하는 데 도움을 주었습니다. 그의 경력은 기술 및 리더십 역할에서 시작하여 스타트업 환경과 이스라엘의 방위 기술 부문에서 강한 엔지니어링 및 대규모 시스템 기초를 다졌습니다.

백슬래시 보안은 AI 주도 소프트웨어 개발을 위한 새로운 사이버 보안 플랫폼입니다. 이 회사는 AI 에이전트, 코드 생성 파이프라인, 현대적 개발자 워크플로우를 포함한 전체 AI 네이티브 개발 스택을 보호하는 데 중점을 둡니다. 이는 전통적인 보안 도구가 종종 간과하는 영역입니다. 개발자 속도를 방해하지 않으면서 가시성, 거버넌스, 실시간 보호를 제공함으로써, 백슬래시 보안은 자동 코딩 및 “바이브 코딩” 환경에서 발생하는 증가하는 위험을 해결하려고 합니다. 소프트웨어 생성이 점점 더 AI 지원 시스템으로 이동함에 따라, 이 플랫폼은 보안이 병목 현상이 되지 않도록 보안이 병렬로 진화하도록 설계되었습니다. 이는 백슬래시 보안을 DevSecOps와 차세대 AI 개발의 교차점에 위치시킵니다.

아쿠아 보안 및 SAP와 같은 회사에서 제품 및 연구 개발 부문 리더십 역할을 맡았으며, 백슬래시 보안을 공동 창립하기 전에, AI 네이티브 개발 및 바이브 코딩이 소프트웨어 생성을 근본적으로 재정의할 것이라는 초기 신호는 무엇입니까? 또한 보안이 이를 지원하기 위해 재건되어야 한다는 것을 어떻게 확신하셨나요?

클라우드 네이티브 아키텍처로의 소프트웨어 이동과 같은 주요 변화를 이미 경험했습니다. SAP와 아쿠아 보안에서 우리는 개발이如此 많이 변경될 때 보안이 뒤처지는 것을 직접 보았습니다. AI는 이것을 전혀 새로운 수준으로 끌어올렸습니다. 코드를 더 빠르게 작성하는 데 도움이 되는 것뿐만 아니라, 소프트웨어 생성을 둘러싼 전체 환경을 재정의하기 시작했기 때문입니다.

코드를 보호하는 것은 이제 코드 자체에 관한 것이 아니라 코드를 둘러싼 환경에 관한 것입니다. 1년도 되지 않아 상대적으로 제한적이고 낮은 위험의 개발 설정이 광범위하게 연결된 공격 표면으로 확장되었습니다. 이는 거의 감독이나 거버넌스가 없는 상태입니다. 일단 이것이 발생하면 코드 취약성에 대한 보안 질문이 완전히 달라집니다. 실제 문제는 특정 코드가 취약한지 여부가 아닙니다. 문제는 AI 주도 개발을 가능하게 함으로써, 우리는 코드 자체를 훨씬 넘어서는 시스템, 에이전트, 통합, 액세스 경로를 도입했다는 것입니다. 보안은 더 이상 코드의 출력만을 중점으로 둘 수 없습니다. 코드를 가능하게 하는 전체 환경을 고려해야 합니다.

바이브 코딩을 코드를 넘어서 프롬프트, 에이전트, MCP 서버, 툴링 레이어로 공격 표면을 확장하는 것으로 설명합니다. 개발자와 보안 팀이 현재 간과하고 있는 이 새로운 스택에서 가장 오해받는 위험은 무엇입니까?

가장 큰 오해는 많은 팀이 여전히 위험이 주로 생성된 코드에 존재한다고 생각하는 것입니다. 이것은 하나의 계층에 불과합니다. AI 네이티브 개발에서 위험은 더早い 시점에 그리고 더 많은 곳에서 도입됩니다. 이것은 프롬프트, 모델에 제공된 컨텍스트, 에이전트에 부여된 권한, 에이전트가 연결되는 MCP 서버, 개발을 확장하는 외부 툴 및 플러그인에서 발생할 수 있습니다. 단일 사용자의 랩톱이 잠재적으로 공격의 브릿지헤드로 사용될 수 있으며, 이는 엔드포인트의 문제로 나타날 수 있지만 실제로는 AI 코딩 문제입니다. 코드 취약성과 달리 이것은 응용 프로그램뿐만 아니라 전체 조직에 위험을 초래할 수 있습니다. 코드만看着 있다면 그림의 대부분을 놓치고 있습니다.

전통적인 애플리케이션 보안은 코드 검토에 중점을 두었습니다. AI 에이전트가 코드를 생성, 수정, 배포할 때 보안 생각은 어떻게 진화해야 합니까?

보안은 주기적인 검사에서 지속적인 감독으로 이동해야 합니다. 신뢰의 개념은 완전히 깨졌습니다. 신뢰할 수 있는 모델과 신뢰할 수 있는 MCP 서버가 있을 수 있지만, AI의 비결정론적 특성으로 인해它们는 여전히 조작되거나 예기치 않게 위험을 생성할 수 있습니다.

이것은 보안이 개발 프로세스와 함께 작동해야 하며, 더 깊은 거버넌스, 가드레일, 탐지 및 응답 기능을 갖추어야 함을 의미합니다. 즉, 어떤 툴을 사용하고 있는지, 어떤 컨텍스트를 소비하고 있는지, 어떤 정책이 그것들을 규정하고 있는지, 그리고 어떤 행동을 실시간으로 취하고 있는지에 대해 비판적으로 생각해야 합니다.

또한 AI 및 AI 모델이 취약성 처리에서 역할을 하는 것을 무시해서는 안 됩니다. 1년 전 AI 모델이 기본적으로 많은 취약성을 생성하는 반면, 현재는 상황이 상당히 개선되었습니다. 또한 다른 모델은 이전에 발견되지 않은 제로 데이를 발견하는 데 사용됩니다. 따라서 우리는 더 나은 출력으로 향하고 있습니다. 그러나 우리는誰가 그 작업을 감시하는지 궁금해합니다. 공격자는 다른 곳을 찾고 있습니다.

Cursor, Claude Code, GitHub Copilot과 같은 툴이 개발자 워크플로우에서 표준이 되고 있습니다. 이러한 툴을 적절한 거버넌스 레이어 없이 채택할 때 보안에서 가장 큰 격차는 어디에 있습니까?

가장 큰 격차는 가시성입니다. 많은 조직에서 이러한 툴이 빠르게 확산되고 있지만, 공식적인 검토 없이 확산되고 있습니다. 보안 팀은 어떤 에이전트가 사용되고 있는지, 어떻게 구성되어 있는지, 어떤 데이터에 액세스할 수 있는지, 어떤 외부 시스템에 연결되어 있는지 모르는 경우가 많습니다. 이것은影 IT와 유사한 影 AI 문제를 생성합니다. 이는 훨씬 더 빠르고 동적입니다.

두 번째로 큰 격차는 시행 가능한 정책의 부족입니다. 대부분의 조직은 지침을 가지고 있지만, 지침만으로는 개발자가 IDE 내에서 빠르게 이동할 때 도움이 되지 않습니다. 툴 및 워크플로우 레이어에 거버넌스가 없으면 팀은 기업 표준을 충족하지 않는 과다 허가된 툴을 위험에 빠뜨립니다. 이러한 툴 자체는 본질적으로 나쁘지 않지만, 거버넌스 없이 채택하면 개발 속도는 증가하지만, 통제는 증가하지 않습니다.

제3의 새로운 격차는 누구든 개발자가 될 수 있다는 것입니다. 우리는 이를 시티즌-개발자라고 부르며, 바이브 코딩 툴을 사용합니다. 재무 담당자가 Claude Code를 사용하여 프로세스를 자동화하고 내부 시스템에 연결할 때, 이는 잠재적인 위험을 생성하며, 이는 현재까지도 큰 맹점입니다.

백슬래시 보안은 개별 툴보다는 전체 AI 개발 에코시스템을 보호하는 데 중점을 두고 있습니다. 왜 이러한 풀스택 접근 방식이 필요한가요? 또한 조직이 이러한 위험을 분리하여 처리하는 경우에 어떤 일이 발생합니까?

위험은 스택의 어느 한 제품 내에만 존재하지 않습니다. AI 네이티브 개발은 본질적으로 에코시스템 문제입니다. 왜냐하면 많은 다른 장소에서 작동하며, 많은 다른 툴을 사용하기 때문입니다. IDE, 모델, 에이전트, MCP 서버, 외부 플러그인, 아이덴티티, 연결된 데이터 소스는 모두 무엇을 구축하고 어떻게 구축하는지에 영향을 미칩니다. 조직은 툴을 표준화하지 않으려 합니다. 왜냐하면 상대적인 강점이 매우 빠르게 변화하고 있기 때문입니다. 스택의 체인 중 하나만 보호한다면, 여전히 위험을 어떻게 이동하는지 놓치고 있습니다.

이러한 위험을 분리하여 처리하면 조각난 방어와 위험한 맹점이 생성됩니다. 코드 스캐너를 강화할 수 있지만, 모델에 위험한 컨텍스트를 제공한 MCP 서버를 간과할 수 있습니다. 이것이为什么 우리는 전체 AI 개발 에코시스템에 대한 풀스택 가시성 및 실시간 보호 접근 방식을 믿는 이유입니다. 그렇지 않으면, 조직은 증상만 해결하고 실제 공격 표면은 계속 확장됩니다.

프롬프트는 새로운 프로그래밍 가능성 계층으로 등장하고 있습니다. 프롬프트 주입, 데이터 누출, 조작과 같은 문제를 방지하기 위해 조직은 프롬프트를 보호하는 방법으로 어떻게 접근해야 합니까?

프롬프트는 점점 더 로직과 행동을 형성합니다. 많은 경우에, 이는 효과적으로 소프트웨어 생성을 위한 새로운 제어 평면입니다. 즉, 코드 또는 인프라 정의와 마찬가지로 정책, 모니터링, 가드레일이 필요합니다. 실제로, 이는 프롬프트가 액세스할 수 있는 항목과 트리거할 수 있는 다운스트림 액션을 제한하는 것으로 시작됩니다. 또한, 보안 및 품질 기대와 일치하는 프롬프트 규칙을 정의하는 것을 의미합니다. 또한, 컨텍스트 창을 통해 민감한 데이터가 노출되지 않도록 하며, 프롬프트 주입 또는 간접 지침 하이재킹과 같은 조작 시도를 감시합니다. 또한, 규칙 자체가 프롬프트 주입을 위한 백도어로 사용되지 않도록 해야 합니다. 더广い 관점에서, 개발자가 “주의하십시오”라고 지시하는 것이 아니라, 프롬프트가 실제로 발생하는 환경에 제어를 삽입함으로써 프롬프트를 보호합니다.

MCP 서버와 에이전트 스킬은 시스템 간의 동적 연결을 도입합니다. 보안 관점에서, 이것은 AI 주도 개발에서 가장 중요한 새로운 위험 벡터를 나타내는 것입니까?

MCP 서버와 에이전트 스킬은 주요한 새로운 위험 계층을 나타냅니다. 왜냐하면它们가 AI 시스템이 실제 세계와 어떻게 연결되고 상호작용하는지 정의하기 때문입니다. 스킬은 에이전트가 무엇을 할 수 있는지 정의하며, MCP는 에이전트의 액세스 및 시스템을 확장합니다. 함께,它们는 에이전트의 실제 행동을 형성합니다. 이러한 레이어가 엄격하게 제어되지 않으면, 조직은 AI 툴이 실제로 무엇을 할 수 있는지 및 무엇을 하고 있는지에 대한 가시성을 잃어버립니다. 코드 생성에서 행동으로의 전환은이如此 중요한 보안 영역을 만드는 것입니다. 또한,它们를 연결하면 더 예측할 수 없습니다.

하나의 핵심 테마는 “예스 부서”입니다. 즉, 개발자를 느리게 하지 않으면서 보안을 가능하게 하는 것입니다. 개발자 속도가 중요한 환경에서 실시간 보호와 개발자 속도를 어떻게 균형합니까?

보안은 늦게 발생하거나 개발자 실제 작업과 분리될 때 마찰을 생성합니다. 보안은 워크플로우에 직접 삽입되고 실제로 중요한 사항에 집중할 때 훨씬 더 효과적입니다. 이것은 백슬래시 보안이 시작된 이후 생각의 일부였으며,現在는 AI 주도 개발에서 훨씬 더 중요합니다.

실제로, 이는 실제 위험을 나타내는 몇 가지 문제를 개발자에게 제시하는 것을 의미합니다. 모든 이론적으로 의심스러운 항목을 개발자에게 넘겨주는 것이 아닙니다. IDE 및 에이전트 워크플로우에서 정책을 시행하는 것을 의미합니다. 또한, 투명하고 결정적인 가드레일을 생성하여 팀이 이동할 수 있도록 하되, 어떤 툴이 사용되고 있는지, 어떤 권한을 가지고 있는지, 그리고 何か 비정상적인 일이 발생하는지 알 수 있도록 합니다. 목표는 AI 채택을 느리게 하는 것이 아닙니다. 조직이 이를 자신감 있게 채택할 수 있도록 도와주는 것입니다. 실제로, 이는 개발자가最初에 오류를 कम Commit할 수 있도록 하되, 오류가 발생하면迅速하게 捕获 및 처리되도록 합니다.

비기술적 사용자가 AI 툴을 사용하여 소프트웨어를 구축하는 경우가 점점 더 많아지고 있습니다. 이러한 비개발자 바이브 코더의 증가가 위협 풍경을 어떻게 변화시키나요?

이것은 위협 풍경을 두 가지 방식으로 확대합니다. 첫째, 소프트웨어와 같은 출력을 생성할 수 있는 사람들이 증가하지만, 보안 영향에 대한 이해가 부족합니다. 둘째, 툴이 개발을 대화형이고 저마찰로 만듦으로써, 거짓된 안전감을 생성합니다.

즉, 조직은 보안 영향을 고려하지 않고 소프트웨어와 같은 출력을 생성할 수 있는 더 많은 사람들이 나타날 것입니다. 즉, 신뢰 경계, 입력 유효성, 의존성 위생, 액세스 제어 또는 데이터 노출과 같은 기본적인 엔지니어링 규율을 고려하지 않고, 워크플로우 및 시스템을 생성할 수 있습니다. 이는 소프트웨어가 더 많이 작성됨으로써 공격 표면이 확대되는 것뿐만 아니라, 더 많은 사람들이 소프트웨어와 같은 행동을 하는 워크플로우 및 시스템을 생성할 수 있기 때문에, 공격 표면이 확대됩니다. 이는 가시성 및 내장된 안전 장치가 더욱 중요하다는 것을 의미합니다. 왜냐하면, 더 이상 생성 지점에서 보안 지식을 가정할 수 없기 때문입니다.

12~24 개월을 내다보면, AI 네이티브 개발 워크플로우로 인해 어떤 유형의 공격이나 취약성이 나타날 것으로 예상합니까?

우리는 많은 일반적인 코드 취약성이 LLM의 개선 또는 “하네스” 내에 내장된 더 나은 프롬프트 규칙을 통해 처음부터 피할 수 있을 것으로 예상합니다. 만약 우리는 현재 코드 속도 증가로 인해 취약성의 증가를 보는 중이라면, 이것은 스스로 교정될 것입니다. 그리고 교정되지 않는 모든 것은 AI 활성화된 SAST 및 SCA(일부는 AI 플랫폼 벤더에서 제공됨, 예: Claude Code Security 및 프로젝트 Glasswing)에 의해 추적될 것입니다.

그러나, 미검사 및 미감독 AI 툴을 애플리케이션 개발에 사용할 때, 노출로 인해 훨씬 더 나쁜 결과가 발생할 것으로 예상합니다. 예를 들어, OpenClaw와 같은 오픈 소스 에이전트는 매우 나쁨 보안 기본값을 갖고 있으며, 사용자 기반은 보안 지식보다 바이브 코딩에 대한 열정을 훨씬 더 갖고 있습니다.

따라서, 우리는 개발 에코시스템 자체를 대상으로 하는 공격으로의 전환을 예상합니다. AI가 소프트웨어 생성의 일부가 되면서, 공격자는 프로세스를 형성하는 툴 및 연결을 조작하는 데 중점을 둘 것입니다. 즉, 소프트웨어가 배포되기 전에 이미 손상될 수 있습니다.

훌륭한 인터뷰에 감사드립니다. 더 많은 정보를 배우고 싶은 독자는 백슬래시 보안을 방문하십시오.