Всички разработчици искат да създават сигурен и надежден софтуер. Те трябва да се чувстват горди, че могат да публикуват своя код с пълната увереност, че не са въвели никакви слабости или антимодели в своите приложения. За съжаление в наши дни разработчиците в по-голямата си част не пишат своя собствен код. 96 % от всичкия софтуер съдържа компоненти с отворен код, а компонентите с отворен код съставляват между 70 и 90 % от всяко едно съвременно софтуерно произведение. За съжаление на нашите разработчици, които се грижат за сигурността, повечето съвременни уязвимости идват от тези софтуерни компоненти.

Тъй като се появяват нови уязвимости, които се съобщават публично като общи уязвимости и експозиции (Common Vulnerabilities and Exposures – CVE), екипите по сигурността нямат друг избор, освен да поискат от разработчика да преработи кода, за да включи различни версии на зависимостите. Никой не е щастлив в тази ситуация, тъй като тя блокира нови функции и може да бъде безумна, когато трябва да се връщат версиите на компонентите и да се надяваме, че нищо няма да се счупи. Разработчиците се нуждаят от начин да определят бързо дали даден компонент, който искат да използват, има известна уязвимост, преди да подадат заявка за изтегляне.

За щастие на разработчиците и екипите по сигурността, сега е по-лесно и по-бързо от всякога да се сканира за CVE на място, автоматично и преди да се направят каквито и да било изменения.

Разберете какво има във вашия код, преди да бъде предаден

Анализът на изходния код (SCA) се появява най-вече при обсъждането на софтуерните спецификации (SBOM) и в разговорите за съответствие, и обикновено много по-късно от действителното писане на кода. С помощта на GitGuardian Software Composition Analysis (SCA) разработчиците сканират за проблеми директно от терминала си във всеки момент от работата си благодарение на ggshield, CLI на GitGuardian. С една бърза команда програмистите могат да проверят дали определена версия на зависимост въвежда известна уязвимост. GitGuardian дори ще покаже дали е налична поправка.

В този пример сме добавили изискване за библиотеката `go-getter` и сме посочили версия 1.7.1. Може да има много причини, поради които разработчикът би използвал тази версия, като например копиране от по-старо ръководство или публикация онлайн, която обяснява функционалността на тази библиотека. Обикновено сканиране на SCA показва, че тази версия не само би въвела известна уязвимост, но има и поправка, налична във версия 1.7.4.

ggshield, CLI на GitGuardian, извършва сканиране на SCA, за да открие уязвимост в кода.

Автоматично сканиране само на новите промени

Въпреки че локалното сканиране за CVE в нашия код е много мощно, то все още е ръчен процес. Хората сме страхотни в това да бъдем креативни, но не сме страхотни, когато става въпрос за последователно извършване на всяка стъпка в даден процес многократно, особено в досадните такива. Добре е, че всеки разработчик разполага с цяла платформа за автоматизация, вградена директно в любимия му инструмент за управление на изходния код – Git Hooks.

Сканирането на SCA от GitGuardian може да се задейства автоматично във фазата преди коммит или преди пуш от работния процес на Git. Идеалният момент за улавяне на какъвто и да е проблем в кода е преди той изобщо да попадне в историята на вашия проект. Ако той никога не е предаден, тогава няма вероятност сканирането за сигурност по-късно да открие проблем в CI/CD конвейера или в продукцията. Въпреки че ежедневно се появяват нови CVE, трябва да направим всичко възможно, за да се уверим, че не добавяме известни такива в нашия код.

Предварителен запис в git, който автоматично изпълнява командата ggshield sca scan pre-commit

Сканиране само на правилния обхват на работа

Ще видите, че в примерната git кука използваме командата `ggshield sca scan pre-commit` вместо `ggshield sca scan all`, както използвахме в примера с ръководството. Този вариант на SCA сканирането ограничава сканирането само до текущата работна директория, което означава само промените, които са направени след последното предаване. По този начин, ако в базата данни има съществуващи уязвимости, които все още не могат да бъдат отстранени, те няма да блокират вашите промени. Ще бъдат идентифицирани само нови проблеми със зависимостите и тогава предаването ще бъде спряно.

При опит за извършване на commit куката на git открива критична уязвимост, която спира добавянето на кода в проекта.

В този пример не само, че не се извършва предаването, но и съобщението от GitGuardian ни казва, че има налична поправка в по-късна версия. Всичко, което нашият разработчик трябва да направи, е да промени един символ в идентифицирания файл, да го запише и след това може успешно да направи новия commit.

Успешно предаване след актуализиране на кода.

Преместването наляво означава по-ранно решаване на проблеми

Въпреки че сигурността изисква цялата организация, въоръжаването на екипа за разработка с правилните инструменти за ранно откриване и отстраняване на проблеми със сигурността може да премахне много главоболия по-късно в процеса на доставка на софтуера. Колкото по-близо до производството откриете проблем, толкова по-скъпо става отстраняването му. Ето защо направихме GitGuardian SCA достъпен като Git Hook преди коммит, така че всеки разработчик да може да се предпази от добавянето на известна уязвимост в конвейера и в крайна сметка в производството.

GitGuardian SCA е на разположение за 2-седмичен безплатен пробен период след бърз разговор с техния екип. SCA е само един от проблемите, с които се занимава пакетът продукти на GitGuardian. Те също така интегрират редица инструменти за сигурност, включително Secrets Detection (откриване на тайни), Public Monitoring (публичен мониторинг), Infra as Code Security (сигурност на инфраструктурата като код) и Honeytoken (мед).