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

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

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

Принципи

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

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

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

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