حمله به زنجیره تأمین فقط «هک سرور production» نیست: تزریق در CI، وابستگی مخرب، build غیررسمی، یا artifact عوض‌شده بین build و نصب. امضای یک باینری به‌تنهایی نمی‌گوید مسیر ساخت قابل اعتماد بوده است.

in-toto پاسخ استاندارد این لایه است:

A framework to secure the integrity of software supply chains — از شروع تا نصب نزد کاربر نهایی شفاف می‌کند چه گام‌هایی، توسط چه کسانی، و به چه ترتیبی انجام شده‌اند.

CNCF Graduated. لایسنس ابزارها عمدتاً Apache. مشخصات باز و قابل گسترش برای metadata زنجیره تأمین.

in-toto چه مشکلی را حل می‌کند؟

طبق سایت رسمی: استاندارد metadata باز + اکوسیستم یکپارچه‌سازی + tooling گسترده.

نکته حیاتی: in-toto جایگزین امن‌سازی خود گام‌ها نیست. اگر سیاست بگوید «از اینترنت curl کن و build کن» و همان را امضا کنید، verify موفق می‌شود — فقط ثابت می‌کند همان کار ناامن طبق Layout انجام شده. پروژه‌هایی مثل SLSA روی in-toto می‌نشینند تا بگویند کدام شواهد و سطوح اعتماد لازم است.

مفاهیم کلیدی

Project owner → root.layout (امضا)
       │
       ▼
Functionaries → stepN.<keyid>.link  یا attestations
       │
       ▼
Verifier (کاربر / admission / CD)
  in-toto-verify + کلید عمومی owner
  → قبول یا رد نصب/استقرار

مدل کلاسیک: Layout و Link

طبق Getting started و مشخصات:

Layout شامل چیست؟

• expiration — تاریخ انقضا سیاست
• readme — توضیح اختیاری
• functionary keys — کلیدهای عمومی برای verify لینک‌ها
• signatures — امضای Layout با کلید(های) owner
• steps — هر گام: نام یکتا، functionaryهای مجاز، قوانین materials/products
• inspections — چک‌های سمت verify

Link چگونه ساخته می‌شود؟

ابزارهایی مثل in-toto-run فرمان را wrap می‌کنند و ثبت می‌کنند:

• materials — مسیر و hash فایل‌ها قبل از اجرا
• products — مسیر و hash بعد از اجرا
• فرمان، کد برگشت، stdout/stderr (طبق پیاده‌سازی)
• امضا با کلید functionary → فایل .<step>.<keyid>.link

# مفهومی — نام ابزار بسته به پیاده‌سازی Python/Go
in-toto-run -n build -k alice.key -m src/ -p out/ -- go build -o out/app ./...

گام بدون فرمان (مثلاً review دستی) هم می‌تواند فقط materials را attest کند.

Verification (in-toto-verify)

Verifier نیاز دارد به: Layout، فایل‌های link، کلید عمومی owner.

بررسی‌ها:

1. Layout با کلید owner امضا شده و منقضی نشده
2. برای هر step، آستانهٔ لازم از linkهای معتبر وجود دارد
3. لینک‌ها توسط functionary مجاز امضا شده‌اند
4. materials/products با artifact rules جورند
5. inspections اجرا و قوانینشان چک می‌شوند

موفق = زنجیره مطابق سیاست اعلام‌شده؛ سپس نصب/deploy عادی.

Artifact rules — چسب زنجیره

قوانین روی materials و products تعیین می‌کنند فایل‌ها چطور بین گام‌ها جریان یابند، مثلاً:

• محصول گام checkout باید مادهٔ گام build باشد
• فایل‌های غیرمجاز ظاهر نشوند
• MATCH / CREATE / DELETE / MODIFY (طبق schema مشخصات)

این همان «لینک رمزنگاری‌شده» بین مراحل است که SBOM امضاشدهٔ تکی معمولاً ندارد.

Attestation Framework (ITE-6)

علاوه بر مدل Layout/Link کلاسیک، جامعه in-toto Attestation Framework را معرفی کرد:

Attestation = metadata احرازهویت‌شده درباره artifactها و فرایندهایی که آن‌ها را می‌سازند.

ساختار مفهومی:

Envelope (امضا)
  └── Statement
        ├── subject: artifactها (digest)
        └── predicateType + predicate: ادعای خاص

Predicateهای رایج اکوسیستم:

ITEهای دیگر (مثل ITE-4) اجازه می‌دهند artifact با URI عمومی (نه فقط path محلی) شناسایی شود — مناسب registry و منابع remote؛ hash روی محتوا است نه روی خود رشته URI.

in-toto در برابر SLSA، Sigstore، SBOM

طبق FAQ رسمی SLSA: in-toto لایه بدون‌نظر برای بیان اطلاعات زنجیره است؛ SLSA مشخص می‌کند برای رسیدن به سطح معین چه اطلاعاتی باید در آن metadata باشد.

پیاده‌سازی‌های Go/Java/Rust و ابزارهایی مثل cosign، SLSA GitHub Generator، و پلاگین Jenkins از APIهای provenance مرتبط استفاده می‌کنند.

ابزارها و زبان‌ها

شروع پیشنهادی: Docs → Getting started → Basic Demo → سپس Attestation برای CI مدرن.

جریان عملی در CI/CD امروزی

Developer PR
    → code review (attestation اختیاری)
    → CI build (SLSA Provenance / in-toto link)
    → SBOM predicate
    → push image به [Harbor](/blog/harbor-cloud-native-registry-guide/)
    → امضا Cosign + ذخیره attestation
    → [Flux](/blog/flux-cd-gitops-kubernetes-guide/) / [Argo](/blog/argo-project-kubernetes-gitops-cicd/) / admission
         verify layout یا policy (Kyverno/OPA/Binary Auth)
    → deploy فقط اگر verify OK

Admission روی Kubernetes می‌تواند بدون نصب کامل Layout کلاسیک، حداقل provenance SLSA را از registry بخواند — باز هم ریشه در مدل attestation in-toto است.

Adopters و اکوسیستم

سایت رسمی بخش Adoptions and Integrations دارد. در عمل با موارد زیر هم‌نشینی رایج است:

• Sigstore / cosign
• SLSA generators روی GitHub Actions
• Jenkins in-toto plugin
• سیاست‌های Binary Authorization / admission
• CNAB و ابزارهای بسته (با URIهای ITE-4)

امنیت و محدودیت‌ها

گزارش باگ: بخش Security در docs.

مقایسه با رویکردهای نزدیک

چه زمانی in-toto؟

✅ استفاده کنید

• می‌خواهید سیاست چندگامی (checkout → test → build → package) قابل verify باشد
• چند تیم/سیستم روی زنجیره با کلیدهای جدا
• پایه برای SLSA و attestation در registry
• ممیزی: «ثابت کن این باینری از این مسیر آمده»

⚠️ انتظارات غلط

Best practices

1. Layout را در Git نگه دارید؛ امضا و توزیع کلید owner را جدا و محدود کنید
2. برای build از attestation SLSA Provenance + ذخیره در registry/Harbor استفاده کنید
3. گام‌های حساس را با threshold چند امضا تعریف کنید
4. inspections را برای چک‌های سمت مصرف‌کننده (مثلاً unpack + hash) جدی بگیرید
5. انقضای Layout و چرخش کلید را در runbook بیاورید
6. CI را functionary کنید نه لپ‌تاپ توسعه‌دهنده برای گام release
7. Predicateهای استاندارد (Provenance، SPDX) را به schemaهای سفارشی خام ترجیح دهید مگر نیاز خاص
8. Verify را در CD/admission gate بگذارید نه فقط «مستند روی کاغذ»
9. با Sigstore transparency log، انکارناپذیری عمومی را تقویت کنید
10. Demo رسمی را یک‌بار end-to-end روی lab ببرید قبل از طراحی Layout سازمانی

جمع‌بندی

in-toto به کاربر نهایی (یا دروازه استقرار) اجازه می‌دهد نپرسد «آیا فایلی امضا شده؟» بلکه بپرسد: آیا کل مسیر اعلام‌شده، با عامل‌های مجاز، بدون شکستن زنجیره hash، طی شده است؟

قدم بعدی

1. in-toto.io → Learn More / Get started / Demo
2. Demo پایتون را روی یک repo نمونه اجرا کنید (layout → run → verify)
3. یک build CI با SLSA Provenance و cosign attest روی ایمیج
4. Policy پذیرش در cluster: فقط ایمیج با provenance معتبر
5. Layout سازمانی برای مسیر source → build → sign → deploy با Flux یا Helm chartهای امضاشده

منابع

• in-toto — in-toto.io
• Documentation
• Getting started
• GitHub — in-toto/in-toto
• Attestation Framework
• ITE (enhancements)
• SLSA and in-toto
• SLSA FAQ — relation to in-toto
• Harbor (مقاله P30Light)
• Flux (مقاله P30Light)

منتشر شده در P30Light — بخش امنیت شبکه.