الأسئلة الشائعة

لا، وهذا مقصود وليس قيدًا. فـ Docker Compose وSwarm ومضيفو SSH/WinRM والأهداف المعتمدة على السكربتات أهداف أساسية من الدرجة الأولى، لا بدائل احتياطية لمن لم يعتمد Kubernetes بعد.

الأهداف المدعومة: مشاريع Docker Compose ومضيفو SSH/WinRM. عمليات نشر SSH/WinRM بلا وكيل — إذ تنفذ صورة Docker العمل.

والعكس صحيح أيضًا: إذا كان كل ما تشغّله يعمل على Kubernetes، فليست Stella Ops أداتك. فهي مبنية للنصف الآخر من البنية — الأجهزة الافتراضية ومشاريع Compose والخوادم التقليدية — ومعظم الفرق تشغّل الاثنين معًا.

تُعرض بالحالة Missing (مفقودة). لا تُعدّ ناجحة، ولا يُفترض أنها سليمة، ولا تُتجاوز بصمت.

تحمل كل مرحلة من مراحل سلسلة العهدة إحدى ثلاث حالات — Missing أو Recorded أو Signed. والبوابة التي لا تجد الأدلة التي تحتاجها لا تعود افتراضيًا إلى النجاح؛ ولا تُحتسب حالة NOT EVALUATED نجاحًا أبدًا. معظم الأدوات تعامل غياب الأدلة على أنه غياب للمشكلة. أما هنا فالعكس تمامًا، وهذا ما يجعل لبقية الأدلة قيمة.

نعم. الكبسولة النموذجية أرشيف موقَّع حقيقي يمكنك فحصه بأدوات قياسية — cosign verify-blob مع sha256sum، دون الحاجة إلى Stella Ops إطلاقًا.

هذا التنزيل عينة منقّحة موقَّعة بمفتاح تجريبي، لذا لا تحمل أي ثقة تتجاوز ذاتها. أما stella evidence card verify وإعادة التشغيل الحتمية فتتطلبان تثبيتًا وكبسولة مُصدَّرة من المنتج — ولن تنجحا مع العينة.

نعم، ودون اتصال. يُعاد تشغيل الحكم على نحو حتمي من المدخلات المجمّدة التي أنتجته: قائمة SBOM نفسها، ولقطة التنبيهات نفسها، وإصدار السياسة نفسه.

هذا هو الفرق بين أداة تخبرك بالإجابة وأداة يمكن إلزامها بعرض طريقة وصولها إليها بعد أشهر، على جهاز بلا شبكة، أمام شخص لا يثق بك.

بعد النشر يواصل Stella المراقبة. المراقبة هي المرحلة الأخيرة في مسار العهدة (المصدر ← البناء ← الفحص ← الحكم ← القرار ← النشر ← المراقبة): فهي تقارن digest العامل فعليًا في كل بيئة بـ digest المعتمد لها.

عند اختلافهما تُرفع إشارة للخدمة: digest العامل ليس digest معتمدًا/منشورًا (صورة غير معتمدة أو معدلة). وترى بدقة الخدمة والبيئة اللتين انحرفتا عن الحالة المعتمدة.

الخدمة التي لا تتوفر لدى Watch أدلة عنها تُبلّغ Missing — ولا تُعرض أبدًا على أنها مطابقة لمجرد افتراض أن شيئًا لم يتغير.

اطلع على عرض Estate →

نعم، ويُفرض ذلك داخل المنتج بدل أن يُترك لشبكتك. يمنع الوضع المختوم (EgressPolicyMode.Sealed) الاتصالات الصادرة؛ ويُدخل stella offline import --bundle حزمة موقّعة؛ ويفحص stella evidence verify-offline المجاميع الاختبارية والبيان وربط DSSE وتغطية مقاطع Rekor (tiles) دون أي اتصال بالشبكة، ويفشل مغلقًا عند أي عبث.

تجمع Offline Kit تغذيات الثغرات وصور الحاويات وبيانات المنشأ (provenance). وتحصل على نتائج فحص متطابقة سواء كنت متصلًا أو في شبكة سيادية.

اطلع على Offline Kit →

تُبنى رسوم الاستدعاء عبر خط الفحص لتسع لغات: بدقة مستوى المُصرِّف لـ Go وJava و.NET، ومن نص المصدر لـ Python وJavaScript وTypeScript وRust وPHP وRuby. وتحمل كل حافة المستوى الذي أنتجها.

والحالة الأضيق أهم: بناء رسم استدعاء من شجرة مصدر في CLI يدعم Go وRust فقط. أما كل ما عداهما فيصل في صورة رسم مستخرج مسبقًا من خط الفحص. والنتائج خارج اللغات المشمولة لا تُسقط بصمت — بل تبقى في مجموعة العمل بوصفها مجهولة، تُقيَّم بدرجة بدلًا من تجاوزها.

لا يحتوي سجل الهدف على السر أبدًا — بل على مرجع إليه فقط. أما السر نفسه فيُختم بـ AES-256-GCM بمفتاح خاص بكل مستأجر مشتق من مفتاح رئيسي، والتشفير مرتبط بالمستأجر والمالك وهوية بيانات الاعتماد، فلا يمكن إعادة استخدام النص المشفَّر لصف على أنه لصف آخر. ثم يُختم سجل اتصال الهدف بالكامل مرة أخرى في نطاق تشفير خاص به قبل أن يصل إلى قاعدة البيانات.

المفتاح الرئيسي توفّره أنت، ولا نُنشئه نحن أبدًا. يأتي من متغير بيئة، أو ملف مُركَّب تُفحَص صلاحياته، أو HashiCorp Vault أو OpenBao، أو HSM. وإذا لم يُهيَّأ مخزن دائم، تفشل كل عمليات الختم والاسترجاع بدلًا من التراجع صامتًا إلى الذاكرة.

التقييد والتدوير مُلزِمان لا استشاريان: كل استعلام يُرشَّح بالمستأجر، فقراءة عبر المستأجرين لا تُرجع شيئًا ولا تكشف حتى وجود بيانات اعتماد. والتدوير يُبقي السر السابق قابلًا للاسترجاع خلال مهلة سماح ثم يفشل مغلقًا، والإبطال يمحو النص المشفَّر المحفوظ حتى لا يستعيده اختراق مفاتيح لاحق.

الإصدار المُبوَّب يُحجَب ولا يُمرَّر. فإن لم يتيسّر الوصول إلى الفاحص أو محرّك السياسات، تعامل البوابة انتهاء المهلة على أنه فشل بحكم التصميم — وتعليقات الشيفرة تقول ذلك حرفيًا، ولا يوجد في سطر الأوامر أي مفتاح fail-open. والأمر نفسه عند النشر: أثرٌ لا يمكن استرجاع نتيجة فحصه لا يُنشَر.

الإصدار أثناء انقطاع هو فعل مقصود وقابل للمساءلة لا حلٌّ التفافي. فاستثناء البوابة يتطلب إذنًا لا يملكه أحد افتراضيًا، وتبريرًا مكتوبًا، وإقرارًا صريحًا بالخطر، ومدة انتهاء بين يوم و365 يومًا — والاستثناءات المفتوحة مرفوضة — وتوقيعًا من المشغّل الذي يتحمّل المسؤولية، وإعادة مصادقة خلال الخمس دقائق الأخيرة. ويُسجَّل على الإصدار. ولاحظ أنه يحتاج تهيئة مسبقة: في تثبيت غير معدَّل لا يكون مسار التوقيع موصولًا، فيُرفض الطلب حتى تُسجّل مفتاح مشغّل.

لا تحتاج البوابة المنصة بأكملها. فقرار النشر يعتمد على نحو عشر خدمات — قاعدة البيانات ومنسّق الإصدارات والفاحص ومحرّك السياسات والهوية والبوابة الأمامية — لا على المنظومة بأكملها؛ أما ختم الأدلة والإشعارات وتدقيق الخط الزمني فهي خارج مسار القرار.

النشر على جهاز افتراضي خام مدعوم دعمًا كاملًا: عبر SSH أو WinRM أو Ansible تستطيع Stella Ops وضع ملف أو إعادة تشغيل خدمة أو تشغيل ملف تنفيذي يوفّره المشغّل على المضيف، وتلتقط الأمر ومخرجاته ورمز الخروج كدليل — دون حاوية.

أما المراقبة المستمرة فأضيق، ويجدر قول ذلك بدقة. تراقب Watch وقابلية الوصول الحاويات العاملة عبر digest الصورة — وبذلك يعرف كشف الانحراف أن الأثر العامل لا يزال مطابقًا للمعتمد. أما مضيف لا تستطيع قراءة حاوية منه فيُعرَض على أنه غير مراقَب، ولا يُفترَض أبدًا أنه سليم. فعمليةٌ خام على مضيف بلا Docker تُنشَر ويُسجَّل تشغيلها، لكنها لا تُراقَب باستمرار بحثًا عن انحراف كما يحدث لحمل داخل حاوية. و«الخوادم البسيطة» تعني خوادم تشغّل حاويات خارج Kubernetes — لا عمليات غير محوّاة كيفما كانت.

لا. مشغّل مخوّل يرفع الحظر بنفسه. ترفع استثناء سياسة محدَّد المدة يمر عبر سير موافقة تُهيّئه أنت: أدوار موافِقين مسمّاة، وحد أدنى لعددهم، ورمز سبب، وأدلة داعمة، وأي ضوابط تعويضية، مع حد أقصى لمدة صلاحيته. والموافقة الذاتية خيار تضبطه أنت، لا إعداد افتراضي نفرضه.

الاستثناء الممنوح يقلب تلك النتيجة تحديدًا — كتمًا أو تأجيلًا أو تخفيضًا أو اشتراط ضابط — ويُكتَب في مسار تدقيق القرار مع من وافق ومتى. ويمكن توقيعه بـ DSSE، فيكون الرفع خاضعًا للمساءلة وقابلًا لإعادة التشغيل، لا تجاوزًا صامتًا يختفي من السجل.

يبقى حدٌّ غير قابل للاستثناء عمدًا: كل أثر منشور يجب أن يحمل اجتياز فحص حقيقيًا. الاستثناء يرفع نتيجة سياسة محددة؛ ولا يرفع أبدًا اشتراط أن يكون الأثر قد فُحِص أصلًا.

افتراضيًا تحتفظ Stella Ops بمستخدميها المحليين وتخزّن كلمات المرور مُجزّأة بخوارزمية Argon2id. وتُشحن موصّلات SAML وOIDC وLDAP/Active Directory موقَّعة مع المنصة، وتفعيل أحدها خطوة تهيئة يقوم بها المشغّل لا إعداد افتراضي. وتتضمن حزمة التثبيت ملف تهيئة لكل موصّل.

الوصول محدود بالمستأجر ومبني على أذونات لا على أدوار تقريبية. تشحن المنصة أكثر من 200 إذن مُسمّى، فتكون الأمور المهمة منحًا منفصلة: الموافقة على استثناء سياسة، وتجاوز بوابة إصدار، وتدوير مفتاح تشفير المفاتيح — كلٌّ إذن بذاته. يمكنك السماح لشخص بقراءة النتائج دون السماح له برفع حظر.

تُسجَّل الإجراءات التي تُحدث تغييرًا في سجل التدقيق الخاص بالمنتج، بإذن قراءة خاص به — منفصل عن سلسلة الأدلة الموقّعة التي يحملها الإصدار وإضافي إليها. ولا شيء من ذلك مقيّد بالخطة: خطتا مجاني ومرخّص تتضمنان كل القدرات.

إنه السؤال الصحيح، ولن نتهرب منه: التوقيع يثبت أن تثبيتك أنتج الحكم، فمنصة تحكم مخترَقة يمكنها توقيع سجل يبدو صالحًا. وما يفعله التصميم هو أن يجعل الوثوق بذلك السجل ثقةً عمياء أمرًا صعبًا، وكشفه أمرًا سهلًا.

يجري التحقق مقابل جذر ثقة تُهيّئه أنت ويفشل مغلقًا من دونه — ولا يتصل أبدًا بخدمة لدى Stella Ops ليقرر بمن يثق. ويُختَم كل حكم زمنيًا مقابل سلطة توقيت تحدّدها أنت، ويتوفر الإدراج في سجل شفافية مقابل سجل تُشغّله أنت — فيصير «متى» و«هل سُجِّل أصلًا» مرتكزين خارج الصندوق الخاضع للتدقيق.

أقوى فحص هو إعادة التشغيل: يُعاد حساب كل حكم من مدخلاته المختومة، وأي سجل لا يُعاد حسابه إلى النتيجة نفسها يفشل. أعد التشغيل على بنية لا تتحكم بها منصة التحكم المشبوهة، ولن ينجو حكم مزوَّر من إعادة الحساب. لا شيء من هذا يجعل منصة مخترَقة غير ضارة — بل ينقل مرتكز الثقة بعيدًا عنها ويمنحك وسيلة مستقلة لكشف الكذب.

لم يُحذف شيء. قابلية الوصول تغيّر ما إذا كانت النتيجة تحجب الترقية، لا ما إذا كانت موجودة: تبقى النتيجة في السجل بالحالة التي أُعطيت لها، ويحفظ دليل البوابة العدد الكامل للنتائج إلى جانب المجموعة الفرعية التي حجبت فعلًا. ولا توجد خطوة كتمان يلزم إعادة بنائها لاحقًا.

والكبسولة تقول لماذا ومتى. فهي تربط بالبصمة كل مُدخل أنتج الحكم: SBOM ولقطات التنبيهات ودليل قابلية الوصول الذي جاءت منه الحالة ومعرّف السياسة ونسختها التي عملت عليه. أما الموافقة التي رقّت الإصدار فتُسجّل على الإصدار نفسه، في مرحلة Decision من سلسلة العهدة.

ويمكن إعادة حسابه. فإعادة التشغيل (replay) تنفّذ الحكم مجددًا من تلك المدخلات المختومة في سياق غير متصل وتقارن النتيجة بالنتيجة المسجّلة، فتُبلّغ عن تباعد إن اختلفتا؛ وإعادة التشغيل التي لا تستطيع إعادة الحساب فعلًا تفشل بدل أن تعيد الحكم المخزَّن كما هو. وبعد أي حادثة يصبح ما كان معروفًا وقت القرار مسألة سجل لا مسألة جدال.

المخاطرة المتبقية تخصك. سياستك هي التي قررت أي الحالات تحجب وأيها لا، والبوابة لا تساوي أكثر من السياسة التي خلفها. يدّعي Stella Ops أن القرار كان مدعومًا بالأدلة وقابلًا للإعادة، ولم يدّعِ قط أنه كان صحيحًا. ومما يجدر معرفته قبل كتابة تلك السياسة: لا يحجب الإصدارَ إلا مسار وصول مُثبت، لأن «عدم ملاحظة مسار» ليس إثباتًا لعدم وجود مسار، ولا يُسجّل على هذا النحو.

الأدلة والتدقيق → كيف تعمل قابلية الوصول →

يُعاد فتح الحكم. فحداثة التنبيهات ليست تقريرًا تقرؤه لاحقًا — إذ تعيد بيانات التنبيهات الجديدة تقييم القرارات المتخذة سابقًا، ويُعلَّم الإصدار المتأثر.

القرار الذي كان صحيحًا يوم الثلاثاء قد يكفّ عن كونه صحيحًا يوم الخميس دون أن يتغير شيء في بيئتك. والأنظمة التي لا تُقيِّم إلا وقت الترقية لا ترى ذلك.

يُعرض عمر البيانات لكل مصدر على حدة على الشاشة. القِدم ظاهر دائمًا، ولا يُخفى أبدًا.

إن تثبيتًا معزولًا يقدّم بصمت بيانات تنبيهات عمرها شهر وهو يبدو سليمًا أسوأ من تثبيت يرفض البدء. تُظهر لك Stella Ops عمر البيانات التي تبني عليها قراراتها، ويسجّل استيراد Offline Kit الـ digest الخاص باللقطة، بحيث تستخدم إعادة التشغيل بعد أشهر البيانات نفسها التي بنيت عليها قرارك.

شيئًا يستطيعون التحقق منه بأنفسهم، دون أن يثقوا بنا أو يثبّتوا أي شيء. فـالكبسولة النموذجية المنشورة يُتحقق منها باستخدام cosign verify-blob وsha256sum في نحو ثلاثين ثانية.

• ما تم فحصه (بصمة القطعة الدقيقة)
• ما تم العثور عليه (SBOM?قائمة مواد البرمجيات - قائمة كاملة بجميع الحزم والتبعيات في برنامجك + الوصول)
• لماذا تمت الموافقة (حكم السياسة)
• من وافق (موافقات موقعة)

يمكن للمدققين التحقق من التوقيعات بشكل مستقل وإعادة تشغيل القرار بدون اتصال باستخدام stella replay.

الأوامر كما تظهر في وحدة تحكم المنتج (v1.0-RC1).

لا. تأتي الأدلة من CLI داخل مهمة البناء الحالية لديك. ينشئ stella ci init هيكل خطوات المسار؛ ويوقّع CLI أدلة البناء داخل المهمة (stella attest sign).

لا يلزم أي موصل — فأي CI يستطيع تشغيل ملف تنفيذي يفي بالغرض. يستهلك Stella digests وأدلة موقعة، لا صلاحية وصول إلى المستودع.

الأوامر كما تظهر في وحدة تحكم المنتج (v1.0-RC1).

تربط حزم الامتثال أدلة العهدة بالتزامات NIS2 وDORA وCRA. يبدأ التفعيل جمع الأدلة في وضع متحفظ يعتمد الأدلة فقط؛ ولا يدّعي تحقيق الامتثال التنظيمي.

يظل المشغّل دائمًا صاحب القرار الخاضع للتنظيم. يساعدك Stella في تجميع العناصر التي يتوقعها المنظّم وتوقيعها — لكنه لا يقدّم الإقرارات ولا يمنح شهادات.

لا تزال بعض مسارات الكتابة قيد التنفيذ — فمثلًا ينتظر نقل الإرسال التلقائي إلى ENISA صدور المخطط الرسمي (يُسلّم حاليًا إلى نظام ملفات المشغّل). وتوضح صفحة الامتثال الحالة الراهنة لكل حزمة.

حزم الامتثال بالتفصيل →

حمل عمل مُدار واحد في بيئة واحدة من تثبيتك: خدمة حاوية، أو قطعة برمجية معنونة بالـ digest تُنشر على مضيف عبر SSH أو WinRM؛ ويُحتسب كلاهما بالطريقة نفسها. ويمكن أن تُحتسب العلاقة بين حمل العمل والبيئة عندما تنشر Stella Ops إصداراته أو تُخضعها لبواباتها أو ترقّيها، أو تفحص صورته أو قطعته البرمجية المثبّتة، أو تطبّق نتيجة فحص سابق على حمل العمل المثبّت ذاك. ولا يتطلب تطبيق نتيجة سابقة تشغيل فحص جديد. وتُحتسب كل علاقة مستوفية للشروط مرة واحدة، حتى إذا انطبق عليها أكثر من نشاط من هذه الأنشطة.

تُحتسب المواضع لكل تثبيت — والتثبيت هو نشر منطقي واحد لمستوى التحكم في Stella Ops: تُحتسب عُقد العنقود ونسخ قاعدة البيانات المتماثلة ومكونات تجاوز الفشل التابعة للنشر نفسه معًا، أما التثبيتات التي تُشغَّل بشكل مستقل فهي تثبيتات منفصلة. ولا تُحتسب البنية التحتية الخاصة بـ Stella Ops أبدًا. وينتهي الموضع عندما تنتهي فعليًا كل إدارة لحمل العمل ذاك في تلك البيئة، أو عندما يُزال حمل العمل ولا يُبقيه أي نشاط إداري آخر نشطًا؛ واكتمال الفحص لا يُنهيه، والاحتفاظ بالأدلة التاريخية أو التقارير لا يُنشئ موضعًا ولا يعيد تنشيطه ولا يُبقيه نشطًا بذاته.

لا يعرض الإصدار الحالي إجمالي المواضع. عُدّ كل حمل عمل في كل بيئة مرة واحدة إذا كانت Stella Ops تنشر إصداراته أو تُخضعها لبواباتها أو ترقّيها، أو تفحص صورته أو قطعته البرمجية المثبّتة، أو تطبّق عليه نتيجة فحص سابق. يسرد عرض Estate عمليات النشر التي نفّذتها Stella Ops؛ وعليك أيضًا أن تعدّ كل حمل عمل آخر مستوفٍ للشروط، بما في ذلك ما تنشره أدوات أخرى وما لا يُظهره الجرد التلقائي.

ما الذي يُعدّ موضعًا مُدارًا →

لا. خمس نسخ متماثلة من حمل عمل في بيئة واحدة هي موضع واحد. وإعادة تشغيله أو إعادة نشره أو طرح إصدار صورة جديد أو digest جديد لحمل العمل نفسه في البيئة نفسها لا يضيف شيئًا.

ثلاثة. الموضع هو حمل عمل واحد في بيئة واحدة، لذا فإن حمل العمل الذي يُشغَّل في التطوير والتجهيز والإنتاج يمثل 3 مواضع، وعشرة أحمال عمل عبر ثلاث بيئات تمثل 30 موضعًا. أما البيئات نفسها فلا تُقيَّد ولا تُسعَّر أبدًا.

لا. لا رسوم لكل فحص أو إعادة فحص أو تقرير ثغرات أو ترقية أو عملية نشر. إن فحص صورة حمل عمل مثبّت أو قطعته البرمجية، أو تطبيق نتيجة فحص سابق عليه، قد يُدخل حمل العمل هذا في عدد المواضع في كل بيئة معنية. وتُحتسب كل علاقة بين حمل عمل وبيئة مرة واحدة فقط، مهما كان عدد الفحوص أو التقارير.

مجرد الاحتفاظ بتقرير أو الاطلاع عليه بوصفه دليلًا تاريخيًا فحسب لا يُنشئ موضعًا. أما تقديم نتيجة سابقة على أنها معلومات فحص منطبقة على حمل عمل مثبّت فيُعدّ تطبيقًا لتلك النتيجة. وفحص صورة أو قطعة برمجية غير مثبّتة في أي من بيئاتك لا يُنشئ موضعًا.

يتطلب الاستخدام في الإنتاج فوق 20 موضعًا لكل تثبيت خطة مرخّص: ترخيصًا لسعة مواضع لا تقل عن عدد المواضع التي تديرها. وتكلفتها $100 شهريًا لسعة تصل إلى 100 موضع، وفوق ذلك $1 لكل موضع من السعة شهريًا؛ وفوق 20 يُحتسب كل موضع — فلا تُخصم المواضع الـ 20 المجانية — لذا تكلّف سعة 30 موضعًا $100 شهريًا، وسعة 200 موضع $200.

تسري زيادات السعة عند طلبها وتُحتسب تناسبيًا من ذلك التاريخ؛ أما التخفيضات فتسري عند التجديد.

إذا لاحظت أنك تجاوزت سعتك، أو تجاوزت المواضع الـ 20 المجانية، عن غير قصد، فيمكنك مواصلة الاستخدام مدة 14 يومًا من تاريخ ملاحظتك ذلك ريثما تقلّص الاستخدام أو تطلب السعة اللازمة. وهذه المهلة مخصّصة للتجاوز غير المقصود، لا للتجاوز المتعمَّد أو المتكرر.

يمكنك الاشتراك اليوم: راسل sales@stella-ops.org؛ ويُقدَّم الطلب عبر تاجر مُسجَّل معتمد. وسيتوفر الدفع عبر الإنترنت قريبًا.

كم ستكلّف؟ →

لخطة مرخّص حد أدنى شهري قدره $100، ويغطي هذا الحد الأدنى ما يصل إلى 100 موضع: فـ 21 موضعًا و100 موضع يكلّفان كلاهما $100 شهريًا. وابتداءً من 101 موضع يكون السعر $1 لكل موضع — فتكلفة 101 موضع $101، وتكلفة 150 موضعًا $150.

لا يتوقف شيء. الإصدار الحالي لا يفرض حد المواضع ولا يتحقق من أي ترخيص، لذا يستمر برنامجك وأحمال عملك وفحوصك وعمليات النشر لديك في العمل، ويبقى كل سجل أدلة قابلًا للتحقق بجذر الثقة الخاص بك.

غير أن السعة المدفوعة مرخَّصة لمدة الاشتراك. فبمجرد انتهاء المدة، يتطلب الاستخدام في الإنتاج فوق 20 موضعًا تجديد الاشتراك أو التقليص إلى 20 موضعًا أو أقل.

لا. لا خادم تراخيص ولا تفعيل ولا اتصال راجع إلينا: الإصدار الحالي لا يتحقق من أي ترخيص، لذا يُرخَّص التثبيت المعزول تمامًا كما يُرخَّص التثبيت المتصل. استخدامك المجاني تحدده شروط الترخيص، وسعتك المدفوعة يحددها طلبك — لا الاتصال بنا.

تصل تحديثات معلومات الثغرات إلى التثبيت غير المتصل عبر Offline Kit، ويُعرض عمر بيانات كل مصدر على حدة على الشاشة.

بطلبك. تُشترى خطة مرخّص عبر تاجر مُسجَّل معتمد بسعة مواضع لا تقل عن عدد المواضع التي تديرها، وينص الطلب المقبول على تلك السعة وعلى المدة بموجب اتفاقية عملاء Stella Ops.

الإصدار الحالي لا يستورد ذلك السجل ولا يتحقق منه، لذا فإن إبقاء التثبيت ضمن حدوده مسؤوليتك. وعند انتهاء المدة لا يتوقف شيء في البرنامج، لكن الاستخدام في الإنتاج فوق 20 موضعًا يتطلب حينها تجديد الاشتراك أو التقليص إلى 20 موضعًا.

اتفاقية العملاء →

الأدلة التي يولّدها تثبيتك موقّعة بمفاتيح تثبيتك أنت، لا بمفاتيحنا. تحقّق من حزمة أدلة محمولة دون أي اتصال مقابل جذر الثقة الذي تعلنه: stella evidence verify-offline <bundle.tgz> --trust-root <keys.jwks.json|key.pem>. يفحص الأمر المجاميع الاختبارية وروابط البيان والتوقيع، ويفشل مغلقًا.

إصدارات Stella Ops موقّعة على نحو منفصل: حزمة الإصدار والصور موقّعة بـ Cosign، والمفتاح العام منشور في صفحة مفاتيح التحقق. يبيّن توقيع الإصدار أن الحزمة جاءت منا؛ ويبيّن توقيع الأدلة أن السجل جاء من تثبيتك.

مفاتيح التحقق →

نعم، عبر الواجهات نفسها التي يستخدمها الشخص. فمهمة CI أو سكريبت أو وكيل ذكاء اصطناعي تشغّله يُصادَق عليه بوصفه عميل خدمة OAuth بمنح بيانات اعتماد العميل (client credentials)، ويقود الإصدارات عبر واجهة برمجة الإصدارات أو stella release approve|reject|promote|deploy|rollback. ويقيّم الخادم الموافقات وبوابات السياسات، فيخضع المستدعي الآلي للسياسة نفسها التي يخضع لها الشخص.

وتندمج أدوات الفحص الأخرى أيضًا: يستورد stella sbom upload قائمة SBOM خارجية بصيغة CycloneDX?صيغة معيارية مفتوحة لقوائم مواد البرمجيات (SBOM) مستخدمة في جميع أنحاء الصناعة أو SPDX?Software Package Data Exchange - صيغة معيارية مفتوحة أخرى لـ SBOM، واسعة الاستخدام في البرمجيات مفتوحة المصدر ويسجّل الأداة التي أنتجتها، ويمرّر stella gate score batch --sarif نتائج SARIF من أداة أخرى عبر بوابة الإصدار نفسها.

تغطي المراجعة الواحدة مشكلة واحدة محددة. يحلل مهندس المعلومات التي ترسلها ويرد برد هندسي مكتوب: السبب المرجح، والخطوات التصحيحية أو التشخيصية التي نوصي بها.

ولا تشمل ساعات هندسية غير محدودة أو تطويرًا مخصصًا أو معالجة مضمونة أو استشارات مستمرة، ولا يوجد مستوى خدمة مستمر. وقبل الشراء نعطيك إطارًا زمنيًا تقديريًا للتسليم؛ وبمجرد حصولنا على المعلومات التي نحتاجها، نرد كتابيًا خلال مدة معقولة. وقبل أن نطلب سجلات التشغيل، نوضح لك كيفية إرسال بيانات التشخيص بأمان. لشراء مراجعة، راسل support@stella-ops.org مع وصف موجز للمشكلة.

إذا أظهرت المراجعة أن المشكلة الرئيسية عيبٌ قابل لإعادة الإنتاج في إصدار مدعوم ومهيّأ تهيئة صحيحة، تُسترد الرسوم — أو تُقيَّد رصيدًا لصالحك إن فضّلت ذلك.

التوثيق وتشخيصات Doctor واستكشاف الأخطاء وإصلاحها ذاتيًا مجانية للجميع، والإبلاغ عن عيب في المنتج أو ثغرة أمنية لا يتطلب أبدًا مراجعة مدفوعة.

Stella Ops في مرحلة مرشّح الإصدار (v1.0-RC1).

• الآن: v1.0.0-RC1-20261029 — الحزمة الموقّعة والصور عامة وتُجلب دون مصادقة من get.stella-ops.org وregistry.stella-ops.org
• قبل إطلاق v1.0: عميلان على الأقل يشغّلونه في الإنتاج، وتثبيت سطح الـ API العام
• يُتوقع صدور v1.0 في 1 يناير 2027
• الشيفرة المصدرية متاحة بموجب BUSL-1.1
• ثابت في الحالتين: صيغ أدلة متوافقة مع الإصدارات السابقة وإعادة تشغيل حتمية

كيف تبدأ →

تسجيل الدخول عبر الدليل غير مفعَّل افتراضيًا. تُشحن إضافات LDAP وOIDC وSAML موقَّعة مع v1.0.0-RC1-20261029، وتتضمن حزمة التثبيت ملف إعداد لكل منها، لكن Stella Ops لا توفر تسجيل دخول عبر الدليل دون إعداد: عليك توجيه الإضافة إلى دليلك ثم تفعيلها.

وليست كذلك أداة لـ Kubernetes — وهذا موقف مقصود لا ثغرة. ولا تفحص البرمجيات الخبيثة، ولا تتضمن حزم امتثال فدرالية أمريكية. وإن كان أيٌّ من ذلك مطلبك الحاسم، فهناك اليوم ما يناسبك أكثر.

Stella يصمم الإصدارات كرسم ترقية (Dev → Stage → Prod). في كل بوابة:

• يتم تقييم السياسة مقابل أدلة القطعة
• يتم تسجيل الموافقات بتوقيعات تشفيرية
• يتم إنشاء Decision Capsule للتدقيق

الترقيات مرتبطة ببصمات القطع، وليس بالعلامات. نفس البصمة = نفس الأدلة معاد استخدامها.

يُطوَّر Stella Ops في أوروبا وتُشغّله شركة مسجّلة في بلغاريا؛ وتُستضاف بنيتنا الخاصة — هذا الموقع والسجل وقنوات التحديث — في سويسرا، التي تتمتع بقرار كفاية لحماية البيانات من الاتحاد الأوروبي. ولا يوجد مورّد مقره الولايات المتحدة ضمن سلسلة توريدك. وتفاصيل المشغّل الكاملة موجودة في الإشعار القانوني.

المنصة مستضافة ذاتيًا، لذا تبقى العناصر وSBOMs والأدلة في بنيتك — ومعزولة عن الشبكة إذا احتجت. ويعني الجمع بين الولاية القضائية الأوروبية والاستضافة الذاتية أنك الطرف الوحيد الذي يحتفظ بأدلة إصداراتك.

سؤال وجيه لأي شيء يقع في مسار الإصدار. وجواب التصميم: التشغيل اليومي لا يعتمد أبدًا على الوصول إلينا. المنتج مستضاف ذاتيًا ويعمل في بيئات معزولة؛ لا خادم تراخيص ولا اعتماد على سحابة لدينا، ولا شيء في الإصدار الحالي يتحقق من أي ترخيص، لذا لا يتوقف شيء عند انتهاء الاشتراك — لكن الاستخدام في الإنتاج فوق 20 موضعًا يتطلب حينها تجديد الاشتراك أو التقليص إلى 20 موضعًا.

أدلتك أيضًا لا تحتاج إلينا. تُتحقق الأحكام والكبسولات دون اتصال — يعيد stella replay حساب القرار من مدخلاته المختومة دون أي خدمة أو حساب لدى Stella Ops.

الشيفرة متاحة المصدر بموجب BUSL-1.1: يمكنك قراءة وبناء وترقيع النسخة التي تشغّلها. وللرخصة أجل مدمج — تتحول كل نسخة إلى رخصة مفتوحة في تاريخ التغيير الخاص بها، وفي موعد أقصاه 20 يناير 2030 للنسخة الحالية. ولا تعتمد علينا في التشغيل اليومي أيضًا: stella doctor يشغّل فحوص تشخيص التثبيت، وstella doctor export يحزم ملفًا للدعم، وstella doctor fix يطبّق إصلاحات غير تدميرية. الشيفرة المصدرية على git.stella-ops.org.

في التشغيل اليومي، يدعم المنتج نفسه بنفسه. يفحص Doctor سلامة المنصة ويعيد خطوات المعالجة لكل ما يجده؛ وضمن نافذة صيانة يطبّق الإصلاحات غير التدميرية بنفسه، أما التدميرية فلا يطبّقها إلا خلف بوابة موافقة مع معاينة تشغيل تجريبي وسجل تدقيق دائم — وإلا فإنه يسلّمك الخطوات اليدوية. وتتوفر المساعدة البشرية فوق ذلك في صورة مراجعة مدفوعة لمشكلة واحدة محددة، لا بوصفها ما يُبقي تثبيتك قيد التشغيل. وإذا كانت مشترياتك تتطلب شروط استمرارية تعاقدية، فحدّد نطاقها مع sales@stella-ops.org أثناء التقييم.

مفاتيح التحقق ومثال دليل موقّع ووثائق البنية والتحصين كلها عامة ومجمّعة في صفحة المراجعة الأمنية للمورّد، التي تذكر أيضًا موقفنا من الاعتمادات. ومراجع العملاء قادمة قريبًا — نتائج النسخة التجريبية الداخلية لدينا. ويمكن تحديد نطاق مناقشات العناية الواجبة أثناء التقييم.

مراجعة أمان المورّد →

يتولى الطلب والدفع والضرائب والفوترة تاجر مُسجَّل معتمد — انظر إشعار الدفع. يمكنك الطلب اليوم عبر البريد الإلكتروني: خطة مرخّص عبر sales@stella-ops.org، ومراجعة الدعم عبر support@stella-ops.org. وسيتوفر الدفع عبر الإنترنت قريبًا.

المنتج مصمَّم ليستمر في العمل دون تذكرة دعم: يفحص Doctor سلامة المنصة ويطبّق الإصلاحات غير التدميرية بنفسه ضمن نافذة صيانة، مسلِّمًا إياك الخطوات الدقيقة لكل ما لن يفعله دون إشراف. التوثيق وDoctor واستكشاف الأخطاء وإصلاحها ذاتيًا مجانية في كل خطة. وحين تحتاج إلى مهندس، تكلّف مراجعة الدعم $75 لمشكلة واحدة محددة: تحصل قبل الشراء على إطار زمني تقديري للتسليم، ثم على رد هندسي مكتوب، وتُسترد الرسوم إذا تبيّن أن المشكلة الرئيسية عيبٌ قابل لإعادة الإنتاج في إصدار مدعوم ومهيّأ تهيئة صحيحة. ولا تتضمن أي خطة مستوى خدمة مستمرًا. وأيًّا كان من يجيب، فهو الفريق الهندسي الذي يبني المنتج — الدعم ليس مُسنَدًا إلى جهة خارجية.

Stella Ops Suite متاحة المصدر بموجب BUSL-1.1. يمكنك قراءة الشيفرة وبناءها وتدقيقها. أما طبقة التحقق (التحقق من صحة الكبسولة، والتحقق من التوقيعات) فمرخّصة بموجب Apache-2.0. والشيفرة المصدرية متاحة على git.stella-ops.org.

يسمح BUSL-1.1 بالاستخدام المجاني في الإنتاج حتى 20 موضعًا مُدارًا لكل تثبيت. وفوق ذلك، يتطلب الاستخدام في الإنتاج خطة مرخّص، أي ترخيصًا لعدد مواضعك. وبعد تاريخ التغيير — أربع سنوات من كل إصدار — تتحول الشيفرة إلى Apache-2.0.

يموّل هذا النموذج تطويرًا مستدامًا للمنتج، مع إبقاء سلسلة الأدلة قابلة للتدقيق بالكامل.

المستأجر مساحة عمل معزولة لها مستخدموها وأدوارها وسياساتها وسجل أدلتها الخاص. وتعليق المستأجر يجمّد كل صلاحيات الوصول الخاصة به.

يتشارك المستأجرون تثبيتًا واحدًا، وتُفصل الأدلة والصلاحيات لكل مستأجر على حدة. والكلمتان تجيبان عن سؤالين مختلفين:

• Environment?هدف نشر منطقي (مثل dev وstaging وprod) يتتبع سجل إصداراته وقواعد الترقية وبوابات السياسات الخاصة به (البيئة) هدف نشر — أين يعمل الإصدار، وأي سياسة تضبط ترقيته.
• أما المستأجر فحدٌّ للوصول وللأدلة — من يستطيع الاطلاع والتصرف، وفي سجل أدلة مَن تُسجَّل.

يضم المستأجر الواحد عادةً عدة بيئات. ولا يُسعَّر المستأجرون ولا البيئات: يحتسب التسعير المواضع المُدارة عبر التثبيت كله.

نعم. Stella هي طبقة التحكم فوق أي ماسح تستخدمه، ولمخرجاته مكان يصل إليه: يقبل stella sbom upload مستند CycloneDX?صيغة معيارية مفتوحة لقوائم مواد البرمجيات (SBOM) مستخدمة في جميع أنحاء الصناعة أو SPDX?Software Package Data Exchange - صيغة معيارية مفتوحة أخرى لـ SBOM، واسعة الاستخدام في البرمجيات مفتوحة المصدر خارجياً ويسجّل الأداة التي أنتجته، ويمرّر stella gate score batch --sarif مخرجات SARIF من أي منتج عبر بوابة الإصدار نفسها التي تمرّ بها فحوص Stella.

وفوق قائمة النتائج هذه تضيف Stella تحليل قابلية الوصول، وVEX?Vulnerability Exploitability eXchange - بيانات قابلة للقراءة آليًا حول ما إذا كانت الثغرات قابلة للاستغلال فعلاً في سياقك من عدة جهات إصدار، وبوابات سياسة تراعي البيئة التشغيلية، وتصدير أدلة موقّعة. ماسحك يجد الثغرات؛ وStella تقرر أيها يهم وتثبت القرار.

قابلية الوصول تحسبها Stella من فحصها الخاص للبصمة. أما ملف SARIF المستورد فيحمل قابلية الوصول التي سجّلها منتِجه — تقرأ Stella هذا الحقل ولا تعيد اشتقاقه.

الأوامر كما تظهر في وحدة تحكم المنتج (v1.0-RC1).

مقارنة مع Trivy · مقارنة مع Snyk · المقارنة الكاملة →

Stella ليست طبقة فوق أداة النشر لديك — بل هي نفسها منسّق إصدارات. تأتي Docker وCompose وSSH وWinRM وECS وNomad وAnsible كإضافات تنفيذ مدمجة. وعلى الأهداف التي تغطيها، تنفّذ Stella النشر بنفسها ولا تغلّف أداة تقوم بذلك أصلاً.

يبقى نظام التكامل المستمر لديك في مكانه تماماً، لأن البوابة مجرد ملف تنفيذي. أي نظام يستطيع تشغيله يستدعي stella gate evaluate ويتصرف بحسب رمز الخروج. ويكتب stella ci init مسارات جاهزة لـ GitHub Actions وGitLab CI وGitea Actions؛ وأي نظام آخر يُربط يدوياً في بضعة أسطر.

تتوفر موصّلات لـ Gitea وGitHub App وGitLab وJenkins وHarbor وNexus وسجلات OCI?مبادرة الحاويات المفتوحة — المعيار الصناعي لتنسيقات صور الحاويات والسجلات وVault وConsul. التقسيم العملي: احتفظ بنظام التكامل المستمر لديك، وقرّر لكل بيئة ما إذا كانت Stella تنفّذ النشر أم تضبط نشراً تنفّذه أداتك الحالية.

الأوامر كما تظهر في وحدة تحكم المنتج (v1.0-RC1).

مقارنة مع Octopus Deploy · ما الذي يُربط، وما الذي لا يحتاج موصّلاً →

نعم. تقدّم Stella الدليل على مستوى الأثر الرقمي الذي يستند إليه برنامج الامتثال ولا يستطيع إنتاجه بنفسه: لكل إصدار، ما المنشور، وتحت أي بصمة، وعبر أي سياسة مرّ، ومن اعتمده، وفي أي يوم. يُقرأ هذا السجل من النشر نفسه، ويُعاد حسابه من الأدلة نفسها فيعطي النتيجة ذاتها — فما تراه المراجعة بعد عام هو ما تراه اليوم.

ويُصدَّر هذا السجل في ثمانية ملفات موقّعة موجّهة للجهات التنظيمية: بيان قابلية التطبيق وتقرير الفاعلية بموجب NIS2؛ وسجل المعلومات وتقرير الحوادث الكبرى وتبادل المعلومات بموجب المادة 45 وحزمة أدلة الاختبار بموجب DORA؛ والملف التقني وملف المطابقة بموجب CRA. كل حزمة مختومة وموقّعة ويمكن التحقق منها دون اتصال مقابل جذور ثقة منشورة — يُتحقق من التوقيع دون أي وصول إلى نسختك من Stella.

لا شيء في البرنامج الذي تديره اليوم يحتاج إلى تغيير. كل تصدير ملف موقّع قابل للنقل: أرفقه بالضابط الذي يثبته، أو سلّمه إلى مدقّق، أو اسحبه عبر واجهة تصدير الأدلة البرمجية. وقبل التصدير، يسمّي فحص الجاهزية لكل ملف ما ينقصه بالضبط — فتظهر الفجوة بينما لا يزال بإمكانك سدّها، لا أثناء التدقيق.

ميدان الامتثال، بمصادره · حزم الامتثال بالتفصيل →