Продавати програмне забезпечення уряду США? Спершу дізнайтеся про атестацію безпеки

Продавати програмне забезпечення уряду США? Спершу дізнайтеся про атестацію безпеки

Мітка часу: 7 серпня 2023 р., 10:00
Продавати програмне забезпечення уряду США? Знати атестацію безпеки First PlatoBlockchain Data Intelligence. Вертикальний пошук. Ai.

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

Нові вимоги до безпеки програмного забезпечення: що змінилося?

За останні кілька років подібні резонансні інциденти безпеки вплинули на SolarWinds і пакет з відкритим кодом log4j звернули увагу уряду на безпеку програмного забезпечення. Починаючи з Указ Білого дому 14028 щодо покращення кібербезпеки країни в травні 2021 року низка дій протягом останніх двох років призвела до набору чітких вимог, які впливають на будь-якого державного постачальника програмного забезпечення.

У майбутньому будь-яка організація, яка продає програмне забезпечення уряду США, повинна буде підтвердити, що вона відповідає безпечним методам розробки програмного забезпечення, викладеним урядом у NIST Secure Software Development Framework.

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

На початку червня уряд підтвердив ці вимоги в Доповідна записка ОМБ М-23-16 (PDF) і встановіть терміни відповідності, які швидко наближаються — імовірно, вони настануть у четвертому кварталі цього року (для критичного програмного забезпечення) та першому кварталі наступного року (для всього іншого програмного забезпечення).

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

Відповідно до М-23-16 штраф за невиконання є суворим:

«[Федеральне] агентство повинно припинити використання програмного забезпечення якщо агентство визнає документацію виробника програмного забезпечення незадовільним або якщо агентство не може підтвердити, що виробник визначив методи, які він не може підтвердити…»

Особливо складний випадок відкритого коду

Оскільки багато організацій глибше занурюються у вимоги до атестації, вони виявляють, що відповідність вимогам, особливо в стислі терміни, може виявитися складним завданням. NIST SSDF — це складна структура безпеки, і організаціям потрібен час, щоб не тільки забезпечити дотримання цих практик, але й детально задокументувати свою практику.

Але ще більш страшним є те, що уряд просить постачальників засвідчити практику безпеки всього свого програмного продукту, який включає компоненти з відкритим кодом у цьому програмному забезпеченні. Сьогодні сучасне програмне забезпечення часто складається в основному з компонентів з відкритим кодом, які були зібрані воєдино, разом із деяким спеціальним програмним забезпеченням. У нашому дослідженні ми це виявили понад 90% програм містять компоненти з відкритим кодом, і в багатьох випадках відкритий вихідний код становить понад 70% бази коду.

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

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

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

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

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

Складний, але необхідний крок вперед

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

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

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