์ธํฐ๋ทฐ
์์ด๋ ์ ํ๋ง๋, ๋ถ์คํธ ๋ณด์์ CEO ๋ฐ ์ฐฝ๋ฆฝ์ – ์ธํฐ๋ทฐ ์๋ฆฌ์ฆ
자이드 알 하마니, 부스트 보안의 CEO 및 창립자는 20년 이상의 경험을 가진 사이버 보안 및 DevSecOps 리더입니다. 부스트 보안을 2020년에 창립한 이후, 그는 소프트웨어 개발 보안을 현대화하는 데 집중해 왔으며, 트렌드 마이크로의 애플리케이션 보안 부문 부사장 및 IMMUNIO의 공동 창립자/CEO를 포함한 이전 역할에서 경험을积累했습니다. 이전에는 캐노니컬에서 제품, 엔지니어링, 글로벌 지원 이니셔티브를领导한 선임 리더십 직책을 맡았으며, SITA에서 대규모 미션 크리티컬 IT 운영을 관리했습니다. 그의 경력은 팀을 구축하고 시스템을 최적화하며 현대적인 보안 관행을 발전시키는 강력한 기록을 보여줍니다.
부스트 보안은 개발자 중심의 DevSecOps 플랫폼을 통해 현대적인 소프트웨어 공급망을 보안하는 사이버 보안 회사입니다. 이 기술은 CI/CD 파이프라인에 직접 통합되어 취약성을 자동으로 обнаруж하고, 우선순위를 지정하고, 수정하여 수동 오버헤드를 줄이고 개발 속도를 유지합니다. 애플리케이션 및 공급망 보안을 단일 시스템으로 통합함으로써, 플랫폼은 코드, 종속성 및 인프라에 대한 전체 가시성을 제공하여 클라우드 네이티브 환경에서 복잡성을 강화하는 데 도움이 됩니다.
이전에는 트렌드 마이크로의 애플리케이션 보안을领导하고 IMMUNIO를 공동 창립했습니다. 부스트 보안을 창립하게 된 동기는 무엇이며, 시장에서 어떤 격차를 식별하기 위해 고유하게 위치했나요?
IMMUN.IO는 최초의 RASP 회사 중 하나였으며, 우리의 경험은 WAF가 런타임 보안 기술로서 유지 관리가 불가능하고 효과가 없다는 것을 보여주었습니다. 우리는 WAF를 대체할 수 있는 더 정확하고 유지 관리가 쉬운 솔루션을 구상했습니다. 즉, 애플리케이션을 기계화하는 것입니다.
그것은 2012년이었고, DevOps는 아직 초기였으며, 대부분의 팀은 애자일하지 않았으며, 쿠버네티스는 아직 존재하지 않았습니다.
트렌드 마이크로가 IMMUN.IO를 2017년에 인수했습니다. 그 때, 더 많은 DevOps 관행이 있었습니다. CI/CD 파이프라인, 애자일 개발 관행, 더 빠른 반복 및 릴리스 사이클, 클라우드 등이 있었습니다. 소프트웨어 개발 팀은 소프트웨어를 구축하고 출하하는 데 더 좋았으며, 보안은 여전히 깨졌습니다.
- 스캔이 너무 느리거나 결과가 너무 늦게 도착합니다.
- 결과가 개발자에게 작업하기에 너무 복잡합니다.
- 일반적으로 받아들이기 어려운 거짓 양성률이 있습니다.
- 새로운 유형의 아티팩트가 스캔되지 않습니다. 예를 들어 인프라 코드, 컨테이너, API 등이 있습니다.
소프트웨어를 빠르게 생성하는 것은 더 쉬웠습니다. 그러나 보안이 있는 소프트웨어를 빠르게 생성하는 것은 여전히 어려웠습니다.
그것이 우리가 해결하려고 했던 원래 문제입니다. DevSecOps를 실제 세계에서 작동하게 하십시오. 소프트웨어 개발 팀이 쉽게 SDLC에 보안을 추가할 수 있는지 확인하십시오. 범위가 넓은지 확인하십시오. 하나의 플랫폼이 모든 것을 다할 수 있는지 확인하십시오. 개발자가 기술을 채택하고 이점을 보는지 확인하십시오. 그것을 확장하여 보안 전문가의 군대를 필요로 하지 않도록 하십시오.
우리는 DevOps 시대에 SDLC에 보안을 주입하는 데 도움을 주었습니다. 그것은 1에서 10으로 가는 것이었습니다. 우리는現在 에이전트 코딩의 시대에 있습니다. 에이전트가 엄청난 양의 코드를 작성하지만, 본질적으로 동일한 문제입니다. 속도와 코드의 양이 10에서 100으로 증가했습니다. 우리는 동일한 궤적을 계속하려고 합니다.
소프트웨어 개발 수명주기(SDLC)가 근본적으로 업스트림으로 이동했다고 주장했습니다. 전통적인 DevSecOps 접근 방식이 더 이상 충분하지 않은 것을 깨달은 순간은 언제였나요?
공격자가 실제로 어떻게 침투하는지 관찰하면서였습니다. 우리는 동일한 패턴을 계속 보았습니다. 노출된 GitHub Actions 워크플로우, 토큰이 프로덕션 클라우드에 액세스할 수 있는.runner 구성 파일, 합법적인 CI 작업이 공격자 페이로드를 배포하도록 탈취되었습니다. 이것은 “파이프라인에서 살기” 공격으로 알려졌습니다. 공격자는 자신의 자동화를 사용하여 당신을 공격하고, 보안 팀이 이미 승인한 자격증명을 사용합니다.
우리가 구축한 DevSecOps 스택은 그것에 대한 답이 없었습니다. SAST는 애플리케이션 소스를 스캔합니다. SCA는 애플리케이션 종속성을 스캔합니다. 둘 다 파이프라인이 신뢰할 수 있는 것으로 가정합니다. 그러나 파이프라인 자체는 YAML 파일로, 셸 명령어, 네트워크 액세스 및 민감한 자격증명이 포함된 것입니다. 거의 아무도 그것을 검토하지 않습니다.
그것이 가장 저항이 적은 경로가 될 때, 코드를 완벽하게 깨끗하게 유지하고도 클라우드를 공격자에게 넘길 수 있습니다.
AI 에이전트가 지속적으로 코드를 생성하는 세계에서 기업은 SDLC를 어떻게 재고해야 합니까?
우리는 모두 SDLC를 체크포인트의 순서로 생각하는 것을停止해야 합니다. AI 에이전트는 코드가 작성된 후 프로덕션에 도달하는 시간을 주간에서 분으로 축소했습니다. 이전 모델은 코드 검토, SAST, SCA 및 배포 사이의 인간적인 간격을 가정했습니다. 그러나 우리는 이미 그 시대를 넘어섰습니다.
보안은 에이전트가 작동하는 곳에서 살아야 합니다. 개발자의 머신에서, 프롬프트 컨텍스트 내에서, 에이전트가 MCP 서버 및 외부 모델에 연결된 곳에서입니다. 코드가 파이프라인에 도달하는 순간, 이미 코드를 형성할 기회를 잃었습니다. 에이전트는 이미 종속성을 가져왔습니다. 모델은 이미 자격증명을 보았습니다. 제어를 업스트림으로 이동하십시오. 실제로 작업이 진행되는 곳에서입니다.
많은 조직은 아직 AI 코딩 도구를 단순한 생산성 계층으로 취급합니다. 왜 그것들이 기존 워크플로의 확장으로서가 아니라 완전히 새로운 공격 표면을 나타내는지 설명해 주시겠습니까?
AI 코딩 도구를 생산성 계층으로 취급하는 것은 루트 액세스가 있는 주니어 개발자를 생산성 계층으로 취급하는 것과 같습니다. 레이블은 기술적으로 정확하지만, 무엇이 잘못될 수 있는지에 대해 생각하는 데 유용한 프레임워크를 제공하지 않습니다.
코딩 에이전트는 파일시스템을 읽고, 환경 변수에서 컨텍스트를 스크레이핑하고, 공용 레지스트리에서 종속성을 가져오고, 원격 모델 제공자 및 MCP 서버와의 아웃바운드 연결을 열고, 셸 명령어를 실행합니다. 이러한 각 동작은 이전에는 인간의 개입이 필요했습니다. 이제 그것은 밀리초 안에 발생하며, 에이전트를 시작한 개발자와 동일한 특권을 가집니다.
그것은 이전에 별개였던 신뢰 경계를 융합합니다. 개발자의 권한, 외부 도구가 가져올 수 있는 것, 비신뢰할 수 있는 코드가 실행할 수 있는 것입니다. 그것은 공격자에게 새로운 기회를 제공하고, 수비수가 볼 수조차 없는 새로운 맹점을 생성합니다.
부스트는 개발자 랩톱을 새로운 제어 평면으로 프레이밍합니다. 보안 팀이 현재 간과하고 있는 엔드포인트에 어떤 위험이 있습니까?
가장 큰 것은 인벤토리입니다. 대부분의 보안 팀은 랩톱에서 실행 중인 AI 에이전트를 알지 못하며, 에이전트가 연결된 MCP 서버를 알지 못하며, IDE 확장 프로그램이 현재 리포지토리 콘텐츠를 스크레이핑하는지 알지 못합니다. EDR은 에이전트 계층에 대한 가시성이 없으며, SIEM도 로컬에서 에이전트가 하는 일을 볼 수 없습니다. 그것은 코드 실행 특권이 있는 섀도우 IT 문제입니다.
그 아래에는 자격증명 메스가 있습니다. 우리는 그것을 구체적으로 만들기 위해 Bagel이라는 오픈소스 도구를 구축했습니다. 일반적인 개발자 랩톱에는 프로덕션 리포지토리에 쓰기 액세스 권한이 있는 GitHub 토큰, 인프라를 시작할 수 있는 클라우드 자격증명, 수백만 명의 사용자에게 게시할 수 있는 npm 또는 PyPI 토큰 및 공격자가 재판매할 수 있는 AI 서비스 키가 있습니다.NONE이 하드닝된 방식으로 보호되지 않습니다. 동일한 머신은 또한 웹을 브라우징하고 임의의 VS Code 확장 프로그램을 설치합니다.
두 가지를 조합하면 실제 공격 표면이 됩니다. 개발자 특권으로 실행되는 비신뢰할 수 있는 확장 프로그램은 클라우드 키가 포함된 환경에서最高의 레버리지 대상입니다. 대부분의 팀은 아직 그것을 살펴보지 않았습니다.
AI 에이전트가 로컬 파일, 환경 변수 및 구성에 액세스할 수 있는 “컨텍스트 트랩”을 강조했습니다. 프롬프트를 통해 민감한 데이터가 누출되는 위험이 얼마나広く 퍼져 있으며, 그것을 감지하기가 왜 어려운가요?
관리되지 않는 개발 환경의 기본 상태로 간주할 정도로広く 퍼져 있습니다. 우리는 조사한 모든 코딩 에이전트가 로컬 컨텍스트를 공격적으로 가져옵니다. 그들은 도트 파일, 환경 변수, 최근 파일, 때로는 전체 디렉토리 트리, 그리고 컨텍스트를 원격 모델로 보냅니다. 도구는 그렇게 작동하도록 설계되었습니다. 공격적인 컨텍스트抓取은 그것們이 유용하게 만드는 것입니다.
감지 문제는 트래픽이 정상적인 제품 사용과 동일하게 보이기 때문에 시작됩니다. 그것은 api.openai.com 또는 api.anthropic.com으로의 TLS입니다. 그것은 승인된 비즈니스 애플리케이션에서 발생합니다. 표준 DLP는 개발자가 회사가 라이센스를 구매한 AI 도구를 사용하는 것을 볼 수 있습니다. 그러나 DLP는 프롬프트에 포함된 문자열 중 하나가 .env 파일에서 가져온 AWS 비밀 키라는 것을 보지 못합니다.
그것은 랩톱을 떠나기 전에 프롬프트를 검사함으로써만 감지할 수 있습니다. 이는 거의 모든 보안 스택이 현재 위치하지 않은 곳입니다.
기계 속도 공급망 공격에 대해 설명해 주시겠습니까? 전통적인 보안 도구가 취약성을 식별하기 전에 AI 에이전트가 취약성을 도입하는 현실적인 시나리오를 설명해 주시겠습니까?
여기서 한 가지 예가 있습니다. 개발자가 에이전트에게 HTTP 재시도 라이브러리가 필요한 기능을 추가하도록 요청합니다. 에이전트는 패키지 이름을 제안합니다. 패키지는 합리적으로 들리지만 실제로는 npm에 존재하지 않습니다. 한 시간 내에 공격자가 그것을 등록하고, 작동하는 재시도 논리 및 작은 post-install 스크립트와 함께 채웁니다. 스크립트는 ~/.aws/credentials를 읽고 내용을 웹후크에 게시합니다. 에이전트는 npm install을 실행하지만, 에이전트는 명성이 좋지 않기 때문에 확인하지 않습니다. 자격증명은 개발자가 코드를 실행하기도 전에 사라집니다.
공격 자체는 기술적으로 정교하지 않지만, 전통적인 공급망 보안은 알려진 취약성 및 알려진 패키지에 대한 것입니다. CVE, SBOM, 라이센스 스캔 등이 있습니다. 그 프레임워크는 이전에 존재하지 않았던 패키지, AI의 환상에 맞게 특별히 생성된 패키지, 그리고 스캔이 마지막으로 실행된 이후에 생성된 패키지에 대해 아무 것도 말할 수 없습니다.
공개에서 손상까지의 시간 창은 이제 분으로 측정됩니다. 事実 후에 확인하는 모든 것은 너무 늦습니다.
환상 종속성이 AI 주도 개발에서 가장 큰 위험 중 하나가 되고 있습니까? 조직이 그것에 대비하기 위해 어떤 실질적인 단계를 취할 수 있습니까?
이미 vậy입니다. 공격자는 인기 있는 AI 도구를 모니터링하여 환상 종속성을 등록하고 몇 분 내에 등록합니다. 몇 년 전 연구자들이 그것을 slopsquatting이라고 불렀으며, 이름이 붙었습니다. 한 번에 너무 자주 환상 종속성이 발생하면, 그것을 앉아 있는 것으로 남겨두는 것은 거의 노력 없이 공급망 공격이 됩니다.
실질적인 방어는 현재 대부분의 팀이 가지고 있는 것과 다릅니다. 시작은 가져오기에서입니다. 개발자의 머신에서 npm install 또는 pip install이 실행될 때, typosquatted 및 새로 등록된 패키지를 차단하십시오. CI에서 사후 감지는 post-install 스크립트가 이미 자격증명을 탈취한 후에는 도움이 되지 않습니다. 그런 다음 에이전트에게 가드레일을 제공하십시오. 승인된 종속성 목록을 에이전트의 컨텍스트에 직접 삽입하여 모델이 허용된 항목을 생성하기 전에 무엇이 허용되는지 보십시오. 개발자가 “보안 프롬프트”를 작성하도록 요청하는 것은 전략이 아닙니다. 전략적이면 보안이 경계를 설정하고, 에이전트가 그것을 상속합니다. 그리고 AI 물품 명세서를 추적하십시오. 대부분의 팀은 어떤 에이전트, 모델 및 패키지가 어떤 리포지토리와 상호작용하는지 알지 못합니다. आप 인벤토리할 수 없는 것을 방어할 수 없습니다.
CI/CD에서 보안을 시작할 수 없다고 말했습니다. 보안이 더 일찍 개발 프로세스에서 시작해야 할 때, 현대적인 보안 파이프라인은 무엇처럼 보입니까?
CI/CD에서 보안을 시작하면, 전체 프리 커밋 단계를 에이전트에게 넘겨줍니다. 에이전트는 이미 컨텍스트를 가져왔으며, 자격증명이 이미 다른 곳의 로그에 있을 수 있습니다. 당신은 시체를 스캔하고 있습니다.
현대적인 파이프라인은 랩톱에서 시작됩니다. 즉,そこ에서 실행 중인 에이전트와 확장 프로그램을 인벤토리화하는 것입니다. 에이전트와 통신할 수 있는 MCP 서버와 모델을 확인하는 것입니다. 머신에서 나가는 것을 정화하는 것입니다. 그리고 설치하기 전에 악의적인 패키지를 차단하는 것입니다. 거기서 정책은 IDE로 작업을 따릅니다. 우리는 에이전트의 컨텍스트 창에 직접 보안 표준을 삽입하여 생성된 코드가 업스트림에서부터 가드레일 내부에 유지되도록 합니다. 파이프라인은 여전히 실행되며, 업스트림에서 이미 적용된 제어에 대한 최종 확인을 수행합니다.
파이프라인 자체가 사라지지 않습니다. 그 역할은 확인으로 바뀝니다. 업스트림 제어가 유지되었는지 확인합니다.
조직이 AI 코딩 에이전트를 채택하는 동안, 개발 환경을 향후 몇 년 동안 안전하게 유지하기 위해 해야 할 가장 중요한 변경은 무엇입니까?
가장 큰 실수는 커밋된 것만을 보호하는 것입니다. 현재의 관심은 커밋되기 8시간 전입니다. 랩톱에서, 프롬프트에서, 패키지 설치에서 숨겨진 드라마가 발생할 수 있습니다. PR에서 시작하는 도구는 잘못된 워크플로의 반을 보호합니다.
관련된 내용입니다. 코딩 에이전트를 생산성 소프트웨어로 취급하는 것을 중지하십시오. 그것들은 셸 액세스, 리포지토리 쓰기 권한 및 아웃바운드 네트워크 연결을 가진 비인간 사용자입니다. 다른 특권 있는 ID와 마찬가지로 인벤토리, 승인된 기능 및 감사 로그와 함께 그것들을 거버넌스하십시오.
마지막으로 더 어려운 문화적 변화입니다. 대부분의 현재 “AI 보안” 도구는 결과를 표시하고 인간에게 라우팅합니다. 인간은 에이전트가 생성하는 속도에서 트라이지를 할 수 없습니다. 무엇을 채택하든지, 워크플로우 내에서 자동으로 문제를 해결하고 추적 가능한 이유를 제공하거나, 그것은 읽지 않는 또 다른 대시보드가 됩니다.
우수한 인터뷰에 감사드립니다. 더 많은 것을 배우고 싶은 독자는 부스트 보안을 방문하십시오.
