#supply_chain_security — Public Fediverse posts

«Fix typo»: как в PHP закоммитили бэкдор и почему composer install — это акт доверия

Каждый composer install — это акт доверия: вы запускаете на CI и в проде код, который собрал и опубликовал кто‑то другой, а проверяете обычно лишь хеш в composer.lock. Но хеш отвечает на вопрос «тот же ли это байт, что вчера», а не «кто и из чего его собрал». Реальные инциденты показывают цену этого доверия: в 2021-м в исходники PHP закоммитили бэкдор от имени Расмуса Лердорфа; в xz вредонос жил в release‑архиве, которого не было в git; у популярного GitHub Action переписали теги и слили секреты из тысяч пайплайнов. Между кодом на ревью и артефактом в вашем vendor/ — длинная цепочка, и атаковать можно любое звено. В статье сначала разбор: как устроены эти атаки и почему GPG, хеши и composer audit закрывают цепочку лишь частично. Затем ответ индустрии — Sigstore: подпись без управления ключами. И главное — практика на PHP: подписываем релиз в GitHub Actions без единого секрета, проверяем эталонным gh, из CLI и прямо из кода с типизированным SLSA‑провенансом, мониторим журнал Rekor. С рабочим кодом и честной моделью угроз: что подпись ловит, а что нет. Разобрать цепочку поставок ПО

https://habr.com/ru/articles/1048056/

#supply_chain_security #Sigstore #Rekor #Fulcio #SLSA #Composer #Packagist #аттестация_артефактов #github_actions #php

«Fix typo»: как в PHP закоммитили бэкдор и почему composer install — это акт доверия

Каждый composer install — это акт доверия: вы запускаете на CI и в проде код, который собрал и опубликовал кто‑то другой, а проверяете обычно лишь хеш в composer.lock. Но хеш отвечает на вопрос «тот же ли это байт, что вчера», а не «кто и из чего его собрал». Реальные инциденты показывают цену этого доверия: в 2021-м в исходники PHP закоммитили бэкдор от имени Расмуса Лердорфа; в xz вредонос жил в release‑архиве, которого не было в git; у популярного GitHub Action переписали теги и слили секреты из тысяч пайплайнов. Между кодом на ревью и артефактом в вашем vendor/ — длинная цепочка, и атаковать можно любое звено. В статье сначала разбор: как устроены эти атаки и почему GPG, хеши и composer audit закрывают цепочку лишь частично. Затем ответ индустрии — Sigstore: подпись без управления ключами. И главное — практика на PHP: подписываем релиз в GitHub Actions без единого секрета, проверяем эталонным gh, из CLI и прямо из кода с типизированным SLSA‑провенансом, мониторим журнал Rekor. С рабочим кодом и честной моделью угроз: что подпись ловит, а что нет. Разобрать цепочку поставок ПО

https://habr.com/ru/articles/1048056/

#supply_chain_security #Sigstore #Rekor #Fulcio #SLSA #Composer #Packagist #аттестация_артефактов #github_actions #php

«Fix typo»: как в PHP закоммитили бэкдор и почему composer install — это акт доверия

Каждый composer install — это акт доверия: вы запускаете на CI и в проде код, который собрал и опубликовал кто‑то другой, а проверяете обычно лишь хеш в composer.lock. Но хеш отвечает на вопрос «тот же ли это байт, что вчера», а не «кто и из чего его собрал». Реальные инциденты показывают цену этого доверия: в 2021-м в исходники PHP закоммитили бэкдор от имени Расмуса Лердорфа; в xz вредонос жил в release‑архиве, которого не было в git; у популярного GitHub Action переписали теги и слили секреты из тысяч пайплайнов. Между кодом на ревью и артефактом в вашем vendor/ — длинная цепочка, и атаковать можно любое звено. В статье сначала разбор: как устроены эти атаки и почему GPG, хеши и composer audit закрывают цепочку лишь частично. Затем ответ индустрии — Sigstore: подпись без управления ключами. И главное — практика на PHP: подписываем релиз в GitHub Actions без единого секрета, проверяем эталонным gh, из CLI и прямо из кода с типизированным SLSA‑провенансом, мониторим журнал Rekor. С рабочим кодом и честной моделью угроз: что подпись ловит, а что нет. Разобрать цепочку поставок ПО

https://habr.com/ru/articles/1048056/

#supply_chain_security #Sigstore #Rekor #Fulcio #SLSA #Composer #Packagist #аттестация_артефактов #github_actions #php

[Перевод] Пакетным менеджерам пора ввести период охлаждения

Когда злоумышленник получает доступ к учетной записи мейнтейнера или захватывает заброшенный пакет, вредоносная версия может разойтись по тысячам проектов быстрее, чем ее успеют заметить. Один из способов снизить риск — ввести период охлаждения для зависимостей: не устанавливать новую версию пакета сразу после публикации, а ждать несколько дней, пока сообщество и вендоры безопасности успеют отреагировать. Публикуем перевод статьи Эндрю Несбитта о dependency cooldown и о том, как этот подход реализуют разные пакетные менеджеры и инструменты обновления зависимостей: npm, pnpm, Yarn, Bun, Deno, pip, uv, Poetry, Bundler, Cargo, Dependabot, Renovate и другие. Отдельно в материале рассматриваются различия между относительными интервалами и абсолютными датами, проблемы временных меток, исключения для обновлений безопасности и ограничения подхода в разных экосистемах.

https://habr.com/ru/companies/codescoring/articles/1044132/

#пакетные_менеджеры #зависимости #supply_chain_security #open_source #npm #PyPI #RubyGems #Dependabot #Renovate #dependency_cooldown