Случаят Джем (Йоздемир). Защо „Зелените“ победиха в Баден-Вюртемберг

Post Syndicated from Светла Енчева original https://www.toest.bg/sluchayat-dzhem-yozdemir-zashto-zelenite-pobediha-v-baden-vyurtemberg/

Случаят Джем (Йоздемир). Защо „Зелените“ победиха в Баден-Вюртемберг

Резултатите от изборите в една германска федерална провинция на пръв поглед бяха изненада. Провинцията е Баден-Вюртемберг, а на изборите, които се проведоха на 8 март, спечелиха „Зелените“ – въпреки прогнозите, даващи през целия период преди вота преднина на Християндемократическия съюз (ХДС). „Зелените“ победиха едва с 0,5 процентни пункта (30,2% срещу 29,7% за ХДС) и ще управляват паритетна коалиция с християндемократите – и двете партии ще разполагат с по 56 места в местния парламент.

„Зелените“
30,2%

ХДС
29,7%

АзГ
18,8%

СДП
5,5%

Свободни демократи
4,4%

Разлика между първите две партии: 0,5 пункта
Източник: Tagesschau


Загубата на ХДС обаче е знакова и поразклаща позициите на канцлера Фридрих Мерц, който е и председател на партията. А големият победител, също като героя от романа на Вера Мутафчиева, се казва Джем. Само че Йоздемир. И не е османски принц, а син на турски гастарбайтери.

„Майната ви, тук сме!“ Децата на гастарбайтерите и стрийткултурата
Във втората част от поредицата си за гастарбайтерската песен Емине Садкъ ни връща в 90-те, когато децата на гастарбайтерите градят идентичността си през субкултурни общности и с музиката си дават отпор на неонацистките движения.
Случаят Джем (Йоздемир). Защо „Зелените“ победиха в Баден-Вюртемберг

Защо победата на „Зелените“ в югозападната провинция беше изненада?

За да отговорим на този въпрос, трябва да хвърлим светлина върху местния контекст. Партия „Зелените“ всъщност е основана тъкмо в Баден-Вюртемберг през 1980 г. – в град Карлсруе. Тя има по-силни позиции в тази федерална провинция, отколкото в останалата част на Германия, и вече 15 години (от 2011 г. досега) е управляваща. От 1953 до 2011 г. водещата политическа сила в Баден-Вюртемберг е ХДС, която години наред дори има пълно мнозинство в местния парламент.

Между 2021 и 2025 г. „Зелените“ заедно със Социалдемократическата партия (СДП) и „Свободните демократи“ са част от управляващата коалиция в Германия, известна като „Светофар“ (заради цветовете на трите партии). Върху нея се стовариха последствията от COVID-19 и от войната на Русия срещу Украйна и като цяло правителството ѝ не се запомни с добро. И трите партии загубиха много от дотогавашната си подкрепа, като „Свободните демократи“ дори не преминаха 5-процентовата бариера за влизане в настоящия парламент.

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

В богатата провинция Баден-Вюртемберг, в която повечето села изглеждат като излезли от рекламен каталог, водещите индустрии са автомобилната и земеделието. В столицата ѝ Щутгарт се намират централите на „Порше“ и на концерна „Мерцедес-Бенц Груп“, произвеждащ „Мерцедес“ и „Мини“. Хиляди работни места, както и милиони от данъчни приходи за отделните общини зависят от просперитета на тази индустрия. Логично е местните да не горят от нетърпение за бърз преход към зелена енергия.

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

Както например християндемократите са по-либерални в области като Северен Рейн-Вестфалия, така и „Зелените“ са по-консервативни в Баден-Вюртемберг. Те са и по-умерени в екологичните си политики. Известна е крилатата фраза на досегашния премиер на провинцията Винфрид Кречман, изречена на местен диалект, с която той иска да сложи точка на критиките срещу „Зелените“, демонстрирайки, че местната автомобилна индустрия е важна за правителството му и лично за него. Ако се опитаме да предадем типичното за тази част на Германия диалектно ш-кане, може да преведем думите му така:

Миништър-предшедателят на Баден-Вюртемберг кара [автомобил на] „Даймлер“. Башта! [от basta, итал. ‘стига’ – б.а.]

„Даймлер-Бенц“ е бившето име на концерна „Мерцедес-Бенц Груп“.

Като говорим за консерватизма в Баден-Вюртемберг обаче (както и в Германия като цяло), не трябва да си го представяме като българските му версии. Той не отрича нито либералната демокрация, нито правата на човека, а още по-малко бъдещето на страната в ЕС. Според резултатите от екзитпол, актуални към 16:10 часа в деня на изборите, като най-голямо свое притеснение 72% от гласоподавателите посочват именно сигурността на Европа. На второ и трето място се нареждат съответно заплахата за демокрацията и правовата държава и опасението, че автомобилната индустрия в региона няма бъдеще. Следват тревоги от икономическо естество, а неприемането на чужденците е на предпоследно място – с 48%.


„Притеснявам се, че…“

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

Сигурността в Европа е застрашена
72%

Демокрацията и правовата държава са в опасност
64%

Автомобилната индустрия в Баден-Вюртемберг няма бъдеще
60%

В напреднала възраст ще имам финансови проблеми
56%

Цените ще растат толкова, че няма да мога да си плащам сметките
52%

Няма да мога да поддържам жизнения си стандарт
50%

Твърде много чужденци идват в Германия
48%

В Баден-Вюртемберг вече не може да се чувстваш в безопасност
43%

Източник: Tagesschau

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

А за гласоподавателите от първостепенно значение е икономиката – 29% от тях я посочват като най-значима (със 7 процентни пункта повече, отколкото на изборите през 2021 г.), докато климатът е на трето място – това е приоритет за 16% (с 3 пункта по-малко, отколкото през 2021 г.). Най-голям дял – 38%, имат доверие на ХДС, че може да се справи с икономическите проблеми. На второ място е Алтернатива за Германия (АзГ) с 15%, а „Зелените“ са чак на трето – с 13%.


Коя тема е най-важна за избора?

спрямо 2021

Икономика
Промяна спрямо 2021: +7
+7
29%

Социална сигурност
Промяна спрямо 2021: +1
+1
17%

Околна среда, климат
Промяна спрямо 2021: -3
-3
16%

Вътрешна сигурност
Промяна спрямо 2021: +7
+7
15%

Образование, училище
Промяна спрямо 2021: -3
-3
12%

Миграция
Промяна спрямо 2021: +3
+3
8%

Транспорт
Без отчетена промяна спрямо 2021
—
1%

Коя партия според избирателите може да се справи с икономиката?

ХДС
38%

АзГ
15%

„Зелените“
13%

Парадоксът: печели партия, която според избирателите не е водеща в справянето с главната тема на изборите.
Източник: Tagesschau

Сега вече става ясно защо победата на „Зелените“ е изненада. И все пак на какво се дължи тя?

Програмата или кандидатът?

За гласоподавателите на ХДС най-важно за решението за кого да гласуват е програмата на партията, докато за избирателите на „Зелените“ от първостепенно значение е кандидатът. Възможно обяснение за тази разлика е не само че програмата на християндемократите по-добре отговаря на приоритетите на местните жители, а и че „Зелените“, за разлика от тях, имат по-силен водещ кандидат. Джем Йоздемир е популярен политик от десетилетия, докато за конкурента му Мануел Хагел не се знае много.

Запитани дали биха гласували за Йоздемир, или за Хагел, ако можеха директно да изберат премиера на провинцията си, само избирателите на ХДС и АзГ показват предпочитание за кандидата на християндемократите, а всички останали – за този на „Зелените“. При това 22% от самите християндемократи биха предпочели Йоздемир, а едва 2% от „Зелените“ – Хагел.

Как е възможно хомосексуална жена да е начело на „Алтернатива за Германия“
В случай че някой се чуди как точно се връзва личността на Алис Вайдел с посоката и позициите на партията ѝ, Светла Енчева дава някои много интересни отговори. И не, „Алтернатива за Германия“ не е германското „Възраждане“, защото радикализацията там върви по съвсем друга линия.
Случаят Джем (Йоздемир). Защо „Зелените“ победиха в Баден-Вюртемберг

Йоздемир печели, и то с между 10 и 27 пункта, сред всички възрастови групи. Също и (с между 9 и 22 пункта) по всички личностни показатели, включени в екзитпола – по-симпатичен, по-компетентен, по-добре пасващ на областта, вдъхващ повече доверие. Удовлетворението от политическата му дейност също е на ниво – по-висока оценка в това отношение получава само Кречман – досегашният премиер на Баден-Вюртемберг.

Личността на Йоздемир обаче е по-силен фактор за избирателите на „Зелените“, отколкото тази на Кречман през 2011, 2016 и 2021 г., когато партията, оглавявана от последния, е печелила изборите в провинцията. Тя е била решаваща за 51% от тях – резултат, до който Кречман е най-близко през 2016 г., радвайки се на 48%. За сравнение, от 2001 г. досега личността на кандидата на християндемократите е била решаващ фактор най-много за 29% от избирателите на ХДС.

Кой е този толкова решаващ фактор Йоздемир?

Джем Йоздемир е от първото поколение деца на турски гастарбайтери, родени в Германия. Той е от градчето Бад Урах, близо до Щутгарт. Завършва реална гимназия. Това е тип професионално училище, в което учениците не се дипломират с матура и съответно не могат директно да кандидатстват в университет. Но за дете на гастарбайтери и реалната гимназия е сериозно постижение, особено в онези години. Някои младежи от турски произход, родени в Германия, и днес не говорят добре немски. Той обаче си доучва в професионален колеж, който завършва с матура, а през 1994 г. получава диплома за висше образование със специалност „Социална педагогика“.

Гастарбайтерската песен като дом. Добре дошли в Алманя
В три поредни статии Емине Садкъ проследява генезиса, поколенията и социалния контекст на турската музика в Германия. Първият текст ни разказва за гастарбайтерската вълна през 60-те и нейната песен, копнееща за дом, но също така гневна и саркастична.
Случаят Джем (Йоздемир). Защо „Зелените“ победиха в Баден-Вюртемберг

Междувременно още през 1981 г., едва 16-годишен, става член на „Зелените“ – само година след създаването на партията и две години преди да се сдобие с германско гражданство. Следват периоди на възход в политическата му кариера, издънки, временни оттегляния и нови възходи. Йоздемир е бил депутат в Бундестага, после в Европейския парламент, след това отново в Бундестага. В „светофарното“ правителство той е земеделски министър, а през последната половин година от управлението му съвместява и поста на министър на образованието и науката.

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

Йоздемир е не само известен политик, а има и попкултурен статус. През 2022 г. например, няколко месеца след като става министър, се появява в два видеоклипа на известната германска пънк група Die Toten Hosen, превъплъщавайки се в участник в група за взаимопомощ в психиатрия:

Не чужденец, а нашенец

Джем Йоздемир не е от хората с миграционен произход, които свеждат идентичността си до етническите си корени. Автобиографичната му книга е озаглавена „Аз съм нашенец. Един анадолски шваба в Бундестага“¹ (Швабия е районът, в който е роден). Определя се и като „светски мюсюлманин“ и е сериозен критик на режима на Ердоган и на влиянието му върху голяма част от турците в Германия, а с това – и върху германската политика.

Тези му възгледи заедно с приноса му за признаването от Германия на арменския геноцид го превръщат във враг в очите на турския президент и привържениците му. Те личат и в разбиранията му за миграцията, които го причисляват по-скоро към консервативния лагер. През 2024 г. разказва пред Frankfurter Allgemeine Zeitung как дъщеря му е ставала обект на сексуални подмятания от страна на мигранти в Берлин, и посочва като причина патриархалните структури в държавите по произход на чужденците.

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

Всичко това не означава, че Йоздемир се отрича от турския си произход и заради това германците го харесват. По-скоро той, имайки германска идентичност, принадлежи към светски настроените етнически турци, критични към Ердоган и ислямизма, и по този начин допринася за преодоляването на стереотипите спрямо етноса си. Етническите турци биват различни, някои от тях може да са и критици на Ердоган, и пълноценни шваби. Понякога – и „по-католици от папата“ по отношение на миграцията. Цялата многоизмерност на идентичността – ако се случи да е в личност като тази на Джем Йоздемир, може да се окаже рецепта за политически успех.

Победата на „Зелените“ в Баден-Вюртемберг, макар и важна в национален план, е крехка

Не само заради нищожната преднина пред ХДС и третата позиция на АзГ – с 18,8%. Харизмата на Йоздемир може да е била решаващият фактор за спечелването на изборите, но тя няма как да компенсира неодобрението за политиките на „Зелените“. Участието им в управлението на страната и опитите им да превърнат идеите си в реалност накараха много германци да се отърсят от екологичните си блянове. Когато нещата опрат до собствения джоб и работно място, високите цели вече не са достатъчни.

Макар да спечелиха, „Зелените“ отбелязаха с 2,4 пункта по-нисък резултат, отколкото на изборите през 2021 г., а подкрепата си увеличиха ХДС – с 5,6 пункта, и най-вече АзГ – с 9,1 пункта. Големите губещи бяха СДП, които едва прескочиха 5-процентовата бариера, и „Свободните демократи“, които, както и на националните избори, се озоваха под нея.

Ако не искат да се обезличат като СДП, която като че в постиндустриалното общество не може да определи кой е електоратът ѝ, „Зелените“ ще трябва да предложат идеи, чието реализиране няма да води до икономическа катастрофа. В противен случай и политическото бъдеще на Йоздемир ще е далеч по-безславно от миналото му.


1 Преводът на заглавието е леко фриволен, с цел да се подчертае заигравката в него. Inländer означава по-скоро „местно лице“, буквално – някой, който е в страната, но е антоним на Ausländer (чужденец). По аналогичен начин можем да противопоставим нашенец на чужденец.

Гласовете на Америка – брой 13

Post Syndicated from Йоанна Елми original https://www.toest.bg/glasovete-na-amerika-broy-13/

Гласовете на Америка – брой 13

Година и малко измина от избирането на президента Тръмп, който обеща край на войните, по-ниски цени на горивата, спад на цените и инфлацията, по-ниски лихвени проценти и енергийно независима Америка. Дори на симпатизантите му вече става трудно да поддържат тезите, че някои войни са оправдани, че временното затягане на коланите и стискането на зъби си заслужават в името на по-голямата дългосрочна цел за Велика Америка (нещо като „светлото бъдеще“ за уж-капиталисти, чиито възгледи са формирани от TikTok и YouTube), че цените всъщност наистина са се понижили от времето на президента Байдън (засега само яйцата са поевтинели, но малко ли е; като няма мир – яжте яйца) и така нататък. 

Гласовете на Америка – брой 2
Във втория брой от новия бюлетин на „Тоест“, воден от Йоанна Елми, продължава виртуалната разходка из паралелните реалности на 100-те дни от втория мандат на Тръмп. Нещата са такива, каквито са, освен когато не са. Важно е да има яйца.
Гласовете на Америка – брой 13

Величията стигат дотам, че консервативната и най-гледана в страната телевизия Fox News трябваше да се извини, че е пускала стари записи с президента, който се появи с новата си шапка – част от мърча, достъпен за продажба в личния му сайт, на церемонията в памет на убитите в Кувейт американци. Появата с подобен аксесоар обичайно се смята за неуважително отношение към паметта на загиналите. Следва да уточним, че на грешно излъчените записи президентът е без шапка. Както посочва и AFP, през 2021 г. Тръмп атакува бившия президент Джо Байдън, защото си е гледал часовника по време на подобна церемония за загинали в Афганистан. Пийт Хегсет, тогава ководещ на шоуто „Фокс и приятели“, понастоящем министър на войната на САЩ, също остро разкритикува президента Байдън.

Някой беше казал, че „войната е мир, свободата е робство, невежеството е сила“, но в свят, в който всички виждат какви ли не конспиративни дистопии, само не и истината, случваща се току пред очите им, няма смисъл да се чудим кой какво е казал, по-добре да си го измислим. Но не за Иран, не за културните войни, в които само другата страна е грешна, и дори не за самолетите на летище „Васил Левски“ в София ще говорим в този бюлетин. За първото препоръчвам да изслушате Руслан Трад, за второто – да си припомните броя ни за културните войни, а за третото ви поздравявам с това меме на Мишел от Съпротивата, защото, ако не се посмеем, вероятно ще откачим. 

А иначе, ще си говорим за пари. За много, много пари. 

Два журналистически материала от последната седмица диктуват избора на тема: разследването на консорциума ProPublica, който разкрива финансовите връзки между приближените на Тръмп, част от неговата администрация, и индустриите, които уж трябва да регулират; и анализът на New York Times, че през 2024 г. почти една пета от финансовите дарения за политика са били направени от милиардери. 

Разследването на ProPublica

Разследване на финансовите документи на над 1500 души, назначени от Тръмп, разкрива най-българската схема на света: подставени фирми и лица източват бюджета на страната през търгове, държавни поръчки и договори. 

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

Назначените от президента служители: 

  • Вече няма нужда да се съобразяват с правилото, което им забраняваше в рамките на две години да работят по въпроси, свързани с предишни техни лобистки дейности или клиенти. 
  • Няма нужда да се тревожат, че ще ги притесни някой от главните инспектори, които разследват измами, корупция и конфликти на интереси във всички клонове на федералното правителство. Президентът Тръмп ги уволни до един – всички 17. 
  • Вече могат да бъдат спокойни, че Кабинетът по правителствена етика също няма да им се меси – президентът уволни директора му и в момента службата работи без ръководство. 

Благодарение на това: 

  • Висши служители на изпълнителната власт, като главната прокурорка Пам Бонди, извършват сделки с ценни книжа, сключени в подходящ момент, и понякога продават акции непосредствено преди пазарите да се сринат, когато президентът Тръмп обявява нови мита. 
  • Двама високопоставени учени от Агенцията за опазване на околната среда, които преди това са заемали ръководни постове във водеща група в химическата промишленост, съдействат за занижаване на оценката на ведомството относно рисковете за здравето от формалдехида. 
  • Лица, притежаващи стотици милиони долари в инвестиции в криптовалута, в момента заемат позиции, чрез които контролират или влияят върху регулирането на криптоиндустрията. Един от тях е Тод Бланш – бивш адвокат на президента Тръмп и настоящ втори по ранг служител в американското Министерство на правосъдието. Неговите документи показват, че е притежавал най-малко 150 000 долара в активи, свързани с криптовалути, докато е прекратявал разследвания срещу криптокомпании, дилъри и борси. 

Както посочват и журналистите от ProPublica, конфликтите на интереси не са нищо ново в американската държавна машина. Една от най-логичните и най-широко подкрепяните от обществото мерки – законодателство, което да забрани на политиците да търгуват на стоковата борса, използвайки вътрешна информация, не е приета именно поради корупция и липса на политическа воля. Така се зараждат казуси като този на главната прокурорка Пам Бонди или на Нанси Пелоси – бившата говорителка на Камарата на представителите. Схемите на Пелоси на стоковата борса са толкова известни, че на нея е кръстена цяла инициатива, която позволява на обикновените граждани да следят инвестиционните ѝ сделки и евентуално да направят свой опит за печалба. 

Гласовете на Америка – брой 7
И либерали, и консерватори си мият ръцете със свободата на словото, замервайки се с вини и първопричини. Но какво означава убийството на неоконсервативния активист Чарли Кърк? Йоанна Елми е сигурна, че Америка не я чакат добри времена. Светът също не се е запътил към тях.
Гласовете на Америка – брой 13

„Установих, че на никого не му дреме и ми е позволено“, казва президентът пред New York Times в отговор на въпрос за облагодетелстването на семейството му и приближените му след встъпването му в длъжност. Говорителката на Белия дом Анна Кели пък каза, че

президентът Тръмп е начело на една от най-прозрачните администрации в историята. 

В университета имах чудесна преподавателка по конституционно право, която казваше, че „прозрачността“ е едно от най-умните изобретения на политическия елит: корупцията и нарушенията са прозрачни, налични в огромни, неразбираеми бази данни, а схемите не могат да бъдат разбрани от обикновения избирател, за когото е много по-лесно да повярва в далеч по-прости неща. На никого не му дреме, позволено е, прозрачно е – по-добре едва ли може да се каже.

Политическите дарения на милиардерите

300 милиардери и техни близки са дарили над 3 млрд. долара – 19% от всички дарения – за различни федерални избори през 2024 г. Преди само пет избирателни цикъла и преди решението на Върховния съд от 2010 г., което премахва повечето ограничения за политическите дарения, сумата, похарчена от милиардери за демокрация, е едва 0,3%. 

Дареното от един милиардер се равнява на дареното от 100 000 „обикновени“ донори. В този процент обаче не са включени парите, дарени от свръхбогатите по други канали, например на т.нар. dark money groups (букв. „тъмни пари“) – различни бизнес и неправителствени организации и асоциации, които не са задължени от закона да разкриват кой им е дал парите, за да направят те самите дарение. Анализът на New York Times не включва и медиите например, които създават идеологически и политически екосистеми. 

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

Подобна тенденция не е прецедент в историята на САЩ, като в миналото и двете партии са жънали ползи от нея. През 2024 г. обаче се наблюдава рязко покачване на даренията за републиканците. Голяма част от парите идват от технологичния сектор, който подкрепи заявките на президента Тръмп за ниски данъци и дерегулация. Над десет милиардери получиха постове в администрацията на президента. 

Гласовете на Америка – брой 9
Какво всъщност представляват културните войни, как изглеждат те в момента в САЩ и по какъв начин се изнасят извън американските граници? Надеждата за спасението на демокрацията е в разбирането на същността ѝ – здравата демокрация по условие дава пространство за различията. От Йоанна Елми.
Гласовете на Америка – брой 13

Пример за всичко изброено е Джеф Яс – съосновател на търговската фирма Susquehanna International Group, дарил над 100 млн. долара в различни изборни надпревари през 2024 г. и 55 млн. долара за федерални кампании през 2026 г. Влиянието му е очевидно в щата Пенсилвания, където надпреварата за главен прокурор през 2024 г. беше между републиканеца Дейв Съндей и демократа Юджийн Депаскуале. Яс подкрепи републиканския кандидат, осигурявайки близо 90% от 14-те млн. долара, отишли за кампанията му.

Съндей печели с 51% от гласовете и в момента е начело на службата, разследваща TikTok – социалната мрежа, в която Джеф Яс е основен инвеститор. И далеч не става въпрос за „ти на мене, аз на тебе“: щатските постове често са трамплин за губернаторско място, а Яс има амбиции за много по-всеобхватни политики, особено в сферата на финансирането на държавните училища. Идеята му е да има „избор“ и „парите да следват ученика“, което неизменно ще доведе до закриване на държавни училища. Политическите съветници на Яс казват пред New York Times, че играят дългосрочна игра. 

И последната свежа великоамериканска новина от последните дни: организацията Open the Books отчита исторически рекорд в разходите на САЩ за септември 2025 г., когато федералните агенции са похарчили безпрецедентните 93,4 млрд. долара за грантове и договори. Този септемврийски бум е традиционен и има за цел остатъкът от бюджета да се изразходва преди края на фискалната година, за да се избегнат съкращения през следващата.

Типичен пример са разходите за мебели, които в Министерството на отбраната скачат средно с 564% спрямо останалите месеци. През 2025 г. ведомството е платило 225,6 млн. долара за обзавеждане, включително за луксозни столове Herman Miller на стойност 1844 долара за брой и за декоративни поставки за плодове, струващи 12 000 долара.

Освен към офис оборудване, бюджетът за отбрана е бил насочен и към необичайни хранителни продукти и външни контрагенти. През септември Пентагонът е похарчил 2 млн. долара за кралски раци от Аляска – рекорд, достиган няколко пъти по време на мандатите на Доналд Тръмп, и безпрецедентните над 7,4 млн. долара за опашки от омари в рамките на годината. Паралелно с това покупките от чужди правителства и компании също достигат връх от 6,6 млрд. долара, като основни бенефициери са Обединеното кралство, Швейцария и Канада.

Основният призив на Open the Books е Конгресът да преразгледа произволно определения едногодишен срок за усвояване на бюджетите и да позволи прехвърлянето на средства към следващата година. Според организацията това е единственият начин да се сложи край на безразсъдното септемврийско прахосничество за луксозни стоки и да се предприемат реални стъпки за овладяване на огромния държавен дефицит. Разбира се, това следваше и да е сред основните цели на консерваторите.

Накрая обаче ще се окаже, че политиката и демокрацията отдавна не са идеали. В XXI век са просто добра инвестиция. В раци, омари и мебели. А за този, който няма, остават яйцата, както вече казахме.

Гласът на миналото 

Гласовете на Америка – брой 13
Източник: Wikimedia Commons

Карикатурата Bosses of the Senate („Господарите на сената“), публикувана в списание Puck на 23 януари 1889 г., илюстрира огромното влияние на монополистите над Сената на САЩ по време на Позлатената епоха (Gilded Age). Изобразени са могъщи бизнесмени, които се извисяват над сенаторите – символ на корпоративното влияние в политиката. Придружаващият надпис гласи: „Това е Сенатът на монополистите, от монополистите и за монополистите“, подчертавайки корупцията и провала на правната система да държи богатите елити отговорни. 


Абонирайте се, за да получавате този бюлетин на електронната си поща в момента, в който излезе!

Вече сте регистриран потребител на Toest.bg? Може директно от настройките на бюлетините в своя профил да изберете „Гласовете на Америка“ или да натиснете бутона по-долу:

Още нямате профил в Toest.bg? Регистрирайте се само с няколко клика:

Meta Outlines New MTIA Accelerator Roadmap for its Next-Gen AI Compute Mix

Post Syndicated from Cliff Robinson original https://www.servethehome.com/meta-outlines-new-mtia-accelerator-roadmap-for-its-next-gen-ai-compute-mix/

Meta shared more on its MTIA 300 AI accelerator, already in production, and future MTIA 400, 450, and 500 generations for its infrastructure

The post Meta Outlines New MTIA Accelerator Roadmap for its Next-Gen AI Compute Mix appeared first on ServeTheHome.

Introducing account regional namespaces for Amazon S3 general purpose buckets

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/introducing-account-regional-namespaces-for-amazon-s3-general-purpose-buckets/

Today, we’re announcing a new feature of Amazon Simple Storage Service (Amazon S3) you can use to create general purpose buckets in your own account regional namespace simplifying bucket creation and management as your data storage needs grow in size and scope. You can create general purpose bucket names across multiple AWS Regions with assurance that your desired bucket names will always be available for you to use.

With this feature, you can predictably name and create general purpose buckets in your own account regional namespace by appending your account’s unique suffix in your requested bucket name. For example, I can create the bucket mybucket-123456789012-us-east-1-an in my account regional namespace. mybucket is the bucket name prefix that I specified, then I add my account regional suffix to the requested bucket name: -123456789012-us-east-1-an. If another account tries to create buckets using my account’s suffix, their requests will be automatically rejected.

Your security teams can use AWS Identity and Access Management (AWS IAM) policies and AWS Organizations service control policies to enforce that your employees only create buckets in their account regional namespace using the new s3:x-amz-bucket-namespace condition key, helping teams adopt the account regional namespace across your organization.

Create your S3 bucket with account regional namespace in action
To get started, choose Create bucket in the Amazon S3 console. To create your bucket in your account regional namespace, choose Account regional namespace. If you choose this option, you can create your bucket with any name that is unique to your account and region.

This configuration supports all of the same features as general purpose buckets in the global namespace. The only difference is that only your account can use bucket names with your account’s suffix. The bucket name prefix and the account regional suffix combined must be between 3 and 63 characters long.

Using the AWS Command Line Interface (AWS CLI), you can create a bucket with account regional namespace by specifying the x-amz-bucket-namespace:account-regional request header and providing a compatible bucket name.

$ aws s3api create-bucket --bucket mybucket-123456789012-us-east-1-an \
   --bucket-namespace account-regional \
   --region us-east-1

You can use the AWS SDK for Python (Boto3) to create a bucket with account regional namespace using CreateBucket API request.

import boto3

class AccountRegionalBucketCreator:
    """Creates S3 buckets using account-regional namespace feature."""
    
    ACCOUNT_REGIONAL_SUFFIX = "-an"
    
    def __init__(self, s3_client, sts_client):
        self.s3_client = s3_client
        self.sts_client = sts_client
    
    def create_account_regional_bucket(self, prefix):
        """
        Creates an account-regional S3 bucket with the specified prefix.
        Resolves caller AWS account ID using the STS GetCallerIdentity API.
        Format: ---an
        """
        account_id = self.sts_client.get_caller_identity()['Account']
        region = self.s3_client.meta.region_name
        bucket_name = self._generate_account_regional_bucket_name(
            prefix, account_id, region
        )
        
        params = {
            "Bucket": bucket_name,
            "BucketNamespace": "account-regional"
        }
        if region != "us-east-1":
            params["CreateBucketConfiguration"] = {
                "LocationConstraint": region
            }
        
        return self.s3_client.create_bucket(**params)
    
    def _generate_account_regional_bucket_name(self, prefix, account_id, region):
        return f"{prefix}-{account_id}-{region}{self.ACCOUNT_REGIONAL_SUFFIX}"


if __name__ == '__main__':
    s3_client = boto3.client('s3')
    sts_client = boto3.client('sts')
    
    creator = AccountRegionalBucketCreator(s3_client, sts_client)
    response = creator.create_account_regional_bucket('test-python-sdk')
    
    print(f"Bucket created: {response}")

You can update your infrastructure as code (IaC) tools, such as AWS CloudFormation, to simplify creating buckets in your account regional namespace. AWS CloudFormation offers the pseudo parameters, AWS::AccountId and AWS::Region, making it easy to build CloudFormation templates that create account regional namespace buckets.

The following example demonstrates how you can update your existing CloudFormation templates to start creating buckets in your account regional namespace:

BucketName: !Sub "amzn-s3-demo-bucket-${AWS::AccountId}-${AWS::Region}-an"
BucketNamespace: "account-regional"

Alternatively, you can also use the BucketNamePrefix property to update your CloudFormation template. By using the BucketNamePrefix, you can provide only the customer defined portion of the bucket name and then it automatically adds the account regional namespace suffix based on the requesting AWS account and Region specified.

BucketNamePrefix: 'amzn-s3-demo-bucket'
BucketNamespace: "account-regional"

Using these options, you can build a custom CloudFormation template to easily create general purpose buckets in your account regional namespace.

Things to know
You can’t rename your existing global buckets to bucket names with account regional namespace, but you can create new general purpose buckets in your account regional namespace. Also, the account regional namespace is only supported for general purpose buckets. S3 table buckets and vector buckets already exist in an account-level namespace and S3 directory buckets exist in a zonal namespace.

To learn more, visit Namespaces for general purpose buckets in the Amazon S3 User Guide.

Now available
Creating general purpose buckets in your account regional namespace in Amazon S3 is now available in 37 AWS Regions including the AWS China and AWS GovCloud (US) Regions. You can create general purpose buckets in your account regional namespace at no additional cost.

Give it a try in the Amazon S3 console today and send feedback to AWS re:Post for Amazon S3 or through your usual AWS Support contacts.

— Channy

iPhones and iPads Approved for NATO Classified Data

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/03/iphones-and-ipads-approved-for-nato-classified-data.html

Apple announcement:

…iPhone and iPad are the first and only consumer devices in compliance with the information assurance requirements of NATO nations. This enables iPhone and iPad to be used with classified information up to the NATO restricted level without requiring special software or settings—a level of government certification no other consumer mobile device has met.

This is out of the box, no modifications required.

Boing Boing post.

How to manage the lifecycle of Amazon Machine Images using AMI Lineage for AWS

Post Syndicated from George'son Tib original https://aws.amazon.com/blogs/security/how-to-manage-the-lifecycle-of-amazon-machine-images-using-ami-lineage-for-aws/

As organizations scale their cloud infrastructure, maintaining proper lifecycle management of Amazon Machine Images (AMIs) is a critical component of their security and risk management goals. AMIs provide the essential information required to launch Amazon Elastic Compute Cloud (Amazon EC2) instances, however; they present security and compliance challenges if not tracked and managed throughout their lifecycle. This blog post explores how organizations can meet their evolving security and compliance requirements by managing potential vulnerabilities across the AMIs deployed throughout their AWS environment.

At the end of 2024, AWS announced lineage supportfor Amazon EC2, providing source details for your AMIs. With this lineage information, you can trace copied or derived AMIs back to their original source. The source AMI information is available for AMIs that were created using specific API commands like CreateImage, CopyImage, and CreateRestoreImageTask. If the AMI was created using a different API command, the ID and AWS Region of the source AMI don’t appear, which can create visibility gaps that potentially impact security and compliance efforts.

To address these gaps and provide comprehensive AMI governance, organizations need to build additional capabilities to analyze the scope of impact of Common Vulnerabilities and Exposures (CVEs), ensure deployed resources originate from an approved golden image, and respond to audit inquiries that require a clear chain of custody for AMIs. A well-designed solution should also help track and enforce approved AMI creation patterns across all accounts and AWS Regions. The AMI lineage solution described in this post is designed to help you manage your organization’s AMI hierarchy and lifecycle, including tracking AMI origins and usage throughout its AWS environment. By implementing this solution, your security teams can quickly understand the scope of impact when security vulnerabilities are discovered, help ensure compliance with organizational policies, and maintain better visibility into their AMI estate.

The solution in this blog post uses Amazon Neptune, a high-performance graph database, along with native AWS security services to maintain a comprehensive view of AMI relationships and enable proactive security monitoring. With the solution in place, you can enforce controls on AMI sourcing, including validation of marketplace AMIs through service control policies (SCPs), and maintain compliance with organizational and regulatory requirements throughout the AMI lifecycle.

Solution overview

AMI Lineage provides a comprehensive governance solution that uses AWS security services and Neptune to create and maintain a hierarchical graph representation of their AMI relationships. This solution helps security and compliance teams understand the complete history of their AMIs including where they originated from, enforce organizational policies such as requiring all AMIs to be encrypted, and rapidly assess security impacts across their organization.
The solution integrates core AWS services with security and governance capabilities. The core components of the solution in the security tooling account are:

  • Neptune: A purpose-built, high-performance graph database securely stores and manages the AMI relationship data.
  • AWS Lambdafunctions serve as the processing engine for the solution. They process AMI lifecycle events (such as CreateImage, CopyImage, DeregisterImage), evaluate them against compliance rules, and update the Neptune graph database. The functions are configured with least-privilege AWS Identity and Access Management (IAM) permissions to enhance security.
  • Amazon API Gateway provides secure REST endpoints for lineage queries and security assessments. Authentication is handled using a combination of API keys and IAM roles to help ensure that only authorized users and systems can access the data.

From a governance perspective, this solution provides comprehensive AMI origin validation to help ensure AMIs come from approved sources, including the validation of AWS Marketplace AMIs against a list of trusted vendors. Lifecycle management capabilities enforce AMI retention policies and deprecation processes. Compliance monitoring tracks adherence to organizational and regulatory requirements, while security event scope assessment capabilities quickly identify affected resources when security vulnerabilities are discovered. A detailed audit trail maintains a complete history of AMI creation, modification, and usage patterns.

Architecture

The AMI Lineage solution follows AWS security best practices with a multi-account deployment architecture designed to maximize security while maintaining operational efficiency. The architecture distributes responsibilities across three primary account types: an organization management account, a centralized security tooling account, and multiple member accounts.

This architectural approach helps ensure that sensitive operations and data remain centralized in the security tooling account while enabling distributed monitoring and policy enforcement across the organization. The clear separation of concerns enhances security while maintaining the scalability needed for large-scale AWS deployments.

Figure 1: AMI Lineage solution architecture and workflow

Figure 1: AMI Lineage solution architecture and workflow

The workflow and architecture shown in figure one includes the following:

  1. Policy enforcement: The organization management account is the central point for control. It uses AWS Organizations to enforce SCPs that prevent non-compliant AMI actions across the member accounts.
  2. Event capture: When an AMI lifecycle event (like CreateImage or CopyImage) occurs in a member account, a local Amazon EventBridge rule captures it.
  3. Centralized processing: The event is securely forwarded from the member account’s EventBridge to the central EventBridge in the security tooling account.
  4. Data ingestion and analysis: A Lambda function is triggered in the security tooling account. This function processes the event, analyzes it for compliance, and updates the Neptune graph database with the new AMI relationship data. AWS Security Hub and Amazon GuardDuty in the security tooling account also receive and analyze findings from member accounts.
  5. Query and visualization: Security teams query the lineage data through a secure API Gateway endpoint. By doing this, they can to visualize AMI hierarchies, investigate security findings from Security Hub, and assess the scope of impact for a given AMI.

The organization management account serves as the central control point for policy enforcement and organizational oversight. This account hosts SCPs that prevent non-approved AMI usage across the organization and manages organization-wide EventBridge rules that capture AMI events from member accounts. Cross-account trust policies configured in this account enable secure communication between the management account and the security tooling account.

Additionally, the management account establishes Security Hub in delegated administrator mode, designating the security tooling account as the centralized security administrator for the organization. From the security tooling account, Security Hub can be then configured to aggregate all Regions down to one core Region for easier evaluation by security personnel.

The security tooling account acts as the central hub for AMI lineage processing and storage. This account hosts the Neptune graph database cluster with encrypted storage, helping to ensure that AMI relationship data is securely maintained. Lambda functions running in this account process events, handle API requests, and evaluate compliance with least-privilege permissions. API Gateway provides secure REST endpoints for lineage queries and security assessments. Security Hub custom insights and findings are centralized here in the security tooling account as the Security Hub delegated administrator account, along with Amazon Simple Notification Service (Amazon SNS) topics for notifications and alerts. The Amazon Virtual Private Cloud (Amazon VPC) infrastructure supporting these services is also deployed in the security tooling account, providing network-level isolation and security.

The solution enables distributed monitoring and enforcement by deploying lightweight components into each member account across the organization. Each member account includes AWS Config rules for continuous compliance monitoring, cross-account IAM roles to enable secure access from the security tooling account, and local EventBridge rules that forward AMI-related events to the central processing system.

Security and compliance integration extends throughout the solution. IAM manages least-privilege access control and permissions across components. AWS CloudTrail records API activity for audit trails and compliance reporting, while Security Hub centralizes security findings and compliance status across your AMI estate. GuardDuty provides threat detection for AMI-related activities. SCPs enforce organization-wide controls on AMI creation and usage patterns, and AWS Config tracks AMI configuration changes and evaluates compliance rules.

How it works

The AMI Lineage solution operates through a continuous monitoring and automated response system that maintains comprehensive visibility into your AMI landscape. When AMI lifecycle events occur in your organization, EventBridge rules capture these activities, including creation, copying, modification, and deregistration events. Lambda functions in the security tooling account are then called upon to process these events with appropriate security controls and update the Neptune graph database in real-time, while CloudTrail logs provide a comprehensive audit trail of AMI-related activities.

The system tracks critical security and compliance metadata that forms the foundation of effective AMI governance. This includes:

  • Source AMI information and validation status to help ensure lineage integrity
  • Creation method and timestamp data for comprehensive audit trails
  • Cross-Region and cross-account relationships to understand the full scope of AMI distribution
  • Instance launch history with security context to track usage patterns
  • AMI state changes including deprecation and deregistration for lifecycle management
  • Compliance status along with policy violations to maintain organizational standards.

Security teams use this comprehensive data through secure API calls to visualize complete AMI hierarchies and relationships, providing clear insight into how AMIs are related across your infrastructure. The compliance of your AMI estate is continuously tracked through a combination of services:

  • Detection: AWS Config rules deployed in member accounts check for policy violations (for example, incorrect tags and public permissions).
  • Aggregation: These findings, along with vulnerability data from services like Amazon Inspector, are aggregated in AWS Security Hub.
  • Correlation: Lambda functions in the security tooling account correlate this information with the lineage data in Neptune. Because of this correlation, you can see not just that an AMI is non-compliant, but also its entire downstream impact. When security events like CVE findings are discovered, teams can quickly assess the scope of impact across their entire AMI estate. The solution monitors AMI usage patterns for security anomalies and enforces governance controls through automated policy checks.

The solution provides robust automated policy enforcement capabilities that operate continuously to maintain security and compliance. The system helps ensure that only approved AMIs with verified lineage history can be used to launch new instances, automatically blocking attempts to use non-compliant images. SCP controls on AMI creation and usage are enforced organization-wide, preventing unauthorized AMI operations before they can impact your environment. When policy violations are detected, the system can trigger automated responses to security events and maintain compliance with organizational standards through real-time enforcement.

Implementation

Before deploying the AMI Lineage solution, you need to establish the proper security and governance foundation across your organization. Your AWS Organizations management account requires administrative permissions, and your organization must be enabled with all features to support the policies used in this solution. You will also need a dedicated security tooling account to host the solution’s core components, with cross-account IAM roles configured to allow secure access. Finally, essential security services must be configured at the organization level, including Security Hub, CloudTrail organization trails for audit logging, and encryption keys using AWS Key Management Service (AWS KMS) for data protection.

From a technical perspective, ensure you have Python 3.8 or later installed if deploying from a local environment, along with AWS Command Line Interface (AWS CLI) version 2 installed and configured with appropriate security credentials. You’ll also need an Amazon Simple Storage Service (Amazon S3) bucket for deployment artifacts, encrypted using SSE-KMS with a customer-managed key to align with best practices for protecting deployment assets.

The complete AMI Lineage solution is available as open source code in the AWS Samples repository. You can clone the repository and follow the deployment instructions. The repository includes the necessary AWS CloudFormation templates, Lambda functions, and deployment scripts referenced in the following phases.

Deployment

The deployment process follows a five-phase approach that builds security and compliance capabilities progressively:

  1. Security foundations
  2. Security controls
  3. EventBridge rules
  4. Core infrastructure
  5. Compliance and monitoring

Phase 1 – Establishing security foundations

The first phase establishes the security foundation by configuring AWS Organizations security services. This involves enablingSecurity Hub in the management account and designating the security tooling account as the delegated administrator, enablingnullGuardDuty with the security tooling account configured as thenulldelegated administrator, and enabling an organizational wide CloudTrail trail for audit logging.

# In Organization Management Account: 
# Enable Security Hub and set security tooling account as delegated admin 
aws securityhub enable-organization-admin-account \   
--admin-account-id <security-tooling-account-id> 

# Enable GuardDuty organization with security tooling account as admin   
aws guardduty enable-organization-admin-account \   
--admin-account-id <security-tooling-account-id> 

# Create organization trail with encryption aws cloudtrail create-trail \   
--name ami-lineage-trail \   
--s3-bucket-name <your-secure-bucket> \   
--is-organization-trail \   
--kms-key-id <your-kms-key-id> \   
--enable-log-file-validation

Phase 2 – Security controls

The second phase deploys base security controls through organization-wide SCPs. These policies enforce AMI governance controls by preventing the use of non-approved AMIs and helping to ensure that proper tagging and approval workflows are followed.

# In Organization Management Account: 
# Deploy organization-wide SCPs 
aws organizations create-policy \   
--content file://ami-governance-scp.json \   
--name "AMI-Governance-Controls" \   
--type SERVICE_CONTROL_POLICY 

# Attach to organizational units 
aws organizations attach-policy \   
--policy-id <policy-id> \   
--target-id <ou-id>

Phase 3 – EventBridge rules

The third phase deploys organization-wide EventBridge rules from the management account to capture AMI events across member accounts and forward them to the security tooling account for processing. These rules listen for specific API calls captured by CloudTrail.

An example of the event pattern used to capture CreateImage and CopyImage events looks like this:

{
	"source": ["aws.ec2"],
	"detail-type": ["AWS API Call via CloudTrail"],
	"detail": {
		"eventSource": ["ec2.amazonaws.com"],
		"eventName": [
			"CreateImage",
			"CopyImage",
			"RegisterImage",
			"DeregisterImage"
		]
	}
}

# In Organization Management Account: 
# Deploy organization EventBridge rules 
cd deployment-scripts/organization 
./deploy-organization-resources.sh

Phase 4 – Core infrastructure

The fourth phase focuses on core infrastructure deployment in the security tooling account. This is where the primary processing and storage components are deployed, following security best practices by centralizing sensitive operations in a dedicated account.

# Switch to Security Tooling Account context 
# Deploy Neptune cluster with encryption in security tooling account 
cd deployment-scripts/shared 
./deploy-shared-resources.sh

This deployment script handles multiple components in the security tooling account. The Neptune cluster deployment includes encryption and VPC configuration to help ensure secure storage and access to AMI lineage data. Lambda functions are deployed with security controls and configured with VPC attachment, which allows for secure Neptune access in the VPC, appropriate IAM roles with least-privilege permissions, and environment variables for secure configuration. API Gateway provides secure REST endpoints for external access to AMI lineage data and security assessments.

Phase 5 – Compliance and monitoring

The fifth phase establishes comprehensive compliance and monitoring capabilities across member accounts. AWS Config rules are deployed to continuously monitor AMI compliance across your organization, while EventBridge rules forward AMI events to the central processing system.

# In each Member Account: 
# Deploy AWS Config Rules and monitoring capabilities 
cd deployment-scripts/child-account   
./deploy-child-account-resources.sh

After deployment, thorough verification helps ensure that security configurations are properly implemented. This includes validating IAM permissions to help ensure least-privilege access, testing security controls to verify SCP enforcement, validating encryption settings acrosscomponents, and confirming that the security tooling account is properly configured as the Security Hub delegated administrator.

Using AMI Lineage

When deployed, AMI Lineage provides security operations and compliance monitoring capabilities through its API hosted in the security tooling account and automated monitoring systems. Security teams can query and receive complete AMI security relationships to understand the full context of AMIs in their environment.

When investigating AMIs, the system provides detailed security context including source validation information that confirms:

  • Whether AMIs come from marketplace sources or trusted accounts
  • Compliance status that shows patch levels and policy adherence
  • Vulnerability status with CVE findings and scan results
  • Comprehensive lineage data showing the complete chain of AMI relationships and approval history
# Get complete security context for an AMI (API Gateway in Security Tooling Account) 
curl -X GET "https://<api-gateway-id>.execute-api.<region>.amazonaws.com/v1/api/v1/ami/ami-1234567890abcdef0/security-context?include_compliance=true" \  
	-H "x-api-key: <your-api-key>"

For security impact assessments, such as when a new CVE is discovered, the solution provides a powerful scope of impact analysis. By querying the API with a specific finding, security teams can rapidly determine every affected resource across their entire organization that stems from a compromised or vulnerable AMI. Using that information, they can understand the full scope of their exposure and begin remediation. See Security best practices in Amazon API Gateway for helpful considerations while using API Keys.

# Assess for a security finding (Security Tooling Account API) 
curl -X POST "https://<api-gateway-id>.execute-api.<region>.amazonaws.com/v1/api/v1/security-impact" \   
	-H "Content-Type: application/json" \   
	-H "x-api-key: <your-api-key>" \   
	-d '{     "ami_id": 
		"ami-1234567890abcdef0",     
		"finding_type": "CVE",     
		"finding_id": "CVE-2024-XXXX",     
		"severity": "CRITICAL"   
	}'

This analysis returns impact information including:

  • Affected AMIs in the lineage chain
  • Running instances requiring immediate remediation
  • Affected AWS accounts and regions for coordinated response
  • Associated auto-scaling groups and launch templates that need updates
  • Compliance impact assessment for regulatory reporting
  • Detailed remediation steps prioritized by risk level.

Compliance monitoring operates continuously through automated assessment capabilities that evaluate your AMI estate against organizational policies and regulatory requirements. Teams can generate comprehensive compliance reports that show adherence to security standards across their entire infrastructure.

# Generate comprehensive compliance report (Security Tooling Account API) 
curl -X POST "https://<api-gateway-id>.execute-api.<region>.amazonaws.com/v1/api/v1/compliance-assessment" \   
	-H "Content-Type: application/json" \   
	-H "x-api-key: <your-api-key>" \   
	-d '{     
		"rules": [       
    		"required_tags",       
    		"approved_source_validation",       
    		"security_scan_status",       
    		"naming_convention",       
    		"lineage_verification"     
		],     
		"scope": "ORGANIZATION"   
	}'

The solution provides security automation and remediation through configurable automated responses to security events. Security Hub, operating in delegated administrator mode from the security tooling account, can be configured to automatically respond to findings by stopping instances using AMIs with critical vulnerabilities, quarantining instances launched from unapproved sources, and sending immediate notifications for high-severity findings.

Security visualization and reporting capabilities, centralized in the security tooling account, provide real-time dashboards showing:

  • Compliance status across the organization
  • Scoping visualization for rapid decision-making
  • AMI approval workflow status for process monitoring
  • Patch compliance metrics for maintaining security posture
  • Automated remediation activity logs for audit purposes
  • Custom security reports tailored to specific organizational needs.

For security investigations and audit purposes, the solution maintains a queryable audit trail that provides a complete history of AMIs, including creation and modification events, security scanning results and findings, approval workflow history, and compliance status changes over time.

# Query comprehensive audit history (Security Tooling Account API) 
curl -X GET "https://<api-gateway-id>.execute-api.<region>.amazonaws.com/v1/api/v1/ami/ami-1234567890abcdef0/lineage?direction=both&depth=10" \   
	-H "x-api-key: <your-api-key>"

Clean up

To decommission the AMI Lineage solution, use the following steps to prevent dependency errors. The process is the reverse of the deployment.

  1. (Optional) Back up your data. Before you begin, export critical data for your audit and compliance records. This includes generating final compliance reports from the API or creating a final snapshot of the Neptune database (you will be prompted to do this when you delete the cluster).
  2. Run cleanup in member accounts. Sign in to each participating member account and run the cleanup script from the deployment files. This removes the local EventBridge rules, AWS Config rules, and cross-account IAM roles.
    # In each Member Account 
    cd deployment-scripts/child-account
    ./cleanup-child-account-resources.sh 
    # Removes Config rules and cross-account roles from each member account

  3. Run cleanup in the security tooling account. Sign in to your security tooling account and run the cleanup script. This decommissions the core solution, including the API gateway, Lambda functions, Neptune cluster, and the associated VPC.
    # Clean up security tooling account   
    cd deployment-scripts/shared
    
    ./cleanup-shared-resources.sh 
    # Removes Neptune, Lambda, API Gateway, SNS, and Security Hub components

  4. Run cleanup in the organization management account. Sign in to your organization management account to remove the organization-level resources.
    1. Run the cleanup script to remove the organization-wide EventBridge rules.
      # Clean up organization management account
      
      cd deployment-scripts/organization
      
      ./cleanup-organization-resources.sh   
      # Removes SCPs, EventBridge rules, and cross-account trust policies

    2. In the AWS Organizations console, detach and delete the AMI-Governance-Controls SCP.
    3. In the Security Hub and GuardDuty consoles, remove the security tooling account as the delegated administrator.
  5. Delete final data and encryption keys. After the solution’s infrastructure is removed, you can delete the remaining assets.
    1. In the security tooling account,empty and delete the S3 bucket that held the deployment artifacts.
    2. In the organization management account,schedule the deletion of the KMS keys you created for encrypting the solution’s data.

Conclusion

In this blog post, we showed you how you can use the AMI Lineage solution to build a comprehensive approach to tracking the complete history of your AMIs from creation to decommissioning. By storing this data in an Amazon Neptune graph database, you can build a hierarchical view of the relationships between your EC2 instances and the AMIs they were launched from. You learned how that data can be used to improve security response and remediation and assist in auditing and compliance activities.

The solution uses AWS Organizations to provide preventative controls to help ensure that only approved AMIs are used and integrates AWS security services like Amazon GuardDuty, AWS Security Hub, and AWS Config to add additional layers of security monitoring and management. Finally, you saw how the solution can be used during a security event or when new CVEs are published, so that you can rapidly discover which systems are affected and automate responses based on those findings.

While this solution provides powerful capabilities, it’s important to consider the operational and cost aspects. The core components, particularly Neptune, have associated costs that will scale with the size of your AMI estate. We recommend implementing cost monitoring and alerts as part of your deployment. Furthermore, because the solution is event-driven, you should plan a one-time backfill process to ingest your organization’s existing AMI history into the graph database. For organizations that require this level of granular control and visibility, these operational considerations are offset by the significant gains in security posture and compliance automation.

AMI Lineage transforms AMI governance from a manual, error-prone process into an automated, comprehensive security capability that scales with your organization’s growth. By implementing this solution, your organization can gain the visibility, control, and automated response capabilities needed to maintain a strong security posture while enabling rapid, secure deployment of infrastructure across its AWS environment.


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

Luis Pastor

Luis Pastor

Luis is a Senior Security Solutions Architect at AWS leading the Infrastructure Security and Compliance Technical Field Communities. He drives security architecture for enterprise customers across financial services, healthcare, and retail, specializing in cloud security transformation and regulatory compliance frameworks. Before AWS, Luis architected security solutions in hybrid cloud environments.

George'son Tib.

George’son Tib.

George’son is a Solutions Architect focused on Infrastructure Security at AWS, working with Enterprise customers in the Auto and Manufacturing Industry. He specializes in helping organizations build robust, automated control frameworks that enhance their security posture and drive operational efficiency.

Geoff Sweet

Geoff Sweet

Geoff has been in industry since the late 1990s. He began his career in electrical engineering. Starting in IT during the dot-com boom, he has held a variety of diverse roles, such as systems architect, network architect, and, for the past several years, security architect. Geoff specializes in infrastructure security.

Bharat Lakhiyani

Bharat Lakhiyani

Bharat is a senior solutions architect at AWS. With more than 12 years of experience spanning FinOps, cybersecurity, AI/ML, and enterprise architecture, he specializes in guiding travel and hospitality customers through their digital transformation journeys. Outside of work, Bharat enjoys baking, exploring new restaurants, driving scenic routes, and hiking the trails of North Carolina.

Continuous AI for accessibility: How GitHub transforms feedback into inclusion

Post Syndicated from Carie Fisher original https://github.blog/ai-and-ml/github-copilot/continuous-ai-for-accessibility-how-github-transforms-feedback-into-inclusion/


For years, accessibility feedback at GitHub didn’t have a clear place to go.

Unlike typical product feedback, accessibility issues don’t belong to any single team—they cut across the entire ecosystem. For example, a screen reader user might report a broken workflow that touches navigation, authentication, and settings. A keyboard-only user might hit a trap in a shared component used across dozens of pages. A low vision user might flag a color contrast issue that affects every surface using a shared design element. No single team owns any of these problems—but every one of them blocks a real person.

These reports require coordination that our existing processes weren’t originally built for. Feedback was often scattered across backlogs, bugs lingered without owners, and users followed up to silence. Improvements were often promised for a mythical “phase two” that rarely materialized.

We knew we needed to change this. But before we could build something better, we had to lay the groundwork—centralizing scattered reports, creating templates, and triaging years of backlog. Only once we had that foundation in place could we ask: How can AI make this easier?

The answer was an internal workflow, powered by GitHub Actions, GitHub Copilot, and GitHub Models, that ensures every piece of user and customer feedback becomes a tracked, prioritized issue. When someone reports an accessibility barrier, their feedback is captured, reviewed, and followed through until it’s addressed. We didn’t want AI to replace human judgment—we wanted it to handle repetitive work so humans could focus on fixing the software.

This is how we went from chaos to a system where every piece of accessibility feedback is tracked, prioritized, and acted on—not eventually, but continuously.

Accessibility as a living system

Continuous AI for accessibility weaves inclusion into the fabric of software development. It’s not a single product or a one-time audit—it’s a living methodology that combines automation, artificial intelligence, and human expertise.

This philosophy connects directly to our support for the 2025 Global Accessibility Awareness Day (GAAD) pledge: strengthening accessibility across the open source ecosystem by ensuring user and customer feedback is routed to the right teams and translated into meaningful platform improvements.

The most important breakthroughs rarely come from code scanners—they come from listening to real people. But listening at scale is hard, which is why we needed technology to help amplify those voices. We built a feedback workflow that functions less like a static ticketing system and more like a dynamic engine—leveraging GitHub products to clarify, structure, and track user and customer feedback, turning it into implementation-ready solutions.

Designing for people first

Before jumping into solutions, we stepped back to understand who this system needed to serve:

  • Issue submitters: Community managers, support agents, and sales reps submit issues on behalf of users and customers. They aren’t always accessibility experts, so they need a system that guides them and teaches accessibility concepts in the flow of work.
  • Accessibility and service teams: Engineers and designers responsible for fixes need structured, actionable data—reproducible steps, WCAG mapping, severity scores, and clear ownership.
  • Program and product managers: Leadership needs visibility into pain points by category, trends, and progress over time to allocate resources strategically.

With these personas in mind, we knew we wanted to 1) treat feedback as data flowing through a pipeline and 2) build a system able to evolve with us.

How feedback flows

With that foundation set, we built an architecture around an event-driven pattern, where each step triggers a GitHub Action that orchestrates what comes next—ensuring consistent handling no matter where the feedback originates. We built this system largely by hand starting in mid-2024. Today, tools like Agentic Workflows let you create GitHub Actions using natural language—meaning this kind of system could be built in a fraction of the time.

The workflow reacts to key events: Issue creation launches GitHub Copilot analysis via the GitHub Models API, status changes initiate hand-offs between teams, and resolution triggers submitter follow-up with the user. Every Action can also be triggered manually or re-run as needed—automation covers the common path, while humans can step in at any point.

Feedback isn’t just captured—it continuously flows through the right channels, providing visibility, structure, and actionability at every stage.

*Click images to enlarge.

A left-to-right flowchart showing the seven steps of the feedback workflow in sequence: Intake, Copilot Analysis, Submitter Review, Accessibility Team Review, Link Audits, Close Loop, and Improvement. Feedback loops show that Submitter Review can re-run Copilot Analysis, Close Loop can return to Accessibility Team Review, and Improvement feeds updated prompts back to Copilot Analysis.

1. Actioning intake

Feedback can come from anywhere—support tickets, social media posts, email, direct outreach—but most users choose the GitHub accessibility discussion board. It’s where they can work together and build community around shared experiences. Today, 90% of the accessibility feedback flows through that single channel. Because posts are public, other users can confirm the problem, add context, or suggest workarounds—so issues often arrive with richer detail than a support ticket ever could. Regardless of the source, every piece of feedback gets acknowledged within five business days, and even feedback we can’t act on gets a response pointing to helpful resources.

When feedback requires action from internal teams, a team member manually creates a tracking issue using our custom accessibility feedback issue template. Issue templates are pre-defined forms that standardize how information is collected when opening a new issue. The template captures the initial context—what the user reported, where it came from, and which components are involved—so nothing is lost between intake and triage.

This is where automation kicks in. Creating the issue triggers a GitHub Action that engages GitHub Copilot, and a second Action adds the issue to a project board, providing a centralized view of current status, surfacing trends, and helping identify emerging needs.

A left-to-right flowchart where user or customer feedback enters through Discussion Board, Support Ticket, Social Media, Email, or Direct Outreach, moves to an Acknowledge and Validate step, branches at a validity decision, and either proceeds to Create Issue or loops back through Request More Details to the user.

2. GitHub Copilot analysis

With the tracking issue created, a GitHub Action workflow programmatically calls the GitHub Models API to analyze the report. We chose stored prompts over model fine-tuning so that anyone on the team can update the AI’s behavior through a pull request—no retraining pipeline, no specialized ML knowledge required.

We configured GitHub Copilot using custom instructions developed by our accessibility subject matter experts. Our prompt serves two roles: triage analysis, which classifies issues by WCAG violation, severity, and affected user group, and accessibility coaching, where GitHub Copilot acts as a subject-matter expert to help teams write and review accessible code.

These instruction files point to our accessibility policies, component library, and internal documentation that details how we interpret and apply WCAG success criteria. When our standards evolve, the team updates the markdown and instruction files via pull request—the AI’s behavior changes with the next run, not the next training cycle. For a detailed walkthrough of this approach, see our guide on optimizing GitHub Copilot custom instructions for accessibility.

The automation works in two steps. First, an Action fires on issue creation and triggers GitHub Copilot to analyze the report. GitHub Copilot populates approximately 80% of the issue’s metadata automatically—over 40 data points including issue type, user segment, original source, affected components, and enough context to understand the user’s experience. The remaining 20% requires manual input from the team member. GitHub Copilot then posts a comment on the issue containing:

  • A summary of the problem and user impact
  • Suggested WCAG success criteria for potential violations
  • Severity level (sev1 through sev4, where sev1 is critical)
  • Impacted user groups (screen reader users, keyboard users, low vision users, etc.)
  • Recommended team assignment (design, engineering, or both)
  • A checklist of low-barrier accessibility tests so the submitter can verify the issue

Then a second Action fires on that comment, parses the response, applies labels based on the severity GitHub Copilot assigned, updates the issue’s status on the project board, and assigns it to the submitter for review.

If GitHub Copilot’s analysis seems off, anyone can flag it by opening an issue describing what it got wrong and what it should have said—feeding directly into our continuous improvement process.

A left-to-right flowchart where a newly created issue triggers Action 1, which feeds the report along with custom instructions and WCAG documentation into Copilot Analysis. Copilot posts a comment with its findings, then Action 2 parses that comment and branches into four parallel outcomes: applying labels, applying metadata, adding to the project board, and assigning the submitter.

3. Submitter review

Before we act on GitHub Copilot’s recommendations, two layers of review happen—starting with the issue submitter.

The submitter attempts to replicate the problem the user reported. The checklist GitHub Copilot provides in its comment guides our community managers, support agents, and sales reps through expert-level testing procedures—no accessibility expertise required. Each item includes plain-language explanations, step-by-step instructions, and links to tools and documentation.

Example questions include:

  • Can you navigate the page using only a keyboard? Press “Tab” to move through interactive elements. Can you reach all buttons, links, and form fields? Can you see where your focus is at all times?
  • Do images have descriptive alt text? Right-click an image and select “Inspect” to view the markup. Does the alt attribute describe the image’s purpose, or is it a generic file name?
  • Are interactive elements clearly labeled? Using a screen reader, navigate to a button or link. Is its purpose announced clearly? Alternatively, review the accessibility tree in your browser’s developer tools to inspect how elements are exposed to assistive technologies.

If the submitter can replicate the problem, they mark the issue as reviewed, which triggers the next GitHub Action. If they can’t reproduce it, they reach out to the user for more details. Once new information arrives, the submitter can re-run the GitHub Copilot analysis—either by manually triggering the Action from the Actions tab or by removing and re-adding the relevant label to kick it off automatically. AI provides the draft, but humans provide the verification.

A left-to-right flowchart where the submitter receives the issue with Copilot’s checklist, attempts to replicate the problem, and reaches a decision. If replicable, the issue is marked as reviewed and moves to the accessibility team. If not replicable, the submitter contacts the user for more details. When new information arrives, the submitter re-runs Copilot analysis, which loops back to the replication step.

4. Accessibility team review

Once the submitter marks the issue as reviewed, a GitHub Action updates its status on the workflow project board and adds it to a separate accessibility first responder board. This alerts the accessibility team—engineers, designers, champions, testing vendors, and managers—that GitHub Copilot’s analysis is ready for their review.

The team validates GitHub Copilot’s analysis—checking the severity level, WCAG mapping, and category labels—and corrects anything the AI got wrong. When there’s a discrepancy, we assume the human is correct. We log these corrections and use them to refine the prompt files, improving future accuracy.

Once validated, the team determines the resolution approach:

  • Documentation or settings update: Provide the solution directly to the user.
  • Code fix by the accessibility team: Create a pull request directly.
  • Service team needed: Assign the issue to the appropriate service team and track it through resolution.

With a path forward set, the team marks the issue as triaged. An Action then reassigns it to the submitter, who communicates the plan to the user—letting them know what’s being done and what to expect.

A left-to-right flowchart where a reviewed issue triggers an Action that updates the project board and adds it to the first responder board. The accessibility team validates Copilot’s analysis, logs any corrections, then determines a resolution: provide documentation, create a code fix, or assign to a service team. All three paths converge at marking the issue as triaged, which triggers an Action that reassigns it to the submitter to communicate the plan to the user.

5. Linking to audits

As part of the review process, the team connects user and customer feedback to our formal accessibility audit system.

Roughly 75–80% of the time, reported issues correspond to something we already know about from internal audits. Instead of creating duplicates, we find the existing internal audit issue and add a customer-reported label. This lets us prioritize based on real-world impact—a sev2 issue might technically be less critical than a sev1, but if multiple users are reporting it, we bump up its priority.

If the feedback reveals something new, we create a new audit issue and link it to the tracking issue.

A left-to-right flowchart where the team checks whether an existing audit issue covers the reported problem. If one exists, they link it and add a customer-reported label. If not, they create a new audit issue and link it. Both paths converge at updating priority based on real-world impact.

6. Closing the loop

This is the most critical step for trust. Users who take the time to report accessibility barriers deserve to know their feedback led to action.

Once a resolution path is set, the submitter reaches out to the original user to let them know the plan—what’s being fixed, and what to expect. When the fix ships, the submitter follows up again and asks the user to test it. Because most issues originate from the community discussion board, we post confirmations there for everyone to see.

If the user confirms the fix works, we close the tracking issue. If the fix doesn’t fully address the problem, the submitter gathers more details and the process loops back to the accessibility team review. We don’t close issues until the user confirms the fix works for them.

A left-to-right flowchart where the submitter communicates the resolution plan to the user and monitors until the fix ships. The user is asked to test the fix. If it works, the issue is closed. If it doesn’t, the submitter gathers more details and the process loops back to the accessibility team review.

7. Continuous improvement

The workflow doesn’t end when an issue closes—it feeds back into itself.

When submitters or accessibility team members spot inaccuracies in GitHub Copilot’s output, they open a new issue requesting a review of the results. Every GitHub Copilot analysis comment includes a link to create this issue at the bottom, so the feedback loop is built into the workflow itself. The team reviews the inaccuracy, and the correction becomes a pull request to the custom instruction and prompt files described earlier.

We also automate the integration of new accessibility guidance. A separate GitHub Action scans our internal accessibility guide repository weekly and incorporates changes into GitHub Copilot’s custom instructions automatically.

The goal isn’t perfection—it’s continuous improvement. Each quarter, we review accuracy metrics and refine our instructions. These reviews feed into quarterly and fiscal year reports that track resolution times, WCAG failure patterns, and feedback volume trends—giving leadership visibility into both progress and persistent gaps. The system gets smarter over time, and now we have the data to show it.

A left-to-right flowchart with two parallel loops. In the first, an inaccuracy is spotted, a review issue is opened, the team creates a pull request to update the prompt files, and the changes merge to improve future analyses. In the second, a weekly Action scans the accessibility guide repository and auto-updates Copilot's custom instructions. Both loops feed into quarterly reviews that produce fiscal year reports tracking resolution times, WCAG failure patterns, and feedback volume trends.

Impact in numbers

A year ago, nearly half of accessibility feedback sat unresolved for over 300 days. Today, that backlog isn’t just smaller—it’s gone. And the improvements don’t stop there.

  • 89% of issues now close within 90 days (up from 21%)
  • 62% reduction in average resolution time (118 days → 45 days)
  • 70% reduction in manual administrative time
  • 1,150% increase in issues resolved within 30 days (4 → 50 year-over-year)
  • 50% reduction in critical sev1 issues
  • 100% of issues closed within 60 days in our most recent quarter

We track this through automated weekly and quarterly reports generated by GitHub Actions—surfacing which WCAG criteria fail most often and how resolution times trend over time.

Beyond the numbers

A user named James emailed us to report that the GitHub Copilot CLI was inaccessible. Decorative formatting created noise for screen readers, and interactive elements were impossible to navigate.

A team member created a tracking issue. Within moments, GitHub Copilot analyzed the report—mapping James’s description to specific technical concepts, linking to internal documentation, and providing reproduction steps so the submitter could experience the product exactly as James did.

With that context, the team member realized our engineering team had already shipped accessible CLI updates earlier in the year—James simply wasn’t aware.

They replied immediately. His response? “Thanks for pointing out the –screen-reader mode, which I think will help massively.”

Because the AI workflow identified the problem correctly, we turned a frustration into a resolution in hours.

But the most rewarding result isn’t the speed—it’s the feedback from users. Not just that we responded, but that the fixes actually worked for them:

  • “Huge thanks to the team for updating the contributions graph in the high contrast theme. The addition of borders around the grid edges is a small but meaningful improvement. Keep it up!”
  • “Let’s say you want to create several labels for your GitHub-powered workflow: bug, enhancement, dependency updates… But what if you are blind? Before you had only hex codes randomly thrown at you… now it’s fixed, and those colors have meaningful English names. Well done, GitHub!”
  • “This may not be very professional but I literally just screamed! This fix has actually made my day… Before this I was getting my wife to manage the GitHub issues but now I can actually navigate them by myself! It means a lot that I can now be a bit more independent so thank you again.”

That independence is the point. Every workflow, every automation, every review—it all exists so moments like these are the expectation, not the exception.

The bigger picture

Stories like these remind us why the foundation matters. Design annotations, code scanners, accessibility champions, and testing with people with disabilities—these aren’t replaced by AI. They are what make AI-assisted workflows effective. Without that human foundation, AI is just a faster way to miss the point.

We’re still learning, and the system is still evolving. But every piece of feedback teaches us something, and that knowledge now flows continuously back to our team, our users, and the tools we build. 

If you maintain a repository—whether it’s a massive enterprise project or a weekend open-source library—you can build this kind of system today. Start small. Create an issue template for accessibility. Add a .github/copilot-instructions.md file with your team’s accessibility standards. Let AI handle the triage and formatting so your team can focus on what really matters: writing more inclusive code.

And if you hit an accessibility barrier while using GitHub, please share your feedback. It won’t disappear into a backlog. We’re listening—and now we have the system to follow through.

The post Continuous AI for accessibility: How GitHub transforms feedback into inclusion appeared first on The GitHub Blog.

[$] Practical uses for a null filesystem

Post Syndicated from corbet original https://lwn.net/Articles/1062163/

One of the first changes merged for the upcoming 7.0 release was nullfs,
an empty filesystem that cannot actually contain any files. One might
logically wonder why the kernel would need such a thing. It turns out,
though, that there are places where a null filesystem can come in handy.
For 7.0, nullfs will be used to make life a bit easier for init
programs; future releases will likely use nullfs to increase the isolation
of kernel threads from the init process.

Security updates for Thursday

Post Syndicated from jzb original https://lwn.net/Articles/1062570/

Security updates have been issued by AlmaLinux (gimp, git-lfs, grafana-pcp, kernel, mysql8.4, nfs-utils, opentelemetry-collector, osbuild-composer, postgresql:16, and python3.12), Debian (imagemagick and netty), Fedora (dr_libs and python-lxml-html-clean), Slackware (libarchive and libxml2), SUSE (busybox, coredns, firefox, freerdp, ghostty, gnutls, go1.25, go1.26, GraphicsMagick, grype, helm, helm3, ImageMagick, perl-Compress-Raw-Zlib, python, python311-lxml_html_clean, python311-PyPDF2, tomcat11, and traefik), and Ubuntu (curl, gimp, and libpng).

The Face of Penetration Testing is Changing: Announcing Metasploit Pro 5.0.0

Post Syndicated from The Metasploit Team original https://www.rapid7.com/blog/post/pt-announcing-metasploit-pro-5-penetration-testing-evolving

The role and demand for red-teaming capabilities are growing, as more exploitable CVEs make their way into criminal hands. Being proactive is no longer a capability that can be reserved for annual tests, but a continuous assessment to determine exposure and even through the validation of an organization’s security posture. With this in mind, we are delighted to announce the long awaited availability of Metasploit Pro 5.0.0 – which is not just an update, but a fundamentally new approach to red-teaming, designed with the sole intention of staying ahead of ever-increasingly capable threat actors. 

Amongst the multitude of changes, Metasploit 5.0.0 offers an intuitive testing workflow that removes the ever evolving complexity of testing, as well as a suite of powerful new modules and critical enhancements. This is the version you can’t afford to miss. For all the technical details, the granular release notes can be viewed here.

So what’s new?

Intuitive testing workflow

Say goodbye to complexity, as Metasploit Pro has completely overhauled the testing workflow. Updates are highlighted by an intuitive user interface, ensuring that your focus remains on high-value penetration testing and vulnerability validation, not fighting the interface. These changes are the foundation for the future, preserving the core functionality you rely on while enabling even more powerful features down the road.

image2.png

⠀

Stop guessing and start seeing. The new implementation of Network Topology support provides instant, crystal-clear clarity on hosts that have been compromised, have associated cracked credentials, or captured data. For enterprise environments with vast, complex surfaces, we’ve invested in performance improvements, giving you the power to zoom and pan through hundreds of available hosts with zero lag. This is actionable visualization that transforms data into defense.

image6.png

⠀

Vulnerability detection improvements

Get the necessary assurance before you click ‘run.’ Metasploit modules can now register crucial vulnerability detection details as part of running. This means that modules capable of running pre-check detection logic give you the full intelligence picture before you attempt exploitation. This new level of transparency and detail empowers you to make smarter, faster decisions, saving you precious time and minimizing the chance of failed module runs and adverse side effects.

image4.png

⠀

Advanced workflow improvements

Unleash your inner expert with unprecedented control and efficiency. Advanced users of Metasploit Pro will immediately benefit from multiple UX improvements to the single module run page. Tired of manually configuring options? Users now receive intelligent suggestions for applicable values, including network targets, Kerberos credential cache files, and more –  streamlining ADCS workflows.

image3.png

⠀

Furthermore, you now have the ability to manually choose and configure individual payloads, giving you the final word on how you exploit targets. Metasploit Pro will continue to default to the most common payload for each exploit.

Plus, new quality-of-life improvements for replaying module runs ensure that verifying remediation and re-exploiting targets is a seamless, one-click process. Gone are the days of reconfiguring an entire module run to change a single option. The old list view has also been updated to include the ability to view the module option details that a module was run with. These capabilities can additionally be leveraged by advanced users who are interacting with Metasploit Pro in a programmatic fashion or through the command line interface to see exactly how Metasploit Pro is running modules.

image1.png

⠀

Finally, boost your team’s collaboration with the new session tagging feature. Sessions can now be tagged to facilitate advanced and coordinated post-exploitation workflows. Team members can apply instant, custom tags to track status and flag arbitrary qualities, which significantly improves coordination and organization across multi-person engagements.

AD CS exploitation

Tackle one of the most critical attack vectors in modern networks: Metasploit continues its relentless investment in modern exploitation techniques with the groundbreaking updates to the AD CS Workflows Metamodule. This powerful new feature is a significant advancement, providing security professionals with an automated, comprehensive approach to identifying and leveraging nine common AD CS vulnerabilities. 

Now we’ve taken it even further, with new support for the latest and most dangerous ESC flaws: ESC9, ESC10, and ESC16. Take back control of your Active Directory environment and neutralize these threats with surgical precision. For detailed configuration instructions and comprehensive feature documentation, visit our AD CS Workflows MetaModule documentation.

image5.png

⠀

Session tags

In fast-moving operations, context can disappear quickly as new sessions come online and analysts shift between tasks. Session tagging brings clarity back to your workflow by letting you attach meaningful labels to every open session. Instead of relying on IPs or hostnames alone, you can tag sessions with identifiers that matter to your team – such as priority, environment, or role – making it easy to group related systems and instantly recognize high-value targets.

Metasploit-pro-5-session-tagging.png

⠀

SAML Single Sign On

Metasploit Pro now incorporates SAML Single Sign-On (SSO) authentication, providing your team with a simple, unified login experience. By connecting to your centralized directory, users can access Metasploit Pro with the same credentials they use for all other major applications. Administrators can easily configure their identity provider (IDP) to enable a passwordless workflow and utilize existing Multi-Factor Authentication (MFA) services, making access quick, consistent, and part of your standard corporate flow.

These features are available in Metasploit Pro 5.0.0 onwards. We’re also proud to collaborate with our customers, who are often the source of inspiration for product evolution. Ideas for improvements or enhancements can be shared with our Support team to help you refine the idea, then submit it to our Product team on your behalf.

Related viewing

Rapid7 Labs launched a podcast today! Episode 1 of ‘Hacktics & Telemetry’ is now live on Rapid7’s YouTube page. Alongside some expert commentary on emergent threats and an exciting guest spot, the final segment is all about Metasploit Pro 5.0.0. Dive into our official companion blog here, and find the full episode embedded below.

⠀

Introducing Hacktics and Telemetry, a Podcast from Rapid7 Labs

Post Syndicated from Douglas McKee original https://www.rapid7.com/blog/post/tr-introducing-hacktics-telemetry-podcast-rapid7-labs

If you spend your days building, shipping, defending, or fixing systems, you already know how this goes. A new technique shows up in a research thread, someone drops a “has anyone checked if we’re exposed?” comment, and suddenly you’re juggling risk, patches, logging gaps, and whatever tool is in the blast radius this week.

That day-to-day reality is why Rapid7 Labs is launching Hacktics and Telemetry, a bi-weekly video and audio podcast with episodes built to fit into a lunch break or a commute. It’s hosted by Rapid7’s Douglas McKee, bringing to the pod years of deep technical and leadership experience, then co-hosted by Jonah ‘CryptoCat’ Burgess – a strong researcher with a solid pulse on the cybersecurity community.

The format stays consistent on purpose. Each episode starts with a scan of what’s emerging, shifts into a guest conversation, then closes with a short segment that ties the story back to mitigation and tooling. The goal is simple: move past theory, show what’s happening with real examples, and leave you with something you can act on.

Episode 1: OpenClaw Risks, RCEs, and Metasploit Pro Updates

Doug and Jonah open by digging into two AI-centric stories from the past week. The first is PhoneLeak, described as data exfiltration in Gemini via phone call. It’s the kind of uncomfortable example that forces practical questions: how do you defend against mobile clickjacking when it’s disguised as a routine CAPTCHA? When an AI assistant has deep extensions into a user’s workspace, how do you prevent malicious prompts from quietly accessing sensitive data like 2FA codes? And perhaps most importantly, how do defenders anticipate and monitor for bizarre, out-of-the-box exfiltration methods—like an AI bypassing SMS confirmations to leak data via DTMF tones on a phone call?

The second story comes from the other side of the AI conversation: an AI agent reportedly identifying an RCE in BeyondTrust remote support, plus discussion of older privileged remote access versions. More automation can mean faster discovery, which shrinks the window between “interesting finding” and “you need to patch this.” That changes how defenders think about exposure, patch prioritization, and what “good enough” means (and looks like) when it comes to monitoring.

In the guest segment, Greg Richardson (Global Advisory CISO & AI Thought Leader, 6 Levers AI) walks through how he uses AI agents in his workflow while keeping control tight. He talks about setting tasks while he sleeps, but the constraints are the point: access is locked down, the agent only touches files he explicitly provides, communication is limited, and token limits help cap the size of any mistake. He also makes a strong case for starting small, with one task at a time, instead of trying to automate dozens of things on day one.

To close out this inaugural episode, the team hits on a SolarWinds Help Desk vulnerability, then shares a quick look at Metasploit Pro 5.0 updates – including more granular payload selection and a walkthrough of the new UI.

If your idea of useful content includes threat trade-offs, concrete mitigations, and a bit of candid “how this actually plays out,” you’re in the right place.

Catch the full episode below:

⠀

Избори 2026 – активност в подаването на заявления през първите дни

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

Минаха 6 дни от началото на кампанията за събиране на заявления за гласуване в чужбина за изборите на 19-ти април. Писах за формуляра за подаване на заявления и съвети за попълването му на 6-ти март. Седмица по-рано описах защо сега за разлика от последните няколко години подаването на заявления е от критично значение за отварянето на секции. Това се случва след промени в Изборния кодекс, които връщат правата и възможностите за гласуване на българите в чужбина години назад и създават излишни трудности както в организирането, така и в участието в изборния процес. Тъй като промените станаха буквално в последния момент, имаше несигурност дали ще има кандидати специално за район Чужбина, както и какъв ще е процеса за създаване на секциите. Вероятно затова отново имаше забавяне в публикуването на електронното заявление за гласуване от страна на ЦИК.

Както и предишни години следя активността по подаване на заявления на страницата на Glasuvam.org. Има карта и подробен списък отразяващ точно подадените заявления. Опитал съм се максимално да отразя и решението за автоматично одобрени секции. Имаше проблем с автоматичното следене на заявленията, но се реши. За първите 5 дни графиката на подадените заявления по часове е оценка на база активност предишни години и броя подадени в различни часове сега. На графиката виждате сравнение в светло синьо с активността на последния вот през октомври 2024-та.

Това, което следя също е активността по дни и я сравнявам с изборите през последните 10 години. Тук виждате броят събрани заявления по ден от започването на кампанията – т.е. публикуване на електронния формуляр. През 2024-та имаше доста ниска активност, тъй като доста от секциите бяха отворени автоматично и повечето хора не виждаха смисъл да подават заявления. През 2023-та, 2022-ра и ноември 2021-ва активността беше по-висока, включително на самия вот. Най-много заявления имаше през април и юли 2021-ва като през април имаше рекорден брой събрани в първия ден, както и общо през кампанията. Отговорност за това имаше както най-дългия срок за подаване до сега, така и много добрата координация и работа на доброволци и задгранични огранизации.

Сега виждаме, че събирането върви с добри темпове и се доближава до това през юли 2021-ва. На втората графика виждаме същите данни, но с оставащи дни до крайния срок. Там също се вижда, че въпреки късния старт – едва 19-дни преди срока от 24-ти март – събирането на заявления изпреварва кампаниите от предходните години.

Великобритания, където българите бяха сред най-засегнатите от органиченията в пробмените на Изборния кодекс, показват най-голяма активност. Вижда се, че събирането върви със същите темпове както през юли 2021-ва и изпреварва в пъти събраните заявления две седмици преди крайния срок.

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

Събирането на заявления в Турция винаги е показвала различна крива на активност от другите държави. Този път в началото се виждаше липсва на заявления напомнящо на 2017-та, когато десет дни почти никой не подаваше такива. На 4-тия ден обаче се активизираха и вече се движи аналогично на събирането на заявления на последния вот. Общият им брой обаче е сред най-ниския на този етап от кампанията, както и спрямо оставащото време, както се вижда на следващите две графики. Данните за 2026-та са е синьо.

Това е странно предвид, че по подобие на Великобритания не само броят секции е ограничен, но и изрично трябва да се подават заявления, за да е възможно отварянето им, тъй като автоматичното одобрение беше оставено само в рамките на ЕС.

Ако вземем данните за всички други държави освен Турция виждаме, че активността на събиране е идентична с тази от юли 2021-ва.

Предвид късния старт и при липса на промяна в динамиката очаквам поне 55 хиляди заявления. Сравнил съм броя заявления събирани по държави в последните 10 години и се вижда, че в Турция се подават между 18 и 28 хиляди на година. Тази година очаквам повече в горния край заради ограниченията. Кривата за активността в другите държави ми показва, че вероятно ще се повтори сценария от юли 2021-ва, когато под 40% от заявленията са в Турция. Ще разберем през следващите две седмици.

Електронния формуляр за заявления за гласуване в чужбина ще намерите на страницата на ЦИК.

The collective thoughts of the interwebz