Правярайце, што трапляе ў выпуск

Спытайце, ці патрэбная залежнасць

Агент можа прапанаваць пакет, які нібыта вырашае праблему. Гэта прапанова, а не доказ таго, што пакет існуе або падыходзіць. Праверце дакладны рэестр пакетаў, выдаўца, назву пакета і версію перад усталяваннем.

Для выдуманага экспарту CSV асяроддзе выканання ўжо можа забяспечваць патрэбныя паводзіны. Новы пакет усё роўна можа быць дарэчным, але дадае суправаджэнне і шляхі выканання. Параўнайце намаганні на рэалізацыю з пастаяннымі абавязкамі, якія стварае залежнасць.

Праверце ліцэнзію і падтрыманае асяроддзе выканання. Вывучыце актыўнасць суправаджэння і адпаведныя паведамленні пра бяспеку. Знаёмая назва можа абазначаць іншы пакет у іншым рэестры. Паспяховае ўсталяванне паказвае толькі тое, што ўсталяванне завяршылася.

Вывучайце паводзіны ўсталявання і зборкі

Залежнасці могуць выконваць код падчас усталявання або зборкі. Абмяжоўвайце ўліковыя даныя і сеткавы доступ у гэтых асяроддзях. Не давайце сакрэты production задачы, якая апрацоўвае недавераны pull request.

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

SSDF ад NIST ахоплівае абарону праграм і практыкі распрацоўкі на працягу жыццёвага цыкла. Улічвайце гэты шырэйшы погляд пры праектаванні асяроддзя зборкі. Прачытайце framework.

Адрознівайце пералік кампанентаў ад паходжання

Спецыфікацыя складу праграмнага забеспячэння, або SBOM, запісвае кампаненты праграмы. Яна дапамагае вызначыць закранутыя выпускі, калі кампанент выклікае занепакоенасць. Сама па сабе яна не пацвярджае бяспеку кампанентаў.

Звесткі пра паходжанне апісваюць, як быў створаны артэфакт. SLSA вызначае фармат provenance для інфармацыі пра зборку і яе ўваходныя даныя. Праверка павінна звязваць гэтую інфармацыю з давераным вытворцам і артэфактам, які вы збіраецеся выкарыстоўваць. Файла з назвай «provenance» недастаткова. SLSA provenance.

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

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

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

Вызначайце значэнне выяўленай праблемы

Выяўленая ўразлівасць патрабуе кантэксту: закранутая версія, магчымасць выклікаць адпаведныя паводзіны, даступнасць для атакі, наяўнае выпраўленне і наступствы. Запісвайце доказы, на якіх грунтуецца кожнае часовае выключэнне. Вызначце для яго адказнага, тэрмін дзеяння і ўмову перагляду.

Не адключайце ўвесь сканер таму, што адна выяўленая праблема не датычыцца сістэмы. Не заяўляйце пра чысты вынік, калі сканаванне не завяршылася. Тайм-аўт, непадтрыманы пакет або недаступная крыніца паведамленняў пра бяспеку азначаюць адсутнасць доказаў.

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

Працягвайце з урокам пра пастаяннае кіраванне ўразлівасцямі, каб звязаць паўторныя сканаванні з праверанымі выпраўленнямі ў production.