Dockerfile змінили, але стара версія залишилася
Хтось змінює один рядок у Dockerfile, збірка проходить, CI стає зеленим — і команда вважає оновлення Node.js завершеним. За кілька днів перевірка знаходить стару версію в нічній задачі, про яку майже забули.
Це не обов’язково наслідок недбалості. Сучасне середовище виконання може одночасно жити в контейнерах, на віртуальних машинах, у CI runners, serverless-функціях і допоміжних скриптах. Репозиторій показує намір команди, але не доводить стан уже запущених систем.
Після червневого повідомлення Node.js про безпеку практичне запитання звучить не як «чи оновили ми Dockerfile?», а як «де саме ще працює affected version і яким доказом ми підтвердимо її заміну?»
Спочатку складіть карту місць, де працює Node.js
Почніть не зі сканера, а зі списку поверхонь. Додайте основні API та вебзастосунки, фонові обробники, cron-задачі, контейнери, VM, системи збірки, CI runners, serverless-функції та адміністративні інструменти.
Окремо перевірте шаблони базових образів і файли, які задають версію інструментів. Вони допомагають знайти джерело версії, але не замінюють перевірку запущеного процесу.
Для кожної поверхні потрібні щонайменше власник, середовище, спосіб розгортання та команда або запит, що повертає фактичну версію. Якщо компонента немає в інвентарі, її легко пропустити під час наступного оновлення.
Перетворіть повідомлення на перевірювані вимоги
Відкрийте офіційне повідомлення Node.js і випишіть підтримувані гілки, affected versions, fixed versions та умови, за яких проблема стосується системи. Не переносіть номер виправлення з однієї гілки в іншу й не визначайте його за назвою контейнерного тегу.
Якщо повідомлення описує додаткові умови експлуатації, використовуйте їх для визначення терміновості. Але відсутність очевидного шляху атаки не є доказом, що стару версію можна залишити без власника та строку оновлення.
Збирайте докази з того, що справді запущено
Команда node --version усередині запущеного контейнера, VM або runner показує більше, ніж змінений manifest. Для контейнера також запишіть дайджест образу. Тег може бути перепризначений, тоді як дайджест указує на конкретний вміст.
SBOM допомагає перевірити склад артефакту, але сам по собі не доводить, що цей артефакт працює у production. Зв’яжіть SBOM із дайджестом, а дайджест — із запущеним екземпляром.
Наскрізна таблиця може виглядати так:
| Поверхня | Фактичний доказ | Потрібне виправлення | Перевірка | Стан |
|---|---|---|---|---|
| API-контейнер | версія з процесу та дайджест | fixed version для його гілки | канарковий екземпляр і smoke-тест | у роботі |
| Нічна задача | версія з журналу запуску | fixed version для її гілки | ручний тестовий запуск | не почато |
| CI runner | версія з job | fixed version для його гілки | чиста повторна збірка | перевірено |
| Serverless-функція | версія активної конфігурації | підтримуване виправлене середовище | тестова подія | потребує перевірки |
Стани тут лише приклад. Важливо, щоб кожен запис мав власний доказ, а не успадковував статус головного сервісу.
Визначайте черговість за реальною експозицією
Першими оновлюйте системи, доступні з мережі, компоненти, що обробляють недовірені дані, а також процеси з доступом до секретів або важливих ресурсів. Далі врахуйте умови з офіційного повідомлення та наявність компенсаційних заходів.
Не відкладайте нічну задачу автоматично лише тому, що вона запускається рідко. Вона може обробляти зовнішні файли або мати ширші права, ніж основний застосунок.
Перевірте оновлення на малій частині системи
Канаркове розгортання має відповісти на два запитання: чи справді запущена fixed version і чи не зламалися важливі сценарії. Перевірте запуск процесу, підключення до залежностей, обробку типового запиту, фонові задачі та помилки в журналах.
Smoke-тест не замінює повний набір тестів. Його мета — швидко помітити проблеми сумісності перед ширшим розгортанням. Після цього поступово збільшуйте охоплення й спостерігайте за помилками, затримками та перезапусками.
План відкату не повинен повертати вразливе середовище виконання. За можливості підготуйте попередню версію застосунку, перебудовану на виправленому базовому образі.
Завершення означає повторну перевірку
Після розгортання знову отримайте версії із запущених процесів. Перевірте активні дайджести, довгоживучі VM, вимкнені за розкладом задачі та runners, які могли не перезапуститися.
Потім приберіть застарілі посилання, кеші й образи, які система ще може розгорнути випадково. Не видаляйте потрібні артефакти до перевірки відкату, але й не залишайте вразливий образ стандартним варіантом.
Якщо компонент поки не можна оновити, створіть явний виняток. Запишіть власника, причину, компенсаційний захід і дедлайн. Формулювання «оновимо пізніше» не дає команді способу перевірити завершення роботи.
Типові хибні ознаки успіху
- Pull request об’єднано, але старі екземпляри не перезапущено.
- Контейнер має новий тег, але його дайджест не перевірено.
- Сканер перевірив registry, але не активні VM чи CI runners.
- Основний API оновлено, а cron-задачі автоматично вважаються виправленими.
- Відкат повертає попередній застосунок разом зі старим Node.js.
Патч завершений не тоді, коли змінився файл у репозиторії. Він завершений, коли для кожної відомої поверхні є фактична версія, потрібне виправлення, результат перевірки та зрозумілий стан.
Джерела
- Node.js — June 2026 security releases: https://nodejs.org/en/blog/vulnerability/june-2026-security-releases
- Офіційна стрічка блогу Node.js: https://nodejs.org/en/feed/blog.xml
Короткий чеклист
- виписати affected і fixed versions з офіційного повідомлення Node.js
- перевірити фактичну версію Node.js у кожному запущеному середовищі
- зіставити контейнери за дайджестами, а не лише за тегами
- провести канаркове розгортання та перевірити ключові сценарії
- повторно просканувати флот і зафіксувати всі винятки
Перевірка охоплення флоту виправленням Node.js
Допоможи перевірити, чи виправлена версія Node.js розгорнута в усьому нашому флоті. Вхідні дані: - офіційне повідомлення про безпеку або його URL; - перелік сервісів, контейнерів, VM, CI runners, cron-задач і serverless-функцій; - фактичні версії Node.js, дайджести образів і доступні SBOM; - рівень зовнішньої доступності кожного компонента; - обмеження на розгортання та відкат. Не вгадуй affected або fixed versions. Бери їх лише з наданого офіційного повідомлення. Познач відсутні дані як такі, що потребують перевірки. Поверни результат у Markdown: 1. короткий висновок про охоплення; 2. таблиця affected і fixed versions за підтримуваними гілками; 3. таблиця доказів із колонками: поверхня, фактична версія, дайджест, потрібне виправлення, спосіб перевірки, ризик, стан; 4. порядок розгортання; 5. план канаркового розгортання та smoke-тестів; 6. повторна перевірка після розгортання; 7. список винятків із власником, компенсаційним заходом і дедлайном.