AWS Security Hub now generally available with near real-time analytics and risk prioritization

Post Syndicated from Esra Kayabali original https://aws.amazon.com/blogs/aws/aws-security-hub-now-generally-available-with-near-real-time-analytics-and-risk-prioritization/

Today, AWS Security Hub is generally available, transforming how security teams identify and respond to critical security risks across their AWS environments. These new capabilities were first announced in preview at AWS re:Inforce 2025. Security Hub prioritizes your critical security issues and unifies your security operations to help you respond at scale by correlating and enriching signals across multiple AWS security services. Security Hub provides near real-time risk analytics, trends, unified enablement, streamlined pricing, and automated correlation that transforms security signals into actionable insights.

Organizations deploying multiple security tools need to manually correlate signals across different consoles, creating operational overhead that can delay detection and response times. Security teams use various tools for threat detection, vulnerability management, security posture monitoring, and sensitive data discovery, but extracting value from the findings these tools generate requires significant manual effort to understand relationships and determine priority.

Security Hub addresses these challenges through built-in integration that unifies your cloud security operations. Available for individual accounts or entire AWS Organizations accounts, Security Hub automatically aggregates and correlates signals from Amazon GuardDuty, Amazon Inspector, AWS Security Hub Cloud Security Posture Management (AWS Security Hub CSPM), and Amazon Macie, organizing them by threats, exposures, resources, and security coverage. This unified approach reduces manual correlation work, helping you quickly identify critical issues, understand coverage gaps, and prioritize remediation based on severity and impact.

What’s new in general availability
Since the preview announcement, Security Hub has added several new features.

Historical trends
Security Hub includes a Trends feature through the Summary dashboard that provides up to 1 year of historical data for findings and resources across your organization. The Summary dashboard displays an overview of your exposures, threats, resources, and security coverage through customizable widgets that you can add, remove, and arrange based on your operational needs.

The dashboard includes a Trends overview widget that displays period-over-period analysis for day-over-day, week-over-week, and month-over-month comparisons, helping you track whether your security posture is improving or degrading. Trend widgets for Active threat findings, Active exposure findings, and Resource trends provide visualizations of average counts over selectable time periods including 5 days, 30 days, 90 days, 6 months, and 1 year. You can filter these visualizations by severity levels such as critical, high, medium, and low, and hover over specific points in time to review detailed counts.

The Summary dashboard also includes widgets that display current exposure summaries prioritized by severity, threat summaries showing malicious or suspicious activity, and resource inventories organized by type and associated findings.

The Security coverage widget helps you identify gaps in your security service deployment across your organization. This widget tracks which AWS accounts and Regions have security services enabled, helping you understand where you might lack visibility into threats, vulnerabilities, misconfigurations, or sensitive data. The widget displays account coverage across security capabilities including vulnerability management by Amazon Inspector, threat detection by GuardDuty, sensitive data discovery by Amazon Macie, and posture management by AWS Security Hub CSPM. Coverage percentages show which security checks passed or failed across your AWS accounts and Regions where Security Hub is enabled.

You can apply filters to widgets using shared filters that apply across all widgets, finding filters for exposure and threat data, or resource filters for inventory data. You can create and save filter sets using and/or operators to define specific criteria for your security analysis. Dashboard customizations, including saved filter sets and widget layouts, are saved automatically and persist across sessions.

If you configure cross-Region aggregation, the Summary dashboard includes findings from all linked Regions when viewing from your home Region. For delegated administrator accounts in AWS Organizations, data includes findings for both the administrator account and member accounts. Security Hub retains trends data for 1 year from the date findings are generated. After 1 year, trends data is automatically deleted.

Near real-time risk analytics
Security Hub now calculates exposures in near real-time and includes threat correlation from GuardDuty alongside existing vulnerability and misconfiguration analysis. When GuardDuty detects threats, Amazon Inspector identifies vulnerabilities, or AWS Security Hub CSPM discovers misconfigurations, Security Hub automatically correlates these findings and updates associated exposures. This advancement provides immediate feedback on your security posture, helping you quickly identify new exposures and verify that remediation actions have reduced risk as expected.

Security Hub correlates findings across AWS Security Hub CSPM, Amazon Inspector, Amazon Macie, Amazon GuardDuty, and other security services to identify exposures that could lead to security incidents. This correlation helps you understand when multiple security issues combine to create critical risk. Security Hub enriches security signals with context by analyzing resource associations, potential impact, and relationships between signals. For example, if Security Hub identifies an Amazon Simple Storage Service (Amazon S3) bucket containing sensitive data with versioning disabled, Object Lock disabled, and MFA delete disabled, remediating any component triggers automatic calculation, helping you verify remediation effectiveness without waiting for scheduled assessments.

The Exposure page organizes findings by title and severity, helping you focus on critical issues first. The page includes an Overview section with a trends graph that displays the average count of exposure findings over the last 90 days, segmented by severity level. This visualization helps you track changes in your exposure posture over time and identify patterns in security risk.

Exposure findings are grouped by title with expandable rows showing the count of affected resources and overall severity. Each exposure title describes the potential security impact, such as “Potential Data Destruction: S3 bucket with versioning, Object Lock, and MFA delete disabled” or “Potential Remote Execution: EC2 instance is reachable from VPC and has software vulnerabilities.” You can filter exposures using saved filter sets or quick filters based on severity levels including critical, high, medium, and low. The interface also provides filtering by account ID, resource type, and accounts, helping you quickly narrow down exposures relevant to specific parts of your infrastructure.

Security Hub generates exposures as soon as findings are available. For example, when you deploy an Amazon Elastic Compute Cloud (Amazon EC2) instance that is publicly accessible and Amazon Inspector detects a highly exploitable vulnerability while AWS Security Hub CSPM identifies the public accessibility configuration, Security Hub automatically correlates these findings to generate an exposure without waiting for a scheduled assessment. This near-real time correlation helps you identify critical risks in newly deployed resources and take action before they can be exploited.

When you select an exposure finding, the details page displays the exposure type, primary resource, Region, account, age, and creation time. The Overview section shows contributing traits that represent the security issues directly contributing to the exposure scenario. These traits are organized by categories such as Reachability, Vulnerability, Sensitive data, Misconfiguration, and Assumability.

The details page includes a Potential attack path tab that provides a visual graph showing how potential attackers could access and take control of your resources. This visualization displays the relationships between the primary resource (such as an EC2 instance), involved resources (such as VPC, subnet, network interface, security group, AWS Identity and Access Management (IAM) instance profile, IAM role, IAM policy, and volumes), and contributing traits. The graph helps you understand the complete attack surface and identify which security controls need adjustment.

The Traits tab lists all security issues contributing to the exposure, and the Resources tab shows all affected resources. The Remediation section provides prioritized guidance with links to documentation, recommending which traits to address first to reduce risk most effectively. By using this comprehensive view, you can investigate specific exposures, understand the full context of security risks, and track remediation progress as your team addresses vulnerabilities, misconfigurations, and other security gaps across your environment.

Expanded partner integrations
Security Hub supports integration with Jira and ServiceNow for incident management workflows. When viewing a finding, you can create a ticket in your preferred system directly from the AWS Security Hub console with finding details, severity, and recommended remediation steps automatically populated. You can also define automation rules in Security Hub that automatically create tickets in Atlassian’s Jira Service Management and ServiceNow based on criteria you specify, such as severity level, resource type, or finding type. This helps you route critical security issues to your incident response teams without manual intervention.

Security Hub findings are formatted in the Open Cybersecurity Schema Framework (OCSF) schema, an open-source standard that enables security tools to share data seamlessly. Partners who have built integrations with the OCSF format with Security Hub include Cribl, CrowdStrike, Databee, DataDog, Dynatrace, Expel, Graylog, Netskope, Securonix, SentinelOne, Splunk a Cisco company, Sumo Logic, Tines, Upwind Security, Varonis, DTEX, and Zscaler. Additionally, service partners such as Accenture, Caylent, Deloitte, Optiv, PwC, and Wipro can help you adopt Security Hub and the OCSF schema.

Security Hub also supports automated response workflows through Amazon EventBridge. You can create EventBridge rules that identify findings based on criteria you specify and route them to targets such as AWS Lambda functions or AWS Systems Manager Automation runbooks for processing and remediation. This helps you act on findings programmatically without manual intervention.

Now available
If you currently use AWS Security Hub CSPM, Amazon GuardDuty, Amazon Inspector, or Amazon Macie, you can access these capabilities by navigating to the AWS Security Hub console. If you’re a new customer, you can enable Security Hub through the AWS Management Console and configure the security services appropriate for your workloads. Security Hub automatically consumes findings from enabled services, making the findings available in the unified console and creating correlated exposure findings based on the ingested security data.

For Regional availability, visit our AWS Services by Region page. Near real-time exposure calculation and the Trends feature are included at no additional charge. Security Hub uses a streamlined, resource-based pricing model that consolidates charges across integrated AWS security services. The console includes a cost estimator to help you plan and forecast security investments across your AWS accounts and Regions before deployment. For detailed information about capabilities, supported integrations, and pricing, visit the AWS Security Hub product page and technical documentation.

— Esra

Amazon GuardDuty adds Extended Threat Detection for Amazon EC2 and Amazon ECS

Post Syndicated from Betty Zheng (郑予彬) original https://aws.amazon.com/blogs/aws/amazon-guardduty-adds-extended-threat-detection-for-amazon-ec2-and-amazon-ecs/

Today, we’re announcing new enhancements to Amazon GuardDuty Extended Threat Detection with the addition of two attack sequence findings for Amazon Elastic Compute Cloud (Amazon EC2) instances and Amazon Elastic Container Service (Amazon ECS) tasks. These new findings build on the existing Extended Threat Detection capabilities, which already combine sequences involving AWS Identity and Access Management (IAM) credential misuse, unusual Amazon Simple Storage service (Amazon S3) bucket activity, and Amazon Elastic Kubernetes Service (Amazon EKS) cluster compromise. By adding coverage for EC2 instance groups and ECS clusters, this launch expands sequence-level visibility to virtual machine and container environments that support the same application. Together, these capabilities provide a more consistent and unified way to detect multistage activity across diverse Amazon Web Services (AWS) workloads.

Modern cloud environments are dynamic and distributed, often running virtual machines, containers, and serverless workloads at scale. Security teams strive to maintain visibility across these environments and connect related activities that might indicate complex, multistage attack sequences. These sequences can involve multiple steps, such as establishing initial access and persistence, providing missing credentials or performing unexpected data access, that unfold over time and across different sources. GuardDuty Extended Threat Detection automatically links these signals using AI and machine learning (ML) models trained at AWS scale to build a complete picture of the activity and surface high-confidence insights to help customers prioritize response actions. By combining evidence from diverse sources, this analysis produces high-fidelity, unified findings that would otherwise be difficult to infer from individual events.

How it works
Extended Threat Detection analyzes multiple types of security signals, including runtime activity, malware detections, VPC Flow Logs, DNS queries, and AWS CloudTrail events to identify patterns that represent a multistage attack across Amazon EC2 and Amazon ECS workloads. Detection works with the GuardDuty foundational plan, and turning on Runtime Monitoring for EC2 or ECS adds deeper process and network-level telemetry that strengthens signal analysis and increases the completeness of each attack sequence.

The new attack sequence findings combine runtime and other observed behaviors across the environment into a single critical-severity sequence. Each sequence includes an incident summary, a timeline of observed events, mapped MITRE ATT&CK® tactics and techniques, and remediation guidance to help you understand how the activity unfolded and which resources were affected.

EC2 instances and ECS tasks are often created and replaced automatically through Auto Scaling groups, shared launch templates, Amazon Machine Images (AMIs), IAM instance profiles, or cluster-level deployments. Because these resources commonly operate as part of the same application, activity observed across them might originate from a single underlying compromise. The new EC2 and ECS findings analyze these shared attributes and consolidate related signals into one sequence when GuardDuty detects a pattern affecting the group.

When a sequence is detected, the GuardDuty console highlights any critical-severity sequence findings on the Summary page, with the affected EC2 instance group or ECS cluster already identified. Selecting a finding opens a consolidated view that shows how the resources are connected, which signals contributed to the sequence, and how the activity progressed over time, helping you quickly understand the scope of impact across virtual machine and container workloads.

In addition to viewing sequences in the console, you can also see these findings in AWS Security Hub, where they appear on the new exposure dashboards alongside other GuardDuty findings to help you understand your overall security risk in one place. This detailed view establishes the context for interpreting how the analysis brings related signals together into a broader attack sequence.

Together, the analysis model and grouping logic give you a clearer, consolidated view of activity across virtual machine and container workloads, helping you focus on the events that matter instead of investigating numerous individual findings. By unifying related behaviors into a single sequence, Extended Threat Detection helps you assess the full context of an attack path and prioritize the most urgent remediation actions.

Now available
Amazon GuardDuty Extended Threat Detection with expanded coverage for EC2 instances and ECS tasks is now available in all AWS Regions where GuardDuty is offered. You can start using this capability today to detect coordinated, multistage activity across virtual machine and container workloads by combining signals from runtime activity, malware execution, and AWS API activity.

This expansion complements the existing Extended Threat Detection capabilities for Amazon EKS, providing unified visibility into coordinated, multistage activity across your AWS compute environment. To learn more, visit the Amazon GuardDuty product page.

–Betty

Introducing Amazon Nova Forge: Build your own frontier models using Nova

Post Syndicated from Danilo Poccia original https://aws.amazon.com/blogs/aws/introducing-amazon-nova-forge-build-your-own-frontier-models-using-nova/

Organizations are rapidly expanding their use of generative AI across all parts of the business. Applications requiring deep domain expertise or specific business context need models that truly understand their proprietary knowledge, workflows, and unique requirements.

While techniques like prompt engineering and Retrieval Augmented Generation (RAG) work well for many use cases, they have fundamental limitations when it comes to embedding specialized knowledge into a model’s core understanding. Supervised fine-tuning and reinforcement learning help in customizing the model, but they operate too late in the development lifecycle, layering modifications on top of models that are a fully trained, and therefore difficult to steer to specific domains of interest.

When organizations attempt deeper customization through Continued Pre-Training (CPT) using only their proprietary data, they often encounter catastrophic forgetting, where models lose their foundational capabilities as they learn new content. At the same time, the data, compute, and cost needed for training a model from scratch are still a prohibitive barrier for most organizations.

Today, we’re introducing Amazon Nova Forge, a new service to build your own frontier models using Nova. Nova Forge customers can start their development from early model checkpoints, blend their datasets with Amazon Nova-curated training data, and host their custom models securely on AWS. Nova Forge is the easiest and most cost-effective way to build your own frontier model.

Use cases and applications
Nova Forge is designed for organizations with access to proprietary or industry-specific data who want to build AI that truly understands their domain. This includes:

  • Manufacturing and automation – Building models that understand specialized processes, equipment data, and industry-specific workflows
  • Research and development – Creating models trained on proprietary research data and domain-specific knowledge
  • Content and media – Developing models that understand brand voice, content standards, and specific moderation requirements
  • Specialized industries – Training models on industry-specific terminology, regulations, and best practices

Depending on the specific use cases, Nova Forge can be used to add differentiated capabilities, enhance task-specific accuracy, reduce costs, and lower latency.

How Nova Forge works
Nova Forge addresses the limitations of current customization approaches by allowing you to start model development from early checkpoints across pre-training, mid-training, and post-training phases. You can blend your proprietary data with Amazon Nova-curated data throughout all training phases, running training using proven recipes on Amazon SageMaker AI fully managed infrastructure. This data mixing approach significantly reduces catastrophic forgetting compared to training with raw data alone, helping preserve foundational skills—including core intelligence, general instruction following capabilities, and safety benefits—while incorporating your specialized knowledge.

Nova Forge provides the ability to use reward functions in your own environment for reinforcement learning (RL). This allows the model to learn from feedback generated in environments that are representative of your use cases. Beyond single-step evaluations, you can also use your own orchestrator to manage multi-turn rollouts, enabling RL training for complex agent workflows and sequential decision-making tasks. Whether you’re using chemistry tools to score molecular designs, or robotics simulations that reward efficient task completion and penalize collisions, you can connect your proprietary environments directly.

You can also take advantage of the built-in responsible AI toolkit available in Nova Forge to configure the safety and content moderation settings of your model. You can adjust settings to meet your specific business needs in areas like safety, security, and handling of sensitive content.

Getting started with Nova Forge
Nova Forge integrates seamlessly with your existing AWS workflows. You can use the familiar tools and infrastructure in Amazon SageMaker AI to run your training, then import your custom Nova models as private models on Amazon Bedrock. This gives you the same security, consistent APIs, and broader AWS integrations as any model in Amazon Bedrock.

In Amazon SageMaker Studio, you can now build your frontier model with Amazon Nova.

Amazon Nova Forge in the SageMaker AI console

To start building the model, choose which checkpoint to use: pre-trained, mid-trained, or post-trained. You can also upload your dataset here or use existing datasets.

Amazon Nova Forge checkpoints

You can blend your training data by mixing in curated datasets provided by Nova. These datasets, categorized by domain, can help your model to preserve general performance and prevent overfitting or catastrophic forgetting.

Amazon Nova Forge data mixing

Optionally, you can choose to use Reinforcement Fine-Tuning (RFT) to improve factual accuracy and reduce hallucinations in specific domains.

When training completes, import the model into Amazon Bedrock and start using it in your applications.

Things to know
Amazon Nova Forge is available in the US East (N. Virginia) AWS Region. The program includes access to multiple Nova model checkpoints, training recipes to mix proprietary data with Amazon Nova-curated training data, proven training recipes, and integration with Amazon SageMaker AI and Amazon Bedrock.

Learn more in the Amazon Nova User Guide and explore Nova Forge from the Amazon SageMaker AI console.

Organizations interested in expert assistance can also reach out to our Generative AI Innovation Center for additional support with their model development initiatives.

— Danilo

Let’s Encrypt to reduce certificate lifetimes

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

Let’s Encrypt has announced
that it will be reducing the validity period of its certificates from
90 days to 45 days by 2028:

Most users of Let’s Encrypt who automatically issue certificates
will not have to make any changes. However, you should verify that
your automation is compatible with certificates that have shorter
validity periods.

To ensure your ACME client renews on time, we recommend using ACME
Renewal Information (ARI). ARI is a feature we’ve introduced to help
clients know when they need to renew their certificates. Consult your
ACME client’s documentation on how to enable ARI, as it differs from
client to client. If you are a client developer, check out this
integration guide.

If your client doesn’t support ARI yet, ensure it runs on a
schedule that is compatible with 45-day certificates. For example,
renewing at a hardcoded interval of 60 days will no longer be
sufficient. Acceptable behavior includes renewing certificates at
approximately two thirds of the way through the current certificate’s
lifetime.

Manually renewing certificates is not recommended, as it will need
to be done more frequently with shorter certificate lifetimes.

FreeBSD 15.0 released

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

FreeBSD
15.0 has been released. Notable changes in this release include a new
method for installing
the base system using the pkg package manager, an update
to OpenZFS 2.4.0-rc4,
native support for the inotify(2)
interface, and the addition of Open Container Initiative (OCI) images
to FreeBSD’s release artifacts. See the release
notes for a full list of changes, hardware
notes for supported hardware, and check the errata
before installing or upgrading.

[$] Zig’s new plan for asynchronous programs

Post Syndicated from daroc original https://lwn.net/Articles/1046084/

The designers of the

Zig programming language have been working to find a
suitable design for asynchronous code for some time.
Zig is a carefully minimalist language, and its

initial design for
asynchronous I/O did not fit well with its other
features. Now, the project has

announced (in a Zig SHOWTIME video) a new approach to asynchronous I/O that
promises to solve the

function coloring problem, and allows writing code that will execute
correctly using either synchronous or asynchronous I/O.

Security updates for Tuesday

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

Security updates have been issued by Fedora (gnutls, libpng, mingw-python3, python-spotipy, source-to-image, unbound, and webkitgtk), Mageia (libpng), SUSE (bash-git-prompt, gitea-tea, java-17-openjdk, java-21-openjdk, kernel, openssh, python, and shadowsocks-v2ray-plugin, v2ray-core), and Ubuntu (binutils, openjdk-17-crac, openjdk-21-crac, and openjdk-25-crac).

Rapid7 Helps Lower Your Cost to Assurance for HITRUST

Post Syndicated from Jon Schipp original https://www.rapid7.com/blog/post/pt-rapid7-hitrust-lowers-continuous-assurance-cost-asm

Organizations across regulated sectors are under growing pressure to prove their security readiness. At the same time, traditional assurance approaches rely on periodic audits and manual evidence collection. These activities take time, strain staff, and often fall out of date as environments evolve.

To help close this gap, Rapid7 has partnered with HITRUST to bring automated evidence collection and continuous validation of security controls to customers who follow HITRUST frameworks. This partnership builds on existing capabilities in the Rapid7 Command Platform and creates a more efficient path for organizations that need to demonstrate strong and reliable assurance.

Rapid7 achieves this by leveraging our native telemetry and extensive support for third-party data sources; the Rapid7 Command Platform has visibility into vulnerabilities, exposures, configurations, identities, threat detections, IT context and more, the very same datasets that make up the evidence of technical compliance controls.  Meaning that Rapid7 as a Security Operations platform, not only implements those very controls but can also help customers to prove those controls to lower their cost to certification. This is accomplished through automated evidence collection and continuous controls monitoring from Surface Command to detect things like compliance drift.

⠀

HITRUST-e1-Dashboard-Example.png
HITRUST e1 Dashboard Example

⠀

To help understand how Rapid7 can help our customers to assure against HITRUST and its many levels of assurance, we will provide a brief background on HITRUST.

The importance of HITRUST

HITRUST offers one of the most comprehensive cybersecurity assurance programs for risk, security, and compliance. Its framework is informed by more than 60 standards and is continuously updated based on active threats and risk thresholds. This helps close the gap between traditional checkbox compliance and the realities of modern risk.

HITRUST has developed an all-encompassing compliance framework, a framework of frameworks, if you will. It’s the only compliance framework that is actively updated based on the latest attacker behavior and security threats, meaning it can further close the gap between checkbox compliance and actual risk reduction. It offers a portfolio of assessments and certifications that validate the security of systems, data and environment. They currently laude a 99.41% breach-free rate for organizations that have a HITRUST certification. This alone is a very compelling stat, yet there’s another area of differentiation that is worth mentioning. HITRUST assessors are entirely independent from the HITRUST organization. This independence provides organizations with a consistent and transparent way to validate their control performance. Achieving HITRUST assurance also extends coverage across several major frameworks, including ISO/IEC 27001, NIST CSF, HIPAA, and GDPR. This helps teams streamline overlapping requirements while working within a single, structured model.

⠀

HITRUST-did-you-know.png

⠀

HITRUST-security-breach-rate-chart.png

What is HITRUST assurance?

Assurance, defined by HITRUST, is a token of trust that HITRUST designates to organizations that have been through the assurance process. There are two main requirements to be trustworthy:

  1. The control set has to be relevant e.g. informed by latest attacker behavior

  2. The control set has to be reliable, transparent and have an open scoring system and independent assessor network

Customers are assessed by an independent network of HITRUST assessors (e.g audit firms) to evaluate if they meet the requirements of the HITRUST framework, which provides several levels of controls based on the size, sector, and risk profile of the organization. HITRUST provides a free CSF framework that has been downloaded by over 35,000 organizations. The r2 certification has been around the longest, for around 10 years and is the most rigorous. There is a newer certification called e1, which is an entry-level control set to help customers get started and is seeing the majority of adoption by new HITRUST customers.

The e1 currently has over 40 technical controls to adhere to, and the r2 is a combination of the control set from i1 (over 100 controls) with a per-customer set of controls based on the specific risk to that business. This means that no two r2 assessments are the same. Highlighting another key differentiator of HITRUST that goes beyond the check-the-box, minimal viable security approach to compliance.

⠀

HITRUST-assessment-types.png

⠀
Lastly, HITRUST frameworks are typically updated quarterly leveraging the latest research on threats and industry best practices. While this can be challenging for customers to maintain that have not adopted automated evidence collection, it ensures that HITRUST is providing a high quality risk-informed framework that drives meaningful security outcomes.

How the Rapid7 partnership strengthens assurance programs

Rapid7’s Surface Command provides customers with a complete internal and external view of their attack surface, including vulnerabilities, misconfigurations, assets, and exposure data. With this new integration, the platform can now collect, map, and validate technical controls against HITRUST requirements using the same datasets security teams rely on for day-to-day operations.

This automated approach supports several outcomes featured in the press release:

  • Continuous compliance visibility: The Command Platform assesses environments for control drift based on HITRUST requirements, which are updated in response to emerging threats.

  • Proactive risk mitigation: Customers can connect vulnerability and exposure insights with HITRUST controls to address areas that matter most.

  • Lower audit burden: Continuous validation reduces manual evidence collection and helps narrow audit scope to the areas that require attention.

  • Support for cyber insurance: Demonstrating consistent control performance can help organizations show strong risk management practices to insurers.

  • Lower costs: By reducing manual work and helping teams focus on priority controls, organizations can minimize the resource-intensive process associated with traditional assurance cycles.

To summarize, Rapid7 Command Platform can map & monitor technical controls to HITRUST e1, i1 and r2, and then by sampling them continuously, Rapid7 can detect control drift to identify areas that need attention, lowering the need for an expensive, comprehensive assessment. We can now help customers focus on remediating what needs attention and enable their assessors to look for only those areas that need addressing, instead of the full scope, ultimately saving costs during the evidence collection and assurance process.

Moving from periodic audits to continuous assurance

Moving from periodic audits to continuous assurance with Surface Command, Rapid7’s attack surface management (ASM) solution, provides our customers with a unified, continuously updated view of all assets and exposures in their organization through a combination of Rapid7 and third-party security data. Today’s security programs need approaches that keep pace with real threats and regulatory expectations. By pairing Rapid7’s visibility into security controls with HITRUST’s structured and independently assessed framework, customers can shift from point-in-time checks to a continuous, evidence-based view of their cybersecurity posture.

This partnership helps teams maintain confidence in their control performance, reduce evidence decay, and communicate program health more effectively to leadership and stakeholders.
Learn more here.

⠀

HITRUST-e1-Dashboard-Example-2.png
HITRUST e1 Dashboard Example

От „на парче“ към ясни цели. Как общината да работи ефективно?

Post Syndicated from original https://www.toest.bg/ot-na-parche-kum-yasni-tseli-kak-obstinata-da-raboti-efektivno/

От „на парче“ към ясни цели. Как общината да работи ефективно?

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

В тази статия разглеждам Столичната община (СО) като пример. Ще разкажа какво представлява визията ѝ (да, има такава) и ще премина през целеполагането, изхождащо от тази визия. Ще стигна до изпълнението, за да се види какво е нужно, така че като резултат от визията да усетим в ежедневието си на граждани трайна и устойчива промяна към по-добро. Ще се позовавам на примера с общинско предприятие, в чийто екип съм била и съм участвала в организирането на неговата работа.

Визията като основа на целите и плана

София, наред с градове като Берлин, Бостън, Лондон, Бърно и Хелзинки, има своята дългосрочна визия, която задава посоката за цялостното развитие на града и общината чак до 2050 г. Тя е разработена от мултидисциплинарен екип от експерти (ядрото на който продължава работата си в Общинско предприятие „Софияплан“ и по-късно основава „Екипът на София“) съвместно с над 10 000 участници. Те са представители на администрацията, бизнеса, неправителствения сектор, изследователи от различни сфери и отделни граждани. 

Работата по Визия за София продължава две години. Приета е от Столичния общински съвет (СОС) през 2020 г. Стратегическият документ би следвало да служи за основа на всички останали планове, цели и стратегии на СО до 2050 г. Като следваща стъпка средносрочните цели на СО са зададени в Програмата за София, приета от СОС година след Визията. От нея би трябвало да зависят развитието на общината и нейните приоритети до 2027 г.

Би трябвало… а така ли е наистина? С уговорката, че целеполагането в СО не е изцяло публичен процес и е също въпрос на вътрешна организация на работата, да видим какво знаем по темата и какво споделя самата СО.

Целите – ясни или не съвсем?

Като част от „Екипът на София“ следя отблизо как Общината целеполага, как отчита дейността си и доколко е прозрачна в тези свои дейности. Ето и какво забелязвам през последните няколко години.

Целите на настоящото управление на СО бяха зададени в Управленската програма 2023–2027 (УП). В нея виждаме заявки за реформи и инициативи в четири основни области, определени от управлението като най-важни: здраве, възможности, ред и ефективна община. Някои от тях съответстват на документите, споменати по-горе, например стремежът СО да бъде максимално ефективна. Други, като фокуса върху реда, са по-скоро отговор на отдавна съществуващи проблеми.

Ако погледнем по-цялостно на Програмата, 

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

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

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

И по този показател виждаме разнопосочност в поставените цели и мерки в УП. Някои, например „Единно мобилно приложение и уебсайт за гражданите и бизнеса за работа с услугите на общината“, са относително ясно дефинирани: или ще имаме разработен сайт и приложение до края на 2027 г., или не. Макар че в случая може да се поставят и цели за определен брой потребители, които да ползват даден брой услуги например, все пак тази цел е ясно дефинирана. Други обаче, като „Подобряване на електронните услуги, предоставяни от общината“, звучат като добри пожелания без конкретен измерител за успех. Какво точно означава „подобряване“? Как ще разберем дали сме подобрили услугите? И какво точно искаме да стане с електронните услуги, кога и как?

От цели към изпълнение… и отчетност

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

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

Отчетността на Общината такава, каквато е в момента, е стъпка в правилната посока: прозрачност и информираност. Ала ако разгледаме годишните отчети, ще забележим, че има теми от УП, които не са засегнати, и липсват разяснения защо това е така.

Нека вземем само един от няколкото примера с хоризонт края на 2024 г. 

В УП се прави заявка дотогава да се реорганизира разпределението на отговорности между централната и районните администрации, но тази тема отсъства от отчета за 2024 г. – в него се говори изрично само за финансова децентрализация, а в отчета за 2025 г. децентрализация вече не се споменава под никаква форма. Не става ясно дали има действия в посока разпределение на отговорности отвъд финансите, но авторите на отчета са преценили, че информацията за това не е достатъчно значима или интересна. Или пък нещо е наложило разместване в приоритетите и по тези задачи не е работено. Ако се е случило второто, какво е наложило темата да бъде заменена с други, които не намираме в програмата, но са отразени в отчета? 

Когато липсват отговори на тези въпроси, има риск читателят на отчета да остане с усещането, че е работено „на парче“, без ясна и последователна визия, дори и това да не е така и въпреки че видимо са постигнати успехи в сферите, които засяга отчетът.

„Добрите“ цели

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

За да преминем от визия към реалност, е нужно да поставим конкретни, измерими и изпълними цели в средносрочен и дългосрочен план. За да постигнем това, може да използваме множество готови рамки и модели. Една такава рамка е „Цели и ключови резултати“, по-известна с английското си наименование Objectives and Key Results, съкратено OKR. Тя идва от бизнеса, но е приложима и в публичния сектор. Прилагана е например в Националната агенция за превенция на корупцията в Украйна и община Сиракюз, Ню Йорк.

OKR е рамка за поставяне на цели, която помага на организациите да свържат целите (Objectives) с измерими резултати (Key Results). Целите са това, което искаме да постигнем, докато ключовите резултати са начините, по които измерваме дали сме ги постигнали. OKR работи, като зададем цели, за всяка от които определим от 3 до 5 конкретни, измерими и количествено определени ключови резултата, които целим да постигнем за определен период.


Цел 1

Измерим резултат

Измерим резултат

Измерим резултат

Измерим резултат

Цел 2

Измерим резултат

Измерим резултат

Измерим резултат


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

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

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

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

  • Какво предстои да стане, кога и как? 
  • Какви възможности имам да се включа в процеса по планиране, поставяне на цели и съставяне на бюджета? 
  • Кое от планираното се изпълнява и как върви работата по него? 
  • Кое се бави, защо и кога ще стане? 
  • Кои неща се налага да отпаднат от плана и защо? Какво ще стане с тях?

А можем ли и в София?

Тук може би някои читатели скептично повдигат вежди: „Публична администрация ли е, не може да е ефективна, нито да прилага съвременни методи на работа.“ Обаче не само може, а и подобна добра практика се прилага активно точно в общинско предприятие. Бях част от неговия екип в ключов момент от развитието му и ще ви разкажа от своя личен опит за добрите практики, които приложихме с екипа на предприятието, за да увеличим максимално ефективността на работата в тази организация.

„Софияплан“ е звеното за стратегическо и пространствено планиране на СО. Преди да поеме тази роля през 2020 г., предприятието работи по различни задачи, свързани с устройствено планиране, под името „Софпроект – ОГП“ (съкратено от „общ градоустройствен план“). Като част от подготовката за трансформацията в звено за цялостно стратегическо планиране още през 2019 г. в „Софияплан“ се въвеждат съвременни методи за планиране, изпълнение и отчитане на работата, които се доразвиват през 2020 и 2021 г.

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

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

Този начин на работа е съществен фактор „Софияплан“ да се превърне в едно от най-ефективните и продуктивни звена на СО, 

което с екип от само 26 души успява да разработи сложни проекти, като Програмата за София. Ефективност има и в направените разходи. За 2021 г. – годината, през която се разработва Програмата, целият бюджет на предприятието е 1 364 509 лв. С него се обезпечава работата по 32 проекта с различен мащаб, обхват и сложност, само един от които е Програмата за София. 

За сравнение, община Варна, която е с 28% от населението и 25% от площта на Столичната, бюджетира 606 000 лв. само за разработването на своя план за интегрирано развитие – еквивалента на Програмата за София, но за Варна. А бюджетът на община Велико Търново (със 7% от населението и 66% от площта на Столичната) за аналогичен план е 270 000 лв.


270 000 лв.

План за интегрирано развитие – еквивалент
на Програмата за София

Община Велико Търново
7% от населението и 66% от площта на Столичната община

606 000 лв.

План за интегрирано развитие – еквивалент
на Програмата за София

Община Варна
28% от населението и 25% от площта на Столичната община

1 364 509 лв.

Програмата за София + 31 други проекта





































„Софияплан“
с екип от 26 човека


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

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

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

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

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

От „на парче“ към ясни цели. Как общината да работи ефективно?

Like Social Media, AI Requires Difficult Choices

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/12/like-social-media-ai-requires-difficult-choices.html

In his 2020 book, “Future Politics,” British barrister Jamie Susskind wrote that the dominant question of the 20th century was “How much of our collective life should be determined by the state, and what should be left to the market and civil society?” But in the early decades of this century, Susskind suggested that we face a different question: “To what extent should our lives be directed and controlled by powerful digital systems—and on what terms?”

Artificial intelligence (AI) forces us to confront this question. It is a technology that in theory amplifies the power of its users: A manager, marketer, political campaigner, or opinionated internet user can utter a single instruction, and see their message—whatever it is—instantly written, personalized, and propagated via email, text, social, or other channels to thousands of people within their organization, or millions around the world. It also allows us to individualize solicitations for political donations, elaborate a grievance into a well-articulated policy position, or tailor a persuasive argument to an identity group, or even a single person.

But even as it offers endless potential, AI is a technology that—like the state—gives others new powers to control our lives and experiences.

We’ve seen this out play before. Social media companies made the same sorts of promises 20 years ago: instant communication enabling individual connection at massive scale. Fast-forward to today, and the technology that was supposed to give individuals power and influence ended up controlling us. Today social media dominates our time and attention, assaults our mental health, and—together with its Big Tech parent companies—captures an unfathomable fraction of our economy, even as it poses risks to our democracy.

The novelty and potential of social media was as present then as it is for AI now, which should make us wary of its potential harmful consequences for society and democracy. We legitimately fear artificial voices and manufactured reality drowning out real people on the internet: on social media, in chat rooms, everywhere we might try to connect with others.

It doesn’t have to be that way. Alongside these evident risks, AI has legitimate potential to transform both everyday life and democratic governance in positive ways. In our new book, “Rewiring Democracy,” we chronicle examples from around the globe of democracies using AI to make regulatory enforcement more efficient, catch tax cheats, speed up judicial processes, synthesize input from constituents to legislatures, and much more. Because democracies distribute power across institutions and individuals, making the right choices about how to shape AI and its uses requires both clarity and alignment across society.

To that end, we spotlight four pivotal choices facing private and public actors. These choices are similar to those we faced during the advent of social media, and in retrospect we can see that we made the wrong decisions back then. Our collective choices in 2025—choices made by tech CEOs, politicians, and citizens alike—may dictate whether AI is applied to positive and pro-democratic, or harmful and civically destructive, ends.

A Choice for the Executive and the Judiciary: Playing by the Rules

The Federal Election Commission (FEC) calls it fraud when a candidate hires an actor to impersonate their opponent. More recently, they had to decide whether doing the same thing with an AI deepfake makes it okay. (They concluded it does not.) Although in this case the FEC made the right decision, this is just one example of how AIs could skirt laws that govern people.

Likewise, courts are having to decide if and when it is okay for an AI to reuse creative materials without compensation or attribution, which might constitute plagiarism or copyright infringement if carried out by a human. (The court outcomes so far are mixed.) Courts are also adjudicating whether corporations are responsible for upholding promises made by AI customer service representatives. (In the case of Air Canada, the answer was yes, and insurers have started covering the liability.)

Social media companies faced many of the same hazards decades ago and have largely been shielded by the combination of Section 230 of the Communications Act of 1994 and the safe harbor offered by the Digital Millennium Copyright Act of 1998. Even in the absence of congressional action to strengthen or add rigor to this law, the Federal Communications Commission (FCC) and the Supreme Court could take action to enhance its effects and to clarify which humans are responsible when technology is used, in effect, to bypass existing law.

A Choice for Congress: Privacy

As AI-enabled products increasingly ask Americans to share yet more of their personal information—their “context“—to use digital services like personal assistants, safeguarding the interests of the American consumer should be a bipartisan cause in Congress.

It has been nearly 10 years since Europe adopted comprehensive data privacy regulation. Today, American companies exert massive efforts to limit data collection, acquire consent for use of data, and hold it confidential under significant financial penalties—but only for their customers and users in the EU.

Regardless, a decade later the U.S. has still failed to make progress on any serious attempts at comprehensive federal privacy legislation written for the 21st century, and there are precious few data privacy protections that apply to narrow slices of the economy and population. This inaction comes in spite of scandal after scandal regarding Big Tech corporations’ irresponsible and harmful use of our personal data: Oracle’s data profiling, Facebook and Cambridge Analytica, Google ignoring data privacy opt-out requests, and many more.

Privacy is just one side of the obligations AI companies should have with respect to our data; the other side is portability—that is, the ability for individuals to choose to migrate and share their data between consumer tools and technology systems. To the extent that knowing our personal context really does enable better and more personalized AI services, it’s critical that consumers have the ability to extract and migrate their personal context between AI solutions. Consumers should own their own data, and with that ownership should come explicit control over who and what platforms it is shared with, as well as withheld from. Regulators could mandate this interoperability. Otherwise, users are locked in and lack freedom of choice between competing AI solutions—much like the time invested to build a following on a social network has locked many users to those platforms.

A Choice for States: Taxing AI Companies

It has become increasingly clear that social media is not a town square in the utopian sense of an open and protected public forum where political ideas are distributed and debated in good faith. If anything, social media has coarsened and degraded our public discourse. Meanwhile, the sole act of Congress designed to substantially reign in the social and political effects of social media platforms—the TikTok ban, which aimed to protect the American public from Chinese influence and data collection, citing it as a national security threat—is one it seems to no longer even acknowledge.

While Congress has waffled, regulation in the U.S. is happening at the state level. Several states have limited children’s and teens’ access to social media. With Congress having rejected—for now—a threatened federal moratorium on state-level regulation of AI, California passed a new slate of AI regulations after mollifying a lobbying onslaught from industry opponents. Perhaps most interesting, Maryland has recently become the first in the nation to levy taxes on digital advertising platform companies.

States now face a choice of whether to apply a similar reparative tax to AI companies to recapture a fraction of the costs they externalize on the public to fund affected public services. State legislators concerned with the potential loss of jobs, cheating in schools, and harm to those with mental health concerns caused by AI have options to combat it. They could extract the funding needed to mitigate these harms to support public services—strengthening job training programs and public employment, public schools, public health services, even public media and technology.

A Choice for All of Us: What Products Do We Use, and How?

A pivotal moment in the social media timeline occurred in 2006, when Facebook opened its service to the public after years of catering to students of select universities. Millions quickly signed up for a free service where the only source of monetization was the extraction of their attention and personal data.

Today, about half of Americans are daily users of AI, mostly via free products from Facebook’s parent company Meta and a handful of other familiar Big Tech giants and venture-backed tech firms such as Google, Microsoft, OpenAI, and Anthropic—with every incentive to follow the same path as the social platforms.

But now, as then, there are alternatives. Some nonprofit initiatives are building open-source AI tools that have transparent foundations and can be run locally and under users’ control, like AllenAI and EleutherAI. Some governments, like Singapore, Indonesia, and Switzerland, are building public alternatives to corporate AI that don’t suffer from the perverse incentives introduced by the profit motive of private entities.

Just as social media users have faced platform choices with a range of value propositions and ideological valences—as diverse as X, Bluesky, and Mastodon—the same will increasingly be true of AI. Those of us who use AI products in our everyday lives as people, workers, and citizens may not have the same power as judges, lawmakers, and state officials. But we can play a small role in influencing the broader AI ecosystem by demonstrating interest in and usage of these alternatives to Big AI. If you’re a regular user of commercial AI apps, consider trying the free-to-use service for Switzerland’s public Apertus model.

None of these choices are really new. They were all present almost 20 years ago, as social media moved from niche to mainstream. They were all policy debates we did not have, choosing instead to view these technologies through rose-colored glasses. Today, though, we can choose a different path and realize a different future. It is critical that we intentionally navigate a path to a positive future for societal use of AI—before the consolidation of power renders it too late to do so.

This post was written with Nathan E. Sanders, and originally appeared in Lawfare.

Шест години по-късно. Изгуби ли културата в Пловдив своята посока?

Post Syndicated from Георги Велев original https://www.toest.bg/6-godini-po-kusno-izgubi-li-kulturata-v-plovdiv-svoyata-posoka/

Шест години по-късно. Изгуби ли културата в Пловдив своята посока?

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

Съживяване на културния живот в Пловдив

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

Шест години по-късно. Изгуби ли културата в Пловдив своята посока?
Част от изложбата „Дим. Истории на тютюна“ © Георги Велев

Един от реставрираните складове в Тютюневия град беше домакин на изложбата „Дим. Истории на тютюна“, която увлекателно представи историята на индустрията, формирала съществена част от облика на Пловдив в края на XIX и началото на XX век. Немалко жители на града вероятно влязоха в тютюнев склад за първи път и имаха възможност да видят отблизо високите тавани, дървените подове и автентичните метални елементи в интериора.

Фасадата на студентските общежития на Медицинския университет се превърна в поле за изява на впечатляваща вертикална хореография, дело на френския колектив La Compagnie Acte. В селата Бойково и Добралък в Родопите, познати основно като отправни точки за планински туризъм, Фондация „Открити пространства“ реализира проекта „Шепоти от родопски приказки“, който съчета различни артистични форми – работилници за разказване на истории, повлияни от местния фолклор, сетивен театър и преработка на традиционни песни.

Шест години по-късно. Изгуби ли културата в Пловдив своята посока?
Шест години по-късно. Изгуби ли културата в Пловдив своята посока?

Фестивал „Шепоти от родопски приказки“, с. Добралък © Георги Велев

Това бяха само три от събитията, които ми направиха силно впечатление през 2019 г.

Но в предишните години One Architecture Week, One Design Week, One Dance Week, Нощта на галериите и музеите, павилионът Fluca, Седмицата на съвременното изкуство, „Арт позитив“, „Капана фест“, Hills of Rock и множество други фестивали и събития очертаха трансформацията в артистичния облик на града. Критична маса икономисти, художници, писатели и културни мениджъри (като Богдан Русев и Георги Стоев) се преместиха да живеят в Пловдив. Доколкото именно активните хора създават културния облик на един град със своята енергия, ентусиазъм и нови инициативи, подемът беше осезаем.

Титлата „Европейска столица на културата“ донесе и целево финансиране от българската държава и Европейската комисия за инфраструктурни проекти, като реконструкцията на площад „Централен“ срещу 12 млн. лв., превръщането на някогашния „Детмаг“ в галерия „Капана“ за 1 млн. лв. и реконструкцията на галерията на Съюза на българските художници в галерия 2019. Към онзи момент Пловдив имаше огромна нужда от подобни инвестиции, тъй като поддръжката и обновяването на културната инфраструктура бяха неглижирани от поредица управници.

2025-та: усещане за застой

Превъртаме лентата шест години напред. В публичното пространство все по-често се чуват мнения, че възможността за утвърждаване на града като международен културен център в годините след 2019 г. е загубена. Част от иновативните фестивали, като One Architecture Week, One Design Week и Нощта на галериите и музеите, прекратиха съществуването си поради натрупаната умора в неправителствените организации, които ги изнасяха на плещите си. За тази умора допринесе и сблъсъкът с недалновидната политиката от страна на Общината, която се забърка в поредица от конфликти с някои от най-активните мениджъри на културно съдържание. Липсват нови събития, които да са насочени към визуални или сценични изкуства, а все по-често се набляга върху комерсиалните музикални форми. 

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

Емблематичен е случаят с произведението „Стената“ на утвърдената съвременна артистка Севдалина Кочевска.

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

Превръщането на Тютюневия град в артистичен квартал забуксува, тъй като част от собствениците предпочетоха на ръба на закона да съборят сградите, вместо да се захванат с бавния, скъп и тежък административен и строителен процес по възстановяването им в автентичен вид. Действията на Министерството на културата и Националния институт по недвижимо културно наследство по обявяване на складовете за недвижими културни ценности бяха изпреварени от т.нар. Планове за безопасност и здраве. Така евфемистично се наричат документите, с които Общината позволява унищожаването на ценните архитектурни образци от началото на XX в.

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

Река Марица продължава да се усеща като зона с пропилян потенциал,

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

Пловдив изглежда и се усеща като град, който не може да намери своя автентичен облик и посока. Наследството от 2019 г. се изразява основно в обявяване на ежегодни покани за организиране на събития от Фондация „Пловдив 2019“, които без съмнение са необходими за града, но ползват вече създадената инерция. Липсва ясна и конкретна цел за развитието на културата, която да сплоти администрацията, хората на изкуството, мултинационалните и местните компании и гражданите. Концепция, която да вдъхнови и да обедини, в синхрон с мотото „Заедно“.

Къде може да се намира Пловдив след десетилетие?

От интернет страницата на Община Пловдив разбираме, че времевата рамка на културната стратегия на града е изтекла преди почти година. Липсва инициатива за изработване на нов стратегически документ, необходим за поставянето на целите за следващото десетилетие. Подобна визия беше включена в Апликационната книга за кандидатстване за Европейска столица на културата през 2014 г.

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

Една бъдеща културна стратегия следва да е фокусирана и върху развитието на нови градски пространства,

които да предлагат възможност за провеждане на събития с различни теми и мащаб. Общината може да задели целеви средства, за да закупи банята „Орта мезар“, една от четирите най-стари оцелели сгради в Пловдив, чиято история се проследява до XV–XVI век, но за съжаление тъне в разруха от години, а части от нея са увредени от пожар. Трансформацията на постройката в галерия или в център за съвременно изкуство, ведно с облагородяването на принадлежащите зелени площи, визуално и пространствено би допълнила по подходящ начин наситената в исторически и културен план зона около Градската градина, Природонаучния музей и Дома на младоженците. 

Пешеходният мост е покрит с изключително грозна и неподходяща конструкция и приютява основно магазинчета за дрехи и обувки, които напомнят с бутафорния си облик софийския базар „Илиянци“ от средата на 90-те. Администрацията има възможност да инициира преговори с Българската банка за развитие, която е настоящ концесионер на съоръжението, и да придобие актива срещу сума от порядъка на 4–5 млн. лв. Върху част от пространството на моста би могло да се разположи кафене с панорамни гледки към река Марица, а останалото място е подходящо например за изложбени пана, временни скулптурни форми или провеждане на фестивали. 

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

Извън новите градски пространства, от които се нуждае Пловдив,

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

В унисон с намерението на Европейския съюз да постигне въглеродно неутрална икономика до 2050 г. са създадени наградите за Европейска зелена столица, като процесът на кандидатстване е отворен за всички градове с над 100 000 жители. Река Марица и тепетата са символите на Пловдив, които едновременно имат статус на природни забележителности и носят потенциал за разгръщане като места за реализация на проекти, свързани с културата и изкуството. Като южен град Пловдив е изложен на заплахи от промяната на климата – внезапни речни наводнения и екстремни летни горещини. Качествената поддръжка на зелените зони и облагородяването на крайречните пространства биха донесли както екологични ползи, така и възможности за създаване на изкуство, което вплита теми, свързани с опазването на околната среда. 

Както показва и примерът на Вилнюс, спечелил титлата „Европейска зелена столица“ за 2025 г.,

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

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

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

По едноименната книга на урбаниста Ян Геел, това е рубрика за добрите чужди (и не само) примери за градско управление или градоустройствено решение, които са променили средата в добра посока. Които са сложили човека в центъра на вниманието. По изключение даваме и примери за тъкмо обратното, но се надяваме, че добрите практики ще преобладават. Защото имаме нужда от позитивност и показвайки, че и иначе може, се надяваме да повлияем на взискателността и чувството за естетика у читателите.

От февруари 2021 г. в рубриката „Градове за хората“ се включват експерти от Съюза на урбанистите в България, а от декември 2024 г. – автори от „Екипът на София“.

Visualizing Target Relabeling Rules in Prometheus 3.8.0

Post Syndicated from Julius Volz (@juliusv) original https://prometheus.io/blog/2025/12/02/visualizing-target-relabeling-rules-in-the-prometheus-ui/

Prometheus’ target relabeling feature allows you to adjust the labels of a discovered target or even drop the target entirely. Relabeling rules, while powerful, can be hard to understand and debug. Your rules have to match the expected labels that your service discovery mechanism returns, and getting any step wrong could label your target incorrectly or accidentally drop it.

To help you figure out where things go wrong (or right), Prometheus 3.8.0 just added a relabeling visualizer to the Prometheus server’s web UI that allows you to inspect how each relabeling rule is applied to a discovered target’s labels. Let’s take a look at how it works!

Using the relabeling visualizer

If you head to any Prometheus server’s “Service discovery” page (for example: https://demo.promlabs.com/service-discovery), you will now see a new “show relabeling” button for each discovered target:

Service discovery page screenshot

Clicking this button shows you how each relabeling rule is applied to that particular target in sequence:

The visualizer shows you:

  • The initial labels of the target as discovered by the service discovery mechanism.
  • The details of each relabeling rule, including its action type and other parameters.
  • How the labels change after each relabeling rule is applied, with changes, additions, and deletions highlighted in color.
  • Whether the target is ultimately kept or dropped after all relabeling rules have been applied.
  • The final output labels of the target if it is kept.

To debug your relabeling rules, you can now read this diagram from top to bottom and find the exact step where the labels change in an unexpected way or where the target gets dropped. This should help you identify misconfigurations in your relabeling rules more easily.

Conclusion

The new relabeling visualizer in the Prometheus server’s web UI is a powerful tool to help you understand and debug your target relabeling configurations. By providing a step-by-step view of how each relabeling rule affects a target’s labels, it makes it easier to identify and fix issues in your setup. Update your Prometheus servers to 3.8.0 now to give it a try!

Decreasing Certificate Lifetimes to 45 Days

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2025/12/02/from-90-to-45.html

Let’s Encrypt will be reducing the validity period of the certificates we issue. We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028.

This change is being made along with the rest of the industry, as required by the CA/Browser Forum Baseline Requirements, which set the technical requirements that we must follow. All publicly-trusted Certificate Authorities like Let’s Encrypt will be making similar changes. Reducing how long certificates are valid for helps improve the security of the internet, by limiting the scope of compromise, and making certificate revocation technologies more efficient.

We are also reducing the authorization reuse period, which is the length of time after validating domain control that we allow certificates to be issued for that domain. It is currently 30 days, which will be reduced to 7 hours by 2028.

Timeline of Changes

To minimize disruption, Let’s Encrypt will roll this change out in multiple stages. We will use ACME Profiles to allow you control over when these changes take effect. They are configured in your ACME client. For more information, see our blog post announcing them.

Changes will be deployed to our staging environment approximately one month before the production dates below.

  • May 13, 2026: Let’s Encrypt will switch our tlsserver ACME profile to issue 45-day certificates. This profile is opt-in and can be used by early adopters and for testing.
  • February 10, 2027: Let’s Encrypt will switch our default classic ACME profile to issuing 64-day certificates with a 10-day authorization reuse period. This will affect all users who have not opted into the tlsserver or shortlived (6-day) profiles.
  • February 16, 2028: We will further update the classic profile to issue 45-day certificates with a 7 hour authorization reuse period.

These dates are when the change takes effect for new certificates, so Let’s Encrypt users will see the reduced certificate validity period at their next renewal after these dates.

Action Required

Most users of Let’s Encrypt who automatically issue certificates will not have to make any changes. However, you should verify that your automation is compatible with certificates that have shorter validity periods.

To ensure your ACME client renews on time, we recommend using ACME Renewal Information (ARI). ARI is a feature we’ve introduced to help clients know when they need to renew their certificates. Consult your ACME client’s documentation on how to enable ARI, as it differs from client to client. If you are a client developer, check out this integration guide.

If your client doesn’t support ARI yet, ensure it runs on a schedule that is compatible with 45-day certificates. For example, renewing at a hardcoded interval of 60 days will no longer be sufficient. Acceptable behavior includes renewing certificates at approximately two thirds of the way through the current certificate’s lifetime.

Manually renewing certificates is not recommended, as it will need to be done more frequently with shorter certificate lifetimes.

We also recommend that you make sure your systems have sufficient monitoring in place to alert appropriately if certificates aren’t renewed when expected. There are many available options, some of which are documented on our Monitoring Service Options page.

Making Automation Easier with a new DNS Challenge Type

For many of our users, the hardest part of automatically issuing certificates is proving domain control. Reducing certificate lifetimes and the authorization reuse period will make users need to demonstrate control more often.

All validation methods today require that the ACME client have live access to your infrastructure, either to serve the correct HTTP-01 token, perform the right TLS-ALPN-01 handshake, or update the right DNS-01 TXT record. For a long time, people have wanted a way to run an ACME client without granting it access to these sensitive systems.

These challenges are why we are working with our partners at the CA/Browser Forum and IETF to standardize a new validation method called DNS-PERSIST-01. The key advantage of this new method is that the DNS TXT entry used to demonstrate control does not have to change every renewal.

This means you can set up the DNS entry once and begin automatically renewing certificates without needing a way to automatically update DNS. This should allow even more people to automate their certificate renewals. It will also reduce reliance on authorization reuse, since the DNS records can stay unchanged without any further ACME client involvement.

We expect DNS-PERSIST-01 to be available in 2026, and will have more to announce soon.

Keep Up to Date

Additional updates, reminders, and other changes will be shared on our technical updates mailing list. Subscribe to keep up-to-date with these and all other upcoming changes. If you have any questions, please ask on our community forum. If you want to read more about the work happening at Let’s Encrypt and our other projects, check out our Annual Report, which was published today.

[$] Checked-size array parameters in C

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

There are many possible programmer mistakes that are not caught by the
minimal checks specified by the C language; among those is passing an array
of the wrong size to a function. A recent attempt to add some safety
around array parameters within the crypto layer involved the use of some
clever tricks, but it turns out that clever tricks are unnecessary in this
case. There is an obscure C feature that can cause this checking to
happen, and it is already in use in a few places within the kernel.

AWS Transform for mainframe introduces Reimagine capabilities and automated testing functionality

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/aws-transform-for-mainframe-introduces-reimagine-capabilities-and-automated-testing-functionality/

In May, 2025, we launched AWS Transform for mainframe, the first agentic AI service for modernizing mainframe workloads at scale. The AI-powered mainframe agent accelerates mainframe modernization by automating complex, resource-intensive tasks across every phase of modernization—from initial assessment to final deployment. You can streamline the migration of legacy mainframe applications, including COBOL, CICS, DB2, and VSAM to modern cloud environments—cutting modernization timelines from years to months.

Today, we’re announcing enhanced capabilities in AWS Transform for mainframe that include AI-powered analysis features, support for the Reimagine modernization pattern, and testing automation. These enhancements solve two critical challenges in mainframe modernization: the need to completely transform applications rather than merely move them to the cloud, and the extensive time and expertise required for testing.

  • Reimagining mainframe modernization – This is a new AI-driven approach that completely reimagines the customer’s application architecture using modern patterns or moving from batch process to real-time functions. By combining the enhanced business logic extraction with new data lineage analysis and automated data dictionary generation from the legacy source code through AWS Transform, customers transform monolithic mainframe applications written in languages like COBOL into more modern architectural styles, like microservices.
  • Automated testing – Customers can use new automated test plan generation, test data collection scripts, and test case automation scripts. AWS Transform for mainframe also provides functional testing tools for data migration, results validation, and terminal connectivity. These AI-powered capabilities work together to accelerate testing timelines and improve accuracy through automation.

Let’s learn more about reimagining mainframe modernization and automated testing capabilities.

How to reimagine mainframe modernization
We recognize that mainframe modernization is not a one-size-fits-all proposition. Whereas tactical approaches focus on augmentation and maintaining existing systems, strategic modernization offers distinct paths: Replatform, Refactor, Replace, or the new Reimagine.

In the Reimagine pattern, AWS Transform AI-powered analysis combines mainframe system analysis with organizational knowledge to create detailed business and technical documentation and architecture recommendations. This helps preserve critical business logic while enabling modern cloud-native capabilities.

AWS Transform provides new advanced data analysis capabilities that are essential for successful mainframe modernization, including data lineage analysis and automated data dictionary generation. These features work together to define the structure and meaning to accompany the usage and relationships of mainframe data. Customers gain complete visibility into their data landscape, enabling informed decision-making for modernization. Their technical teams can confidently redesign data architectures while preserving critical business logic and relationships.

The Reimagining strategy follows the principle of human in the loop validation, which means that AI-generated application specifications and code such as AWS Transform and Kiro are continuously validated by domain experts. This collaborative approach between AI capabilities and human judgment significantly reduces transformation risk while maintaining the speed advantages of AI-powered modernization.

The pathway has a three-phase methodology to transform legacy mainframe applications into cloud-native microservices:

  • Reverse engineering to extract business logic and rules from existing COBOL or job control language (JCL) code using AWS Transform for mainframe.
  • Forward engineering to generate microservice specification, modernized source code, infrastructure as code (IaC), and modernized database.
  • Deploy and test to deploy the generated microservices to Amazon Web Services (AWS) using IaC and to test the functionality of the modernized application.

Although microservices architecture offers significant benefits for mainframe modernization, it’s crucial to understand that it’s not the best solution for every scenario. The choice of architectural patterns should be driven by the specific requirements and constraints of the system. The key is to select an architecture that aligns with both current needs and future aspirations, recognizing that architectural decisions can evolve over time as organizations mature their cloud-native capabilities.

The flexible approach supports both do-it-yourself and partner-led development, so you can use your preferred tools while maintaining the integrity of your business processes. You get the benefits of modern cloud architecture while preserving decades of business logic and reducing project risk.

Automated testing in action
The new automated testing feature supports IBM z/OS mainframe batch application stack at launch, which helps organizations address a wider range of modernization scenarios while maintaining consistent processes and tooling.

Here are the new mainframe capabilities:

  • Plan test cases – Create test plans from mainframe code, business logic, and scheduler plans.
  • Generate test data collection scripts – Create JCL scripts for data collection from your mainframe to your test plan.
  • Generate test automation scripts – Generate execution scripts to automate testing of modernized applications running in the target AWS environment.

To get started with automated testing, you should set up a workspace, assign a specific role to each user, and invite them to onboard your workspace. To learn more, visit Getting started with AWS Transform in the AWS Transform User Guide.

Choose Create job in your workspace. You can see all types of supported transformation jobs. For this example, I select the Mainframe Modernization job to modernize mainframe applications.

After a new job is created, you can kick off modernization for tests generation. This workflow is sequential and it is a place for you to answer the AI agent’s questions, providing the necessary input. You can add your collaborators and specify resource location where the codebase or documentation is located in your Amazon Simple Storage Service (Amazon S3) bucket.

I use a sample application for a credit card management system as the mainframe banking case with the presentation (BMS screens), business logic (COBOL) and data (VSAM/DB2), including online transaction processing and batch jobs.

After finishing the steps of analyzing code, extracting business logic, decomposing code, planning migration wave, you can experience new automated testing capabilities such as planning test cases, generating test data collection scripts, and test automation scripts.

The new testing workflow creates a test plan for your modernization project and generates test data collection scripts. You will have three planning steps:

  • Configure test plan inputs – You can link your test plan to your other job files. The test plan is generated based on analyzing the mainframe application code and can provide more details optionally using the extracted business logic, the technical documentation, the decomposition, and using a scheduler plan.
  • Define test plan scope – You can define the entry point, the specific program where the application’s execution flow begins. For example, the JCL for a batch job. In the test plan, each functional test case is designed to start the execution from a specific entry point.
  • Refine test plan – A test plan is made up of sequential test cases. You can reorder them, add new ones, merge multiple cases, or split one into two on the test case detail page. Batch test cases are composed of a sequence of JCLs following the scheduler plan.

Generating test data collection scripts collects test data from mainframe applications for functional equivalence testing. This step actively generates JCL scripts that will help you gather test data from the sample application’s various data sources (such as VSAM files or DB2 databases) for use in testing the modernized application. The step is designed to create automated scripts that can extract test data from VSAM datasets, query DB2 tables for sample data, collect sequential data sets, and generate data collection workflows. After this step is completed, you’ll have comprehensive test data collection scripts ready to use.

To learn more about automated testing, visit Modernization of mainframe applications in the AWS Transform User Guide.

Now available
The new capabilities in AWS Transform for mainframe are available today in all AWS Regions where AWS Transform for mainframe is offered. For Regional availability and future roadmap, visit the AWS Capabilities by Region. Currently, we offer our core features—including assessment and transformation—at no cost to AWS customers. To learn more, visit AWS Transform Pricing page.

Give it a try in the AWS Transform console. To learn more, visit the AWS Transform for mainframe product page and send feedback to AWS re:Post for AWS Transform for mainframe or through your usual AWS Support contacts.

— Channy

AWS Transform announces full-stack Windows modernization capabilities

Post Syndicated from Prasad Rao original https://aws.amazon.com/blogs/aws/aws-transform-announces-full-stack-windows-modernization-capabilities/

Earlier this year in May, we announced the general availability of AWS Transform for .NET, the first agentic AI service for modernizing .NET applications at scale. During the early adoption period of the service, we received valuable feedback indicating that, in addition to .NET application modernization, you would like to modernize SQL Server and legacy UI frameworks. Your applications typically follow a three-tier architecture—presentation tier, application tier, and database tier—and you need a comprehensive solution that can transform all of these tiers in a coordinated way.

Today, based on your feedback, we’re excited to announce AWS Transform for full-stack Windows modernization, to offload complex, tedious modernization work across the Windows application stack. You can now identify application and database dependencies and modernize them in an orchestrated way through a centralized experience.

AWS Transform accelerates full-stack Windows modernization by up to five times across application, UI, database, and deployment layers. Along with porting .NET Framework applications to cross-platform .NET, it migrates SQL Server databases to Amazon Aurora PostgreSQL-Compatible Edition with intelligent stored procedure conversion and dependent application code refactoring. For validation and testing, AWS Transform deploys applications to Amazon Elastic Compute Cloud (Amazon EC2) Linux or Amazon Elastic Container Service (Amazon ECS), and provides customizable AWS CloudFormation templates and deployment configurations for production use. AWS Transform has also added capabilities to modernize ASP.NET Web Forms UI to Blazor.

There is much to explore, so in this post I’ll provide the first look at AWS Transform for full-stack Windows modernization capabilities across all layers.

Create a full-stack Windows modernization transformation job
AWS Transform connects to your source code repositories and database servers, analyzes application and database dependencies, creates modernization waves, and orchestrates full-stack transformations for each wave.

To get started with AWS Transform, I first complete the onboarding steps outlined in the getting started with AWS Transform user guide. After onboarding, I sign in to the AWS Transform console using my credentials and create a job for full-stack Windows modernization.

Create a new job for Windows Modernization
Create a new job by choosing SQL Server Database Modernization

After creating the job, I complete the prerequisites. Then, I configure the database connector for AWS Transform to securely access SQL Server databases running on Amazon EC2 and Amazon Relational Database Service (Amazon RDS). The connector can connect to multiple databases within the same SQL Server instance.

Create new database connector by adding connector name and AWS Account ID

Next, I set up a connector to connect to my source code repositories.

Add a source code connector by adding Connection name, AWS Account ID and Code Connector Arn

Furthermore, I have the option to choose if I would like AWS Transform to deploy the transformed applications. I choose Yes and provide the target AWS account ID and AWS Region for deploying the applications. The deployment option can be configured later as well.

Choose if you would like to deploy transformed apps

After the connectors are set up, AWS Transform connects to the resources and runs the validation to verify IAM roles, network settings, and related AWS resources.

After the successful validation, AWS Transform discovers databases and their associated source code repositories. It identifies dependencies between databases and applications to create waves for transforming related components together. Based on this analysis, AWS Transform creates a wave-based transformation plan.

Start assessment for discovered database and source code repositories

Assessing database and dependent applications
For the assessment, I review the databases and source code repositories discovered by AWS Transform and choose the appropriate branches for code repositories. AWS Transform scans these databases and source code repositories, then presents a list of databases along with their dependent .NET applications and transformation complexity.

Start wave planning of asessed databases and dependent repositories

I choose the target databases and repositories for modernization. AWS Transform analyzes these selections and generates a comprehensive SQL Modernization Assessment Report with a detailed wave plan. I download the report to review the proposed modernization plan. The report includes an executive summary, wave plan, dependencies between databases and code repositories, and complexity analysis.

View SQL Modernization Assessment Report

Wave transformation at scale
The wave plan generated by AWS Transform consists of four steps for each wave. First, it converts the SQL Server schema to PostgreSQL. Second, it migrates the data. Third, it transforms the dependent .NET application code to make it PostgreSQL compatible. Finally, it deploys the application for testing.

Before converting the SQL Server schema, I can either create a new PostgreSQL database or choose an existing one as the target database.

Choose or create target database

After I choose the source and target databases, AWS Transform generates conversion reports for my review. AWS Transform converts the SQL Server schema to PostgreSQL-compatible structures, including tables, indexes, constraints, and stored procedures.

Download Schema conversion reports

For any schema that AWS Transform can’t automatically convert, I can manually address them in the AWS Database Migration Service (AWS DMS) console. Alternatively, I can fix them in my preferred SQL editor and update the target database instance.

After completing schema conversion, I have the option to proceed with data migration, which is an optional step. AWS Transform uses AWS DMS to migrate data from my SQL Server instance to the PostgreSQL database instance. I can choose to perform data migration later, after completing all transformations, or work with test data by loading it into my target database.

Choose if you would like to migrate data

The next step is code transformation. I specify a target branch for AWS Transform to upload the transformed code artifacts. AWS Transform updates the codebase to make the application compatible with the converted PostgreSQL database.

Specify target branch destination for transformed codebase

With this release, AWS Transform for full-stack Windows modernization supports only codebases in .NET 6 or later. For codebases in .NET Framework 3.1+, I first use AWS Transform for .NET to port them to cross-platform .NET. I’ll expand on this in a following section.

After the conversion is completed, I can view the source and target branches along with their code transformation status. I can also download and review the transformation report.

Download transformation report

Modernizing .NET Framework applications with UI layer
One major feature we’re releasing today is the modernization of UI frameworks from ASP.NET Web Forms to Blazor. This is added to existing support for modernizing model-view-controller (MVC) Razor views to ASP.NET Core Razor views.

As mentioned previously, if I have a .NET application in legacy .NET Framework, then I continue using AWS Transform for .NET to port it to cross-platform .NET. For legacy applications with UIs built on ASP.NET Web Forms, AWS Transform now modernizes the UI layer to Blazor along with porting the backend code.

AWS Transform for .NET converts ASP.NET Web Forms projects to Blazor on ASP.NET Core, facilitating the migration of ASP.NET websites to Linux. The UI modernization feature is enabled by default in AWS Transform for .NET on both the AWS Transform web console and Visual Studio extension.

During the modernization process, AWS Transform handles the conversion of ASPX pages, ASCX custom controls, and code-behind files, implementing them as server-side Blazor components rather than web assembly. The following project and file changes are made during the transformation:

From To Description
*.aspx, *.ascx *.razor .aspx pages and .ascx custom controls become .razor files
Web.config appsettings.json Web.config settings become appsettings.json settings
Global.asax Program.cs Global .asax code becomes Program.cs code
*.master *layout.razor Master files become layout.razor files

Image showcasing how the specific project files are transformed

Other new features in AWS Transform for .NET
Along with UI porting, AWS Transform for .NET has added support for more transformation capabilities and enhanced developer experience. These new features include the following:

  • Port to .NET 10 and .NET Standard – AWS Transform now supports porting to .NET 10, the latest Long-Term Support (LTS) release, which was released on November 11, 2025. It also supports porting class libraries to .NET Standard, a formal specification for a set of APIs that are common across all .NET implementations. Furthermore, AWS Transform is now available with AWS Toolkit for Visual Studio 2026.
  • Editable transformation report – After the assessment is complete, you can now view and customize the transformation plan based on your specific requirements and preferences. For example, you can update package replacement details.
  • Real-time transformation updates with estimated remaining time – Depending on the size and complexity of the codebase, AWS Transform can take some time to complete the porting. You can now track transformation updates in real-time along with the estimated remaining time.
  • Next steps markdown – After the transformation is complete, AWS Transform now generates a next steps markdown file with the remaining tasks to complete the porting. You can use this as a revised plan to repeat the transformation with AWS Transform or use AI code-companions to complete the porting.

Things to know
Some more things to know are:

  • AWS Regions – AWS Transform for full-stack Windows modernization is generally available today in the US East (N. Virginia) Region. For Regional availability and future roadmap, visit the AWS Capabilities by Region.
  • Pricing – Currently, there is no added charge for Windows modernization features of AWS Transform. Any resources you create or continue to use in your AWS account using the output of AWS Transform are billed according to their standard pricing. For limits and quotas, refer to the AWS Transform User Guide.
  • SQL Server versions supported – AWS Transform supports the transformation of SQL Server versions from 2008 R2 through 2022, including all editions (Express, Standard, and Enterprise). SQL Server must be hosted on Amazon RDS or Amazon EC2 in the same Region as AWS Transform.
  • Entity Framework versions supported – AWS Transform supports the modernization of Entity Framework versions 6.3 through 6.5 and Entity Framework Core 1.0 through 8.0.
  • Getting started – To get started, visit AWS Transform for full-stack Windows modernization User Guide.

– Prasad

Introducing AWS Transform custom: Crush tech debt with AI-powered code modernization

Post Syndicated from Matheus Guimaraes original https://aws.amazon.com/blogs/aws/introducing-aws-transform-custom-crush-tech-debt-with-ai-powered-code-modernization/

Technical debt is one of the most persistent challenges facing enterprise development teams today. Studies show that organizations spend 20% of their IT budget on technical debt instead of advancing new capabilities. Whether it’s upgrading legacy frameworks, migrating to newer runtime versions, or refactoring outdated code patterns, these essential but repetitive tasks consume valuable developer time that could be spent on innovation.

Today, we’re excited to announce AWS Transform custom, a new agent that fundamentally changes how organizations approach modernization at scale. This intelligent agent combines pre-built transformations for Java, Node.js, and Python upgrades with the ability to define custom transformations. By learning specific transformation patterns and automating them across entire codebases, customers using AWS Transform custom have achieved up to 80% reduction in execution time in many cases, freeing developers to focus on innovation.

You can define transformations using your documentation, natural language descriptions, and code samples. The service then applies these specific patterns consistently across hundreds or thousands of repositories, improving its effectiveness through both explicit feedback and implicit signals like developers’ manual fixes within your transformation projects.

AWS Transform custom offers both CLI and web interfaces to suit different modernization needs. You can use the CLI to define transformations through natural language interactions and execute them on local codebases, either interactively or autonomously. You can also integrate it into code modernization pipelines or workflows, making it ideal for machine-driven automation. Meanwhile, the web interface provides comprehensive campaign management capabilities, helping teams track and coordinate transformation progress across multiple repositories at scale.

Language and framework modernization
AWS Transform supports runtime upgrades without the need to provide additional information, understanding not only the syntax changes required but also the subtle behavioral differences and optimization opportunities that come with newer versions. The same intelligent approach applies to Node.js, Python and Java runtime upgrades, and even extends to infrastructure-level transitions, such as migrating workloads from x86 processors to AWS Graviton.

It also navigates framework modernization with sophistication. When organizations need to update their Spring Boot applications to take advantage of newer features and security patches, AWS Transform custom doesn’t merely update version numbers but understands the cascading effects of dependency changes, configuration updates, and API modifications.

For teams facing more dramatic shifts, such as migrating from Angular to React, AWS Transform custom can learn the patterns of component translation, state management conversion, and routing logic transformation that make such migrations successful.

Infrastructure and enterprise-scale transformations
The challenge of keeping up with evolving APIs and SDKs becomes particularly acute in cloud-based environments where services are continuously improving. AWS Transform custom supports AWS SDK updates across a broad spectrum of programming languages that enterprises use including Java, Python, and JavaScript. The service understands not only the mechanical aspects of API changes, but also recognizes best practices and optimization opportunities available in newer SDK versions.

Infrastructure as Code transformations represent another critical capability, especially as organizations evaluate different tooling strategies. Whether you’re converting AWS Cloud Development Kit (AWS CDK) templates to Terraform for standardization purposes, or updating AWS CloudFormation configurations to access new service features, AWS Transform custom understands the declarative nature of these tools and can maintain the intent and structure of your infrastructure definitions.

Beyond these common scenarios, AWS Transform custom excels at addressing the unique, organization-specific code patterns that accumulate over years of development. Every enterprise has its own architectural conventions, utility libraries, and coding standards that need to evolve over time. It can learn these custom patterns and help refactor them systematically so that institutional knowledge and best practices are applied consistently across the entire application portfolio.

AWS Transform custom is designed with enterprise development workflows in mind, enabling center of excellence teams and system integrators to define and execute organization-wide transformations while application developers focus on reviewing and integrating the transformed code. DevOps engineers can then configure integrations with existing continuous integration and continuous delivery (CI/CD) pipelines and source control systems. It also includes pre-built transformations for Java, Node.js and Python runtime updates which can be particularly useful for AWS Lambda functions, along with transformations for AWS SDK modernization to help teams get started immediately.

Getting started
AWS Transform makes complex code transformations manageable through both pre-built and custom transformation capabilities. Let’s start by exploring how to use an existing transformation to address a common modernization challenge: upgrading AWS Lambda functions due to end-of-life (EOL) runtime support.

For this example, I’ll demonstrate migrating a Python 3.8 Lambda function to Python 3.13, as Python 3.8 reached EOL and is no longer receiving security updates. I’ll use the CLI for this demo, but I encourage you to also explore the web interface’s powerful campaign management capabilities.

First, I use the command atx custom def list to explore the available transformation definitions. You can also access this functionality through a conversational interface by typing only atx instead of issuing the command directly, if you prefer.

This command displays all available transformations, including both AWS-managed defaults and any existing custom transformations created by users in my organization. AWS-managed transformations are identified by the AWS/ prefix, indicating they’re maintained and updated by AWS. In the results, I can see several options such as AWS/java-version-upgrade for Java runtime modernization, AWS/python-boto2-to-boto3-migration for updating Python AWS SDK usage, AWS/nodejs-version-upgrade for Node.js runtime updates.

For my Python 3.8 to 3.13 migration, I’ll use the AWS/python-version-upgrade transformation.

You run a migration by using the atx custom def exec command.  Please consult the documentation for more details about the command and all its options. Here, I run it against my project repository specifying the transformation name. I also add pytest to run unit tests for validation. More importantly, I use the additionalPlanContext section in the  --configuration input to specify which Python version I want to upgrade to. For reference, here’s the command I have for my demo (I’ve used multiple lines and indented it here for clarity):

atx custom def exec 
-p /mnt/c/Users/vasudeve/Documents/Work/Projects/ATX/lambda/todoapilambda 
-n AWS/python-version-upgrade
-C "pytest" 
--configuration 
    "additionalPlanContext= The target Python version to upgrade to is Python 3.13" 
-x -t

AWS Transform then starts the migration process. It analyzes my Lambda function code, identifies Python 3.8-specific patterns, and automatically applies the necessary changes for Python 3.13 compatibility. This includes updating syntax for deprecated features, modifying import statements, and adjusting any version-specific behaviors.

After execution, it provides a comprehensive summary including a report on dependencies updated in requirements.txt with Python 3.13-compatible package versions, instances of deprecated syntax replaced with current equivalents, updated runtime configuration notes for AWS Lambda deployment, suggested test cases to validate the migration, and more. It also provides a body of evidence that serve as proof of success.

The migrated code lives in a local branch so you can review and merge when satisfied. Alternatively, you can keep providing feedback and reiterating until yo’re happy that the migration is fully complete and meets your expectations.

This automated process changes what would typically require hours of manual work into a streamlined, consistent upgrade that maintains code quality while maintaining compatibility with the newer Python runtime.

Creating a new custom transformation
While AWS-managed transformations handle common scenarios effectively, you can also create custom transformations tailored to your organization’s specific needs. Let’s explore how to create a custom transformation to see how AWS Transform learns from your specific requirements.

I type atx to initialize the atx cli and start the process.

The first thing it asks me is if I want to use one of the existing transformations or create a new one. I choose to create a new one. Notice that from here on the whole conversation takes place using natural language, not commands. I typed new one but I could have typed I want to create a new one and it would’ve understood it exactly the same.

It then prompts me to provide more information about the kind of transformation I’d like to perform. For this demo, I’m going to migrate an Angular application, so I type angular 16 to 19 application migration which prompts the CLI to search for all transformations available for this type of migration. In my case, my team has already created and made available a few Angular migrations, so it shows me those. However, it warns me that none of them is an exact match to my specific request for migrating from Angular 16 to 19. It then asks if I’d like to select from one of the existing transformations listed or create a custom one.

I choose to create a custom one by continuing to use natural language and typing create a new one as a command. Again, this could be any variation of that statement provided that you indicate your intentions clearly. It follows by asking me a few questions including whether I have any useful documentation, example code or migration guides that I can provide to help customize the transformation plan.

For this demo, I’m only going to rely on AWS Transform to provide me with good defaults. I type I don't have these details. Follow best practices. and the CLI responds by telling me that it will create a comprehensive transformation definition for migrating Angular 16 to Angular 19.  Of course, I relied on the pre-trained data to generate results based on best practices. As usual, the recommendation is to provide as much information and relevant data as possible at this stage of the process for better results. However, you don’t need to have all the data upfront. You can keep on providing data at any time› as you iterate through the process of creating the custom transformation definition.

The transformation definition is generated as a markup file containing a summary and a comprehensive sequence of implementation steps grouped logically into phases such as premigration preparation, processing and partitioning, static dependency analysis, searching and applying specific transformation rules, and step-by-step migration and iterative validation.

It’s interesting to see that AWS Transform opted for the best practice of doing incremental framework updates creating steps for migrating the application first to 17 then 18 then 19 instead of trying to go directly from 16 to 19 to minimize issues.

Note that the plan includes various stages of testing and verification to confirm that the various phases can be concluded with confidence. At the very end, it also includes a final validation stage listing exit criteria that performs a comprehensive set of tests against all aspects of the application that will be used to accept the migration as successfully complete.

After the transformation definition is created, AWS Transform asks me about what I would like to do next. I can choose to review or modify the transformation definition and I can reiterate through this process as much as I need until I arrive at one that I’m satisfied with. I can also choose to already apply this transformation definition to an Angular codebase. However, first I want to make this transformation available to my team members as well as myself so we can all use it again in the future. So, I choose option 4 to publish this transformation to the registry.

This custom transformation needs a name and a description of its objective which is displayed when users browse the registry. AWS Transforms automatically extracts those from context for me and asks me if I would like to modify them before going ahead. I like the sensible default of “Angular-16-to-19-Migration”, and the objective is clearly stated, so I choose to accept the suggestions and publish it by answering with yes, looks good.

Now that the transformation definition is created and published, I can use it and run it multiple times against any code repository. Let’s apply the transformation to a code repository with a project written in Angular 16. I now choose option 1 from the follow-up prompt and the CLI asks me for the path in my file system to the application that I want to migrate and, optionally, the build command that it should use.

After I provide that information, AWS Transform proceeds to analyze the code base and formulate a thorough step-by-step transformation plan based on the definition created earlier. After it’s done, it creates a JSON file containing the detailed migration plan specifically designed for applying our transformation definition to this code base. Similar to the process of creating the transformation definition, you can review and iterate through this plan as much as you need, providing it with feedback and adjusting it to any specific requirements you might have.

When I’m ready to accept the plan, I can use natural language to tell AWS Transform that we can start the migration process. I type looks good, proceed and watch the progress in my shell as it starts executing the plan and making the changes to my code base one step at a time.

The time it takes will vary depending on the complexity of the application. In my case, it took a few minutes to complete. After it has finished, it provides me with a transformation summary and the status of each one of the exit criteria that were included in the final verification phase of the plan alongside all the evidence to support the reported status. For example, the Application Build – Production criteria was listed as passed and some of the evidence provided included the incremental Git commits, the time that it took to complete the production build, the bundle size, the build output message, and the details about all the output files created.

Conclusion
AWS Transform represents a fundamental shift in how organizations approach code modernization and technical debt. The service helps to transform what was at one time a fragmented, team-by-team effort into a unified, intelligent capability that eliminates knowledge silos, keeping your best practices and institutional knowledge available as scalable assets across the entire organization. This helps to accelerate modernization initiatives while freeing developers to spend more time on innovation and driving business value instead of focusing on repetitive maintenance and modernization tasks.

Things to know

AWS Transform custom is now generally available. Visit the get started guide to start your first transformation campaign or check out the documentation to learn more about setting up custom transformation definitions.

The collective thoughts of the interwebz