AWS Transform custom: Enterprise Code Modernization with the Learn-Scale-Improve Flywheel

Post Syndicated from Venugopalan Vasudevan original https://aws.amazon.com/blogs/devops/aws-transform-custom-enterprise-code-modernization-with-the-learn-scale-improve-flywheel/

Enterprise modernization has reached an inflection point. You can transform one repository easily. Existing tools, including AWS Transform custom, work well for individual repositories, and the process is understood. But what about 50 repositories? 100? 200? When you need to modernize at enterprise scale, transforming code is only part of the challenge. Coordinating people, capturing knowledge, and maintaining quality across your entire portfolio are also important.

In this post, we explore how AWS Transform custom’s bulk automation capabilities address the enterprise coordination problem through intelligent learning and scaled execution. You will see how one customer reduced end-to-end modernization timelines from 7-12 weeks to 2.5 weeks, delivering a 3-5x reduction in delivery time and 10-20x reduction in total effort hours. Most importantly, you will learn how to start your own transformation journey immediately.

The Coordination Problem at Enterprise Scale

Ask any enterprise architect about their last major modernization initiative, and you will hear familiar stories. As an example, an enterprise software company needed to migrate a large legacy codebase to a modern platform. Their projection: 12 weeks of intensive work coordinating across multiple teams.

The code transformation itself took days. The remaining weeks were consumed by the end-to-end activities surrounding it: orchestrating teams across time zones, ensuring consistent patterns across codebases with different histories, and managing dependencies so upstream changes did not break downstream systems. Teams tracked status through meetings and spreadsheets and captured tribal knowledge that existed only in senior developer heads.

This is the enterprise coordination problem. When you scale from one repository to hundreds, coordination overhead explodes. Each additional repository adds not just its own complexity, but new integration points, edge cases, and unanticipated coordination requirements.

The Hidden 70% Gap

In enterprise engagements, we have observed that code transformation represents approximately 30% of the modernization effort. The remaining 70% include things like test generation, validation, comprehensive documentation, business analysis, and organizational coordination across hundreds of moving pieces.

This gap explains why productivity gains from transformation tools rarely materialize. The tools handle code changes, but organizations still struggle with coordination, validation, and knowledge capture. The transformation is completed quickly, but the project takes months.

Here is what we see: traditional approaches fail at enterprise scale because they treat each repository as an independent challenge. Teams repeat work across codebases, make inconsistent decisions, and lose learnings when developers move to different projects. Organizational knowledge remains trapped in individual heads rather than becoming reusable assets.

A New Approach to Enterprise Modernization

AWS Transform custom takes a different approach to enterprise modernization. Rather than repeating the same operation hundreds of times, the service learns from every execution and applies that knowledge to improve future transformations.

The Learn-Scale-Improve Flywheel

The workflow follows a deliberate progression designed to maximize learning while minimizing risk. It begins with a focused learn pilot, scales through bulk automation, and improves through deliberate review, creating a flywheel where each cycle produces better results than the last (Figure 1).

Iterative transformation workflow with three stages: LEARN (interactive pilot, refine TD), SCALE (bulk execution, overnight processing), and IMPROVE (review and approve knowledge items). Arrows show the cycle: org knowledge captured flows from Learn to Scale, edge cases observed flow from Scale to Improve, and TD improves flows from Improve back to Learn.

Figure 1: Learn Scale and Improve Flywheel for AWS Transform custom transformation

Learn — You start with two to three representative repositories and execute transformations in interactive mode. You work directly with the AI agent, providing feedback on decisions and validating quality at each step. When the agent encounters ambiguity, it asks questions. You provide guidance, and the system captures that context. At the end of the pilot, you review the feedback and modify the transformation definition. The result is a transformation definition enhanced with your organizational knowledge, ready to scale.

Scale — You shift to non-interactive mode for bulk execution. The system processes dozens or hundreds of repositories overnight without manual intervention, applying patterns learned during the pilot. It validates transformations using your build and test commands and tracks progress across your portfolio in real time. What previously required weeks of team coordination happens overnight. During execution, the system captures observations: new edge cases, unexpected patterns, and optimization opportunities the pilot did not encounter.

Improve — After each round of bulk execution, you review the knowledge items the system captured during processing. These observations surface patterns and edge cases specific to repositories the pilot did not cover. You approve the valuable learnings, and your transformation definition improves for the next iteration. This review step ensures quality control. The system does not self-modify. Transformation owners decide which learnings get incorporated.

The Scale-Improve cycle repeats. Each round of bulk execution generates insights that make the next round more effective. Transformation success rates increase, manual intervention decreases, and edge case handling improves with every iteration.

This flywheel transforms how enterprises capture and share institutional knowledge. Transformation definitions are not automation scripts. They are organizational assets that encode how your company approaches specific modernization scenarios. When an architect defines a transformation strategy, that strategy becomes a reusable definition stored in your registry. When your team identifies best practices, those practices become embedded within the transformation definition and automatically apply across all repositories. Previously, when a senior developer left your team, that knowledge disappears with them. With AWS Transform custom, their expertise is captured in transformation definitions and knowledge items available to the entire organization. Individual expertise becomes an organizational capability.

An Enterprise Customer Modernization Case Study

These productivity gains are production outcomes, not theoretical projections. An enterprise software company needed to migrate a large volume of production-grade Control-M workflows to Apache Airflow, a modernization requiring both technical precision and consistency across a complex, interdependent codebase. Their estimate was 12 weeks of intensive coordination across multiple teams, with risk of inconsistency and integration failures.

Using AWS Transform custom, the company executed an iterative learn-scale-improve workflow. During the pilot phase, they ran interactive transformations on representative repositories, reviewed results, and refined transformation definitions. With each iteration, transformation definitions improved in edge case handling and accuracy. They then shifted to non-interactive bulk execution across their portfolio and completed the full migration in 2.5 weeks.

The validation achieved a 100% success rate across all workflows in scope. Edge case handling improved by 60% compared to the customer’s existing approach, and the transformed code demonstrated a 19% runtime performance improvement while meeting industry expert code quality standards. This proves that organizations can achieve both migration speed and production readiness, with 3-5x faster delivery timelines and 10-20x reduction in total effort hours compared to traditional approaches.

Get Started: Transform Your Repository Portfolio

AWS Transform custom bulk automation capabilities are available as a solution in this Github repo. Follow the learn-scale-improve workflow to begin your transformation journey.

Prerequisites

Before beginning, ensure you have:

  • An AWS account with AWS Transform custom access enabled
  • AWS CLI configured with appropriate credentials
  • Git installed on your local machine or CI/CD environment
  • IAM permissions for AWS Transform custom operations

Your Implementation Path

AWS Transform custom supports Java upgrades (e.g., 8 to 17, 17 to 21), Python migrations (e.g., 3.7 to 3.11), Node.js updates (e.g., 14 to 20), AWS SDK migrations (e.g., boto2 to boto3, SDK v1 to v2), and other transformations. Beyond these AWS-managed transformations, you can create custom transformation definitions for organization-specific standards, proprietary framework migrations, and architectural patterns unique to your environment.

AWS Transform custom integrates naturally into your existing development processes. The CLI connects with CI/CD pipelines like Jenkins, GitLab CI, or GitHub Actions. Transformations create code in local Git branches that flow through your standard code review and merge processes. The web interface provides centralized visibility for tracking progress across teams. Validation commands execute automatically during transformation, ensuring code builds successfully and tests pass before changes are considered complete. At the end of the transformation, if validation criteria fail, the transformation is marked as failed.

To accelerate your path to scaled execution, AWS provides an open-source sample repository that gives you a production-ready starting point for running transformations across multiple repositories and transformation definitions simultaneously. The aws-transform-custom-samples scaled execution repository includes scripts that orchestrate bulk execution, manage repository queuing, and handle status tracking across your portfolio. Rather than building orchestration from scratch, you clone the sample, configure it with your repository list and transformation definitions, and begin executing scaled transformations immediately.

Conclusion

Enterprise modernization at scale requires more than code transformation tools. The real challenges are coordination across teams, learning from execution, and capturing knowledge as organizational assets. AWS Transform custom learn-scale-improve workflow addresses these challenges through continual learning that improves quality with every execution, organizational knowledge capture that transforms tribal expertise into reusable assets, and bulk automation that scales consistently across hundreds of repositories. When the next critical security vulnerability requires framework updates across your repositories, or a new runtime version unlocks performance improvements, you respond in days rather than months — using transformation definitions you have already proven.

Real customers have reduced delivery timelines by 3-5x and total effort hours by 10-20x, compressing modernization from months to weeks. These are not aspirational goals. They are production results from organizations using AWS Transform custom today.

Begin Your Transformation Today

Follow the learn-scale-improve workflow on two to three representative repositories, refine your transformation definitions, then scale across your portfolio.
To dive deeper into AWS Transform custom bulk automation capabilities, explore these resources:

      • AWS Transform custom Documentation — Technical documentation covering all capabilities, API references, and integration guides: AWS Transform custom
      • Scaled Execution Sample Repository — Open-source scripts for running transformations across multiple repositories and transformation definitions: aws-transform-custom-samples
      • Transformation Registry — Discover AWS-managed transformations and create custom definitions: aws-transform-custom-samples

Contact your AWS account team or visit the AWS Transform custom documentation to begin your journey.

 

 

About the authors

meghan-author

Meghan Kothari

Meghan Kothari is a Senior Technical Product Manager with the Customer Experience and Business Trends team, where he partners with AWS leadership on strategic deep dives to discover evolving trends in agentic AI-driven application development and modernization. His background as a solutions architect and full-stack developer gives him a unique hands-on perspective to help shape the developer experience. 

Venu-author

Venugopalan Vasudevan

Venugopalan Vasudevan (Venu) is a Principal Specialist Solutions Architect at AWS, where he leads Agentic AI initiatives focused on AWS Transform. He helps customers adopt and scale AI-powered developer and modernization solutions to accelerate innovation and business outcomes.

grilli-author

Rodney Grilli

Rodney Grilli is a Principal Technologist at AWS, specializing in product and code modernization using agentic AI services. He builds solutions that help customers modernize their product portfolios and accelerate their transformations into AI-Native Enterprises.

Към единен политически субект в център-дясно

Post Syndicated from Bozho original https://blog.bozho.net/blog/4583

Център-дясното демократично пространство в България е минало през много перипетии. След 2001 г. е в непрекъснат цикъл от роене и последващо коалиране. А и преди това също – СДС става единен субект едва 1997 г., преди това е коалиция. И даже има няколко СДС-та.

В България факторът „новост“ дава електорален бонус, което стимулира възникването на нови субекти в същото пространство. Дори често (макар и невинаги) те да са формирани от бивши членове на някой от предишните субекти. Но това е еднократен бонус, след което нещата се връщат към изходното положение.

И също така, поради естеството на избирателите – с ценностите на свободата и демокрацията – тези субекти винаги са били идеологически вдясно от центъра (дори да са го отричали в началото).

Само че ролята на партиите е те да са устойчив инструмент за политическо представителство. Да осигуряват кадрово допълване, еволюция на позиции, устойчивост на ценности и приемственост на знанията за политическата технология. За да не се открива топлата вода всеки път, за да има трайна кадрова банка от проверени хора, за се намали лутането по политическия спектър.

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

Затова съм убеден в предложението ни от Да, България да начертаем пътна карта към единен политически субект – една партия, която да включва партиите от коалицията и партии извън нея. И това да е дългосрочна инвестиция в инструмент на тази политическа общност, който ще може да се разширява. Защото можеш да се разширяваш само ако изглеждаш устойчив и ако не си зает с „опазване на периметъра“.

Още по-важен е такъв знак на фона на идващите президентски избори, където за първи път от много време имаме шанс за силен резултат.

А моментът е подходящ и по друга причина – предстои ни вероятно дълъг период в опозиция, защото за да падне правителство, излъчено от абсолютно парламентарно мнозинство на един субект, трябва да се случи нещо много кардинално. И в този период има време за формиране и укрепване на единния субект, за да е в пълна готовност за следващи избори. Сега е моментът да се мисли и действа стратегически, с дълъг хоризонт, загърбвайки дребнотемията и тясно-партийното его.

Материалът Към единен политически субект в център-дясно е публикуван за пръв път на БЛОГодаря.

Третата вълна, или как да пием по-добро кафе

Post Syndicated from Йовко Ламбрев original https://yovko.net/tretata-vulna-ili-kak-da-piem-po-dobro-kafe/

Третата вълна, или как да пием по-добро кафе

Преди около две години, написах за „Тоест“ един доста обширен материал, посветен на кафе културата и т.нар. трета вълна. От текстовете, които не остаряват – точно като вкуса на прясно изпеченото кафе.

Няма да я преразказвам и тук, но понеже искам да я добавя към тукашната си колекция с публикации за кафе, затова реферирам към нея.

Третата вълна, или как да пием по-добро кафе
Третата вълна поставя на фокус качеството, произхода и устойчивостта на кафето и обединява фермери, пекари и баристи в стремежа им към по-добър вкус и съзнателна консумация. В този контекст и България намира своето място с нарастващия брой местни пекарни и кафетерии. Обзорен текст от Йовко Ламбрев.
Третата вълна, или как да пием по-добро кафеТоестЙовко Ламбрев
Третата вълна, или как да пием по-добро кафе

Ще прозвучи нескромно, но това е един от най-подробните текстове за кафе култура в българското интернет пространство, а без нея личният ми кафеен архив някак няма да е пълен.

Ако не сте я чели досега, в статията разказвам за третата вълна (и за предходните две, разбира се) и как стигнахме до нея; какво означава специално кафе и какви са разликите и значението на индустриалното и занятчийското му печене. Опитах се да обясня и защо проследимостта на кафето (от фермата до чашата) е важно за неговото качество. И… още една купчина други полезни и (надявам се) интересни неща.

Даже успях да напъхам между другото и две интервюта с местни пекари.

Приятно четене (с чаша хубаво кафе в ръка)!

.

Данни за българите в Германия за 2025

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/bgde-2025/

От над десетилетие следя данните за диаспората ни в Германия. Разглеждал съм различни аспекти като защо имаме няколко различни числа за броя им, колко деца се раждат на българи в Германия, както и социалните, образователните и икономическите показатели. В края на този текст ще пусна списък с всичките ми статии по темата.

Повечето данни, които разглеждам идват от DeStatis – немското НСИ. В последните два месеца излязоха два ресурса от тях – данните на имиграционните и тези от т.н. микропреброяване. Макар да съм критикувал доста числата на имиграционните им, те са единствените, които имаме с разбивка по общини. Т.е. само от тях може да научим къде точно са българите в Германия. Има още няколко числа посочващи общия брой българи в Германия обаче, които е важно да разберем.

Българите в Германия намаляват

През февруари описах подробно защо има различни числа за броя българи в Германия, как се различават те, какво значат, какво показват и какви условности имат. Накратко, имиграционните казват, че през 2023-та в Германия е имало 436860 хора с българско гражданство, а според адресите регистрации статистическата служба казват, че са 410623. След преброяването в Германия обаче, последното число обаче е коригирано с около 10% надолу и вече ще намерите, че българите в Германия са 371128 през 2023-та. В този брой не се включват българите взели германско гражданство, които са между 1600 и 2800 в последните 10 години.

През 2024-та година виждаме намаление в оценките за диаспората ни – имиграционните отчитат 1.1% намаление или 4780 души на 432080, а по адресна регистрация намалението е с 2.4% на 362421. За 2025-та имаме данните само на имиграционните и виждаме ускоряване на намалението с 2.36% или 10185 души достигайки 421895 български граждани. Данните за демографията на Германия ще излязат през август, така че тогава ще разберем колко е тяхната оценка за намаление.

На долната графика виждате динамиката на данните на имиграционните от 1990 до сега. В жълто е промяната година за година в процент. Виждаме, че през 2004-та година е имало за кратко намаление и почти никаква промяна през 2005 и 2006-та. След присъединяването към ЕС се вижда няколко години подред 25% растеж в миграцията ни, който обаче отслабва след 2017-та поради редица фактори в България и най-вече в Германия. След короната практически се изравняват напусналите и пристигащите се в Германия като в последните две вече намаляват.

Карта на българите по общини

В последните 10 години поддържам една карта, която показва оценката на имиграционните къде се намират българите по общини. Пуснал съм картата в статии подобни на тази през времето, които ще намерите в линковете накрая. Тази година освен, че обнових данните, реших да обновя картата. Първо защото кодът ѝ беше на десетилетие, второ, защото открих някои неточности и исках да я направя по-функционална.

Картата разглежда периодът от 1998-ма до сега. Междувременно е имало няколко промени на административното делене в Германия, където общини са били сливани, свободни градове са променяли статута си и прочие. Това усложнява задачата за разглеждане на данните, тъй като тези за предходни години трябва да се преразпределят в различно териториално деление в сегашния контекст. Отделно на места като Saarland събират данни за няколко общини наедно, затова съм ги събрал. Доколкото отчитах тези промени в миналото, заех се да преразгледам всички такива в последните 30 години и да ги отбележа наново. На картата виждате сегашното административно делене на Германия и в сегашните общини се събират демографската и имиграционна статистика от предишни години преди промените.

Друга промяна е, че направих картата да работи на цял екран и на мобилно устройство. Добавих изглед освен абсолютен брой на българите и индекс спрямо населението (българи на всеки 100 хиляди души), също и промяна в броя българи спрямо предходната година. Така може да се види по-лесно къде има отлив на българи и къде има увеличение. Не показвам тази оценка за места, където има до 50 българи, защото тогава дори 10 добавени ще означават 20% увеличение, което не е толкова релевантно. Остава възможността за анимация, която може да пуснете през менюто и ще върти през годините, за да покаже нагледно промените. Натискайки на отделна община ще покаже графика само за нея и детайли като съотношение мъже/жени, население и прочие.

Картата може да разгледате и на цял екран тук.

Демографски аспекти

Следващите данни и числа се базират на т.н. микро-преброяване. Това е редовно допитване, което немската статистическа служба осъществява, което допълва интересни аспекти за населението на Германия. В случая – миграцията. Таблиците им ще намерите тук. Достъпна информация за самото преброяване има тук. Следващите изводи и графики се основават на тези данни за 2025-та като използвам същите методи и изчисления като в предходните ми статии по темата. Поради промяна в параметри, метрики и възрастови отрязъци обаче сравнение с предходни години не винаги възможно.

На долната графика ще видите възрастовата структура на диаспората ни. Виждате, че най-много хора има между 30 и 50 годишна възраст. Разпределението мъже/жени не изненадва и следва това,което срещаме в България. Вижда се ясно, че има все по-малко хора между 19 и 30 годишна възраст, което потвърждава тенденцията описана горе.

На следващата графика виждаме колко време са стояли българите в Германия. Избраните периоди не са с равномерен отрязък, тъй като се базира на това как имиграционните водят статистиката си, а тях ги интересува колко хора имат право на немско гражданство след 7-мата и 8-мата година. Тук виждаме, че най-много българи вече за минали 10-тата година престой в Германия. На този фон намаляващия дял на българите взели немско гражданство всяка година трудно може да се обясни само с тромавата администрация. Изглежда остава мнението сред диаспортата ни, че няма особен смисъл.

Интересен е погледа над това къде са родени българските граждани в Германия. Тук виждаме, че мнозинството от българчетата до 5 г. са родени в страната, както и над половината от тези между 6 и 9 години. Това значи, че са деца на мигранти, които все още нямат право на немско гражданство. В противен случай биха получили автоматично такова и нямаше да се причисляват към тази статистика. Пикът при възрастите над 45 г. е поради това, че в статистиката ги бяха групирали на 10 годишни отрязъци.

В данните от микропреброяването виждаме и няколко нови интересни метрики, които дават нов изглед над произхода на българските граждани в Германия. Една от тях е за месторождението по държави.

Както споменах, оценката на имиграционните за българите в страната е за 421895. От тях обаче 77.8% са родени в България. 10.1% са родени в Германия, както се вижда на графиката горе. 18165 български граждани или 4.3% са родени в Македония. 6255 или 1.5% са родени в Турция – най-вероятно наследниците на насилствено изселените български турци. 4395 или около 1% са родом от Молдова. Иначе казано, 22% от диаспората ни или около 39 хиляди български граждани в Германия не са родени в България.

94.8% от българите са в западна Германия. По провинции най-много има в Nordrhein-Westfalen – 24.2%, следвана от Bayern – 15.5% и Baden-Württemberg с 12.3%.

В това число не се включват обаче тези, които са взели германско гражданство. Според оценката на имиграционните това са 33 хиляди души родени в България. Доколкото някои от тях са се отказали от българското си гражданство, тези случаи са около 4 хиляди и са предимно от преди приемането ни в ЕС. 29 хиляди души родени в България имат двойно гражданство като жените са две трети от тях. Сред децата на българи родени в Германия, за които родителите им се е занимавало да извадят български акт за раждане, 15 хиляди има двойно гражданство и разпределението момчета и момичета е равномерно. Общо 44 хиляди български граждани имат двойно гражданство според германските институции.

Социални аспекти

Следващите данни се отнасят само за хората в Германия, които са родом от България и нямат германско гражданство, както и за техните деца и домакинства.

39% от българите в Германия са неженени. 52.9% имат брак като 84.8% от тези с брак към са се оженили за друг мигрант в Германия – предимно други българи. Това е високо предвид повечето млади хора в диаспората ни спрямо населението на България и причината е, че има финансова изгода – със семейното доходно облагане включването на брак дори фиктивно намалява данъчната тежест в мнозинството от случаите. Около 5.48% са разведени.

12.6% от българите са все още в училищна възраст или са в университет. От останалите, 32.5% имат завършено само основно образование. 31% имат само средно. Отгоре на тях още 18.5% имат професионално и само 18% имат някакво висше образование, което не е дори непременно университет. Писал съм за този аспект преди и как влиза в противоречие с възприятието на обществото за структурата на имиграцията ни.

Като домакинства, 61% от българите в Германия живеят в семейства с деца. Трудно е да се прецени колко средно деца имат, тъй като тази статистика не отчита партньорите немци, както и децата с немско гражданство. 19.7% от хората родени в България, но живеещи в Германия живеят в двойки без деца. 18.4% живеят сами като 26% тях се налага да споделят жилище с други (т.н. WG или просто съквартиранти).

58.4% от българите са заети. Тук интересното е, че тези нива са значително по-високи от средното за Германия. Само 47.9% от жените в Германия са заети – без значение гражданство или произход. Сред жените мигрирали в Германия средното е 49.1%. При българките – 53.1%. Аналогично е при мъжете – средното за всички в Германия е 54.9%. Сред мигрантите – 62.09%, а сред българските мъже – 64.9%.

По часове на графиката долу виждаме, че мнозинството работи по около 40-42 часа седмично. Почти толкова българки обаче работят на половина работен ден, колкото на пълен. Основна причина за това, според мен, е лошият достъп до детски градини и късият им график. Често затварят в 4 или 5 следобед. Същото важи и за доста училища, където местата в занималните не стигат. Това е особено вярно в големите градове, където мнозинството от съгражданите ни живеят.

32% от сънародниците ни работят в неделя като отново има превес при мъжете – 34.4% спрямо 30.2% за жените. 21.6% работят в неделя и 16.6% работят на смени. 24.3% работят в производството. 34.3% работят в магазини, места за настаняване или транспорт.

Гледайки доходите, най-голямата група българи в Германия (около 43%) получава между 1500 и 2500 евро чисти (т.е. нето). При жените доходите са значително по-ниски и най-голямата група получава между 1000 и 2000 евро нето. Причините за това са отчасти по-малкото отработени часове, но и редица типични за Германия и Европа фактори ограничаващи растежа в кариерата. Разбира се, от тези „чисти“ пари, не сме приспаднали значителните местни такси, сметки за ток, множеството практически задължителни застраховки и прочие.

Средно може да кажем, че работещите българи получават около 1986 евро нето. При жените това е 6.9% по-малко на 1849 евро, а при мъжете – 6.4% повече и 2114 евро нето. Тези стойности са значително по-ниски за средното за Германия. Нето заплатата на българите е 11% по-ниска от средното за страната. При жените е аналогична заплатата спрямо средното за мигрантите, но отново с 11% надолу спрямо всички работещи жени в Германия. При мъжете разликата е по-драматична – 16% по-малко от средното за всички мигранти и 23.5% по-малко от средното за страната.

На следващите графики виждате разбивка по нето доходи и какъв дял от съответната демография спада към коя група. Първо виждате средно за хората в Германия родени в България като сравнение с другите мигранти и всички в страната. Вижда се, че мнозинството получават под 2500 евро и много малък дял получават над 3500 в сравнение със средното за страната.

В следващите две графики виждате разбивка на мъже и жени отделно. При жените се забелязва подобна крива сред българките и всички мигрантки. Тази е за българките е с определена грешка заради по-малката извадка и закръглянето от DeStatis до 1000 души. Интересно е, че кривата сред всички жени в Германия не много по-различна. Това дава допълнителни индикации за структурните проблеми в Германия по отношение на възможностите, образованието и подкрепата в семейството влияещи на тези и други индикатори за равенство на половете.

При мъжете се вижда аналогични криви, но с отчетливо изместване на по-голямата част от сънародниците ни към позиции със значително по-ниски доходи. Докато най-голям дял от хората в Германия печели над 3500 евро нето, аналогичен дял сред българите прибира двойно по-малко на месец.

Разчитайки само на тези доходи получаваме, че поне 34.3% от българи пренесли се в Германия живеят под прага на бедността. Ако добавим допълнителните социални помощи този дял намалява на 22.9%. Това отново е доста над средното за България за 2025-та от 21.2%. Някой ще оспорят, че линията на бедност е различна и означава различни неща. Индикаторът обаче е условен с причина и се отнася до разпределението на доходите на населението по еднаква формула. Линията на бедността е условна и е индикатор каква част от населението има проблем да свързва двата края независимо, че работи. Много от тези хора под линията са т.н. работещи бедни.

Сред работещите българи има 42% по-голяма вероятност да живеят в бедност въпреки труда си, отколкото средното за Германия и 21% по-голяма вероятност от всички мигранти. Има сериозна разлика и при половете. При работещите българки в Германия 44.2% са под линията на бедността или 83.3% по-голяма вероятност от средното за населението на Германия и 56.3% повече от средното за всички жени работещи е страната. Подобно е нивото на българките и всички останали мигрантки. При мъжете ни има само 8% по-високо ниво на бедност от средното за цялото население. Ако обаче сравняваме с всички мъже в Германия обаче, вероятността мъж роден в България и работещ в Германия да е под линията на бедността е с 74% по-голяма, отколкото при останалите мъже там. За разлика от жените, има голяма разлика между българските мъже и останалите мигранти – 55% по-висок шанс да са в бедност.

Затова не трябва да ви учудва, че 16.5% получават помощи за безработица и социални. Пенсия получават 3.9%. Още 10.3% получават друга форма на помощ, което значи, че доходите им са твърде ниски, за да свързват двата края. Доколкото виждаме увеличение сред получаващите помощи за безработица (например спрямо 2018-та г. когато отчетох 15%) и намаление сред т.н. бедните работещи, сравнението е подвеждащо. Първо, защото микропреброяването тогава разглеждаше домакинства, а не отделни работещи, но най-вече защото промените в социалната система са причина много хора в затруднено положение да нямат достъп до помощ. Не на последно място, много се говори за работата на черно и как заетостта реално е по-висока. Доколкото го има този феномен, също е вярно, че хиляди българи само се водят проформа регистрирани в Германия надувайки статистиката на отпадналите от трудовия пазар.

Предишни статии за българите в Германия

Тук съм събрал повечето от статиите, които съм писал в последните 14 години за диаспората ни в Германия, икономически и социални аспекти, които ги засягат. Картата поместена горе публикувах за пръв път през август 2017-та. В някои от останалите статии съм публикувал обновени версии, както данни аналогични на тези, които описах горе.

Други статии свързани с Германия, които може да са ви интересни:

Седмицата (20–25 април)

Post Syndicated from Йовко Ламбрев original https://www.toest.bg/sedmitsata-20-25-april/

Седмицата (20–25 април)

През първата седмица след изборите няма как новинарският поток да не бъде подчинен на резултатите от вота и на първоначалните оценки и анализи, провокирани от тях. Очевидно е, че след 19 април 2026 г. политическата сцена в България ще бъде различна и доминирана от нов ключов играч. Би трябвало да напиша, че това е новата партия „Прогресивна България“, но понеже тя бе учредена буквално два дни преди изборите, по-честно ще е да уточним, че победител е бившият президент Румен Радев. Той спечели невиждано отдавна мнозинство, привидяло лично в него това, което му се искаше да види. Тези 44,6% от хората, дали вота си за него, тепърва ще валидират предположенията и надеждите си за идеите и личностите, които ще задават дневния ред на държавата през следващите четири години.

Какво обаче извън предположенията и надеждите е сигурно?

ГЕРБ не просто загубиха изборите, а без малко щяха да останат трета политическа сила в новия парламент. „Възраждане“ едва се закрепиха над 4-процентовата бариера. Жалко! Щяха да липсват на малцина.

На никого няма да липсват със сигурност ИТН, които заслужено безславно приключиха завинаги авантюрите си в политиката. В новия парламент няма да присъстват и БСП, а ДПС (на Делян Пеевски) се сви до малко над 7% подкрепа.

Единствената политическа формация от предишното Народно събрание, която увеличава електоралната си тежест, е коалицията „Продължаваме промяната“ – „Демократична България“ (ПП–ДБ), въпреки атаките на всички срещу тях, преливането на гласове към победителя и собствените им грешки и пропуски, които поне част от лидерите им изглежда да осъзнават.

Юмрукът на Радев след тези избори обаче вече не е символ на бунт, а инструмент на властта, напомня Емилия Милчева в политическия обзор на първата следизборна седмица. Защото абсолютното мнозинство предполага олигархичният модел да бъде „размазан“, както си го представят гласувалите за „Прогресивна България“. И както им беше обещано. Макар те да предоставиха доверието си, без много да се интересуват точно как и от кого ще бъде свършено това. Тези и други въпроси стоят зад заглавието „Радев, ще удряш ли с юмрука?“

Радев, ще удряш ли с юмрука?
Абсолютното мнозинство дава възможност за бързи решения без оправдания. Първият тест е кадровият – ВСС, главен прокурор, регулатори. От него ще се види към обещаната промяна ли се върви, или „юмрукът“ ще пренарежда същата система с други лица. От Емилия Милчева.
Седмицата (20–25 април)ТоестЕмилия Милчева
Седмицата (20–25 април)

„Видях роботи!“ – възкликва Дарина Сарелска в новия си анализ за „Тоест“, тема на който този път е медийното отразяване на изборния ден и нощта след него. И според нея това възклицание, за жалост, почти напълно изчерпва темата. Защото големите телевизии ползваха хуманоидни роботи и холограми само като екзотичен фон на скучни и остарели журналистически клишета, а в студиата продължиха да дефилират „говорещи глави“ с опорни точки от миналото десетилетие. Текстът търси отговори на въпроса защо при наличието на нови технологии, чиято сила е в бързата проверка на факти, анализа на данни и изобразяването им, водещите телевизии избраха патриотарския кич, преразказ на публикации от социалните мрежи и „пликове с прогнози“ пред модерната журналистика.

Неотразимото медийно отразяване на изборите
В отразяването на изборите телевизиите вкараха роботи, но не и особен смисъл. И това ни показа предимно докъде се простират границите им – и технологични, и редакционни, и най-вече зрителски. На телевизионния фронт нищо ново, освен поредната пропусната възможност. От Дарина Сарелска.
Седмицата (20–25 април)ТоестДарина Сарелска
Седмицата (20–25 април)

С новия си коментар за „Тоест“ Светла Енчева предлага да погледнем на случилото се в неделя под малко по-различен ъгъл. А именно дали пък фиксацията върху определени (макар и наболели) теми, като антикорупция и съдебна реформа, и твърде абстрактното им обговаряне не доведоха до тази неочаквана концентрация на власт. Особено на фона на демократичната ни култура в момента, тази концентрация е с потенциал да произведе далеч по-страшни чудовища от тези, от които се опитваме да се отървем.

Казах ви
В случая „казах ви“ е опит за равносметка как някои пренебрегвани процеси, фокусът върху корупцията и страхът от ценностни позиции доведоха до (не)очаквана концентрация на власт. Текст на Светла Енчева за пропуснатите сигнали и изкривените прогнози.
Седмицата (20–25 април)ТоестСветла Енчева
Седмицата (20–25 април)

И понеже преди, след и по време на избори (да не кажа непрекъснато) у нас циркулира темата как някаква друга избирателна система, видите ли, щяла да произведе по-справедлив резултат, сега е моментът да се замислим какъв парламент щеше да ни очаква след няколко дни, ако се бяхме подхлъзнали по идеята за мажоритарна система. Александър Драганов обаче призовава да не я демонизираме прекалено и разбира се, има валидни аргументи за това. Ще ги прочетете в статията му „Избори и избирателни системи. Между черните дупки и реалността“.

Избори и избирателни системи. Между черните дупки и реалността
След дългата поредица от предсрочни избори все по-често на дневен ред излизаше въпросът трябва ли да променим избирателната си система, за да се реши проблемът. Александър Драганов разсъждава по темата, представяйки плюсовете и минусите на пропорционалните и мажоритарните системи.
Седмицата (20–25 април)ТоестАлександър Драганов
Седмицата (20–25 април)

И стига толкова политика…

Повече от половин век след като последният екипаж от програмата „Аполо“ напусна Луната, човешкото присъствие около нашия естествен спътник отново предизвиква внимание. В новия си обзор научни новини за „Тоест“ Михаил Ангелов прави дисекция на мисията Artemis II – събитие, което не предизвика голяма медийна експлозия, но подложи на изпитание актуалната технологична готовност на човечеството за космически мисии. Статията представя и чисто човешките (и понякога комични) предизвикателства на живота в Космоса – от запушената „космическа тоалетна“ до вълнуващото наблюдение на слънчево затъмнение отвъд земната атмосфера.

Научни новини: Artemis II завинаги
Artemis II не донесе големи изненади и обществени придихания. (Макар че част от нас пророниха по някоя и друга сълза при излитането и кацането.) Но без рекорди за показ пак има смисъл, особено когато правим проверка дали можем отново да стигнем до Луната и обратно. Обобщение от Михаил Ангелов.
Седмицата (20–25 април)ТоестМихаил Ангелов
Седмицата (20–25 април)

„Втората цедка“ на класацията на авторите на „Игромислие“ разпали важен и не неочакван дебат: защо все още се страхуваме да превеждаме игрите на български? Тръгвайки от спора дали Baldur’s Gate трябва да е „Портата на Балдур“, или просто топоним, Миглена Николчина, Еньо Стоянов и останалите атакуват „езиковия мързел“ и липсата на институционална подкрепа за гейм индустрията у нас. Публикацията прави паралел с полския успех на „Вещерът“, започнал именно от силна локализация, и задава неудобния въпрос: защо българските програмисти и държавата ни продължават да се държат така, сякаш езикът няма значение за дигиталните светове?

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

Втора цедка на „класацията“. Превод и локализация
На какъв език играем? Ако мислим, разговаряме и четем на български, ако гледаме филми със субтитри, защо това не важи за игрите ни? Втората част от класацията на игромислещите обръща внимание на този проблем, който като че ли най-сетне събуди интереса на играещите общности.
Седмицата (20–25 април)ТоестМиглена Николчина
Седмицата (20–25 април)

Тази седмица може да прочетем и втората част на необичайната „кулинарна география“ на отвъдното в рубриката „Ориент кафе“. След като в първата част Атанас Шиников ни запозна с общите представи за задгробния живот в исляма, сега ни потапя в детайлните и често стряскащи описания на това какво всъщност има на „трапезата“ в Рая и Ада. От реките с вино, което не замайва главата, или мед, до гнойната вода, запазена за грешниците, текстът изследва как ислямската традиция използва сетивните усещания, за да очертае границите на морала. Ще оставя на читателя да прецени дали Атанас е написал екзотичен разказ, или по-скоро метафорично размишление по темата как въображението за „там“ винаги казва нещо важно за живота „тук“.

Вино или гной: Какво се яде и пие в отвъдното според исляма (продължение)
И тази седмица продължаваме да разлистваме заедно с Атанас Шиников двете „менюта“ в мюсюлманското отвъдно. Тези, които възнаграждават праведните, и онези, които изгарят вътрешностите на грешниците. За да допълни преживяването, Атанас е „поканил на масата“ сведущи по темата теолози и коментатори.
Седмицата (20–25 април)ТоестАтанас Шиников
Седмицата (20–25 април)

Новото „Стихотворение на месеца“ от японската поетеса Чика Сагауа се нарича „Сутрешен хляб“ и е сюрреалистичен сън отвъд ръба на едно уж банално измъкване през прозореца… Или може би е взиране в абсурда на ежедневието, прочетено като разбъркан кинокадър, търсещ смисъла на собственото ни смирение. Не съм сигурен.

Сутрешен хляб
Сутринта виждам няколко приятели да се измъкват през прозореца. Зеленото червейче на изкушението. В овощната градина е убита жена със свалени чорапи. Утрото, нахлупило цилиндър, се задава иззад овощната градина. В ръката с вестник, напечатан със зелено мастило. Най-сетне и аз трябва да сляза от хълма. Градските кафенета са красиви
Седмицата (20–25 април)ТоестТоест
Седмицата (20–25 април)

Сигурен съм обаче, че няма никакъв шанс да откриете такива текстове другаде. А екипът на „Тоест“ разчита на вашите дарения, за да продължи да съществува, затова не забавяйте и не забравяйте финансовата си подкрепа.

Станете дарител

Приятно четене!

И не заспивайте! Оставете сетивата си обострени.

Friday Squid Blogging: How Squid Survived Extinction Events

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/04/friday-squid-blogging-how-squid-survived-extinction-events.html

Science news:

Scientists have finally cracked a long-standing mystery about squid and cuttlefish evolution by analyzing newly sequenced genomes alongside global datasets. The research reveals that these bizarre, intelligent creatures likely originated deep in the ocean over 100 million years ago, surviving mass extinction events by retreating into oxygen-rich deep-sea refuges. For millions of years, their evolution barely changed—until a dramatic post-extinction boom sparked rapid diversification as they moved into new shallow-water habitats.

As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.

Blog moderation policy.

Metasploit Wrap-Up 04/25/2026

Post Syndicated from Spencer McIntyre original https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-04-25-2026

Check Method Visibility

Metasploit has supported check methods for many years now. It’s not always desirable to jump straight into exploiting a vulnerability but instead to determine if the target is vulnerable. Metasploit tries to be very conservative with classifying a target as “vulnerable” unless the vulnerability is leveraged as part of the check method, reserving the “appears” status for version checks. The different check codes a module is capable of returning and the logic to select among them varies from exploit to exploit and is not always the easiest to understand. Aligning with the consistent feedback that Metasploit has received that module actions should be more transparent, adfoster-r7 has been adding reasoning information en masse to the check codes returned by a variety of exploits. This information will help users understand why a particular vulnerability status was determined, making troubleshooting efforts easier and increasing confidence in the results.

Legacy SMB Improvements

This week, community member g0tm1lk made multiple improvements for legacy and non-Windows SMB targets. Version information is now more reliably extracted from targets running SMB 1, and a variety of minor bugs were fixed across multiple modules that would have affected users targeting systems the module was not intended to target as is often the case when the module is used to scan an entire network.

New module content (4)

Camaleon CMS Directory Traversal CVE-2024-46987

Authors: Goultarde, Peter Stockli, and bootstrapbool

Type: Auxiliary

Pull request: #21122 contributed by bootstrapbool

Path: gather/camaleon_download_private_file

AttackerKB reference: CVE-2024-46987

Description: This adds an auxiliary module to exploit an arbitrary file vulnerability, CVE-2024-46987, on Camaleon CMS >= 2.8.0 as well as 2.9.0.

Langflow RCE

Authors: Takahiro Yokoyama and weblover12

Type: Exploit

Pull request: #21260 contributed by Takahiro-Yoko

Path: multi/http/langflow_rce_cve_2026_27966

AttackerKB reference: CVE-2026-27966

Description: Adds exploit module for CVE-2026-27966, a prompt injection RCE vulnerability in Langflow < 1.8.0. By creating and sending a specially-crafted flow containing python code, the LangChain will execute that code because LangChain’s Read-Eval-Print Loop (REPL) is exposed by default and runs any Python code it is given.

WebDAV PHP Upload

Authors: g0tmi1k and theLightCosine [email protected]

Type: Exploit

Pull request: #21256 contributed by g0tmi1k

Path: multi/http/webdav_upload_php

AttackerKB reference: CVE-2012-10062

Description: Updates code and adds features: Linux support, check() method, and cleanup after exploit.

Linux Chmod

Author: bcoles [email protected]

Type: Payload (Single)

Pull request: #21238 contributed by bcoles

Path: linux/loongarch64/chmod

Description: Adds a new linux/loongarch64/chmod payload to change the permissions of a specified file.

Enhancements and features (11)

  • #21019 from g0tmi1k – This adds support for phpMyAdmin v3.1.x to the phpMyAdmin Config File Code Injection module (CVE-2009-1285). This also adds a check method.
  • #21230 from bcoles – Reduces the memory footprint of the module metadata cache in Metasploit.
  • #21231 from bcoles – Improves the performance of the module metadata cache as well as bug fixes.
  • #21232 from bcoles – Add a method to discover writable directories on Unix targets using the find command.
  • #21256 from g0tmi1k – Updates code and adds features: Linux support, check() method, and cleanup after exploit.
  • #21347

Bugs fixed (4)

  • #21327 from tair-m – Fixes a crash when loading HTTP modules.
  • #21341 from g0tmi1k – This fixes multiple issues related to various SMB modules when targeting Samba.
  • #21344 from adfoster-r7 – Fixes a bug when running the check method for scanner/http/elasticsearch_traversal against non-vulnerable targets.
  • #21346 from adfoster-r7 – Fixes a false positive that was present in auxiliary/scanner/couchdb/couchdb_enum.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

Protecting your secrets from tomorrow’s quantum risks

Post Syndicated from Stéphanie Mbappe original https://aws.amazon.com/blogs/security/protecting-your-secrets-from-tomorrows-quantum-risks/

As outlined in the AWS post-quantum cryptography (PQC) migration plan, addressing the risk of harvest now, decrypt later (HNDL) attack is an important part of your post-quantum plan. Upgrading the client-side of your workloads to support quantum-resistant confidentiality is an important aspect of your side of the PQC shared responsibility model. Timelines to plan and execute your PQC upgrades vary by region and by industry and will depend on your own business risk profile. To learn more, see the AWS PQC frequently asked questions.

AWS Secrets Manager uses SSL/TLS to communicate with AWS resources, currently supporting TLS 1.2 and 1.3 in all AWS Regions. The service supports using TLS 1.3 with hybrid post-quantum key exchange for clients that support this capability. The hybrid post-quantum approach establishes TLS connections by combining traditional cryptography (such as X25519) with post-quantum algorithms (ML-KEM), and helps to protect your secrets against both current classical attacks and future quantum computer threats. Regardless of how your workload accesses Secrets Manager, this client-side software upgrade is the only action you need to take to address risk to secrets from HNDL. Your secrets at rest are already encrypted using keys managed by AWS Key Management Service (AWS KMS). Properly implemented symmetric encryption is considered quantum-resistant; asymmetric cryptography faces quantum threats. To learn more, watch AWS re:Inforce 2025 – Post-Quantum Cryptography Demystified.

To reduce builder effort for client-side upgrades, we’re pleased to announce the following Secrets Manager clients now enable and prefer post-quantum TLS when initiating connections to Secrets Manager: Secrets Manager Agent (v2.0.0 or later), the AWS Lambda extension (v19 or later) and the Secrets Manager CSI Driver (v2.0.0 or later). For SDK-based clients, hybrid post-quantum key exchange is available in supported AWS SDKs. Enablement requirements vary by language, version, and operating system. See the following table for your SDK client.

This launch is part of the ongoing commitment AWS has made to migrate systems to post-quantum cryptography and making it straightforward for our customers to do the same. See Post-Quantum Cryptography to learn more.

Client hybrid post-quantum key exchange requirements

The following table summarizes the behavior for each client. When the client is upgraded to support hybrid post-quantum key exchange, the Secrets Manager service endpoint automatically selects it during the TLS handshake. Upgrading to the versions listed in the table is the only action you need to take for your workload to begin using hybrid post-quantum key exchange when calling Secrets Manager APIs.

Client Requirements
Secrets Manager Agent Hybrid PQ key exchange in TLS preferred by default (v2.0.0 and later)
AWS Lambda extension Hybrid PQ key exchange in TLS preferred by default (Version 19 and later)
Secrets Manager CSI Driver Hybrid PQ key exchange in TLS preferred by default (v2.0.0 and later)
AWS SDK for Rust Hybrid PQ key exchange in TLS preferred by default (releases after August 29, 2025)
AWS SDK for Go Hybrid PQ key exchange in TLS preferred by default (Go v1.24 and later)
AWS SDK for Node.js Hybrid PQ key exchange in TLS preferred by default (Node.js v22.20 and v24.9.0 and later)
AWS SDK for Kotlin Hybrid PQ key exchange in TLS preferred by default on Linux (v1.5.78 and later)
AWS SDK for Python The AWS SDK for Python (boto3) uses the OS-provided OpenSSL for TLS.
Hybrid PQ key exchange in TLS requires running on a system with OpenSSL 3.5 or later installed.
AWS SDK for Java v2 AWS SDK for Java v2 requires an AWS CRT HTTP client that supports PQ TLS when configured using postQuantumTlsEnabled.
Secrets Manager caching clients The Secrets Manager caching libraries are built on the AWS SDKs and inherit their TLS behavior. Note for Java: The JDBC driver flag and Java Caching flag must be set to enable Hybrid PQ key exchange in TLS.

If you’re using the Secrets Manager Agent, the Lambda extension, or the CSI Driver, upgrade to the listed version to use hybrid post-quantum key exchange in TLS as the default. Customers using the AWS SDK for Rust, Go, or Node.js at the versions listed in the table are already upgraded and no additional action is required. The SDK will select the hybrid post-quantum key exchange for API calls. For customers using the AWS SDK for Python, hybrid post-quantum key exchange in TLS requires OpenSSL 3.5 or later to be present on the host system. Guidance on verifying and enabling this is available in the AWS Secrets Manager documentation. For customers using the AWS SDK for Java v2, hybrid post-quantum key exchange in TLS requires using the AWS CRT HTTP client. The postQuantumTlsEnabled(true) must be set on the CRT client to enable hybrid post-quantum key exchange in TLS.

After your client versions meet the requirements listed in the table, you can verify that your connections are actively using hybrid post-quantum key exchange.

How to verify your connection uses hybrid post-quantum key exchange

With hybrid post-quantum key exchange using ML-KEM now enabled by default for Secrets Manager clients (see the preceding table), most customers will not need ongoing monitoring to verify correct behavior or detect regressions. However, security teams and compliance officers might want to confirm that their Secrets Manager API calls are negotiating the hybrid key exchange. On the server side, you can confirm hybrid post-quantum key exchange in TLS by using AWS CloudTrail. On the client side, you can inspect TLS handshake details using a utility like Wireshark or by using developer tools built into major web browsers.

Verification is a two-step process: first, fetch a secret using your Secrets Manager client to generate a GetSecretValue API call, then confirm in AWS CloudTrail that the call negotiated hybrid post-quantum key exchange.

Fetch your secret using your Secrets Manager client

The following examples show how to retrieve your secret using the Secrets Manager Agent, Lambda extension, and CSI Driver—each of which will automatically negotiate hybrid post-quantum key exchange when calling the GetSecretValue API.

To verify hybrid post-quantum TLS with Secrets Manager Agent on EC2 instance:
Install the agent on your Amazon Elastic Compute Cloud (Amazon EC2) instance and use it as a client to fetch your secret.

  1. Follow the instructions for AWS Secrets Manager Agent.
  2. Ensure that your EC2 instance profile has the permission for secretsmanager:GetSecretValue to fetch the secret.
  3. Connect to your private EC2 instance.
  4. Install the agent on your EC2 instance.
  5. Use the agent to fetch your secret.
    curl -H “X-Aws-Parameters-Secrets-Token: $(</tmp/awssmatoken)” localhost:2773/secretsmanager/get?secretId=<YOUR-SECRET-ARN>
  6. Wait for about 5 minutes for CloudTrail to deliver the logs.
  7. Go to the CloudTrail event history and search for the event GetSecretValue.

To verify hybrid post-quantum TLS with Lambda extension:
Use the AWS parameters and Secrets Manager Lambda extension to create a Lambda function that will consume your secrets from Secrets Manager using direct API calls.

  1. Follow Using the AWS parameters and secrets Lambda extension to create the Lambda layer and the Lambda function.
  2. Select the latest extension version.
  3. Wait for about 5 minutes for CloudTrail to deliver the logs.
  4. Go to the CloudTrail event history and search for the event GetSecretValue.

To verify hybrid post-quantum TLS with CSI driver on Amazon EKS:
On your Amazon Elastic Kubernetes Service (Amazon EKS) cluster, use the AWS Secrets Store CSI Driver provider to fetch secrets from Secrets Manager in Kubernetes pods:

  1. Confirm the installed add-on version is 2.0.0 or later.
    eksctl get addon --cluster <CLUSTER-NAME> --name aws-secrets-store-csi-driver-provider
  2. Trigger a secret retrieval by restarting a pod that mounts a secret, or deploying a new one.
  3. Wait for about 5 minutes for CloudTrail to deliver the logs.
  4. Go to the CloudTrail event history and search for the event GetSecretValue.

Confirm hybrid post-quantum key exchange using CloudTrail

CloudTrail logs include a tlsDetails field for Secrets Manager API calls. When hybrid post-quantum key exchange in TLS is active, the keyExchange field in tlsDetails will show X25519MLKEM768. Each CloudTrail record includes a tlsDetails field that contains the cipher suite and, where available, the key exchange group negotiated during the TLS handshake.

You can work with CloudTrail event history using the AWS Management Console for CloudTrail or the AWS Command Line Interface (AWS CLI).

To look up CloudTrail events using the console:

  1. Verify you are in the correct AWS Region.
  2. Open the CloudTrail console and select Event History.
  3. Under Lookup attributes filter, select Event name and GetSecretValue.
    Figure 1: Search CloudTrail event history by event name

    Figure 1: Search CloudTrail event history by event name

  4. Select your event.
    Figure 2: Select the event

    Figure 2: Select the event

  5. View the output in the Event Record section of the page.
    Figure 3: CloudTrail - GetSecretValue event

    Figure 3: CloudTrail – GetSecretValue event

To look up CloudTrail events using AWS CLI :
Using AWS CLI, select the last events and look at the output.

aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
--max-results 5 \
--region <YOUR-REGION> \
--query 'Events[0].CloudTrailEvent' \
--output text

Example of CloudTrail Event for GetSecretValue API call:

In the following example, the userAgent field reflects what it used as a client to connect to Secrets Manager.

Note: The userAgent value depends on the client you use.

{
    "eventVersion": "1.11",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROA123456789EXAMPLE:i-0c1a23fc456b7ab89",
        "arn": "arn:aws:sts::111122223333:assumed-role/YOUR-EC2-INSTANCE-PROFILE/i-0c1a23fc456b7ab89",
        "accountId": "111122223333",
        "accessKeyId": "ASIAIOSFODNN7EXAMPLE",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "AROA123456789EXAMPLE",
                "arn": "arn:aws:iam::111122223333:role/YOUR-EC2-INSTANCE-PROFILE",
                "accountId": "111122223333",
                "userName": "YOUR-EC2-INSTANCE-PROFILE"
            },
            "attributes": {
                "creationDate": "2026-03-27T17:08:37Z",
                "mfaAuthenticated": "false"
            },
            "ec2RoleDelivery": "2.0"
        },
        "inScopeOf": {
            "issuerType": "AWS::EC2::Instance",
            "credentialsIssuedTo": "arn:aws:ec2:eu-west-2:111122223333:instance/i-0c1a23fc456b7ab89"
        }
    },
    "eventTime": "2026-03-27T17:12:54Z",
    "eventSource": "secretsmanager.amazonaws.com",
    "eventName": "GetSecretValue",
    "awsRegion": "eu-west-2",
    "sourceIPAddress": "1.2.3.4",
    "userAgent": "aws-sdk-rust/1.3.14 os/linux lang/rust/1.94.1 aws-secrets-manager-agent/2.0.0",
    "requestParameters": {
        "secretId": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
    },
    "responseElements": null,
    "requestID": "027507ea-f377-43d9-bf2f-646d4dc19223",
    "eventID": "f9c3ed0f-81f5-450b-a561-2b9e54fa9e73",
    "readOnly": true,
    "resources": [
        {
            "accountId": "111122223333",
            "type": "AWS::SecretsManager::Secret",
            "ARN": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
        }
    ],
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "111122223333",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.3",
        "cipherSuite": "TLS_AES_128_GCM_SHA256",
        "clientProvidedHostHeader": "secretsmanager.eu-west-2.amazonaws.com",
        "keyExchange": "X25519MLKEM768"
    }
}

If the keyExchange field shows X25519MLKEM768, then hybrid post-quantum key exchange in TLS is active. If it shows a traditional algorithm such as X25519, the client is not advertising ML-KEM support, and you should check the client version and configuration.

Troubleshooting

If your Secrets Manager API calls aren’t negotiating X25519MLKEM768 after updating your clients, check your SDK version, OpenSSL version (Python), and firewall or proxy configuration as shown in the Client Hybrid Post-Quantum Key Exchange Requirements section near the beginning of this post.

What’s next

This launch is one step in a broader migration. AWS is continuing to roll out ML-KEM support across AWS service HTTPS endpoints as part of Workstream 2 of the AWS PQC Migration Plan, with a target of full coverage across public AWS endpoints.

Support for CRYSTALS-Kyber, the pre-standardization predecessor to ML-KEM, is phasing out across AWS endpoints in 2026. Customers on older SDK versions that advertise only CRYSTALS-Kyber support will fall back gracefully to traditional TLS rather than negotiate the deprecated algorithm. To avoid this fallback, upgrade to the SDK versions listed in this post.

The journey of PQC migration extends beyond confidentiality of data in transit. To stay informed about the latest developments in the AWS PQC journey and your side of shared responsibility, follow the AWS Post-Quantum Cryptography page.

Conclusion

AWS Secrets Manager now enables hybrid post-quantum key exchange using ML-KEM by default to help protect your secrets and support your compliance efforts. This update requires no code changes or configuration updates for customers using the latest client versions.

This post covered how AWS Secrets Manager uses hybrid post-quantum cryptography to secure TLS connections, which clients support this capability, and how to verify that your connections are protected against harvest now, decrypt later attacks.

To benefit from this announcement today:

  • Upgrade your Secrets Manager client (Agent, Lambda extension, or CSI Driver) to the latest available versions to enable hybrid post-quantum key exchange using ML-KEM
  • If your workload uses the AWS SDK instead of a caching client, upgrade your AWS SDK and underlying dependencies to the minimum versions listed in this post
  • Verify hybrid post-quantum key exchange in TLS is active by checking the keyExchange field in CloudTrail tlsDetails for your Secrets Manager API calls
  • Test end-to-end hybrid post-quantum key exchange TLS connectivity in your environment, including network paths that traverse corporate firewalls or proxies

AWS will continue rolling out post-quantum cryptography support. For information about the broader migration effort, see the AWS PQC Migration Plan. Keep an updated cryptographic inventory of your broader environment to identify other uses of traditional public-key cryptography that will require migration. The CISA Quantum-Readiness guidance and the AWS PQC Migration Plan are good starting points.

Additional resources

If you have feedback about this post, submit comments in the Comments section below.

P. Stéphanie Mbappe

P. Stéphanie Mbappe

Stéphanie is a Security Consultant with Amazon Web Services. She delights in assisting her customers at any step of their security journey. Stéphanie enjoys learning, designing new solutions, and sharing her knowledge with others.

Tobias Nickl

Tobias Nickl

Tobias is a Security Consultant at Amazon Web Services, specializing in security architecture and cloud transformation. He partners with AWS customers to design and implement security architectures that address both current and emerging threats. Through his work, he helps organizations build security strategies that evolve with their cloud maturity.

The collective thoughts of the interwebz