Все постоянно меняется внутри и периодически меняется снаружи. Сегодня мейтейнер адекватный, через год съедет с катушек. Безопасность это вопрос рисков. А риски это штука вероятностная. В том смысле, что негативное развитие ситуации это не если, а когда . Минимизировать зависимости полезно не только в плане security. Но само по себе это не является решением данной проблемы. Даже если вы можете контролировать набор своих непосредственных зависимостей, то на зависимости зависимостей влиять уже не можете.
Ваш подход улучшает ситуацию в определенном домене. Но представьте ситуацию на уровне компании, когда количество собственных репозиториев начинает измеряется тысячами, а счёт технологий идёт на десятки: go, rust, c++, python, c#, java, swift, js, ts, sh, ansible, terraform, docker и куча других. У каждого есть свой механизм определения зависимостей и желание что-то вытянуть снаружи. Тут 100 или 10000 уже не имеет принципиального значения - руками за всем не уследить и нужен комплексный подход.
Ну вручную системно это не сделать. У OWASP неплохо описана эта проблема безопасности, которую создают зависимости (причем не только программные), с примерами соответствующих подходов и инструментов для снижения рисков https://owasp.org/www-community/Component_Analysis
На самом деле крупные корпорации вкладывают кучу денег в безопасность. Например, в статье упоминают Checkmarx. Это гигантский сервис, включающий в себя функции статического анализа приложений SAST (static application security testing), динамического DAST, композиционного анализа SCA (software composition analysis) и т.п.
Последнее в автоматическом режиме проводит анализ зависимостей приложения - да вот этих самых over 9k зависимостей (и зависимостей зависимостей) какого-либо hello world на react.js - и на выходе даёт отчёты о совместимости лицензий, наличии уязвимостей в коде со ссылками на CVE и многое другое. Интернировав такие проверки в CI/CD, компании начинают оперативно получать информацию о возможных инцидентах.
В общем, содержимое публичных репозиториев постоянно сканируется и при обнаружении инцидентов платежеспособная часть сразу получает уведомления. Далее что-то выносится в паблик, в виде твитов, статей или бесплатной помощи - баг репортов в опенсорсные проекты. В целом экосистема находится под постоянным контролем и поэтому довольно легко переносит разные катаклизмы, всплески различного malware, protestware (https://github.com/open-source-peace/protestware-list), и т.п.
В свою защиту вы пытаетесь выставить автотестеров какими-то дремучими. Может такова политика у вашего работодателя или ещё какая-то особенность. Со стороны эти упражнения в риторике и тщетные попытки продать читателям баг как фичу выглядят нелепо. Если вы профессионал, уже сто раз могли набраться мужества и все поправить.
Последние несколько лет часто работаю с QA (индусы в основном) потому, что они знают продукт подчас лучше BA и разработчиков. Иногда про себя упрекаю в дотошности, но ни разу не замечал безграмотности. Они сами меня периодически поправлют когда говорю что-то не правильно.
Наверное Вы ребенку скажете, что вот баранка, если ее крутить, то машинка поворачивает, если жать на педальку она едет.
Если ребенок уже знает, что баранка это съедобное изделие из муки, то у него тоже возникнет когнитивный диссонанс. Вам придется дополнительно рассказывать про шоферский жаргон. Что в целом усложняет задачу обоим: вам объяснить, ребенку - понять. Разве не проще сказать, что крутить нужно рулевое колесо?
В остальном про пред и пост условия полностью поддерживаю.
Да, не. Желание объяснить понятным языком понятно. Но тут, как выше заметили, в результате местами получился какой-то сюр. Видимо у вас там какой-то местный жаргон, раз называете фикстуры декоратором. Но со стороны выглядит феерично. Всё таки в статье на широкую аудиторию лучше назвать вещи своими именами.
Трайбализм — это капитализм. Витька его отменил, и мы оказались в коммунистической утопии
Тут отменили, там отменили, с Китаем сравнили. Культура отмены какая-то. Что в ней позитивного? Позитивная утопия должна быть созидательной. Заголовок не соответствует содержимому). Если серьезно, напомнило Незнайку в Солнечном городе.
Думаю из-за более прочной конструкции, складной рамы и ручек вместо гаек во всех доступных для складывания местах и некоей эксклюзивности. В Школьнике все было тоньше и меньше, во фтулках насыпные подшипники, как в детском Левушке (у Камы шарики в сепараторах).
Думаю у каждого свой опыт. Я в детстве катался на Каме - неубиваемый агрегат и каких-то проблем с тормозами не помню. Ну то есть может они и были, но это не воспринималось как проблема. Простая конструкция, прямая посадка, мягкое сиденье - что ещё нужно чтобы погонять с пацанами во дворе? На зиму можно сложить, закинуть в гараж или кладовку, весной только смазать и снова можно кататься.
Через много лет увлёкся ПВД для тех кому за 150, появился GT с Shimano XTR, контактными педалями и гидравликой. Это агрегат совершенно другого класса, для других целей, требующий понимания как это все работает, отдельного ухода и регулировки после каждой покатушки. Ну и если просто прокатиться во дворе, то он ацки неудобный. В последствии отдал детям, они его естественно разломали в первый же день приложившись кассетой о бордюр.
Насколько мне известно, Форвард и так собирают велики из китайских комплектов. "Кама" это скорее что-то ностальгическое из детства, как Гостья из будущего по телику, или мороженое за 20 коп. По-моему нормальный ход, если по дороге не оптимизировали качество изготовления.
Это называется Schema-based Contact Testing. Подход находится выше юнит тестов потому, что использует данные снаружи. Но ниже E2E - их можно выполнять в изоляции локально или на CI - без развертывания приложения и его зависимостей. Удобно, когда у вас много микросервисов со своими релизными циклами и развертывание всего стека в рамках CI невозможно или нецелесообразно. По смыслу это близко к статистикой проверке типов, где Swagger (OpenAPI, AsyncAPI) вступают в роли унифицированной (платформонезависимой) нотации описания интерфейсов.
Возможность сгенерировать Swagger не отменяет подход, когда Swagger пишется вначале руками (API-first approach). В процессе разработки вы можете использовать сгенерированное описание для проверки соответствия реализации исходной спецификации.
Условия, на которых банк оказываем услуги (не обнуляет ваши счета, начисляет проценты по вкладам и так далее) зависели бы от того, как банк фактически обходится с вашими средствами, а не от того, на каких условиях вы заключили с ним контракт (договор, условия обслуживая и т.п.).
Как будто в жизни так не бывает? У меня летом в банке сняли 30 дополнительных $ за swift перевод просто потому, что у них в зависимостях имплементации что-то поменялось.
Ну что-то sh-образное в линуксах обычно идёт из коробки, а остальное нужно ставить отдельно. Не велика проблема на самом деле. Но на практике тут стена из здравого смысла, личных предпочтений, прошлого опыта, когнитивных искажений и корпоративных стандартов.
По результатам патентных воин между айти гигантами в конце нулевых (или около того), линуксы стали получать с миру по нитке права на использование различных патентов, а *bsd - нет.
Корпоративным пользователям, вместе с обожаемой труъ-админами бесплатной операционной системой, достались не иллюзорные риски попасть на патентные отчисления и судебные разбирательства. Поэтому они быстро развернулись в сторону линуксов. А фря превратилась в нишевый продукт для энтузиастов, любителей труъ-свободы или острых ощущений.
Все постоянно меняется внутри и периодически меняется снаружи. Сегодня мейтейнер адекватный, через год съедет с катушек. Безопасность это вопрос рисков. А риски это штука вероятностная. В том смысле, что негативное развитие ситуации это не если, а когда . Минимизировать зависимости полезно не только в плане security. Но само по себе это не является решением данной проблемы. Даже если вы можете контролировать набор своих непосредственных зависимостей, то на зависимости зависимостей влиять уже не можете.
Ваш подход улучшает ситуацию в определенном домене. Но представьте ситуацию на уровне компании, когда количество собственных репозиториев начинает измеряется тысячами, а счёт технологий идёт на десятки: go, rust, c++, python, c#, java, swift, js, ts, sh, ansible, terraform, docker и куча других. У каждого есть свой механизм определения зависимостей и желание что-то вытянуть снаружи. Тут 100 или 10000 уже не имеет принципиального значения - руками за всем не уследить и нужен комплексный подход.
Ну вручную системно это не сделать. У OWASP неплохо описана эта проблема безопасности, которую создают зависимости (причем не только программные), с примерами соответствующих подходов и инструментов для снижения рисков https://owasp.org/www-community/Component_Analysis
На самом деле крупные корпорации вкладывают кучу денег в безопасность. Например, в статье упоминают Checkmarx. Это гигантский сервис, включающий в себя функции статического анализа приложений SAST (static application security testing), динамического DAST, композиционного анализа SCA (software composition analysis) и т.п.
Последнее в автоматическом режиме проводит анализ зависимостей приложения - да вот этих самых over 9k зависимостей (и зависимостей зависимостей) какого-либо hello world на react.js - и на выходе даёт отчёты о совместимости лицензий, наличии уязвимостей в коде со ссылками на CVE и многое другое. Интернировав такие проверки в CI/CD, компании начинают оперативно получать информацию о возможных инцидентах.
В общем, содержимое публичных репозиториев постоянно сканируется и при обнаружении инцидентов платежеспособная часть сразу получает уведомления. Далее что-то выносится в паблик, в виде твитов, статей или бесплатной помощи - баг репортов в опенсорсные проекты. В целом экосистема находится под постоянным контролем и поэтому довольно легко переносит разные катаклизмы, всплески различного malware, protestware (https://github.com/open-source-peace/protestware-list), и т.п.
В свою защиту вы пытаетесь выставить автотестеров какими-то дремучими. Может такова политика у вашего работодателя или ещё какая-то особенность. Со стороны эти упражнения в риторике и тщетные попытки продать читателям баг как фичу выглядят нелепо. Если вы профессионал, уже сто раз могли набраться мужества и все поправить.
Последние несколько лет часто работаю с QA (индусы в основном) потому, что они знают продукт подчас лучше BA и разработчиков. Иногда про себя упрекаю в дотошности, но ни разу не замечал безграмотности. Они сами меня периодически поправлют когда говорю что-то не правильно.
Расскажите, как у вас в компании вообще строится взаимодействие AQA с разработкой или вы живёте с ними в параллельных мирах не пересекаясь?
Если ребенок уже знает, что баранка это съедобное изделие из муки, то у него тоже возникнет когнитивный диссонанс. Вам придется дополнительно рассказывать про шоферский жаргон. Что в целом усложняет задачу обоим: вам объяснить, ребенку - понять. Разве не проще сказать, что крутить нужно рулевое колесо?
В остальном про пред и пост условия полностью поддерживаю.
Да, не. Желание объяснить понятным языком понятно. Но тут, как выше заметили, в результате местами получился какой-то сюр. Видимо у вас там какой-то местный жаргон, раз называете фикстуры декоратором. Но со стороны выглядит феерично. Всё таки в статье на широкую аудиторию лучше назвать вещи своими именами.
Тут отменили, там отменили, с Китаем сравнили. Культура отмены какая-то. Что в ней позитивного? Позитивная утопия должна быть созидательной. Заголовок не соответствует содержимому). Если серьезно, напомнило Незнайку в Солнечном городе.
Зимний вариант - вычищенный от снега и наледи асфальт, когда вы на шипованой резине. Для велика это каток.
Думаю из-за более прочной конструкции, складной рамы и ручек вместо гаек во всех доступных для складывания местах и некоей эксклюзивности. В Школьнике все было тоньше и меньше, во фтулках насыпные подшипники, как в детском Левушке (у Камы шарики в сепараторах).
Прочитал как лицензирования. Потом ещё платить за нее заставят.
100 МВт - не заработают так согреются.
Думаю у каждого свой опыт. Я в детстве катался на Каме - неубиваемый агрегат и каких-то проблем с тормозами не помню. Ну то есть может они и были, но это не воспринималось как проблема. Простая конструкция, прямая посадка, мягкое сиденье - что ещё нужно чтобы погонять с пацанами во дворе? На зиму можно сложить, закинуть в гараж или кладовку, весной только смазать и снова можно кататься.
Через много лет увлёкся ПВД для тех кому за 150, появился GT с Shimano XTR, контактными педалями и гидравликой. Это агрегат совершенно другого класса, для других целей, требующий понимания как это все работает, отдельного ухода и регулировки после каждой покатушки. Ну и если просто прокатиться во дворе, то он ацки неудобный. В последствии отдал детям, они его естественно разломали в первый же день приложившись кассетой о бордюр.
Насколько мне известно, Форвард и так собирают велики из китайских комплектов. "Кама" это скорее что-то ностальгическое из детства, как Гостья из будущего по телику, или мороженое за 20 коп. По-моему нормальный ход, если по дороге не оптимизировали качество изготовления.
Это называется Schema-based Contact Testing. Подход находится выше юнит тестов потому, что использует данные снаружи. Но ниже E2E - их можно выполнять в изоляции локально или на CI - без развертывания приложения и его зависимостей. Удобно, когда у вас много микросервисов со своими релизными циклами и развертывание всего стека в рамках CI невозможно или нецелесообразно. По смыслу это близко к статистикой проверке типов, где Swagger (OpenAPI, AsyncAPI) вступают в роли унифицированной (платформонезависимой) нотации описания интерфейсов.
Возможность сгенерировать Swagger не отменяет подход, когда Swagger пишется вначале руками (API-first approach). В процессе разработки вы можете использовать сгенерированное описание для проверки соответствия реализации исходной спецификации.
Как будто в жизни так не бывает? У меня летом в банке сняли 30 дополнительных $ за swift перевод просто потому, что у них в зависимостях имплементации что-то поменялось.
Ну что-то sh-образное в линуксах обычно идёт из коробки, а остальное нужно ставить отдельно. Не велика проблема на самом деле. Но на практике тут стена из здравого смысла, личных предпочтений, прошлого опыта, когнитивных искажений и корпоративных стандартов.
По результатам патентных воин между айти гигантами в конце нулевых (или около того), линуксы стали получать с миру по нитке права на использование различных патентов, а *bsd - нет.
Корпоративным пользователям, вместе с обожаемой труъ-админами бесплатной операционной системой, достались не иллюзорные риски попасть на патентные отчисления и судебные разбирательства. Поэтому они быстро развернулись в сторону линуксов. А фря превратилась в нишевый продукт для энтузиастов, любителей труъ-свободы или острых ощущений.