মূল কনটেন্টে যান
এআই টিউটোরিয়াল

sapper-v2 দিয়ে একটি স্বয়ংক্রিয় পেনটেস্টিং লিজিয়ন তৈরি ও পরিচালনা করুন

এই টিউটোরিয়ালে sapper-v2 পরিচয় করিয়ে দেওয়া হয়েছে, যা অনুমোদিত পেনিট্রেশন টেস্টিংয়ের জন্য একটি সহযোগিতামূলক AI ফ্রেমওয়ার্ক। এর কমান্ডার, বিশেষজ্ঞ এজেন্ট, ওয়াচডগ এবং স্তরভিত্তিক ফ্যাক্ট গ্রাফ কীভাবে একসঙ্গে কাজ করে তা শিখবেন। এরপর CLI ইনস্টল করবেন, একটি অ্যাসেসমেন্ট শুরু করবেন, অগ্রগতি পর্যালোচনা করবেন, Docker-ভিত্তিক লিজিয়ন ডিপ্লয় করবেন এবং এর কার্যপরিচালন নীতিগুলো দায়িত্বশীলভাবে প্রয়োগ করবেন।

sapper-v2 দিয়ে স্বয়ংক্রিয় পেনটেস্টিং লিজিয়ন তৈরি ও পরিচালনা

sapper-v2 কী?

sapper-v2 হলো অনুমোদিত পেনিট্রেশন টেস্টিং-এর জন্য তৈরি একটি স্বয়ংক্রিয়, বহুসংখ্যক-এজেন্ট সিস্টেম। ক্রমশ জটিল হয়ে ওঠা একটি এজেন্টের ওপর নির্ভর করার বদলে, এটি একাধিক AI-কে একটি লিজিয়নে সংগঠিত করে, যা কাজ ভাগ করে, আবিষ্কারগুলো পরস্পরের সঙ্গে আদান-প্রদান করে এবং এজেন্ট বদল হলেও জ্ঞান সংরক্ষণ করে।

প্রকল্পটি তৃতীয় Tencent Cloud Intelligent Attack-Defense Challenge-এর অনলাইন কোয়ালিফায়ারে বিজয়ী হয় এবং GeekCon 2026 AI Challenge-এ প্রথম পুরস্কার পায়। Tencent-এর ইভেন্টে এটি আট ঘণ্টার একটি তত্ত্বাবধানহীন রান সম্পন্ন করে 80.18 স্কোর অর্জন করে, প্রায় এক বিলিয়ন টোকেন ব্যবহার করে 85টি ফ্ল্যাগ খুঁজে পায়।

sapper-v2 কেবল নিজের মালিকানাধীন বা পরীক্ষা করার স্পষ্ট অনুমতি রয়েছে এমন সিস্টেমে ব্যবহার করুন। ইনস্টলেশন বা পরিচালনার আগে DISCLAIMER.md পর্যালোচনা করুন।

সিস্টেমটি যেভাবে কাজ করে

প্রকল্পটি তিনটি মৌলিক সক্ষমতার ওপর নির্মিত:

  • Create: সিস্টেমটি tmux-এ নতুন AI সেশন খোলে, ফলে কাজের প্রয়োজন অনুযায়ী বিশেষজ্ঞ কর্মী তৈরি করতে পারে।
  • Language: এজেন্টরা একে অপরের ইনপুট সেশনে বার্তা প্রবেশ করিয়ে যোগাযোগ করে।
  • History: আবিষ্কারগুলো কোনো একটি এজেন্টের কনটেক্সটে আটকে না থেকে স্তরভিত্তিক fact-intent গ্রাফে সংরক্ষিত হয়।

হিস্ট্রি সিস্টেমটির তিনটি স্তর রয়েছে: title, summary এবং evidence document। এজেন্টরা প্রথমে সংক্ষিপ্ত টাইটেল পড়তে পারে, আরও প্রেক্ষাপট প্রয়োজন হলে সারাংশ পরিদর্শন করতে পারে এবং বিস্তারিত যাচাইয়ের জন্য প্রমাণপত্র খুলতে পারে। এই নকশা কনটেক্সট ব্যবহার কমায় এবং ভুল তথ্যের ক্ষতি সীমিত করে।

রানটাইমের ভূমিকা

রানটাইমে sapper-v2 সমন্বয়, কার্যসম্পাদন এবং প্রাপ্যতাকে আলাদা রাখে:

  • Commander: বোর্ড পড়ে, লক্ষ্য মূল্যায়ন করে এবং কাজ বণ্টন করে। এটি নিজে আক্রমণ চালায় না।
  • Generals: কঠিন আক্রমণ পরিচালনা করে এবং নিজেদের স্কোয়াড নিয়োগ করতে পারে।
  • Scouts: স্বল্পমেয়াদি রিকনেসান্স পরিচালনা করে এবং কোনো লক্ষ্যে ব্যাপক এক্সিকিউশন নাকি গভীর তদন্ত প্রয়োজন তা নির্ধারণে সহায়তা করে।
  • Soldiers: নির্ধারিত কাজগুলো সমান্তরালভাবে সম্পন্ন করে।
  • Signalman: একটি স্থান থেকে রিপোর্ট না করা ফ্ল্যাগ সংগ্রহ ও জমা দেয়। এই ভূমিকা আগে থেকে কোড করা ছিল না; পরিচালনার সময় এটি উদ্ভূত হয়।
  • Watchdog: কৌশলমুক্ত একটি স্ক্রিপ্ট, যা --continue ব্যবহার করে ক্র্যাশ করা কমান্ডার পুনরায় চালু করে, কী পরিবর্তন করে এবং রান শেষের কার্যক্রম পরিচালনা করে সিস্টেম সচল রাখে।

README-তে তিনটি দৃশ্যমান রানটাইম উইন্ডোর কথা বলা হয়েছে: কমান্ডার, tmux প্যানগুলোতে চলা AI লিজিয়ন এবং watchdog।

প্রধান বৈশিষ্ট্য

  • সমান্তরাল কাজের বিভাজন: Scout, soldier, general এবং commander পৃথক দায়িত্ব নিয়ে কাজ করে।
  • স্থায়ী সাংগঠনিক স্মৃতি: কোনো পৃথক এজেন্ট বদলালেও জ্ঞান টিকে থাকে।
  • কনটেক্সট রোটেশন: যেসব এজেন্টের কনটেক্সট পূর্ণ হয়ে যায়, তারা উত্তরসূরিদের জন্য লিখিত শিক্ষা রেখে যেতে পারে।
  • মডেল স্তরবিন্যাস: প্রতিযোগিতার কনফিগারেশনে commander ও general-এর জন্য GLM-5.3 এবং scout ও soldier-এর জন্য DeepSeek V4.1 Flash ব্যবহার করা হয়েছে।
  • অপারেশনাল স্থিতিস্থাপকতা: watchdog কৌশলগত সিদ্ধান্ত না নিয়েই commander পুনরায় চালু করতে, কী পরিবর্তন করতে এবং ধারাবাহিকতা বজায় রাখতে পারে।
  • চ্যালেঞ্জের মধ্যে স্থানান্তর: commander কাঠামোগতভাবে একই ধরনের challenge family শনাক্ত করতে পারে এবং সফল playbook নতুনভাবে নিয়োগ করা এজেন্টদের দিতে পারে।
  • Fact-intent CLI: প্রকল্পটি তার গ্রাফ পরিচালনা এবং একাধিক challenge-এর workflow চালানোর জন্য কমান্ড ও নির্দেশনা দেয়।

sapper CLI ইনস্টল করুন

দ্রুত-শুরুর ইনস্টলারটি sapper CLI-কে নির্দিষ্ট স্থানে লিংক করে। README অনুযায়ী, CLI কেবল standard library ব্যবহার করে এবং এর কোনো অতিরিক্ত dependency নেই।

রিপোজিটরির root থেকে চালান:

bash install.sh

README-তে অতিরিক্ত কোনো স্থানীয় prerequisite বা প্ল্যাটফর্ম-নির্দিষ্ট ইনস্টলেশন ধাপের তালিকা নেই। কমান্ডটি আপনার shell-এ sapper উপলভ্য না করলে, install.sh পরিদর্শন করুন এবং নিশ্চিত করুন যে symlink-এর destination আপনার executable path-এর অন্তর্ভুক্ত।

অনুমোদিত অ্যাসেসমেন্ট শুরু করুন

sapper setup দিয়ে একটি নতুন অ্যাসেসমেন্ট তৈরি করুন। নিচের উদাহরণটি প্রকল্পের quick start থেকে নেওয়া:

sapper setup --goal "assess http://target" --agents

http://target-এর পরিবর্তে কেবল আপনার লিখিত অনুমোদনের আওতাভুক্ত কোনো endpoint ব্যবহার করুন। লক্ষ্যটি অনুমোদিত scope স্পষ্টভাবে বর্ণনা করবে, যাতে এজেন্টরা দ্ব্যর্থহীন মিশন পায়।

--agents অপশনটি প্রকল্পে প্রদর্শিত agent-oriented workflow শুরু করে। সেটআপের পর বোর্ড এবং বর্তমান frontier পরিদর্শন করুন:

sapper status

কাজের অগ্রগতি যাচাই করার জন্য status view হলো quick start-এর প্রধান কমান্ড। commander বোর্ড ব্যবহার করে লক্ষ্য মূল্যায়ন ও বিশেষজ্ঞদের কাজ বণ্টন করে; সরাসরি অ্যাসেসমেন্টের কাজ সম্পন্ন করে না।

একটি ন্যূনতম CLI workflow

  1. অনুমোদন যাচাই করুন: টুলের বাইরে লক্ষ্য, সময়সীমা, অনুমোদিত কৌশল এবং থামার শর্ত নথিবদ্ধ করুন।
  2. CLI ইনস্টল করুন: ক্লোন করা রিপোজিটরি থেকে bash install.sh চালান।
  3. লক্ষ্য নির্ধারণ করুন: অনুমোদিত target-সহ sapper setup --goal "assess http://target" --agents চালান।
  4. বোর্ড পর্যবেক্ষণ করুন: বোর্ড এবং frontier পর্যালোচনা করতে sapper status চালান।
  5. সংরক্ষিত জ্ঞান পর্যালোচনা করুন: একক-গ্রাফ অপারেশন বা একাধিক challenge-এর sweep প্রয়োজন হলে SKILL.md-তে নথিবদ্ধ fact-intent workflow ব্যবহার করুন।

Docker দিয়ে সম্পূর্ণ লিজিয়ন চালান

রিপোজিটরিতে commander-ভিত্তিক পূর্ণ legion-এর জন্য একটি Dockerfile রয়েছে। রিপোজিটরির root থেকে image তৈরি করুন:

docker build -f docker/Dockerfile.commander -t sapper:latest .

কনটেইনার চালু করার আগে docker/ENV.md-এ বর্ণিত model gateway, key pool এবং budget environment variable কনফিগার করুন। এই সেটিংগুলো গুরুত্বপূর্ণ, কারণ architecture-এ বিভিন্ন model tier-কে বিভিন্ন দায়িত্ব দেওয়া হয়েছে এবং এতে key rotation ও budget-সচেতন পরিচালনা রয়েছে।

README-তে কনটেইনার চালুর বিষয়টি সংক্ষিপ্ত কাঠামোগত রূপে দেখানো হয়েছে:

docker run -d --name sapper ... sapper:latest

Ellipsis-টি সরাসরি চালানোর মতো কোনো literal argument নয়। রিপোজিটরির environment documentation থেকে প্রয়োজনীয় environment variable এবং অন্যান্য Docker option দিয়ে এটি প্রতিস্থাপন করুন। Production credential অনুমান করবেন না এবং নিরাপদ secret-management পদ্ধতি উপলভ্য থাকলে secret সরাসরি shell history-তে রাখবেন না।

Commander-এর নীতি বুঝুন

Commander-এর operational doctrine docker/commander/SKILL.md-এ সংরক্ষিত আছে। README-তে কয়েকটি নীতি তুলে ধরা হয়েছে:

  • সহজ কাজ আগে, সমান্তরাল scheduling: কাজ এমনভাবে বণ্টন করুন যাতে সমাধানযোগ্য target-গুলো একসঙ্গে সমাধান করা যায়, পুরো legion-কে একটি কঠিন পথের মধ্য দিয়ে চালাতে না হয়।
  • Bottleneck সময়ে salvage: কোনো operation-এর শেষদিকে আংশিকভাবে সমাধান হওয়া target-গুলো আবার পর্যালোচনা করুন, কারণ বিদ্যমান evidence থেকে দ্রুত ফল পাওয়া যেতে পারে।
  • Stop-loss discipline: যে কাজে অগ্রগতি হচ্ছে না, তাতে সীমাহীন সময় বা token ব্যয় করা এড়িয়ে চলুন।
  • ভূমিকা পৃথকীকরণ: সরাসরি execution-এর বদলে board পড়া, বিচার-বিবেচনা এবং dispatch-এর জন্য commander-এর মনোযোগ সংরক্ষণ করুন।

Formal architecture contract-এর জন্য docker/commander/SPEC.md পড়ুন। প্রতিযোগিতার সময় system কীভাবে কাজ করেছিল, সেই retrospective-এর জন্য BATTLE-REPORT.md দেখুন।

উন্নত পরিচালনামূলক পরামর্শ

অনুমোদিত scope-এর সঙ্গে সামঞ্জস্যপূর্ণ goal লিখুন

Setup goal-ই agent-দের কাজের লক্ষ্য নির্ধারণ করে। অনুমোদিত target সুনির্দিষ্টভাবে উল্লেখ করুন এবং এমন বিস্তৃত ভাষা এড়িয়ে চলুন যা unrelated host বা service অনুসন্ধানের অনুমতি হিসেবে ব্যাখ্যা করা যেতে পারে। External authorization document-ই সত্যতার মূল উৎস হিসেবে বিবেচিত হবে।

বড় summary-এর বদলে স্তরভিত্তিক evidence ব্যবহার করুন

উচ্চ-স্তরের তথ্য সংক্ষিপ্ত রাখুন, তবে তার নিচে বিস্তারিত evidence সংরক্ষণ করুন। Title-এ মূল বক্তব্য জানানো উচিত, summary-তে প্রাসঙ্গিকতা ব্যাখ্যা করা উচিত, এবং evidence document-এ verification-এর ভিত্তি থাকা উচিত। এটি sapper-v2-এর design অনুসরণ করে এবং agent context-এ বারবার সব detail load করার প্রয়োজন কমায়।

Agent rotation-এর সময় শিক্ষাগুলো সংরক্ষণ করুন

Project-টি campaign চলাকালে soldier context saturation প্রায় 260,000 token হিসেবে পরিমাপ করেছিল। এর প্রতিক্রিয়া ছিল successor-এর জন্য একটি playbook রেখে worker-কে recycle করা। Operation output পর্যালোচনার সময় verified finding, চেষ্টা করা পদ্ধতি, অমীমাংসিত প্রশ্ন এবং পুনর্ব্যবহারযোগ্য procedure-সহ স্পষ্ট handover note-কে অগ্রাধিকার দিন।

Strategy এবং availability পৃথক রাখুন

Watchdog-এর ইচ্ছাকৃতভাবে কোনো strategic role নেই। Recovery behavior, key rotation এবং process restart-কে target ও tactic-সংক্রান্ত সিদ্ধান্ত থেকে পৃথক রাখুন। এতে কোনো action commander-এর কাছ থেকে এসেছে, নাকি keep-alive automation থেকে এসেছে, তা বোঝা সহজ হয়।

Token এবং model cost নিয়ন্ত্রণ করুন

sapper-v2-এর competition architecture উচ্চ-স্তরের decision-making-এর জন্য শক্তিশালী model এবং high-volume reconnaissance ও execution-এর জন্য হালকা model নির্ধারণ করেছিল। Documented configuration পুনরুৎপাদন করলে Docker environment guidance-এর মাধ্যমে gateway, key pool এবং budget সেট করুন এবং অনুমোদিত run জুড়ে consumption পর্যবেক্ষণ করুন।

স্থানান্তরিত জ্ঞান বিশ্বাস করার আগে evidence পরীক্ষা করুন

Target-গুলোর কাঠামো মিললে cross-challenge transfer কাজ দ্রুত করতে পারে, তবে সাদৃশ্য verification-এর বিকল্প নয়। অন্য challenge-এ উত্তরাধিকারসূত্রে পাওয়া playbook প্রয়োগের আগে layered graph ব্যবহার করে summary এবং supporting evidence পরীক্ষা করুন।

নিরাপত্তা ও দায়িত্বশীল ব্যবহার

sapper-v2 একটি offensive security tool এবং unauthorized access-এর জন্য এটি ব্যবহার করা যাবে না। এর README-তে স্পষ্টভাবে সতর্ক করা হয়েছে যে AI offensive tooling-এর কারণে সৃষ্ট ক্ষতি বাড়িয়ে দিতে পারে। প্রযোজ্য আইন মেনে চলুন, স্পষ্ট অনুমতি নিন, target scope সীমাবদ্ধ রাখুন, budget ও stop condition নির্ধারণ করুন এবং environment অনুযায়ী উপযুক্ত human oversight বজায় রাখুন।

Project-টি ভবিষ্যতের একটি taggant mechanism-এর প্রস্তাবও দেয়: offensive harness-এর সঙ্গে যুক্ত এমন marking, যা illegal intrusion চলাকালে victim-এর কাছে শনাক্তকারী তথ্য ফাঁস করতে এবং attribution-এ সহায়তা করতে পারে। README-তে এটিকে cryptographic ও community design প্রয়োজন এমন একটি proposal হিসেবে উপস্থাপন করা হয়েছে, ব্যবহারকারীরা আজ নির্ভর করতে পারেন এমন বিদ্যমান protection হিসেবে নয়।

উপসংহার

sapper-v2 autonomous security assessment-এর জন্য একটি সমন্বিত পদ্ধতি প্রদর্শন করে: commander কাজ অর্পণ করে, specialist-রা সমান্তরালে কাজ করে, watchdog ধারাবাহিকতা বজায় রাখে এবং layered fact graph সাংগঠনিক জ্ঞান সংরক্ষণ করে। Lightweight CLI দিয়ে শুরু করুন, sapper status ব্যবহার করে board পর্যবেক্ষণ করুন এবং পূর্ণ legion প্রয়োজন হলে Docker setup ব্যবহার করুন। প্রতিটি run-কে explicit authorization এবং project-এর disclaimer-এর সীমার মধ্যে রাখুন।