Перевіряйте, що потрапляє до випуску

Запитайте, чи потрібна залежність

Агент може запропонувати пакет, який нібито розв’язує проблему. Рекомендація — це пропозиція, а не доказ існування або придатності пакета. Перевірте точний реєстр, видавця, назву пакета та версію перед встановленням.

Для вигаданого експорту CSV середовище виконання вже може забезпечувати потрібну поведінку. Новий пакет усе одно може бути доречним, але він додає обов’язки супроводу та шляхи виконання. Порівняйте зусилля на реалізацію з постійними обов’язками щодо залежності.

Перегляньте ліцензію та підтримуване середовище виконання. Перевірте активність супроводу й відповідні повідомлення про вразливості. Знайома назва може позначати інший пакет в іншому реєстрі. Успішне встановлення показує лише те, що встановлення завершилося.

Перевірте поведінку встановлення та збірки

Залежності можуть виконувати код під час встановлення або збірки. Обмежуйте облікові дані й мережевий доступ у цих середовищах. Не надавайте продуктивних секретів задачі, що обробляє недовірений pull request.

Використовуйте закомічений lockfile там, де екосистема це підтримує. Вимагайте, щоб збірка дотримувалася цього файлу. Переглядайте зміни lockfile разом зі зміною вихідного коду, зокрема неочікувані транзитивні пакети. Фіксація версій покращує відтворюваність, але не робить вразливу версію безпечною.

SSDF від NIST охоплює захист програмного забезпечення та практик розробки протягом життєвого циклу. Використовуйте цей ширший погляд під час проєктування середовища збірки. Прочитайте фреймворк.

Відрізняйте інвентаризацію від походження

Перелік компонентів програмного забезпечення, або SBOM, фіксує склад програмного забезпечення. Він допомагає визначити уражені випуски, коли компонент викликає занепокоєння. Сам по собі він не доводить безпеки компонентів.

Відомості про походження описують, як створено артефакт. SLSA визначає формат таких відомостей про збірку та її вхідні дані. Перевірка має пов’язати цю інформацію з довіреним виробником і артефактом, який ви плануєте використати. Самого файлу з назвою «provenance» недостатньо. Походження за SLSA.

Для сервісу експорту запишіть ланцюг, який можна перевірити:

1. Переглянутий commit визначає прийнятий вихідний код.
2. Збірка визначає свої вхідні дані та середовище виконання.
3. Артефакт має сталий digest.
4. Перевірки визначають артефакт або вихідний код, які вони перевірили.
5. Запис розгортання визначає артефакт, поміщений у цільове середовище.

Не виконуйте іншу збірку після схвалення без визначеного процесу перевірки. Змінний тег, наприклад latest, згодом може вказувати на інший образ.

Визначте значення виявленої проблеми

Виявлена вразливість потребує контексту: ураженої версії, досяжної поведінки, доступності для атаки, наявного виправлення та наслідків. Записуйте докази, на яких ґрунтується кожен тимчасовий виняток. Призначайте відповідального, строк дії та умову перегляду.

Не вимикайте весь сканер через одну незастосовну знахідку. Не заявляйте про чистий результат, якщо сканування не завершилося. Тайм-аут, непідтримуваний пакет або недоступне джерело повідомлень про вразливості означають відсутність доказів.

Нарешті, плануйте оновлення після випуску. Нові повідомлення можуть стосуватися артефакту, прийнятого вчора. Відповідальному за сервіс потрібні інвентаризація, процес реагування та спроможність створити виправлений випуск.

Продовжте з уроку про безперервне керування вразливостями, щоб пов’язати повторювані сканування з перевіреними виправленнями в продуктивному середовищі.