Open Source и играта на руска рулетка със сигурността
Има напрежение сред внедряването на отворен код, поддръжката на приложенията и сигурността
Около 75% от кода на приложенията, които са на пазара, е формиран от open source съставни елементи, а това е мотив за терзание, защото едвам 28% от компаниите наблюдават и следят съставените елементи на своите приложения
Проектите с отворен код (open source) са страхотни, освен тъй като можете да видите по какъв начин работят нещата, а и тъй като можете сами да дадете своя принос към развиването на даден артикул. Но когато отвореният код е причина за пробив в сигурността, следва въпросът: „ Колко тъкмо Open би трябвало да е един Open Source , преди да стане прекомерно Open ? ”. Това може да е несъобразителен въпрос в някои случаи, само че знаете ли тъкмо от кое място идва вашият код, когато решавате да работите или приложите някой план с отворен код?
От позиция на сигурността – това е надалеч по-голям въпрос, в сравнение с биха предположили много разработчици, и той се удостоверява от настоящи събития като фиаското с Equifax от началото на септември, когато хакери използваха познати уязвими места през Apache Struts, с цел да получат достъп до персоналните банкови данни на над 143 милиона жители на Съединени американски щати. Тази накърнимост, в началото в самата Apache Struts, бе оповестена публично в деня, в който Apache пусна пач за своя код, като за всички по-нататъшни събития виновността пада върху Equifax, че не поддържат кода си в сходство с кода на Apache.
Open Source има своите плюсове и минуси. Благодарение на отворената си и колаборативна натура, такива планове разрешават на хиляди консуматори или разработчици да надникнат в кода на даден план и да оказват помощ с разкриване на пропуски, неточности или пукнатини. Тези неточности се афишират обществено, което теоретично разрешава на всеки един разработчик да ъпдейтне своя код.
Но опитът демонстрира, че това не постоянно се прави, и то не от единични частни лица, разяснява Светлин Наков от СофтУни. „ Лошата поддръжка или чист бизнес (понякога) карат програмистите да забавят или стопират ъпдейти на кода на приложения, с които работят. И когато техните уязвимости станат обществено налични, се оказва детска игра за хакерите да ревизират огромните компании и компании дали си поддържат кода ъпдейтнат ”, разясни той.
Колко доста е „ прекалено много ” Open Source?
Всичко казано до тук ни навежда на въпроса: „ Колко Open може да е един Open Source план, преди да стане прекомерно Open ”? Съществува напрежение сред внедряването на отворен код, поддръжката на обещано приложение и организационната сигурност. Според отчета за положението на софтуерната сигурност, към 75% от кода на приложенията, които са на пазара, е формиран от open source съставни елементи. Това е мотив за терзание, защото едвам към 28% от компаниите наблюдават и следят съставените елементи на своите приложения.
Друга застрашаваща наклонност е, че инспекцията на кода, който занапред компаниите ще внедряват, постоянно не се прави и по този метод се вкарват съставни елементи на отворен код, които не са пачнати – а един път вкарани в обещано приложение, те си остават такива. Шокиращите 88% от Java приложенията имат най-малко една цепнатина в съставените елементи, които употребяват.
още по тематиката
„ Добрата вест е, че нещата, въпреки и постепенно, се усъвършенстват. Има редица стратегии, които навлизат в един по-завършен стадий и тяхната съществена работа ще е да понижат наситеността на уязвимите места. Лошата вест е, че тези стратегии са още надалеч от функционална комплектност и имат да извървят много дълъг път до момента в който подобрят ситуацията на сигурността в промишлеността ”, уточни Светлин Наков.
Проблем е дългият интервал на „ закърпване ” на открити уязвими места в кода. Около 40% от „ пукнатините ” не са „ изкърпени ” над година, а близо 30% имат потребност от над 90 дни, с цел да бъдат поправени. И по-малко от 10% от такива уязвимости се унищожават до 8 дни след откриването им. Това е много рисково, като се имам в поради, че Equifax беше уязвима за интервал от 60 дни!
Разбира се, нещата не са застинали, напредък има и той се реализира в обилни темпове, с помощта на DevOps методологията. DevOps организациите, които са тествани по-често със „ sandbox scanning ”, имат 48% по-добър „ fix rate ”, по отношение на организациите които разчитат единствено на „ policy-only scanning ”.
А отсам накъде?
Няма по какъв начин да се откажем от отворения код. Той е забележителна част от актуалния интернет. Но можем да бъдем по-внимателни с open source съставените елементи и приложенията и с това от кое място идват. Организациите и компаниите, били те разработчици или консуматори, би трябвало да отделят повече време на сигурността и нейната поддръжка. Метафорично казано, грам предварителна защита може да ни спести нуждата от тонове медикаменти.
Едва ли някой желае да бъде идващото огромно име в листата с жертви на солидни пробиви в сигурността. Така, че не рискувайте да си играете на съветска рулетка с вашата сигурност и да се надявате, че патронът на идващия огромен пробив ще ви подмине.
Около 75% от кода на приложенията, които са на пазара, е формиран от open source съставни елементи, а това е мотив за терзание, защото едвам 28% от компаниите наблюдават и следят съставените елементи на своите приложения
Проектите с отворен код (open source) са страхотни, освен тъй като можете да видите по какъв начин работят нещата, а и тъй като можете сами да дадете своя принос към развиването на даден артикул. Но когато отвореният код е причина за пробив в сигурността, следва въпросът: „ Колко тъкмо Open би трябвало да е един Open Source , преди да стане прекомерно Open ? ”. Това може да е несъобразителен въпрос в някои случаи, само че знаете ли тъкмо от кое място идва вашият код, когато решавате да работите или приложите някой план с отворен код?
От позиция на сигурността – това е надалеч по-голям въпрос, в сравнение с биха предположили много разработчици, и той се удостоверява от настоящи събития като фиаското с Equifax от началото на септември, когато хакери използваха познати уязвими места през Apache Struts, с цел да получат достъп до персоналните банкови данни на над 143 милиона жители на Съединени американски щати. Тази накърнимост, в началото в самата Apache Struts, бе оповестена публично в деня, в който Apache пусна пач за своя код, като за всички по-нататъшни събития виновността пада върху Equifax, че не поддържат кода си в сходство с кода на Apache.
Open Source има своите плюсове и минуси. Благодарение на отворената си и колаборативна натура, такива планове разрешават на хиляди консуматори или разработчици да надникнат в кода на даден план и да оказват помощ с разкриване на пропуски, неточности или пукнатини. Тези неточности се афишират обществено, което теоретично разрешава на всеки един разработчик да ъпдейтне своя код.
Но опитът демонстрира, че това не постоянно се прави, и то не от единични частни лица, разяснява Светлин Наков от СофтУни. „ Лошата поддръжка или чист бизнес (понякога) карат програмистите да забавят или стопират ъпдейти на кода на приложения, с които работят. И когато техните уязвимости станат обществено налични, се оказва детска игра за хакерите да ревизират огромните компании и компании дали си поддържат кода ъпдейтнат ”, разясни той.
Колко доста е „ прекалено много ” Open Source?
Всичко казано до тук ни навежда на въпроса: „ Колко Open може да е един Open Source план, преди да стане прекомерно Open ”? Съществува напрежение сред внедряването на отворен код, поддръжката на обещано приложение и организационната сигурност. Според отчета за положението на софтуерната сигурност, към 75% от кода на приложенията, които са на пазара, е формиран от open source съставни елементи. Това е мотив за терзание, защото едвам към 28% от компаниите наблюдават и следят съставените елементи на своите приложения.
Друга застрашаваща наклонност е, че инспекцията на кода, който занапред компаниите ще внедряват, постоянно не се прави и по този метод се вкарват съставни елементи на отворен код, които не са пачнати – а един път вкарани в обещано приложение, те си остават такива. Шокиращите 88% от Java приложенията имат най-малко една цепнатина в съставените елементи, които употребяват.
още по тематиката
„ Добрата вест е, че нещата, въпреки и постепенно, се усъвършенстват. Има редица стратегии, които навлизат в един по-завършен стадий и тяхната съществена работа ще е да понижат наситеността на уязвимите места. Лошата вест е, че тези стратегии са още надалеч от функционална комплектност и имат да извървят много дълъг път до момента в който подобрят ситуацията на сигурността в промишлеността ”, уточни Светлин Наков.
Проблем е дългият интервал на „ закърпване ” на открити уязвими места в кода. Около 40% от „ пукнатините ” не са „ изкърпени ” над година, а близо 30% имат потребност от над 90 дни, с цел да бъдат поправени. И по-малко от 10% от такива уязвимости се унищожават до 8 дни след откриването им. Това е много рисково, като се имам в поради, че Equifax беше уязвима за интервал от 60 дни!
Разбира се, нещата не са застинали, напредък има и той се реализира в обилни темпове, с помощта на DevOps методологията. DevOps организациите, които са тествани по-често със „ sandbox scanning ”, имат 48% по-добър „ fix rate ”, по отношение на организациите които разчитат единствено на „ policy-only scanning ”.
А отсам накъде?
Няма по какъв начин да се откажем от отворения код. Той е забележителна част от актуалния интернет. Но можем да бъдем по-внимателни с open source съставените елементи и приложенията и с това от кое място идват. Организациите и компаниите, били те разработчици или консуматори, би трябвало да отделят повече време на сигурността и нейната поддръжка. Метафорично казано, грам предварителна защита може да ни спести нуждата от тонове медикаменти.
Едва ли някой желае да бъде идващото огромно име в листата с жертви на солидни пробиви в сигурността. Така, че не рискувайте да си играете на съветска рулетка с вашата сигурност и да се надявате, че патронът на идващия огромен пробив ще ви подмине.
Източник: technews.bg
КОМЕНТАРИ