Дизайн аудиту ланцюга постачання

Аудит ланцюга постачання підтверджує ефективність заходів контролю залежностей репозиторію виключно на основі файлів, що були зафіксовані у репозиторії. Аудит, який можна обдурити (або який проходить, навіть якщо нічого не перевіряє), гірший за його відсутність, оскільки зелений результат у такому разі свідчить про неперевірений стан. Наведені нижче принципи не дозволяють пройти аудит у разі порушення контролю та роблять його проведення доцільним.

Щодо того, які заходи контролю існують і чому, див. розділ «Безпека ланцюга постачання»; що робити, коли аудит не проходить у вашому PR, див. секцію аудиту документів залежностей.

Принципи

1. Перевірка виключно на основі файлів, що потрапили у репозиторій. Аудит зчитує блокування, маніфести, .npmrc та netlify.toml (ніколи — мережу чи дерево встановлених файлів), тому він працює швидко, в автономному режимі і не піддається впливу стану, який повинен перевіряти.
2. Включати цілі структури до списку дозволених; не використовуйте шаблони у списку заборонених. Регулярний вираз у списку заборонених для формату конфігурації пропускає правильні варіанти, яких він не перераховує (ключі TOML у лапках, з крапками та у вбудованих таблицях обходять список заборонених для ключів env). Фіксація всієї перевіреної структури (точні набори ключів, точні значення) є надійнішою і зазвичай коротшою.
3. Виконання синтаксичного аналізу; не сканування рядків. Синтаксичний аналізатор формату визначає його семантику. Регулярний вираз на рівні рядка неправильно моделює її, не повідомляючи про це: таблиця контексту, яку він не розпізнає, все одно має значення для Netlify.
4. Точні ідентифікатори; відсутність збігу за префіксом або прапорцем. Збіг за префіксом допускає додавання доповнення && npm install ... до скрипту, якому аудит довіряє за назвою.
5. Закрита помилка у разі відсутності. Кожна перевірка підрахунку містить перевірку мінімального значення, тому порожній вхідний параметр не може стандартно пройти перевірку; записи, у яких відсутнє очікуване поле, викликають помилку, а не пропускаються.
6. Привʼязка до ідентичності, якій довіряє npm. npm визначає ідентичність пакунка за його URL-адресою в реєстрі resolved, а не за ключем блокування чи полем version, тому аудит повʼязує всі три елементи разом; перевірка лише тих полів, яким npm не довіряє, дозволяє пройти перевірку навіть у разі невідповідності, на яку npm би зреагував.
7. Один «дім» на кожну інваріанту. Список, що перевіряється у двох файлах, може змінюватися; аудит імпортує спільні значення з модуля-власника, а модульний тест цього модуля фіксує вміст.
8. «Спочатку червоне». Новій перевірці довіряють лише після того, як навмисно пошкоджений вхідний параметр призвів до її провалу. Хибний «зелений» стан гірше за «червоний».
9. Асерції визначають очікуваний стан, а у разі рутинних спрацьовувань — і виправлення: асерція allowScripts вказує версію, до якої має бути переміщений запис у результаті підвищення версії залежності, тому повідомлення про помилку є і виправленням.
10. Вкажіть межі сфери дії. Поверхні, які аудит навмисно не охоплює, вказуються в аудиті та документації залежностей, щоб відсутність охоплення ніколи не сприймалася за перевірене охоплення.
11. Кожна перевірка мусить виправдовувати своє існування. Безпека забезпечується завдяки конструкції засобів контролю та процесу перевірки, а не накопиченням тверджень: кожне з них обтяжує учасників та розробників при кожному втручанні. Перевірка має місце лише тоді, коли вона виявляє те, чого рецензія явно не може виявити: непрозору поверхню з високим рівнем авторитету, таку як блокування, або семантику, занадто незрозумілу, щоб її можна було помітити на око. Якщо засіб контролю вже не працює під час виконання, аудит не підтверджує його знову; коли витрати на підтримку перевірки перевищують її цінність для виявлення, її скорочення є правильним кроком, а не послабленням.

Принципи в аудиті

Один приклад на кожен принцип; тестовий файл є авторитетним переліком тверджень.