چگونه یک عامل LangGraph برای اولویت‌بندی آسیب‌پذیری‌های GitOps ساختیم

در محیط‌های پیچیده Kubernetes امروزی، مدیریت و اولویت‌بندی آسیب‌پذیری‌ها می‌تواند به سرعت طاقت‌فرسا شود. با ده‌ها یا حتی صدها کانتینر که در سراسر سرویس‌های مختلف اجرا می‌شوند، چگونه تصمیم می‌گیرید که به کدام آسیب‌پذیری‌ها ابتدا رسیدگی کنید؟

اینجاست که هوش مصنوعی می‌تواند کمک کند، و در این مقاله تجربه خود را در ساخت HAIstings، یک اولویت‌بندی‌کننده آسیب‌پذیری مبتنی بر هوش مصنوعی، با استفاده از LangGraph و LangChain، با امنیت تقویت‌شده توسط CodeGate، یک درگاه هوش مصنوعی متن‌باز توسعه‌یافته توسط Stacklok، به اشتراک خواهیم گذاشت.

اگر تا به حال یک اسکنر آسیب‌پذیری مانند Trivy را در برابر کلاستر Kubernetes خود اجرا کرده باشید، این حس را می‌دانید: صدها یا هزاران آسیب‌پذیری و مواجهه مشترک (CVE) در سراسر ده‌ها تصویر، با زمان و منابع محدود برای رسیدگی به آنها. به کدام یک باید ابتدا رسیدگی کنید؟

رویکرد سنتی متکی به امتیازات شدت (به عنوان مثال، بحرانی، بالا، متوسط، کم) است، اما این امتیازات زمینه زیرساخت خاص شما را در نظر نمی‌گیرند. به عنوان مثال، یک آسیب‌پذیری بالا در یک سرویس داخلی و غیربحرانی ممکن است کمتر از یک آسیب‌پذیری متوسط در یک مؤلفه رو به اینترنت فوری باشد.

ما می‌خواستیم ببینیم آیا می‌توانیم از هوش مصنوعی برای کمک به حل این مشکل اولویت‌بندی استفاده کنیم یا خیر. با الهام از آرتور هستینگز، دستیار دقیق هرکول پوآرو، کارآگاه آگاتا کریستی، HAIstings را ساختیم تا به تیم‌های زیرساخت کمک کند تا آسیب‌پذیری‌ها را بر اساس موارد زیر اولویت‌بندی کنند:

1. شدت (بحرانی/بالا/متوسط/کم).
2. زمینه زیرساخت (از مخازن GitOps).
3. دیدگاه‌های ارائه شده توسط کاربر در مورد اهمیت مؤلفه.
4. درک در حال تکامل از طریق گفتگو.

LangGraph، که بر روی LangChain ساخته شده است، یک چارچوب عالی برای ایجاد عوامل هوش مصنوعی مکالمه‌ای با حافظه فراهم می‌کند. در اینجا نحوه ساختاردهی HAIstings آورده شده است:

1. مؤلفه‌های اصلی

مؤلفه‌های اصلی HAIstings عبارتند از:

• k8sreport: به Kubernetes متصل می‌شود تا گزارش‌های آسیب‌پذیری را از trivy-operator جمع‌آوری کند.
• repo_ingest: فایل‌های مخزن زیرساخت را برای ارائه زمینه، وارد می‌کند.
• vector_db: فایل‌های مرتبط را با استفاده از جاسازی‌های برداری ذخیره و بازیابی می‌کند.
• memory: تاریخچه مکالمه را در سراسر جلسات حفظ می‌کند.

2. جریان مکالمه

HAIstings از یک ماشین حالت LangGraph با جریان زیر استفاده می‌کند:

graph_builder = StateGraph(State)
# Nodes
graph_builder.add_node("retrieve", retrieve)  # Get vulnerability data
graph_builder.add_node("generate_initial", generate_initial)  # Create initial report
graph_builder.add_node("extra_userinput", extra_userinput)  # Get more context

# Edges
graph_builder.add_edge(START, "retrieve")
graph_builder.add_edge("retrieve", "generate_initial")
graph_builder.add_edge("generate_initial", "extra_userinput")
graph_builder.add_conditional_edges("extra_userinput", needs_more_info, ["extra_userinput", END])

این یک حلقه ایجاد می‌کند که در آن HAIstings:

1. داده‌های آسیب‌پذیری را بازیابی می‌کند.
2. یک گزارش اولیه تولید می‌کند.
3. درخواست زمینه اضافی می‌کند.
4. ارزیابی خود را بر اساس اطلاعات جدید اصلاح می‌کند.

3. RAG برای زمینه مرتبط

یکی از چالش‌ها، بازیابی کارآمد تنها فایل‌های مرتبط از مخازن GitOps بالقوه بزرگ بود. ما یک رویکرد تولید تقویت‌شده با بازیابی (RAG) را پیاده‌سازی کردیم:

def retrieve_relevant_files(repo_url: str, query: str, k: int = 5) -> List[Dict]:
    """Retrieve relevant files from the vector database based on a query."""
    vector_db = VectorDatabase()
    documents = vector_db.similarity_search(query, k=k)
    
    results = []
    for doc in documents:
        results.append({
            "path": doc.metadata["path"],
            "content": doc.page_content,
            "is_kubernetes": doc.metadata.get("is_kubernetes", False),
        })
    
    return results

این اطمینان می‌دهد که فقط مرتبط‌ترین فایل‌ها برای هر مؤلفه آسیب‌پذیر در زمینه گنجانده شده‌اند، و اندازه اعلان را قابل مدیریت نگه می‌دارد.

هنگام کار با LLMها و داده‌های زیرساخت، امنیت از اهمیت بالایی برخوردار است. گزارش‌های آسیب‌پذیری و فایل‌های زیرساختی که ما تجزیه و تحلیل می‌کنیم می‌توانند حاوی اطلاعات حساسی مانند موارد زیر باشند:

• جزئیات پیکربندی.
• مکانیسم‌های احراز هویت.
• اعتبارهای به طور بالقوه لو رفته در فایل‌های زیرساخت.

اینجاست که پروژه متن‌باز CodeGate ضروری می‌شود. CodeGate به عنوان یک لایه محافظ بین HAIstings و ارائه‌دهنده LLM عمل می‌کند و محافظت‌های حیاتی را ارائه می‌دهد:

1. ویرایش اسرار

CodeGate به طور خودکار اسراری مانند کلیدهای API، توکن‌ها و اعتبارات را از اعلان‌های شما قبل از رسیدن به مدل زبانی بزرگ (LLM) شناسایی و ویرایش می‌کند. این از نشت تصادفی داده‌های حساس به سرویس‌های ابری شخص ثالث جلوگیری می‌کند.

به عنوان مثال، اگر مانیفست Kubernetes یا مخزن GitOps شما حاوی موارد زیر باشد:

apiVersion: v1
kind: Secret
metadata:
  name: database-credentials
type: Opaque
data:
  username: YWRtaW4=  # "admin" in base64
  password: c3VwZXJzZWNyZXQ=  # "supersecret" in base64

CodeGate این مقادیر را از اعلان‌ها قبل از رسیدن به LLM ویرایش می‌کند؛ سپس آنها را به طور یکپارچه در پاسخ‌ها از حالت ویرایش خارج می‌کند.

ممکن است بگویید، "صبر کنید. ما به مواردی مانند ExternalSecretsOperator برای گنجاندن اسرار Kubernetes تکیه می‌کنیم، بنابراین ما در امان هستیم... درست است؟"

خب، ممکن است در حال آزمایش یک کلاستر باشید و یک توکن در یک فایل در مخزن محلی خود یا در فهرست کاری فعلی خود ذخیره شده باشد. یک عامل ممکن است کمی بیش از حد بلندپرواز باشد و به طور تصادفی آن را به زمینه شما اضافه کند، همانطور که اغلب در ویرایشگرهای کد دیده‌ایم. اینجاست که CodeGate وارد عمل می‌شود و اطلاعات حساس را قبل از به اشتراک گذاشته شدن ناخواسته ویرایش می‌کند.

2. ویرایش PII

فراتر از اسرار، CodeGate همچنین اطلاعات شناسایی شخصی (PII) را که ممکن است در فایل‌های زیرساخت یا مانیفست‌های استقرار شما وجود داشته باشد، شناسایی و ویرایش می‌کند.

3. دسترسی کنترل شده به مدل

CodeGate شامل قابلیت‌های چندگانه سازی مدل (muxing) است که به اطمینان از اینکه اطلاعات آسیب‌پذیری زیرساخت فقط به مدل‌های تأیید شده و مورد اعتماد با اقدامات امنیتی مناسب می‌رود، کمک می‌کند.

Muxing مدل به شما امکان می‌دهد قوانینی ایجاد کنید که انواع فایل خاص، پروژه‌ها یا الگوهای کد را به مدل‌های هوش مصنوعی مختلف هدایت می‌کند. به عنوان مثال، ممکن است بخواهید کد زیرساخت توسط یک مدل خصوصی میزبانی شده به صورت محلی مدیریت شود، در حالی که کد برنامه عمومی می‌تواند توسط مدل‌های مبتنی بر ابر پردازش شود.

Muxing مدل امکانات زیر را فراهم می‌کند:

• کنترل حساسیت داده‌ها: کد حساس (مانند ماژول‌های زیرساخت، امنیتی یا احراز هویت) را به مدل‌هایی با ضمانت‌های حفظ حریم خصوصی سختگیرانه‌تر هدایت کنید.
• الزامات انطباق: با اطمینان از اینکه انواع کد خاص هرگز محیط شما را ترک نمی‌کنند، نیازهای نظارتی را برآورده کنید.
• بهینه‌سازی هزینه: از مدل‌های گران قیمت و قدرتمند فقط برای بخش‌های کد حیاتی استفاده کنید.
• تنظیم عملکرد: پیچیدگی کد را با مناسب‌ترین قابلیت‌های مدل مطابقت دهید.

در اینجا یک مثال از استراتژی muxing مدل با یک مخزن زیرساخت آورده شده است:

• قانون: *.tf، *.yaml یا *-infra.* می‌توانند به یک مدل Ollama میزبانی شده به صورت محلی mux شوند.
• مزیت: فایل‌های Terraform و YAML زیرساخت هرگز محیط شما را ترک نمی‌کنند، و از نشت احتمالی اسرار، آدرس‌های IP یا طراحی زیرساخت جلوگیری می‌کنند.

4. تاریخچه قابل ردیابی

CodeGate یک رکورد مرکزی از تمام تعاملات با مدل‌های هوش مصنوعی را حفظ می‌کند، و یک مسیر حسابرسی از تمام ارزیابی‌ها و توصیه‌های آسیب‌پذیری ایجاد می‌کند.

راه‌اندازی HAIstings برای کار با CodeGate ساده است. پیکربندی LangChain را در HAIstings به روز کنید:

# HAIstings configuration for using CodeGate
self.llm = init_chat_model(
    # Using CodeGate's Muxing feature
    model="gpt-4o",  # This will be routed appropriately by CodeGate
    model_provider="openai",
    # API key not needed as it's handled by CodeGate
    api_key="fake-api-key",
    # CodeGate Muxing API URL
    base_url="http://127.0.0.1:8989/v1/mux",
)

با کارکرد HAIstings و CodeGate در کنار هم، سیستم حاصل، اولویت‌بندی آسیب‌پذیری هوشمند و آگاه از زمینه را در حین حفظ کنترل‌های امنیتی سختگیرانه ارائه می‌دهد.

یک گزارش نمونه از HAIstings ممکن است به این شکل باشد:

# HAIsting's Security Report

## Introduction

Good day! Arthur Hastings at your service. I've meticulously examined the vulnerability reports from your Kubernetes infrastructure and prepared a prioritized assessment of the security concerns that require your immediate attention.

## Summary

After careful analysis, I've identified several critical vulnerabilities that demand prompt remediation:

1. **example-service (internet-facing service)**
   - Critical vulnerabilities: 3
   - High vulnerabilities: 7
   - Most concerning: CVE-2023-1234 (Remote code execution)
   
   This service is particularly concerning due to its internet-facing nature, as mentioned in your notes. I recommend addressing these vulnerabilities with the utmost urgency.

2. **Flux (GitOps controller)**
   - Critical vulnerabilities: 2
   - High vulnerabilities: 5
   - Most concerning: CVE-2023-5678 (Git request processing vulnerability)
   
   As you've noted, Flux is critical to your infrastructure, and this Git request processing vulnerability aligns with your specific concerns.

## Conclusion

I say, these vulnerabilities require prompt attention, particularly the ones affecting your internet-facing services and deployment controllers. I recommend addressing the critical vulnerabilities in example-service and Flux as your top priorities.

تعاملات LLM به خودی خود کند هستند و نباید برای هشدارهای بی‌درنگ و حیاتی به آنها تکیه کنید. پروکسی کردن ترافیک LLM مقداری تأخیر به این ترکیب اضافه می‌کند. این قابل انتظار است زیرا اینها عملیات پرهزینه از نظر محاسباتی هستند. با این حال، ما معتقدیم که مزایای امنیتی ارزشش را دارد. شما چند ثانیه اضافی زمان پردازش را با اولویت‌بندی آسیب‌پذیری بسیار بهتر که متناسب با نیازهای زیرساخت خاص شما است، معامله می‌کنید.

ساخت HAIstings با LangGraph و LangChain نشان داده است که چگونه هوش مصنوعی می‌تواند به حل مشکل اولویت‌بندی آسیب‌پذیری در زیرساخت مدرن کمک کند. ترکیب با CodeGate تضمین می‌کند که این کمک هوش مصنوعی به قیمت امنیت تمام نمی‌شود. شما راهنمایی‌های هوشمندانه و آگاه از زمینه را بدون به خطر انداختن استانداردهای امنیتی دریافت می‌کنید، و تیم خود را آزاد می‌کنید تا بر رفع مهم‌ترین مسائل تمرکز کنند.

همانطور که زیرساخت پیچیده‌تر و آسیب‌پذیری‌ها بیشتر می‌شوند، ابزارهایی مانند HAIstings نشان‌دهنده آینده مدیریت امنیت زیرساخت هستند، و راهنمایی‌های هوشمندانه و آگاه از زمینه را در حین حفظ سخت‌ترین استانداردهای امنیتی ارائه می‌دهند.

شما می‌توانید HAIstings را با استفاده از کد در مخزن GitHub ما امتحان کنید.

آیا می‌خواهید ببینید که چگونه هوش مصنوعی می‌تواند به اولویت‌بندی آسیب‌پذیری‌ها در زیرساخت شما کمک کند؟ یا ایده‌های دیگری برای ترکیب هوش مصنوعی با مدیریت زیرساخت دارید؟ به انجمن Discord Stacklok بپیوندید و به گفتگو ادامه دهید.