Redthread 문서

Redthread는 AI 네이티브 애플리케이션 보호 플랫폼(ANAPP)이며, 구동 엔진은 Redthread입니다. 에이전트 없는 방식을 우선하여 핵심 가치를 제공하는 데 아무것도 설치하지 않으며, 모든 기능은 워크스페이스별로 켜는 모듈이며, 하나의 콘솔에서 관리합니다.

Redthread는 먼저 지도를 만듭니다 — 에이전트, 코드, 클라우드, 인프라가 어떻게 연결되는지 알기 전까지 발견 사항 목록은 그저 목록일 뿐이기 때문입니다. Redthread는 전체 환경을 하나의 그래프 형태로 조립합니다. 에이전트, 애플리케이션, 코드, 클라우드 계정, 신원, 이미 운영 중인 보안 통제, 그리고 이들이 접근할 수 있는 데이터까지 모두 담기며, 모든 모듈이 같은 그래프를 읽고 쓰므로 가장 먼저 보이는 위험은 목록 속 고립된 발견 사항이 아니라 여러 계층에 걸친 위험입니다.

이 지도 위에서 플랫폼은 워크스페이스별로 활성화하는 모듈로 동작합니다:

• AI 위험 평가 (평가 및 통합) — 무료이자 에이전트 없는 첫 관문: 운영 중인 모든 AI, OWASP Top 10 for LLM 및 Agentic 애플리케이션에 매핑되어 우선순위가 매겨진 유해 조합, 에이전트 없이 연결하면 제공되는 보안 태세 점수, 아무것도 감시하지 않는 AI 표면, Redthread 모듈이 대체할 수 있는 기존 도구의 대체 맵, 그리고 입력값 기반 통합 ROI.
• 익스플로잇 검증 (AI 애플리케이션 테스트) — 평가에서 순위가 매겨진 가장 위험한 경로를 입증합니다: 자율 에이전트가 챗봇, 에이전트, RAG 엔드포인트를 OWASP LLM Top 10(MITRE ATLAS에 매핑) 기준으로 탐색하며, 모든 발견 사항에는 재현 가능한 개념 증명이 포함됩니다.
• 섀도 AI 탐지 — 아무도 등록하지 않은 것까지 포함해, 환경 전반의 모든 AI 기반 기능을 목록화합니다.
• 클라우드 & 인프라 보안 태세 — 클라우드를 에이전트 없이(아무것도 설치하지 않고) 연결하여 자산, 신원, 데이터를 매핑하고, 민감한 저장소를 분류(DSPM)하며, 크로스 클라우드 공격 경로를 드러냅니다.
• 엔드포인트 텔레메트리(탐지 전용) — 선택 사항인 코어 내장 경량 에이전트가 OS가 허용하는 안전한 인터페이스에서 호스트 인벤토리와 보안 태세를 보고합니다. 차단은 절대 하지 않으며, 실시간 방지는 로드맵에 있는 파트너 애드온입니다.
• Agentic Trust & Protection Platform — 모든 에이전트/신원에 SPIFFE ID를 부여하고, 입증된 익스플로잇을 근거로 서명되고 TTL이 적용된 신뢰 상태 이벤트(safe/unsafe/revoked)를 브로드캐스트하여 오케스트레이터, 게이트웨이, SIEM이 몇 초 안에 대응하게 합니다. 참고: Agentic Trust & Protection Platform.
• CI/CD 게이트 — 모든 풀 리퀘스트마다 스캔하고, 입증된 공격 경로를 유발할 병합을 차단합니다.
• 지속형 플랫폼 — 드리프트와 추세를 포함한 예약 재평가로, 커버리지가 이번 주 프로덕션의 실제 상태를 반영합니다.
• 조치 & 보고서 — 명확한 수정 방안과 초안 풀 리퀘스트, 그리고 감사인이 묻는 프레임워크에 매핑된 증명서(Letter of Attestation), 전체 기술 보고서, 기계 판독용 사본.
• 신원 & 접근 — 워크스페이스를 위한 SSO, SCIM 프로비저닝, 역할, 감사 로그.

추론이 아닌 입증. 발견 사항은 엔진이 실제로 도달했거나 익스플로잇한 것이며, 재현할 수 있는 정확한 단계가 함께 제공됩니다. 커버리지는 그래프가 뒷받침하는 범위에서만 주장합니다. 플랫폼은 에이전트 없는 탐지 우선 방식입니다 — 모든 방지/차단 조치는 서명되고 옵트인이며 고객이 소유하는 예외일 뿐 결코 기본값이 아니며, 센서에 배포하는 모든 업데이트는 AI 롤아웃 안전성 게이트(카나리 링, 자동 중단)를 거쳐 단계적으로 배포됩니다.

이 문서에서 다루는 내용: 시작하기, 플랫폼 아키텍처, 핵심 개념 (플랫폼의 작동 원리), 작업 중심 가이드, 그리고 전체 API 레퍼런스 — 이를 통해 CI나 자체 스크립트에서 모든 모듈을 구동할 수 있습니다.

최신 업데이트

2026년 10월 31일

• 화이트라벨 보고서. 유료 플랜에서 소유자는 설정 → 일반 → 보고서 브랜딩에서 회사명, 연락처, 로고를 지정합니다. 이후 컴플라이언스 보고서와 증명서(Letter of Attestation)에 귀사가 발행 주체로 표시되며, Redthread를 숨기는 상자를 선택하지 않는 한 Redthread는 플랫폼으로 명시됩니다.
• 센서 업데이트 단계적 배포 적용. 새 엔드포인트 에이전트 빌드는 검증을 거친 뒤 카나리 링(호스트의 1% → 10% → 50% → 100%)으로 제공되며, 링이 정상적으로 복귀하지 않으면 자동으로 중단됩니다.
• 자산은 한 번만 입력합니다. 침투 테스트 스캔은 이제 환경에 이미 등록된 사이트에서 선택하며, 새 URL은 한 번만 저장됩니다. 등록된 사이트의 수동 스캔은 해당 사이트의 지식과 이력을 사용합니다. 지금 스캔, 일정, 드리프트 재스캔, CI 트리거도 수동 스캔처럼 검증된 도메인이 필요합니다. 인프라 스캔에서는 클라우드를 추가하고 하나만 연결 해제할 수 있습니다.
• 매일 실행하는 MCP 레지스트리 스캔이 이제 53,270개 서버를 다룹니다. 모든 서버에 서명된 주장이 발급되며, 그날의 서명된 매니페스트는 공개 Sigstore Rekor 로그에 고정됩니다. 10월 30일 스캔에서는 등록 항목 바꿔치기(이름이 이제 다른 도메인이나 패키지 소유자를 가리키는 경우) 1,489건, 게시된 적 없는 버전을 명시한 등록 항목 227건, 선언된 것과 다른 리포지토리에서 빌드된 패키지 35건이 확인되었습니다. 자세한 내용은 실시간 수치.
• 도구 정의에 핑거프린트를 남깁니다(규칙 atf-6). 자격 증명 없이 응답하는 원격 서버(현재까지 20,504개)에 대해 스캔은 도구 목록의 sha256 핑거프린트를 기록하고, 버전은 그대로인데 도구가 바뀐 서버를 실패 처리합니다. 이것이 러그풀(rug-pull) 수법입니다. 게이트와 훅은 이를 거부합니다.
• Claude Code와 Cursor용 훅, 그리고 AIBOM(미리 보기). atpp hook claude|cursor 명령은 MCP 도구를 호출할 때마다 실행 전에 서버의 서명된 주장과 대조합니다. atpp check-config --cyclonedx 명령은 구성해 둔 MCP 서버의 CycloneDX 1.6 자재 명세서를 작성합니다.
• Enforce가 콘텐츠를 검사합니다(프리뷰). 게이트웨이가 이제 에이전트 트래픽 안을 살펴 프롬프트 인젝션 지시문, 요청에 담겨 밖으로 나가는 시크릿, 오염된 MCP 도구 목록을 찾아냅니다. 신원을 enforce로 전환하기 전까지는 관찰만 하며, 패턴을 매칭하는 방식이라 말을 바꿔 표현하면 빠져나갈 수 있습니다. 하나의 방어 계층일 뿐 보장은 아닙니다.
• 워크스페이스 서명 키를 앱 밖으로 옮겼습니다. 신뢰 이벤트에 서명하는 키는 이제 별도의 서명자(signer) 서비스에 있으며 Oracle Cloud Vault의 키로 봉인됩니다. 앱은 서명을 요청할 수 있지만 키를 읽거나 복사할 수는 없습니다.
• 신뢰 원장은 수정할 수 없습니다. 에이전트 신뢰 이벤트는 PostgreSQL에 저장되며, 데이터베이스 자체가 원장의 업데이트, 삭제, 잘라내기를 거부합니다. 따라서 이 보장은 애플리케이션이 올바르게 동작하는지에 의존하지 않습니다.
• 컴플라이언스 보고서와 증명서(Attestation letter)를 표준별로 앱 안에서 열 수 있습니다. SOC 2, ISO 27001, ISO 42001, PCI DSS v4.0, GDPR, HIPAA, NIST CSF, NIST AI RMF 또는 EU AI Act 중에서 선택한 다음 다운로드(HTML, PDF, JSON)하거나 이메일 또는 Slack으로 공유하세요. 이 보기는 감사를 뒷받침하는 상호 참조일 뿐 인증이 아닙니다. 참고: 보고서 & 증명서.
• 웹사이트가 로그인 상태를 인식합니다. 메뉴에 로그인 대신 대시보드가 표시되며, 로그인이 필요한 문서 링크는 로그인 후 해당 섹션으로 돌아옵니다.
• 계정과 세션 데이터를 안전하게 기록합니다. 쓰기는 복구용 사본을 두고 원자적으로 이뤄지므로, 충돌이 나도 워크스페이스가 잘리는 일이 없고 읽기에 실패해도 빈 워크스페이스로 바뀌지 않습니다.

2026년 10월 7일

• 이제 모든 Oracle 계정에서 Oracle Cloud를 연결할 수 있습니다. 2023년 이후 생성된 계정은 ID 도메인을 사용하는데, ID 도메인은 이메일 주소가 없다는 이유로 기존 스캔 사용자를 거부했습니다. 이제 원클릭 설정이 스캔 사용자에게 이메일 주소를 부여하며, 사용자·그룹·정책 이름도 Redthread로 지정됩니다.
• 엔드포인트 센서를 명령 하나로 설치합니다. Estate Scan에서 키를 발급한 뒤 macOS, Linux 또는 Windows에서 명령 하나를 붙여 넣으면 됩니다. 이 명령은 다운로드 파일을 검증하고, 백그라운드 서비스를 설치하고, 첫 보고서를 전송하며, 머신이 나타나면 화면에서 이를 확인해 줍니다. 같은 화면에 대응하는 제거 명령도 있습니다.
• 보고하는 모든 머신이 자산 목록에 계속 남습니다. 예전에는 새 보고서가 들어올 때마다 전체 목록을 대체해서 마지막으로 보고한 머신만 표시되었습니다. 이제 각 보고서는 해당 머신만 업데이트하며, 클라우드를 다시 스캔해도 센서는 그래프에 그대로 남습니다.
• 클라우드 VM의 센서는 해당 VM과 하나로 합쳐집니다. AWS, Oracle Cloud, Azure 또는 Google Cloud에서는 센서가 인스턴스 ID를 읽으므로, 클라우드 스캔이 이미 찾은 VM은 두 관점을 모두 담은 하나의 노드로 표시됩니다.
• 기존 클라우드 VM은 고객의 Cloud Shell에서 설치합니다. Oracle Cloud, Azure 또는 Google Cloud용 명령 하나로 실행 중인 모든 VM에 센서를 설치하며, 이때 고객 본인의 로그인을 사용합니다. Redthread는 고객의 VM에 대한 접근 권한을 전혀 받지 않습니다.
• 새 클라우드 VM은 첫 부팅 시 설치됩니다. VM의 startup-script 필드에 넣는 시작 스크립트가 새 VM이 처음 부팅될 때 영구 센서를 설치합니다.
• 펜테스트 스캔이 자산 규모에 맞춰 늘어납니다. 모든 유료 요금제에는 워크로드 10개당 매월 펜테스트 스캔 1회가 포함됩니다(Starter 3회, Growth 15회, Enterprise 15회 이상). 이를 초과하면 스캔 팩을 사용하거나 스캔별로 결제합니다. 참고: 요금제.
• 전체 환경을 하나의 지도로. 이제 Redthread Flow는 모든 클라우드, 기기, 아이덴티티와 클라우드 간 연결을 포함한 그 사이의 연결을 보여주는 환경 지도로 시작합니다. 클라우드 이슈와 공격 경로는 왼쪽 메뉴에 별도 페이지가 있습니다.
• 연결된 모든 클라우드를 스캔합니다. 클라우드를 둘 이상 연결한 경우(예: AWS와 Oracle Cloud) 이제 내 환경 스캔이 각 클라우드를 모두 스캔하며, 클라우드별 발견 사항과 그래프의 해당 부분을 따로 유지하므로 한 클라우드를 스캔해도 다른 클라우드가 대체되지 않습니다.
• Mac이 이름으로 표시됩니다. 이제 Mac은 네트워크 주소가 아니라 컴퓨터 이름으로 표시됩니다.

가이드: 전체 자산 연결하기

목표: 모든 소스를 한 번만 연결해 두면, 단 한 번의 내 자산 스캔 실행으로 웹사이트, 코드, 클라우드, 머신과 그 위에서 실행되는 AI까지 매핑합니다. 여기서 연결하는 모든 항목은 읽기 전용이며 무료입니다. 단계는 어떤 순서로 진행해도 됩니다. 환경 스캔 화면의 각 레인은 연결되면 녹색으로 바뀝니다.

시작하기 전에

1. 다음 주소에서 로그인합니다: app.redthreadsec.com (회사 이메일 사용).
2. 인증 이메일의 링크를 클릭합니다. 인증을 마치기 전까지 스캔은 잠겨 있습니다.
3. 다음을 엽니다: 환경 스캔. 로그인 후 처음 표시되는 페이지입니다.

1. 웹사이트 & 앱

1. 먼저 웹사이트 & 앱 레인에 기본 웹사이트 또는 앱 주소를 붙여 넣고 추가합니다.
2. 공개 사이트마다 반복합니다. 자격 증명은 필요하지 않으며, 공개 페이지만 읽습니다.
3. 나중에 사이트를 대상으로 펜테스트를 실행하려면 먼저 소유권을 증명해야 합니다(어떻게).

2. 코드

1. 먼저 코드 레인에서 다음을 클릭합니다: GitHub로 로그인.
2. 읽기 전용 접근을 승인합니다. 리포지토리에서 AI 프레임워크, 시크릿, 인프라 코드를 검사합니다.

3. 클라우드 & 인프라

각 클라우드는 클릭 한 번으로 연결되며, 읽기 전용 접근 권한은 고객의 콘솔에서 직접 철회할 수 있습니다. 클라우드가 연결되는 즉시 첫 스캔이 자동으로 실행됩니다.

• AWS: 클릭: AWS를 열고 역할 생성하기, IAM 확인란 체크, 클릭: Create stack, 약 1분 기다린 뒤 12자리 AWS 계정 번호를 Redthread에 다시 입력합니다. AWS 담당자가 따로 있나요? 다음을 사용합니다: 담당자에게 보낼 링크 받기를 누르면.
• Azure: 다음 섹션에서: AWS를 사용하지 않나요?, 선택: Microsoft Azure, Microsoft로 로그인하고 Redthread를 승인한 뒤 구독을 선택하고 클릭: Create.
• Google Cloud: 선택: Google Cloud, Google로 로그인하고 승인한 뒤 스캔할 프로젝트를 선택합니다.
• Oracle Cloud: 선택: Oracle Cloud, 클릭: Oracle Cloud 열기 및 접근 권한 생성 후 관리자로 로그인합니다. 체크: I have reviewed and accept the Oracle Terms of Use, 클릭: 다음 단계 두 번, 체크: Run apply 후 클릭: Create. Redthread로 돌아오면 몇 분 안에 연결됩니다.

이후 스캔은 일정에 따라 자동으로 실행되지 않습니다. 변경 사항을 반영하려면 클릭: 내 자산 스캔, 또는 스캔 (클라우드 카드에 있음).

4. 엔드포인트 센서(선택 사항)

센서는 노트북, 서버 또는 클라우드 VM 한 대를 모니터링하며 해당 머신의 소프트웨어, 보안 설정, 실행 중인 AI 도구를 보고합니다. 센서는 아무것도 차단하지 않습니다.

1. 먼저 엔드포인트 센서 설치 레인에서 다음을 클릭합니다: 등록 키 발급.
2. 노트북 또는 서버: macOS 또는 Linux 명령은 Terminal에, Windows 명령은 PowerShell에 복사합니다. 서버에서는 sudo 명령을 sh 앞에 붙여 머신 전체에 설치되도록 합니다. 머신이 보고를 시작하면 화면에 표시됩니다.
3. 이미 운영 중인 클라우드 VM: 다음을 열고 기존 클라우드 VM: 모든 VM에 설치, 사용 중인 클라우드용 명령을 복사해 해당 클라우드의 Cloud Shell에 붙여 넣습니다. Oracle Cloud에서는 Cloud Shell이 다음 위치에 있습니다: Developer tools (오른쪽 상단). Azure와 Google Cloud에서는 콘솔 상단의 Cloud Shell 아이콘을 클릭합니다. 명령은 실행 중인 모든 VM에 센서를 설치한 뒤 요약을 출력합니다. AWS에서는 각 인스턴스에서 설치 명령을 사용합니다.
4. 새 클라우드 VM: 다음을 열고 새 클라우드 VM: 자동 설치 화면에서 스크립트를 복사해, VM을 만들 때 해당 VM의 startup-script 필드에 붙여 넣습니다.
5. 센서를 제거하려면 다음 항목의 명령을 실행합니다: 제거 (해당 머신에서).

5. AI 에이전트 & 서비스

입력할 내용이 없습니다. 위 소스에서 자동으로 발견되어 AI 인벤토리에 표시됩니다.

6. 스캔

1. 클릭: 내 자산 스캔. 연결된 모든 항목을 매핑하며, 펜테스트 스캔 횟수는 차감하지 않습니다.
2. 그래프와 발견 항목 화면을 열어 자산, 그 위에서 실행되는 AI, 자산 간 공격 경로를 확인합니다.
3. 앱 하나에 대해 익스플로잇까지 입증하는 펜테스트가 필요하면 펜테스트 스캔을 시작합니다. Free 요금제에는 평생 1회가 포함되며, 유료 요금제에는 워크로드 10개당 매월 1회가 포함됩니다.

빠른 시작 — 브라우저

결과를 가장 빠르게 확인하는 방법입니다. 설치도, 카드도 필요 없습니다.

1. 계정을 만드세요. 다음 주소로 이동해 이메일로 가입하세요: app.redthreadsec.com/app 업무용 이메일이 가장 좋지만 개인 이메일도 사용할 수 있습니다. 카드는 필요 없습니다.
2. 환경을 연결하세요. 처음 도착하는 화면은 환경 스캔. 원하는 만큼만 연결하면 됩니다. 웹사이트 URL은 자격 증명이 필요 없고, GitHub와 각 클라우드는 클릭 한 번, 엔드포인트 센서는 머신당 명령 하나로 연결됩니다. 그중 읽기 전용 클라우드 연결이 커버리지를 가장 크게 넓혀 줍니다. 단계별 안내: 전체 환경 연결하기. 이 모든 대상에 대한 탐색은 무료이며 무제한입니다. 미터에 아직 보이지 않는 부분이 표시되며, 스캔을 막는 것은 없습니다.
3. 이메일을 인증하세요. 보내 드린 링크를 클릭하세요. 그러면 능동 스캔이 활성화됩니다. (메일이 오지 않았나요? 앱에서 "재전송"을 사용하세요.)
4. 하나의 대상에 모의 침투 테스트를 실행하세요. 익스플로잇을 입증하는 능동 스캔을 하려면 앱의 스테이징 URL (앱이 실행 중인 라이브 주소이며, 프로덕션이 아님)을 붙여 넣으세요. 더 깊은 스캔을 원하면 코드( .zip)를 끌어다 놓을 수도 있습니다. 다음을 누르세요: 스캔 시작.
5. 작동 과정을 지켜보세요. 스캔은 격리된 샌드박스에서 실행되며 보통 몇 분 안에 끝납니다. 각 범주를 실시간으로 탐색하는 모습을 볼 수 있습니다.
6. 발견 사항을 확인하세요. 입증된 각 취약점에는 심각도, 영향, 명확한 조치 방안이 함께 제공됩니다. 유료 요금제에서는 모든 발견 사항에 작동하는 개념 증명과 수정 초안도 포함됩니다.

앱을 선호하시나요? Redthread는 Mac 및 Windows용 앱도 제공합니다. 받는 곳: 다운로드 페이지. 같은 제품을 별도 창에서 사용하는 것이며, 데이터는 서버에 있으므로 앱과 브라우저는 항상 같은 워크스페이스를 보여 줍니다. 로그인하려면 앱에 이메일을 입력하고 이메일로 받은 링크를 여세요 — 브라우저가 Redthread를 열지 묻고 로그인을 앱으로 넘겨줍니다( millenniums:// 링크는 1회용이며 15분 후 만료됩니다). 설치 프로그램은 아직 Apple 또는 Microsoft 인증서로 서명되지 않았으므로, 다운로드한 사본은 한 번 확인하기 전까지 차단됩니다. Mac에서는 다음 페이지에 있는 한 줄 터미널 설치 명령을 사용하면 확인 창이 아예 뜨지 않습니다: 다운로드 페이지 — .dmg를 사용할 경우 다음 경로에서 한 번 확인하세요: 시스템 설정 → 개인정보 보호 및 보안 → 확인 없이 열기. Windows에서는 다음을 클릭하세요: 추가 정보 → 실행.

빠른 시작 — API

터미널이나 CI에서 구동하고 싶으신가요? 앱이 하는 모든 작업은 REST 호출입니다. 액세스 토큰은 가입 시 생성되어 앱에 표시되며, Authorization: Bearer 헤더에 넣습니다.

1. 계정 확인

토큰이 작동하는지 확인하고 요금제와 남은 할당량을 확인하세요.

curl https://app.redthreadsec.com/api/me \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

{ "tenant": "acme-3f9a2c", "plan": "starter", "plan_display": "Starter", "poc": true,
  "scans_used": 1, "scans_limit": 5, "apps_used": 1, "apps_limit": 1, "verified": true }

2. 스캔 시작

스캔 대상을 지정하세요: target. 선택적으로 source (리포지토리 또는 경로)를 추가하면 훨씬 깊은 화이트박스 스캔을 할 수 있으며, 지출 한도로 budget 값을 지정할 수 있습니다.

curl -X POST https://app.redthreadsec.com/api/scan \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"target":"https://staging.yourapp.com/chat","budget":10}'

{ "run_id": "20260731-abc123" }

3. 결과 읽기

실행 상태를 확인하세요: running 값이 false가 될 때까지 폴링한 뒤, 발견 사항을 읽으세요.

curl https://app.redthreadsec.com/api/runs/20260731-abc123 \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

이것이 전체 흐름입니다: me → scan → runs/<id>. 다음을 참고하세요: API 레퍼런스 — 모든 필드를 설명합니다.

작동 방식

Redthread는 에이전트 없이 동작합니다: 대상이나 클라우드를 연결하고, 워크스페이스별로 원하는 모듈을 켜면, 모든 작업이 Redthread 클라우드에서 실행됩니다. 모든 모듈의 바탕에는 하나의 개념이 있습니다 — 그래프.

1. 매핑. Redthread는 연결한 모든 것 — 에이전트 없는 클라우드 역할, 리포지토리, 실행 중인 앱 — 으로부터 환경의 단일 그래프를 만듭니다. 여기에는 에이전트, 애플리케이션, 코드, 클라우드 계정, 신원, 그리고 이들이 접근할 수 있는 데이터가 담깁니다.
2. 평가. 활성화한 모듈이 이 지도 위에서 실행됩니다. 자율 에이전트가 격리된 샌드박스에서 AI 앱을 모의 침투 테스트하고, 섀도 AI 탐지는 모든 모델 표면을 목록화하며, 클라우드 & 인프라 보안 태세와 DSPM은 자산과 민감 데이터를 분류하고, 의존성 CVE 분석은 물려받은 위험을 점검합니다.
3. 입증. 발견 사항은 엔진이 실제로 도달했거나 익스플로잇한 것이며, 재현할 수 있는 정확한 단계가 함께 제공됩니다. 실제 결과만 발견 사항이 되고, 입증되지 않은 단서는 별도로 보관됩니다. 추론은 없습니다.
4. 순위 지정. 발견 사항은 다시 그래프에 반영되므로, 여러 계층에 걸친 위험(예: 자격 증명이 다른 클라우드의 분류된 데이터에 도달하는 인터넷 노출 앱)이 고립된 이슈 목록보다 위에 드러납니다.
5. 조치. 각 발견 사항에는 명확한 조치 방안과, 원하는 경우 초안 풀 리퀘스트가 함께 제공됩니다. CI 게이트는 입증된 공격 경로를 유발할 병합을 차단하며, 조치 단계에서 서명된 웹후크를 보내거나 Jira / ServiceNow 티켓을 열 수 있습니다.

코어 제품을 위해 귀사 시스템에 설치하는 것은 없으며, 모듈은 클라우드에서 워크스페이스별로 켭니다(참고: 아키텍처 다이어그램). 더 깊이 들여다보고 싶다면 선택형 에이전트를 사용할 수 있습니다: 경량 아웃바운드 전용 커넥터 (네트워크 내부 스캔용), Kubernetes eBPF 런타임 센서, 그리고 호스트별 엔드포인트 에이전트 — 모두 탐지 전용이며, 결코 차단하지 않습니다. AI 앱 스캔은 스캔마다 격리된 Docker 샌드박스에서 실행되며, 스캔이 끝나면 샌드박스는 폐기됩니다.

도구: 프런티어 LLM이 구동하고 Redthread 취약점 스킬 팩(OWASP LLM Top 10 2025 + MITRE ATLAS)이 안내하는 자율 AI 에이전트; CVSS 3.1 점수화; 의존성 CVE 분석 도구: osv-scanner; 환경 그래프는 일반 node-link JSON으로 내보낼 수 있습니다. 대표 모듈은 AI 애플리케이션 모의 침투 테스트입니다 — 이 섹션의 나머지 부분에서는 모든 모듈과 그 이면의 API를 설명합니다.

플랫폼 아키텍처

이 섹션은 고객이 앱에서 볼 수 있습니다: 로그인 한 뒤 아무 문서 링크나 여세요.

엔드포인트 센서: 수집하는 데이터와 사용 방식

센서는 노트북, 서버 또는 클라우드 VM 한 대에서 실행됩니다. 센서는 읽고 보고하기만 하며, 어떤 것도 차단하거나 종료하거나 변경하지 않습니다. 시작할 때와 15분마다 보고서를 전송하고, 보고서 사이에는 20초마다 실행 중인 AI 도구를 확인하므로 짧게 실행된 도구도 집계됩니다. 설치하기 전에 머신이 무엇을 전송할지 정확히 확인하려면 다음 명령을 실행합니다. redthread-agent -print: 보고서를 출력만 하고 아무것도 전송하지 않습니다.

보고서에 포함되는 내용

센서가 설치된 모든 머신은 Assess에서 Redthread의 탐지 범위에 포함된 것으로 집계됩니다. Estate Scan의 엔드포인트 센서 설치 화면에는 보고 중인 각 머신과 해당 머신이 보고한 내용 및 보고 시점이 표시됩니다.

절대 전송하지 않는 정보

파일 내용, 키 입력, 스크린샷, 네트워크 트래픽, 환경 변수, 비밀번호나 토큰, 원시 하드웨어 ID, 프로세스 명령줄. 명령줄은 AI 도구를 식별하기 위해서만 머신에서 읽은 뒤 즉시 폐기됩니다.

자동 업데이트. 센서는 스스로 최신 상태를 유지합니다. 6시간마다 새로 게시된 빌드를 확인하고, 설치 프로그램과 똑같이 게시된 SHA-256 체크섬으로 검증한 뒤 교체하고 다시 시작합니다. 체크섬이 맞지 않는 빌드는 절대 설치되지 않습니다. 2026년 10월 7일 이전에 설치한 센서는 설치 명령을 한 번 더 실행해야 하며, 그 후에는 다시 실행할 필요가 없습니다. 머신에서 업데이트를 끄려면 MAI_AUTO_UPDATE=0을 설정하세요.

평가 및 통합

이 섹션은 고객이 앱에서 볼 수 있습니다: 로그인 한 뒤 아무 문서 링크나 여세요.

Agentic Trust & Protection Platform

에이전트 신원 + 지속적 신뢰 신호, SPIFFE 기반.

에이전트 신뢰 및 강제 페이지. 콘솔(거버넌스 → 에이전트 신뢰 및 강제)에서 소유자는 버튼 하나로 Agent Trust를 켜거나 끄고, 이름과 범위(에이전트가 보고하는 도구 또는 작업의 정확한 이름)를 지정해 에이전트를 등록합니다. 각 에이전트 카드에는 배지 상태, 섀도 또는 강제 모드, ID와 범위, 게이트웨이가 마지막으로 트래픽을 판정한 시점, 번인 진행 상황(섀도 판정 100건 중 건수, 섀도 60분 중 분, 검토 대기 중인 차단 예정 판정)이 표시됩니다. 소유자는 이를 그룹 단위로 검토하고(차단해야 함 / 정상이었음) 번인이 끝나면 에이전트를 강제로 전환할 수 있습니다. 게이트웨이와 강제 모드는 미리 보기로 표시됩니다.

명령 하나로 게이트웨이(미리 보기). 에이전트를 등록하면 ID와 키가 채워진 명령 하나가 표시됩니다. 에이전트를 실행하는 머신(macOS 또는 Linux, Python 3.10 이상)에서 실행하면 참조 게이트웨이를 127.0.0.1:8888의 백그라운드 서비스로 설치하고, 에이전트 시작에 쓸 줄(프록시 주소와 그 머신에서 게이트웨이가 생성한 인증서)을 출력합니다. 섀도에서는 모든 요청을 판정하고 기록하되 아무것도 차단하지 않으며, 판정은 에이전트 카드의 활동과 번인에 표시됩니다. 각 카드에는 권한 편집기(호스트, 메서드, 경로)도 있습니다. 제거하려면 --uninstall과 함께 실행하세요.

발견된 모든 에이전트와 신원에 지속적이고 검증 가능한 신원을 부여하는 옵트인 모듈로, 그 신뢰 상태를 — safe / unsafe / degraded / revoked — 실시간으로 브로드캐스트합니다. 따라서 오케스트레이터, 에이전트 게이트웨이, SIEM은 누군가 보고서를 읽기를 기다리지 않고 몇 초 안에 대응할 수 있습니다. 이미 보유한 그래프와 익스플로잇 검증 파이프라인 위에서 동작하며, 기본적으로 꺼져 있고 철저히 부가적입니다 — 활성화하지 않은 워크스페이스에는 아무 변화도 없습니다.

이 모듈은 두 업계 범주의 교차점에 있습니다: 비인간 / 워크로드 신원 (SPIFFE/SPIRE가 서비스 계정과 머신에 대해 해결하는 문제를 AI 에이전트로 확장한 것), 그리고 지속적 접근 평가 (엔터프라이즈 신원 관리에서 실시간 권한 취소에 쓰이는 CAEP/RISC Shared-Signals 패턴). Agentic Trust & Protection Platform은 이 두 영역을 하나의 메시로 묶은 Redthread의 이름입니다 — 모든 에이전트가 검증 가능한 신원을 얻고, 그 신뢰 상태가 필요한 곳 어디로든 실시간으로 스트리밍됩니다.

• 신원 — SPIFFE/SPIRE. 모든 에이전트/신원/AI 노드는 다음 값을 받습니다: spiffe_id. 콘솔에서 Terraform 한 단계로 테넌트별 CNCF SPIRE 엔진을 배포하면(탐지가 이미 읽고 있는 동일한 클러스터를 대상으로 하며, 서명 키는 귀사 클라우드를 절대 벗어나지 않음) 수명이 짧고 자동 교체되는 SVID를 발급하며, 이 SVID는 그래프에 다시 반영됩니다. 배포하기 전까지는 Redthread가 결정론적 SPIFFE ID를 할당하므로 이 계층은 지금 바로 동작합니다. 벤더와 모델에 종속되지 않습니다: 신원은 워크로드에 발급되며, 그 안의 모델에는 절대 발급되지 않습니다.
• 그래프 위의 신뢰 배지. 활성화되면 Redthread Flow 뷰의 모든 노드에 신뢰 배지(녹색 safe / 빨간색 unsafe / 주황색 degraded / 회색 revoked)가 표시되며, 그 출처는 동일한 trust_state 필드입니다.
• 추측이 아닌 입증에 근거한 신뢰 상태. 노드가 unsafe 상태로 바뀌는 근거는 오직 입증된 것 — 즉 실제로 성공한 익스플로잇(추론된 것은 제외)뿐입니다. degraded는 잠재적이지만 확인되지 않은 발견 사항이나 만료된 SVID에 해당하며, revoked는 운영자의 수동 재정의입니다.
• 서명되고 TTL이 적용된 이벤트. 모든 신뢰 상태 변경은 CAEP/RISC 표준을 따르는 Ed25519 서명 만료형 이벤트로 발행되며, 이를 유발한 발견 사항으로 돌아가는 링크가 포함됩니다. 어떤 제3자든 워크스페이스의 공개 키로 이벤트를 오프라인 검증할 수 있습니다 — Redthread로 실시간 호출할 필요가 없습니다.
• 전달. 하나 이상의 웹후크를 등록하세요(선택적 HMAC 공유 비밀 포함). 변경이 있을 때마다 서명된 이벤트가 전파됩니다. 추가 전용 원장 덕분에 이벤트를 놓친 구독자도 따라잡을 수 있습니다.
• 키와 원장. 각 워크스페이스의 서명 키는 별도의 서명자 서비스가 보관하며 Oracle Cloud Vault의 키로 봉인됩니다. 앱은 서명을 요청할 수 있지만 키를 읽거나 내보낼 수는 없습니다. 추가 전용 원장은 PostgreSQL에 있으며, 데이터베이스 자체가 원장의 업데이트, 삭제, 잘라내기를 거부합니다.
• Enforce — 프리뷰. 옵트인 인라인 게이트웨이로, 허용 / 거부 / 거부 후 일시 중지를 라이브 요청마다 구조화된 권한(호스트, 메서드, 경로, 본문 크기)을 기준으로, 요청이 목적지에 도달하기 전에 결정합니다. 사후에 기록만 하는 것이 아닙니다. 모든 새 권한은 섀도 모드에서 시작합니다 — 결정하고 기록하되 모든 요청을 지금처럼 그대로 전달합니다. 그리고 번인 게이트가 충족되기 전까지는 API 자체가 신원을 집행 모드로 전환하기를 거부합니다: 정확히 그 권한 아래에서 실제 트래픽을 충분히 오래 관찰해야 하고, 차단되었을 모든 요청을 운영자가 검토하고 동의해야 합니다. 우회 수단은 없습니다. 10월부터 게이트웨이는 콘텐츠도 검사합니다. 대상은 나가는 요청의 프롬프트 인젝션 지시문과 시크릿, 그리고 응답에 담긴 오염된 MCP 도구 목록( tools/list ). 이는 패턴 매칭이며, 신원을 enforce로 전환하기 전까지는 관찰만 하고, 말을 바꿔 표현하면 회피할 수 있습니다. 참고: API 문서 (전체 라우트 목록 포함).

기본값은 여전히 신원 + 신뢰 상태뿐입니다 — 권한/VC 시스템이 아니며, (v1에서는) 조직 간 페더레이션도 아닙니다. Enforce는 이를 획득한 신원에 한해 요청 경로에 실제 결정 지점을 추가하지만, 어떤 규칙에도 맞지 않는 새로운 공격까지 막는다고 보장하지는 않습니다.

공개 배지: 이미지는 포인터이고, 주장은 서명된 파일입니다

README 배지는 누군가의 서버에서 가져오는 이미지이며, 그 그림은 해당 서버가 정하는 무엇이든 보여 줄 수 있습니다. 그래서 ATPP 주장은 이미지 안에 담지 않습니다. 레벨 1(MCP 게시자) 주장은 당사의 일일 스캔 작업이 Ed25519로 서명한, DSSE 봉투에 담긴 in-toto 문(statement) (이 작업은 Redthread 자체 인프라에서 실행됩니다)이며, 그 subject는 스캔한 바로 그 레지스트리 매니페스트의 sha256입니다. 규칙 atf-5 부터는 주장에 해당 등록 항목이 무엇을 설치하는지도 명시됩니다: npm 무결성 해시, PyPI 파일 sha256 또는 각 이미지 태그 뒤의 컨테이너 다이제스트, 그리고 npm 또는 PyPI가 패키지의 Sigstore 빌드 출처 증명을 보관하는 경우 그 안에 기재된 리포지토리입니다. trust.redthreadsec.com 뒤의 서버들은 공개 키만 보유하므로 검증을 통과하는 주장을 만들어 낼 수 없으며, 서명이 확인되지 않으면 배지를 회색으로 표시합니다.

• 고정 배지(기본값). 게시자는 .atpp/badge.svg 및 .atpp/attestation.dsse.json 파일을 커밋합니다(둘 다 다음 경로에서 다운로드: /v/mcp/<namespace>/<server>). 게시자의 README는 Redthread에서 아무것도 가져오지 않으며, 배지에는 버전과 날짜가 표시되고, 그 sha256은 서명된 주장 안에 들어 있습니다.
• 실시간 배지(선택 사항). /badge/mcp/<namespace>/<server>.svg — 재스캔할 때마다 갱신되며, GitHub에서는 약 10분 지연됩니다(이미지 캐시). 단순한 도형과 텍스트만 사용하며 링크나 애니메이션은 없습니다.
• 직접 확인하세요. python3 atpp.py verify <namespace>/<server> (또는 리포지토리 경로) — 출처: github.com/bl014h/atpp: 고정 키 대비 서명, 실시간 레지스트리 해시, 커밋된 배지, 만료일을 검사합니다. 키: /.well-known/atpp-keys.json. 모든 봉투에 대한 일일 서명 매니페스트 위치: /v/log/latest.json, 그 해시는 해당 공개 리포지토리에 커밋됩니다.
• 이미 설치한 것을 확인하세요. python3 atpp.py check-config 명령은 내 컴퓨터에 있는 Claude Desktop, Claude Code, Cursor, VS Code 또는 Windsurf의 MCP 설정을 읽고, 각 패키지나 URL 뒤에 있는 레지스트리 등록 항목을 찾아 서명된 점수, 고정할 정확한 버전 또는 다이제스트, 빌드 주체를 출력합니다. !! 표시는 이름만 보고 신뢰해서는 안 되는 서버를 나타냅니다(등록 항목 바꿔치기, 버전 누락, 다른 리포지토리에서 빌드됨). 설정 파일은 절대 업로드되지 않습니다.
• 도구 정의에 핑거프린트를 남깁니다. 규칙 atf-6 부터 스캔은 MCP 핸드셰이크와 tools/list (도구는 호출하지 않습니다)를 자격 증명 없이 응답하는 각 원격 서버에 보내고, 도구 정의의 핑거프린트를 주장에 서명해 넣습니다. tools-stable 는 버전은 그대로인데 정의가 바뀌면 실패합니다. 러그풀 수법이 바로 이것입니다(OWASP MCP03).
• 훅과 자재 명세서(미리 보기). atpp hook claude (Claude Code의 PreToolUse 훅)과 atpp hook cursor 명령은 MCP 도구를 호출할 때마다 서명된 주장과 대조해, 등록 항목 바꿔치기, 버전 누락, 다른 리포지토리의 빌드 출처, 도구의 조용한 변경을 거부합니다. atpp check-config --cyclonedx bom.json 명령은 구성한 서버의 CycloneDX 1.6 AIBOM을 작성합니다.
• 실행 전 게이트(미리 보기). python3 atpp.py gate <namespace>/<server> 명령은 허용이면 0, 거부면 1로 종료하며, 실행할 수 없는 검사는 거부로 처리됩니다. 실행 전에, CI에서( atpp GitHub Action을 mode: check-config 로 설정하면 검토가 필요한 서버를 추가하는 풀 리퀘스트가 실패합니다), 또는 ToolHive 앞단에서(atf_receipts.py serve --gate) 사용하세요. 이 명령은 게시된 등록 항목과 아티팩트 다이제스트를 정적 스캔과 대조할 뿐, 서버가 실행된 뒤의 동작을 감시하지는 않습니다.
• 내 정책을 내 런타임이 적용합니다. 조직의 허용 목록과 고정된 이미지 다이제스트는 사용자가 소유한 파일에 있습니다: atpp gate --policy org.json 명령은 그 밖의 모든 것을 거부하고, atpp profile --policy org.json 명령은 항목을 thv run --isolate-network용 ToolHive 권한 프로필(허용된 아웃바운드 호스트와 파일 마운트)로 변환합니다. 서명된 주장은 절대 권한을 부여하지 않습니다.
• 키리스 공동 서명. 일일 매니페스트는 공개 atpp 리포지토리의 읽기 전용 워크플로가 Sigstore 키리스 서명으로도 서명합니다(GitHub의 ID, 단기 인증서, Rekor 항목). 검증하려면 sigstore verify identity를 사용하세요. 번들은 해당 리포지토리의 log/ 폴더에 있습니다.
• 롤백 방지. 일일 매니페스트는 공개 Sigstore Rekor 투명성 로그에도 고정되며, 검증 도구는 주장이 최신 매니페스트에 있는지 확인합니다 — 따라서 서버가 침해되더라도 점수가 더 좋았던 예전 주장을 재사용할 수 없고, 리포지토리가 다른 서버의 .atpp/ 파일을 빌려 쓸 수도 없습니다(주장은 그것이 위치한 리포지토리에 속해야 합니다).
• 외부에서 감시됩니다. 매시간 실행되는 카나리와 매일 실행되는 레드팀이 GitHub에서 프로덕션을 대상으로 실행되며, 결과는 공개됩니다.
• 전체 설계(개발자와 보안 책임자용): trust.redthreadsec.com/technical.
• 문제 신고: [email protected] · 취약점 공개 정책.

타 플랫폼과의 비교

아키텍처 관점에서 Redthread가 팀들이 이미 아는 플랫폼들과 비교해 어디에 위치하는지 정리했습니다. 에이전트 축에서 Redthread는 Wiz처럼 에이전트 없는 방식을 우선합니다. 다른 점은 Redthread가 위험을 직접 익스플로잇해 입증하는 방식이라는 점, 그리고 Redthread 그래프가 클라우드 인프라뿐 아니라 AI 에이전트와 애플리케이션을 일급 노드로 다룬다는 점입니다. 이는 아키텍처 비교입니다 — Wiz, Palo Alto, CrowdStrike는 대규모 멀티 제품 제품군이므로, 여기서의 핵심은 기능 동등성이 아니라 형태입니다.

Wiz와 가장 가깝습니다. 기본적으로 에이전트 없이 동작하며, 원시 발견 사항을 순위가 매겨진 공격 경로와 유해 조합으로 바꾸는 보안 그래프가 핵심에 있습니다. 차이점: Wiz는 클라우드 상태로부터 위험을 추론하는 반면, Redthread는 위험을 직접 입증하는 방식입니다 — 자율 모의 침투 테스트가 익스플로잇을 실행하고 재현 가능한 PoC를 첨부합니다. 또한 Redthread 그래프는 클라우드 리소스뿐 아니라 LLM 앱과 에이전트를 일급 노드(OWASP LLM Top 10, MITRE ATLAS)로 다룹니다. 즉 형태로 보면 Redthread는 "공격형 AI 애플리케이션 모의 침투 테스터를 얹은, 에이전트 없는 CNAPP 그래프"입니다.

Palo Alto와의 차이. Prisma Cloud + Cortex는 플랫폼화 전략입니다 — 다수의 제품과 에이전트(에이전트 없는 방식 + Defender + 엔드포인트, 네트워크, 클라우드, 신원 전반의 AI SOC)로 구성됩니다. Redthread는 워크스페이스별로 모듈을 켜는 하나의 에이전트 없는 플랫폼입니다. Palo Alto는 런타임에서 방지하고 대응하지만, Redthread는 설계상 테스트 및 평가 도구로 남습니다 — 선택형 런타임 센서도 탐지만 합니다.

CrowdStrike와의 차이. Falcon의 전제는 모든 엔드포인트에 에이전트 하나를 두고 런타임 EDR을 수행하는 것입니다. Redthread는 코어 제품을 위해 아무것도 설치하지 않으며 런타임 방지를 하지 않습니다. 겹치는 부분은 "클라우드에서 활성화하는 모듈"과 상관관계 그래프 운영뿐입니다 — 단, Falcon은 엔드포인트 이벤트를 그래프로 만들고, Redthread는 귀사의 환경과 그 입증된 공격 경로를 그래프로 만듭니다.

스캔 대상 정하기

가장 흔한 질문에 먼저 답합니다: 귀사가 제공하는 것은 target(대상)이며, 선택적으로 소스도 제공할 수 있습니다. 둘은 같은 것이 아닙니다.

스테이징 vs 프로덕션 — 항상 스테이징을 대상으로

• 프로덕션은 고객이 실제 데이터와 함께 사용하는 실제 앱입니다.
• 스테이징은 테스트 환경에서 실행되는 별도의 사본입니다 — 같은 앱이지만 실제 고객이나 데이터는 없습니다.

스캐너는 실제 공격자처럼 동작합니다: 입력을 제출하고, 레코드를 생성하고, 앱이 노출하는 동작을 트리거하며, 앱의 모델 비용을 끌어올릴 수 있습니다. 스테이징에서는 무해합니다. 프로덕션에서는 쓰레기 데이터가 쌓이거나 실제 사용자에게 실제 부작용이 생길 수 있습니다. 이를 이해하고 감수할 수 있을 때만 프로덕션을 스캔하세요(테스트 계정과 한산한 시간대가 도움이 됩니다).

내 URL은 어떻게 알 수 있나요? 스테이징 URL의 예…

앱이 실행되는 웹 주소일 뿐입니다. 흔한 형태:

• staging.yourapp.com 또는 app-staging.yourapp.com
• 미리보기 URL(Vercel 또는 Netlify — 변경마다 하나씩 생성)
• *-staging.onrender.com 또는 *.herokuapp.com 앱
• 터널(ngrok, cloudflared)로 인터넷에 노출한 로컬 주소(localhost:3000)

가장 쉬운 방법: 앱이 찾아 주게 하기

앱에서, 이미 알고 있는 링크 하나(메인 웹사이트나 앱 주소)를 다음 위치에 붙여 넣으세요: "무엇을 스캔해야 할지 모르시나요?" 그런 다음 누르세요: 스캔 대상 찾기. Redthread가 페이지를 살펴 AI 기능과 API 엔드포인트를 찾고, 다른 환경에 대한 공개 기록도 확인합니다(예: staging. 및 app.). 추천 대상의 짧은 목록이 표시되며, 하나를 클릭하면 바로 스캔합니다. 호스팅 로그인도, 일일이 찾을 필요도 없습니다.

직접 찾기 — 개발자 없이도 가능

직접 하거나 다시 확인하고 싶으신가요? 기술 담당자가 없어도 됩니다. 확실한 방법 두 가지:

1. 자사 앱을 열고 링크를 복사하세요. 고객처럼 제품을 사용하세요 — AI 기능이 있는 페이지(채팅, 어시스턴트)로 이동해 브라우저 주소창에서 주소를 그대로 복사하세요. 그 주소 값이 곧 대상입니다.
2. 결제 내역에서 호스팅 계정을 찾으세요. 앱은 어딘가에서 실행되고 있으며, 호스팅 요금을 결제하는 카드의 소유자는 모든 URL을 볼 수 있습니다. 결제 명세서에서 다음 항목을 확인하세요: Vercel, Netlify, Render, Heroku, AWS, DigitalOcean, Google Cloud. 해당 계정에 로그인하면 대시보드에 앱 주소가 나열됩니다 — 프로덕션과 모든 스테이징/미리보기 주소.

다른 방법: 도메인 등록 기관 / DNS (GoDaddy, Namecheap, Cloudflare 등 도메인을 구입한 곳)에서 다음과 같은 하위 도메인을 확인할 수 있습니다: staging., app., api.; 또는 계정 내부에서 호스팅 업체 고객 지원팀에 문의하세요.

스테이징 URL이 없어요 — 어떻게 만드나요?

• 대부분의 호스팅 업체는 계정에서 클릭 한 번으로 스테이징 사본을 만들어 줍니다 — Vercel, Netlify, Render 모두 코드 없이 무료 미리보기/스테이징 환경을 제공합니다.
• 앱이 GitHub에 있다면, 풀 리퀘스트마다 미리보기 URL이 자동으로 생성되는 경우가 많습니다.
• 프로덕션만 있나요? 그래도 스캔할 수 있습니다 — 실제 공격처럼 다루세요(한산한 시간대, 테스트 계정, 약간의 쓰레기 데이터 예상). 참고: 위의 스테이징 vs 프로덕션 섹션.
• 기술 담당자가 전혀 없나요? 프리랜서라면 반나절이면 스테이징을 구성할 수 있습니다 — 그런 다음 그 URL을 여기에 붙여 넣으세요.

URL이 준비되면 다음을 따르세요: 첫 스캔 실행하기. 더 깊은 화이트박스 스캔을 하려면 코드(업로드 또는 리포지토리)를 추가하세요.

블랙박스 vs 화이트박스

스캐너에 얼마나 많이 제공하느냐가 찾아내는 양을 결정합니다.

• 블랙박스 — 라이브 URL이나 API만 제공합니다. 스캐너는 익명의 공격자처럼 외부에서 공격합니다. 빠르고 설정이 필요 없지만, 정문에서 도달할 수 있는 것만 찾을 수 있습니다.
• 화이트박스 — 라이브 대상에 더해 다음도 제공합니다: 애플리케이션 소스. 스캐너가 공격하면서 코드를 읽으므로 엔드포인트 이면의 도구, 프롬프트, 데이터 경로를 이해합니다. 발견 사항의 수와 깊이가 모두 크게 향상됩니다.

소스를 전달하는 두 가지 방법 — git을 몰라도 됩니다:

• 업로드: .zip (프로젝트 압축 파일). 앱에서는 스캔 상자에 끌어다 놓고, API에서는 업로드한 뒤 반환된 다음 값을 전달하세요: upload_id. 코드는 해당 스캔 동안에만 보관되며 스캔이 끝나면 삭제됩니다 — 학습에는 절대 사용하지 않습니다.
• git 리포지토리 지정 — GitHub, GitLab, Bitbucket, 또는 Azure DevOps. 리포지토리 URL을 source 필드에 붙여 넣거나, 앱에서 GitHub 연결을 한 번 누른 뒤 드롭다운에서 리포지토리(비공개 포함)를 선택하세요. 다른 호스트는 URL을 붙여 넣으면 되며, 그곳의 비공개 리포지토리는 다음 방식을 사용합니다: .zip 업로드.

통합 스캔 — 두 가지 패스를 클릭 한 번으로

스캔 양식에서 통합 스캔 체크박스를 켜면 하나의 대상에 대해 두 가지 패스가 모두 자동으로 실행됩니다: 블랙박스 패스가 라이브 엔드포인트를 탐색한 다음, 화이트박스 패스가 소스를 읽고 알려진 표면을 다시 테스트합니다. 하나로 병합된 발견 사항 목록을 받으며, 각 카드에는 이를 찾아낸 패스가 태그로 표시됩니다. 소스(리포지토리 또는 .zip)가 필요하며, 단일 스캔 예산의 약 두 배를 사용합니다.

화이트박스 패스는 블랙박스 발견 사항을 이어받아 각각을 다시 테스트합니다: 여전히 익스플로잇 가능한 이슈는 ↻ 재확인됨 회귀로 표시되고(두 번이 아니라 한 번만 집계), 소스로만 드러나는 항목은 새로 추가됩니다. 심지어 Free 요금제에서도 통합 스캔을 실행할 수 있으며, 상한은 총 $20 (패스당 $10)입니다.

테스트 항목

OWASP LLM Top 10의 모든 범주를 MITRE ATLAS에 매핑하여 테스트합니다:

• 프롬프트 인젝션
• 민감 정보 노출
• 공급망
• 데이터 & 모델 오염
• 부적절한 출력 처리
• 과도한 에이전시(도구 & 에이전트 남용)
• 시스템 프롬프트 유출
• 벡터 & 임베딩 취약점(RAG)
• 잘못된 정보
• 무제한 소비(비용 폭주)

MITRE ATLAS 매핑을 포함한 전체 매트릭스는 다음에 공개되어 있습니다: 트러스트 센터.

도구: 범주별 취약점 스킬 팩으로, 다음 기준에 맞춰져 있습니다: OWASP LLM Top 10 2025 및 MITRE ATLAS v5.6.0 (기법 ID는 기억이 아니라 원본과 대조해 검증). 공급망 항목은 별도의 섹션이 있습니다.

발견 사항 & 개념 증명

발견 사항은 추측이 아니라 스캐너가 입증한 취약점입니다. 각 발견 사항에는 다음이 포함됩니다:

발견 사항 읽기 — 레이블 설명

모든 발견 사항에는 표준 보안 레이블이 붙어 있어 위험을 판단하고 무엇부터 수정할지 결정할 수 있습니다. 각 레이블의 의미, 읽는 법, 중요한 이유는 다음과 같습니다.

OWASP LLM Top 10 — 각 위험의 의미

지출 한도 & 안전장치

자율 에이전트는 비용이 드는 언어 모델을 호출합니다. 두 가지 독립적인 한도가 스캔으로 인한 예기치 않은 비용을 막아 줍니다:

• 스캔별 예산 한도. 모든 스캔은 budget 값(미국 달러, 기본값 10)을 받습니다. 엔진은 그 상한에 도달하면 멈춥니다.
• 토큰 감시 장치. 별도의 안전장치가 하드 토큰 한도를 넘는 스캔을 강제 종료합니다. 가격 계층이 볼 수 없는 자체 호스팅 모델이라도 마찬가지입니다. 따라서 폭주하는 루프가 계정을 고갈시킬 수 없습니다.

또한 모든 스캔은 자체 격리 샌드박스에서 실행되며, 동시 실행 수는 요금제별로 제한되므로 실수로 스캔 백 개를 한꺼번에 시작할 수 없습니다.

권한 & 도메인 검증

스캔은 실제 공격이므로, 소유하거나 테스트 권한이 있는 앱만 스캔할 수 있습니다. 이것이 약속에 그치지 않도록, 새 공개 도메인을 처음 스캔할 때 Redthread는 소유권 증명을 요청합니다 — 도메인당 한 번입니다. 이를 통해 누구도 경쟁사를 겨냥해 Redthread를 사용할 수 없습니다.

다음 방법 중 하나로 검증하세요(접근할 수 있는 쪽을 선택 — 하나면 충분합니다):

• 메타 태그(가장 쉬움). 홈페이지의 <head>에 한 줄을 추가하세요. 대부분의 사이트 빌더(Wix, Squarespace, Webflow, Shopify)에는 바로 이 용도의 "헤더 코드" 또는 "사이트 인증" 입력란이 있습니다:

  <meta name="millenniums-verification" content="YOUR-TOKEN">

• DNS TXT 레코드. 도메인 등록 기관에서 TXT 레코드를 추가하세요:

  millenniums-verification=YOUR-TOKEN

검증은 루트 도메인 단위로 이루어지며 모든 하위 도메인을 포함합니다 — 예를 들어 acme.com 도메인을 한 번 검증하면 staging.acme.com, api.acme.com, 그 밖의 하위 도메인을 모두 스캔할 수 있습니다. 또한 첫 스캔이 실행되기 전에 짧은 권한 확인서 (앱을 소유하거나 테스트 권한이 있음을 확인)를 작성합니다.

앱에서 안내가 나오면 검증하거나, API의 다음 엔드포인트를 사용하세요: POST /api/domains/verify. 탐지(공개 페이지 읽기)에는 검증이 필요 없으며, 검증이 필요한 것은 오직 스캔 작업뿐입니다.

귀사의 데이터

귀사의 코드와 스캔 결과는 귀사의 것입니다. 각 스캔은 스캔이 끝나면 폐기되는 일회용 샌드박스에서 실행되므로, Redthread는 코드를 가능한 한 적게, 스캔에 필요한 기간 동안만 보관합니다. Redthread는 귀사의 코드나 결과를 어떤 모델 학습에도 사용하지 않습니다. 하위 처리자를 포함한 자세한 내용은 다음을 참고하세요: 트러스트 센터 및 개인정보 처리방침.

추적성 보고서

모든 스캔은 다음을 생성합니다: 증거 관리 연속성 보고서 — 이를 통해 데이터에 정확히 무슨 일이 있었는지 자신, 고객, 감사인에게 입증할 수 있습니다. 마케팅 문구가 아닙니다: 각 항목은 스캔 수명 주기에 기록된 이벤트에서 도출됩니다.

보고서에 포함되는 내용:

• 타임스탬프가 찍힌 타임라인: 스캔 생성 → 소스 수신 → 격리 샌드박스 시작 → 스캔 완료 → 샌드박스 폐기 → (업로드의 경우) 업로드된 소스 삭제.
• 소스 출처: 스캔이 블랙박스(라이브 대상만)였는지, 아니면 업로드나 git 리포지토리 기반 화이트박스였는지. Git URL은 호스트만 기록되며 경로나 자격 증명은 기록되지 않습니다.
• 증명 항목: 격리 샌드박스, 샌드박스 폐기(컨테이너 런타임과 대조해 검증), 업로드된 소스 삭제, 지출 한도 적용, 모델 학습에 사용하지 않음.
• 사용량: 해당 실행의 토큰 및 LLM 호출 수.

앱에서 아무 실행이나 열고 다음 항목에서 확인하세요: 데이터 추적 — 증거 관리 연속성 (원클릭 JSON 다운로드 제공), 또는 API의 다음 엔드포인트: GET /api/runs/{run_id}/trace.

지속 스캔 & 드리프트

기능: 특정 시점의 스캔을 지속적인 커버리지로 바꿉니다. 앱을 자산으로 등록하고, 일정을 지정하면 Redthread가 대신 재스캔하고, 앱이 바뀔 때마다 다시 확인합니다.

방식: 자산별로 설정하는 두 가지 제어 항목이며, 설정 위치는 지속 뷰입니다(또는 API):

• 일정 — 매일, 매주, 매월 주기. 재스캔은 수동 스캔과 같은 경로로 실행되므로 할당량, 동시 실행 수, 지출 한도가 모두 그대로 적용됩니다.
• 드리프트 탐지 — 변경 감시를 켜면 예약 실행 사이에 앱의 지문을 다시 수집합니다(가능하면 OpenAPI/Swagger 명세 기준). 실질적인 변경이 있으면 주기 외 스캔이 시작됩니다. 지문은 CSRF 토큰, nonce, 타임스탬프, 캐시 버스터를 무시하므로 동적 페이지 때문에 잘못 트리거되지 않습니다.

이유: 앱은 릴리스마다 바뀌며, 연 1회 모의 침투 테스트로는 화요일 배포가 만든 구멍을 볼 수 없습니다. 지속 스캔은 회귀가 생기는 즉시 잡아내고, 드리프트 탐지 덕분에 실제로 무언가 바뀌었을 때만 스캔을 소비합니다 — 달력 알림 대신 손이 가지 않는 모니터링입니다.

도구: 자산별 스케줄러가 구동하는 동일한 스캔 엔진; OpenAPI/Swagger 명세(또는 정규화된 표면 크롤링) 기반 앱 지문 수집, 동적 토큰 노이즈를 걸러 내고 실행 간 비교.

대시보드 & 추세

홈 대시보드는 활동 로그가 아니라 위험 현황입니다. 네 개의 타일로 된 위험 밴드로 시작합니다 — 입증된 공격 경로 (몇 개의 위험 중, 몇 개의 미해결 발견 사항에서 나왔는지), 심각도별 미해결 발견 사항 (이전 스캔 대비 신규 / 해결 증감 포함), 커버리지 (등록된 자산, 클라우드 연결, 엔드포인트 호스트, 마지막 스캔 경과 시간), 그리고 Agentic Trust & Protection Platform 상태(safe / unsafe / degraded 에이전트, 또는 꺼짐). 그 아래에는 Redthread의 상위 3개 공격 경로가 홉 체인으로 그려집니다 — Internet → web-01 → data-ingest-role → customer-records — 각 경로에는 입증됨 · PoC 또는 잠재, 둘 중 하나가 표시되며 심각도순, 입증 우선으로 정렬됩니다. 최근 스캔은 그 아래에 표시됩니다.

각 타일과 패널에는 무엇을 세는지 한 줄 설명이 있습니다. 커버리지 타일은 4개 클라우드(AWS, Azure, Google Cloud, Oracle Cloud) 중 연결된 수를 세고 이름을 표시합니다.

모든 타일은 저장된 쿼리입니다: 클릭하면 그 숫자를 만든 뷰가 이미 필터링된 상태로 열립니다 — 심각도 막대는 해당 심각도의 발견 사항을, 경로는 그 경로가 나온 순위별 위험을, 커버리지는 대상을, 신뢰 타일은 평가를 엽니다. 미해결 발견 사항 수는 등록된 각 자산의 최신 스캔에서 가져오며(재실행해도 이중 집계되지 않음), 등록된 자산이 없는 워크스페이스는 대신 최신 스캔을 읽습니다. 수치의 출처: /api/cloud/risks, /api/overview, /api/cloud/status, /api/endpoint 및 /api/trust-signal/status.

경로 아래에는 패널이 세 개 더 있습니다. 마지막 스캔 이후 변경 사항 패널은 등록된 각 자산을 이전 스캔 대비 신규 / 해결 건수 및 다음 예약 실행과 함께 나열합니다 — 새로 발생한 발견 사항이 있는 자산이 먼저 정렬되며, 행을 클릭하면 해당 자산의 최신 스캔이 열립니다. 다음 조치 패널은 이미 보유한 상태에서 도출됩니다: 병합 준비가 된 자동 수정 풀 리퀘스트, 확인을 기다리는 섀도 AI 후보, 교체해야 할 노출된 자격 증명(순위별 위험에서), 그리고 가장 먼저 수정할 입증된 경로. 미해결 발견 사항 · 8주 패널은 등록된 자산 전체를 합산한 스파크라인입니다(각 자산의 최신 미해결 건수를 주 단위로 이월, 출처: /api/assets/<id>/trend). 전주 대비 ↑ / ↓ 화살표가 함께 표시되며 이 화살표는 심각도 타일에도 반복됩니다. 등록된 자산의 두 번째 스캔 이후에 나타납니다.

경영진 뷰. 대시보드 상단의 분석가 / 경영진 토글은 같은 숫자를 한 단계 높은 관점으로 전환합니다: 퍼널 라인이 포함된 입증 경로 수치, 현재 상태를 바탕으로 작성된 평이한 요약(Redthread가 매핑하는 것, 입증된 것, 심각도별 미해결 발견 사항, 이전 스캔 이후 변화, 에이전트 신뢰, 다음 조치), 이어서 커버리지, 신뢰, 심각도, 8주 추세, 상위 공격 경로가 표시됩니다. 스캔 세부 동작은 숨겨집니다. 경영진 뷰가 기본값이며, 분석가 뷰는 클릭 한 번으로 전환할 수 있고 선택은 브라우저에 기억됩니다.

저장된 뷰. 스캔의 발견 사항 화면에서 심각도 / PoC / 악용됨 칩으로 목록을 필터링할 수 있습니다. ＋ 뷰 저장은 현재 심각도 필터와 제외 항목 표시 설정을 이름을 붙여 브라우저에 워크스페이스별로 저장하며, 저장된 뷰는 필터 옆에 ★ 칩으로 표시됩니다.

콘솔 내비게이션은 스캔 유형이 아니라 하는 작업을 기준으로 묶여 있습니다: 개요 (대시보드) · 연결 (스캔 유형. 등록된 대상은 설정 → 대상에서 관리) · 탐색 (Redthread Flow, 평가 및 통합, 채팅, 클라우드 이슈. 지식은 채팅 페이지의 지식 버튼에서 엽니다) · 처리 (발견 사항, PR 리뷰) · 거버넌스 (평가 및 통합, 설정).

지속 뷰는 등록된 모든 자산을 한곳에 집계하므로, 보안 책임자나 이사회가 전체 환경을 한눈에 보고 올바른 방향으로 나아가고 있음을 입증할 수 있습니다. 일정과 CI가 이미 실행하는 스캔만으로 채워지며, 추가로 계측할 것은 없습니다.

자산별 집계 — GET /api/overview. 각 자산에는 최신 스캔 상태, 심각도별 발견 사항, 이전 스캔 대비 신규 / 해결 증감, 일정과 다음 실행이 표시됩니다. 자산의 현재 상태뿐 아니라 지난번 이후 바뀐 점도 확인할 수 있습니다.

위험 추세 — GET /api/assets/<id>/trend. 모든 자산에는 시간에 따른 발견 사항 계열이 있습니다 — 가장 오래된 스캔 → 최신 스캔 순으로 각 단계의 미해결 건수와 신규·해결 건수를 담습니다 — 따라서 단일 스냅샷이 아니라 수 주에 걸쳐 위험이 감소하는 추세임을 보여 줄 수 있습니다. 이것이 대시보드 스파크라인의 데이터입니다.

내보내기 — GET /api/overview.csv. 클릭 한 번으로 조직 전체 집계를 CSV로 내보내 스프레드시트, QBR 자료, 자체 BI에 활용할 수 있습니다.

섀도 AI 탐지(AI 인벤토리)

기능: 보안 팀이 모르는 채 조직에서 사용 중인 AI, 즉 "섀도 AI"를 찾아냅니다. 조용히 LLM API를 호출하는 리포지토리, 클라우드 계정에서 켜진 관리형 AI 서비스, 귀사 도메인에 노출된 자체 호스팅 모델 서버나 챗봇 UI 등입니다. 이것은 탐지 및 인벤토리 기능입니다: 알려 주는 것은 AI의 위치이며, 취약 여부가 아닙니다.

방식: 살펴볼 표면을 연결하면, 각 실행이 무엇을 커버했는지 정확히 보고합니다. 모든 결과는 귀사가 확인해야 하는 후보이며 — 스스로는 아무것도 등록하지 않습니다. 확인된 후보는 중복이 제거된 하나의 AI 인벤토리로 병합되며 커버리지 배너가 표시됩니다. 이미 알고 있거나 범위 밖인 항목은 제외하세요.

이유: 존재를 모르는 AI는 보호하거나 통제할 수 없습니다. 섀도 AI는 데이터 유출, 비용 폭주, 컴플라이언스 공백이 숨는 곳이며, 인벤토리는 첫 번째 통제 수단입니다. 여기에서 확인한 항목이 테스트와 모니터링 대상이 됩니다. 참고: 탐지 & 인벤토리.

도구: GitHub 조직/리포지토리 API + LLM SDK 사용 탐지(리포지토리); 다음을 이용한 에이전트 없는 클라우드 열거: boto3 — Bedrock, SageMaker, Lex, Comprehend(클라우드); 모델 서버 및 OpenAI 호환 엔드포인트에 대한 HTTP/TLS 표면 탐색(외부). 모두 에이전트 없이 동작합니다.

AI 공급망

기능: 앱이 기반으로 삼는 AI 구성 요소에서 오는 위험 — 서드파티 파운데이션 모델, 파인튜닝되거나 사전 학습된 가중치, 학습 및 RAG 데이터셋, 임베딩, 플러그인/도구, 그리고 스택의 ML/LLM 라이브러리와 모델 레지스트리. 오염된 모델, 백도어가 심긴 데이터셋, 허브의 타이포스쿼팅 모델, 취약한 ML 의존성은 코드 한 줄 작성하기도 전에 앱을 침해할 수 있습니다. 해당 항목: OWASP LLM03:2025 공급망.

방식: 스캔 중에 에이전트가 범위 내 AI 구성 요소를 검사합니다 — 모델과 데이터셋의 출처와 그 출처의 신뢰 여부, 플러그인/도구의 연결 방식과 신뢰 수준, ML/LLM 스택의 의존성 트리. 의존성 CVE는 실제 익스플로잇 가능성(KEV / EPSS)과 도달 가능성으로 분류되므로, 소음의 벽이 아니라 실제로 중요한 것만 보게 됩니다.

이유: AI 앱의 신뢰성은 물려받은 모델, 데이터, 라이브러리의 신뢰성을 넘을 수 없습니다 — 그리고 이것들은 코드베이스 외부에서 들어와 앱 수준 통제를 우회합니다. 바로 그 이유로 OWASP LLM Top 10에 포함되어 있습니다.

도구: osv-scanner — 의존성 CVE 인벤토리 생성, 이어서 EPSS / CISA-KEV / 도달 가능성 분류 퍼널(참고: 의존성 CVE); Redthread LLM 스킬 팩은 발견 사항을 OWASP LLM03 및 MITRE ATLAS AI Supply Chain Compromise (AML.T0010)에 매핑합니다.

인프라 & 클라우드

기능: 클라우드 보안 태세 관리(CSPM). 앱을 넘어 공격자가 노리는 노출을 클라우드에서 점검합니다 — 공개 버킷, 과도하게 넓은 IAM, 전 세계에 열린 포트, 암호화되지 않았거나 공개된 데이터, 감사 추적의 사각지대. 에이전트 없음, CVSS 점수화.

방식: 에이전트 없는 역할을 연결하면 Redthread가 그 역할을 위임받아(assume) 읽기 전용으로 열거하고 결정론적 점검을 실행합니다 — 키도, 쓰기 권한도 필요 없습니다. 발견 사항은 실제로 점검에 실패한 리소스에서만 생성됩니다.

명령줄 없이 클릭 두 번으로 AWS 연결. 다음 버튼을 누르세요: AWS를 열고 역할 생성하기. AWS CloudFormation 콘솔이 모든 값이 채워진 상태로 열립니다 — Redthread 스캐너, 귀사의 고유 외부 ID, 그리고 읽기 전용 역할(ReadOnlyAccess + SecurityAudit)이며, 역할 이름은 millenniums-cloud-scan입니다. IAM 승인 확인란을 선택하고 다음을 클릭하세요: Create stack. 약 1분 기다린 뒤 앱에 12자리 AWS 계정 번호를 다시 입력하세요. Redthread가 역할 ARN을 직접 구성하고, 저장하기 전에 실제 읽기 전용 호출 한 번으로 이를 검증합니다. 스택이 아직 생성 중이면 오류 대신 기다렸다가 다시 시도하라는 안내가 표시됩니다. 권한을 회수하려면 MillenniumsCloudScan 스택을 삭제하세요. 이전에(예: Terraform으로) millenniums-cloud-scan 역할을 이미 만들었나요? 스택이 역할이 이미 존재한다고 보고할 것입니다 — 건너뛰고 계정 번호만 입력하세요. 기존 역할이 귀사의 외부 ID로 Redthread 스캐너를 신뢰하는 한 그대로 동작합니다. 템플릿은 공개되어 있고 짧습니다 — 실행하기 전에 읽어 보세요: millenniums-cloud-scan-v1.yaml. Terraform이나 자체 역할을 선호하시나요? 인프라 페이지에서 여전히 Terraform을 생성하고 역할 ARN을 입력받습니다.

AWS 관리 담당자가 아닌가요? 환경 스캔 페이지에서 담당자에게 보낼 링크 받기를 누르면 AWS를 운영하는 담당자를 위해 같은 두 단계를 여는 비공개 링크가 생성됩니다 — 상대방은 계정이 필요 없습니다. 이 링크로 할 수 있는 일은 단 하나, 귀사 워크스페이스에 AWS를 연결하는 것뿐입니다. 회사 이름만 표시되며 이메일이나 발견 사항은 절대 표시되지 않고, 7일 후 만료되며, 새 링크를 만들면 이전 링크는 취소됩니다. 담당자가 완료하면 환경 스캔의 해당 레인이 녹색으로 바뀝니다.

Azure, Google Cloud, Oracle Cloud도 복사하거나 붙여 넣을 것 없이 클릭 한 번으로 연결됩니다. Azure: Microsoft로 로그인해 Redthread를 승인하면, Azure가 미리 채워진 배포를 열어 Redthread 스캐너에 다음 권한을 부여합니다: Reader + Security Reader (선택한 구독 대상). 각 권한 부여에는 워크스페이스 고유 표식이 포함되며, Redthread는 귀사 표식이 있는 구독만 연결합니다. Google Cloud: Google로 로그인하고 소유한 프로젝트를 선택하면, 귀사의 로그인 권한으로 해당 프로젝트에 Redthread 스캐너용 Viewer + Security Reviewer 역할을 추가합니다. Google 토큰은 그 한 번의 변경에만 사용된 뒤 폐기됩니다. Oracle Cloud (OCI): Oracle이 미리 채워진 Resource Manager 스택을 엽니다. 이 스택은 RedthreadCloudScan 그룹과 API 키 전용 사용자(ID 도메인을 사용하는 Oracle 계정에 필요한 이메일 주소 포함), 읽기 전용 정책(inspect all-resources, 그리고 read (버킷, 네트워크, 사용자 설정 대상 — 파일 내용, 데이터베이스 지갑, VM 콘솔 출력은 절대 아님))을 생성하고 워크스페이스의 공개 키를 업로드한 뒤 사용자 정보를 Redthread에 보고합니다. 어떤 경우든 귀사가 Redthread에 비밀을 건네지 않으며, 권한 회수는 귀사 콘솔에서 클릭 한 번이고, 모든 연결은 저장되기 전에 실제 읽기 호출로 검증됩니다. 명령줄을 선호하시나요? 각 클라우드는 여전히 수동 명령(Azure 앱 등록, GCP 서비스 계정 키, OCI Cloud Shell)을 제공하며, 그곳에 붙여 넣은 비밀은 쓰기 전용입니다 — 어떤 화면이나 API에서도 반환되지 않습니다. Kubernetes 및 모든 Prowler 인벤토리도 여전히 직접 수집할 수 있습니다. 참고: API 문서.

이유: 앱이 완벽해도 그 앱이 실행되는 인프라를 통해 침해될 수 있으며, 보안 태세는 팀이 배포할 때마다 표류합니다. 에이전트 없이 동작하므로 분기에 한 번이 아니라 지속적으로 실행해도 안전합니다.

도구: 다음을 이용한 에이전트 없는 클라우드 열거: boto3 (AWS), 귀사가 부여한 역할(ReadOnlyAccess + SecurityAudit) 대상. 이어서 Redthread의 결정론적, CVSS 점수화 보안 태세 점검을 실행합니다. 대신 모든 Prowler-호환 형식 인벤토리를 수집할 수도 있으며, GCP / Azure / Kubernetes에도 동일한 점검이 실행됩니다.

Redthread — 위험 그래프 & 공격 경로

Redthread — Redthread의 그래프 엔진입니다. 공격 경로 보고서, 풀 리퀘스트 게이트, 쿼리 빌더, 런타임 센서 아래에 있는 계층으로, 이 네 가지가 모두 같은 그래프를 읽고 쓰므로 서로 어긋나는 일이 없습니다.

기능: 귀사 클라우드 전반의 모든 자산, 신원, 네트워크 경로, 발견 사항을 하나의 정규화된 그래프로 담고, 그 그래프를 관통하는 공격 경로의 순위 목록을 제공합니다. 발견 사항은 이렇게 말합니다: “이 버킷은 공개되어 있습니다.” 위험은 이렇게 말합니다: “인터넷이 이 워크로드에 도달하고, 이 워크로드는 자격 증명을 보유하며, 그 자격 증명으로 고객 데이터를 읽을 수 있습니다.” 경로가 곧 제품입니다.

방식: 클라우드 제공업체별 용어는 수집기에서 끝납니다. AWS 역할, Entra ID 서비스 주체, GCP 서비스 계정은 모두 같은 종류의 노드가 되므로 경로가 클라우드 경계를 넘을 수 있습니다. 결과 위에서 여덟 가지 규칙이 실행됩니다 — 노출된 워크로드 → 민감 데이터, 자격 증명 체인, 크로스 클라우드 피벗, 권한 상승, 섀도 데이터, 노출된 AI 자산, 입증된 교차 계층 체인. 각 규칙은 알림이 아니라 경로를 반환합니다.

이유: 보안 태세 도구는 수백 개의 critical을 만들어 내지만 우선순위는 주지 않습니다. CVSS만으로 순위를 매기면 공격자가 실제로 거기에 도달할 수 있는지 전혀 알 수 없습니다. 우선순위는 도달 가능성이며, 도달 가능성은 그래프 안에서만 존재합니다.

도구: Redthread는 엔진이지만, 그 파일은 독점 형식이 아닙니다. 그래프는 graphify의 node-link 형식으로 출력되므로 직접 탐색할 수 있습니다 — graphify path "internet" "customer-data" — 또는 위험 뷰에서 다운로드할 수도 있습니다. 운영할 그래프 데이터베이스도, 종속도 없습니다: 떠나면 그래프도 함께 가져갑니다.

아키텍처 및 검증

이 섹션은 고객이 앱에서 볼 수 있습니다: 로그인 한 뒤 아무 문서 링크나 여세요.

Redthread Flow — 그래프 읽기

Redthread Flow는 그래프에 질문하면 답을 목록이 아니라 그림으로 보여 주는 콘솔 패널입니다. 왼쪽 내비게이션에서 대시보드 바로 아래에 있습니다.

환경 지도. Redthread Flow를 열면 전체 환경이 네트워크로 표시됩니다. 각 자산은 위치에 따라 색이 다른 점으로(AWS는 주황, Oracle Cloud는 청록, Azure는 파랑, Google Cloud는 초록, 센서가 설치된 머신은 보라, 외부 ID는 분홍, 인터넷은 검정) 표시되고, 크기는 자산 종류에 따라 정해져 머신, 워크로드, AI 에이전트가 눈에 띕니다. 같은 클라우드의 자산은 옅게 칠해진 영역에 모이며, 자산이 3개 이상인 클라우드에는 가운데에 이름이 붙은 마커가 표시됩니다. 일반 링크는 가는 파란색 선이고, 한 클라우드에서 다른 클라우드로 넘어가는 링크는 빨간색, 공격 경로는 심각도 색상의 굵은 선입니다. 와일드카드 권한(모든 저장소에서 모든 작업이 허용된 역할)은 저장소마다 선을 긋는 대신 해당 클라우드의 “모든 데이터 저장소” 허브로 가는 선 하나로 그려집니다. 이름은 짧게(예: aws-ecs) 서로 겹치지 않는 작은 흰색 라벨에 표시됩니다. 인터넷, 허브, 심각 또는 높음 공격 경로상의 모든 자산은 항상 이름이 표시되고, 나머지는 확대하면 나타납니다. 심각 또는 높음 이슈가 있는 자산에는 빨간 링이 표시됩니다. 지도는 Sigma.js로 그려지므로 링크가 수천 개인 환경도 부드럽게 움직이며, 자산 위에 마우스를 올리면 그 자산과 관계없는 모든 것이 흐려집니다.

위험 강조. 지도는 위험 강조 가 켜진 상태로 열립니다. 문제가 없는 것은 모두 옅은 회색이 되어, 심각 또는 높음 이슈가 있는 모든 자산(빨간 라벨에 이름 표시)과 심각 또는 높음 공격 경로가 눈에 띕니다. 오른쪽 패널에 그 공격 경로가 나열되며, 하나를 클릭하면 그 경로만 표시하고 확대하고, 다시 클릭하면 돌아갑니다. 위험 강조를 끄면 전체 환경을 클라우드별 색상으로 볼 수 있습니다.

보는 법: 스크롤하거나 + 와 − 로 확대/축소하고, 배경을 드래그해 이동하고, 점을 드래그해 배치하며, 맞춤으로 다시 맞춥니다. 색 테두리와 숫자는 문제를 표시하고(테두리는 가장 높은 심각도), 작은 초록 점은 센서가 보고 중임을 뜻합니다. 점을 클릭하면 세부 정보, 문제, 연결이 담긴 카드가 열리고, 인접 자산은 강조되며 나머지는 흐려집니다. 아이덴티티를 숨기거나 클라우드 간 연결만 표시할 수 있습니다.

그래프에 질문 은 두 번째 탭으로, 아래에서 설명하는 질의응답 화면입니다. 공격 경로 는 세 번째 탭으로, 인터넷에서 보호할 대상까지의 경로를 순위대로 보여줍니다. 클라우드 이슈는 왼쪽 메뉴의 채팅 아래에 별도 페이지가 있으며, 모든 클라우드의 잘못된 구성을 클라우드별로 필터링해 보여줍니다.

사용 방법

패널은 이미 그려진 그래프와 함께 열립니다. 저장된 질문을 순서대로 실행해 경로를 반환하는 첫 번째 질문에서 멈추고, 어떤 질문을 선택했는지 강조 표시합니다 — 그래서 빈 캔버스가 아니라 실제 답에서 시작합니다. 직접 질문하는 방법은 세 가지입니다:

• 자연어. 질문을 입력하고 — "인터넷에 노출된 것 중 다른 클라우드의 고객 데이터에 도달하는 키를 가진 것이 있는가?" — 질문 버튼을 누르세요. 모델이 이를 구조화된 그래프 쿼리로 변환합니다. 실행된 쿼리는 항상 "실행한 쿼리" 아래에 표시됩니다: 펼쳐서 질문을 제대로 이해했는지 확인하세요. 질문이 그래프로 표현할 수 있는 범위를 벗어나면, 우연히 유효성 검사를 통과하는 가장 가까운 쿼리를 실행하는 대신 그렇다고 말하고 무엇이 빠졌는지 알려 줍니다. 아무도 묻지 않은 질문에 대한 답도 겉보기에는 똑같이 답처럼 보이기 때문입니다.
• 저장된 질문. 입력란 아래 버튼은 흔히 쓰는 질문을 미리 작성해 둔 것입니다: 다른 클라우드의 PII에 도달하는 유출 키를 가진 노출 VM, 데이터 저장소에 도달하는 자격 증명을 보유한 워크로드, 다른 신원이 될 수 있는 신원, 인터넷에서 도달 가능한 민감 저장소 등. 하나를 클릭해 실행하세요.
• 직접 구성하기. 다음을 펼치면 직접 구성하기 드롭다운이 나타납니다: 찾기 [자산 유형] — [클라우드] 상태: [노출], 연결 관계: [관계], 대상: [자산 유형] 보유 데이터: [데이터 분류]. 쿼리 언어를 배울 필요가 없습니다.

자연어 질문은 질문마다 모델 호출 비용이 들기 때문에 요금제별로 시간당 횟수가 제한됩니다 — Free 10회, Starter 40회, Growth 120회, Enterprise 400회. 저장된 쿼리와 직접 구성한 쿼리는 그래프에 직접 실행되며 제한이 없습니다.

그림 읽는 법

그림은 왼쪽에서 오른쪽으로 흐르는 계층형 흐름입니다: 화살표 방향이 곧 공격 방향입니다. 가장 왼쪽 열은 공격자가 시작하는 지점(보통 인터넷)이고, 가장 오른쪽은 공격자가 도달하는 대상입니다.

체인 끊기

그래프 아래에는 순위가 매겨진 차단 목록이 있습니다. 전체 결과 집합의 모든 홉은 끊었을 때 사라지는 경로 수로 점수가 매겨지며, 각 행에는 조치(자격 증명 교체 및 제거, 권한 축소, 노출 차단), 효과가 있는 이유, 증거가 표시됩니다. 왼쪽 숫자는 끊기는 경로 수입니다. 실제 AWS 계정에서 한 역할의 자격 증명 하나를 교체하는 최상위 차단만으로 닫힌 경로: 1,382개 경로 중 86개.

"일치하는 경로가 없습니다"의 의미

빈 결과는 실패가 아니라 하나의 답입니다. 현재 그래프에는 그것들을 연결하는 것이 없습니다. 정직한 단서 두 가지: 커버리지는 귀사가 연결한 범위이므로 Redthread가 볼 수 없는 경로라고 해서 존재하지 않는 경로는 아닙니다. 그리고 데이터 분류는 결코 추론하지 않습니다 — 저장소는 unknown 상태로 남습니다(DSPM이 샘플링하거나 귀사가 레이블을 지정하기 전까지). 따라서 분류 기준 질문은 아직 분류되지 않은 계정에서 올바르게 아무것도 반환하지 않습니다. 분류를 활성화하고 스캔을 실행하면 답을 내기 시작합니다.

공격 경로 분석 — 개념

공격 경로 분석은 공격자가 환경을 이동해 중요한 자산에 도달할 수 있는 경로를 매핑합니다. 개별 스캔은 수천 개의 발견 사항을 만들지만, 그중 무엇이 서로 연결되어 익스플로잇 가능한 무언가가 되는지는 보여 주지 않기 때문에 이 분석이 필요합니다. 잘못된 구성 하나만으로는 침해가 되는 경우가 드물지만, 잘못된 구성에 약한 권한과 노출된 호스트가 더해지면 침해가 됩니다.

네 단계이며, Redthread는 네 단계를 모두 수행합니다:

1. 자산 및 위험 탐지. 워크로드, 신원, 구성, 데이터에 대한 완전한 에이전트 없는 가시성 — 여기에 취약점, 노출된 시크릿, 잘못된 구성, 과도한 권한까지 더해집니다. 중간 규모 AWS 계정이면 보통 자산 수백 개와 권한 관계 수만 개입니다.
2. 그래프 기반 매핑. 이 위험들은 리소스를 연결하고 서로의 관계를 보여 주는 하나의 그래프에 배치됩니다 — 예를 들어 공용 IP 및 치명적인 취약점을 가진 워크로드가 과도한 권한의 신원과 연결되는 식입니다. 모든 엣지에는 신뢰도가 표시됩니다: 입증됨, 구성에서 추출됨, 또는 추론됨.
3. 경로 식별. 그래프에서 다음을 탐색합니다: 유해 조합 — 개별적으로는 심각도가 낮은 여러 이슈가 연결되어 가치 있는 대상으로 가는 고영향 경로가 되는 시퀀스입니다. 여덟 가지 규칙이 그래프 위에서 실행되며, 각 규칙은 경로를 반환합니다 (알림이 아님).
4. 우선순위 지정. 경로는 심각도, 그다음 입증 우선(이론적 경로보다 먼저), 그다음 경로의 직접성, 그다음 영향 반경 순으로 정렬됩니다. 핵심 자산이나 상승된 권한으로 가는 경로는 무해한 곳에서 끝나는 경로보다 높은 순위를 받습니다.

검색 방식에 대한 참고 — 답이 달라지기 때문입니다. 단순한 최단 경로 검색은 각 대상까지의 최단 경로를 찾는데, 이는 종종 중요한 경로가 아닙니다. 공개적으로 읽을 수 있는 버킷은 한 홉 만에 도달할 수 있고, 그 한 홉이 같은 버킷에 도달하는 세 홉짜리 자격 증명 탈취 체인을 가려 버립니다. 그래서 특정 종류의 홉에 의존하는 규칙은 해당 홉을 반드시 거치도록 명시적으로 검색하며, 체인은 가려지지 않고 그대로 보고됩니다.

크로스 클라우드 위험

기능: 한 클라우드에서 시작해 다른 클라우드에서 끝나는 공격 경로 — 각 제공업체의 자체 도구는 자기 자신만 보기 때문에 볼 수 없는 경로입니다.

방식: 실제로 경계를 넘는 신뢰 관계를 읽습니다: 신뢰 정책에 Entra ID 또는 Google 발급자를 지정한 AWS 역할, AWS 계정을 신뢰하는 GCP 워크로드 신원 풀. 엣지가 생기려면 양쪽이 모두 일치해야 합니다 — 부여된 권한만으로는 결코 충분하지 않습니다.

그래프에서: 확인된 경계 간 신뢰는 클라우드 사이의 can-assume 엣지가 되며, 이를 가로지르는 모든 공격 경로는 다음 위험으로 순위가 매겨집니다: T3 — 크로스 클라우드 피벗 (조회: GET /api/cloud/risks), 엣지별 전체 경로와 증거가 함께 제공되며 입증 우선으로 정렬됩니다. 그래프는 개방형 node-link JSON으로 내보내지므로 직접 탐색할 수도 있습니다: graphify path "aws-prod" "azure-tenant" --graph graph.json.

과도하게 넓은 신뢰는 그 자체로 발견 사항입니다. 신뢰 정책에 sub (subject) 조건이 없는 역할은 해당 외부 테넌트의 모든 신원을 신뢰하게 되며, 의도한 신원만 신뢰하는 것이 아닙니다. OIDC 스니펫을 복사할 때 실수로 배포하기 쉬우며, 경로가 그려지기 전부터 그 자체로 critical 발견 사항입니다.

아이덴티티 신뢰 외에도 클라우드 간 연결이 세 가지 더 있습니다.

• 네트워크: AWS, Oracle Cloud, Azure, Google Cloud의 사이트 간 VPN 터널을 양쪽에서 읽어 공인 IP로 맞춥니다. 그래서 AWS에서 Oracle 게이트웨이로 가는 터널은 두 네트워크 사이의 하나의 연결로 표시됩니다.
• 실제 사용: AWS CloudTrail은 지난 24시간 동안 모든 API 호출의 출발 주소를 기록합니다. 연결된 다른 클라우드의 VM에서 온 호출은 그 VM에서 사용된 AWS 아이덴티티로 이어지는 입증된 연결이 됩니다.
• 외부에서 쓰도록 만든 키: Oracle의 S3 호환 키를 소유 사용자와 함께 나열합니다. 코드에서 발견된 클라우드 키와 identity domains를 쓰는 계정의 Oracle 로그인 페더레이션은 아직 지원하지 않습니다.

이유: 페더레이션 신원은 팀이 장기 키를 피하는 방법이지만, 공격자가 클라우드 사이를 이동하는 방법이기도 합니다. AWS, Azure, GCP 어느 쪽도 상대 측이 부여한 신뢰는 표시하지 않으므로, 이것이 바로 단일 클라우드 보안 태세 도구가 남겨 두는 사각지대입니다.

도구: AWS IAM 신뢰 정책, Microsoft Graph를 통한 Entra ID, GCP 워크로드 신원 페더레이션. 발급자는 식별되며, 결코 추측하지 않습니다 — 인식되지 않은 발급자는 크로스 클라우드 엣지를 만들지 않습니다. 잘못 레이블된 엣지는 없는 것보다 나쁘기 때문입니다.

데이터 보안 태세(DSPM)

기능: 데이터 저장소에 실제로 무엇이 들어 있는지 파악합니다 — 개인 데이터, 카드 소유자 데이터, 건강 데이터, 자격 증명 — 그리고 프로덕션 사본이 조용히 흘러간 위치까지.

방식: 두 단계로 동작합니다. 제한된 샘플링은 이미 부여한 동일한 에이전트 없는 역할을 통해 객체의 작은 샘플을 상한 내에서 읽습니다 — 스냅샷도, 추가 권한도, 설치도 없습니다. VM 디스크에 있는 비관리형 데이터베이스의 경우, 임시 스냅샷 워커가 실행되는 위치는 귀사 계정 내부이며, 스냅샷을 읽기 전용으로 마운트한 뒤 발견 사항만 전송합니다 — 값도, 파일 내용도, 행도 절대 보내지 않습니다 — 그런 다음 종료됩니다.

섀도 데이터: 저장소의 스키마 지문을 수집하므로, 스테이징 버킷에 있는 프로덕션 스키마는 검토가 필요한 사본으로 표시되며 — 그 사본이 인터넷에도 노출되어 있으면 critical로 상향됩니다.

이유: 무엇이 걸려 있는지 모르면 심각도는 의미가 없습니다. CSS 파일이 든 공개 버킷과 고객 레코드가 든 공개 버킷은 같은 발견 사항이지만 위험은 전혀 다릅니다. 둘을 가르는 것이 분류이며, 그래서 Redthread는 결코 추측하지 않습니다: 레이블이 없는 저장소는 unknown, 즉 안전하다고도 민감하다고도 가정하지 않은 상태로 남습니다.

도구: 유효성 검사(Luhn, SSN 구조)를 갖춘 패턴 + 엔트로피 분류기, 열 이름 교차 확인, 계보 추적을 위한 스키마 지문. 객체별 및 전체 상한이 있으며, 커버리지는 추정하지 않고 실제로 샘플링한 범위로 보고합니다.

코드-투-클라우드 — 배포 전에 막기

기능: 모든 풀 리퀘스트에서 Terraform, CloudFormation, ARM, Kubernetes 매니페스트를 읽고, 변경이 실제 문제를 만들 경우 빌드를 실패시키는 검사입니다.

방식: 계획된 리소스는 귀사의 운영 중 환경의 위험 그래프에 병합되며, Redthread는 변경이 새로 유발할 문제를 보고하고, 계정에 이미 있는 상태는 보고하지 않습니다. 발견 사항은 풀 리퀘스트에 단일 코멘트로 게시되며, 푸시할 때마다 새 코멘트가 아니라 같은 코멘트가 수정됩니다.

게이트는 정확히 diff가 책임지는 것에 대해서만 차단합니다: diff가 선언하는 치명적인 잘못된 구성, diff가 유발하는 공격 경로, 또는 diff가 커밋하는 자격 증명. 기존 계정 위험은 결코 풀 리퀘스트를 차단하지 않습니다 — 그렇게 하면 게이트가 꺼지게 되기 때문입니다. 보고 전용 모드는 한 줄만 바꾸면 됩니다.

이유: 잘못된 구성을 수정하기 가장 저렴한 시점은 그것이 생기기 전입니다. 그 이후는 모두 조치, 변경 기간, 우선순위 논쟁입니다.

도구: 실제 HCL 파서(줄 매칭 아님), 그리고 CloudFormation / ARM / Kubernetes. 시크릿 스캔은 플레이스홀더와 변수 참조를 제외합니다 — 다음 같은 것을 플래그하는 스캐너는 password = var.db_password 사람들이 경고를 무시하도록 길들일 뿐입니다. 지원 플랫폼: GitHub Actions 및 Azure DevOps; 계정 토큰이 아니라 자산별 키로 인증합니다.

그래프에 질문

기능: 저장된 질문, 그리고 예상하지 못한 질문을 위한 쿼리 빌더 — "개인 데이터를 담은 저장소에 접근 권한을 주는 평문 키를 보유한, 인터넷에 노출된 모든 VM을 보여 주세요."

방식: 자산 종류를 선택하고, 속성으로 필터링한 다음, 관계를 따라 도달 가능한 대상까지 이동합니다. 결과는 이름 목록이 아니라 다음 형태입니다: 경로 — 각 홉의 증거 포함.

이유: 인시던트 중에 떠오르는 질문은 벤더가 미리 작성해 둔 질문이 아닙니다. 자유 텍스트 검색으로는 "A 및 B 및 C에 도달" 같은 조건을 표현할 수 없습니다 — 이는 집합 소속과 도달 가능성의 문제이며, 그래프가 필요합니다.

도구: 닫힌 안전한 쿼리 형식 — 쿼리는 코드가 아니라 데이터이며, 관계가 검증되고 탐색 범위가 제한되므로 코드 실행으로 바뀔 수도, 대규모 환경에서 멈출 수도 없습니다.

조치 & 티켓 발행

기능: 위험이 규칙과 일치하면 서명된 웹후크를 보냅니다 — 자체 자동화에 연결하거나, 공격 경로가 담긴 티켓으로 Jira나 ServiceNow에 바로 보낼 수 있습니다.

방식: 다음으로 워크플로를 등록합니다: POST /api/workflows — { name, url, kind: "webhook|jira|servicenow", rules: ["T2"], min_severity: "critical", proven_only: false, auth_header }. 전달은 위험이 다음 필터에 모두 일치할 때만 발생합니다: 이름이 지정된 그래프 규칙(T1–T8) 중 하나, 다음 수준 이상: min_severity, 그리고 다음을 설정한 경우 proven_only — 단순히 도달 가능한 것이 아니라 경로가 실제로 익스플로잇된 경우에만. 서명 비밀은 단 한 번만 반환되며 다시는 반환되지 않습니다. POST /api/workflows/<id>/test — 합성 전달을 보내므로, 실제 이벤트 전에 연결 상태를 확인할 수 있습니다.

모든 전달을 검증하세요. 각 요청에는 원시 본문에 대한 HMAC 서명이 다음 헤더에 담겨 있습니다: X-Millennium-Signature — 귀사의 비밀로 다시 계산해 일치하지 않는 것은 모두 거부하세요. 전달은 재전송이 제한되며(타임스탬프 + nonce), 대상은 반드시 공개 주소로 해석되는 HTTPS여야 합니다 — 웹후크를 내부 서비스나 클라우드 메타데이터 엔드포인트로 향하게 할 수 없습니다.

상류 단계의 방지: 같은 위험 그래프가 다음 기능을 구동합니다: 코드-투-클라우드 PR 게이트 — POST /api/iac/scan — 라이브 그래프 기준으로 치명적인 공격 경로를 유발할 풀 리퀘스트를 실패시키므로, 가장 저렴한 수정(병합하지 않는 것)이 조치할 대상이 생기기 전에 이루어집니다.

이유: 클라우드 전반의 쓰기 자격 증명을 보유한 보안 벤더는 치명적 장애의 단일 지점이자, 보안 검토를 통과하기 가장 어려운 항목입니다. 탐지와 실행을 분리하면 두 문제가 모두 사라집니다.

런타임 센서 Enterprise 애드온

기능: Kubernetes 노드, Linux VM, 엔드포인트 센서가 있는 머신에서 나온 선택적 런타임 탐지 결과를 다른 모든 것과 같은 위험 그래프에 표시합니다.

방식: Falco 탐지 결과를 Redthread로 바로 보내는 DaemonSet과, 조용한 노드도 온라인으로 표시되도록 하는 작은 하트비트 사이드카. 앱에서 활성화하고 센서를 추가한 뒤 표시된 세 명령을 실행하세요. 끄면 모든 센서가 즉시 취소됩니다.

Linux VM: 센서를 등록한 뒤 표시되는 명령을 VM에서 root로 실행하세요. 공식 falco.org 패키지 저장소에서 Falco를 설치하고, 모던 eBPF 프로브(Linux 5.8 이상, 커널 모듈 불필요)를 선택하고, 각 탐지 결과를 Redthread로 보내는 root 전용 설정을 쓰고, 재부팅 후에도 유지되는 서비스로 Falco를 시작합니다. Falco의 HTTP 출력은 헤더를 설정할 수 없으므로 센서 키가 그 설정의 URL에 포함되며, 이 키로는 탐지 결과 전송만 할 수 있습니다. Debian과 Ubuntu(apt), RHEL, Oracle Linux, Amazon Linux, Fedora(dnf 또는 yum)를 지원하며, 제거하려면 같은 명령을 --uninstall과 함께 실행하세요.

클라우드의 모든 VM: MAI_SENSOR_KEY를 추가하면 Cloud Shell 플릿 명령이 Falco도 설치합니다(Runtime → 센서 추가에서 채워진 명령이 표시됩니다). Azure(Run Command가 root로 실행)와 Google Cloud(sudo로 gcloud ssh)에서는 모든 Linux VM에 Falco가 설치됩니다. Oracle Cloud에서는 Run Command가 제한된 사용자로 실행되므로, 일회성 관리자 설정으로 그 사용자에게 sudo가 주어진 VM에만 Falco가 설치되고 나머지는 요약에 표시됩니다.

엔드포인트 센서가 있는 머신: 엔드포인트 센서는 20초마다 실행 중인 프로세스를 확인해 암호화폐 채굴기, 리버스 셸 패턴, 임시 폴더에서 실행되는 프로그램을 찾고, 처음 나타날 때 탐지 결과를 보냅니다(일치 항목당 1시간에 한 번). 커널 접근이 필요 없고 macOS와 Linux에서 동작하지만, 한 번의 확인보다 짧은 것은 볼 수 없으므로 Linux에서는 Falco가 더 철저한 선택지입니다. 명령줄은 머신에서 대조되며 전송되지 않습니다. 탐지 결과에는 규칙, 짧은 프로세스 이름, 시간만 담깁니다. Runtime이 켜져 있을 때만 탐지 결과가 수락되며, 그렇지 않으면 센서는 6시간 동안 전송을 멈춥니다.

이유: 구성은 표류하며, 설정 하나 바뀌지 않고도 워크로드가 침해될 수 있습니다. 제공업체 위협 피드는 에이전트 없이도 그중 상당 부분을 잡아냅니다 — 이 기능은 1분 미만의 커널 내 가시성이 특권 DaemonSet을 감수할 가치가 있다고 판단한 팀을 위한 것이며, 의도적으로 Redthread의 기본값이 아니라 그 팀의 결정으로 남겨 둡니다.

방지가 아닌 탐지. 차단, 종료, 격리를 절대 하지 않습니다. 플랫폼의 나머지 부분은 서버에 아무것도 설치하지 않지만 이 기능은 의도적으로 설치하며, 그래서 별도의 애드온이고 기본적으로 꺼져 있습니다. 완전히 에이전트 없는 방식을 유지하고 싶다면, GuardDuty, Security Hub, Inspector의 발견 사항을 에이전트 없이 같은 그래프로 수집합니다.

도구: eBPF 프로브와 규칙 세트에는 Falco(CNCF)를 사용합니다. 하트비트 사이드카는 비특권이며 모든 capability를 제거합니다. 수집량에는 상한이 있으며, 초과한 이벤트는 삭제 집계되며, 조용히 사라지는 일은 없습니다.

네트워크 모의 침투 테스트 — 단계

이 섹션은 고객이 앱에서 볼 수 있습니다: 로그인 한 뒤 아무 문서 링크나 여세요.

컴플라이언스 보고서 & 증명서

완료된 모든 스캔은 기업이 테스트 기준으로 삼는 표준(PTES, NIST SP 800-115, OWASP WSTG, CREST, CVSS)에 근거한 감사 지원 보고서를 생성합니다. 보고서는 세 가지 등급으로 제공되어 독자마다 필요한 수준의 정보를 전달합니다:

• 증명서(Letter of Attestation) — 민감 정보를 제거하고 서명한 1페이지 문서로, 귀사의 고객, 구매 부서, 서드파티 위험 검토자에게 그대로 전달할 수 있습니다. 범위, 일정, 방법론, 심각도별 건수가 담기며 익스플로잇 세부 정보는 포함되지 않습니다. 다음에서 받을 수 있습니다: GET /api/runs/{id}/attestation.
• 전체 컴플라이언스 보고서 — 경영진 요약과 발견 사항별 기술 세부 정보: 수행 규칙(Rules of Engagement), 심각도 히트맵, 조치 로드맵, 그리고 각 발견 사항을 OWASP LLM 2025 → MITRE ATLAS → NIST AI RMF / ISO 42001 / EU AI Act에 매핑하는 AI 추적성 매트릭스. SOC 2, ISO 27001, NIST CSF에도 교차 매핑됩니다. GET /api/runs/{id}/compliance.
• JSON 버전 — 동일한 데이터를 담은 report.json 파일로, Vanta, Drata, Secureframe에서 사용할 수 있습니다. GET /api/runs/{id}/compliance.json.

정직한 점수 산정. CVSS는 종속성 CVE의 경우 실제 권고 점수이고, 취약점 클래스의 경우 표준 클래스 기본 벡터(그렇게 표시됨)입니다. 지어낸 숫자는 절대 사용하지 않습니다. 행위 기반 발견 사항(탈옥, 프롬프트 인젝션)에는 공격 성공률(ASR) — 실제 성공 횟수/시도 횟수 수치 — 이 측정 시 함께 표시됩니다(POST /api/runs/{id}/measure-asr). 100번 중 3번 성공하는 탈옥과 90번 성공하는 탈옥은 같지 않기 때문입니다.

도구: CVSS 3.1 점수 산정; OWASP LLM 2025 + MITRE ATLAS v5.6.0 추적성; PCI DSS 11.4, SOC 2, ISO 27001 / 42001, NIST CSF / AI RMF, EU AI Act에 대한 프레임워크 교차 매핑; OpenVEX (영향 있음/영향 없음 판정용); Wilson 95% 구간과 함께 보고되는 공격 성공률. 선택 사항: 인증된 CREST/OSCP 전문가 검토.

SSO, SCIM & 역할

기능: 팀을 위한 엔터프라이즈 신원 관리 — 싱글 사인온, 사용자 자동 프로비저닝과 디프로비저닝(계정 해제), 역할 기반 접근 제어, 감사 로그를 제공합니다. 모든 자산, 스캔, 발견 사항은 귀사의 워크스페이스 범위로 한정됩니다.

방식: 네 가지 역할 — owner (결제를 포함한 모든 권한), admin (워크스페이스 관리), member (실무 수행), viewer (읽기 전용) — 그리고 다음 기능:

• 싱글 사인온(OIDC) — 팀원이 귀사의 신원 공급자(Okta, Entra/Azure AD, Google, Auth0)로 로그인합니다. 귀사 이메일 도메인의 신규 사용자는 자동으로 프로비저닝됩니다. 소유자가 발급자(issuer) URL, 클라이언트 ID/시크릿, 도메인을 입력해 구성합니다.
• SCIM 2.0 프로비저닝 — 귀사의 IdP가 사용자를 자동으로 생성하고, 무엇보다 중요하게는 디프로비저닝까지 자동으로 처리합니다. IdP에서 사용자를 비활성화하면 이곳의 접근 권한도 즉시 차단됩니다. 플래그만 바꾸는 것이 아니라 토큰 자체가 폐기됩니다.
• 감사 로그 — 누가 어떤 스캔을 실행했는지, 누가 어떤 보고서를 조회하거나 내보냈는지 기록합니다.

이유: 팀 규모가 되면 위험은 외부에만 있지 않습니다. 접근 권한이 회수되지 않은 퇴사자나 과도한 권한을 가진 계정도 위험입니다. SSO는 로그인을 IdP 정책(MFA, 조건부 접근)으로 일원화하고, SCIM은 오프보딩이 누군가 잊어버릴 수 있는 티켓이 아니라 즉시 처리되도록 보장합니다.

도구: SSO용 OpenID Connect(OIDC) — Okta, Microsoft Entra ID, Google Workspace, Auth0; SCIM 2.0 (프로비저닝/디프로비저닝용); 상수 시간 비교와 즉시 폐기를 지원하는 테넌트별 Bearer 토큰. Enterprise 요금제. 설정 방법은 SSO & SCIM 문서를 참조하세요.

가이드: 첫 스캔 실행하기

목표: 새 계정에서 시작해 입증된 발견 사항까지 도달합니다.

사전 준비 사항

• 인증된 계정 (브라우저 빠른 시작).
• 대상 URL — 귀사가 소유하거나 테스트 권한이 있는, 실제로 실행 중인 앱 인스턴스입니다. 운영 환경이 아닌 스테이징 URL을 사용하세요. 이 항목은 필수입니다. 코드만으로는 실행 중인 앱이 되지 않습니다. 아직 없다면 다음을 참조하세요: 스캔 대상 정하기.
• 선택 사항: 소스 코드 — git 리포지토리 URL 또는 .zip 업로드. 더 깊은 화이트박스 스캔에 사용됩니다.

단계

1. 앱을 열고 스캔 상자에 대상을 붙여 넣거나, 다음 API를 호출하세요: POST /api/scan.
2. 소스가 있다면 추가하세요 — 리포지토리 URL 또는 로컬 경로를 다음 필드에 입력합니다: source 발견 사항의 품질을 좌우하는 가장 큰 요소입니다.
3. 스캔을 시작하세요. 다음 값을 기록해 두세요: run_id.
4. 완료될 때까지 기다리세요(상태 running → false). 보통 몇 분이면 끝납니다.
5. 보고서를 열고 위에서부터 분류하세요. Critical 항목이 먼저입니다.

문제 해결

• 403, "이메일을 인증하세요" — 인증 링크를 클릭하거나 "재전송"을 누르세요 / POST /api/resend.
• 402, 할당량 도달 — 남은 포함 스캔이나 팩 스캔이 없습니다. 결제에서 스캔 팩을 구매하세요 (요금제).
• 500, "스캔이 시작되지 않음" — 엔진을 시작할 수 없었습니다(Docker 또는 모델 키 문제). 자체 호스팅이라면 다음을 확인하세요: .env; 호스팅 앱이라면 다시 시도하세요.
• URL만으로 스캔했는데 발견 사항이 0건인 경우 — 다음 값을 제공한 뒤 source 다시 실행하세요. 블랙박스 테스트만으로는 AI 특유의 경로를 놓치는 경우가 많습니다.

가이드: 대상 등록하기

같은 앱을 반복해서 스캔한다면 매번 붙여 넣지 말고 대상 탭에서 한 번만 등록하세요. 각 대상은 자체 설정을 기억하므로, 재스캔은 클릭 한 번이면 됩니다: 지금 스캔. 등록된 대상은 CI 요금제가 각 풀 리퀘스트마다 자동으로 스캔하는 대상이기도 합니다.

각 필드의 역할

지금 스캔을 클릭하면 일어나는 일

1. 설정을 검사해 동작할 수 없는 구성은 즉시 걸러 냅니다. 예를 들어 변경된 파일만 옵션은 코드 리포지토리가 필요하므로, 스캔이 실패한 뒤가 아니라 시작하기 전에 알려 드립니다.
2. 귀사의 요금제와 지출 한도 설정이 적용되므로 스캔이 예산을 넘어 실행되는 일은 없습니다( 지출 한도 & 안전장치).
3. 테스트는 일회용 격리 샌드박스에서 실행됩니다. 코드는 재사용되거나 보관되지 않습니다( 귀사의 데이터).
4. 완료되면 결과가 다음 위치에 표시됩니다: 모의 침투 발견 사항 (참고: 스캔 결과 읽는 법).

가이드: 스캔 결과 읽기

스캔이 완료되면 스캔 목록에서 엽니다. 결과는 모의 침투 발견 사항에 탭별로 정리되어 표시되므로, 스크롤하지 않고도 각 섹션으로 바로 이동할 수 있습니다.

탭 구성

발견 사항 필터링

대규모 스캔에서는 수백 건의 발견 사항이 나올 수 있습니다. 목록 위의 색상 버튼으로 범위를 좁힐 수 있습니다. 하나를 클릭하면 필터가 적용되고, ✕ 필터 해제 버튼을 클릭하면 다시 모든 항목이 표시됩니다:

1. 심각도 버튼 — Critical High Low — 해당 수준의 발견 사항만 표시합니다. 대규모 스캔은 기본적으로 가장 심각한 수준에 초점을 맞춰 열리므로, 가장 심각한 문제부터 확인하게 됩니다.
2. ⚡ PoC — 실제로 동작하는 입증된 익스플로잇이 있는 발견 사항(신뢰도가 가장 높은 항목)만 표시합니다.

모든 발견 사항은 표시되기 전에 적대적 관점에서 한 번 더 검증됩니다. 오탐 가능성 높음 판정을 받은 항목은 기본적으로 숨겨집니다(토글로 다시 표시해 그 판단을 직접 검토할 수 있습니다).

발견 사항 하나 읽기

1. Critical과 High부터 시작하세요 — 공격자가 가장 먼저 도달하는 항목입니다.
2. "개념 증명(PoC)" 열기 — 취약점이 정확히 어떻게 익스플로잇되는지 단계별로 확인합니다. 유료 요금제에서는 ▸ 익스플로잇 스크립트 항목을 펼쳐 실제로 실행 가능한 익스플로잇을 확인할 수 있으므로, 엔지니어가 직접 재현할 수 있습니다.
3. "조치" 읽기 — 구체적인 수정 방법과 해당 코드의 위치.
4. 수정한 뒤 (다음 가이드 참조) 다시 스캔하여 취약점이 해결되었는지 확인하세요.

가이드: 스캔 발견 사항 수정하기

조건: Starter 요금제 이상에서 GitHub를 연결하면, Redthread가 수정안을 풀 리퀘스트 형태로 작성해 드립니다 — 검토와 병합은 귀사가 직접 하며, 아무것도 저절로 변경되지 않습니다. 완료된 스캔의 상단 행에 원클릭 작업 두 가지가 있습니다.

시작하기 전에

• 요금제: Starter 요금제 이상.
• 연동: GitHub 연결 완료 (연동 탭). 스캔 소스: GitHub 리포지토리 사용.
• 스캔이 완료됨 상태여야 합니다 — 도중에 멈춘 스캔은 먼저 재개 기능으로 끝까지 완료할 수 있습니다.

1. 자체 코드 수정 — ⚙ 수정 PR 생성

대상: 애플리케이션 발견 사항 — 귀사의 코드의 결함(예: 취약한 접근 제어, 인젝션):

1. 완료된 스캔을 열고 다음을 클릭하세요: ⚙ 수정 PR 생성 (상단 행).
2. 각 발견 사항의 원인이 되는 코드를 찾아 최소한의 수정을 작성한 뒤, 귀사 리포지토리에 초안 풀 리퀘스트를 엽니다.
3. 클릭: ↗ 수정 PR 보기 — GitHub에서 검토하세요.
4. 수정안이 마음에 들지 않나요? 다음을 클릭한 뒤 ↻ 재생성 — 변경하거나 유지할 내용을 알려 주세요(예: "기존 세션 검사는 그대로 유지"). 그러면 귀사의 지침을 반영해 다시 시도하고 같은 PR을 업데이트합니다 — 중복 PR은 생기지 않습니다.

2. 취약한 라이브러리 수정 — ⬆ 의존성 업데이트

대상: 종속성 발견 사항 — 앱이 의존하는 서드파티 라이브러리의 알려진 CVE:

1. 클릭: ⬆ 의존성 업데이트 (상단 행).
2. 취약한 각 패키지를 패치된 버전으로 올립니다 — 편집 가능한 매니페스트(requirements.txt, package.json)에서 수정하고 초안 PR을 엽니다.
3. 취약한 버전이 고정된 잠금 파일 (package-lock.json, poetry.lock, uv.lock)은 수작업으로 안전하게 수정할 수 없습니다 — PR에 각 항목과 실행할 정확한 명령이 나열됩니다(예: npm install [email protected]).
4. 변경 사항을 검토하고, 나열된 잠금 파일 명령을 실행한 뒤 병합하세요.

가이드: 모든 풀 리퀘스트에서 스캔하기

Starter 요금제 이상에서는 AI 표면을 건드리는 각 풀 리퀘스트마다 범위가 지정된 스캔이 실행되며, 입증된 신규 취약점이 있으면 병합을 차단합니다. 반복되는 발견 사항은 중복 제거되므로, 실제 문제가 나타날 때까지 파이프라인은 조용히 유지됩니다. Starter 요금제 이상에서는 확인된 발견 사항에 대해 초안 수정 풀 리퀘스트(및 종속성 업데이트 PR)를 열어 엔지니어가 검토하게 할 수도 있습니다 — 저절로 병합되는 것은 없습니다. 검토 상태는 다음에서 확인할 수 있습니다: GET /api/pr-reviews.

가이드: GitHub Action으로 스캔하기

저희가 공개한 GitHub Action으로 어떤 파이프라인에든 스캔을 연결할 수 있습니다. 푸시할 때 스캔하여 빌드를 차단하거나, 알림만 보낼 수도 있습니다.

GitHub Marketplace에서 설치 →

1. 트리거 키를 받으세요. 먼저 지속 보기에서 자산을 열고 다음을 클릭하세요: CI — 자산별 트리거 키와 자산 ID가 표시됩니다. 이 키는 해당 자산 하나로 범위가 제한되어, 그 자산의 스캔을 시작하고 읽을 수 있을 뿐 계정 전체에는 접근할 수 없습니다.
2. 리포지토리 시크릿으로 저장하세요 — 이름: REDTHREAD_SCAN_KEY.
3. 워크플로를 추가하세요 — 위치: .github/workflows/security.yml:

name: security
on: [push]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: bl014h/redthread-scan-action@v1
        with:
          api-key: ${{ secrets.REDTHREAD_SCAN_KEY }}
          asset-id: "abcd1234"
          fail-on: high   # critical | high | medium | low | never

fail-on: never 설정은 알림 전용입니다 — 스캔을 실행하고 작업 요약을 게시하지만 빌드를 실패시키지는 않습니다. 키는 같은 패널에서 언제든 교체할 수 있으며, 이전 키는 즉시 작동을 멈춥니다.

가이드: ChatGPT와 Claude에서 Redthread 사용

Redthread는 MCP 서버를 제공하므로 AI 어시스턴트에게 보안 상태를 평범한 말로 물어볼 수 있습니다. 지난 스캔 이후 무엇이 바뀌었는지, 어떤 공격 경로가 입증되었는지, 아무도 검토하지 않은 AI 서비스는 무엇인지. ChatGPT, Claude, 그리고 OAuth를 지원하는 원격 MCP 서버를 쓸 수 있는 모든 클라이언트에서 작동합니다.

1. 서버를 추가하세요. 주소는 https://app.redthreadsec.com/mcp입니다. Claude에서는 Settings → Connectors → Add custom connector을(를) 여세요. ChatGPT에서는 Settings → Apps & Connectors 을(를) 열고 커넥터를 만드세요(개발자 모드 필요).
2. 로그인하고 허용하세요. 어시스턴트가 Redthread 페이지를 엽니다. 로그인하고 워크스페이스를 확인한 뒤 다음을 클릭하세요: 허용.
3. 질문하세요. 예: “가장 심각한 공격 경로는?” 또는 “checkout API의 마지막 스캔 결과를 보여줘.”

어시스턴트는 보안 개요, 공격 경로, 스캔 결과, 섀도 AI 목록을 읽고, Redthread의 서명된 레지스트리 스캔으로 MCP 서버를 확인하며, 이미 연결된 클라우드의 읽기 전용 재스캔을 시작할 수 있습니다. 새 클라우드 연결, 설정 변경, 키 조회, 삭제는 할 수 없습니다.

가이드: 스캔에 대해 질문하기

발견 사항의 의미나 귀사 스택에서의 수정 방법이 궁금하신가요? 질문하세요. POST /api/chat 엔드포인트는 메시지 목록과 선택 사항인 run_id 값을 받으므로, 답변이 해당 스캔의 발견 사항에 근거합니다. 보고서를 수정 계획으로 바꾸는 데 활용하세요.

요금제, 할당량 & 초과 사용

요금제는 귀사의 환경과 사용량에 맞춰 견적을 드립니다 — 견적 요청 (요금제 페이지). 요금제의 할당량과 한도는 앱의 다음 메뉴에 표시됩니다: 결제.

• 스캔이란? 하나의 대상에 대한 1회 실행입니다. 풀 리퀘스트 검사와 전체 스캔은 각각 1회로 계산됩니다.
• 모의 침투 스캔. 모든 유료 요금제에는 워크로드 10개당 매월 1회의 모의 침투 스캔이 포함됩니다(올림, Starter 3회, Growth 15회). 환경이 클수록 더 많이 제공됩니다. 그 이상의 스캔은 선불 스캔 팩(5회 또는 20회, 12개월 유효)을 사용하거나, 카드가 등록되어 있으면 스캔당 청구됩니다.
• 무료 티어. 평생 1회의 모의 침투 스캔(초기화되지 않음)으로 결정하기 전에 실제 발견 사항을 확인할 수 있습니다. 작동하는 익스플로잇과 자동 수정은 모든 유료 요금제에서 제공됩니다.

기존 고객은 앱에서 또는 다음 API로 요금제를 변경할 수 있습니다: POST /api/billing/checkout. 신규 요금제는 문의하세요.

개발 단계

이 섹션은 고객이 앱에서 볼 수 있습니다: 로그인 한 뒤 아무 문서 링크나 여세요.

API 레퍼런스

이 섹션은 고객이 앱에서 볼 수 있습니다: 로그인 한 뒤 아무 문서 링크나 여세요.