Покупатель запрашивает подтверждение SLSA — какую услугу он запрашивает?
Покупатель указывает происхождение SLSA во время регистрации, не называя артефакт, платформу, уровень или приемочный тест. Используйте запись из пяти полей, чтобы направить запрос в нужную службу.
Не обязательно тот источник, который вы бы построили первым. Когда покупатель запрашивает происхождение SLSA во время адаптации, он обычно называет цель соответствия, а не результат, и четыре услуги могут удовлетворить этому предложению — создание происхождения, усиление системы сборки, внедрение политики проверки и проверка доказательств — ни одна из них не является взаимозаменяемой. Запрос направляется к нужному только после того, как вы закрепите пять полей: артефакт и его дайджест, платформу сборки, целевой уровень SLSA, подписывающую сторону или проверяющую сторону и приемочный тест покупателя.
Короткий ответ: маршрут по тому, что не учитывается в запросе.
Уровни цепочки поставок для артефактов программного обеспечения (SLSA) v1.2 — спецификация, опубликованная проектом SLSA и доступная 3 августа 2026 года по адресу slsa.dev/spec/v1.2/ — описывает постепенно усиливающиеся гарантии безопасности цепочки поставок программного обеспечения, организованные по трекам и уровням. Провенанс, как его определяет SLSA v1.2 в документе страница происхождения проекта SLSA (по состоянию на 3 августа 2026 г.), — это проверяемая информация, которая отслеживает артефакт по цепочке поставок, где, когда и как он был произведен. Аттестация — это подписанное заявление, содержащее эту информацию; SLSA рекомендует форматы подтверждения, включая происхождение.
Почему это важно для руководителя по продажам решений для безопасности цепочки поставок ПО: покупатель, упомянувший SLSA, назвал целевой стандарт, а не услугу. Одна и та же фраза может означать четыре разных объема работ. Направьте запрос по тому, каких данных в нем не хватает:
- Именован артефакт, дайджест и платформа сборки, но ничто не подтверждает сборку → генерацию происхождения.
- Платформа не может честно записывать входные данные, команды и выходные данные → усиление защиты системы сборки, прежде чем любая аттестация станет честной.
- Аттестация существует, но правило проверки не отображает приемочное испытание покупателя → реализация политики проверки.
- Подтверждение уже отправлено и отклонено → проверка доказательств.
- Два или более полей неизвестны → отправьте уточняющую запись, затем направьте.
Факты версии 1.2, которые станут основой разговора
Для версии 1.2 схема сборки-происхождения (опубликованной в рамках проекта SLSA, по состоянию на 3 августа 2026 г.) требуются два поля верхнего уровня для уровня сборки SLSA 1: buildDefinition и runDetails, а для runDetails, в свою очередь, требуется построитель. Конкретно:
- buildDefinition описывает, что и как было построено, включая внешние параметры, с которых началась сборка.
- runDetails записывает, как выполнялась сборка, и называет сборщика — идентификатор системы, создавшей артефакт.
- Схема также сохраняет субъект артефакта (созданный артефакт и его дайджест), метаданные вызова и правила проверки как отдельные части.
Суть, которую следует учитывать: создание документа с этими полями не дает уровня SLSA. Поля являются обязательными для форматирования; заслуживает ли их контент доверия, зависит от платформы сборки и от лица, подписавшего удостоверение разработчика. Вот почему запись из пяти полей определяет выбор между службами — генерация заполняет поля, усиление позволяет платформе заполнять их честно, политика проверки решает, что должен проверять проверяющий, а проверка доказательств проверяет то, что уже было создано.
Четыре услуги, пять критериев
Сравните четыре услуги по тем же пяти критериям, используя одну общую запись для каждого покупателя.
| Услуга | Артефакт и дайджест | Построить платформу | Целевой уровень | Подписывающая сторона или верификатор | Приемочный тест покупателя |
|---|---|---|---|---|---|
| Генерация Провенанса | Требуется заранее в качестве предмета аттестации | Предполагается, что можно записать сборку | Решает, какие поля содержит аттестация. | Вы подписываетесь как застройщик | Предоставляет доказательства, которые тест может принять |
| Укрепление системы сборки | Создает воспроизводимый артефакт и сначала переваривает | Объект работы | Решает, какую сборку гарантии должна добавить платформа. | Вы меняете то, на чем работает строитель | Делает возможным получение приемлемых доказательств |
| Реализация политики проверки | Требуется аттестация с проверяемым предметом | Актуально только в том случае, если на это ссылается политика. | Решает, какие правила проверки применяются | Вы настраиваете верификатор | Определяет, как оценивается тест. |
| Обзор доказательств | Повторно проверяет дайджест в существующей аттестации. | Чтение из существующих записей | По сравнению с уровнем, заявленным покупателем | Вы просматриваете; ты не подписываешь | Карты отвергли доказательства для теста |
Матрица решений
Компактная матрица маршрутизации на тех же полях:
| Если запрос… | …и | Маршрут |
|---|---|---|
| Называет артефакт, дайджест и платформу. | никакого подтверждения не существует | поколение происхождения |
| Называет уровень, который платформа не может честно записать. | покупатель ожидает реальных месторождений | усиление защиты системы сборки |
| Ссылается на свидетельство | ни одно правило проверки не соответствует приемочному тесту | реализация политики проверки |
| Сообщает об отклонении подтверждения | не говоря, какое поле не удалось | обзор доказательств |
| Оставляет большинство полей открытыми | ожидает имя службы сегодня | сначала уточняющая запись |
| Там, где приемочный тест покупателя читается как запрос доказательства SOC 2 — именованный тип доказательства без каких-либо дополнительных подробностей — применяется шаблон из нашего рассмотрения Запросы на получение доказательств SOC 2: в запросе указывается тип доказательства, а не поля, необходимые для его оценки. |
Рабочий пример: составной запрос на регистрацию
Иллюстративное составное сообщение Telegram — не запись о клиенте; нет реального покупателя, коммерческого предложения или срока:
«Для регистрации нам необходимо подтверждение SLSA для отправляемых вами артефактов. Наша служба безопасности проверит его на соответствие нашим критериям приемки, прежде чем мы одобрим поставщика. Можете ли вы подтвердить, что предоставили это?»
Запустите проверку по пяти полям:
- Артефакт и дайджест: без названия.
- Платформа сборки: не названа.
- Целевой уровень: не назван.
- Строитель-подписчик или верификатор: команда покупателя «проверит», что подразумевает, что вы будете действовать как подписавший-создатель — это умозаключение, а не констатируемый факт.
- Приемочное испытание покупателя: называется «критериями приемки» без содержания.
Два или более полей отсутствуют, поэтому правильный ответ сегодня — это уточняющая запись, а не обещание услуги: запросите артефакт и дайджест, платформу сборки, целевой уровень, любую существующую аттестацию и точный приемочный тест — кто проверяет, по какому правилу и по какому уровню.
Иллюстративное продолжение (все еще составное): если покупатель затем называет образ контейнера и его дайджест, размещенную платформу CI, целевой уровень сборки 1 и отсутствие существующей аттестации, то маршрутом является создание источника. Если вместо этого они назовут целевой уровень, одновременно подтвердив, что платформа не может записывать входные данные сборки, маршрут ужесточается. Этот метод не устраняет двусмысленность; ответы покупателя имеют значение.
Почему это важно: обещание неправильной услуги тратит впустую цикл покупателя и ваш авторитет. Если вы генерируете коммерческое предложение о происхождении, а реальным препятствием является то, что платформа не может записать сборку, результат не будет получен по прибытии. Запись из пяти полей также дает вам оправданную причину задавать вопросы: вы заполняете запись, которая понадобится покупателю для приемочного испытания, а не задерживаетесь.
Что остается неизвестным и кто должен это проверить: целевой уровень и приемочный тест принадлежат команде безопасности покупателя; способность платформы записывать сборки должна быть проверена вашей командой инженеров, а не предполагаться на странице продукта; и наличие любой предварительной аттестации должно быть проверено по реестру артефактов. Ничто из этого не может быть подтверждено только из регистрационного сообщения.
Если канал покупателя сам по себе является отслеживаемой группой Telegram, применяется та же дисциплина, которую мы рассматриваем при рассмотрении Telegram Проверки DPA поставщика мониторинга: канал показывает то, что было сказано; оно не подтверждает это. В собственном документе Telegram политика конфиденциальности (по состоянию на 3 августа 2026 г.) говорится, что боты являются независимыми сторонними службами, что доступ к сообщениям не является обязательным, а интерфейс показывает, какой режим применяется, и что сторонние разработчики ботов должны запрашивать разрешение перед доступом к данным. TOP Prospect применяет эту границу на практике: он обрабатывает только группы Telegram, к которым пользователь намеренно подключается и имеет к ним доступ, создает кандидатов для проверки человеком, а не для подтверждения фактов, оставляет решение за человеком и не связывается с членами группы автоматически. О том, как проверка канала отделяется от доказательств артефактов, см. в документе Telegram Компонент анализа бизнес-сигналов.
Ключевые факты: даты, цифры и то, что они не доказывают
-
Спецификация SLSA v1.2 — опубликована проектом SLSA, по состоянию на 3 августа 2026 г. (slsa.dev/spec/v1.2/); SHA-256 46edf6…e7e3ae. Описывает постепенно усиливающиеся гарантии безопасности цепочки поставок на всех этапах и уровнях.
-
Provenance, v1.2 — по состоянию на 3 августа 2026 г. (slsa.dev/spec/v1.2/provenance); SHA-256 9a176a…0e51e44. Поддающаяся проверке информация, отслеживающая артефакт: где, когда и как он был произведен; построение трассировок происхождения, сбор выходных данных в исходный код, отслеживание происхождения источников, версии исходных кодов и управление изменениями.
-
Происхождение сборки, v1.2 — по состоянию на 3 августа 2026 г. (slsa.dev/spec/v1.2/build-provenance); SHA-256 04a97c…170f647. Уровень сборки 1 требует buildDefinition и runDetails; runDetails требует сборки.
-
Политика конфиденциальности Telegram — текущая страница политики доступна 3 августа 2026 г. (telegram.org/privacy); SHA-256 9ae1e9…253786b. Боты — это независимые сторонние сервисы; доступ к сообщениям не является обязательным и отображается в интерфейсе; сторонним разработчикам ботов следует спросить разрешения.
Контекст измерения: значения SHA-256 являются отпечатками контента для подтверждения того, что цитируемая страница соответствует версии, полученной на дату доступа. Версии и даты закрепляют доказательства; они не измеряют намерение покупателя, и дата доступа не является крайним сроком соблюдения требований со стороны покупателя.
Часто задаваемые вопросы
Означает ли упоминание SLSA, что покупателю нужен именно документ о происхождении сборки? Нет. Упоминание SLSA указывает на целевой стандарт, а генерация данных о происхождении — лишь один из четырех маршрутов. Сопоставьте запрос с пятью полями — артефакт и дайджест, платформа сборки, целевой уровень, подписант-сборщик или верификатор, приемочный тест — и, если большинство полей пусты, сначала отправьте уточняющее сообщение.
Может ли один документ иметь уровень SLSA? Нет. Схема происхождения сборки версии 1.2 требует для уровня сборки 1 поля buildDefinition и runDetails с указанием сборщика, но это требования к формату. Надежность зависит от платформы сборки и подписанта аттестации, действующего от имени сборщика: документ описывает уровень, но не присваивает его.
Что нужно ответить, прежде чем обещать услугу? Краткое уточняющее сообщение со списком пяти полей: артефакт и дайджест, платформа сборки, целевой уровень SLSA, любая существующая аттестация и точный приемочный тест — кто проверяет, по какому правилу и на соответствие какому уровню.
Следующий шаг, который стоит сделать на этой неделе: превратить запись из пяти полей в одностраничный шаблон с копипастом уточняющего сообщения, чтобы следующий запрос на регистрацию, в котором имена маршрутов SLSA назывались в одном обмене вместо трех.
Часто задаваемые вопросы
Означает ли покупатель, называющий SLSA, что ему необходимо указать происхождение?
Нет. Упоминание SLSA указывает на целевой стандарт, а генерация данных о происхождении — лишь один из четырех маршрутов. Сопоставьте запрос с пятью полями — артефакт и дайджест, платформа сборки, целевой уровень, подписант-сборщик или верификатор, приемочный тест — и, если большинство полей пусты, сначала отправьте уточняющее сообщение.
Может ли документ сам по себе получить уровень SLSA?
Нет. Схема происхождения сборки версии 1.2 требует для уровня сборки 1 поля buildDefinition и runDetails с указанием сборщика, но это требования к формату. Надежность зависит от платформы сборки и подписанта аттестации, действующего от имени сборщика: документ описывает уровень, но не присваивает его.
Что мне следует отправить обратно, прежде чем обещать услугу?
Краткое уточняющее сообщение со списком пяти полей: артефакт и дайджест, платформа сборки, целевой уровень SLSA, любая существующая аттестация и точный приемочный тест — кто проверяет, по какому правилу и на соответствие какому уровню. Следующий шаг на эту неделю — превратить список в одностраничный шаблон с готовым уточняющим сообщением, чтобы следующий запрос на допуск с упоминанием SLSA направлялся за один обмен, а не за три.
Источники и дополнительное чтение
Как обнаруживается Signal, заслуживающий внимания
Методика показывает, как Top Prospect находит и упорядочивает Signals, которые стоит проверить, сохраняет исходный контекст Telegram, удаляет дубли и помогает определить порядок просмотра. Решение о дальнейших действиях остаётся за вами.
