Supply-chain Compromise

1. هم‌نام بودن artifact با release مورد انتظار، lineage را ثابت نمی‌کند

فرض کنید یک bundle محلی شامل source revision، lockfile، build attestation و artifact digest است، اما یکی از linkهای زنجیره با policy مورد انتظار سازگار نیست. package name، version یا حتی یک digest منفرد فقط یک مشاهده محلی است؛ برای تصمیم release باید بدانیم source از کدام revision آمده، dependency selection چه بوده، چه builderی artifact را ساخته، provenance به کدام subject اشاره می‌کند و artifact ذخیره‌شده همان خروجی مورد انتظار است. این درس روی پیدا کردن اولین trust link شکسته تمرکز دارد، نه ساختن روایت قطعی از روی یک علامت.

2. Source track و Build track یک مسئله واحد نیستند

SLSA v1.2 یک specification تأییدشده است و Source و Build را به‌صورت trackهای جداگانه مدل می‌کند. Source track درباره شواهد ایجاد و تاریخچه source revision است؛ Build track روی provenance و این تمرکز دارد که artifact چگونه و با چه inputها و builderی تولید شده است. [SLSA-12] در نتیجه، سالم بودن source history به‌تنهایی build را اثبات نمی‌کند و provenance build نیز به‌تنهایی قصد یا correctness کد را تضمین نمی‌کند.

3. Provenance مدرک lineage است، نه گواه بی‌نقص بودن نرم‌افزار

SLSA provenance اطلاعات قابل‌راستی‌آزمایی درباره این است که artifact کجا، چه زمانی و چگونه تولید شده است. [SLSA-12] اگر provenance subject با artifact یا revision مورد انتظار mismatch داشته باشد، trust chain برای همان release قابل‌بستن نیست. اما provenance صحیح هم نمی‌گوید نرم‌افزار bug یا منطق مخرب ندارد؛ این lesson عمداً چنین ادعایی نمی‌کند.

4. Lockfile فقط یک link از chain است

Lockfile می‌تواند dependency resolution را پایدار و قابل‌ممیزی‌تر کند، ولی build environment، source control، artifact repository، signing infrastructure یا provenance را پوشش نمی‌دهد. OWASP نیز software supply-chain security را در چند control family شامل source control، dependencies، build tooling، artifact repository، signing و provenance مطرح می‌کند. [OWASP-SUPPLY] پس «lockfile درست است» مساوی «supply chain سالم است» نیست.

5. Signature هم باید در مرز ادعای خودش خوانده شود

اعتبار یک signature نشان می‌دهد verification طبق identity/key و policy تعریف‌شده موفق بوده است؛ اما به‌تنهایی source correctness، builder trust یا نبود منطق مخرب را ثابت نمی‌کند. OWASP علاوه بر code signing، روی hardening زیرساخت signing و build هم تأکید دارد. [OWASP-SUPPLY] بنابراین signature evidence یکی از linkهاست، نه verdict کل chain.

6. یک trust-link map بسازید

برای این درس مسیر را به‌ترتیب source revision → dependency evidence → builder identity → provenance subject → artifact/repository digest → release policy بررسی کنید. اولین جایی که evidence دیگر policy را satisfy نمی‌کند، candidate اصلی broken trust link است. اگر evidence یک link وجود ندارد، آن را UNKNOWN نگه دارید؛ از روی link بعدی به عقب علت‌سازی نکنید.

7. Supply-Chain Compromise Trace & Quarantine Record v1

Artifact اصلی درس این فیلدها را ثبت می‌کند: Source Revision، Dependency Evidence، Builder Identity، Provenance Subject، Artifact Digest، Repository Digest، Signature/Policy Check، Broken Trust Link، Quarantine Scope، Trusted Rebuild Evidence، Verification Result و Residual Trust Gap. هر تصمیم باید به observation، authority-backed rule، inference مشخص یا UNKNOWN متصل باشد.

8. First broken link را از downstream symptom جدا کنید

اگر artifact ذخیره‌شده digest متفاوت دارد، ممکن است repository tamper رخ داده باشد؛ اما اگر provenance از قبل به subject اشتباه اشاره می‌کرد، broken link جلوتر از repository است. به همین دلیل record باید chain را از upstream به downstream بخواند. quarantine نیز باید همه خروجی‌هایی را پوشش دهد که از اولین link نامطمئن مشتق شده‌اند.

9. Negative evidence برای رد alternative لازم است

اگر builder مشکوک است، بررسی کنید source revision و dependency evidence هنوز policy را satisfy می‌کنند یا نه. اگر آن‌ها سالم‌اند و builder identity خارج از allowlist است، alternative «dependency selection علت اصلی بوده» ضعیف‌تر می‌شود. برعکس، اگر dependency evidence ناقص است، نباید builder را با قطعیت اولین failure اعلام کنید.

10. Adjacent failure را جذب نکنید

یک alert درباره credential signer ممکن است مهم باشد، اما اگر chain evidence این درس هنوز match است، نباید فقط از روی alert نتیجه Supply-chain Compromise بسازید. Credential compromise outcome متعلق به FLR-008 است. این درس می‌تواند release را hold و review را route کند، اما علت credential را بدون evidence خودش تعیین نمی‌کند.

11. Containment یعنی blast radius را محدود کنید

Containment می‌تواند quarantine کردن artifact و downstream releaseها، جلوگیری از promotion، freeze کردن repository path یا بازسازی با dependency set و builder تأییدشده باشد. هدف containment کاهش انتشار خروجی نامطمئن است؛ containment خودش علت را اثبات نمی‌کند و به‌تنهایی closure نیست.

12. Recovery به lineage جدید و مستقل نیاز دارد

برای بستن incident، صرفاً همان build را دوباره اجرا نکنید و «سبز شد» را proof ندانید. باید یک trusted rebuild path داشته باشید: source revision مورد انتظار، dependency evidence معتبر، builder identity پذیرفته‌شده، provenance subject درست، digestهای هماهنگ و verification policy pass. نتیجه فقط همان fixture و policy اعلام‌شده را می‌بندد، نه همه ریسک‌های واقعی supply chain را.

13. اگر evidence ناقص است، state باز بماند

Artifact امضاشده‌ای را تصور کنید که digest آن درست است اما source-policy evidence برای revision در دسترس نیست. signature و digest کافی نیستند تا missing link را پر کنند. classification باید OPEN_TRUST_LINK_UNRESOLVED بماند، affected output quarantine شود و human review یا evidence retrieval trigger تعریف شود.

14. Lab: هشت fixture و 64 assertion

Lab کاملاً local و inert است. هشت case شامل safe baseline، dependency mismatch، unapproved builder، provenance-subject mismatch، repository digest mismatch، adjacent credential signal، source-policy evidence ناقص و transfer mutation هستند. evaluator مدیریتی برای هر case هشت خروجی را بررسی می‌کند؛ در مجموع 64 assertion. هیچ package مخربی ساخته یا منتشر نمی‌شود و هیچ registry یا target خارجی استفاده نمی‌شود.

15. Exit checklist و مرز ادعا

قبل از خروج باید بتوانید chain را از source تا release trace کنید؛ first broken trust link را فقط با evidence تعیین کنید؛ حداقل یک alternative را رد کنید؛ UNKNOWN را حفظ کنید؛ containment را از recovery جدا کنید؛ trusted rebuild را با oracle مستقل verify کنید؛ و توضیح دهید که lockfile، signature، provenance یا یک rerun موفق هیچ‌کدام به‌تنهایی امنیت کامل supply chain را ثابت نمی‌کنند.