Подозрительное обновление и восстановление
Подозрительное обновление требует сохранить основание разбирательства и ограничить дальнейшее воздействие. Простое удаление node_modules или возврат старой версии не отвечает на вопрос, какие полномочия уже могли быть использованы. В последнем уроке составим локальный учебный план изоляции и восстановления.
Сценарий «Контура выпуска» вымышленный: у lab-native в модели появилась неизвестная операция install-скрипта. Настоящий инцидент, вредоносный пакет или утечка ProfessorWeb не обнаружены. Никакие операционные действия не выполняются.
Сначала область и состояние выполнения
Первый вопрос — успел ли подозрительный код исполниться. В нашем сценарии состояние not_run: изменение увидели до установки. Поэтому пока обсуждается отказ от будущего выполнения и разбор модели. Если в настоящем проекте скрипт уже запускался, круг вопросов шире: какие файлы, сеть и полномочия были доступны этой стадии. Нельзя переносить вывод раннего обнаружения на исполненный инцидент.
В incident-plan.md сохраняем источник подозрения, версии до и после, исходный diff, время обнаружения и известные действия. Документ отделяет факт от гипотезы. «В модели появился новый скрипт» — факт нашего fixture. «Он похищает токены» — гипотеза, для которой нет настоящего исходника и наблюдения. Сильную формулировку нельзя добавлять ради драматичности урока.
План изоляции относится к затронутой стадии. Для будущей установки она остаётся остановленной. Для уже выполнявшегося CI могут понадобиться ограничение runner, остановка выпуска и разбор доступных полномочий. Конкретные реальные действия должны следовать процессу проекта и соответствующему доступу. Наш Markdown описывает последовательность вопросов, не отправляет команды в инфраструктуру.
Не уничтожайте исходные сведения раньше разбирательства. Сохранённый lockfile, архив, конфигурация и журналы помогают понять предмет. Удаление рабочей папки может стереть полезное состояние. При этом доказательства нужно хранить с ограниченным доступом, если они содержат секреты или данные. Учебный архив специально не содержит таких сведений.
Возврат старой зависимости сам по себе не отзывает уже доступные токены и не очищает изменённый артефакт. Для исполненного сценария потребуется отдельная оценка полномочий и результата. Даже краткоживущий OIDC не делает последствия автоматически нулевыми: разрешённая операция могла состояться. Карта стадий показывает, что следует проверять после остановки.
Восстановление через известное состояние
Для будущего восстановления выбираем известную исходную ревизию, согласованное дерево, проверенную политику скриптов и чистое окружение. Новый артефакт должен получить собственные фактические сведения. Нельзя считать старый локальный ZIP безопасным только потому, что его имя выглядит прежним. Происхождение и байты остаются самостоятельными вопросами.
План содержит критерий возвращения к выпуску: причина разобрана до достаточной границы, полномочия проверены, состояние входа известно, артефакт принят соответствующей ролью. В лаборатории все критерии planned, потому что операций не было. Список не является выполненным восстановлением и не предполагает автоматическую публикацию.
После сценария добавим профилактическое изменение. Например, новое разрешение install-скрипта требует карточки конкретной версии, а стадия сборки больше не имеет постоянного токена записи. Такое изменение связано с обнаруженной границей доверия. Не нужно расширять план до универсального перечня всех мер безопасности, которые не относятся к механизму этого случая.
Результат серии — полный авторский пакет: граф, модели дерева, политика, ревью, advisory, состав артефакта, план CI, доверие публикации и сценарий восстановления. Каждый документ имеет происхождение и статус. Они помогают готовить собственный процесс, сохраняя различие плана, исполнения и подтверждённого результата.
При обсуждении восстановления важно назначить ответственного за неизвестное. Если никто не устанавливает, был ли скрипт исполнен, команда может бесконечно спорить о теоретическом риске. В учебном документе роль demo-maintainer должна получить конкретное свидетельство стадии. При отсутствии такого основания статус остаётся unknown, а решение выбирается с учётом этой границы.
Завершите сценарий короткой историей решений. Почему установка была остановлена? Какие сведения сохранены? Почему выбрана прежняя модель? Что не проверено? Такая история позволит следующему человеку понять процесс без догадок по текущей версии package.json. Именно это делает курс полезным для сопровождения проекта, а не только для чтения о последних возможностях npm.
| Часть плана | Граница действия |
|---|---|
| Состояние выполнения | Сначала различаются остановленное до запуска изменение и код, который уже имел доступ к среде. |
| Сохранение основания | Исходные данные не уничтожаются ради быстрого возврата и не выдаются за доказанное вредоносное поведение. |
| Полномочия | Возврат версии не считается отзывом уже доступных секретов либо отменой состоявшегося выпуска. |
| Восстановление | Требует известного входа и нового принятого результата, который в локальной подготовке остаётся планом. |
Разбор границы остановленного сценария
Найдите в плане execution_state not_run. Это существенно меняет первую задачу: сохраняем подозрительную модель и не продолжаем установку, но не объявляем уже совершённую утечку. Для исполненного случая потребуется другая ветка с анализом доступных ресурсов. Сценарий курса намеренно сохраняет обе логики, не смешивая факт нашего примера и условный вариант.
При восстановлении отдельно назовите источник нового результата. Если просто вернуть старое package.json, могут остаться изменённые рабочие файлы, кеш или артефакт. В настоящем исполненном случае их состояние придётся выяснить. У нашей лаборатории таких фактических изменений нет, поэтому документ не предлагает выполнять разрушительную очистку в рабочем каталоге ProfessorWeb.
Ветку отзыва полномочий также нельзя заполнить автоматически. Сначала устанавливают, какие права были доступны и какие операции могли произойти. Долгоживущий секрет и OIDC-процесс имеют разные свойства, но оба требуют внимания к фактически возможному действию. Возврат версии зависимости не заменяет этот разбор. Наш план сохраняет вопрос как отдельную карточку владельца инфраструктуры.
Превратите профилактическое решение в конкретное изменение договора. Например, approval версии должен ссылаться на source_review, а release принимает известный artifact_id. Общие пожелания «усилить безопасность» трудно выполнить и проверить. Связь с обнаруженной границей делает последующую работу небольшой и понятной.
Завершение учебного сценария не является разрешением публикации. В этой серии готовы документы и полный собственный код примера; команды, CI, установки, аудит, проверки и развертывание не выполнялись. Когда появится отдельный запрос на практику, потребуется актуальная среда и фактические свидетельства. Такой переход сохраняет честность материала и позволяет использовать его как основу сопровождаемого процесса.
Полный основной артефакт incident-plan.md выбранного состояния:
# DEMO-INCIDENT-01
fictional:true. execution_state:not_run. Настоящий инцидент не обнаружен.
Основание: в модели v2 появилась неизвестная деталь install-скрипта. Факт кражи данных не установлен. До запуска: сохранить модели и diff, не продолжать установку, назначить source_review.
Условная ветка уже выполненного кода: определить стадию, доступные ресурсы и действия; сохранить исходники/журналы с подходящим доступом; оценить полномочия отдельно от возврата версии. Конкретные операции инфраструктуры здесь не выполняются.
Восстановление как будущий план: известная ревизия, согласованное дерево, ограниченная политика, чистая среда, новый принятый артефакт. Все критерии planned. Публикация не разрешается этим документом.Все исходники серии: папка lesson-10 содержит полный самостоятельный снимок, собственный проект и авторские модели. Исполнение примеров, npm, установки, аудит, тесты, CI, настройки и публикация не выполнялись.