Незаконната постройка на българската законност

Post Syndicated from Светла Енчева original https://www.toest.bg/nezakonnata-postroyka-na-bulgarskata-zakonnost/

Незаконната постройка на българската законност

15 април, вторият ден от Страстната седмица. Докато мейнстрийм медиите се надпреварват коя ще произведе повече материали за мъките Христови, кметът на столичния район „Илинден“ Емил Бранчевски разпорежда да се съборят единствените жилища на около 200 души в кв. „Захарна фабрика“. За потушаване на евентуалната съпротива на обитателите им на място са изпратени жандармеристи. Има дори водно оръдие.

Унищожаването на съществувалото от десетилетия ромско гето се извършва, въпреки че три дни по-рано Европейският съд по правата на човека (ЕСПЧ) в Страсбург изрично забранява разрушаването на махалата в „Захарна фабрика“. Бранчевски защитава отказа си да се съобрази със съдебното решение с аргументи, които може да се обобщят така: ЕСПЧ нещо се е объркал.

За хората, оставени без дом, няма осигурени алтернативни жилища. Единственото предложение е жилищен блок в кв. „Ботунец“ без ток, вода, прозорци и врати. Междувременно кметове на различни столични райони заявяват, че няма да приемат на територията си бедстващите роми.

Липса на официални позиции и наличие на неофициални

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

Няма позиции и на „Спаси София“ (СС), чиято номинация за районен кмет е Бранчевски, както и на останалите партии и коалиции в Столичния общински съвет. Включително на „Продължаваме промяната“ и „Демократична България“, които бяха в коалиция със СС до 22 април 2025 г., когато „Спаси София“ обяви, че сваля доверието си от Терзиев.

Чий е Емил Бранчевски?

От СС и коалицията, от която бяха част, всъщност имат известно основание да не поемат отговорност за действията на Бранчевски. В края на 2024 г. той се обърна срещу партията на Борис Бонев и обвини членовете ѝ в „некадърност“. Това стана в деня, след като Върховният административен съд го възстанови на поста му.

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

Подобни дела имаше и срещу други районни кметове от ПП–ДБ–СС. Кметовете на „Оборище“ Георги Кузмов и на „Слатина“ Георги Илиев решиха да участват в нови избори за постовете си. Кузмов спечели на първи тур, а частичните избори в „Слатина“ предстоят през юни.

Откакто Бранчевски се отрече от СС, той вече не е на прицела на българската правосъдна система.

Единствената позиция на представител на екипа на кмета е на Надежда Бачева от „Да, България“,

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

Незаконната постройка на българската законност
Ул. „Суходолска“ 3, кв. „Захарна фабрика“. Снимка: Вера Гоцева

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

На зам.-кметицата се противопостави съпартиецът ѝ Манол Пейков. Той определи поста ѝ като „неуместен“ и „проява на лош вкус“, подчерта, че е имало решение на ЕСПЧ, и заключи:

Когато се намираш от страната на оня, дето е сгафил […], не се втурваш да обясняваш какво и как, ами навеждаш глава, понасяш ударите и действаш, за да оправиш нещата.

Позицията на общинския съветник Христо Копаранов

Освен член на групата на СС в СОС, Христо Копаранов е адвокат и правозащитник. Той защитава про боно Бранчевски по делото за фирмата във Великобритания. „Тоест“ го помоли за коментар за събарянето на ромските къщи в район „Илинден“.

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

В същото време заиграването с техните страхове посредством потъпкване на международното право е безобразно

подчерта той и определи действията на районната администрация като „поведение тип „слон в стъкларски магазин“.

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

Същевременно Копаранов смята, че изискванията на международното право са от първостепенно значение, още повече че България вече е била осъждана по подобни казуси от ЕСПЧ, например по делото „Йорданова и други срещу България“. В присъдите се казва, че когато премахва незаконни строежи, които са нечии единствени жилища, държавата трябва да постъпи съразмерно, т.е. да осигури алтернативно настаняване. А щом в конкретния случая със „Захарна фабрика“ ЕСПЧ е наложил привременни мерки,

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

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

Границата, която събарянето на къщите в „Захарна фабрика“ прекрачва

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

Не е прецедент и да не се изпълняват решения на ЕСПЧ. Ето няколко примера.

По общо три дела ЕСПЧ е постановил, че България не може да отнема правото на глас на затворници и на хора, поставени под запрещение, без да се отчитат тежестта на извършеното престъпление и размерът на присъдата на лишените от свобода или съответно индивидуалните възможности на запретените лица. До ден днешен обаче хората под запрещение нямат право да гласуват, както и лишените от свобода с влязла в сила присъда, независимо каква е тя.

През септември 2023 г. ЕС отсъди, че България трябва да създаде правна рамка, дори тя да не е брак, която признава и гарантира защита на съюзите на лица от един и същи пол. Не само че това не е направено, а дори интимните връзки на еднополовите двойки не се признават за съществуващи от закона.

Случаят със „Захарна фабрика“ обаче е различен, защото става въпрос за дело по конкретен казус, заведено от БХК от името на 14 жители на махалата с цел предотвратяване на определено действие. В други аналогични ситуации българските институции са се съобразявали с разпореждането на ЕСПЧ да не се събарят къщи, преди да се осигури алтернатива. Но не и в тази.

Незаконната постройка на българската законност
Ул. „Суходолска“ 3, кв. „Захарна фабрика“. Снимка: Вера Гоцева

Пирамидалната структура на правосъдието

Аргументът на Емил Бранчевски за незаконността на постройките и взетото още през 2016 г. решение за премахването им показва, че той или не разбира какво е правосъдие, или не иска да се съобразява с него.

Решенията, които една или друга институция взема, се основават на нормативни актове. Има подзаконови актове, например правилници и наредби. Над тях са законите и кодексите. Те пък се подчиняват на Конституцията. Основният закон, от своя страна, не трябва да противоречи на международното законодателство, което България е ратифицирала. Част от това международно законодателство е Европейската конвенция за правата на човека (ЕКПЧ).

Както Конституционният съд решава какво противоречи на Конституцията и какво – не, така Съдът в Страсбург съблюдава спазването на ЕКПЧ. И решенията му са задължителни за страните, ратифицирали Конвенцията.

Правосъдие в стил „за кокошка няма прошка, за милиони няма закони“

Позволявайки си да не се съобрази с решение на ЕСПЧ, Бранчевски демонстрира, че за него незаконността на едни къщи е по-сериозно закононарушение от несъобразяването с международното законодателство.

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

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

А какво да правим с незаконно паркиралите ламарини на колела?

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

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

Хайде да си направим един мисловен експеримент.

Да си представим, че някой от районните кметове в София е твърдо решен да се справи с незаконното паркиране по тротоари и градинки. И въведе радикална мярка – всеки автомобил, паркиран в нарушение, се предава за скрап. Но вместо да казва „коли“ или „автомобили“, кметът употребява израза „незаконно паркирали ламарини на колела“.

Притежателите на превозните средства се противопоставят на мярката с аргументите, че тя е непропорционална, че е посегателство върху правото им на собственост, че за колите си са плащали данъци и осигуровки, че няма достатъчно места, където да паркират. Кметът обаче настоява, че незаконно паркиралите ламарини на колела трябва да ги няма. И точка.

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

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

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

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

How to import existing AWS Organizations SCPs and RCPs to CloudFormation

Post Syndicated from Swara Gandhi original https://aws.amazon.com/blogs/security/how-to-import-existing-aws-organizations-scps-and-rcps-to-cloudformation/

Many AWS Organizations customers begin by creating and manually applying service control policies (SCPs) and resource control policies (RCPs) through the AWS Management Console or AWS Command Line Interface (AWS CLI) when they first set up their environments. However, as the organization grows and the number of policies increases, this manual approach can become cumbersome. It can result in limited visibility into all implemented SCPs and RCPs, the targets they’re attached to (such as accounts, organizational units (OUs), or nested OUs), and the ability to manage updates effectively. Without clear visibility and proper access controls, it becomes challenging to track who’s making changes and how they are being made.

Importing existing SCPs and RCPs into AWS CloudFormation can help streamline the management of your policies by enabling history tracking, policy validation through CloudFormation Hooks, and rollback capabilities. You can also sync stacks with source code stored in a Git repository with Git sync. With Git sync, you can use pull requests and version tracking to configure, deploy, and update your CloudFormation stacks from a centralized location. When you commit changes to the template or the deployment file, CloudFormation automatically updates the stack.

In this post, I provide a solution to import existing SCPs and RCPs into AWS CloudFormation templates using the CloudFormation infrastructure as code generator (IaC generator). By using the IaC generator, you can automate the management of your SCPs and RCPs at scale.

Important: Only existing policies are brought into CloudFormation; policies are not recreated.

Solution overview

The solution in this post includes a command line tool for discovering SCPs and RCPs in your organization and automating policy import into CloudFormation templates. The following figure shows the end-to-end flow:

Figure 1: Solution overview

Figure 1: Solution overview

The end-to-end flow shown in the preceding figure includes:

  1. Run the tool: The tool automates the following steps and can be run in the management account or delegated administrator account.
    1. Identify SCPs and RCPs in the organization: The tool begins by making API calls to the Organizations service to retrieve the policies in your environment. It then provides a count of the total number of SCPs and RCPs present.
    2. Identify AWS Control Tower SCPs and RCPs and policies without targets:
      1. AWS Control Tower SCPs and RCPs: The tool checks for SCPs and RCPs created by AWS Control Tower and lists them in the output for your review.
        • SCPs are identified by the aws-guardrails- prefix in their policy names.
        • RCPs are identified by the AWSControlTower-Controls- prefix in their policy names.
      2. Policies with no targets: The tool also identifies SCPs and RCPs that aren’t attached to an organizational unit (OU), account, or root and lists them. These policies might be redundant or need reassignment.
    3. CloudFormation IaC generator scan: At this stage, you will be prompted to confirm whether you want to import the policies to the CloudFormation templates using CloudFormation resource scan. If you select yes, the tool will initiate a CloudFormation resource scan using IaC generator to get details about the policies including policy name, targets, policy tags, and so on.
    4. Create template from scanned policy resources: The tool generates CloudFormation template with the policy resources. The template will include the policies without targets (if any).
  2. Review process: After the template is generated, it’s recommended that you preview the template using IaC generator from the CloudFormation console. We recommend viewing the template resource section to verify and adjust the generated templates as needed (step 11 of the solution deployment).
  3. Create CloudFormation stacks with the generated templates: After reviewing the templates, import them into CloudFormation stacks for deployment. It’s important to note that only existing policies are brought into CloudFormation—policies aren’t recreated. The templates reflect the current policies and policy attributes.

Consideration before implementing the solution

There are some considerations that you need to keep in mind before implementing the solution.

  • If you have enabled the AWS Organizations policy management delegation, you should run this solution from the delegated administrator account. Otherwise, you can run the solution using the management account.

    Note: Delegating management of organizations policies to a delegated administrator member account is recommended best practice.

  • AWS Control Tower SCPs and RCPs (with or without targets) won’t be imported to the CloudFormation templates because they should be managed using AWS Control Tower. Changes made to AWS Control Tower resources outside of AWS Control Tower can cause drift and affect AWS Control Tower functionality in unpredictable ways.
  • FullAWSAccess SCP and RCPFullAWSAccess RCP are AWS managed policies that won’t be imported to CloudFormation because CloudFormation stacks do not allow importing AWS managed resources.
  • You might see multiple CloudFormation templates created if you exceed the CloudFormation template size quotas. To help ensure smooth creation, the tool is designed to automatically split the content into multiple templates if necessary, allowing you to stay within the quotas while still accommodating the imported content.
  • Note that the generated templates have the following attributes set by default.
    • Deletion policy: Set to Retain. This enables persisting the policies even when their related stack is deleted.
    • Update Replace policy: Set to Delete. This enables deletion of the physical ID associated with the policy when the policy is updated.

Solution deployment

Now that you understand the solution and know the considerations to keep in mind, you’re ready to deploy the solution.

  1. Clone the solution repository.
    git clone https://github.com/aws-samples/sample-tool-for-importing-existing-AWS-SCPs-and-RCPs
    

  2. Navigate to the directory of the cloned repository.
    cd sample-tool-for-importing-existing-AWS-SCPs-and-RCPs/
    

  3. Install the solution (Python 3.10+ is supported)
    pip install .
    

  4. If you want to use a particular AWS Identity and Access Management (IAM) principal to run this tool, create a profile in ~./aws/config using an IAM principal from your AWS Organizations management account. If you have delegated policy management to a member account, make sure that you use the IAM principal from the delegated administrator account. 

    Note: The IAM principal will need to have the following permissions to be able to successfully run the tool.

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "VisualEditor0",
                "Effect": "Allow",
                "Action": [
                    "organizations:Describe*",
                    "organizations:List*",
                    "cloudformation:Describe*",
                    "cloudformation:Detect*",
                    "cloudformation:Estimate*",
                    "cloudformation:Get*",
                    "cloudformation:List*",
                    "cloudformation:CreateGeneratedTemplate",
                    "cloudformation:StartResourceScan",
                    "cloudformation:UpdateGeneratedTemplate",
                    "cloudformation:CreateStack",
                    "cloudformation:DeleteStack",
                    "cloudformation:UpdateStack",
                    "cloudformation:DeleteGeneratedTemplate"
                ],
                "Resource": "*"
            }
        ]
    }
    

  5. You can run the tool specifying a profile name as a command line argument. Use the following command, replacing <profile_name> with the name of the profile you created in step 4. If you do not specify a profile, the default profile from the file ~./aws/config will be used.
    policy-importer --profile <profile_name>
    

  6. After the preceding command is executed, you will see an output displaying the total number of SCPs and RCPs found in the organization. The output will also list AWS Control Tower managed policies as INFO, in addition to policies without targets as a WARNING. At this point, you can enter Yes to proceed with scanning to import the policies, or enter No if you want to exit.

    Note: If policies without targets are detected, we recommend stopping at this point. Either delete the policies without targets or assign appropriate targets to them. You can then rerun the tool from step 5. If you proceed without addressing the policies without targets, be aware that these policies will also be included in the CloudFormation template.

    Figure 2: Terminal view with policies identified in the organization

    Figure 2: Terminal view with policies identified in the organization

  7. If you enter Yes, the CloudFormation IaC resource scan will begin immediately. You will see the resource scan ID Amazon Resource Name (ARN) displayed.

    Note: A scan can take up to 10 minutes for every 1,000 resources.

    Figure 3: Terminal view with AWS CloudFormation resource scan details

    Figure 3: Terminal view with AWS CloudFormation resource scan details

  8. You can also review the scan progress from the IaC generator page of the CloudFormation console as shown in the following figure. To get to the IaC generator page, go to the CloudFormation console and choose IaC generator from the navigation pane.
    Figure 4: View the scan summary in the CloudFormation console to track progress

    Figure 4: View the scan summary in the CloudFormation console to track progress

  9. Upon completion of the scan, the template generation process will be initiated.
    Figure 5: Terminal view showing CloudFormation template being created

    Figure 5: Terminal view showing CloudFormation template being created

  10. After the template creation is finished, sign in to the AWS CloudFormation IaC console. Choose the Templates tab to review the generated templates and verify that they align with your requirements.
    Figure 6: View CloudFormation templates in the console

    Figure 6: View CloudFormation templates in the console

  11. You can review the policies added to a template by selecting a template name.
    Figure 7: Review policies included in the template

    Figure 7: Review policies included in the template

  12. When satisfied, you can proceed to import the templates into CloudFormation stacks for deployment by selecting Import to stack.
    Figure 8: Import a template into the CloudFormation stack

    Figure 8: Import a template into the CloudFormation stack

  13. Follow the prompts to create a stack.
    Figure 9: AWS CloudFormation stack example

    Figure 9: AWS CloudFormation stack example

  14. The tool automatically creates a folder named Policies in your current directory and downloads the generated templates.

    Note: If you encounter errors, check the recommended solutions for common issues.

As shown in the following figure, there are two recommended next steps.

Figure 10: Solution overview including recommended next steps

Figure 10: Solution overview including recommended next steps

After the existing policies are imported into a CloudFormation stack, we recommend storing your CloudFormation templates in a private Git repository. You can use the Policies folder that was automatically created by the tool in the current local directory with the generated templates downloaded and set up a continuous integration and delivery (CI/CD) pipeline to efficiently manage the imported policies.

By using a Git repository, you can use version control features like pull requests, branch management, and history tracking. This approach allows your team to efficiently review, update, and deploy policies with better collaboration and control. You can also create a CI/CD pipeline to automate the deployment of changes to your CloudFormation stacks, helping to ensure that updates are consistent and reliable.

We also recommend incorporating CloudFormation Hooks in your environment. CloudFormation Hooks can help validate policies (and other resources) against best practices, to help ensure that they adhere to the correct syntax, follow security best practices, and minimize potential vulnerabilities.

Related resources:

Conclusion

Importing existing AWS Organizations service control policies (SCPs) and resource control policies (RCPs) into CloudFormation provides an efficient and scalable approach to managing and automating your AWS governance. After they’ve been imported, you can manage and update policies directly in CloudFormation, to help ensure consistency and version control across your organization. The tool also creates a Policies folder in your current directory, storing downloaded templates for use as a central repository and integration with a CI/CD pipeline.

By using CloudFormation Hooks, you can further improve your policy management by validating SCPs and RCPs against best practices and policy grammar. This approach centralizes your policy updates, making governance more automated and efficient while reducing the risk of misconfiguration.

Swara Gandhi

Swara Gandhi

Swara is a Senior Solutions Architect on the AWS Identity Solutions team. She works on building secure and scalable end-to-end identity solutions. She is passionate about everything identity, security, and cloud.

Amazon introduces SWE-PolyBench, a multilingual benchmark for AI Coding Agents

Post Syndicated from Christian Bock original https://aws.amazon.com/blogs/devops/amazon-introduces-swe-polybench-a-multi-lingual-benchmark-for-ai-coding-agents/

Coding agents powered by large language models have shown impressive capabilities in software engineering tasks, but evaluating their performance across diverse programming languages and real-world scenarios remains challenging. This led to a recent explosion in benchmark creation to assess the coding effectiveness of said systems in controlled environments. In particular, SWE-Bench which measures the performance of systems in the context of GitHub issues has spurred the development of capable coding agents resulting in over 50 leaderboard submissions, thereby becoming the de-facto standard for coding agent benchmarking. Despite its significant impact as a pioneering benchmark, SWE-Bench, and in particular its “verified” subset, also shows some limitations. It contains only Python repositories, the majority of tasks are bug fixes, and at over 45% of all tasks, the Django repository is significantly over-represented.

Today, Amazon introduces SWE-PolyBench, the first industry benchmark to evaluate AI coding agents’ ability to navigate and understand complex codebases, introducing rich metrics to advance AI performance in real-world scenarios. SWE-PolyBench contains over 2,000 curated issues in four languages. In addition, it contains a stratified subset of 500 issues (SWE-PolyBench500) for the purpose of rapid experimentation. SWE-PolyBench evaluates the performance of AI coding agents through a comprehensive set of metrics: pass rates across different programming languages and task complexity levels, along with precision and recall measurements for code/file context identification. These evaluation metrics can help the community address challenges in understanding how well AI coding agents can navigate through and comprehend complex codebases

The leaderboard is accessible here. The SWE-PolyBench dataset is available on Hugging Face and the paper at arxiv. Evaluations can be run using the SWE-PolyBench codebase.

Below, we describe the key features, characteristics, and the creation process of our dataset alongside the new evaluation metrics, and performance of open source agents from our experiments.

Key features of SWE-PolyBench at a glance

  1. Multi-Language Support: Java (165 tasks), JavaScript (1017 tasks), TypeScript (729 tasks), and Python (199 tasks).
  2. Extensive Dataset: 2110 instances from 21 repositories ranging from web frameworks to code editors and ML tools, on the same scale as SWE-Bench full with more repository.
  3. Task Variety: Includes bug fixes, feature requests, and code refactoring.
  4. Faster Experimentation: SWE-PolyBench500 is a stratified subset for efficient experimentation.
  5. Leaderboard: A leaderboard with a rich set of metrics for transparent benchmarking.

Building a comprehensive dataset

The creation of SWE-PolyBench involved a data collection and filtering process designed to ensure the quality and relevance of the benchmark tasks. SWE-Bench, a benchmark for Python code generation, evaluates agents on real-world programming tasks by utilizing GitHub issues and their corresponding code and test modifications. We extended the SWE-Bench data acquisition pipeline to support 3 additional languages besides Python and used it to gather and process coding challenges from real-world repositories as shown in Figure 1.

A flowchart diagram showing a software development process. It starts with an issue (#3039) and pull request (#3147) on the left, goes through a metadata filter in the middle, then splits into a runtime setup and testing phase on the right. The testing phase feeds into a test-based filter at the end. The diagram includes icons for programming languages like JavaScript, TypeScript, Python, and Java.

Figure 1: Overview of the SWE-PolyBench data generation pipeline, illustrating the process of collecting, filtering, and validating coding tasks.

The data acquisition pipeline collects pull requests (PRs) that close issues from popular repositories across Java, JavaScript, TypeScript, and Python. These PRs undergo filtering and are set up in containerized environments for consistent test execution. The process categorizes tests as fail-to-pass (F2P) or pass-to-pass (P2P) based on their outcomes before and after patch application. Only PRs with at least one F2P test are included in the final dataset, ensuring that each task represents a meaningful coding challenge. This streamlined approach results in a dataset that closely mimics real-world coding scenarios, providing a robust foundation for evaluating AI coding assistants.

Dataset characteristics

When constructing SWE-PolyBench, we aimed to collect GitHub issues that represent diverse programming scenarios: issues involving modifications across multiple code files and spanning different task categories (such as bug fixes, feature requests, and refactoring). Tables 1 and 2 provide descriptive statistics on the composition and complexity of SWE-PolyBench full (PB) and SWE-PolyBench500 (PB500). To offer a point of reference, we compare these statistics with those of SWE-Bench (SWE) and SWE-Bench verified (SWEv). Tasks in SWE-PolyBench require on average more files to be modified and more nodes to be changed, which indicates that they have higher complexity and are closer to tasks in real-world projects. The distribution of tasks is also more diverse, in particular for SWE-PolyBench500.

A comparison table showing statistics for different software benchmarks (SWE-PolyBench, SWE-PolyBench500, SWE-Bench, and SWE-Bench verified). The table has two main sections: Modified Files showing average changes across programming languages (Python, Java, JavaScript, TypeScript), and Task Category distribution showing percentages for Bug Fix, Feature Request, Refactoring, and Miscellaneous tasks

A detailed table comparing dataset complexity across different programming languages and benchmarks (SWE, SWEv, PB, and PB500). The table shows statistics for syntax tree node changes, divided into two main sections: Node Change Category percentages (None, Function only, Class only, Mixed) and Node Change Count averages (Function, Class, Number of Nodes). The highest values in each column are shown in bold, with notable variations across Python, Java, JavaScript, and TypeScript implementations.

New evaluation metrics

To comprehensively evaluate AI coding assistants, SWE-Polybench introduces multiple new metrics in addition to the pass rate. The pass rate is the proportion of tasks successfully solved as measured by the generated patch passing all relevant tests. It is the primary metric for assessing coding agent performance, but it doesn’t provide a complete picture of an agent’s capabilities. In particular, it doesn’t give much information on an agent’s ability to navigate and understand complex code repositories. SWE-PolyBench introduces a new set of metrics based on Concrete Syntax Tree (CST) node analysis and the established file-level localization metric:

  1. File-level Localization: assesses the agent’s ability to identify the correct files that need to be modified within a repository. Let us assume that we would need to modify file.py to solve our problem. If our coding agent implements a change in any other file, it would receive a file retrieval score of 0.
  2. CST Node-level Retrieval: evaluates the agent’s ability to identify specific code structures that require changes. It uses the Concrete Syntax Tree (CST) representation of the code to measure how accurately the agent can locate the exact functions or classes that need modification.
A side-by-side comparison showing two Git version control diffs. Each diff shows a line being removed (in red, prefixed with '-') where my_var equals 3, and a line being added (in green, prefixed with '+') where my_var equals 2. Above the diffs are connected dots in different colors (green, pink, blue, and yellow) representing Git commit history visualization.

Figure 2: Illustration of CST node changes.

In Figure 2, we see a change in class node A materialized by a change in its initialization function on the left path starting from the file node. In contrast to the first change, the change in class B is considered a function node change as it doesn’t impact class construction.

Let us assume the change that would solve our problem is the change in the __init__ function. If our coding agent implements the change in my_func, it receives both a class and function node retrieval score of 0.

By combining pass rate assessment with both file-level and CST node-level retrieval metrics, SWE-PolyBench offers a detailed evaluation of AI coding assistants’ capabilities in real-world scenarios. This approach provides deeper insights into how well agents navigate and comprehend complex codebases, going beyond simple task completion to assess their understanding of code structure and organization.

Performance of open-source coding agents

Key Findings

  1. Language Proficiency: Python is the strongest language for all agents, likely due to its prevalence in training data and existing benchmarks.
  2. Complexity Challenges: Performance degrades as task complexity increases, particularly when modifications to 3 or more files are required.
  3. Task Specialization: Different agents show strengths in various task categories (bug fixes, feature requests, refactoring).
  4. Context Importance: The informativeness of problem statements impacts success rates across all agents (refer to Figure 5 of the appendix paper for details about this analysis).

Many existing open-source agents are designed primarily for Python. Adapting them to work for all four languages of SWE-PolyBench required adjusting test execution commands, modifying parsing mechanisms, and adapting containerization strategies for each language. We adapted and evaluated three open-source agents on SWE-PolyBench. The aforementioned adjustments are reflected by the added “-PB” suffix to the original agent names.

Two radar charts comparing three AI models: Aider-PB Sonnet 3.5, Agentless-PB Sonnet 3.5, and SWE-agent-PB Sonnet 3.5. The left chart shows performance across programming languages (Java, JavaScript, TypeScript, Python). The right chart displays performance in different coding styles (Functional only, Single Function, All, Mixed, No nodes, Single Class, Class only). Each model is represented by a different colored line, with Aider-PB generally showing the highest performance across categories.

Figure 3: Performance of coding agents across programming languages and task complexities, highlighting strengths and areas for improvement.

Figure 3 provides a visual representation of agent performance across different dimensions:

  • Language Proficiency: The left side of the chart shows that all three agents perform best in Python, with significantly lower pass rates in other languages. This highlights the current bias towards Python in many coding agents and their underlying large language models.
  • Task Complexity: The right side of the chart illustrates how performance degrades as task complexity increases. Agents show higher pass rates for tasks involving single class or function changes, but struggle with tasks requiring modifications to multiple classes or functions and in instances where both class and function changes are required.

This comprehensive view of agent performance underscores the value of SWE-PolyBench in identifying specific strengths and weaknesses of different coding assistants, paving the way for targeted improvements in future iterations.

In addition to these insights, the evaluation revealed interesting patterns across different task categories as shown in Table 2. The performance data across bug fixes, feature requests, and refactoring tasks reveals varying strengths among AI coding assistants. The performance on bug fixing tasks is relatively consistent. There is more variability between different agents and between multiple runs of a given agent for feature request tasks and refactoring tasks.

Table 3 showing average pass rates with standard error by task category for three agents: Agentless-PB, SWE-Agent-PB, and Aider-PB. The task categories are Bug Fix, Feature Request, and Refactoring. Aider-PB has the highest pass rates for Bug Fix (13.8) and Feature Request (15.1), while SWE-Agent-PB leads in Refactoring (16.1). Standard errors are provided for each value.

Join the SWE-PolyBench community

SWE-PolyBench and its evaluation framework are publicly available. This open approach invites the global developer community to build upon this work and advance the field of AI-assisted software engineering. As coding agents continue to evolve, benchmarks like SWE-PolyBench play a crucial role in ensuring they can meet the diverse needs of real-world software development across multiple programming languages and task types.

Explore SWE-PolyBench today and contribute to the future of AI-powered software engineering!

Resources

Authors

Christian Bock

Christian Bock is an Applied Scientist at Amazon Web Services working on AI for code.

Laurent Callot

Laurent Callot is a Principal Applied Scientist at Amazon Web Services leading teams creating AI agents for software development.

Luca Franceschi

Luca Franceschi is an Applied Scientist at Amazon Web Services working on ML models to improve the efficiency of AI agents for code generation.

Woo Jung Kim

Woo Jung Kim is an applied scientist at Amazon Web Services. He is developing an AI agentic tool designed to improve developer’s productivity.

Shihab Rashid

Shihab Rashid is an Applied Scientist at Amazon Web Services working on agentic AI for code generation with a focus on multi agent systems.

Prabhu Teja

Prabhu Teja is an Applied Scientist at Amazon Web Services. Prabhu works on LLM assisted code generation with a focus on natural language interaction.

Simon Valentin

Simon Valentin is an Applied Scientist at Amazon Web Services working on AI for code.

Martin Wistuba

Martin Wistuba is a senior applied scientist at Amazon Web Services. As part of Amazon Q Developer, he is helping developers to write more code in less time.

Giovanni Zappella

Giovanni Zappella is a Principal Applied Scientist working on the creations of intelligent agents for code generation. While at Amazon he also contributed to the creation of new algorithms for Continual Learning, AutoML and recommendations systems.

Yuan Zhuang

Yuan Zhuang is an Applied Scientist at Amazon Web Services working on AI agents for code generation.

[$] Addressing UID/GID drift in rpm-ostree and bootc

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

The Fedora Project is looking for solutions to an interesting
problem with its image-based editions and spins, such as the Atomic Desktops
or CoreOS, that are
created with rpm-ostree or bootc. If a package that
is part of a image-based version has a user or group created
dynamically on installation, and it owns files installed on the
system, the system may be subject to user ID (UID) and group ID (GID) “drift”
on updates. This “UID/GID drift” may come about when a new image with
updates is generated, and therefore files may have the wrong
ownership. This can have side-effects ranging from mildly inconvenient to
serious. No solutions have been adopted just yet, but there are a few
ideas on how to deal with the problem.

Analyzing Performance at Exabyte Scale

Post Syndicated from Tim Johnson original https://www.backblaze.com/blog/analyzing-performance-at-exabyte-scale/

A decorative image showing a cloud in the foreground and various mocked up graphs in the background.

When you’re operating a data storage platform at exabyte scale, even small inefficiencies become big problems. With billions of files flowing through our systems, performance isn’t something we think about after the fact—it’s something we constantly chase, measure, and optimize.

But before you can improve cloud performance, you have to know where to look. When we were working on improving small file uploads, I was tasked with taking a closer look at our file upload pipeline to see if we could make it faster. 

The path from that general idea to hitting a clear performance goal taught me a lot—not just about our systems, but about how to approach performance work in a principled, strategic way. Here’s how it unfolded, and what you can apply to your own environment.

Step one: Define the problem

The initial ask from our Product team was pretty familiar: “Can we make uploads faster?” It’s a fair question, but not a very actionable one. So we worked with our Product team to define our success criteria. Here are some of the questions we asked to get to specific, actionable goals:

“What do we mean by faster? Do we want to improve latency or throughput?”

“Do we want to improve all uploads? Just big files? Just small files?
“What qualifies as a small upload?”

After some back and forth, we landed on a clear, measurable target: Process file uploads of 1MB or less via our B2 API in under 40 milliseconds. That specificity made a huge difference:

  • With a goal of 40 milliseconds, we had a stopping point. We would know when we’d done enough.
  • We had a bar to measure against and a way to identify what was worth optimizing. If something took two milliseconds, we could leave it alone. If it took 30, it became the focus.
  • We could scope effort. There’s a big difference between getting something under 40 milliseconds versus 200. 

Step two: Use the right tools for the job if you possibly can

Analyzing performance without proper tooling means doing a lot of heavy lifting by hand. We had to drop custom instrumentation throughout the stack, create metric-collecting objects, and pass them all the way down the call stack so we could get timing data from different parts of the upload path.

The upload flow touches more than 20 storage pods and services, so we also built a lightweight sampling system to keep from flooding our metrics pipeline. The data went into an open-source search and analytics suite, and from there we built dashboards to try to make sense of it all.

It was time-consuming. Painfully so. But it worked. 

I could now compare fast and slow uploads, identify patterns, and—most importantly—see where time was actually being spent. That’s how we discovered that fsync was dominating our performance profile, captured in the screenshot below. We measured each sub-operation that comprises our drive write operations, and grouped them by the total time they took to complete. You can see the process fsync sub-operation dominates in every group. Removing or optimizing around it offered a 10x speedup. But it took weeks of manual effort to get to that insight.

Drive write operations grouped by the time they took to complete.

Enter: Tracing at scale

Eventually, we brought in more powerful tooling, including an open source distributed tracing system. It was a game changer.

What used to take dozens of lines of code and a lot of custom wiring now took a single annotation. More importantly, it gave us something we couldn’t get otherwise: a way to see activity across services, systems, and pods—all in one view.

It allowed us to correlate events happening across different physical machines, trace performance end-to-end, and understand the impact of specific changes in real time.

At one point, we were debating whether a particular optimization would get us across the finish line. This optimization allows the slowest shard to store asynchronously if and only if all others had been successfully and durably stored. This prevents a single slow shard from slowing down the entire upload. Thanks to the new tooling, we didn’t have to guess—we could see that once we flipped the switch, we’d hit our 40ms goal (and it would help all other uploads as well, not just small uploads). That let us focus on getting that one feature ready for production, confident that it would move the needle.

Visualization demonstrating one of our upload optimizations, this time for a slower upload. The first 19 shards to complete were stored successfully and durably, so we stop waiting for the last shard, return a 200 status code to the customer (indicated by the dotted line), and allow the 20th shard to finish asynchronously.

Step three: Optimize with intent

One of the biggest lessons I learned through this process is that you can spend weeks optimizing the wrong thing if you’re not careful. That’s why measurement has to come first.

Don’t guess. Instrument. Don’t tweak randomly. Set a baseline and track deltas. Performance work is iterative. You’ll fix one bottleneck, only to reveal the next one lurking beneath it. That’s the job.

In hindsight, one of the smartest things we did was setting a clear performance goal at the start of the project. It didn’t just help us focus—it told us when we were done. You can optimize forever. Knowing when to stop is just as important as knowing where to begin.

Step four: Tool up for the future

The tracing tool has made life a lot easier, but it’s not the only tool we use. Our analytics suite still plays a big role when we want to analyze aggregate data, or need the flexibility to slice and dice data. The two complement each other nicely.

There’s no one-size-fits-all solution—it’s more like a toolbox. And like any good toolbox, it keeps growing with our needs.

Advice from the trenches

If you’re running distributed systems or chasing performance in your own stack, here’s what I’d suggest:

  • Start with a clear goal. Know exactly what “faster” means, and write it down.
  • Measure before you optimize. Otherwise, you’re flying blind.
  • Pick the right tool for the job. Tracing, metrics, logs—they all have their place.
  • Don’t wait to build your tools. Invest in observability early.
  • Know when to stop. The ROI of performance work diminishes fast if you’re not careful.

And maybe give your helper methods better names than DoSomeWork. Or don’t. It makes the code reviews a little more entertaining.

The post Analyzing Performance at Exabyte Scale appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

NLnet announces funding for 42 FOSS projects

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

The NLnet Foundation has announced
the projects that have received funding from its October call
for grant proposals from the Next
Generation Internet (NGI) Zero Commons Fund
.

The selected projects all contribute, one way or another, to the
mission of the Commons Fund: reclaiming the public nature of the
internet. For example, there are people working on interesting open
hardware projects such as the tablet MNT Reform Touch
and the Solar
FemtoTX motherboard
— a collaborative effort to create an
ultra-low power motherboard that can run on solar power. LLM2FPGA aims to enable
running open source LLMs locally on programmable chips (“FPGAs”) using
a fully open-source toolchain. bcachefs
readies itself as the next generation filesystem for Linux, improving
performance, scalability and reliability when compared to legacy
filesystems.

In all, 42 projects have been selected for the NGI grants which are
between €5,000 and €50,000. See the announcement for the
full list of selected projects, and the current projects page
for other recent projects funded by NLnet.

Regulating AI Behavior with a Hypervisor

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/04/regulating-ai-behavior-with-a-hypervisor.html

Interesting research: “Guillotine: Hypervisors for Isolating Malicious AIs.”

Abstract:As AI models become more embedded in critical sectors like finance, healthcare, and the military, their inscrutable behavior poses ever-greater risks to society. To mitigate this risk, we propose Guillotine, a hypervisor architecture for sandboxing powerful AI models—models that, by accident or malice, can generate existential threats to humanity. Although Guillotine borrows some well-known virtualization techniques, Guillotine must also introduce fundamentally new isolation mechanisms to handle the unique threat model posed by existential-risk AIs. For example, a rogue AI may try to introspect upon hypervisor software or the underlying hardware substrate to enable later subversion of that control plane; thus, a Guillotine hypervisor requires careful co-design of the hypervisor software and the CPUs, RAM, NIC, and storage devices that support the hypervisor software, to thwart side channel leakage and more generally eliminate mechanisms for AI to exploit reflection-based vulnerabilities. Beyond such isolation at the software, network, and microarchitectural layers, a Guillotine hypervisor must also provide physical fail-safes more commonly associated with nuclear power plants, avionic platforms, and other types of mission critical systems. Physical fail-safes, e.g., involving electromechanical disconnection of network cables, or the flooding of a datacenter which holds a rogue AI, provide defense in depth if software, network, and microarchitectural isolation is compromised and a rogue AI must be temporarily shut down or permanently destroyed.

The basic idea is that many of the AI safety policies proposed by the AI community lack robust technical enforcement mechanisms. The worry is that, as models get smarter, they will be able to avoid those safety policies. The paper proposes a set technical enforcement mechanisms that could work against these malicious AIs.

[$] VFS write barriers

Post Syndicated from jake original https://lwn.net/Articles/1017947/

In the filesystem track at the 2025 Linux Storage, Filesystem, Memory
Management, and BPF Summit (LSFMM+BPF), Amir Goldstein wanted to resume
discussing
a feature that he had briefly introduced at the end of a 2023 summit session: filesystem “write
barriers”. The idea is to have an operation that would wait for any
in-flight write()
system calls, but not block any new write() calls as bigger
hammers, such as freezing the filesystem,
would do. His prototype implementation is used by a hierarchical
storage management
(HSM) system to create a crash-consistent
change log, but there may be other use cases to consider. He wanted
to discuss
implementation options and the possibility of providing an
API for user-space applications.

Разследване на Валя Ахчиева Елин Пелин – Истината за смъртносните взривове

Post Syndicated from Екип на Биволъ original https://bivol.bg/elin_pelin-explosions.html

сряда 23 април 2025


Девет месеца след трагедията край Елин Пелин с взривилите се складове за пиротехнически изделия, огнестрелни оръжия и боеприпаси за гражданска употреба, на 25-ти юли миналата година, отнела живота на четирима…

Материалът <span style='color:#ff0000;font-size:12px;'>Разследване на Валя Ахчиева</span> <BR> <H1 class='post-title single-post-title entry-title'>Елин Пелин – Истината за смъртносните взривове</H1> е публикуван за пръв път на Bivol!.

Security updates for Wednesday

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

Security updates have been issued by AlmaLinux (bluez, expat, and postgresql:12), Fedora (chromium, golang, LibRaw, moodle, openiked, ruby, and trafficserver), Red Hat (bluez, expat, gnutls, libtasn1, libxslt, mod_auth_openidc, mod_auth_openidc:2.3, ruby:3.1, thunderbird, and xmlrpc-c), and Ubuntu (linux, linux-aws, linux-gcp, linux-hwe-6.11, linux-lowlatency, linux-lowlatency-hwe-6.11, linux-oem-6.11, linux-oracle, linux-raspi, linux-realtime, linux-azure, linux-azure-6.11, linux-gcp-6.8, and matrix-synapse).

From Noise to Action: Introducing Intelligence Hub

Post Syndicated from Rapid7 original https://blog.rapid7.com/2025/04/23/from-noise-to-action-introducing-intelligence-hub/

From Noise to Action: Introducing Intelligence Hub

Co-authored by Raj Samani (Chief Scientist) & Craig Adams (Chief Product Officer)

In traditional conflicts, intelligence is both integral and beneficial to decision-making at every level. Unfortunately, in cybersecurity, the impact of threat intelligence as an asset for organizations—and in particular their security operations team—has been less significant.  

Why has this been the case? While threat intelligence should be intrinsic to the detection and response process, the reality is that security teams are overwhelmed with far too much noise to efficiently gather what they need from it. Not responding in a timely fashion ultimately means that by the time any response can be mustered, it will be too late. This is particularly the case given threat actors’ dwell times have in some instances decreased to a matter of hours.

The threat landscape is not static—defenders need a continuous view of what is occurring, right now.

We are delighted to announce the availability of Intelligence Hub, an evolution in threat intelligence delivery that is designed to provide meaningful context and actionable insights integrated with the Rapid7 Command Platform.

High-fidelity data: curated intelligence

Intelligence is not a commodity. Simply gathering every feed is why many organizations are overwhelmed and unable to respond in a timely manner to disrupt the kill chain before attackers move to the final stage. Consider many of the recent significant breaches; invariably, alerts are missed and data is exfiltrated. With this in mind, the focus of Rapid7 Labs has been to increase the fidelity of data, leveraging our own approach to curated intelligence.

Data that can be trusted

The objective of curated intelligence is to extract the low-prevalence indicators and verify the malicious nature of the artifact, thus enabling a timely response while reducing the risk of false positives. Introducing high-fidelity data also provides the opportunity to automate the response. Such an approach goes beyond the analyst and considers what an appropriate response should be.

The curated intelligence within Intelligence Hub is derived from ingestion sources that are unique to Rapid7, such as our honeypot data and proprietary research, as well as insights from our open source and research communities. These include Metasploit, AttackerKB, and other global communities that make our reach into understanding the threatscape both broader and deeper. Expertly crafted machine learning (ML) models combined with manual verification from our Rapid7 Labs team create additional layers of validation.

From Noise to Action: Introducing Intelligence Hub
What matters to me? Understand prevalence quickly with the campaigns that are targeting your business sector or geography as efficiently as possible.

Decay modeling maintains relevance

Even curated intelligence can quickly get very stale. If we consider an IP address used within a given campaign, this artifact will soon cease to be relevant since threat actors will migrate once it has been identified as known bad. For this reason, Intelligence Hub shows the decay score, which will reduce over time as the artifact migrates from known bad to unknown (or another state).

From Noise to Action: Introducing Intelligence Hub
A view of campaign activities being conducted by the Mustang Panda APT group (correct at the time of writing). Intelligence Hub covers all major threat activities from organized crime and APT groups.

Contextualized information

Intelligence Hub’s higher fidelity data remains continuously updated, allowing us to move away from the problem of traditional Threat Intelligence Platforms (TIPs) that have provided the firehose of false positives and noisy alerts. The opportunity is to now use prevalence to allocate resources to only the areas which are necessary. In other words, if a threat campaign is targeting a specific sector and/or geography and exploiting specific vulnerabilities, then surely these will require remediation first. In addition, if the campaign is being carried out by a ransomware group whose dwell time continues to drop, then almost certainly prioritizing remediation should include automation.

Automation does, of course, demand high-fidelity data, which is why curated intelligence remains the foundation of the solution.

Actionable insights

What all of this means is the security teams can get true, actionable insights — understanding what indicators within their environment are confirmed as malicious, as well as the threat actors’ motivations. Utilizing these insights to take the appropriate action to mitigate the threat in a timely fashion now becomes a reality with Intelligence Hub.

From Noise to Action: Introducing Intelligence Hub
Learn more about the active threat groups conducting operations in the world today.

Intelligence is great, but what does this mean for your organization?

Above all else, the integration of Intelligence Hub with the Rapid7 Command Platform provides the ability to go beyond the analyst and deliver true security outcomes. Firstly, with our next-gen SIEM, Rapid7 InsightIDR, the security analyst can prioritize triaging security alerts that demand attention. For example, if there are reliable indicators regarding the possibility of a ransomware group inside the environment, this clearly demands prioritization with the intention of disrupting the kill chain before the final stage payload is delivered. Such an approach reinforces why context matters, and perhaps controversially, why attribution becomes operationally relevant.

From Noise to Action: Introducing Intelligence Hub
Migrate away from the dependency of manual tools to integrate intelligence into operations and surface the alerts that truly matter.

Threat-informed remediation: beyond the security analyst

The role of intelligence Hub therefore goes beyond the security analyst, and supports integration with the remediation actions of any organization. An upcoming integration with Remediation Hub will give security analysts the added insight to justify security updates being rolled out outside of the normal change control cycle. An example of this could be CVE-2024-55591, an authentication bypass in Fortinet firewalls, which was exploited as a zero-day in January 2025 and reported to be used by ransomware groups on March 18, 2025. This attack warrants immediate remediation in order to mitigate the potential of being exploited. This answers the question many security practitioners are often asked: Are we vulnerable? And, with the investigation option within Intelligence Hub, the opportunity exists to answer the question: Have we been compromised?

With actionable (and relevant) intelligence being incorporated into the allocation of resources for remediation, Intelligence Hub provides the critical data necessary for effective security operations.

From Noise to Action: Introducing Intelligence Hub
Intelligence Hub is the integrated threat intelligence solution that delivers proactive context and prioritization, rapidly accelerating time to remediation.

The evolution of threat intelligence

In summary, Intelligence Hub represents a significant leap forward in threat intelligence delivery. By providing curated, high-fidelity data with relevant context and actionable insights, it empowers security teams to move beyond the noise of traditional threat intelligence solutions. The integration with the Rapid7 Command Platform and Remediation Hub further offers threat-informed remediation, allowing organizations to prioritize and automate responses effectively. Ultimately, Intelligence Hub is designed to help organizations achieve true security outcomes by focusing on what truly matters and disrupting the kill chain quicker, and with greater confidence. Learn more about Intelligence Hub here.

How can we empower girls in computing? An important conversation on the Hello World podcast

Post Syndicated from Meg Wang original https://www.raspberrypi.org/blog/how-can-we-empower-girls-in-computing-hello-world-podcast/

A key part of digital literacy is ensuring that all learners, regardless of their background or gender, have equal opportunities to develop computing skills and confidence in using technology.

However, the Department for Education in the UK recently released a report highlighting the growing gender gap in maths and science education. With International Girls in ICT Day just around the corner, it’s a timely reminder of the need to empower more girls and women within the computing sector.

In the latest episode of the Hello World podcast, Rachel Arthur, Chief Learning Officer at the Raspberry Pi Foundation, is joined by Dr. Jessica Hamer from King’s College London and Becky Patel from Tech She Can. Together, they explore the current state of girls’ engagement in computing and what we can do to support change.

This episode is the second in our three-part mini series on digital literacy. Each episode continues the conversations featured in the latest issue of the Hello World magazine, offering expert perspectives and practical examples from educators making a difference.

What is the gender gap, and why is it a problem?

The gender gap in computing refers to the disparity between the proportion of female and male students who choose computing as a subject or career. This is problematic because:

  • It reinforces harmful societal stereotypes that limit opportunities for girls
  • It hinders economic growth and innovation
  • It limits diversity in tech development, potentially leading to biased products, especially in artificial intelligence (AI)

Who are the guests on the podcast, and what will I learn?

To address these issues in detail, Rachel is joined by two guests who have dedicated years to understanding and addressing the gender gap. 

Dr. Jessica Hamer, King’s College London

Dr. Jessica Hamer is a Research Associate at King’s College London. She transitioned to academic research after working for a decade as a science teacher in secondary education. With a focus on projects like the SCARI project, she investigates factors affecting girls’ performance and participation in secondary-level computing. Her work includes a key report published last year on this topic.

In the podcast, Dr. Hamer reveals concerning findings about stereotypes in computing and how early they form. She explains that beliefs portraying girls as less interested in computing emerge as early as ages five or six, which significantly hinders girls’ engagement and involvement in the field.

Further, when students were asked to name famous figures in computing, most cited white, male tech entrepreneurs who are frequently in the news. This revealed a limited view of the kinds of people involved in computing, as well as a narrow conception of tech careers, with roles in areas like climate change and social justice being overlooked. However, Jessica highlights a key insight: “We found that girls were three times more likely to suggest a female famous face”, emphasising the vital importance of female representation and the need for relatable role models.

Becky Patel, Tech She Can

Becky Patel is the Head of Education and Learning at Tech She Can, a UK charity focused on increasing women’s representation in technology. She has a decade of teaching experience in both primary and secondary education and now develops the ‘Tech WE Can’ educational resources, which aim to inspire all children, particularly girls, to pursue careers in technology.

In the podcast, Becky emphasises the importance of early intervention to address gender stereotypes. She advocates for introducing children to a wide range of STEM careers, and to do this not just in computing lessons but across the whole curriculum. 

Another key strategy Becky highlights is showing children that they can explore their hobbies and interests further through technology, even when at first glance it might seem that technology can’t play a role. She explains:

“There are so many tech roles which you can do working behind the scenes, training the athlete, helping them with health and physiotherapy, working on goal-line technology… There’s so many cool things and when you show children this, you see the attention. You see them sit up like, hold on, she’s talking about me and the thing I love. And she’s also talking about computing.” 

Listen or watch now

To hear more about how to empower girls into computing, listen to or watch the full episode. 

We hope this episode inspires you and helps you to engage your students more in computing. In the comments section below, we’d love to hear your thoughts, your feedback, and any of your own tips for empowering girls and young women.

Enjoy the conversation!

More to discover next week

Next week, in the final podcast in our mini series, we’ll be looking at the notion of the ‘digital native’. Are young people truly tech-savvy, or are they simply reliant on digital tools without understanding the underlying mechanics?

James Robinson, Senior Learning Manager at the Raspberry Pi Foundation, will be joined by fellow colleague Sway Gratham and two guest speakers, Anna Lahtinen from Haaga-Helia University and Nicole O’Connor from Digi Know This, as they debate the complexities of digital skills, access, and education. Discover how the label ‘digital native’ can mask crucial issues and learn what real digital literacy looks like today.

Subscribe to Hello World

You can watch, or listen, to each episode of our podcast on YouTube, or listen via your preferred audio streaming service, whether that’s Apple Podcasts, Spotify, or Amazon Music. 

Don’t miss out on this discussion — subscribe to Hello World today to ensure you never miss a podcast episode or issue of the magazine.

The post How can we empower girls in computing? An important conversation on the Hello World podcast appeared first on Raspberry Pi Foundation.

The collective thoughts of the interwebz