Стратегії ланцюга постачання програмного забезпечення для парирування атак плутанини залежностей

Стратегії ланцюга постачання програмного забезпечення для парирування атак плутанини залежностей

Стратегії ланцюга постачання програмного забезпечення для парирування атак плутанини залежностей PlatoBlockchain Data Intelligence. Вертикальний пошук. Ai.

"Що в імені? Те, що ми називаємо трояндою, під будь-якою іншою назвою пахло б так само солодко». Коли Шекспір ​​писав ці слова («Ромео і Джульєтта», дія 2, сцена 2) у 1596 році, він казав, що ім’я — це лише умовність. Це не має внутрішнього значення. Джульєтта любить Ромео за те, ким він є, а не за його ім'я.

Але сам того не знаючи, Шекспір ​​також описував атаки плутанини залежностей.

Плутанина залежностей виникає, коли пакети, які ви використовуєте у своєму коді, не є вашими. Вони мають однакові назви, але це не ваш код, який працює у виробництві. Така ж назва, але одна упаковка пахне трояндою, а інша... смердить.

За оцінками останніх досліджень, від 41% до 49% організацій піддаються ризику атак, пов’язаних із залежністю. Нове дослідження OX Security показує, що коли організація піддається ризику атаки плутанини залежностей, 73% її активів є вразливими. Дослідження було зосереджено на середніх і великих організаціях (1K+, 8K+, 80K+ співробітники) у багатьох секторах — фінансах, іграх, технологіях і медіа — і виявили ризик у кожному секторі в організаціях будь-якого розміру. Дослідження також виявило, що майже всі програми з понад 1 мільярдом користувачів використовують залежності, які вразливі до плутанини залежностей.

Ця стаття має на меті допомогти вам зрозуміти плутанину залежностей і як цьому запобігти.

Подвійний, подвійний

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

Менеджери пакетів часто використовуються для встановлення залежностей і їх оновлення. Вони сканують загальнодоступні та приватні реєстри на предмет назви пакета та, за інших рівних умов, вибирають найвищий номер версії. Зловмисники користуються цим, розміщуючи «фіктивний» пакет у публічному реєстрі з такою ж назвою, але вищою версією.

Коли менеджер пакунків натрапляє на два ідентичні пакунки, один у загальнодоступному реєстрі, а інший у приватному реєстрі, це викликає плутанину — звідси й назва «плутанина залежностей». Оскільки ці два пакунки ідентичні, менеджер автоматично вибере для встановлення пакет із вищою версією - у цьому випадку шкідливий пакет зловмисника.

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

Праця і біда

Існують різні підходи до атаки плутанини залежностей.

  • Простір імен. Шляхом завантаження бібліотеки зловмисного програмного забезпечення до загальнодоступного реєстру, наприклад Python Package Index (PyPI) або JavaScript реєстр npm - тобто названий так само довіреної бібліотеки, що використовується внутрішньо, системи, які пропускають перевірку простору імен/URL або не примусово отримують із приватного реєстру, можуть помилково втягнути шкідливий код. The недавній інцидент плутанини залежностей PyTorch є одним з таких прикладів.
  • Підробка DNS. Використовуючи таку техніку, як DNS-спуфінг, можна скерувати системи витягувати залежності зі зловмисних сховищ, одночасно відображаючи те, що виглядає як законні внутрішні URL-адреси/шляхи.
  • Написання сценаріїв. Змінюючи сценарії збірки/встановлення або постійна інтеграція/безперервна доставка (CI/CD) конвеєрних конфігурацій, системи можна обманом змусити завантажити програмні залежності зі зловмисного джерела, а не з локального сховища.

Речі зроблено добре та з турботою

Щоб захиститися від плутанини залежностей, запровадьте ці практики.

  • Встановіть політики в менеджері пакетів. Заборонити менеджерам пакунків надавати пріоритет публічному пакету над приватним пакетом.
  • Завжди включайте файл .npmrc. Якщо ви використовуєте популярний NPM як менеджер пакунків, завжди включайте файл .npmrc, у якому вказується, куди завантажувати пакети в межах певної організації.
  • Зарезервуйте назву пакета в публічному реєстрі. Інший спосіб захисту від атак плутанини залежностей полягає в тому, щоб зарезервувати ім’я пакета в загальнодоступному реєстрі, щоб зловмисники не могли його використовувати і, отже, не могли «обманом» змусити менеджера пакетів встановити шкідливий пакет.

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

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

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

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

Вихід, переслідуваний ведмедем

Атаки плутанини залежностей становлять серйозну та неминучу загрозу кібербезпеці для організацій у всьому світі. Близько половини всіх організацій знаходяться в зоні ризику, і 73% активів цих організацій є відкритими. Щоб протистояти цій зростаючій загрозі, організації повинні впроваджувати надійні превентивні заходи та застосовувати найкращі практики кібербезпеки.

Троянди Шекспіра, можливо, передвіщали ризик нападів плутанини протягом сотень років, але інша цитата Барда може містити певну мудрість для захисту від них: «Нехай кожне око домовляється за себе і не довіряйте жодному агенту». (Багато шуму з нічого, дія 2, сцена 1)

Часова мітка:

Більше від Темне читання