Techlist.io - 한국 테크 블로그 큐레이터

gitlab원문

GitLab Duo 에이전트 플랫폼을 활용한 탐지 격차 분석 자동화 (새 탭에서 열림)

GitLab의 Signals Engineering 팀은 보안 침해 사고 이후 발생하는 '탐지 격차(Detection Gap)' 분석을 자동화하기 위해 **GitLab Duo Agent Platform**을 활용하고 있습니다. 이 플랫폼은 AI 에이전트가 사고 타임라인과 데이터를 직접 분석하여 수동 검토 없이도 미흡했던 탐지 지점을 찾아내고, 이를 MITRE ATT&CK 프레임워크에 매핑하여 구체적인 개선안을 제시하도록 돕습니다. 결과적으로 보안 팀은 반복적이고 소모적인 분석 업무에서 벗어나 실제 탐지 역량을 강화하는 데 집중할 수 있게 되었습니다. ### 탐지 격차 분석의 어려움과 자동화의 필요성 * **탐지 격차의 정의:** 공격자가 행동을 취했음에도 불구하고 기존 보안 탐지 시스템이 이를 포착하지 못한 지점을 의미합니다. * **수동 분석의 한계:** 사고 데이터를 일일이 읽고 공격자의 행동을 탐지 기회와 매핑하는 작업은 시간이 많이 걸리며, 담당 엔지니어에 따라 결과가 일관되지 않을 가능성이 큽니다. * **워크플로우 통합:** GitLab 팀은 사고 기록이 남는 'GitLab Issues' 내에서 분석 과정이 자연스럽게 이루어지도록 자동화된 프로세스를 구축했습니다. ### GitLab Duo Agent Platform의 특징 * **에이전트 기반 프레임워크:** 단순한 챗봇을 넘어 추론하고, 행동을 취하며, 이슈(Issues)나 머지 리퀘스트(MR), 코드와 같은 GitLab 리소스와 기본적으로 통합되는 AI 에이전트를 구축할 수 있습니다. * **두 가지 활용 경로:** 즉시 사용 가능한 '보안 분석가 에이전트(Security Analyst Agent)'를 활용하거나, 특정 팀의 표준에 맞춘 '맞춤형 에이전트'를 직접 제작할 수 있습니다. ### 보안 분석가 에이전트 (Security Analyst Agent) 활용 * **즉각적인 도입:** 보안 도메인 지식이 사전 학습되어 있어, 종료된 사고 이슈에서 에이전트를 호출하는 것만으로 분석을 시작할 수 있습니다. * **분석 범위:** 사고 설명, 타임라인, 작업 내역 및 댓글을 검토하여 탐지가 누락된 전술, 기술 및 절차(TTP)를 식별합니다. * **장단점:** 별도의 설정 없이 바로 가치를 제공하지만, 기업 고유의 SIEM 환경이나 로그 소스, 특정 탐지 표준에 대한 맥락은 부족할 수 있습니다. ### 맞춤형 탐지 엔지니어링 어시스턴트 구축 기술 GitLab 팀은 더 정교한 분석을 위해 'Detection Engineering Assistant'라는 맞춤형 에이전트를 구축했으며, 핵심은 **시스템 프롬프트(System Prompt)** 설계에 있습니다. * **명확한 역할 정의:** 에이전트에게 "GitLab Signals Engineering 팀의 탐지 엔지니어"라는 구체적인 역할을 부여하여 응답의 일관성을 높였습니다. * **탐지 철학 주입:** 오탐(False Positive)을 줄이고 행동 기반 탐지를 우선시하는 팀의 원칙을 프롬프트에 포함하여, 에이전트가 팀의 기준에 맞는 권고안을 내도록 했습니다. * **기술 스택 및 로그 소스 정보:** 실제 사용 중인 SIEM과 수집 가능한 로그 소스 정보를 입력하여, 이론적인 제안이 아닌 실제 구현 가능한 탐지 규칙을 제안하게 했습니다. * **MITRE ATT&CK 및 출력 형식 지정:** 모든 결과를 ATT&CK 기법에 매핑하고, 탐지 누락 내용, 로그 소스, 권장 접근 방식을 포함한 정형화된 리스트로 출력하도록 설정했습니다. (실제 시스템 프롬프트는 약 1,870단어, 337행에 달할 정도로 상세함) ### 실용적인 권장 사항 AI를 이용한 탐지 분석 자동화를 고려한다면, 처음에는 GitLab에서 제공하는 **보안 분석가 에이전트**로 시작하여 AI의 잠재력을 확인해 보는 것이 좋습니다. 이후 분석의 정확도를 높이고 싶다면, 팀의 고유한 탐지 표준과 인프라 정보를 상세히 담은 **시스템 프롬프트**를 설계하여 맞춤형 에이전트를 구축하는 단계로 발전시킬 것을 권장합니다.

figma2분 읽기큐레이션 요약

AI 시대에 갈고닦아야 할 5가지 디자인 기술 | 피그마 블로그

AI는 제품 제작을 가속하고 디자인 참여자의 범위를 넓히고 있으며, 이에 따라 디자이너에게 요구되는 역량도 변화하고 있다. Figma의 「State of the Designer 2026」 조사에 따르면 AI 활용 능력은 선택 사항이 아니라 디자이너와 비디자이너 모두에게 중요한 기본 역량이 되고 있다. 특히 명확한 프롬프트를 작성하고 AI를 반복 가능한 디자인 워크플로에 통합하는 능력이 핵심이다. ## AI 도구 활용 능력과 프롬프트 역량 - AI 활용 능력은 이제 디자이너 채용에서 필수에 가까운 기술로 자리 잡고 있다. - 디자이너의 91%는 AI가 더 나은 디자인을 만드는 데 도움이 된다고 답했고, 89%는 업무 속도가 빨라졌다고 답했다. - 채용 담당자의 54%는 AI를 활용한 디자인을 디자이너에게 가장 중요한 수요 기술 중 하나로 꼽았다. - AI 디자인 역량은 디자이너에게만 요구되지 않는다. - 채용 담당자의 57%는 PM, 개발자, 마케터 등 비디자인 직군에도 AI 활용 능력이 중요하다고 답했다. - 활용 사례는 다음과 같이 다양하다. - 기존 이미지의 세부 요소를 AI로 수정하기 - 코드를 직접 작성하기보다 AI로 앱 프로토타입 만들기 - 제품 요구사항 문서(PRD)보다 먼저 작동하는 프로토타입을 제작해 아이디어 검증하기 ## 프로토타입 중심의 협업 - AI 도구가 보편화되면서 역할 간 경계가 흐려지고, 다양한 직군이 직접 디자인과 프로토타이핑에 참여하고 있다. - 특히 제품 관리자는 문서로 요구사항을 설명하기보다 프로토타입을 만들어 가정을 빠르게 검증할 수 있다. - 구체적인 결과물을 조기에 공유하면 팀의 이해를 높이고, 의사결정을 빠르게 하며, 프로젝트 추진력을 확보할 수 있다. ## 구조화된 프롬프트 작성 - AI 결과물의 품질은 프롬프트의 명확성과 구조에 크게 좌우된다. - 효과적인 프롬프트는 다음 요소를 포함할 수 있다. - **작업(Task):** AI가 수행해야 할 구체적인 작업 - **맥락(Context):** 제품, 사용자, 사용 목적 등 배경 정보 - **요소(Elements):** 포함해야 할 화면·콘텐츠·기능 - **동작(Behavior):** 인터랙션과 상태 변화 - **제약 조건(Constraints):** 플랫폼, 스타일, 기술적 제한, 브랜드 규칙 - 좋은 프롬프트는 일회성 지시가 아니라 반복 가능한 작업 구조로 설계해야 한다. - 이를 통해 AI를 단순한 아이디어 생성기가 아니라 지속적인 디자인 협업 도구로 활용할 수 있다. ## 실용적인 적용 방향 AI 도구를 익힐 때는 단순히 다양한 기능을 시험하기보다, 작업 목적과 맥락·제약 조건을 포함한 프롬프트 템플릿을 먼저 만드는 것이 좋다. 또한 문서 작성 전에 프로토타입을 제작해 가정을 검증하고, AI가 만든 결과물을 디자이너의 판단과 검토를 거쳐 개선하는 방식이 효과적이다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

비샬 카푸르의 AI로 정직한 제품을 만드는 10가지 규칙 | 피그마 블로그

AI 제품 개발은 속도보다 사용자 신뢰를 우선해야 하는 문제이며, 특히 금융처럼 감정과 위험이 얽힌 영역에서는 정직하고 인간적인 경험이 필수다. AI는 사람을 대체하는 기술이 아니라 탐색·프로토타이핑·반복을 가속하는 팀원으로 활용해야 한다. 이를 위해서는 인간의 직관과 비판적 사고, 고객의 실제 감정에 대한 이해를 끝까지 유지해야 한다. ## 1. 기본 원리에서 출발하라 - 복잡한 문제를 근본 요소로 분해하고, 고객의 필요와 제품의 차별화 요소를 직접 파악해야 한다. - AI는 아이디어 탐색과 반복 속도를 높일 수 있지만, 독창적인 관점과 직관을 대신할 수는 없다. - 기존 결정을 당연하게 받아들이지 말고 “왜 세 가지 결제 옵션인가?”, “한 가지나 다섯 가지는 어떤가?”, “사용자가 직접 설계할 수는 없는가?”처럼 근본적인 질문을 던져야 한다. - AI가 여러 대안을 빠르게 제시하더라도 중요한 통찰은 사람 사이의 건설적인 의견 충돌에서 나온다. ## 2. 고객의 깊은 감정에 기반하라 - 실제 고객을 관찰하고 직접 질문하는 UX 리서치와 현장 경험은 대체할 수 없다. - 소셜 미디어, 앱스토어 리뷰, 고객과의 대화를 통해 제품 사용 중 발생하는 불만과 기대를 지속적으로 파악해야 한다. - Affirm은 내부 AI 도구 ‘Pluto’를 활용해 최근 30일 동안 고객이 어떤 점에서 실망했는지 조회한다. - 대시보드와 지표는 문제의 방향을 보여주지만, 금융 서비스의 핵심 감정인 불안, 신뢰, 좌절, 안도까지 설명하지는 못한다. - 사용자가 구매하는 것은 단순한 상품이 아니라, 그 상품이 제공하는 기쁨과 안심이라는 점을 이해해야 한다. ## 3. AI를 또 하나의 팀원으로 대하라 - AI를 만능 도구나 인간을 대체할 존재로 보는 극단적인 시각을 피해야 한다. - 제품 개발은 본질적으로 협업 작업이므로, AI는 고객 인사이트를 프로토타입과 실제 제품으로 빠르게 전환하는 팀원처럼 활용할 수 있다. - 웹·모바일·데스크톱처럼 환경별로 checkout 흐름이 다른 경우, AI 도구를 사용해 다양한 실험과 검토를 수행할 수 있다. - Figma Make를 이용하면 여러 화면과 사용 사례를 한 번에 점검하고, 오래된 인터랙션 패턴이나 일관성이 깨진 부분을 조기에 찾을 수 있다. - 반복적인 검토 작업을 엔지니어에게서 디자이너와 PM에게 분산하면 개발 리소스를 절약하면서 실험과 창의성을 높일 수 있다. ## 4. 엣지 케이스를 집중적으로 실험하라 - 좋은 제품은 대표적인 성공 경로(happy path)만 매끄럽게 만드는 데서 끝나지 않는다. - 다양한 사용자 조건과 예외 상황까지 검토해야 진정성 있고 신뢰할 수 있는 경험을 만들 수 있다. - 제공된 글은 이 원칙의 도입부에서 끝나 있어, 구체적인 엣지 케이스 실험 방법과 나머지 규칙의 내용은 확인할 수 없다. AI를 제품 개발에 도입할 때는 먼저 고객 문제와 감정을 직접 이해하고, AI는 대안 탐색과 반복 작업을 가속하는 역할로 제한하는 것이 바람직하다. 특히 금융처럼 신뢰가 중요한 서비스에서는 자동화의 속도보다 인간의 판단, 설명 가능성, 예외 상황에 대한 대비가 우선되어야 한다.

원문 읽기(새 탭에서 열림)
aws원문

AWS 주간 소식: Amazon (새 탭에서 열림)

이번 주 AWS는 헬스케어 전용 AI 에이전트인 Amazon Connect Health의 정식 출시와 함께 Amazon Bedrock을 활용한 보안 및 개발 편의성 강화에 중점을 두었습니다. 인프라 측면에서는 VPC 암호화 제어의 유료화 전환과 데이터베이스 예약 플랜의 지원 범위 확대 등 운영 효율과 비용 최적화를 위한 실질적인 업데이트가 이루어졌습니다. 전 세계적으로 개최된 JAWS Days 2026과 케냐의 커뮤니티 이벤트를 통해 AI 기반 개발 팀 구축과 클라우드 네이티브 엔지니어링에 대한 뜨거운 관심을 확인할 수 있었습니다. **AI 에이전트 및 헬스케어 특화 서비스** - **Amazon Connect Health 정식 출시**: 환자 인증, 예약 관리, 환자 통찰력 제공, 진료 문서화 및 의료 코딩을 지원하는 5가지 전용 AI 에이전트를 선보였습니다. HIPAA를 준수하며 기존 임상 워크플로에 수일 내로 배포가 가능합니다. - **Amazon Bedrock AgentCore 정책 지원**: 에이전트 코드 외부에서 도구 간 상호작용을 중앙 집중식으로 제어할 수 있습니다. 자연어로 정의된 보안 규칙은 AWS의 오픈소스 정책 언어인 Cedar로 자동 변환되어 적용됩니다. - **Lightsail 기반 OpenClaw 도입**: 사용자의 클라우드 인프라에 프라이빗 자율 AI 에이전트를 원클릭 HTTPS 및 기기 페어링 인증을 통해 안전하게 배포하고 Slack이나 Discord 등에 연결할 수 있습니다. **인프라 보안 및 비용 관리 업데이트** - **VPC 암호화 제어 유료화**: 2026년 3월 1일부터 프리뷰 기간이 종료되어 유료로 전환됩니다. 리전 내외의 모든 트래픽 암호화를 모니터링하거나 강제할 수 있는 기능을 제공합니다. - **데이터베이스 Savings Plans 확대**: Amazon OpenSearch 서비스 및 Neptune Analytics가 지원 대상에 추가되어, 1년 약정 시 최대 35%의 비용을 절감할 수 있게 되었습니다. - **콘솔 내 IAM 역할 생성 간소화**: EC2, Lambda, EKS, Glue 등 주요 서비스의 워크플로 내에서 IAM 콘솔로 이동하지 않고도 즉시 역할을 생성하고 구성할 수 있는 패널이 추가되었습니다. **개발자 경험 및 운영 자동화** - **Elastic Beanstalk AI 분석 기능**: 환경 상태가 악화될 경우 Amazon Bedrock이 로그와 인스턴스 상태를 분석하여 단계별 트러블슈팅 권장 사항을 제공합니다. - **GameLift 서버 DDoS 보호**: 추가 비용 없이 릴레이 네트워크를 통해 클라이언트 트래픽을 인증하고 플레이어당 트래픽 제한을 설정하여 멀티플레이어 게임을 공격으로부터 보호합니다. - **Lambda 지속성 함수 개발 지원**: AI 에이전트 기반 개발 도구인 'Kiro'를 통해 재실행 모델, 에러 처리, 동시 실행 패턴 등 복잡한 워크플로 개발에 필요한 가이드를 동적으로 제공받을 수 있습니다. 이번 업데이트를 통해 AWS는 AI를 단순한 모델 제공을 넘어 의료 현장의 실무나 인프라 장애 조치와 같은 구체적인 운영 영역에 깊숙이 통합하고 있음을 보여줍니다. 특히 보안 정책을 자연어로 관리하거나 인프라 진단에 AI를 활용하는 기능들은 운영 부담을 크게 줄여줄 것으로 기대되므로, 현재 운영 중인 서비스의 효율성을 높이기 위해 이러한 도구들을 적극적으로 검토해 보시길 권장합니다.

meta원문

메신저의 고급 브라우징 보호 작동 원리 (새 탭에서 열림)

메신저의 고급 브라우징 보호(ABP) 기술은 종단간 암호화(E2EE) 환경에서 사용자의 프라이버시를 침해하지 않으면서도 악성 링크로부터 사용자를 안전하게 보호하기 위해 설계되었습니다. 이 시스템은 '프라이빗 정보 검색(PIR)' 기술과 정교한 인프라를 활용하여, 서버가 사용자가 어떤 링크를 클릭했는지 알 수 없게 하면서도 수백만 개의 악성 사이트 목록을 실시간으로 대조합니다. 결과적으로 사용자는 보안 위협으로부터 보호받는 동시에 대화 내용의 기밀성을 완벽하게 유지할 수 있습니다. ### 프라이빗 정보 검색(PIR)과 ABP의 설계 원칙 * PIR은 클라이언트가 서버의 데이터베이스를 조회할 때, 서버가 클라이언트의 쿼리 내용을 전혀 알 수 없도록 설계된 암호화 프로토콜입니다. * 가장 단순한 방법은 서버의 전체 데이터베이스를 클라이언트에 전송하는 것이지만, ABP의 데이터베이스는 크기가 너무 크고 업데이트가 빈번하여 이 방식은 불가능합니다. * 대안으로 OPRF(망각 의사 난수 함수)를 사용하고 데이터베이스를 여러 개의 '버킷(Bucket)'으로 나누어 샤딩(Sharding)하는 방식을 도입했습니다. 이를 통해 선형 탐색의 범위를 획기적으로 줄여 효율성을 높였습니다. ### URL 접두사 매칭의 복잡성과 프라이버시 문제 * 악성 URL은 단순한 문자열 일치가 아니라 접두사(Prefix) 매칭이 필요합니다. 예를 들어 `example.com`이 차단 목록에 있다면 `example.com/a/b/index.html` 같은 하위 경로도 차단되어야 합니다. * URL의 모든 가능한 접두사를 개별적으로 쿼리하는 방식은 서버에 누출되는 정보량을 증가시켜, 이론적으로 서버가 사용자의 원래 URL을 유추할 수 있게 만듭니다. * 도메인을 기준으로 버킷을 구성하면 프라이버시는 향상되지만, 단축 URL 서비스처럼 특정 도메인에 수많은 링크가 집중될 경우 버킷 크기가 비정상적으로 커져 데이터 전송 효율이 급격히 떨어지는 문제가 발생합니다. ### 규칙 세트(Ruleset)를 통한 데이터 균형 최적화 * 서버는 버킷 크기의 불균형을 해결하기 위해 클라이언트와 사전에 공유하는 '규칙 세트(Ruleset)'를 생성합니다. * 규칙 세트는 특정 해시 접두사에 대해 URL 경로 세그먼트를 몇 개 더 추가하여 다시 해싱할지를 지시하는 매핑 테이블입니다. * 클라이언트는 이 규칙에 따라 반복적으로 해싱 작업을 수행하여 최종적인 버킷 식별자를 도출합니다. 이 과정을 통해 서버는 사용자가 어떤 도메인을 조회하는지 알 수 없으면서도 균등하게 분배된 데이터 묶음을 응답할 수 있습니다. * 서버는 가장 큰 버킷을 반복적으로 쪼개는 반복 연산 과정을 통해 이 규칙 세트를 생성하며, 이를 통해 전체 시스템의 응답 속도와 대역폭 사용을 최적화합니다. ABP 기술은 암호학적 프리미티브와 대규모 인프라 공학을 결합하여 보안과 프라이버시라는 상충하는 가치를 동시에 실현한 사례입니다. 사용자 입장에서는 추가적인 조작 없이도 고도화된 보안 설정을 유지할 수 있으며, 서비스 제공자는 사용자 데이터를 열람하지 않고도 안전한 플랫폼 환경을 구축할 수 있습니다.

github4분 읽기큐레이션 요약

내부 살펴보기: GitHub

GitHub Agentic Workflows는 에이전트를 기존 CI/CD에 통합하되, 에이전트의 비결정성과 프롬프트 인젝션 위험을 전제로 설계된 보안 아키텍처를 사용합니다. 핵심은 자유로운 에이전트 작성과 통제된 실행을 분리하고, 워크플로를 명시적인 권한·출력·네트워크·감사 제약이 있는 GitHub Actions로 컴파일하는 것입니다. 특히 에이전트에 비밀을 직접 제공하지 않고, 계층적 격리와 단계적 쓰기 검증으로 피해 범위를 제한합니다. ## 에이전트 자동화가 만드는 새로운 위협 - 에이전트는 저장소 상태와 외부 입력을 해석해 런타임에 자율적으로 결정을 내리므로 기본적으로 신뢰할 수 없습니다. - GitHub Actions는 구성 요소들이 하나의 신뢰 도메인에서 실행되는 비교적 개방적인 환경입니다. - 에이전트가 손상되면 다음과 같은 행동이 가능해질 수 있습니다. - MCP 서버와 상호작용 - 인증 토큰과 환경 변수 접근 - 임의의 인터넷 호스트로 네트워크 요청 - 악성 이슈·웹 페이지를 통한 프롬프트 인젝션 실행 - 원치 않는 커밋, 댓글, 이슈 생성 - 따라서 기본 보안 모드는 에이전트가 읽거나 쓰면 안 되는 상태에 접근하고, 허가되지 않은 통신 채널을 악용한다고 가정합니다. ## 다층 방어 구조 GitHub Agentic Workflows는 **기반 인프라(substrate)**, **구성(configuration)**, **계획(planning)**의 세 계층으로 방어합니다. - **기반 인프라 계층** - GitHub Actions 러너 VM과 신뢰된 컨테이너를 사용합니다. - 컨테이너 격리, 커널 수준 통신 경계, 권한 있는 작업과 시스템 호출 중재를 제공합니다. - 사용자 수준 구성 요소가 손상되어 컨테이너 내부에서 임의 코드를 실행하더라도 격리 경계를 넘는 피해를 제한합니다. - **구성 계층** - 어떤 구성 요소를 실행하고 서로 어떻게 연결할지 선언적으로 정의합니다. - 허용되는 통신 채널과 각 구성 요소의 권한을 결정합니다. - 에이전트 API 키와 GitHub 토큰 같은 외부 자격 증명을 어떤 컨테이너에 주입할지 통제합니다. - 컴파일러, 방화벽 정책, MCP 설정 등이 이 계층에 포함됩니다. - **계획 계층** - 구성 계층이 정한 구성 요소들을 언제, 어떤 순서로 실행할지 결정합니다. - 구성 요소 간 데이터 교환을 명시한 단계적 워크플로를 생성합니다. - 안전한 출력 시스템을 통해 쓰기 작업을 검증하고 제한하는 역할을 담당합니다. ## 에이전트에 비밀을 제공하지 않는 설계 - 일반적인 GitHub Actions 환경에서는 여러 프로세스가 환경 변수와 설정 파일에 저장된 토큰을 볼 수 있습니다. - 프롬프트 인젝션을 받은 에이전트는 셸 도구를 이용해 다음 정보에 접근할 수 있습니다. - 설정 파일 - SSH 키 - Linux `/proc` 상태 - 워크플로 로그 - 탈취한 자격 증명은 외부 웹사이트로 전송하거나 공개 이슈·풀 리퀘스트·댓글에 삽입할 수 있습니다. - 이를 막기 위해 에이전트를 별도 컨테이너에서 실행하고 네트워크 경로를 제한합니다. - 인터넷 접속은 방화벽을 통해 통제 - MCP 호출은 신뢰된 MCP 게이트웨이를 통해서만 허용 - LLM 호출은 API 프록시를 통해 중계 - MCP 게이트웨이는 별도의 신뢰 컨테이너에서 MCP 서버를 실행하며, MCP 인증 정보에 독점적으로 접근합니다. - 에이전트 컨테이너는 LLM 인증 토큰을 직접 보지 않고, 격리된 API 프록시가 인증을 대신 처리하는 구조를 사용합니다. ## 네트워크와 권한의 제한 - 에이전트와 방화벽 사이에 전용 사설 네트워크를 구성해 인터넷 연결을 통제합니다. - 허용 목록 기반 방화벽 정책으로 에이전트가 통신할 수 있는 대상과 채널을 제한합니다. - MCP 서버와 LLM API를 직접 노출하지 않고 각각 게이트웨이와 프록시 뒤에 배치합니다. - 이 구조는 에이전트가 손상되더라도 임의의 외부 호스트로 데이터를 반출하거나 인증 서비스를 직접 악용하는 가능성을 줄입니다. ## 안전한 쓰기와 감사 가능성 - 에이전트가 저장소나 GitHub 객체에 직접 자유롭게 쓰지 못하도록 출력 단계를 별도로 통제합니다. - 계획 계층의 안전한 출력 시스템은 다음을 담당하도록 설계됩니다. - GitHub 쓰기 작업의 허용 여부 결정 - 호출 가능한 기능과 호출 횟수 제한 - 출력에서 비밀 정보 제거 - 부적절하거나 원치 않는 내용 조정 - 에이전트의 실행 결과와 외부 효과를 추적할 수 있도록 모든 작업을 기록하는 원칙을 적용합니다. - 결과적으로 에이전트의 자유로운 추론 능력은 유지하되, 실제 커밋·댓글·이슈 생성 같은 효과는 검증된 단계와 명시적 정책을 거쳐야 합니다. ## 실용적인 결론 에이전트 기반 CI/CD를 도입할 때는 에이전트를 일반 스크립트처럼 신뢰하지 말고, 처음부터 침해 가능성을 전제로 설계해야 합니다. 별도 컨테이너 격리, 비밀의 프록시 위임, 허용 목록 네트워크, 단계적 쓰기 검증, 전체 감사 로그를 함께 적용하는 것이 안전한 기본값입니다.

원문 읽기(새 탭에서 열림)
cloudflare원문

Pingora OSS 배포 (새 탭에서 열림)

Cloudflare는 최근 오픈소스 프레임워크인 Pingora에서 발견된 여러 건의 HTTP/1.x 요청 스머글링(Request Smuggling) 취약점을 해결하기 위해 0.8.0 버전을 출시했습니다. 이번 취약점(CVE-2026-2833, 2835, 2836)은 Pingora를 단독 수신 프록시(Ingress Proxy)로 사용할 경우 보안 제어 우회, 세션 하이재킹, 캐시 오염 등을 유발할 수 있는 위험을 내포하고 있습니다. Cloudflare의 자체 CDN 서비스는 내부 아키텍처 구조상 영향을 받지 않았으나, Pingora 프레임워크를 활용하는 외부 사용자들에게는 즉각적인 업데이트가 권고됩니다. ### 101 응답 전 조기 업그레이드 처리 문제 * Pingora는 `Upgrade` 헤더를 포함한 요청을 받을 때, 백엔드로부터 `101 Switching Protocols` 응답을 확인하기 전에도 후속 바이트를 스트림으로 직접 전달하는 결함이 있었습니다. * 공격자는 업그레이드 요청 바로 뒤에 두 번째 HTTP 요청을 붙여서 보냄으로써, Pingora의 보안 필터나 WAF를 통과하지 않은 채 백엔드 서버에 직접 명령을 전달할 수 있었습니다. * 백엔드가 업그레이드를 거부하고 `200 OK`를 반환하더라도 Pingora는 이미 연결을 패스스루 모드로 전환했기 때문에, 프록시와 백엔드 간의 상태 불일치(Desync)가 발생하여 후속 사용자의 요청 데이터가 오염될 위험이 확인되었습니다. * 패치 이후 Pingora는 백엔드로부터 공식적인 101 응답을 받은 경우에만 데이터 해석 방식을 전환하도록 수정되었습니다. ### HTTP/1.0 및 Transfer-Encoding 해석의 불일치 * Pingora의 기존 로직은 `Transfer-Encoding` 헤더 인식 방식이 단순하여, 여러 인코딩이 나열되거나 표준을 벗어난 요청에서 본문 길이를 잘못 판단하는 경우가 있었습니다. * 특정 공격 시나리오에서 Pingora는 `Content-Length`를 기준으로 요청 본문의 끝을 인식했지만, 백엔드 서버(Node.js 등)는 `Transfer-Encoding: chunked`를 우선시하여 요청을 다르게 해석하는 CL.TE 방식의 스머글링이 가능했습니다. * 특히 HTTP/1.0 요청에서 `Transfer-Encoding`을 사용하는 비표준적인 상황에 대해 Pingora가 지나치게 관대하게 처리했던 점이 보안 약점으로 작용했습니다. * 0.8.0 버전에서는 RFC 표준에 따라 마지막 인코딩이 chunked인 경우를 정확히 식별하도록 강화되었으며, 유효하지 않은 인코딩 조합에 대한 검증 로직이 추가되었습니다. **권고 사항** Pingora를 사용하여 수신 프록시나 로드 밸런서를 구축한 운영자는 이러한 취약점으로부터 시스템을 보호하기 위해 즉시 **Pingora 0.8.0** 버전으로 업그레이드해야 합니다. Cloudflare 내부 시스템은 구조적으로 해당 공격 경로가 차단되어 있어 별도의 조치가 필요하지 않으나, 독립적인 배포 환경에서는 보안 사고의 원인이 될 수 있으므로 주의가 필요합니다.

cloudflare원문

능동적 방어: API를 (새 탭에서 열림)

Cloudflare는 기존 WAF의 수동적 방어를 넘어, API의 복잡한 로직 결함을 사전에 탐지하는 '상태 기반(Stateful) 웹 및 API 취약점 스캐너'를 출시했습니다. 이 서비스는 OWASP API Top 10 중 가장 치명적인 BOLA(객체 수준 권한 위반)를 우선적으로 겨냥하며, 유효한 요청으로 위장한 논리적 공격을 찾아내는 데 집중합니다. Cloudflare의 엣지 네트워크 지능과 기존 API Shield 기능을 결합하여, 트래픽이 부족한 개발 환경에서도 자동화된 보안 테스트가 가능해진 것이 핵심입니다. ### API 보안에서 논리적 결함과 BOLA의 위험성 * 기존 웹 취약점(SQL Injection, XSS 등)은 구문 오류의 형태를 띠어 탐지가 용이하지만, API 취약점은 정상적인 HTTP 요청 형식을 유지하면서 비즈니스 로직을 악용하는 경우가 많습니다. * BOLA(Broken Object Level Authorization)는 공격자가 유효한 본인의 인증 토큰을 사용하되, 요청 파라미터의 ID값만 타인의 것으로 교체하여 권한이 없는 데이터에 접근하는 방식입니다. * 이러한 공격은 인증과 스키마가 모두 적절해 보이기 때문에, 단순히 패턴을 매칭하는 전통적인 WAF나 봇 관리 도구로는 방어하기 매우 어렵습니다. ### 기존 DAST 및 수동적 보안의 한계 * 수동적 보안(Passive Scanning)은 실제 사용자 트래픽에 의존하므로, 트래픽이 없는 개발 단계나 새로운 환경에서는 취약점을 미리 발견할 수 없습니다. * 전통적인 DAST(동적 애플리케이션 보안 테스트) 도구는 구성이 복잡하고, 수동으로 OpenAPI 파일을 업데이트해야 하며, 현대적인 복잡한 로그인 흐름을 처리하는 데 한계가 있습니다. * 대부분의 기존 스캐너는 각 요청을 독립적으로 처리하는 '무상태(Stateless)' 방식이라, 여러 요청을 연결하여 로직을 검증해야 하는 BOLA 탐지에 부적합합니다. ### Cloudflare의 상태 기반(Stateful) 스캐닝 기술 * **상태 기반 테스트**: '소유자(Owner)' 계정으로 자원을 생성한 뒤 '공격자(Attacker)' 계정으로 해당 자원에 접근을 시도하는 등, 요청 간의 상관관계를 추적하는 체인형 테스트를 수행합니다. * **자동화된 스캔 플랜**: 제공된 OpenAPI 스키마를 분석하여 API 호출 그래프를 스스로 구축하고, 이를 기반으로 공격 시나리오를 자동 설계합니다. * **API Shield와의 통합**: 기존의 API Discovery 및 Schema Learning 데이터를 활용하므로, 사용자는 복잡한 설정 없이도 자신의 API 구조에 최적화된 스캔을 즉시 시작할 수 있습니다. * **능동적 검증**: 수동적인 트래픽 관찰에서 얻은 통찰을 바탕으로 실제 공격 요청을 생성하여 전송함으로써, 보안 위협이 실재하는지 능동적으로 입증합니다. BOLA와 같은 로직 결함은 코드 수준의 수정이 필수적이므로, API Shield 고객은 이번 베타 버전을 활용해 운영 환경뿐만 아니라 개발 단계에서부터 취약점을 선제적으로 식별하고 수정하는 '시프트 레프트(Shift-left)' 보안 전략을 구축할 것을 권장합니다.

cloudflare원문

복잡성은 선택입니다. SASE (새 탭에서 열림)

제로 트러스트 및 SASE(Secure Access Service Edge) 아키텍처로의 전환은 더 이상 수년이 걸리는 고통스러운 과정이 아니며, 클라우드플레어는 이를 단 몇 주 만에 완료할 수 있는 '선택의 영역'으로 바꾸고 있습니다. Cloudflare One 플랫폼을 통해 복잡한 수동 설정과 레거시 장비의 한계를 극복함으로써, 기업은 기술 부채와 보안 공백을 최소화하고 신속하게 안전한 AI 환경을 구축할 수 있습니다. ### 획기적인 구축 기간 단축: 18개월에서 6주로 * 기존 레거시 SASE 제품을 대규모 조직에 배포하는 데는 통상 18개월이 소요되지만, Cloudflare One을 활용하면 이를 4~6주로 대폭 단축할 수 있습니다. * 복잡한 '마법' 같은 기술 대신 전기나 수도처럼 설치 후 관리가 거의 필요 없는 '노터치(no-touch)' 방식의 보안 인프라를 제공합니다. * 이를 통해 CIO는 장기간의 기술 부채에서 벗어나 비즈니스 본연의 가치 창출에 집중할 수 있는 환경을 마련하게 됩니다. ### 레거시 마이그레이션 실패 원인 분석 및 해결 * 기존 마이그레이션은 단순 하드웨어 교체로 접근하여 데이터가 여러 검사 클러스터를 거치며 발생하는 '트롬본 효과(지연 현상)'와 복잡한 서비스 체이닝 문제를 야기했습니다. * 클라우드플레어는 보안 정책을 물리적 네트워크에서 분리하여 세 가지 핵심 요소를 통해 전환 속도를 높입니다. * **ID 중심의 온램프:** 네트워크 세그먼트를 재구축하는 대신 기존 ID 공급자(IdP) 그룹을 사용하여 액세스를 정의합니다. * **통합 정책 엔진:** SWG(보안 웹 게이트웨이)와 ZTNA(제로 트러스트 네트워크 액세스)를 단일 통과 방식으로 처리하여 관리자의 동기화 수고를 덜어줍니다. * **클라우드 네이티브 커넥터:** `cloudflared`와 같은 경량 데몬을 사용하여 인바운드 방화벽 포트를 열지 않고도 즉각적인 연결을 구현합니다. ### 유연하고 프로그래밍 가능한 확장형 에지 * 고정된 GUI 환경에서 벗어나 소프트웨어 정의 기반의 구성 가능한 플랫폼을 제공하여 특수한 업무 워크플로우를 수용합니다. * 특정 개발팀이 사용하는 Arch Linux와 같은 비표준 환경에서도 맞춤형 패키징(PKGBUILD 등)을 통해 기기 상태 점검(디스크 암호화, 방화벽 상태 등)을 일관되게 적용할 수 있습니다. * 이러한 유연성은 조직 전체의 보안 태세를 유지하면서도 특정 기술 요구 사항을 충족할 수 있게 합니다. ### 안전한 AI 도입을 위한 통합 보안 체계 * SWG의 역할이 단순 URL 차단에서 LLM(대규모 언어 모델)으로 흐르는 데이터 제어로 진화함에 따라, AI 보안 스위트를 통합적으로 제공합니다. * **Shadow AI 가시성:** 대시보드를 통해 네트워크 내에서 사용되는 미승인 타사 AI 도구를 즉시 발견하고 분류합니다. * **AI 신뢰 점수 및 DLP:** 규정 준수 포스처에 따라 AI 모델별로 등급을 매기고, DLP(데이터 손실 방지) 기능을 통해 민감한 소스 코드나 개인정보가 AI 학습 데이터로 유입되는 것을 차단합니다. * **AI용 방화벽:** 외부로 노출된 LLM 엔드포인트를 자동으로 식별하고 프롬프트 인젝션 등의 공격을 차단하여 자체 구축한 AI 앱을 보호합니다. 급변하는 비즈니스 환경에서 보안 마이그레이션의 속도는 곧 경쟁력입니다. 기업은 복잡한 하드웨어 중심의 레거시 방식에서 벗어나, ID 중심의 통합 클라우드 보안 플랫폼을 도입함으로써 제로 트러스트 전환과 안전한 AI 활용이라는 두 마리 토끼를 동시에 잡아야 합니다.

line원문

엔터프라이즈 LLM 서비스 구축기 2: 에이전트 엔지니어링 (새 탭에서 열림)

엔터프라이즈 LLM 서비스를 구축함에 있어 복잡한 최신 기술을 무작정 도입하기보다, 서비스의 본질에 집중하여 불필요한 기술을 덜어내는 '소거법' 기반의 아키텍처를 설계했습니다. 실전 운영 결과, 파인 튜닝 대신 RAG를, 기계적 청킹 대신 '검색 후 자르기' 전략을, 그리고 복잡한 워크플로 대신 단순한 ReAct 구조를 채택함으로써 96.1%라는 높은 응답률과 시스템 안정성을 동시에 확보할 수 있었습니다. 이는 화려한 기술적 기교보다 제한된 비용과 속도 안에서 최적의 효율을 찾는 것이 실제 서비스 환경에서 더 효과적임을 입증합니다. ### 지식 주입 방식의 선택: 파인 튜닝 제외와 RAG 채택 * 파인 튜닝은 새로운 지식(Fact)을 주입하기보다 답변 스타일(Style)을 조정하는 데 훨씬 효율적이며, 지식 주입 정확도는 상대적으로 낮다는 연구 결과를 바탕으로 RAG를 주력 기술로 선정했습니다. * 제품 문서가 수시로 갱신되는 환경에서 파인 튜닝은 매번 데이터셋을 재구성하고 교차 검수해야 하는 막대한 유지보수 비용이 발생하지만, RAG는 원본 문서 업데이트만으로 즉각적인 대응이 가능합니다. * 실험 결과, 소규모 데이터셋을 통한 파인 튜닝은 모델이 이미 학습한 방대한 기존 지식의 벽을 넘지 못하고, 질문 형식이 조금만 바뀌어도 오답을 내놓는 한계를 보였습니다. ### 문맥 보존을 위한 전략: 청킹 없는 '검색 후 자르기' * 기존 RAG의 기계적 청킹(Pre-split)은 문맥 상실의 문제를 야기하므로, 각 문서의 주제가 명확하고 분량이 적은 서비스 특성을 고려해 문서를 통째로 임베딩하는 역발상을 적용했습니다. * 사용자 질문이 들어오면 관련 문서를 통째로 찾은 뒤, 마크다운 헤더(##) 기준으로 분할하고 경량 LLM 필터를 통해 질문과 관련 있는 섹션만 정밀하게 추출하는 '검색 후 자르기(Post-split)' 프로세스를 구축했습니다. * 이 방식은 질문의 맥락을 이미 알고 있는 상태에서 문서를 자르기 때문에, 정보의 희석 없이 모델에게 가장 필요한 핵심 조각들만 선별하여 전달할 수 있다는 장점이 있습니다. ### 효율적인 행동 구조: 복잡한 워크플로 대신 ReAct 방식 * '계획 후 실행(Plan-and-execute)'이나 '멀티 에이전트' 구조는 시스템 복잡도와 응답 지연(Latency)을 높일 뿐, 실제 답변 품질에서의 체감 성능 향상은 크지 않았습니다. * 특히 멀티 에이전트 구조는 전문가 간의 질문 배분 과정에서 추가적인 LLM 호출 비용이 발생하고, 여러 도메인이 섞인 질문에서 정보가 누락되는 취약점을 보였습니다. * 정제된 컨텍스트와 적절한 도구가 주어진다면 모델 스스로 추론하고 행동하는 ReAct 루틴만으로도 복잡한 논리적 순서를 충분히 구현할 수 있음을 확인하여, 시스템을 단순하게 유지했습니다. 성공적인 AI 에이전트 구축의 핵심은 유행하는 기술을 좇는 '덧셈'이 아니라, 서비스의 본질에 맞는 기술만 남기는 '뺄셈'에 있습니다. 현재 발생하는 답변 실패 원인의 절반 이상이 기술적 결함이 아닌 '참조 문서의 부재'에서 기인한다는 점을 고려할 때, 모델 아키텍처를 복잡하게 만들기보다는 AI가 학습하고 참조할 '교과서(원본 문서)'의 품질을 높이는 것이 성능 향상을 위한 가장 확실하고 실용적인 투자입니다.

discord3분 읽기큐레이션 요약

게임의 소셜 레이어 위

게임의 지속적인 참여를 이끄는 핵심은 콘텐츠뿐 아니라 친구와의 연결이며, Discord는 이를 게임의 ‘소셜 레이어’로 확장하려 한다. Discord 계정과 게임 계정을 연결하면 친구를 찾고 함께 플레이하는 과정이 단순해져 플레이 일수와 세션 시간이 증가한다. GDC 2026에서는 계정 연동, 게임 내 커뮤니케이션, Rich Presence, 성과 공유, 게임 아이템 선물 기능 등이 공개됐다. ## 친구를 게임 안으로 연결하는 계정 연동 - Discord 친구와 게임 내 친구는 대체로 같지만, 두 서비스 사이의 연결이 부족해 함께 플레이하려면 별도의 초대나 코드 공유가 필요했다. - Discord Social SDK는 Discord 계정과 게임 계정을 연결해 친구의 게임 활동을 지속적으로 공유한다. - 친구가 어떤 게임을 플레이 중인지 Discord에서 확인하고, 별도 메시지나 코드 없이 게임에 합류할 수 있다. - 초기 파트너 게임에서 계정 연결 사용자는: - 활성 게임 일수가 중앙값 기준 25% 증가 - 세션 시간이 16% 증가 - 참여 게임에는 *Marvel Rivals*, *Rust*, *Pax Dei*, *Delta Force*, *Arena Breakout*, *Predecessor* 등이 포함된다. ## Social SDK의 주요 개선 사항 - **간편해진 계정 연결** - Discord 내부에서 계정을 연결할 수 있다. - 친구가 연결된 게임을 플레이할 때 상황에 맞는 연결 안내가 표시된다. - 여러 게임을 운영하는 퍼블리셔는 퍼블리셔 인증을 통해 한 번의 연결로 여러 타이틀을 연동할 수 있다. - iOS와 Android에서 모바일 계정 연결이 네이티브 방식으로 지원된다. - **강화된 게임 내 커뮤니케이션** - 지속적인 메시지 기록으로 세션 사이에도 대화 내용을 확인할 수 있다. - 오디오 후처리 효과를 적용할 수 있는 오디오 도구가 제공된다. - 서버 측 API를 이용해 기존에 사용하던 모더레이션 서비스와 연동할 수 있다. - **개선된 Rich Presence** - 사용자 지정 표시 이름과 버튼을 설정할 수 있다. - ‘플레이 중’ 외에도 듣기, 시청, 경쟁 등 다양한 활동 유형을 표시할 수 있다. - 개발자가 Discord에서 게임 활동이 어떻게 보일지 세부적으로 구성할 수 있다. ## 게임 성과를 Discord 프로필에 공유 - Game Stats Widget을 사용하면 게임의 주요 성과를 Discord 프로필에 표시할 수 있다. - *Wuthering Waves*에서는 대표 캐릭터인 Resonator와 최근 업적을 프로필에 추가할 수 있다. - 게임 플레이 시간과 성과를 친구들에게 자연스럽게 노출해 게임의 발견과 재방문을 유도한다. - Discord 프로필은 월간 약 1억 3,300만 명이 조회하므로, 게임 개발자에게 새로운 홍보 접점이 될 수 있다. - 현재 *Wuthering Waves*와 *Marvel Rivals*에서 해당 기능을 체험할 수 있으며, 다른 게임 개발자도 파트너 참여를 신청할 수 있다. ## 대화를 중단하지 않는 게임 아이템 선물 - 많은 게임은 친구에게 스킨이나 아이템을 선물하는 기능이 부족해, 구매와 선물이 게임 밖에서는 어렵다. - Discord Social Commerce는 Discord 안에서 게임 아이템을 구매하고 선물할 수 있는 기능이다. - 공식 게임 서버에 삽입된 Game Shop에서 아이템을 구매할 수 있다. - 아이템은 다음 공간에서도 제공된다. - 개인 메시지 - 음성 채널 - 플레이어 프로필의 Wishlist - 친구와 대화하던 중 채팅을 떠나지 않고 스킨을 구매해 선물할 수 있으며, 수신자는 다음에 게임에 접속했을 때 받을 수 있다. ## 실용적인 시사점 - 게임 개발자는 계정 연동을 통해 초대·매칭·재접속에 필요한 마찰을 줄이는 것이 효과적이다. - 게임 내 활동을 Discord 프로필과 대화에 노출하면 자연스러운 바이럴과 친구 간 유입을 기대할 수 있다. - 성과 공유와 선물 기능은 단순한 편의 기능을 넘어 플레이 동기와 커뮤니티 참여를 강화하는 수단으로 활용될 수 있다.

원문 읽기(새 탭에서 열림)
gitlab원문

파일 트리 브라우저로 저장 (새 탭에서 열림)

GitLab 18.9 버전에서 새롭게 도입된 '파일 트리 브라우저'는 웹 환경에서도 IDE와 유사한 코드 탐색 경험을 제공하여 개발자의 생산성을 높여줍니다. 기존의 번거로운 뒤로 가기 방식이나 브레드크럼(breadcrumb) 의존 방식에서 벗어나, 파일 구조를 유지한 채 직관적으로 코드를 탐색할 수 있는 환경을 구축한 것이 핵심입니다. 이 기능은 GitLab.com뿐만 아니라 자가 관리형(Self-Managed) 및 전용(Dedicated) 인스턴스에서도 모두 사용할 수 있습니다. ### 직관적인 파일 구조 탐색 및 동기화 * **IDE 스타일의 트리 뷰**: 파일 및 디렉토리 구조를 측면 패널에 상시 표시하여, 현재 위치를 잃지 않고 코드의 계층 구조를 한눈에 파악할 수 있습니다. * **실시간 위치 동기화**: 메인 콘텐츠 영역에서 파일을 선택하면 트리 뷰가 해당 파일의 상위 디렉토리를 자동으로 확장하고 위치를 강조해 줍니다. * **유연한 레이아웃**: 트리 패널은 접거나 크기를 조절할 수 있어, 사용자의 화면 작업 공간에 맞춰 최적화가 가능합니다. ### 강력한 검색 및 키보드 중심의 내비게이션 * **빠른 파일 필터링**: 트리 브라우저가 열린 상태에서 'F' 키를 누르면 검색창이 활성화되며, 파일명이나 확장자의 일부를 입력해 원하는 파일로 즉시 이동할 수 있습니다. * **W3C ARIA 표준 준수**: 키보드 사용자와 스크린 리더 사용자를 위해 W3C ARIA treeview 패턴을 구현하였습니다. 화살표 키, Enter, Space, Home, End 키 등을 사용하여 손을 마우스로 옮기지 않고도 모든 탐색이 가능합니다. * **반응형 인터페이스**: 데스크톱에서는 사이드바 형태로 제공되지만, 작은 화면에서는 토글 방식의 드로어(drawer)로 전환되며 모바일에서는 코드 뷰를 최대로 활용할 수 있도록 숨김 처리됩니다. ### 대규모 저장소를 위한 성능 최적화 * **페이지네이션(Pagination) 적용**: 항목이 매우 많은 대형 저장소에서도 성능 저하가 발생하지 않도록 페이지네이션 기술을 도입하여 필요한 만큼 데이터를 로드합니다. * **확장성**: 프로젝트 규모가 커지더라도 트리 뷰의 응답성을 유지하도록 설계되어 대규모 엔터프라이즈 환경에서도 쾌적한 사용이 가능합니다. ### 활용 팁 및 권장 사항 새로운 파일 트리 브라우저를 효율적으로 사용하려면 `Shift + F` 단축키를 기억하는 것이 좋습니다. 저장소 뷰에서 이 키를 눌러 브라우저를 즉시 켜고 끌 수 있으며, 파일 검색 시에는 `F` 키를 활용해 계층 구조를 일일이 클릭하지 않고도 대상 파일에 접근하는 방식을 추천합니다. GitLab은 향후 성능 및 접근성을 더욱 개선할 예정이므로 피드백 이슈를 통해 개선 의견을 전달하는 것도 좋은 방법입니다.

datadog3분 읽기큐레이션 요약

AI 에이전트가 문을 두드렸을 때: 데이터독 오픈 소스 저장소의 악성 기여 탐지

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 ‘Leader’로 선정되었다는 소식과 제품 포트폴리오를 소개하는 내용입니다. 제공된 본문에는 상세한 평가 기준이나 선정 이유, 기술적 분석보다 Datadog의 제품 메뉴와 기능 목록이 대부분 포함되어 있습니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog은 Gartner® Magic Quadrant™ for Observability Platforms 2026에서 리더로 소개되었습니다. - 다만 제공된 내용에는 Gartner의 구체적인 평가 점수, 경쟁사 비교, 선정 근거는 포함되어 있지 않습니다. - 따라서 리더 선정이 제품 완성도, 실행력, 비전 중 어떤 요소에 기반했는지는 확인할 수 없습니다. ### 인프라 및 애플리케이션 모니터링 - 인프라 모니터링, 메트릭, 컨테이너 및 Kubernetes 모니터링을 제공합니다. - 네트워크, 서버리스, 클라우드 비용, 스토리지, GPU 모니터링까지 지원합니다. - 애플리케이션 성능 모니터링(APM), 서비스 모니터링, 코드 프로파일링, 동적 계측 기능도 포함됩니다. - 데이터베이스와 데이터 스트림 모니터링을 통해 애플리케이션 외부의 데이터 처리 상태도 관찰할 수 있습니다. ### 로그 및 데이터 관측성 - 로그 관리와 Observability Pipelines를 통해 로그 수집·처리·전송을 관리합니다. - Sensitive Data Scanner로 로그와 데이터에 포함된 민감정보를 탐지할 수 있습니다. - 데이터 품질 모니터링과 작업(Job) 모니터링을 통해 데이터 파이프라인의 오류와 품질 문제를 추적합니다. - Audit Trail은 플랫폼 내 활동과 변경 사항을 기록하는 기능으로 제시됩니다. ### 보안 통합 - 코드 보안, SAST, IAST, 소프트웨어 구성 분석(SCA), IaC 보안을 제공합니다. - 클라우드 보안 상태 관리(CSPM), 권한 관리(CIEM), 취약점 관리, 컴플라이언스 기능을 포함합니다. - Cloud SIEM, 워크로드 보호, 애플리케이션·API 보호 등 런타임 보안 영역도 지원합니다. - Datadog Security Labs와 오픈소스 프로젝트를 통해 보안 연구 및 생태계 활동도 강조합니다. ### 사용자 경험과 소프트웨어 전달 - Browser·Mobile RUM, 세션 리플레이, 신서틱 모니터링으로 실제 사용자 경험을 분석합니다. - 오류 추적, 제품 분석, 실험 기능을 통해 사용자 행동과 애플리케이션 품질을 함께 관찰할 수 있습니다. - CI Visibility, 테스트 최적화, 지속적 테스트, 코드 커버리지로 개발·배포 과정까지 모니터링합니다. - 기능 플래그와 내부 개발자 포털도 소프트웨어 전달 영역에 포함됩니다. ### 서비스 관리와 AI - 이벤트 관리, 서비스 카탈로그, SLO, 인시던트 대응, 워크플로 자동화 기능을 제공합니다. - Watchdog과 Bits AI Agents, Bits Investigation 등 AI 기반 분석·조사 기능을 내세웁니다. - AI 에이전트 관측성, GPU 모니터링, MCP Server 등 AI 시스템 운영을 위한 기능도 포함됩니다. - 대시보드, 알림, 접근 제어, 거버넌스 콘솔 등 플랫폼 운영 기능도 제공됩니다. 실제 글의 상세 주장이나 기술적 결론을 정확히 요약하려면 기사 본문이 추가로 필요합니다. 현재 제공된 내용만으로는 Datadog이 관측성·보안·개발·AI 운영을 하나의 플랫폼으로 통합하고 있다는 점이 핵심입니다.

원문 읽기(새 탭에서 열림)
datadog원문

AI 에이전트가 문을 두드리자: Datadog 오픈 소스 저장소의 악성 기여를 포착하다 (새 탭에서 열림)

데이터독(Datadog)은 최근 GitHub Actions 및 LLM 기반 워크플로우를 표적으로 삼는 AI 에이전트 'hackerbot-claw'의 악성 기여 시도를 성공적으로 차단했습니다. 이 공격은 AI 기술을 활용해 오픈소스 리포지토리에 취약점을 주입하려는 시도였으나, 데이터독의 AI 기반 탐지 시스템인 'BewAIre'와 선제적인 CI/CD 보안 제어 덕분에 무력화되었습니다. 이번 사례는 공격자들이 LLM을 통해 공격 규모를 확장함에 따라, 방어자 또한 AI를 보안 체계에 적극적으로 도입해야 함을 시사합니다. **오픈소스 CI 파이프라인을 향한 주요 공격 벡터** - **변수 삽입 취약점:** PR 제목과 같이 사용자가 제어할 수 있는 변수를 워크플로우 스크립트 내에 안전하지 않게 삽입하는 경우를 악용합니다. - **I-PPE(간접 포이즌 파이프라인 실행):** 악성 의존성이나 빌드 지침을 PR에 삽입하여 빌드 과정에서 자동으로 실행되게 함으로써 CI 비밀번호(Secrets)를 탈취합니다. - **`pull_request_target` 오용:** 신뢰할 수 없는 PR에서 실행되는 워크플로우에 높은 권한을 부여하는 설정을 악용하여 시스템을 장악합니다. - **LLM 프롬프트 인젝션:** `claude-code-action`이나 `run-gemini-cli`처럼 LLM을 사용하는 GitHub 액션에 악의적인 지시를 주입하여 자동화된 트리징 시스템을 교란합니다. **AI 기반 탐지 시스템 'BewAIre'의 운영** - **실시간 코드 리뷰:** 매주 유입되는 약 10,000건의 내외부 PR을 대상으로 LLM 기반의 자동화된 보안 검사를 수행합니다. - **2단계 분석 파이프라인:** GitHub 이벤트를 통해 코드 차분(diff) 데이터를 추출 및 정규화한 뒤, 2단계 LLM 파이프라인을 거쳐 변경 사항을 '악성' 또는 '정상'으로 분류하고 그 근거를 구조화하여 제시합니다. - **SIEM 통합 및 대응:** 악성으로 판정된 결과는 즉시 Datadog Cloud SIEM으로 전송되어 보안 사고 대응 팀(SIRT)이 즉각적으로 조사하고 사고화할 수 있도록 지원합니다. **선제적인 인프라 강화 및 보안 모범 사례** - **최소 권한의 임시 자격 증명:** OIDC identity federation을 활용한 `dd-octo-sts-action`을 도입하여, 수명이 길고 권한이 과도한 개인 액세스 토큰(PAT) 대신 수명이 짧고 권한이 제한된 인증 정보를 동적으로 생성합니다. - **비밀 정보 관리:** 수천 개의 리포지토리를 전수 조사하여 사용되지 않는 GitHub Actions 비밀 정보를 대규모로 식별하고 제거했습니다. - **CI 보안 정책 강제화:** 브랜치 보호 규칙, 휴먼 및 봇의 커밋 서명 의무화, 필수 PR 승인 절차를 도입하고 `GITHUB_TOKEN` 권한을 기본적으로 최소 수준으로 설정했습니다. - **보안 골든 패스(Golden Paths):** 엔지니어들이 별도의 복잡한 설정 없이도 보안이 확보된 표준 CI 파이프라인을 사용할 수 있도록 가이드를 문서화하고 시스템화했습니다. AI 에이전트를 활용한 공격이 현실화됨에 따라 단순한 규칙 기반의 탐지는 한계에 직면해 있습니다. 조직은 BewAIre와 같은 AI 기반 탐지 모델을 구축함과 동시에, OIDC를 통한 인증 체계 개선 및 GITHUB_TOKEN 권한 최소화와 같은 근본적인 CI/CD 보안 설정을 병행하여 자동화된 공격에 대한 방어 계층을 다각화해야 합니다.

github4분 읽기큐레이션 요약

GitHub Security Lab의 오픈 소스

GitHub Security Lab은 오픈 소스 AI 프레임워크인 **Taskflow Agent**와 웹 보안 감사용 taskflow를 활용해 80건 이상의 취약점을 발견했으며, 그중 상당수는 인증 우회와 민감 정보 노출처럼 영향도가 높은 취약점이었다고 설명합니다. 이 방식은 대형 단일 프롬프트 대신 여러 단계의 작업을 YAML로 정의하고, LLM의 분석 결과를 데이터베이스로 전달해 반복적·구조적인 보안 감사를 수행합니다. 프레임워크와 taskflow는 공개되어 있어 GitHub Copilot 사용자는 자신의 저장소에서도 실행할 수 있습니다. ## 오픈 소스 AI 보안 감사의 성과 - 새로운 taskflow는 웹 애플리케이션 취약점 탐색에 특화되어 있습니다. - 지금까지 80건 이상의 취약점을 보고했으며, 작성 시점에 약 20건이 공개되었습니다. - 발견된 취약점의 상당수는 다음과 같은 고위험 유형입니다. - 인증 또는 권한 우회 - 다른 사용자로 로그인할 수 있는 문제 - 다른 사용자의 비공개 데이터에 접근하는 정보 노출 - 글에서 제시한 사례로는 다음이 언급됩니다. - 전자상거래 애플리케이션의 장바구니에서 개인식별정보(PII) 접근 - 채팅 애플리케이션에서 어떤 비밀번호를 사용해도 로그인 가능한 문제 - 연구자들은 기존에 악용 가능성이 불분명한 후보를 검증하는 데 쓰던 시간을 줄이고, 실제 결과를 수동 검증하고 보고하는 데 더 집중할 수 있게 되었다고 설명합니다. ## 자신의 저장소에서 실행하는 방법 - `GitHubSecurityLab/seclab-taskflows` 저장소에서 Codespace를 시작합니다. - 초기화가 끝난 뒤 다음 명령을 실행합니다. ```bash ./scripts/audit/run_audit.sh myorg/myrepo ``` - 중간 규모 저장소에서는 실행에 한두 시간이 걸릴 수 있습니다. - 완료되면 SQLite 뷰어가 열리고, `audit_results` 테이블에서 `has_vulnerability` 열이 체크된 행을 확인합니다. - 실행에는 GitHub Copilot 라이선스가 필요하며, 프리미엄 모델 요청 할당량을 많이 사용할 수 있습니다. - LLM 결과는 비결정적이므로 같은 코드베이스를 여러 번 검사하는 것이 권장됩니다. - 서로 다른 모델을 사용하면 결과가 달라질 수 있습니다. - 예시로 GPT 5.2와 Claude Opus 4.6을 각각 사용할 수 있습니다. - 비공개 저장소도 지원하지만, Codespace 설정을 수정해 접근 권한을 별도로 부여해야 합니다. ## Taskflow의 구조 - Taskflow는 LLM에 수행시킬 작업 목록을 YAML로 정의한 파일입니다. - `seclab-taskflow-agent`가 다음 기능을 담당합니다. - 작업을 순차적으로 실행 - 앞선 작업의 결과를 다음 작업에 전달 - 여러 구성 요소에 같은 작업을 비동기적으로 반복 실행 - 템플릿 프롬프트에 구성 요소별 정보를 삽입 - 저장소 감사는 일반적으로 다음 단계로 나뉩니다. - 저장소를 기능별 구성 요소로 분할 - 각 구성 요소의 진입점, 신뢰할 수 없는 입력, 요구 권한, 역할 등을 분석 - 분석 결과를 `repo_context.db` 같은 데이터베이스에 저장 - 저장된 컨텍스트를 사용해 취약점 후보를 생성 - 후보별로 세부 검증을 수행 - 현재는 각 구성 요소에 대해 일반적인 보안 문제를 제안하는 작업과, 제안된 문제를 정밀하게 검증하는 작업이 사용됩니다. - 특정 취약점 유형에 집중하는 별도의 taskflow도 추가할 수 있습니다. ## 하나의 거대한 프롬프트 대신 여러 작업을 사용하는 이유 - LLM의 컨텍스트 창에는 한계가 있습니다. - 복잡한 작업을 하나의 프롬프트에 모두 넣으면 일부 단계가 누락되거나 제대로 수행되지 않을 수 있습니다. - 작업을 분리하면 다음과 같은 장점이 있습니다. - 각 단계의 결과를 개별적으로 확인 가능 - 실패하거나 잘못된 단계를 디버깅하기 쉬움 - 이전 분석 결과를 후속 작업의 컨텍스트로 재사용 가능 - 여러 코드 구성 요소에 동일한 분석을 일관되게 적용 가능 - 더 큰 컨텍스트 창을 지원하는 모델에서도, 작업 흐름을 통제하고 검증하기 위해 taskflow 방식이 유용하다고 설명합니다. ## 일반 보안 코드 감사에서의 과제 - 초기에는 CodeQL 경고 분류처럼 범위와 판단 기준이 명확한 작업에 Taskflow Agent를 사용했습니다. - 이후 특정 경고에 한정하지 않고 일반적인 취약점까지 찾는 방식으로 확장했습니다. - LLM에 더 많은 자유를 주면 다음 문제가 커집니다. - 환각 - 오탐 - 검증하기 어려운 취약점 보고 - CodeQL 경고 분류가 효과적이었던 이유는 지시와 판정 기준이 엄격하고, 각 단계에서 결과가 요구사항을 충족하는지 확인할 수 있었기 때문입니다. - 따라서 목표는 LLM이 다양한 취약점을 자유롭게 탐색하게 하면서도 taskflow 설계와 프롬프트 엔지니어링으로 환각과 오탐을 통제하는 것입니다. ## 실용적인 권장 사항 실제 프로젝트에 적용할 때는 한 번의 실행 결과를 확정적인 보안 보고서로 취급하지 말고, 여러 모델과 반복 실행으로 후보를 수집한 뒤 사람이 재현 가능성과 악용 가능성을 검증하는 것이 좋습니다. 또한 저장소 전체를 한 번에 분석하기보다 기능별 구성 요소와 단계별 taskflow로 나누면 결과를 추적하고 수정하기 쉽습니다.

원문 읽기(새 탭에서 열림)