Team IT Security - 📰 Alle Kategorien

Security: Mangelnde Rechteprüfung in terraform-provider-susepubliccloud (SUSE)

Sat, 25 Jul 2026 07:17:46 +0200

Security: Mehrere Probleme in terraform-provid, terraform-provider-aws, terraform-provider-azurerm, terraform-provider-external, terraform-provider-google, terraform-provider-helm und terraform-provider-kubernetes (SUSE)

Fri, 24 Jul 2026 18:47:24 +0200

Security: Mehrere Probleme in terraform-provider-susepubliccloud (SUSE)

Fri, 24 Jul 2026 18:32:31 +0200

Release v1.171.0

Thu, 23 Jul 2026 01:20:41 +0200

1.171.0 - 2026-07-22

### Added

Added support for the OpenTofu .tofu file extension. Because OpenTofu uses the same HCL grammar as Terraform, .tofu files are now automatically detected and scanned as Terraform, so they are picked up by recursive scans and Terraform rulesets (e.g. p/terraform) with no extra configuration. (ENGINE-2884)

### Changed

The window for collecting git contributor information during semgrep ci has been extended from the last 30 days to the last 90 days, to match the updated usage policy. (contributor-window-90-days)

### Fixed

Fixed a source of rare, nondeterministic crashes and incorrect results caused
by an OCaml compiler bug. Semgrep now builds against a compiler fork that
backports the upstream fix. (ocaml_codegen_fix)
Fixed excessive heap growth after explicit major garbage collections. Semgrep
now builds against an OCaml compiler that improves garbage collection duty
cycle pacing. (ocaml_gc_pacing_fix)
Improved the Scan Status output when no code rules will run (e.g. a
Secrets-only or Supply-Chain-only scan). The summary line no longer reports a
confusing "0 Code rules", and the "Code Rules" section now states explicitly
either that code scanning is not enabled or that there are no code rules to run,
instead of printing an empty table. (ENGINE-2878)
Fixed lockfileless Gradle dependency resolution failing with "Parsing
dependency output failed (Resolve_gradle.gradle_resolved_dependency)". The
github-dependency-graph-gradle-plugin used during resolution was fetched
unpinned, and its 1.4.2 release renamed keys in its JSON output. The plugin is
now pinned to 1.4.1. (sc-3738)

What’s New in Rapid7 Products and Services: Q2 2026 in Review

Wed, 22 Jul 2026 16:30:13 +0200

If Q1 set the pace for Rapid7's tools, Q2 accelerated it. This quarter brought a steady stream of product enhancements, platform investments, and customer-driven innovation across Rapid7’s portfolio. Each release was designed with a clear goal in mind: helping security teams reduce complexity while increasing speed, context, and confidence in their day-to-day operations. Here’s a closer look at what launched in Q2.

Detection and response

Streamline investigations with bidirectional and enriched Microsoft Defender alerts

Bidirectional synchronization and enriched alert context for Microsoft Defender is now generally available for SIEM and MDR customers, enabling security teams to automatically synchronize alert status between Rapid7's SIEM and the Microsoft Defender console. With added process tree and user identity context, analysts can investigate threats more efficiently while reducing manual effort.

Confidently scale detection engineering with Detection as Code

Detection as Code enables security teams to build, test, version, and deploy detections using Terraform and modern engineering workflows. Built-in validation, guardrails, and version control help teams deliver higher-quality alerts, maintain more consistent coverage, and scale detection engineering more effectively.

Figure 1: Rapid7's Detection as Code methodology.

Strengthen ransomware resilience with Ransomware Prevention for Incident Command

Ransomware Prevention for Incident Command adds an intent-based layer of protection designed to stop ransomware encryption and endpoint damage before they disrupt operations. Built into the Insight Agent, this capability strengthens ransomware resilience while working alongside existing endpoint security investments, without adding operational complexity.

Compliance

New solutions webpages

Across the globe, cybersecurity regulation is shifting away from static compliance checklists and toward ongoing risk management that blends proactive defense with effective detection and response. Rapid7’s platform, which brings exposure management and CTEM together with detection, response, and MDR, is well positioned to help organizations operationalize compliance across mandates such as NIS2, NIST CSF 2.0, DORA, HIPAA, HITRUST, and GovRAMP. To support that effort, Rapid7 has launched an updated library of dedicated compliance solution pages that map platform capabilities to the requirements that matter most across industries and regions. The first set of pages is live now, with more to follow in the coming weeks.

Figure 2: Rapid7's new GovRAMP compliance solutions page.

Exposure management

Turn prioritized exposures into remediation progress

We improved Remediation Hub to help teams turn prioritized exposures into more actionable remediation progress. Updates to the Top Remediations Report add asset-level context, including operating system, IP address, cloud provider, tags, endpoint protection, and patch management details, so teams can better understand what needs to be fixed and who needs to act.

With clearer patch and endpoint coverage signals, reboot status, customizable filters, exportable reports, and scheduled email delivery, teams can spend less time assembling manual updates and more time tracking the remediation work that reduces risk. Read the full blog to learn more about how Exposure Command helps teams move from prioritized exposures to remediation progress.

AI pre-triage for AppSec findings

Rapid7 is also making application security testing faster and more focused with AI vulnerability pre-triaging for InsightAppSec. Available now for AppSec customers in supported regions, the capability uses AI to automatically remove false positives during the scan process, helping teams spend less time manually reviewing findings and more time remediating actual risk.

Initial coverage started with BlindSQL, and the latest engine release adds AI validation for BlindNoSQL findings, including content-based and timing-based detections. The result is a cleaner, more confident view of application risk, so security teams can focus on high-impact vulnerabilities and accelerate remediation with less manual effort.

Attack surface management

Open-source MCP Server and Agent Skill

We are delighted to announce the introduction of a free, open-source MCP Server and Agent Skill for Bulk Export. Bulk export is a highly efficient way to access all your Rapid7 vulnerability and exposure data to AI assistants and custom AI workflows. Built as an open-source bridge, it helps customers bring their Rapid7 data into the tools and experiences that work best for their teams. Check out our blog for more detail.

Figure 3: Agent Skill for Bulk Export.

Turn exposure filters into live dashboards

Surface Command also made exposure reporting easier with filter-based dashboard widgets. Teams can now turn saved asset and identity filters into live dashboards without writing Cypher queries, making it faster to track high-risk internet-facing assets, identity-driven exposure hotspots, unmanaged cloud infrastructure, and business-unit risk.

For continuous threat exposure management programs, this helps teams move from one-off reporting to repeatable, always-on views of exposure risk and remediation progress. Read this blog to learn more.

Platform and Labs

Rapid7 Command Platform

Cyber GRC

Rapid7 introduced Cyber GRC to select customers in Q2, giving teams an early look at a new way to connect security, risk, compliance, and third-party risk management in one program. Available to both Exposure Management and Detection and Response customers, Cyber GRC brings governance and compliance workflows closer to the security data teams already use every day.

Cyber GRC will be broadly available in late July. It helps organizations move toward continuous compliance by mapping controls to real environment telemetry, automating evidence collection, and prioritizing risk with live attack surface context. That means teams can spend less time chasing audit artifacts, screenshots, and vendor risk details, and more time understanding which controls, assets, third parties, and risks need attention now.

Rapid7 Labs

Rapid7 Quarterly Threat Landscape Report

The Rapid7 Quarterly Threat Landscape Report examines the key trends shaping today's threat landscape, drawing on MDR incident response, vulnerability intelligence, ransomware monitoring, and dark web telemetry. Q1 2026 data highlights the growing dominance of vulnerability exploitation as an initial access vector, the rise of zero-click vulnerabilities, evolving ransomware operations, and the accelerating pace at which attackers operationalize newly disclosed vulnerabilities. Read the report to explore all key findings and takeaways.

Figure 4: Rapid7's quarterly threat report.

The latest threat research

Rapid7 researchers explored emerging trends shaping the threat landscape, including the growing commercialization of criminal AI-as-a-Service and the evolving tradecraft of advanced threat actors. From the underground adoption of AI tools for fraud and social engineering to an in-depth analysis of the Dropping Elephant malware campaign, these reports provide actionable intelligence on how attackers are adapting their techniques and what defenders can do to stay ahead.

Emergent Threat Response

This quarter's Emergent Threat Response (ETR) coverage highlights a sustained wave of high-impact vulnerabilities affecting widely deployed enterprise technologies, including Oracle PeopleSoft, Palo Alto Networks PAN-OS, Check Point VPN, Ivanti Sentry, cPanel/WHM, and Nginx UI. For each of these CVEs, Rapid7 tracked active exploitation and rapidly evolving attacker activity to provide timely guidance to help defenders assess risk and respond quickly. See all the details, and our latest ETR coverage, here.

From strengthening detection and response to advancing exposure management, expanding governance capabilities, and delivering actionable threat intelligence, Q2 demonstrated Rapid7’s continued focus on helping security teams do more with less complexity. Every enhancement this quarter was designed to reduce manual effort, surface the context that matters, and help organizations make faster, more confident security decisions. We’re carrying that momentum into the rest of the year, so stay tuned to our blog and releases as we continue building the security operations platform that helps defenders stay ahead of what’s next.

Security Is a Platform Property, Not a Pipeline Step

Mon, 20 Jul 2026 18:59:48 +0200

A few weeks ago, I disabled key authentication on an Azure storage account we used for Terraform state management. It was one of the key security recommendations in Microsoft Defender for Cloud. It made sense to use RBAC-only permissions, enforce…

The post Security Is a Platform Property, Not a Pipeline Step appeared first on IT Security News.

v0.386.0

Mon, 13 Jul 2026 18:35:24 +0200

What's Changed

Capture offending gem details on bundler registry metadata errors by @kbukum1 in #15512
Bundler: apply empty-checksum metadata patch to the v2 helper by @kbukum1 in #15513
[Update graph] Ensure bystander txt files are removed before parsing for Python by @brrygrdn in #15508
Handle global.json with no SDK version in dotnet_sdk parser by @brettfo in #15510
Type the cargo ecosystem and remove it from the T.untyped burndown by @JamieMagee in #15492
Type the conda ecosystem and remove it from the T.untyped burndown by @JamieMagee in #15493
Type the docker ecosystem and remove it from the T.untyped burndown by @JamieMagee in #15495
Use shared git-tag cooldown in terraform by @robaiken in #15472
Retry corepack once on signature metadata error by @thavaahariharangit with @Copilot in #15466
Type the deno, elm, devcontainers, bazel, and helm ecosystems by @JamieMagee in #15527
Add word-separator and lowercase formatting for branch name by @AbhishekBhaskar in #15478
Fix Docker cooldown not respected for multi-arch images missing Last-Modified by @robaiken with @Copilot in #15486
Reduce redundant git-source probes during npm metadata resolution by @thavaahariharangit with @Copilot in #15480
Type the maven ecosystem and remove it from the T.untyped burndown by @JamieMagee in #15531
Add branch name config template format support with validation by @AbhishekBhaskar in #15535
fix(gradle): prefer local gradlew for lockfile updates by @thavaahariharangit in #15546
helm: support versioning-strategy (range-preserving updates) by @casey-robertson-paypal in #15218
Bump gradle from 9.4.1-jdk21-ubi to 9.6.1-jdk21-ubi in /gradle by @dependabot[bot] in #15498
[Update graph] Add support for requirements.txt 'layering' instead of compressing to a single file by @brrygrdn in #15521
Allow periods in Helm values file names for Docker ecosystem by @telnet23 in #15557
Match existing group PRs covering a subset of job directories by @IanButterworth in #15548
Bump library/golang from 1.26.1-bookworm to 1.26.5-bookworm in /go_modules by @dependabot[bot] in #15562
Fix npm security updates for transitive dependencies in workspace monorepos by @Swampen in #15514
Add helm to the smoke-test matrix by @casey-robertson-paypal in #15554
v0.386.0 by @dependabot-core-action-automation[bot] in #15564

New Contributors

@telnet23 made their first contribution in #15557
@Swampen made their first contribution in #15514

Full Changelog: v0.385.0...v0.386.0

Do programming certifications still matter?

Mon, 13 Jul 2026 17:04:44 +0200

If you’re a software developer or architect, you might wonder if programming certifications are still worth the effort, especially in the era of rapid AI-driven evolution. The short answer is, it depends.

“Certifications are shifting from a checkbox to a compass. They’re less about proving you memorized syntax and more about proving you can architect systems, instruct AI coding assistants, and solve problems end-to-end,” says Faizel Khan, lead AI engineer at Landing Point, an executive search and recruiting firm.

“In the AI era, fewer students will get trained on the job, which means they have to train themselves,” Khan says. “Certifications—especially architectural ones like AWS, Kubernetes, Terraform—are still the clearest path to do that.”

Pros and cons of programming certifications

It’s not all black and white when it comes to deciding whether to pursue programming certifications. The effort involves both pros and cons.

“In terms of pros, certifications concretely demonstrate that you have a skillset at a documented level,” says Chris Riccio, vice president of engineering at Uplevel, an engineering optimization system provider. “They also show that you’ve put in the time and effort to learn, study, and prepare.”

Programming certifications are “a useful way to validate foundational skills and show that someone understands core concepts,” says Greg Fuller, vice president of Skillsoft’s training provider, Codecademy. “They’re especially helpful for people entering the field or shifting from adjacent roles.”

Certifications offer a structured path to demonstrate proficiency, and they can confirm your ability to build and deploy in various environments, Fuller says.

These types of certifications often demonstrate baseline proficiency and continuous learning, says Reshmi Ramachandran, head of partnerships and GTM strategy for Cprime, a consultancy. “These are often key indications of proficiency for companies looking to filter large candidate pools,” she says.

Certifications really do two things, Khan adds. “First, they force you to learn by doing,” he says. “If you’re taking AWS Solutions Architect or Terraform, you don’t pass by guessing—you plan, build, and test systems. That practice matters. Second, they act as a public signal. Think of it like a micro-degree. You’re not just saying, ‘I know cloud.’ You’re showing you’ve crossed a bar that thousands of other engineers recognize.”

But there are cons, too. “In tech, employers don’t just want credentials, they want proof you can deliver,” says Kevin Miller, CTO at IFS, a maker of factory automation software. “Programming certifications can be a valuable indicator of your baseline knowledge and competencies, especially if you’re early in your career or pivoting into tech, but their importance is dwindling.”

AI tools that can generate, debug, and optimize code are already performing tasks once done by entry-level developers, “which means fewer traditional programming roles are available,” Miller says. “As a result, the job market is becoming more competitive, and certifications aren’t seen as the noteworthy achievement they once were.”

What’s more, not all certifications carry the same weight, Riccio says. “Some may reflect only familiarity rather than true expertise,” he says. “Certifications also often measure ‘book knowledge’ rather than practical experience, and they don’t always map clearly to the requirements of a specific role.”

Programming certifications “can be a helpful signal, especially for confirming baseline knowledge in areas like cloud, security, or devops, but they’re not the full picture,” says Morgan Watts, vice president of IT at 8×8, a contact center platform developer.

“I’m more interested in a candidate’s attitude and aptitude: what problems they’ve solved, what they’ve built, and how they’ve approached challenges,” Watts says. “Certifications can show commitment and discipline, and they’re especially useful in highly specialized roles. But I’m cautious when someone presents a laundry list of certifications with little evidence of real-world application.”

A certification without experience doesn’t carry much weight, Watts says, and over-certification can sometimes signal the wrong focus. “Ultimately, it’s the ability to apply knowledge, collaborate, and adapt that sets great developers apart,” he says.

Finally, certifications can age fast, Khan says. “Tech stacks evolve and a badge from two years ago may already feel dusty,” he says. “And some certifications are paper-thin—multiple-choice exams that don’t prove you can debug production at 2 a.m. So, the risk is you collect badges but still can’t ship.”

Which certifications will get you noticed?

Despite the drawbacks, certifications are still very much in demand, and some carry more weight than others.

The most in-demand certifications are typically platform-based—Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and others, Riccio says. “Many of these platforms provide managed services that integrate with existing systems or serve as the glue between them,” he says. “Today’s engineering teams aren’t just building standalone systems in isolation; they’re using other systems to store data, orchestrate business workflows, and connect applications.”

A certification that demonstrates the ability to build solutions on these platforms can put a development professional ahead of the competition, Riccio says.

“The certifications I see in highest demand tend to reflect the evolving tech landscape,” Watts says. “Cloud certifications from AWS, Azure, and GCP are incredibly valuable, especially as distributed systems become the norm.”

Also in demand are certifications for devops and CI/CD tools including Kubernetes, Docker, and Jenkins, Watts says, “because deployment automation and reliability are critical at scale. Also, with AI reshaping development, we’re seeing growing interest in certifications around machine learning, data science, and AI model integration. These certifications stand out because they align directly with the skills that teams need to move faster and more intelligently.”

On the AI front, certifications in TensorFlow and other machine learning platforms are gaining traction as organizations look to embed AI across the development process, Watts says. “These are the certifications that align closely with where modern engineering is headed—scalable, secure, and AI-enabled,” he says.

And then there are cybersecurity credentials that continue to be in high demand. Security certifications, such as CompTIA Security+ or Certified Ethical Hacker, “have become essential as every company faces increasing cyber threats and compliance requirements,” Miller says.

“Core programming certifications are still a bit niche, but the adjacent skills, like those that help developers deploy, secure, and scale their code, are driving demand,” Fuller says. “Companies want developers who understand the full lifecycle, not just how to write code.”

Also see: The best Java certifications for software developers.

Certifications in the hiring process

Experts are clear that programming certifications alone will not get you the job. But they do play a role in the hiring process.

“The information technology world is characterized by rapid and continuous evolution, including the skills and knowledge required to work in the field,” says Diane Rafferty, managing director of the National Technology Group at Atrium, a global talent solutions and extended workforce management firm.

“Certifications not only prove that you have the skills and knowledge needed, but they also show employers that you’re invested in your education and career growth,” Rafferty says. “They can give you a competitive edge when looking for a job, as many companies now require candidates to have them.”

Certifications are one part of the hiring equation, “but never the only part,” Watts says. “They help validate that a candidate has taken the time to build foundational knowledge, and that’s a good sign. But I put more weight on how a person thinks, solves problems, and contributes to the team. I look for people who are curious and proactive, who are learning because they want to, not just because a course told them to.”

Certifications can also play a valuable role in retention, Watts says. “I encourage team members to pursue growth, and when they invest in their own development, the whole organization benefits,” he says. “But again, it’s that balance of knowledge, attitude, and applied experience that really moves the needle.”

Certifications “may allow you to breeze through the initial résumé screening process, potentially getting you to the next stage faster,” Riccio says. “At a minimum, they will set your profile apart from the rest of the pack. They also demonstrate that you’ve reached a baseline level of expertise, allowing hiring managers to quickly evaluate whether you have the skills for the role.”

Employers today “care far less about whether someone has passed an exam and far more about whether they can apply knowledge effectively in real-world situations, leverage AI tools, and solve complex problems,” Miller says. “A certification might get someone an interview, but being able to demonstrate problem-solving skills, teamwork, and adaptability will really make them stand out.”

Popular programming certifications

The following certifications consistently rose to the top in my conversations with tech leaders and hiring managers.

AWS Certified Developer—Associate

Showcases skills and knowledge in developing, optimizing, packaging, and deploying applications, using CI/CD workflows, and identifying and resolving application issues, according to AWS. This certification is said to be a good starting point on the AWS certification journey for professionals in IT or cloud developer job roles.

Azure Developer Associate

This certificate from Microsoft is intended for developers participating in all phases of cloud development, including design, deployment, maintenance, and monitoring. The course teaches developers how to create end-to-end solutions in Microsoft Azure, using the Microsoft Learn Sandbox environment to access Azure resources and services.

Certified Kubernetes Application Developer (CKAD)

This certification was created by the Linux Foundation and Cloud Native Computing Foundation. It demonstrates that candidates can design, build, and deploy cloud-native applications for Kubernetes.

Certified Secure Software Lifecycle Professional (CSSLP)

This certification, from ISC2, focuses on secure software development practices. It recognizes leading application security skills and demonstrates advanced technical skills and knowledge needed for authentication, authorization, and auditing throughout the software development lifecycle.

Databricks Certified Machine Learning Professional

Professionals learn about the latest data and AI techniques and how they can use the Databricks Data Intelligence Platform to build a variety of solutions across data engineering, data warehousing, data science, and AI.

Professional Cloud Architect

This certification from Google assesses the ability to design and plan a cloud solution architecture, manage and provision the cloud solution infrastructure, design for security and compliance, analyze and optimize technical and business processes manage implementations of cloud architecture, and ensure solution and operations reliability.

Terraform Associate

This certification from HashiCorp is for cloud engineers specializing in operations, IT, or development who know the basic concepts and skills associated with Terraform. It validates foundational skills in using Terraform for infrastructure as code development.

Cloud native explained: How to build scalable, resilient applications

Mon, 13 Jul 2026 17:04:33 +0200

What is cloud native? Cloud native defined

The term “cloud-native computing” encompasses the modern approach to building and running software applications that exploit the flexibility, scalability, and resilience of cloud computing. The phrase is a catch-all that encompasses not just the specific architecture choices and environments used to build applications for the public cloud, but also the software engineering techniques and philosophies used by cloud developers.

The Cloud Native Computing Foundation (CNCF) is an open source organization that hosts many important cloud-related projects and helps set the tone for the world of cloud development. The CNCF offers its own definition of cloud native:

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

Cloud native technologies and architectures typically consist of some combination of containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless, and declarative APIs — this list is not exhaustive.

This definition is a good start, but as cloud infrastructure becomes ubiquitous, the cloud native world is beginning to spread behind the core of this definition. We’ll explore that evolution as well, and look into the near future of cloud-native computing.

Cloud native architectural principles

Let’s start by exploring the pillars of cloud-native architecture. Many of these technologies and techniques were considered innovative and even revolutionary when they hit the market over the past few decades, but now have become widely accepted across the software development landscape.

Microservices. One of the huge cultural shifts that made cloud-native computing possible was the move from huge, monolithic applications to microservices: small, loosely coupled, and independently deployable components that work together to form a cloud-native application. These microservices can be scaled across cloud environments, though (as we’ll see in a moment) this makes systems more complex.

Containers and orchestration. In could-native architectures, individual microservices are executed inside containers — lightweight, portable virtual execution environments that can run on a variety of servers and cloud platforms. Containers insulate the developers from having to worry about the underlying machines on which their code will execute. That is, all they have to do is write to the container environment.

Getting the containers to run properly and communicate with one another is where the complexity of cloud native computing starts to emerge. Initially, containers were created and managed by relatively simple platforms, the most common of which was Docker. But as cloud-native applications got more complex, container orchestration platforms that augmented Docker’s functionality emerged, such as Kubernetes, which allows you to deploy and manage multi-container applications at scale. Kubernetes is critical to cloud native computing as we know it — it’s worth noting that the CNCF was set up as a spinoff of the Linux Foundation on the same day that Kubernetes 1.0 was announced — and adhering to Kubernetes best practices is an important key to cloud native success.

Open standards and APIs. The fact that containers and cloud platforms are largely defined by open standards and open source technologies is the secret sauce that makes all this modularity and orchestration possible, and standardized and documented APIs offer the means of communication between distributed components of a larger application. In theory, anyway, this standardization means that every component should be able to communicate with other components of an application without knowing about their inner workings, or about the inner workings of the various platform layers on which everything operates.

DevOps, agile methodologies, and infrastructure as code. Because cloud-native applications exist as a series of small, discrete units of functionality, cloud-native teams can build and update them using agile philosophies like DevOps, which promotes rapid, iterative CI/CD development. This enables teams to deliver business value more quickly and more reliably.

The virtualized nature of cloud environments also make them great candidates for infrastructure as code (IaC), a practice in which teams use tools like Terraform, Pulumi, and AWS CloudFormation, to manage infrastructure declaratively and version those declarations just like application code. IaC boosts automation, repeatability, and resilience across environments—all big advantages in the cloud world. IaC also goes hand-in-hand with the concept of immutable infrastructure—the idea that, once deployed, infastructure-level entities like virtual machines, containers, or network appliances don’t change, which makes them easier to manage and secure. IaC stores declarative configuration code in version control, which creates an audit log of any changes.

There’s a lot to love about cloud-native architectures, but there are also several things to be wary of when considering it.

Foundry

How the cloud-native stack is expanding

As cloud-native development becomes the norm, the cloud-native ecosystem is expanding; the CNCF maintains a graphical representation of what it calls the cloud native landscape that hammers home to expansive and bewildering variety of products, services, and open source projects that contribute to (and seek to profit from) to cloud-native computing. And there are a number of areas where new and developing tools are complicating the picture sketched out by the pillars we discussed above.

An expanding Kubernetes ecosystem. Kubernetes is complex, and teams now rely on an entire ecosystem of projects to get the most out of it: Helm for packaging, ArgoCD for GitOps-style deployments, and Kustomize for configuration management. And just as Kubernetes augmented Docker for enterprise-scale deployments. Kubernetes itself has been augmented and expanded by service mesh offerings like Istio and Linkerd, which offer fine-grained traffic control and improved security

Observability needs. The complex and distributed world of cloud-native computing requires in-depth observability to ensure that developers and admins have a handle on what’s happening with their applications. Cloud-native observability uses distributed tracing and aggregated logs to provide deep insight into performance and reliability. Tools like Prometheus, Grafana, Jaeger, and OpenTelemetry support comprehensive, real-time observability across the stack.

Serverless computing. Serverless computing, particularly in its function-as-a-service guise, offers to strip needed compute resources down to their bare minimum, with functions running on service provider clouds using exactly as much as they need and no more. Because these services can be exposed as endpoints via APIs, they are increasingly integrated into distributed applications, operating side-by-side with functionality provided by containerized microservices. Watch out, though: the big FaaS providers (Amazon, Microsoft, and Google) would love to lock you in to their ecosystems.

FinOps. Cloud computing was initially billed as a way to cut costs — no need to pay for an in-house data center that you barely use — but in practice it replaces capex with opex, and sometimes you can run up truly shocking cloud service bills if you aren’t careful. Serverless computing is one way to cut down on those costs, but financial operations, or FinOps, is a more systematic discipline that aims to aligns engineering, finance, and product to optimize cloud spending. FinOps best practices make use of those observability tools to best determine what departments and applications are eating up resources.

How cloud-native architecture is adapting to AI workloads

Enterprises deploy larger AI models and make use of more and more real-time inference services. That’s putting demands on cloud-native systems and forcing them to adapt to remain scalable and reliable.

For instance, organizations are re-engineering cloud environments around GPU-accelerated clusters, low-latency networking, and predictable orchestration. These needs align with established cloud-native patterns: containers package AI services consistently, while Kubernetes provides resilient scheduling and horizontal scale for inference workloads that can spike without warning.

Kubernetes itself is changing to better support AI inference, adding hardware-aware scheduling for GPUs, model-specific autoscaling behavior, and deeper observability into inference pipelines. These enhancements make Kubernetes a more natural platform for serving generative AI workloads.

AI’s resource demands are amplifying traditional cloud-native challenges. Observability becomes more complex as inference paths span GPUs, CPUs, vector databases, and distributed storage. FinOps teams contend with cost volatility from training and inference bursts. And security teams must track new risks around model provenance, data access, and supply-chain integrity.

Application frameworks for building distributed cloud-native apps

Microsoft’s Aspire is one of the most visible examples of a shift towards application frameworks to simplify how teams build distributed systems. Opinionated frameworks like Aspire provide structure, observability, and integration out of the box so developer don’t need to stitch together containers, microservices, and orchestration tooling by hand.

Aspire in particular is a prescriptive framework for cloud-native applications, bundling containerized services, environment configuration, health checks, and observability into a unified development model. Aspire provides defaults for service-to-service communication, configuration, and deployment, along with a built-in dashboard for visibility across distributed components.

While Aspire was originally aligned with Microsoft’s .NET platform,Redmond now sees it as having a polyglot future. This positions Aspire as part of a broader trend: frameworks that help teams build cloud-native, service-oriented systems without being locked into a single language ecosystem. Several other frameworks are gaining traction: Dapr provides a portable runtime that abstracts many of the plumbing tasks in cloud-native distributed applications, and Orleans offers an actor-model-based framework for large-scale systems in the .NET world, and Akka gives JVM teams a mature, reactive toolkit for elastic, resilient services.

Frameworks and tools in the expanding cloud-native ecosystem

While frameworks like Aspire simplify how developers compose and structure distributed applications, most cloud-native systems still depend on a broader ecosystem of platforms and operational tooling. This deeper layer is where much of the complexity—and innovation—of cloud-native computing lives, particularly as Kubernetes continues to serve as the industry’s control plane for modern infrastructure.

Kubernetes provides the core abstractions for deploying and orchestrating containerized workloads at scale. Managed distributions such as Google Kubernetes Engine (GKE), Amazon EKS, Azure AKS, and Red Hat OpenShift build on these primitives with security, lifecycle automation, and enterprise support. Platform vendors are increasingly automating cluster operations—upgrades, scaling, remediation—to reduce the operational burden on engineering teams.

Surrounding Kubernetes is a rapidly expanding ecosystem of complementary frameworks and tools. Service meshes like Istio and Linkerd provide fine-grained traffic management, policy enforcement, and mTLS-based security across microservices. GitOps platforms such as Argo CD and Flux bring declarative, version-controlled deployments to cloud-native environments. Meanwhile, projects like Crossplane turn Kubernetes into a universal control plane for cloud infrastructure, letting teams provision databases, queues, and storage through familiar Kubernetes APIs. These tools illustrate how cloud-native development now spans multiple layers: developer-focused application frameworks like Aspire at the top, and a powerful, evolving Kubernetes ecosystem underneath that keeps modern distributed applications running.

Advantages and challenges for cloud-native development

Cloud native has become so ubiquitous that its advantages are almost taken for granted at this point, but it’s worth reflecting on the beneficial shift the cloud native paradigm represents. Huge, monolithic codebases that saw updates rolled out once every couple of years have been replaced by microservice-based applications that can be improved continuously. Cloud-based deployments, when managed correctly, make better use of compute resources and allow companies to offer their products as SaaS or PaaS services.

But cloud-native deployments come with a number of challenges, too:

Complexity and operational overhead: You’ll have noticed by now that many of the cloud-native tools we’ve discussed, like service meshes and observability tools, are needed to deal with the complexity of cloud-native applications and environments. Individual microservices are deceptively simple, but coordinating them all in a distributed environment is a big lift.
Security: More services executing on more machines, communicating by open APIs, all adds up to a bigger attack surface for hackers. Containers and APIs each have their own special security needs, and a policy engine can be an important tool for imposing a security baseline on a sprawling cloud-native app. DevSecOps, which adds security to DevOps, has become an important cloud-native development practice to try to close these gaps.
Vendor lock-in: This may come as a surprise, since cloud-native is based on open standards and open source. But there are differences in how the big cloud and serverless providers works, and once you’ve written code with one provider in mind, it can be hard to migrate elsewhere.
A persistent skills gap: Cloud-native computing and development may have years under its belt at this point, but the number of developers who are truly skilled in this arena is a smaller portion of the workforce than you’d think. Companies face difficult choices in bridging this skills gap, whether that’s bidding up salaries, working to upskill current workers, or allowing remote work so they can cast a wide net.

Cloud native in the real world

Cloud native computing is often associated with giants like Netflix, Spotify, Uber, and AirBNB, where many of its technologies were pioneered in the early ’10s. But the CNCF’s Case Studies page provides an in-depth look at how cloud native technologies are helping companies. Examples include the following:

A UK-based payment technology company that can switch between data centers and clouds with zero downtime
A software company whose product collects and analyzes data from IoT devices — and can scale up as the number of gadgets grows
A Czech web service company that managed to improve performance while reducing costs by migrating to the cloud

Cloud-native infrastructure’s capability to quickly scale up to large workloads also make it an attractive platform for developing AI/ML applications: another one of those CNCF case studies looks at how IBM uses Kubernetes to train its Watsonx assistant. The big three providers are putting a lot of effort into pitching their platforms as the place for you to develop your own generative AI tools, with offerings like Azure AI Foundry,Google Firebase Studio, and Amazon Bedrock. It seems clear that cloud native technology is ready for what comes next.

Learn more about related cloud-native technologies:

What is GitOps? Extending devops to Kubernetes and beyond

Mon, 13 Jul 2026 17:04:29 +0200

Over the past decade, software development has been shaped by two closely related transformations. One is the rise of devops and continuous integration and continuous delivery (CI/CD), which brought development and operations teams together around automated, incremental software delivery.

The other is the shift from monolithic applications to distributed, cloud-native systems built from microservices and containers, typically managed by orchestration platforms such as Kubernetes.

While Kubernetes and similar platforms simplify many aspects of running distributed applications, operating these systems at scale is still complicated. Configuration sprawl, environment drift, and the need for rapid, reliable change all introduce operational challenges. GitOps emerged as a way to address those challenges by extending familiar devops and CI/CD techniques beyond application code and into infrastructure and system configuration.

At the heart of GitOps is the concept of infrastructure as code (IaC). In a GitOps model, not only application code but also infrastructure definitions, deployment configurations, and operational settings are described in files stored in a version control system. Automated processes continuously compare the running system with those declarations and work to bring the live environment back into alignment when differences appear.

In this approach, the version control repository serves as the system of record for how applications and their supporting infrastructure should look in production. Changes flow through the same review, approval, and automation pipelines that developers already use for software, bringing greater consistency, traceability, and repeatability to cloud-native operations.

At a high level, GitOps refers to a set of operational practices for managing cloud-native systems using declarative configuration, version control, and automated reconciliation. Rather than treating infrastructure and application configuration as mutable runtime state, GitOps treats them as versioned artifacts that move through the same review, testing, and deployment processes as application code.

GitOps defined

The term GitOps was originally coined and popularized by Weaveworks, which helped formalize the approach in the context of Kubernetes operations. While that early work shaped the way GitOps was discussed and implemented, GitOps has since evolved into a broadly adopted, vendor-neutral pattern. Today, it describes a shared set of ideas rather than a specific product or platform.

The defining characteristic of GitOps is its reliance on declarative configuration stored in a version control system. Instead of issuing imperative commands to change live systems, teams describe the desired state of applications and infrastructure in configuration files. Automated agents then continuously compare that declared state with what is actually running and work to reconcile any differences. This pull-based model—where systems converge toward the desired state defined in version control—provides built-in drift detection, repeatability, and a clear audit trail for every change.

Because GitOps centers on configuration files stored in a version control system, familiar software development practices carry over naturally. Changes are proposed through commits, reviewed before being accepted, and tracked over time. Rollbacks are accomplished by reverting to known-good versions, and the history of how a system evolved is preserved alongside the configuration itself.

While the use of Git as the version control system is not strictly required, it has become the default choice because of its ubiquity in modern devops workflows and its strong support for collaboration and change management, so its place in the name has stuck.

GitOps vs. IaC

Infrastructure as code (IaC) and GitOps are closely related, but they solve different problems.

IaC focuses on how infrastructure is defined. Servers, networks, and services are described using declarative configuration files, which are then applied by automation tools. GitOps builds on IaC by adding an operating model around those definitions. In a GitOps workflow, the desired state of systems is stored in a version control repository and treated as the system of record. Automated agents continuously compare the running environment with that desired state and reconcile any differences.

The key distinction is persistence. IaC provisions infrastructure; GitOps keeps systems in the intended state over time. By using pull-based reconciliation and continuous drift detection, GitOps extends IaC into a day-to-day operational discipline.

What is the CI/CD process?

A complete look at CI/CD is beyond the scope of this article—see the InfoWorld explainer on the subject—but we need to say a few words about CI/CD because it’s at the core of how GitOps works. The continuous integration half of CI/CD is enabled by version control repositories like Git: Developers can make constant small improvements to their codebase, rather than rolling out huge, monolithic new versions every few months or years. The continuous deployment piece is made possible by automated systems called pipelines that build, test, and deploy the new code to production.

Again, we keep talking about code here, and that usually summons up visions of executable code written in a programming language such as C or Java or JavaScript. But in GitOps, the “code” we’re managing is largely made up of configuration files. This isn’t just a minor detail — it’s at the heart of what GitOps does. These config files are, as we’ve said, the “single source of truth” describing what our system should look like. They are declarative rather than instructive. That means that instead of saying “start up ten servers,” the configuration file will simply say, “this system includes ten servers.”

GitOps and Kubernetes

GitOps first took hold in the Kubernetes ecosystem, where declarative configuration and continuous reconciliation are core design principles. As a result, Kubernetes remains the most common and best-understood environment for applying GitOps practices. A typical GitOps-driven update process for a Kubernetes application looks like this:

A developer proposes a change by committing updated application code or configuration to a version control repository, usually through a pull request.
That change is reviewed and approved, then merged into the main branch.
The merge triggers an automated CI/CD pipeline that tests the change, builds new artifacts if needed, and publishes them to a registry.
A GitOps controller or similar automated agent detects the updated desired state stored in version control.
The controller compares that desired state with the current state of the Kubernetes cluster and applies the necessary changes to bring the cluster back into alignment.

This pull-based reconciliation loop—where the cluster continuously converges toward the desired state defined in version control—is central to how GitOps works in practice. While Kubernetes provides a natural fit for this model, it represents just one canonical use case. The same patterns increasingly apply to infrastructure provisioning, policy enforcement, and multi-cluster operations beyond Kubernetes itself.

GitOps tooling in practice: Argo CD, Flux, and the ecosystem

GitOps is enabled by a set of tools that embody the principles we’ve outlined, with some open-source projects emerging as de facto standards in cloud-native environments.

At the center of the GitOps ecosystem is Argo CD, an open-source controller that continuously monitors a version control repository and ensures that the state of running systems matches the declared desired state. Argo CD is widely used in Kubernetes environments because it directly implements pull-based reconciliation: it compares the desired state stored in Git with the cluster’s actual state and applies changes to correct any drift.

Alongside Argo CD, Flux is another prominent open source GitOps engine. Both Flux and Argo CD help teams adopt GitOps workflows by managing the synchronization loop between code and runtime, but they differ in operational philosophy, integration surfaces, and ecosystem fit.

GitOps tooling often appears as part of broader platforms or integrated stacks rather than as isolated utilities. For example, multicloud and cluster management solutions now routinely include GitOps support, with Argo CD or compatible controllers bundled alongside deployment, policy, and governance capabilities.

In addition to Flux and Argo CD, a range of auxiliary tools contribute to a complete GitOps ecosystem: policy as code engines (e.g., Open Policy Agent), drift detection systems, and infrastructure provisioning tools that mesh with Git-centric workflows.

GitOps, devops, and normalization

GitOps grew out of the same forces that drove devops into mainstream IT practice, and in its early days, GitOps was often discussed as a distinct extension of devops, specifically tailored to managing declarative infrastructure and Kubernetes-centric systems. At the time, GitOps was still relatively new and not yet widely adopted outside cloud-native pioneers.

Over the last several years, however, GitOps practices have become deeply woven into how teams operate modern cloud environments. Rather than being treated as an optional add-on or marketing term, the core ideas of GitOps — using version-controlled, declarative configuration and automated reconciliation loops to continuously align running systems with intended state — are now part of standard operational practice in many Kubernetes-centric shops. In this sense, GitOps has shifted from a buzzword about what might be possible to a baseline pattern for cloud-native operations, much like devops itself did years earlier.

In environments where Kubernetes and declarative systems are the norm, GitOps workflows are the default way teams manage and deploy change. Many organizations now implement these patterns without explicitly calling them “GitOps,” just as few teams today explicitly say they do “CI/CD” even though continuous pipelines are taken for granted. The term has become less prominent in marketing, but its practices are often embedded in pipelines, controllers, and platform tooling.

That normalization shows up in how GitOps workflows are woven into broader operational frameworks. For example, platform engineering teams frequently build internal developer platforms that encapsulate GitOps patterns behind standardized developer APIs, making the pattern invisible to most application teams while still providing the auditability and automation that GitOps promises.

GitOps beyond Kubernetes: infrastructure, policy, and drift

While GitOps first gained traction as a way to manage Kubernetes deployments, its core principles apply broadly to infrastructure and operational concerns beyond any single orchestration platform. GitOps treats desired state as declarative configuration stored in version control and uses automated reconciliation to ensure running systems align with that state. That pattern naturally extends to infrastructure provisioning, policy enforcement, configuration drift detection, and governance workflows across diverse environments.

In modern operational stacks, infrastructure is increasingly defined declaratively, whether through Kubernetes manifests, Terraform modules, or other infrastructure-as-code formats. Storing these declarations in version control enables the same peer-review, auditability, and rollback practices developers already use for application code. Automated tooling then continuously detects when the live infrastructure diverges from the declared state and works to bring it back into alignment, reducing the risk of configuration drift and inadvertent misconfigurations.

Configuration drift — the state where an environment has diverged from what’s declared in version control — remains a major operational headache, especially in complex, dynamic systems. Drift can arise from ad hoc fixes, emergency updates, or manual changes made outside normal pipelines, and it can lead to inconsistencies, outages, and security gaps. By continually checking running systems against the desired state in Git and reconciling deviations automatically, GitOps workflows help teams keep environments predictable and auditable.

Policy enforcement and compliance are another natural extension of GitOps patterns. As organizations adopt declarative practices, policy-as-code engines and drift detection systems can be woven into GitOps pipelines to validate that proposed configurations meet security, compliance, or operational standards before they’re ever applied to running systems. Embedding policy checks into declarative workflows brings consistency to governance while preserving the automation and speed that devops teams expect.

GitOps – beyond Kubernetes

GitOps began as a way to bring devops discipline to Kubernetes operations, but its longer-term impact has been more subtle. In many ways, it’s been absorbed into the fabric of modern cloud-native operations, where declarative configuration, version control, and automated reconciliation are taken for granted. Today, GitOps is less about a specific set of tools or a named practice and more about an operational mindset. By treating infrastructure and configuration as versioned, auditable artifacts and relying on automation to enforce consistency, GitOps helps teams manage complexity at scale. Even as the term itself fades from the spotlight, the practices it introduced continue to shape how distributed systems are built, deployed, and operated.

Security updates for Monday

Mon, 13 Jul 2026 14:41:08 +0200

Security updates have been issued by Debian (chromium, libxfont, mesa, opam, and wireless-regdb), Fedora (acl, attr, chromium, cjson, composer, docker-compose, jfrog-cli, librabbitmq, libssh2, libXfont2, log4cxx, OpenImageIO, openssh, p11-kit, perl-Crypt-DSA, perl-HTML-Gumbo, prometheus, python-dulwich, python-idna, python-pillow, python-tornado, sssd, tmux, upower, webkitgtk, xorg-x11-server, and xorg-x11-server-Xwayland), Mageia (libarchive and vim), Oracle (389-ds:1.4, buildah, cups, edk2, freerdp, golang, grafana, gstreamer1-plugins-bad-free, gstreamer1-plugins-good, gstreamer1-plugins-ugly-free, kernel, libexif, libsolv, libtasn1, libxml2, nginx:1.24, nginx:1.26, nodejs:22, nodejs:24, oci-seccomp-bpf-hook, podman, postgresql:18, python-urllib3, tigervnc, tomcat, unbound, and xorg-x11-server), Slackware (p11-kit), and SUSE (agama, dash, dracut, flannel, go1.26, gsasl, gstreamer-plugins-good, ImageMagick, imagemagick, kernel, krb5, krb5, krb5-mini, libIex-3_4-33, libmbedtls23, libxfont2, nasm, nghttp2, perl-CGI-Session, perl-dbi, perl-List-SomeUtils-XS, python-pillow, python-social-auth-app-django, python-urllib3, python313-Django4, python313-Django6, python313-pytest-html, python313-sqlparse, python313-websockets, rclone, rust-keylime, rustup, sccache, spectre-meltdown-checker, sssd, terraform-provider-aws, terraform-provider-azurerm, terraform-provider-external, terraform-provider-google, terraform-provider-helm, terraform-provider-kubernetes, terraform-provid, thunderbird, tiff, traefik2, xorg-x11-server, and xwayland).

Denial of Service in terraform-provid, terraform-provider-aws, terraform-provider-azurerm, terraform-provider-external, terraform-provider-google, terraform-provider-helm und terraform-provider-kubernetes (SUSE)

Sat, 11 Jul 2026 00:04:40 +0200

CVE-2026-15067 | Snowflake Terraform Provider up to 2.17.x Data Source/User Management workspace sql injection (CNNVD-2026-97425599)

Fri, 10 Jul 2026 09:09:28 +0200

A vulnerability categorized as problematic has been discovered in Snowflake Terraform Provider up to 2.17.x. This vulnerability affects unknown code of the component Data Source/User Management. Such manipulation of the argument workspace leads to sql injection. This vulnerability is traded as CVE-2026-15067. The attack may be launched remotely. There is no exploit available.

[NEU] [mittel] Hashicorp Terraform: Schwachstelle ermöglicht Offenlegung von Informationen

Tue, 07 Jul 2026 10:51:28 +0200

Ein entfernter, authentisierter Angreifer kann eine Schwachstelle in Hashicorp Terraform ausnutzen, um Informationen offenzulegen.

CVE-2026-14468 | HashiCorp Terraform Enterprise up to 2.0.3 VCS Ingestion Boundary information disclosure (EUVD-2026-41946)

Tue, 07 Jul 2026 01:21:47 +0200

A vulnerability identified as problematic has been detected in HashiCorp Terraform Enterprise up to 2.0.3. This impacts an unknown function of the component VCS Ingestion Boundary. Performing a manipulation results in information disclosure. This vulnerability is cataloged as CVE-2026-14468. It is possible to initiate the attack remotely. There is no exploit available.

Why developers are over the cloud

Mon, 06 Jul 2026 12:19:48 +0200

You can be forgiven if you think the most important thing AWS ever sold developers was EC2. It’s not. No, AWS’s big gift to developers was permission to stop fretting about servers. That sounds obvious now, but it was close to magical at the time. Before the cloud, getting infrastructure meant waiting on procurement, hardware, and the somewhat arcane process that stood between a developer and a running machine. AWS turned that into a credit card and an API.

It was awesome.

AWS still (over)uses a great phrase for what it removed: “undifferentiated heavy lifting.” That is, all the mess associated with racking servers, patching operating systems, managing storage, planning capacity, etc. Important work, sure, but not the work that makes your application special. Let AWS do that, the company intoned, and developers could focus on the thing their customers actually cared about.

It was a brilliant abstraction. It helped build one of the most important technology companies of the past two decades. It’s also the same logic that increasingly makes the cloud seem superfluous. Not because the cloud is dying. It isn’t. The cloud is bigger and more essential than ever. But developers don’t begin by asking, “Which cloud should I use?” They begin with, “How quickly can I get this thing working?”

That is a different question, and it leads to different tools.

Where to begin?

Let’s get the obvious thing out of the way: AWS remains the biggest developer cloud, and its revenue growth has accelerated in the wake of AI. In the 2024 Stack Overflow Developer Survey⁠, AWS was the top cloud platform, used by 48% of respondents. Microsoft Azure and Google Cloud followed at 27.8% and 25.1%, respectively.

The 2025 Stack Overflow Developer survey⁠ is more interesting, however, because the “cloud development” category no longer reads like a clear cloud-vendor horse race. Docker jumped 17 points to 71% usage, followed by npm and then AWS at 43%. Kubernetes, Azure, Google Cloud, Cloudflare, Terraform, Firebase, Vercel, Netlify, and Supabase all show up in the same mental map.

This is my point: Developers aren’t simply choosing a different cloud first. Often, they’re not choosing a cloud first at all. They’re choosing a workflow, and a workflow is an increasingly separate decision from the underlying cloud.

The first mile moved

For a long time, AWS owned the first mile. If you wanted to build something, you opened an AWS account. Need compute? Launch EC2. Storage? S3. Whatever a developer needed—database, queue, function, CDN, identity layer—AWS, the “everything store,” almost certainly had an answer.

It was magical! Then it became the norm. And, over time, it became a lot. The “everything store” arguably had too much, making it hard for developers to know how to use it effectively. The developer’s question became, “How much AWS do I have to understand before I can ship?” Developers increasingly don’t want to answer that question at the start.

The first mile now often begins in GitHub⁠, which says more than 36 million developers joined in a single year. Or it begins in VS Code, which keeps winning because it’s familiar, extensible, and already open. Or it begins in Cursor, GitHub Copilot, Claude, Codex, and the broader AI coding layer. GitHub’s 2025 Octoverse⁠ says nearly 80% of new developers on GitHub use Copilot within their first week. Stack Overflow’s 2025 AI survey results⁠ point the same way, with 84% of respondents using or planning to use AI tools in their development process, up from 76% in 2024.

The starting point is changing. The default interface to building software is becoming an AI-assisted workflow, not a cloud console. This doesn’t make the cloud less important, but it definitely makes it less visible.

The joy of not caring

The developer platforms with momentum right now are winning because they expose less cloud infrastructure. Call it serverless if you like, but it’s deeper than AWS Lambda ever was. AWS Lambda still made you think in AWS. These new platforms make you think in your app.

Take Vercel⁠. It didn’t win developer mindshare by offering more than 200 services and praying developers would navigate them all. Instead, it attached itself to the way many front-end and full-stack developers already work: GitHub, Next.js, previews, deployments, performance, and a short path from code to live application. It seems to be working: Reuters reported last year that Vercel raised $300 million at a $9.3 billion valuation⁠, after doubling its user base and growing revenue 82%.

Cloudflare offers a similar promise from a different angle, as I’ve written: deploy globally, run close to users, scale automatically, and don’t make infrastructure the developer’s first problem. Supabase⁠ does the same for data, wrapping Postgres with authentication, instant APIs, edge functions, real-time subscriptions, storage, and vectors so the database feels less like a separate system and more like an app platform.

None of this is anti-cloud. But it’s very definitely stripping away the need to even think about cloud. And it’s just as definitely where developers are focused today.

AI accelerated all of this because it changed the first question developers ask. For an AI application, the opening move often isn’t where do you host it, but rather which model, which agent framework, etc., will get you to a live application fastest? For this reason, OpenAI’s developer platform⁠ isn’t framed as renting infrastructure. It’s framed as building with models, APIs, tools, docs, and examples. Similarly, Anthropic’s Claude Code⁠ isn’t positioned as configuring a cloud environment; it’s an agentic coding system that works in your code base and helps you build, test, and ship.

The second mile matters more

I’m not saying the cloud vendors should abandon hope. Indeed, though the first mile has moved away from the hyperscalers, the second mile is still very much theirs to win.

Vercel, Cloudflare, Supabase, OpenAI, Anthropic, and GitHub are brilliant at helping developers make something work, fast. But in the enterprise, “fast” isn’t the key priority: Enterprises eventually need the boring stuff like identity, network controls, observability, cost management, compliance, and the rest of the unglamorous apparatus that keeps customer data from leaking onto Reddit.

Boring is good when boring means the thing works.

This is where AWS, Azure, Google Cloud, Oracle, and other infrastructure companies should have an advantage. But it won’t be enough to say, “We have the grown-up features.” That’s true, but it’s dull, and in this case, “dull” isn’t a winning proposition. No, the strategic challenge for the hyperscalers is to make the jump from prototype to production feel like an upgrade instead of a punishment.

AWS’s new $1 billion investment in forward-deployed AI engineers⁠ is interesting for exactly this reason. AWS says the new organization will embed experts with customers to co-develop and deploy agentic AI solutions in days. That’s not classic bottom-up developer love, but it’s a smart recognition that the bottleneck has moved closer to the application. The hard part is turning capability into a working system, not merely getting access to infrastructure or a model.

Yep. Exactly.

Hiding the cloud

The mistake for cloud infrastructure companies would be to respond to this by trying to become a Vercel, Supabase, GitHub, OpenAI, or Anthropic all at once. That’s the classic incumbent move, and it rarely works. The better move is narrower: become the most natural next step when the prototype starts to matter.

That means meeting developers where they work: GitHub, VS Code, Cursor-style environments, CI/CD systems, and AI agents. It means outcome-native starts: deploy this app, connect this data, expose this API, add auth, evaluate this agent, secure this workflow, move this prototype into production. It means fewer scavenger hunts across product pages and establishing more golden paths (yes, even if that infuriates a service team that gets left out).

The old question was, “Can you run my workload?” For AWS, Azure, Google Cloud, Oracle, and others, the answer is almost always yes. But no one is impressed by this anymore. Therefore, the better question is, “Can you become part of how I build?”

Developers came to the cloud because it was the easiest way to get infrastructure. They’re shifting to developer experience platforms because those are the easiest way to get outcomes. If the cloud providers can become part of the first mile before the Vercels of the world become part of the second mile, they’ll win, and big. If they don’t, well….

Preventing agent-generated infrastructure bloat through spec-driven governance

Wed, 01 Jul 2026 11:19:17 +0200

Autonomous AI engineer agents can deliver software at a scale in multiples of what a human engineering team can do, and that productivity is genuinely valuable. But without proper guardrails at the specification level, these agents can industrialise inefficient infrastructure patterns at the same pace, consistently and at a scale that makes post-deploy remediation impractical. When an agent provisions a three-node GKE cluster using n2-standard-16 machines for a workload a single e2-medium node could handle, or generates a Kubernetes pod spec with 4-CPU and 8GB memory requests for a service that peaks at 200 milli-cores and 256MB, or writes a Dockerfile that pulls a full Ubuntu base image where a distro-less container would serve, infrastructure runs that decision continuously, for the lifetime of the service. The agent will reproduce these patterns across every environment it touches, because the specification never instructed it otherwise. When agentic pipelines are generating infrastructure at scale, operational remediation after the fact becomes impractical.

The scale of what is now being generated autonomously is significant. InfoWorld’s reporting on AI-driven development shows the pace of AI-generated output is accelerating sharply, and projections suggest more than a quarter of new production code and configuration is already AI-generated. What those projections do not yet capture is the shift from AI-assisted to fully agentic pipelines, where agents generate Terraform, Kubernetes manifests, Helm charts and Docker configurations end-to-end, commit them and trigger deployment, with no human in the loop or little oversight that concentrates on functional capabilities. When that pipeline runs without sustainability constraints, it systematically reproduces that infrastructure inefficiency across every environment it touches.

Green software has traditionally been an operational problem: Right-size the containers retrospectively, tune the cluster after the fact, schedule workloads in low-carbon windows. That approach was already struggling before agentic pipelines arrived. Gartner projects that by 2027, just 30% of large enterprises will have software sustainability embedded in their non-functional requirements. That statistic carries a consequence most engineering leaders have not yet confronted: If 70% of enterprise code has been written without sustainability intent, then the training data autonomous AI engineer agents learned from is dominated by potentially unsustainable patterns. An agent defaults to the majority pattern in its training distribution, which is the inefficient one. This makes the specification constraint not just a governance need, but a corrective instruction that the agent’s training data never provided.

Sustainable specification as a reliable intervention point

In a fully agentic development pipeline, the specification is not a document an engineer reads before writing code. It is the instruction set the agent executes. It determines which machine types get provisioned, which container base images get selected, how pod resource requests are sized, how storage is allocated and how networking is configured. Every infrastructure decision the agent makes downstream is a function of what the specification permitted or left undefined.

If the specification contains no sustainability constraints, the agent will make infrastructure decisions based on defaults, conventions and training data patterns, none of which are optimised for energy efficiency. An agent prompted to scaffold a GKE-based microservice will, by default, select machine types that ensure availability headroom rather than efficiency. It will size pod resource requests conservatively to avoid out-of-memory conditions from potentially inefficient application code, but not to minimise node utilization. It will pull familiar base images rather than minimal ones. These are not failures of the agent. They are the predictable output of an instruction set that never asked for sustainability.

The fix is to make sustainability a first-class constraint in the specification itself. A constraint such as GS-INFRA-001 (select the smallest GKE machine type that satisfies the workload’s measured resource ceiling, defaulting to e2-medium or smaller) or GS-K8S-001 (set pod CPU requests to measured p95 consumption with a 20% ceiling, not to arbitrary safe values) is a structured policy the agent reads before it generates a single line of Terraform or YAML. The agent does not override it. It executes it. That is the mechanism that makes sustainability structural and automated rather than aspirational.

The infrastructure patterns that matter most

Three infrastructure domains represent the highest-impact targets for sustainability constraints, precisely because autonomous AI engineer agents generate them prolifically and the consequences compound continuously at runtime rather than only when code executes.

The first is IaC and cloud resource provisioning. An agent generating a Terraform configuration for a GKE cluster defaults to instance families and node counts calibrated for resilience, not efficiency. A three-node cluster of n2-standard-16 machines (64 vCPUs, 192GB RAM) provisioned for a service that runs comfortably on a single e2-medium (2 vCPUs, 4GB RAM) represents a 32x over-provisioning of compute. That gap does not show up in staging. It runs in production, is billed continuously, emitting continuously. A sustainability constraint in the Terraform specification that enforces machine type selection against a measured workload profile eliminates this class of error before the agent writes its first resource block.

The second is the Kubernetes pod resource configuration. Pod resource requests are the input the Kubernetes scheduler uses to place workloads on nodes. When an autonomous AI engineer agent generates a pod spec with generous CPU and memory requests, the scheduler reserves that capacity whether the pod uses it or not. Nodes that could host eight efficiently-sized pods instead host two or three over-specified ones, leaving the remaining capacity stranded and the underlying VM running at low utilization. A pod spec with a 4-CPU, 8GB memory request for a service that observably consumes 200 millicores and 256MB at peak is not cautious engineering. It is a scheduler instruction to waste three and a half CPUs and 7.75GB of memory per pod, per node, per hour, across every replica in every environment. A sustainability constraint specifying that pod resource requests must be derived from measured p95 consumption data, not from defaults or intuition, changes this systematically.

The third is the container base image selection. When an agent generates a Dockerfile, it gravitates toward familiar, full-featured base images: Ubuntu, Debian, Python, Node.js. These images are large, carry a significant attack surface and consume more storage, memory and transfer bandwidth than their minimal equivalents. A distroless or Alpine-based image for the same workload can be an order of magnitude smaller. At the scale at which an autonomous AI engineer agent operates, pulling, storing and running bloated base images across hundreds of services is a significant and entirely avoidable infrastructure cost. A constraint specifying distroless or minimal base images as the default, with justification required for exceptions, eliminates the pattern without slowing generation.

4 pipeline stages where constraints are enforced

Embedding constraints in the specification is the intervention. Enforcing them through the pipeline is what makes the intervention reliable. Four stages create the enforcement architecture.

The first stage is generation itself. When sustainability constraints are part of the specification the autonomous AI engineer agent operates from, those constraints shape every artifact the agent produces: Terraform resource blocks, Kubernetes manifests, Helm chart defaults, Dockerfile base image selections. The agent does not reason about sustainability independently. It executes the specification. A well-constrained specification produces sustainable infrastructure by construction, not by review.

The second stage is static analysis. Tools including Checkov, tfsec, KICS and Trivy analyze Terraform, Kubernetes YAML and Dockerfiles against configurable policy rules without modifying the agent or the pipeline architecture. A Checkov policy enforcing the GKE machine type constraint, or a tfsec rule flagging over-provisioned node pools, runs against every artifact the agent generates before it reaches a deployment gate. The violation surfaces as structured CI output the gate acts on. The agent’s output is checked the same way a human engineer’s output would be, consistently, at every commit.

The third stage is the quality gate. Sustainability violations fail the build. They do not generate warnings that an agent pipeline has no mechanism to act on. A gate that blocks deployment on policy violations is the enforcement layer that makes constraints binding rather than advisory. Because the gate operates on artifact output rather than on the agent itself, it is fully autonomous AI engineer agent-agnostic: It does not matter whether the Terraform was generated by Copilot, a custom LLM pipeline, an internal scaffolding agent or a human engineer. The gate evaluates the artifact against the policy. That is the only thing that matters.

The fourth stage is runtime telemetry feeding back into constraint refinement. Actual resource utilization, node efficiency metrics and carbon intensity data from production inform constraint updates at the specification level. A constraint calibrated on design-time estimates tightens over time as empirical data replaces assumptions. The governance model improves continuously rather than stagnating at its initial calibration.

3 steps to start this week

Most engineering organizations already have everything they need to begin. The static analysis toolchain is there: Checkov, tfsec, KICS, Trivy and OPA Conftest all support configurable sustainability policies against Terraform, Kubernetes YAML and Dockerfile artifacts without pipeline replacement. The CI/CD pipeline is there: GitHub Actions, GitLab CI, Jenkins, Tekton and Azure DevOps Pipelines all support blocking quality gates against policy tool outputs. The specification layer is there: Terraform modules, Helm chart value schemas, Kubernetes admission controllers and architectural decision records are already version-controlled in most mature engineering organizations. And critically, this approach is a fully autonomous AI engineer agent-agnostic. The governance layer does not inspect which agent or model generated the infrastructure artifact. It enforces the policy against the output. Whether the Terraform came from a custom agentic pipeline, a Copilot suggestion or a human engineer, the gate applies identically. The only things genuinely missing are the sustainability constraint definitions authored into the specification and the policy rules wired into the CI/CD pipeline to enforce them. Three steps close that gap.

Audit your IaC specifications for sustainability constraints. Open an active Terraform module or Helm chart and locate the machine type defaults, pod resource request defaults and base image defaults. For most organizations, these are set to safe, familiar values with no sustainability rationale. Define three constraints: A maximum machine type ceiling for each workload tier, a pod resource request ceiling derived from measured utilization, and a base image policy requiring distro-less or Alpine equivalents. Version control these constraints alongside the specifications they govern.
Add one Checkov or tfsec policy to your CI pipeline. A policy flagging GKE node pools configured above the e2-standard-4 threshold without a documented justification is implementable in under an hour using Checkov’s custom check API. Wire it as a blocking gate, not a warning. This single addition creates immediate, agent-agnostic enforcement across every Terraform commit in your repository.
Embed sustainability constraints before you scale your agentic pipelines. The highest-leverage moment is now, before autonomous AI engineer agents are generating infrastructure at full organizational scale. Every agentic pipeline that goes into production without sustainability constraints in its specification becomes a systematic source of over-provisioned, carbon-intensive infrastructure that compounds daily. Retrofitting governance after hundreds of agent-generated services are running is an order of magnitude harder than constraining generation at the specification source.

What lies ahead

The sustainability challenge discussed here is not the energy consumed by the AI engineer agent itself, but the long-lived infrastructure decisions encoded into the artifacts it generates. Sustainable infrastructure engineering is no longer an operational discipline. It is an architectural necessity, and the specification layer is where that necessity must be addressed. When autonomous AI engineer agents are generating Terraform, Kubernetes manifests and Docker configurations at scale, the organizations that embed sustainability constraints into the specifications those agents execute will build efficient, cost-controlled, regulation-ready infrastructure by construction. Those that do not will build a remediation programme instead, which at scale will become impractical.

The urgency is not speculative. IEEE Spectrum reports that Microsoft’s emissions have risen 23% since its 2020 baseline and Google’s have climbed 51% since 2019, with AI infrastructure as the primary driver. Global data centres are on track to consume more electricity than Japan by 2030. A significant fraction of that load is over-provisioned infrastructure that an autonomous AI engineer agent generated from a specification that never asked for efficiency. The constraint cost is low. The compounding cost of the alternative is not.

The governance imperative is converging from three directions simultaneously. Cloud cost: Over-provisioned AI-generated infrastructure compounds spend at a rate that makes early specification-layer control orders of magnitude cheaper than post-deployment rightsizing programmes. Technical debt: Every agentic sprint that ships infrastructure without sustainability constraints adds configuration debt that grows faster than any platform team can retrospectively correct. Regulatory pressure: Sustainability reporting requirements, already mandatory in the EU and accelerating in other jurisdictions, will reach infrastructure efficiency metrics. Engineering organizations that have operationalised sustainability governance at the specification layer will meet those requirements as a natural output of their existing pipeline. Those who have not will discover that compliance is a crisis programme when the deadline arrives. These are not abstract architectural concerns. The organizations that govern agentic generation upstream, at the specification, will compound efficiency gains with every agent run, not just sustainability but cost, too. Those who govern only in production will spend a lot of time remediating what they should have prevented before the first line of Terraform was written.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

v0.384.0

Tue, 30 Jun 2026 18:19:52 +0200

What's Changed

Bazel: Fix prerelease filtering with same-release-line scoping by @v-HaripriyaC in #15332
Respect cooldown for Docker digest updates and suppress multi-arch no-ops by @robaiken in #15354
Bypass npmrc min-release-age for transitive npm security updates by @robaiken in #15386
Ratchet the Sorbet T.untyped burndown by @JamieMagee in #15399
feat(docker): implement single-platform image detection and optimize manifest fetching logic by @jpinz in #15390
Fix private registry config not found error not being raised issue in npm_and_yarn by @AbhishekBhaskar in #15394
don't fail if nuget cred is missing url by @brettfo in #15378
Type commit_message_options with a value object by @JamieMagee in #15400
Type the Dependabot config file parser by @JamieMagee in #15401
Fix Terraform registry replacement typing and credential semantics by @thavaahariharangit with @Copilot in #15406
fix: avoid path collisions for SHA-pinned GitHub Actions by @markhallen in #14806
Nix: skip flake inputs pinned to a bare commit SHA by @JamieMagee in #15412
Type the vulnerability version-range renderer by @JamieMagee in #15402
Add JobCommand enum and Command property to NuGet Job model by @brettfo in #15277
Upgrade Ruby to 4.0.5 by @Bo98 in #14830
Bump updater-core image to RubyGems/Bundler 4.0.13 by @JamieMagee in #15256
Fix issue with PrivateRegistryConfigNotFound error incorrectly firing when scope is configured by @AbhishekBhaskar in #15416
Fake MSBuild SolutionDir during NuGet discovery (#13756) by @brettfo in #15392
NuGet: Filter all editable files not present prior to discovery by @brettfo in #15358
Support Central Package Versions updates in XmlFileWriter by @brettfo in #15409
[Update Graph] Report empty manifests as present but empty instead of omitting them by @brrygrdn in #15427
Fix vcpkg empty PRs for up-to-date baselines by @JamieMagee in #15420
Nix: update NixOS channel tarball inputs by @JamieMagee in #15413
fix(opentofu): accept terraform_registry credentials for OCI registry tags by @thavaahariharangit in #15422
Commit changes to workspace member TOML files by @crabbit-git in #15142
Fix COREPACK_NPM_REGISTRY trailing slash causing pnpm HTTP 404 on private registries by @thavaahariharangit with @Copilot in #15444
Map additional NuGet feed errors to private_source_bad_response by @brettfo in #15426
Support version and security NuGet job commands by @brettfo in #15430
Show the vcpkg release tag instead of master in PR titles by @JamieMagee in #15433
Register MSBuild before running the job so early NuGet errors are reported by @brettfo in #15431
Add a baseline to vcpkg projects missing one by @JamieMagee in #15432
Fix file updater failed to update for all support files sentry error by @AbhishekBhaskar in #15421
Skip disabled Maven repositories by @adoroszlai in #15443
v0.384.0 by @dependabot-core-action-automation[bot] in #15438

New Contributors

@crabbit-git made their first contribution in #15142
@adoroszlai made their first contribution in #15443

Full Changelog: v0.383.0...v0.384.0

Musk On Mars (Theater, 60 min) (fusion26)

Fri, 26 Jun 2026 22:18:25 +0200

Elon Musk landet als erster Mensch auf dem Mars. Doch anstelle den Planeten ohne Bedingungen nach seinen Wünschen terraformen zu können, muss er sich vor dem marsianischen Einwanderungsgericht einigen Fragen stellen, die schnell ziemlich unangenehm für ihn werden. Die ‚Aufnahmegesellschaft Mars‘ – das Publikum – prüft jeden Ankömmling aufs Genaueste. Seid Teil dieser interplanetaren Gerichtsshow von der wunderbaren Alisa Tretau! Musik, KI und Grünheide inklusive! Language: DE Translation: NO Video Recording: YES Graphic Recording: YES Elon Musk lands on Mars. But instead of being able to terraform the planet exactly as he pleases, he must answer the questions of the Martian immigration court. The “Mars Host Society”—the audience—scrutinizes every new arrival in minute detail. Be part of this interplanetary courtroom show! Music, AI, and Grünheide included! Language: DE Translation: NO Video Recording: YES Graphic Recording: YES Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://c3voc.de

Security updates for Tuesday

Tue, 23 Jun 2026 15:10:49 +0200

Security updates have been issued by Debian (ffmpeg), Fedora (erlang, ffmpeg, prometheus, python-scrapy, python3-docs, python3.14, thorvg, tigervnc, and vips), Mageia (mumble and sslh), Oracle (389-ds:1.4, dracut, firefox, hplip, kernel, openssh, postgresql:15, redis:6, and uek-kernel), Red Hat (delve, gvisor-tap-vsock, nginx, nginx:1.24, nginx:1.26, osbuild-composer, podman, rhc, skopeo, and yggdrasil), SUSE (containerized-data-importer, graphite2, kernel, libarchive, openssh, openssh-askpass-gnome, openvswitch, openvswitch3, postfix, python-lxml, python-nltk, python-python-multipart, python-urllib3, rmt-server, terraform-provider-local, terraform-provider-null, and util-linux), and Ubuntu (google-guest-agent, haproxy, libxml2, linux-azure, linux-intel-iotg-5.15, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-oracle-5.15, mysql-8.0, mysql-8.4, and nginx).

Denial of Service in terraform-provider-local und terraform-provider-null (SUSE)

Mon, 22 Jun 2026 23:53:48 +0200

Phone Numbers and Emails to Hidden Subdomains: The OSINT Acquisition Pipeline That Uncovered a…

Fri, 19 Jun 2026 13:09:24 +0200

Phone Numbers and Emails to Hidden Subdomains: The OSINT Acquisition Pipeline That Uncovered a Critical Bug

A deep technical blog on using phone numbers and email addresses to discover hidden domains, subdomains, and attack surface — with real-world techniques you can use today.

Phone Numbers and Emails to Hidden Subdomains

Foreword: Why I Wrote This

In bug bounty and security research, one of the biggest challenges is not finding vulnerabilities — it’s finding the right attack surface.

Many researchers start with traditional reconnaissance: collecting subdomains, checking DNS records, and running automated tools. While these methods are valuable, they often miss assets that are not directly connected to the primary domain.

This is where OSINT becomes powerful.

A simple phone number or email address can become a starting point for discovering hidden digital assets:

A company email can reveal related domains and third-party services
Public profiles can expose forgotten infrastructure
Developer footprints can reveal technology stacks and assets
Business records can connect organizations to previously unknown domains

The idea behind this research is simple:

Public information creates relationships, and relationships create attack surface.

This blog explores an OSINT-driven acquisition workflow for connecting phone numbers and email addresses with domains, subdomains, and external assets. These techniques are useful for authorized security testing, bug bounty research, and improving reconnaissance skills.

The goal is not just to collect more assets — it is to understand how different pieces of public information connect together to reveal a larger security picture.

Part I: The Conceptual Framework — Why This Works

The Problem with Traditional Subdomain Discovery

Traditional subdomain discovery relies on one thing: the DNS namespace is enumerable. You either brute-force it (guess names) or query passive sources (CT logs, passive DNS).

Both approaches share a fundamental limitation: they only find subdomains that are publicly resolvable or historically logged.

Here’s what they miss:

Private/internal domains (e.g., internal.company.com that only resolves on the corporate VPN)
Pre-production domains that were registered but never deployed to DNS
Acquired company domains that aren’t linked from the parent
Domains used for third-party services (e.g., company.slack.com, company.atlassian.net)
Personal domains used by employees for work purposes

The Email-to-Domain Bridge

Every email address user@domain.com tells you:

The domain exists (obvious, but foundational)
The domain is actively used (someone sent mail from it)
The domain has a user (potential credential, potential account)
The domain is connected to services (GitHub, Slack, Jira, AWS, etc.)

When you collect thousands of email addresses associated with a company, and you extract every domain from those emails, you build a corporate domain graph that DNS brute-force can never replicate.

The Phone-to-Domain Bridge

Every phone number +1 (415) 555-0199 tells you:

The company exists at a physical location (office, data center)
The company uses a specific VOIP provider (Twilio, RingCentral, Vonage)
The company has registered infrastructure (WHOIS records, business registries)
The company has extensions (which map to departments, which map to services)

When you collect phone numbers and reverse-search them, you find domains that were registered with those same phone numbers — often from before the company had a proper security team.

Part II: Phone Number → Domain Discovery

Phone numbers are a persistent identifier. Companies change domains more often than they change phone numbers. A domain registered in 2005 with a phone number is still associated with that company today — even if the domain is forgotten.

Technique 1: WHOIS Phone Number Search

Every domain registration includes a phone number. SecurityTrails, WhoisXMLAPI, and DomainTools allow you to search by phone number to find all domains registered with it.

#!/bin/bash
# phone-to-domain.sh - Find domains registered with a specific phone number
PHONE="$1"

# Using WhoisXMLAPI (paid, but worth it)
curl -s "https://www.whoisxmlapi.com/whoisserver/WhoisService?apiKey=$API_KEY&domainName=$PHONE&outputFormat=JSON" | \
    jq -r '.WhoisRecord.registryData.registrarName // empty'

# Using DomainTools (requires API key)
curl -s "https://api.domaintools.com/v1/$PHONE/domains/" \
    -u "$DOMAINTOOLS_USER:$DOMAINTOOLS_KEY" | \
    jq -r '.response.domains[]'

# Manual: Reverse WHOIS lookup on SecurityTrails
# https://securitytrails.com/list/phone/$PHONE

What this finds: Every domain that was ever registered with that phone number — including domains for subsidiaries, defunct products, and personal projects.

Technique 2: Business Registry Phone Search

Every corporation in the US registers with a state business registry. These registries include phone numbers. You can search by phone number to find all corporations registered under that number.

# OpenCorporates API
curl -s "https://api.opencorporates.com/v0.4/companies/search?q=$PHONE&api_token=$TOKEN" | \
    jq -r '.results[].company.name'

# State-specific registries (examples)
# California: https://businesssearch.sos.ca.gov/
# Delaware: https://icis.corp.delaware.gov/
# Texas: https://mycpa.cpa.state.tx.us/coa/

What this finds: Legal entities, DBAs, and subsidiaries that aren’t publicly linked to the parent company.

Technique 3: Phone Number Reverse Lookup Services

# Twilio Lookup API
curl -s "https://lookups.twilio.com/v1/PhoneNumbers/$PHONE?Type=carrier&Type=caller-name" \
    -u "$TWILIO_SID:$TWILIO_TOKEN" | \
    jq '.carrier.name, .caller_name.caller_name'

# Numverify
curl -s "https://apilayer.net/api/validate?access_key=$KEY&number=$PHONE" | \
    jq '.carrier, .location, .line_type'

# Manual: Whitepages reverse lookup

What this finds: The carrier name (VOIP provider), which tells you what infrastructure to attack, and sometimes the registered business name.

Technique 4: Breach Data Phone Search (Authorized Only)

If you have authorized access to breach databases:

# Dehashed search by phone
curl -s "https://api.dehashed.com/v1/search?query=phone:$PHONE&size=1000" \
    -u "$EMAIL:$API_KEY" | \
    jq -r '.entries[].domain' | sort -u

What this finds: Every domain where an account was registered with that phone number — including internal systems, VPN portals, and employee benefits portals.

Real-World Example: Phone-to-Domain Discovery

Target: Large healthcare tech company. Scope: *.healthtech.com.

I found the company’s main phone number from their contact page: +1 (617) 555-0100.

I ran a WHOIS phone number search:

# SecurityTrails reverse WHOIS by phone
# Result: 47 domains registered with +1.617.555.0100

Among those 47 domains:

47 domains

Critical find: internal-healthtech.com was registered with the same phone number but was not on any subdomain list. It resolved to a private IP range (10.x.x.x) from the outside, but it hosted an internal tool portal accessible via VPN. The VPN wasn't in scope either — until I found it through the phone number.

Part III: Email Address → Domain Discovery

Every email address user@domain.com is a direct pointer to a domain. When you collect thousands of emails associated with a target company, you build a comprehensive domain inventory.

Technique 1: Cross-Company Email Analysis

When employees from Company A and Company B communicate, email headers reveal both domains. If you find john@company-a.com and jane@company-b.com in the same email chain, they're connected.

# From breach data (authorized): find which domains appear alongside the target domain
# From leaked email threads: extract all sender/receiver domains
# From public mailing lists: find cross-company email patterns

What this finds: Business relationships — partners, vendors, clients, and acquired companies.

Technique 2: The Hunter.io API Multi-Domain Search

Hunter.io allows you to search by domain AND by company name. The company name search returns emails from multiple domains:

# Search by company name
curl -s "https://api.hunter.io/v2/company/domain?company=healthtech&api_key=$KEY" | \
    jq -r '.data.domains[]'

# Result:
# healthtech.com
# healthtech.io
# healthtech.dev
# healthtech-careers.com
# healthtech-benefits.com

What this finds: All domains associated with a company name, including HR, benefits, and internal tool domains.

Technique 3: Email-to-GitHub-to-Domain Chain

This is one of the most powerful discovery chains in bug hunting:

Collect employee email: alice@healthtech.com
Search GitHub for that email: finds Alice’s GitHub account
Look at Alice’s GitHub repos, commits, and organizations
Find references to other domains in code, configs, and commit messages

#!/bin/bash
# email-to-github-to-domains.sh
EMAIL="$1"

# Step 1: Find GitHub account
echo "[*] Searching GitHub for $EMAIL..."
curl -s "https://api.github.com/search/users?q=$EMAIL+in:email" | \
    jq -r '.items[].login' > github_users.txt

# Step 2: For each GitHub user, find their repos and orgs
while read USER; do
    echo "[*] Checking user: $USER"
    
    # Get user's repos
    curl -s "https://api.github.com/users/$USER/repos?per_page=100" | \
        jq -r '.[].full_name' >> repos.txt
    
    # Get organizations
    curl -s "https://api.github.com/users/$USER/orgs" | \
        jq -r '.[].login' >> orgs.txt
    
    sleep 2  # Rate limiting
done < github_users.txt

# Step 3: Search repo contents for domain references
while read REPO; do
    echo "[*] Searching repo: $REPO"
    
    # Search code for domain patterns
    curl -s "https://api.github.com/search/code?q=repo:$REPO+healthtech" | \
        jq -r '.items[].html_url' >> code_refs.txt
    
    # Search commit messages for domain references
    curl -s "https://api.github.com/search/commits?q=repo:$REPO+healthtech" | \
        jq -r '.items[].html_url' >> commit_refs.txt
    
    sleep 2
done < repos.txt

What this finds: Internal domains referenced in code comments, config files, READMEs, and commit messages.

Technique 4: Email-to-Breach-to-Domain Correlation

When an employee’s email appears in a breach, you can see what service they were using and what domain was involved:

# Dehashed query (authorized)
curl -s "@healthtech.com&size=10000">https://api.dehashed.com/v1/search?query=email:@healthtech.com&size=10000" \
    -u "$EMAIL:$API_KEY" | \
    jq -r '.entries[] | "\(.domain) \(.email) \(.password)"' | sort -u

# Extract unique domains
curl -s "@healthtech.com&size=10000">https://api.dehashed.com/v1/search?query=email:@healthtech.com&size=10000" \
    -u "$EMAIL:$API_KEY" | \
    jq -r '.entries[].domain' | sort -u > breached-domains.txt

What this finds: Domains where employees had accounts — including personal projects, side businesses, and services they used for work purposes (sometimes on unmanaged infrastructure).

Technique 5: Email-Specific Subdomain Discovery

Services like Have I Been Pwned, Firefox Monitor, and custom tools can tell you which subdomains of a company have accounts registered:

# Check if a subdomain has active accounts
# For Office 365: login.microsoftonline.com will reveal tenant info
# For Atlassian: company-name.atlassian.net
# For Slack: company-name.slack.com
# For GitHub: github.com/orgs/CompanyName

# Using emails to discover the company's Atlassian instance:
for email in $(cat emails.txt); do
    # Check for Atlassian account
    response=$(curl -s -o /dev/null -w "%{http_code}" \
        "https://healthtech.atlassian.net/rest/analytics/1.0/user/is-licensed?username=$email")
    
    if [ "$response" == "200" ] || [ "$response" == "401" ]; then
        echo "Atlassian domain found: healthtech.atlassian.net"
        break
    fi
done

Real-World Example: Email-to-Domain Discovery Chain

Target: Financial services company finsecure.com.

I collected 2,400 emails using Hunter.io, theHarvester, and LinkedIn scraping. Among them was devops@finsecure.com.

GitHub search on devops@finsecure.com: Found a GitHub account finsecure-devops with a private repo (misconfigured visibility).

Repo contents revealed:

deploy.config with DB_HOST=mariadb.internal.finsecure.com
terraform.tf with bucket = "finsecure-terraform-state"
README.md with See internal docs at docs.internal.finsecure.com

New domains discovered:

internal.finsecure.com — Not in any CT log or DNS record
docs.internal.finsecure.com — Subdomain of the above
mariadb.internal.finsecure.com — Internal database hostname
finsecure-terraform-state.s3.amazonaws.com — S3 bucket with terraform state

The S3 bucket was publicly listable. It contained AWS access keys. The AWS keys gave access to the production environment.

Chain: 1 email → 1 GitHub account → 1 repo → 4 new domains → 1 S3 bucket → AWS root access.

Part IV: Phone Number + Email → Subdomain Discovery (The Real Gold)

When you combine phone numbers and emails, you unlock subdomain discovery that no DNS tool can match.

Technique 1: WHOIS Contact Cross-Reference

Company domains are often registered by the same person. If you find the registrant’s name and email from one domain, you can find all other domains they’ve registered:

# Step 1: Get WHOIS info for the main domain
whois healthtech.com | grep -E "Registrant|Admin|Tech|Email" > whois-info.txt

# Step 2: Extract registrant name and email
NAME=$(grep "Registrant Name" whois-info.txt | awk -F: '{print $2}' | xargs)
EMAIL=$(grep "Registrant Email" whois-info.txt | awk -F: '{print $2}' | xargs)

# Step 3: Search for other domains with same registrant
# Using WhoisXMLAPI
curl -s "https://www.whoisxmlapi.com/whoisserver/WhoisService?apiKey=$API_KEY&domainName=$NAME&outputFormat=JSON" | \
    jq -r '.WhoisRecord.registryData.registrantDomains[]'

# Using DomainTools Reverse WHOIS
curl -s "https://api.domaintools.com/v1/$NAME/domains/" \
    -u "$DOMAINTOOLS_USER:$DOMAINTOOLS_KEY" | \
    jq -r '.response.domains[]'

Technique 2: Social Media Profile Mining

Employee LinkedIn profiles often list multiple domains:

Current: Senior Engineer at HealthTech (healthtech.com)
Past: Lead Developer at MedData (meddata.io)
Education: MIT (mit.edu)

Each of these is a domain that may or may not be in scope. If meddata.io was acquired by healthtech.com, then meddata.io infrastructure is likely part of the target's attack surface.

# LinkedIn scraper (requires authentication)
# Extract: current company, past companies, education
# Cross-reference with known acquisitions

# For each past company found on LinkedIn profiles:
# Check if it was acquired by the target
# If yes: run full acquisition pipeline on that domain

Technique 3: Support Portal and Help Desk Domains

Phone numbers often lead to support portals, which lead to subdomains:

# Call the company's support number
# Listen for automated messages:
# "Press 1 for billing" → billing.helpdesk.com
# "Press 2 for technical support" → support.helpdesk.com
# "Press 3 for sales" → sales.helpdesk.com

# These are subdomains of the support portal domain
# Check if they resolve, check for takeovers

# Also check: support@company.com → Zendesk, Freshdesk, Helpscout
# Zendesk: company.zendesk.com
# Freshdesk: company.freshdesk.com
# Helpscout: company.helpscout.net

Technique 4: Email Header Subdomain Discovery

If you can obtain a legitimate email from the company (e.g., by signing up for their newsletter), the email headers reveal internal infrastructure:

Received: from mail.healthtech.com (192.168.1.10)
Received: from mx1.healthtech.com (203.0.113.5)
Received: from smtp-in.healthtech.com (198.51.100.20)
DKIM-Signature: d=healthtech.com; s=selector1
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of newsletter@healthtech.com designates 203.0.113.5 as permitted sender)

Each of these IPs and hostnames is a potential subdomain:

mail.healthtech.com
mx1.healthtech.com
smtp-in.healthtech.com

Real-World Example: Phone + Email → Subdomain Discovery

Target: SaaS company cloudserve.com.

Phone number from WHOIS: +1 (425) 555-0100 (Seattle area)

Email from WHOIS: admin@cloudserve.com

Step 1: WHOIS reverse search on phone number Found 12 domains, including:

cloudserve.io (known)
cloudserve-backup.com (unknown — registered 2008)
cs-legacy.com (unknown — registered 2005)

Step 2: WHOIS reverse search on email Found 8 more domains:

cloudserve-status.com (status page — known but useful)
cloudserve-dev.com (development — not in scope docs)

Step 3: Emails collected from Hunter.io 1,800 emails. Found devops@cloudserve.com in a GitHub commit.

Step 4: DevOps email → GitHub repos Found a repo with monitoring.cloudserve.com hardcoded in a config file.

Step 5: Subdomain enumeration on new domains

subfinder -d cloudserve-backup.com -silent
# Found: admin.cloudserve-backup.com
# Found: db.cloudserve-backup.com

Result: 14 new domains and 47 new subdomains discovered through phone and email OSINT alone. DNS brute-force against the main domain found none of these.

Part V: Building the Phone-to-Email-to-Domain Pipeline

Here’s a practical automated pipeline that can be used for this workflow.

Phase 1: Phone Number Collection & Analysis

#!/bin/bash
# phase1-phone-collect.sh
TARGET="$1"
DOMAIN="$2"

echo "[*] Phase 1: Phone Number Collection"

# 1a. WHOIS extraction
whois "$DOMAIN" 2>/dev/null | grep -oP '(\+?\d{1,3}[-.\s]?)?\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}' > phones.txt

# 1b. Web scraping for phone numbers
katana -u "https://$DOMAIN" -d 2 -silent | \
    grep -oP '(\+?\d{1,3}[-.\s]?)?\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}' >> phones.txt

# 1c. Business directories
curl -s "https://api.opencorporates.com/v0.4/companies/search?q=$DOMAIN" | \
    jq -r '.results[].company.phone_number' 2>/dev/null | grep -v null >> phones.txt

# Deduplicate
sort -u phones.txt -o phones.txt
echo "[*] Found $(wc -l < phones.txt) unique phone numbers"

Phase 2: Phone → Domain Mapping

#!/bin/bash
# phase2-phone-to-domain.sh
TARGET="$1"

echo "[*] Phase 2: Phone to Domain Mapping"

while read PHONE; do
    echo "[*] Processing phone: $PHONE"
    
    # 2a. Reverse WHOIS by phone (if you have access)
    # DomainTools API
    # curl -s "https://api.domaintools.com/v1/$PHONE/domains/" -u "$USER:$KEY" | \
    #     jq -r '.response.domains[]' >> phone-domains.txt
    
    # 2b. SecurityTrails (manual or API)
    # curl -s "https://api.securitytrails.com/v1/search?query=whois.phone:$PHONE" \
    #     -H "APIKEY: $ST_KEY" | jq -r '.records[].hostname' >> phone-domains.txt
    
    # 2c. Breach data (authorized)
    # dehashed API
    # curl -s "https://api.dehashed.com/v1/search?query=phone:$PHONE" \
    #     -u "$EMAIL:$DEHASHED_KEY" | jq -r '.entries[].domain' >> phone-domains.txt
    
    sleep 1
done < phones.txt

sort -u phone-domains.txt -o phone-domains.txt
echo "[*] Found $(wc -l < phone-domains.txt) domains from phone numbers"

Phase 3: Email Collection

#!/bin/bash
# phase3-email-collect.sh
DOMAIN="$1"

echo "[*] Phase 3: Email Collection"

# 3a. Hunter.io
curl -s "https://api.hunter.io/v2/domain-search?domain=$DOMAIN&api_key=$HUNTER_KEY" | \
    jq -r '.data.emails[].value' > emails-hunter.txt

# 3b. theHarvester
theHarvester -d "$DOMAIN" -b google,linkedin,github -f /dev/null 2>/dev/null | \
    grep -oP '[a-zA-Z0-9._%+-]+@'"$DOMAIN" > emails-harvester.txt

# 3c. Skymem
curl -s "https://www.skymem.info/srch?q=$DOMAIN" | \
    grep -oP '[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]*\.?'"$DOMAIN" > emails-skymem.txt

# 3d. Web page extraction
katana -u "https://$DOMAIN" -d 2 -silent | \
    grep -oP '[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]*\.?'"$DOMAIN" > emails-web.txt

# 3e. JS file extraction
katana -u "https://$DOMAIN" -jc -silent | xargs -I{} curl -s {} 2>/dev/null | \
    grep -oP '[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]*\.?'"$DOMAIN" > emails-js.txt

# Combine
cat emails-hunter.txt emails-harvester.txt emails-skymem.txt emails-web.txt emails-js.txt | \
    sort -u > emails.txt

echo "[*] Found $(wc -l < emails.txt) unique email addresses"

Phase 4: Email → Domain Extraction

#!/bin/bash
# phase4-email-to-domain.sh
DOMAIN="$1"

echo "[*] Phase 4: Email to Domain Extraction"

# 4a. Extract all domains from email addresses
grep -oP '@[a-zA-Z0-9.-]+' emails.txt | sed 's/@//' | sort -u > email-domains.txt

# 4b. Remove the main domain (keep only non-obvious domains)
grep -v "$DOMAIN" email-domains.txt > other-domains.txt

echo "[*] Found $(wc -l < email-domains.txt) total domains from emails"
echo "[*] Found $(wc -l < other-domains.txt) domains OUTSIDE the main domain"

Phase 5: LinkedIn → Name → Email → Domain

#!/bin/bash
# phase5-linkedin-to-domains.sh
TARGET="$1"
DOMAIN="$2"

echo "[*] Phase 5: LinkedIn Name to Email to Domain"

# 5a. Scrape LinkedIn for employees (manual or with tool)
# linkedin_scraper -c "$TARGET" -o linkedin-employees.csv

# 5b. Extract past companies from LinkedIn profiles
# awk -F, '{print $3}' linkedin-employees.csv | sort -u > past-companies.txt

# 5c. For each past company, check if it's in scope
while read COMPANY; do
    echo "[*] Checking past company: $COMPANY"
    
    # Search for the company's domain
    domain_from_name=$(echo "$COMPANY" | tr '[:upper:]' '[:lower:]' | sed 's/ //g').com
    nslookup "$domain_from_name" > /dev/null 2>&1 && echo "$domain_from_name" >> past-company-domains.txt
    
done < past-companies.txt

# 5d. For each past company domain, check if acquired by target
# Manual step: verify acquisition history

Phase 6: Cross-Reference and Subdomain Enumeration on New Domains

#!/bin/bash
# phase6-subdomain-enum.sh
DOMAIN="$1"

echo "[*] Phase 6: Subdomain Enumeration on All Discovered Domains"

# Combine all domain lists
cat phone-domains.txt other-domains.txt past-company-domains.txt | sort -u > all-discovered-domains.txt

# Run subdomain enumeration on each
while read DISCOVERED_DOMAIN; do
    echo "[*] Enumerating: $DISCOVERED_DOMAIN"
    
    # CT logs
    curl -s "https://crt.sh/?q=%25.$DISCOVERED_DOMAIN&output=json" | \
        jq -r '.[].name_value' 2>/dev/null >> all-subs.txt
    
    # Subfinder
    subfinder -d "$DISCOVERED_DOMAIN" -silent >> all-subs.txt
    
    # DNS brute-force
    puredns bruteforce ~/wordlists/subdomains.txt "$DISCOVERED_DOMAIN" \
        -r ~/resolvers.txt -q >> all-subs.txt
    
done < all-discovered-domains.txt

sort -u all-subs.txt -o all-subs.txt
echo "[*] Total subdomains discovered: $(wc -l < all-subs.txt)"

Part VI: The Complete Real-World Workflow

To understand how this methodology works in practice, let's walk through an anonymized example of how phone numbers, emails, and public intelligence can reveal hidden assets. payflow.com

08:00 — Phone Collection

# WHOIS
whois payflow.com | grep -E "Phone|Tel"
# +1 (415) 555-0100

# Contact page
katana -u https://payflow.com/contact -d 1 | grep -oP '(\+?\d{1,3}[-.\s]?)?\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}'
# +1 (415) 555-0100 (same)
# +1 (512) 555-0200 (different — Austin)

# Business registry
curl -s "https://api.opencorporates.com/v0.4/companies/search?q=payflow" | \
    jq -r '.results[].company.phone_number'
# +1 (512) 555-0200
# +1 (512) 555-0300 (NEW — unknown)

Phone numbers collected:

+1 (415) 555-0100 (San Francisco — HQ)
+1 (512) 555-0200 (Austin — known office)
+1 (512) 555-0300 (Austin — UNKNOWN)

08:30 — Phone → Domain

# SecurityTrails reverse WHOIS by phone
# +1 (512) 555-0300 → registered to:
# payflow-holdings.com
# payflow-ventures.com
# pf-internal.com

New domains discovered:

payflow-holdings.com — Holding company
payflow-ventures.com — Venture arm
pf-internal.com — INTERNAL DOMAIN

09:00 — Email Collection

# Hunter.io: 847 emails
# theHarvester: 312 emails
# Skymem: 1,204 emails
# Web scraping: 89 emails
# JS files: 34 emails
# Total unique: 1,892 emails

09:30 — Email → Domain Extraction

grep -oP '@[a-zA-Z0-9.-]+' emails.txt | sed 's/@//' | sort -u

# Unique domains found in emails (excluding payflow.com):
# payflow.io (known)
# payflow.co (NEW)
# payflow-engineering.com (NEW — engineering team domain)
# pf-payments.com (NEW — payments processing domain)
# payflow-benefits.com (NEW — HR/benefits domain)

10:00 — GitHub Cross-Reference

# Searched for devops@payflow.com on GitHub
# Found GitHub user: payflow-devops
# Scanned repos for domain references

# Found in deploy configs:
# monitoring.internal.payflow.com
# logs.internal.payflow.com
# ci.internal.payflow.com

10:30 — Subdomain Enumeration on New Domains

# On pf-internal.com:
subfinder -d pf-internal.com -silent
# vpn.pf-internal.com (LIVE)
# jenkins.pf-internal.com (LIVE)
# git.pf-internal.com (LIVE)

# On payflow-engineering.com:
subfinder -d payflow-engineering.com -silent
# dev.payflow-engineering.com (LIVE)
# staging.payflow-engineering.com (LIVE)
# api.payflow-engineering.com (LIVE)

11:00 — Priority Assessment

P0:

vpn.pf-internal.com — VPN portal (potential credential access)
jenkins.pf-internal.com — Jenkins (potential RCE)
pf-internal.com — Internal domain (potential for more discovery)

P1: 4. payflow-engineering.com — Engineering domain (dev/staging instances) 5. payflow-holdings.com — Holding company (potential subsidiary assets) 6. monitoring.internal.payflow.com — Monitoring (potential Grafana/Prometheus)

11:30 — Attack Phase

Jenkins on pf-internal.com:

No authentication required
Created a freestyle project with a reverse shell
Got shell access to the Jenkins server
Jenkins had AWS keys in environment variables
AWS keys had full admin access to production

Chain: 1 phone number → 3 unknown phone numbers → 1 unknown domain → 3 subdomains → 1 Jenkins server → AWS root access.

Part VII: Tool Reference Guide

Phone Number Tools

Email Collection Tools

Cross-Reference Tools

Part VIII: Common Mistakes (From Personal Experience)

Mistake 1: Not Checking All Phone Numbers from WHOIS

A common mistake is finding one phone number in WHOIS and stopping too early, ran my reverse search, and stopped. There were actually three different phone numbers across different domains — I missed two.

Fix: Extract EVERY phone number from EVERY WHOIS record for EVERY domain you find.

Mistake 2: Ignoring Email Domains That Don’t Match the Target

What happened: I collected 2,000 emails for target.com. I filtered out everything that wasn't @target.com. I missed the 200 emails with @target-engineering.com, @target-holdings.com, and @target-benefits.com — all of which were owned by the same company.

Fix: Extract ALL unique domains from your email collection, not just the primary domain.

Mistake 3: Not Checking LinkedIn Past Companies

What happened: An employee’s LinkedIn profile showed they previously worked at acme-solutions.com. I ignored it. Acme Solutions had been acquired by my target three years prior. Its infrastructure was in scope but I never checked it.

Fix: Scrape past companies from LinkedIn profiles and cross-reference with acquisition history.

Mistake 4: Not Running Subdomain Enumeration on Each New Domain

What happened: I found pf-internal.com and added it to my list. I didn't run subfinder or CT log queries against it. vpn.pf-internal.com was sitting there the whole time.

Fix: Run full subdomain enumeration on EVERY domain you discover, no exceptions.

Mistake 5: Stopping After One Round

What happened: I discovered new domains, ran subfinder once, and started attacking. I didn’t recurse. Some of those new domains had their own subdomains, and those subdomains had their own CT logs.

Fix: Recursive enumeration. Every new domain → full acquisition pipeline → find more domains → repeat.

Bug Hunter Acquisition Checklist — Phone & Email Edition

☐ Phone Number Collection

☐ WHOIS records extracted for all discovered domains
☐ Contact/scraped pages (main site, subdomains, subsidiaries)
☐ Business registries checked (OpenCorporates, state registries)
☐ SEC filings reviewed (10-K, 10-Q, S-1)
☐ Press releases and news articles mined
☐ Social media profiles checked (LinkedIn, Twitter, Facebook)
☐ Breach data queried (with authorization)

☐ Phone Number Analysis

☐ VOIP provider identified for each number
☐ Area codes mapped to physical office locations
☐ Multi-number comparison for organizational structure
☐ Extension patterns identified
☐ Reverse WHOIS by phone number completed
☐ Business registry search by phone completed
☐ Phone number range scanning (if applicable)

☐ Phone → Domain Mapping

☐ Reverse WHOIS for every unique phone number
☐ Business registry domain mapping
☐ Carrier/VOIP provider infrastructure checked
☐ Support portal domains discovered (Zendesk, Freshdesk, etc.)
☐ VOIP admin console exposure checked
☐ Webhook endpoint testing (if Twilio/RingCentral identified)

☐ Email Collection

☐ Hunter.io domain search completed
☐ theHarvester multi-source harvest completed
☐ Skymem cross-reference completed
☐ Web page email extraction completed
☐ JavaScript file email extraction completed
☐ LinkedIn employee name scraping completed
☐ GitHub commit email extraction completed
☐ Mailing list/public forum extraction completed
☐ Breach data email extraction (with authorization)

☐ Email → Domain Extraction

☐ All unique domains extracted from email addresses
☐ Primary domain filtered out to reveal hidden domains
☐ Subsidiary/acquired company domains identified
☐ Internal/private domains identified
☐ Third-party service domains identified
☐ Employee personal domains identified

☐ Email → GitHub → Domain Chain

☐ GitHub accounts found for employee emails
☐ Repos and commits scanned for domain references
☐ Organization discovery completed
☐ Config files and environment vars checked
☐ Hardcoded endpoints extracted
☐ S3 bucket names and cloud resources extracted

☐ Email → Service → Domain Chain

☐ Atlassian (Jira/Confluence) instance discovered
☐ Slack workspace discovered
☐ Microsoft 365 tenant discovered
☐ Google Workspace tenant discovered
☐ Zendesk/Freshdesk/Helpscout portal discovered
☐ Status page hosted domain discovered
☐ Documentation/wiki hosted domain discovered

☐ Full Subdomain Enumeration on New Domains

☐ CT log queries (crt.sh, certspotter) for each new domain
☐ Passive DNS queries (SecurityTrails, VirusTotal)
☐ Subdomain brute-force (subfinder, puredns, massdns)
☐ Permutation-based discovery (alterx, gotator, dmut)
☐ Recursive enumeration (each subdomain → parent as new target)
☐ Wayback Machine historical subdomain discovery
☐ Technology fingerprinting (httpx, whatweb)
☐ HTTP response analysis (live vs. dead, redirects, error pages)

☐ Cross-Reference Validation

☐ Phone numbers matched to discovered domains
☐ Emails matched to discovered domains
☐ LinkedIn past companies cross-referenced with acquisitions
☐ GitHub profiles cross-referenced with company email domains
☐ Breach data cross-referenced (correlates emails, phones, domains)
☐ Scope validation for every newly discovered asset

☐ Continuous Monitoring

☐ Daily CT log monitoring for new subdomains on discovered domains
☐ Weekly phone number re-check (new WHOIS entries)
☐ Weekly email re-harvesting (new employees, new domains)
☐ GitHub monitoring for new employee commits
☐ Acquisition news monitoring (Google Alerts, Crunchbase)
☐ LinkedIn employee movement tracking
☐ Quarterly full pipeline re-run

Final Technical Notes

Why This Works at Scale

The average Fortune 500 company has:

50–200 registered domains
10–50 subsidiaries/acquired entities
2,000–20,000 employees
5–20 different phone numbers

DNS brute-force will find maybe 30–50% of the subdomains on the main domain. It will find almost none of the subdomains on other domains.

Phone and email OSINT finds the other domains. Then you run DNS brute-force on those. The result is a 3–5x increase in discovered attack surface.

The Data Flow

Phone Number → Reverse WHOIS → New Domains
Phone Number → Business Registry → Legal Entities → New Domains
Phone Number → VOIP Provider → Admin Console → Subdomains

Email Address → Hunter.io → Cross-Company Domains
Email Address → GitHub → Repos → Configs → Domains
Email Address → Breach Data → Service Registrations → Domains
Email Address → LinkedIn → Past Companies → Acquired Domains

New Domains → Subdomain Enumeration → Attack Surface

A Final Word on Authorization

Everything in this blog assumes you have explicit written authorization to test the target’s assets. I do not share the names of actual targets. All examples are anonymized composites of real engagements.

If you’re new to bug bounty:

Start with public programs on HackerOne/Bugcrowd that explicitly allow OSINT
Never use breach data unless the program explicitly permits it
Never use social engineering unless the program explicitly permits it
When in doubt, ask the program’s security team

Disclaimer: Only for authorized bug bounty / pentesting environments.

GitHub: SecurityTalent | Medium: Security Talent | Twitter: Securi3yTalent | Facebook: Securi3ytalent | Telegram: Securi3yTalent

#BugBounty #OSINT #CyberSecurity #EthicalHacking #Infosec #PenetrationTesting #AttackSurface #SubdomainEnumeration #ThreatHunting #SecurityResearch #RedTeam #DigitalFootprint #CyberSecurity #BugBounty #BugBountyHunter #EthicalHacking #InfoSec #WebSecurity #ApplicationSecurity #AppSec #CloudSecurity #FrontendSecurity #WebDevelopment #JavaScript #ReactJS #Laravel #NodeJS #DevSecOps #OWASP #SecretsManagement #GitHub #GitHubDorks #SourceMaps #EnvFiles #SecurityResearch #PenetrationTesting #RedTeam #BlueTeam #CloudComputing #AWS #Azure #GoogleCloud #VibeCoding #AI #SecureCoding #DeveloperSecurity #TechBlog #Programming

Phone Numbers and Emails to Hidden Subdomains: The OSINT Acquisition Pipeline That Uncovered a… was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

v2.1.183

Fri, 19 Jun 2026 03:50:11 +0200

What's changed

Improved auto mode safety: destructive git commands (git reset --hard, git checkout -- ., git clean -fd, git stash drop) are now blocked when you didn't ask to discard local work, git commit --amend is blocked when the commit wasn't made by the agent this session, and terraform destroy/pulumi destroy/cdk destroy are blocked unless you asked for the specific stack
Added a warning when the requested model is deprecated or automatically updated to a newer model, shown on stderr in print mode (-p) and now also covering models set in agent frontmatter
Added attribution.sessionUrl setting to omit the claude.ai session link from commits and PRs in web and Remote Control sessions
Added /config --help to list all available shorthand keys for /config key=value
Changed /config toggle behavior: Enter and Space both change the selected setting, and Esc now saves and closes instead of reverting
Removed the startup "setup issues" line under the logo — run /doctor to see configuration issues or use --debug
Fixed thinking.disabled.display: Extra inputs are not permitted 400 errors on subagent spawns and session-title generation for affected configurations
Fixed WebSearch returning empty results in subagents
Fixed the terminal cursor being stranded above the prompt after navigating history in vim mode with the native cursor enabled
Fixed fullscreen TUI corruption (statusline mid-screen, duplicated spinner rows, merged text) in Windows Terminal under heavy nested-subagent load
Fixed turns silently completing with no visible output when the model returned only a thinking block; Claude now re-prompts once
Fixed user-level skills appearing multiple times in slash-command autocomplete when multiple plugins are enabled
Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode
Fixed tmux teammate panes failing to launch when the shell has slow rc-file initialization, and keystrokes typed during agent spawn leaking into the new tmux pane instead of the leader prompt
Fixed background tasks started by a teammate being killed when the teammate finishes a turn
Fixed scheduled task and webhook trigger deliveries being treated as keyboard input; they now classify as task notifications and can no longer approve a pending action or set the session title in auto mode
Fixed focus mode showing "Ran N PostToolUse hooks" timing lines under each response

Terraform Alternatives in 2026: OpenTofu, Pulumi, Crossplane, and What Actually Fits Your Team

Wed, 17 Jun 2026 11:09:15 +0200

In this post, I will talk about the best Terraform alternatives in 2026 and discuss OpenTofu, Pulumi, Crossplane, and what actually fits your team. Back in 2023, when HashiCorp changed Terraform’s license, a lot of teams were caught off guard. Suddenly, everyone had to figure out: do we keep using Terraform, or is it time […]

The post Terraform Alternatives in 2026: OpenTofu, Pulumi, Crossplane, and What Actually Fits Your Team appeared first on SecureBlitz Cybersecurity.

How to Migrate from Terraform to OpenTofu on Rocky Linux 9 (2026 Guide)

Tue, 16 Jun 2026 05:13:22 +0200

Marcus’s DevOps Brief: I have been running Terraform in production for four years across Kubernetes clusters and cloud deployments. When HashiCorp switched to the Business Source License in 2023, my team spent two weeks evaluating OpenTofu before making the jump.…

IBM, ServiceNow team to bring AI to legacy enterprise systems

Thu, 11 Jun 2026 21:05:39 +0200

IBM and ServiceNow are teaming up for new services they say will help enterprise customers bring aging legacy environments into an AI-ready infrastructure.

The collaboration will combine IBM’s AI, data, and automation capabilities and ServiceNow’s AI platform for a variety of offerings that will modernize aging systems, enable autonomous IT operations, and help organizations evolve existing systems rather than replace them, the companies stated. ServiceNow says its AI-Platform offers a workflow layer that sits on top of an enterprise’s existing systems and helps automate work across them.

Decades of deeply interconnected legacy systems are the biggest barrier to moving fast on AI, the companies stated. Their pairings will take advantage of Big Blue’s expertise in working with large systems, such as its mainframe environment, and extensive legacy applications, along with ServiceNow’s workflow and agent management platforms.

“Most enterprises have the ambition to deploy agentic AI, but lack the foundation to run it at scale,” said John Aisien, senior vice president and general manager, central product management, security and risk, at ServiceNow. “IBM brings the tooling to modernize the systems and extend ServiceNow’s data capabilities. ServiceNow provides the platform to put that data to work across every workflow in the business.”

The vendors will focus on three core services that will be available in the second half of 2026:

Application modernization: Scans and refactors legacy systems using tools like IBM Bob, Enterprise Application runtime (Java) and IBM watsonx.data to help enterprises bring existing applications into the AI era without starting from scratch.
Autonomous infrastructure operations: Integrates Red Hat Ansible, IBM Bob, Instana, Hashicorp Terraform, and Hashicorp Vault into ServiceNow IT workflows to detect, remediate, and resolve issues before they affect the business.
Data governance: Extends ServiceNow Workflow Data Fabric with IBM watsonx.data to unlock key capabilities like Data Quality, Observability, Master Data Management – employing the ServiceNow Data Catalog so that mutual customers can keep track of their AI-ready data.

IBM and ServiceNow have a long-standing relationship, having worked together to help large enterprise customers implement everything from cloud computing, automation, and security to IT service management and observability technologies.

10 MCP-Server für DevOps

Thu, 04 Jun 2026 06:06:56 +0200

DevOps ist mit Aufwand und Kosten verbunden. Mit MCP aufzurüsten, macht deshalb Sinn.

PeopleImages | shutterstock.com

KI-Agenten für Programmierer haben sich zu einem beeindruckenden Hilfsmittel entwickelt. Allerdings sind diese Agenten nur begrenzt einsetzbar, wenn sie nicht auch mit modernen DevOps-Tools kompatibel sind. An dieser Stelle kommt das Model Context Protocol (MCP) ins Spiel. Der von Anthropic Ende 2024 veröffentlichte Standard verbindet KI-Systeme mit externen Tools und Daten.

Mit Blick auf DevOps stehen KI-Agenten damit neue Fähigkeiten offen – etwa:

Versionskontrollen mit Git,
Continuous Integration & Deployment (CI/CD),
Infrastructure as Code (IaC),
Observability, oder
Zugriff auf Dokumentationen.

Im Folgenden werfen wir einen Blick auf zehn offizielle MCP-Server, die populären DevOps-Tools und -Plattformen entsprungen sind und jeweils unterschiedliche Funktionalitäten abdecken. Diese lassen sich innerhalb MCP-kompatibler KI-Entwicklungs-Tools relativ einfach konfigurieren und mit Berechtigungen ausstatten. Offizielle MCP-Server zu nutzen, hat zudem den Vorteil, dass deren Lebensdauer sehr wahrscheinlich länger ist – und sie durchgängig gewartet und aktualisiert werden.

1. GitHub MCP-Server

Kaum ein Entwickler nutzt GitHub nicht in irgendeiner Form. Deshalb entwickelt sich der offizielle MCP-Server der Plattform zu einer immer beliebteren Methode, um KI-Agenten zu befähigen, mit Code-Repositories zu interagieren – etwa, indem sie Issues erstellen und kommentieren oder Pull Requests zusammenführen.

Außerdem enthält dieser MCP-Server auch Endpunkte für das CI/CD-Management über GitHub Actions. So könnte etwa ein natürlichsprachlicher Befehl wie “Aktuelle Aktion abbrechen” das cancel_workflow_run-Tool innerhalb von GitHub Actions aufrufen.

Der offizielle MCP-Server von GitHub bietet vergleichsweise umfangreiche Funktionen, die die APIs der Plattform widerspiegeln. Damit dabei die Sicherheit nicht zu kurz kommt und KI-Agenten keine Mutationen durchführen, lassen sich jederzeit --read-only-Flags konfigurieren.

2. Notion MCP-Server

Notion ist eher ein KI-Collaboration- als ein DevOps-Tool und hat sich mittlerweile fachbereichsübergreifend etabliert, wenn es darum geht, teamintern Transparenz zu schaffen. Der offizielle MCP-Server von Notion ist jedoch auch aus DevOps-Perspektive nützlich. Damit lassen sich Agenten beispielsweise anweisen, interne Stilrichtlinien oder Betriebshandbücher zu konsultieren, die in Notion gespeichert sind.

Der Remote-MCP-Server von Notion ist über eine IDE abrufbar – kann aber mit dem offiziellen Docker-Image auch lokal aufgesetzt und ausgeführt werden. Dieser MCP-Server ist als risikoarm zu betrachten, da er über konfigurierbare Scopes und Tokens verfügt, um Notion-Seiten und -Blöcke zu managen.

3. Atlassian Remote MCP-Server

Atlassians Remote MCP-Server verbindet IDEs oder Agentic-AI-Plattformen mit den Cloud-Produkten des Unternehmens. Beispielsweise dem Projektmanagement-Tool Jira. Anzumerken ist dabei, dass sich dieser MCP-Server derzeit in der Beta-Phase befindet und Atlassian-Cloud-Kunden vorbehalten ist.

Damit ist es denkbar, einen Agenten anzuweisen, ein Jira-Issue zum Benutzertesting für eine BezahlApp auf der Grundlage eines aktuellen Bug Report zu aktualisieren – und dabei auf die relevanten Protokolle zu verweisen. Die Aktualisierung von Jira läuft anschließend über den MCP-Server.

Der MCP-Server von Atlassian unterstützt diverse Clients und gewährleistet mit Oauth-2.1-Support auch sicheren Zugriff.

4. Argo CD MCP-Server

Auch die Entwickler des populären Open-Source-Tools Argo CD stellen einen MCP-Server zur Verfügung. Dieser fasst Calls an die Argo-CD-API zusammen und enthält Tools, mit denen die Benutzer über natürliche Sprache mit Argo CD interagieren können:

Mit dem Application-Management-Tool können KI-Agenten Anwendungsinformationen abrufen, Anwendungen erstellen und löschen sowie weitere Prozesse ausführen.
Über das Resource-Management-Tool rufen KI-Agenten Ressourceninformationen, Protokolle und Ereignisse für bestimmte Anwendungen ab und führen spezifische Aktionen für bestimmte Ressourcen aus.

Mit Hilfe dieses MCP-Servers lassen sich viele Tasks “natürlichsprachlich” ausführen, die auch über das User Interface oder das CLI-Tool von Argo CD verfügbar sind. Eine Staging-App zu synchronisieren, geht so beispielsweise flotter von der Hand. Damit das auch funktioniert, muss der MCP-Server von Argo CD aber auch ordentlich integriert werden – und benötigt Zugriff auf eine laufende Argo-CD-Instanz inklusive korrekt konfigurierter Anmeldedaten.

5. Grafana MCP-Server

Das Datenvisualisierungs- und Monitoring-Tool Grafana gehört für viele DevOps- und SRE-Teams zum Standardrepertoire. Der offizielle MCP-Server für Grafana befähigt KI-Agenten dazu, Observability-Daten bereitzustellen, um Entwicklungs- oder Betriebsprozesse zu optimieren.

Über diesen MCP-Server können Agenten außerdem vollständige oder teilweise Details aus Dashboards abfragen, die Metriken zur Systemleistung und Health-Daten aus verschiedenen Quellen kombinieren. Darüber hinaus lassen sich über den Grafana MCP-Server auch Informationen zu Datenquellen abrufen, weitere Monitoring-Systeme oder Details zu spezifischen Vorfällen abfragen.

Das Toolset ist dabei konfigurierbar, die Berechtigungen der Agenten können durch den Benutzer definiert werden. Darüber hinaus hat Grafana auch die Antwortstruktur seines MCP-Servers optimiert. Das soll die Nutzung des Kontextfensters minimieren und die Kosten für Token senken. Beispielsweise kann ein MCP-Client das get_dashboard_property-Tool aufrufen, um einen bestimmten Part eines Dashboards anhand seiner UID abzurufen.

6. Terraform MCP-Server

HashiCorp Terraform ist – Alternativen zum Trotz – weiterhin die erste Adresse, wenn es um Infrastructure as Code (IaC) geht. Entsprechend ist der offizielle MCP-Server eine interessante Option, um Terraform-Konfigurationen über KI-Agenten zu generieren und zu managen. Der MCP-Server lässt sich dabei sowohl in die Registry APIs als auch in die Enterprise/HCP-Services von Terraform integrieren. Das ermöglicht KI-Agenten etwa:

Modul- und Anbieter-Metadaten abzufragen,
den Status von Workspaces zu überprüfen, und
Tasks (mit menschlicher Genehmigung) auszulösen.

Ein Befehl wie “Generiere Terraform-Code für einen neuen Run” könnte so die create_run-Operation aufrufen, woraufhin der KI-Agent die Konfiguration validiert und plant, bevor er sie anwendet.

Der Terraform MCP-Server wird mit der Readme-Datei AGENTS.md ausgeliefert. Diese erleichtert es Agenten, Tools zu interpretieren. Aktuell (Stand Dezember 2025) ist der Terraform MCP-Server ausschließlich für die lokale Nutzung verfügbar. Er ist ausdrücklich nicht für Remote- oder gehostete Deployments vorgesehen.

7. GitLab MCP-Server

Auch die GitLab-Plattform stellt – ihren Premium- und Ultimate-Kunden – einen MCP-Server bereit. Dieser befindet sich aktuell in der Beta-Phase und befähigt KI-Agenten dazu, Projetinformationen zu sammeln und Operationen über GitLab-APIs sicher auszuführen.

Der GitLab MCP-Server erlaubt einige Statusänderungen, etwa Issues zu erstellen oder Merge Requests. Die anderen Funktionen dienen hauptsächlich der Datenabfrage – also etwa Informationen zu Issues, Merge-Anfragen, Commits, Diffs und Pipelines abzufragen. Enthalten ist zudem ein allgemeines Suchwerkzeug.

Die Dokumentation des GitLab MCP-Servers ist sehr ausführlich und enthält zahlreiche Beispiele für natürlichsprachliche Ausdrücke, die verarbeiten werden können. Der Server unterstützt zudem die dynamische Client-Registrierung über OAuth 2.0.

8. Snyk MCP-Server

Snyk bietet eine Security-Plattform für Entwickler an – und einen MCP-Server. Dieser kann dazu genutzt werden, mit Hilfe von KI-Agenten (IaC-)Code, Open-Source-Abhängigkeiten, Container sowie SBOMs oder auch AIBOMs auf Schwachstellen zu scannen und diese zu beheben. Den Snyk MCP-Server zu integrieren, ist also dazu geeignet, Sicherheitsscans automatisch im Rahmen eines CI/CD-Workflows mit KI-Agenten durchzuführen. Diese Scans lassen sich sogar über andere MCP-Server hinweg koordinieren, beispielsweise indem Repository-Details über den GitHub MCP-Server abgerufen werden, bevor ein Snyk-Scan gestartet wird.

Ein Prompt wie “Scanne das Authentication-Microservice-Repo auf Sicherheitslücken” könnte einen Agenten anweisen, das Repository mit GitHub MCP zu lokalisieren und dann Snyk-Tools wie snyk_sca_scan oder snyk_code_scan nutzen, um bekannte Schwachstellen, geleakte Anmeldedaten und andere Risiken zu identifizieren.

Dieser MCP-Server wird lokal ausgeführt und verwendet die Snyk-CLI, um Befehle wie diese über authentifizierte API-Calls auszuführen. Das Unternehmen bietet keine gehostete Remote-Version seines MCP-Servers an.

9. AWS MCP-Server

Die Cloud-Hyperscaler haben besonders eifrig daran gearbeitet, schnell MCP-Server auf die Beine zu stellen, die sich in ihre Ökosysteme integrieren lassen. Amazon Web Services (AWS) hat beispielsweise Dutzende spezialisierter MCP-Server eingeführt, die KI-Agenten ermöglichen, mit sämtlichen Arten von AWS-Services zu interagieren. Einige davon werden als vollständig gemanagte Dienste angeboten, andere können hingegen nur lokal ausgeführt werden.

So können KI-Agenten über den Lambda Tool MCP-Server beispielsweise Lambda-Funktionen auflisten und aufrufen.
Der AWS S3 Tables MCP-Server lässt sich hingegen von einem Agenten nutzen, um S3-Buckets abzufragen oder neue Tabellen aus CSV-Dateien zu erstellen.
Der AWS Knowledge MCP-Server verbindet Agenten mit den neuesten AWS-Dokumentationen, API-Referenzen und Architekturleitfäden.

Eine Query an letztgenannten Knowledge-Server könnte etwa die Anweisung beinhalten, eine API-Referenz für das von AWS gemanagte Prometheus-Tool aufzurufen. Das würde die richtigen aktuellen Informationen liefern – optimiert für die Nutzung durch KI-Agenten.

10. Pulumi MCP-Server

Pulumi ist eine weitere beliebte IaC-Option – und hat ebenfalls einen offiziellen MCP-Server eingeführt. Dieser ermöglicht es KI-Agenten,

Pulumi-Registries abzufragen,
auf Cloud-Ressourcen und -Infrastruktur zuzugreifen, und
Pulumi-Befehle auszuführen.

Wie Entwickler diesen MCP-Server nutzen können, um einen Azure Kubernetes Service (AKS)-Cluster bereitzustellen, erklärt Pulumi beispielhaft in einer ausführlichen Schritt-für-Schritt-Anleitung. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

v0.380.0

Mon, 01 Jun 2026 12:33:47 +0200

What's Changed

bundler: avoid adding Bundler checksum for lockfiles using 4.0.0-4.0.10 by @thavaahariharangit in #15164
Remove beta ecosystem flag handling for Deno by @markhallen in #15173
[bun] Add lockfile generator for bun by @brrygrdn in #14882
Pass --config.minimumReleaseAge=0 for pnpm security updates to bypass pnpm-workspace.yaml by @yeikel in #15170
build(deps): bump terraform to 1.15.3 by @HorizonNet in #15055
Change cron schedule from Thursday to Monday by @robaiken in #15181
Add specific error for missing .NET SDK in discovery by @brettfo in #15168
Throw UnparseableFileException when slnx parsing fails by @brettfo in #15167
v0.380.0 by @dependabot-core-action-automation[bot] in #15192

Full Changelog: v0.379.0...v0.380.0

IBM und Red Hat investieren Milliarden in Open-Source-Sicherheit

Sat, 30 May 2026 01:13:45 +0200

width="1024" height="576" sizes="auto, (max-width: 1024px) 100vw, 1024px">

Leistungsfähige KI-Modelle wie Claude Mythos bedrohen den Open-Source-Ansatz. IBM und Red Hat wollen den Fortbestand sichern.

Norman Chan / Shutterstock

Open-Source-Code ist in Unternehmen allgegenwärtig; Schätzungen zufolge nutzen mehr als 90 Prozent der Fortune-500-Unternehmen ihn in ihren Software-Lieferketten. Open-Source-Code ist jedoch bekanntermaßen voller Schwachstellen und das Aufspüren und Beheben dieser Fehler kann für Sicherheitsteams zu einem endlosen Kampf werden.

IBM und Red Hat setzen darauf, dass eine neue Initiative, Project Lightwell, dazu beitragen kann, diesen Prozess zu beschleunigen. Im Rahmen des Projekts wollen die beiden Unternehmen fünf Milliarden Dollar sowie 20.000 Ingenieure von IBM und Red Hat bereitstellen, um eine Art „Clearingstelle“ für Unternehmen aufzubauen.

Den Unternehmen zufolge soll diese als KI-gestützte „Sicherheits-Koordinierungsebene“ dienen und Unternehmen die Möglichkeit geben, Patches direkt in ihre bestehenden Software-Lieferketten zu integrieren.

„Project Lightwell“ befindet sich derzeit in der Konzeptphase mit einer Gruppe von elf Finanzpartnern und soll später als kommerzielles Abonnement angeboten werden.

„Die Fortschritte bei KI-Tools haben die Patching-Landschaft revolutioniert – also die Fähigkeit, Schwachstellen in Software zu entdecken, ohne dabei an Behebungsgeschwindigkeit einzubüßen“, erklärt Ashesh Badani, Senior Vice President und Chief Product Officer bei Red Hat, gegenüber CSOonline. „Jeder nutzt Open-Source-Software und die Herausforderung besteht darin, Schwachstellen nicht schnell genug beheben zu können.“

Die Lücke bei der Behebung von Schwachstellen schließen

Die Sicherheitsprobleme bei Open-Source-Software sind gut dokumentiert: Fast 50.000 Common Vulnerabilities and Exposures (CVEs) wurden im Jahr 2025 veröffentlicht, und das Project Glasswing von Anthropic, das auf dem Mythos Preview-Modell basiert, fand kurz nach dem Start rund 3.900 bisher unentdeckte Schwachstellen mit hohem oder kritischem Schweregrad in Open-Source-Software.

IBM betreibt eines der größten kommerziellen Open-Source-Ökosysteme und nutzt mehr als 62.000Softwarepakete in Umgebungen wie Linux, Kubernetes, Kafka, Terraform und Java. Das Unternehmen bietet dort bereits Lebenszyklusmanagement, Validierung und Patching an.

Mit Project Lightwell sollen diese Prinzipien nun auf KI-Frameworks, unabhängige Bibliotheken, Sprach-Toolchains und Daten-Streaming-Plattformen ausgeweitet werden. Ziel ist es, validierte Sicherheitskorrekturen für Open-Source-Code bereitzustellen, der bereits in Unternehmensumgebungen eingesetzt wird – ohne Stabilität, Zertifizierungen oder Compliance-Anforderungen zu beeinträchtigen.

IBM zufolge sind dafür keine Upgrades oder der Zugriff auf den Quellcode erforderlich. Project Lightwell werde Sicherheitskorrekturen auf genau die Abhängigkeitsversionen zurückportieren, die bereits getestet und bereitgestellt wurden. Die Lösung arbeitet auf Basis von Konfigurationsdateien wie pom.xml, sodass der Code innerhalb der kontrollierten Unternehmensumgebung verbleibt. Der anfängliche Fokus liegt auf Java/Maven, später sollen auch PyPI, npm, Go und weitere Plattformen unterstützt werden.

Diskrete Fehlerbehebung möglich

Unternehmen sollen zudem die Möglichkeit erhalten, sensible Schwachstellen unter Embargo über ein „sicheres Vermittlermodell“ zu teilen und validierte Patches zu erhalten, die Red Hat-Plattformen und unabhängigen Community-Code abdecken. Darüber hinaus können sie Korrekturen über Abhängigkeitsketten hinweg bereitstellen, Probleme in aktiven Produktionsumgebungen melden und beheben sowie Korrekturen an die Upstream-Community weitergeben, damit diese sie integrieren kann.

„Wir wollen sicherstellen, dass alle Korrekturen, die wir den Unternehmen über die Clearingstelle zur Verfügung stellen, auch wieder ihren Weg zurück in die Open-Source-Projekte finden, die [den Code] entwickelt haben“, erklärt Badani. „Wenn beispielsweise ein Stück Python-Code gepatcht wurde, soll die Korrektur schnell an die Python-Community zurückgeliefert werden.“

Mithilfe fortschrittlicher KI und in Zusammenarbeit mit führenden Open-Source-Mitwirkenden werden sich die Ingenieure von IBM und Red Hat darauf konzentrieren, Upstream- und Downstream-Umgebungen besser zu verbinden, damit die Korrekturen sofort für Unternehmen nutzbar sind. Zudem sollen sie Patches entwickeln, große Mengen an Schwachstellen analysieren und priorisieren sowie Abhängigkeiten absichern.

Badami zufolge stammen die 20.000 Ingenieure aus den bestehenden Teams von IBM und Red Hat. Bei Bedarf sollen weitere Fachkräfte hinzugezogen werden. Die Unternehmen wollen sowohl moderne Foundation-Modelle führender KI-Labore als auch eigene KI-Werkzeuge und Frameworks einsetzen. Die fünf Milliarden Dollar werden in KI-Werkzeuge und den Aufbau der erforderlichen Infrastruktur investiert.

Zu den frühen Unterstützern von Project Lightwell zählen unter anderem Bank of America, BNY, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa und Wells Fargo. Nach der Designphase soll das Angebot schrittweise weiteren Kunden über ein Abonnementmodell zugänglich gemacht werden.

Ein Aufruf zum Handeln?

David Shipley von Beauceron Security bezeichnet die Initiative als „dringend notwendig“, wenn Unternehmen Open Source langfristig erhalten wollen. Die Zeit, in der Billionenwerte auf der Arbeit freiwilliger Entwickler beruhten, sei mit Claude Mythos abrupt zu Ende gegangen. Nun müssten Unternehmen ihren Beitrag leisten, um Open Source zu unterstützen.

„Wenn wir keinen Weg finden, in Open Source zu investieren, besteht die Alternative darin, dass jeder seinen eigenen maßgeschneiderten Code mithilfe von KI entwickelt“, erklärt Shipley. Das wäre aus Rechen- und Umweltperspektive „enorm verschwenderisch“.

Menschen bleiben unverzichtbar

Red-Hat-Manager Badani betont, dass KI zwar hervorragend darin sei, Sicherheitsprobleme in Open-Source-Code aufzudecken, der Prozess der Fehlerbehebung jedoch nach wie vor mühsam sein kann. Korrekturen müssten zunächst an die Entwickler weitergeleitet, an die Open-Source-Community verteilt und dann an Kunden und Nutzer zurückgespielt werden.

„Den Fehler zu finden ist eine Sache“, so Badani. „Die eigentliche Herausforderung sind die vielen Schritte, die erforderlich sind, um ihn tatsächlich zu beheben. Genau diesen zusätzlichen Zeitaufwand wollen wir verkürzen.“

Während die öffentliche Diskussion häufig davon geprägt sei, menschliche Entwickler durch KI zu ersetzen, verfolge Project Lightwell den gegenteiligen Ansatz, fügte der Red-Hat-CPO an „Wir können das Problem mit einer Kombination aus KI-Tools und menschlichem Wissen und Fachkompetenz angehen. Die Verbindung beider Aspekte führt zu einem besseren Ergebnis als ausschließlich das eine oder das andere zu nutzen.“ (mb)

IBM·레드햇, 기업용 오픈소스 보안 컨트롤타워 구축 나서

Fri, 29 May 2026 07:05:07 +0200

기업 환경에서 오픈소스 코드는 사실상 필수 요소가 됐다. 포춘 500대 기업의 90% 이상이 소프트웨어 공급망에 오픈소스 코드를 포함하고 있는 것으로 추정된다. 그러나 오픈소스는 수많은 보안 취약점을 안고 있는 경우가 많아, 이를 찾아내고 패치하는 작업은 보안팀의 끝없는 과제로 꼽힌다.

IBM과 레드햇은 이러한 문제를 해결하기 위해 새로운 프로젝트인 ‘프로젝트 라이트웰(Project Lightwell)’을 추진한다.

29일 공개된 프로젝트 라이트웰은 50억 달러(약 6조 8,000억 원)와 IBM 및 레드햇 엔지니어 2만 명을 투입해 오픈소스 소프트웨어의 취약점 발견과 대응을 가속화하는 새로운 ‘엔터프라이즈 클리어링하우스(Enterprise Clearinghouse)’를 구축하는 것이 목표다. 양사는 이 클리어링하우스가 AI 기반 ‘보안 조정 계층(Security Coordination Layer)’ 역할을 수행해 기업이 기존 소프트웨어 공급망에 패치를 직접 통합할 수 있도록 지원할 것이라고 밝혔다.

프로젝트 라이트웰은 현재 11개 금융기관과 함께 설계 단계에 있으며, 향후 구독형 상용 서비스로 제공될 예정이다.

레드햇의 수석부사장 겸 최고제품책임자(CPO) 아셰시 바다니는 “AI 도구의 발전으로 취약점을 발견하면서도 대응 속도를 유지할 수 있는 환경이 마련됐다”라며 “대부분의 기업이 오픈소스 소프트웨어를 사용하고 있지만, 취약점을 충분히 빠르게 해결하지 못하는 것이 가장 큰 과제”라고 CSO온라인에 설명했다.

취약점 대응 격차 해소 나선 IBM·레드햇

오픈소스 보안 문제는 이미 널리 알려져 있다. 2025년 한 해 동안 공개된 공통 취약점 및 노출(CVE)은 약 5만 건에 달했다. 또한 앤트로픽의 미토스 프리뷰(Mythos Preview) 모델 기반 ‘프로젝트 글래스윙(Project Glasswing)’은 출시 직후 오픈소스 소프트웨어에서 약 3,900건의 미발견 고위험 및 치명적 취약점을 찾아냈다.

IBM은 업계에서 가장 폭넓은 상용 오픈소스 생태계를 보유한 기업 가운데 하나로 평가받는다. 현재 6만 2,000개 이상의 패키지를 활용하고 있으며, 리눅스(Linux), 쿠버네티스(Kubernetes), 카프카(Kafka), 테라폼(Terraform), 자바(Java) 등 다양한 플랫폼에서 운영·검증·패치 및 라이프사이클 관리 서비스를 제공하고 있다.

IBM은 프로젝트 라이트웰을 통해 이러한 엔지니어링 원칙을 AI 프레임워크, 독립 라이브러리, 언어 툴체인, 데이터 스트리밍 플랫폼 등으로 확대 적용할 계획이다. 이를 통해 기업 환경에서 이미 사용 중인 오픈소스 코드에 검증된 수정 사항을 제공하고, 시스템 안정성이나 인증, 규제 준수에 영향을 주지 않으면서 취약점을 해결할 수 있도록 지원한다는 설명이다.

프로젝트 라이트웰은 소스코드 접근 권한이나 버전 업그레이드를 요구하지 않는다. 이미 테스트와 배포가 완료된 정확한 의존성 버전에 맞춰 수정 사항을 역이식(backport)하는 방식으로 운영된다. 또한 pom.xml과 같은 구성 매니페스트를 기반으로 작동해 패치된 아티팩트가 배포되더라도 코드는 기업의 통제된 운영 환경 내에 그대로 유지된다. 초기에는 자바·메이븐(Java/Maven) 생태계에 집중하지만, 향후 PyPI, npm, Go 등으로 지원 범위를 확대할 예정이다.

기업은 ‘보안 중개 모델(Secure Intermediary Model)’을 통해 공개 전 단계의 민감한 취약점 정보를 안전하게 공유할 수 있으며, 레드햇 플랫폼은 물론 독립 오픈소스 커뮤니티 코드에 대한 검증된 패치도 받을 수 있다. 또한 의존성 체인 전반에 걸쳐 수정 사항을 배포하고, 운영 환경에서 발견된 문제를 보고·해결하며, 수정 사항을 다시 업스트림에 공유해 오픈소스 커뮤니티 전체가 활용할 수 있도록 지원한다.

레드햇의 수석부사장 겸 최고제품책임자(CPO) 아셰시 바다니는 “클리어링하우스를 통해 기업에 제공하는 수정 사항이 해당 코드를 개발한 오픈소스 커뮤니티에도 다시 전달되도록 하는 것이 중요하다”라며 “예를 들어 파이썬 코드의 취약점을 수정했다면 그 결과가 신속하게 파이썬 커뮤니티에도 공유돼야 한다”고 설명했다. 이어 “프로젝트 라이트웰은 이러한 과정을 안전하게 연결하는 ‘보안 지도(Secure Map)’ 역할을 수행할 것”이라고 덧붙였다.

IBM과 레드햇 엔지니어들은 첨단 AI 기술과 주요 오픈소스 기여자들과의 협력을 바탕으로 업스트림과 다운스트림 환경을 연결해 기업 환경에 바로 적용할 수 있는 패치를 개발할 계획이다. 이와 함께 대규모 취약점 검토 및 분류 작업, 의존성 강화 작업도 수행한다.

바다니는 “프로젝트에 투입되는 2만 명의 엔지니어는 IBM과 레드햇이 보유한 기존 인력으로 구성되며, 필요에 따라 추가 인력을 배치할 예정”이라고 설명했다. 양사는 최첨단 AI 연구소들이 개발한 파운데이션 모델과 자체 개발한 AI 도구 및 프레임워크를 함께 활용할 계획이다. 50억 달러(약 6조 8,000억 원)의 투자금은 AI 도구 도입과 내부 운영 인프라 구축에 사용된다.

프로젝트 라이트웰의 초기 참여 기업으로는 뱅크오브아메리카(Bank of America), BNY, 씨티(Citi), 골드만삭스(Goldman Sachs), JP모건체이스(JPMorganChase), 마스터카드(Mastercard), 모건스탠리(Morgan Stanley), 캐나다왕립은행(Royal Bank of Canada), 스테이트스트리트(State Street), 비자(Visa), 웰스파고(Wells Fargo) 등이 포함됐다. IBM과 레드햇은 초기 설계 단계가 마무리되면 구독형 모델을 통해 더 많은 고객으로 프로젝트를 확대할 계획이다.

오픈소스 생태계를 위한 투자 촉구

보서론 시큐리티(Beauceron Security)의 데이비드 십리는 기업이 오픈소스 생태계를 지속 가능하게 유지하려면 이와 같은 프로젝트가 “절실히 필요하다”고 평가했다.

십리는 미토스(Mythos)의 등장으로 막대한 규모의 디지털 자산이 자원봉사자들의 노력에 의존하던 시대는 사실상 막을 내렸다고 지적했다. 이제 오픈소스 생태계 유지 비용을 기업이 부담해야 할 시점이 왔으며, 그렇지 않으면 결국 그 혜택을 잃게 될 것이라는 설명이다.

십리는 “오픈소스에 투자할 방법을 찾지 못한다면, 오랫동안 이어져 온 형평성 문제도 해결할 수 없게 된다”라며 “그 대안은 모든 기업이 AI를 활용해 각자 맞춤형 코드를 개발하는 것뿐”이라고 말했다. 이어 “이는 컴퓨팅 자원과 환경 측면에서 매우 비효율적이고 낭비가 큰 방식”이라고 지적했다.

또한 “이번 프로젝트가 다른 기업들의 행동을 촉발하는 계기가 되기를 기대한다”고 밝혔다.

인간의 역할은 여전히 중요

바다니는 AI가 오픈소스 코드의 보안 취약점을 발견하는 데는 뛰어난 성능을 발휘하지만, 실제 패치 과정은 여전히 복잡하고 시간이 많이 소요된다고 강조했다.

취약점이 발견되면 수정 사항을 업스트림 프로젝트에 전달해야 하고, 이후 오픈소스 커뮤니티 전체에 배포된 뒤 다시 고객과 사용자 환경으로 전달되는 과정을 거쳐야 한다.

바다니는 “버그를 발견하는 것과 실제로 이를 해결하는 것은 전혀 다른 문제”라며 “실제 수정 작업에는 수많은 절차가 필요하며, 그 과정에서 발생하는 시간 지연이 우리가 줄이고자 하는 격차”라고 설명했다.

문제의 심각성을 보여주듯 프로젝트 라이트웰 발표 이후 IBM과 레드햇에는 관련 문의와 참여 요청이 쇄도하고 있는 것으로 알려졌다.

바다니는 “이 문제는 가까운 시일 내에 사라지지 않을 것”이라며 “초기 과제를 성공적으로 해결하더라도 기업은 이러한 지원을 지속적이고 반복적으로 필요로 하게 될 것”이라고 전망했다.

최근 AI가 인간 엔지니어를 대체할 것이라는 논의가 확산되고 있지만, 프로젝트 라이트웰은 오히려 AI와 인간의 협업에 초점을 맞추고 있다.

바다니는 “AI 도구와 인간의 지식, 전문성을 결합하면 이 문제를 훨씬 효과적으로 해결할 수 있다”라며 “둘 중 하나만 사용하는 것보다 두 요소를 함께 활용할 때 더 나은 결과를 얻을 수 있다”고 강조했다.
dl-ciokorea@foundryco.com

IBM and Red Hat want to become the ‘security clearinghouse’ for open source applications in the enterprise

Fri, 29 May 2026 04:02:40 +0200

Open source code is everywhere in the enterprise; it’s estimated that upwards of 90% of Fortune 500 companies have it in their software supply chains. But open source code is notoriously rife with vulnerabilities, and identifying and patching those bugs can be an endless battle for security teams.

IBM and Red Hat are betting that a new initiative, Project Lightwell, can help accelerate this process.

Announced today, the project will commit $5 billion and 20,000 IBM and Red Hat engineers to build a new ‘enterprise clearinghouse’ to accelerate discovery and remediation of vulnerabilities in open source software. The companies say the clearinghouse will serve as an AI-powered “security coordination layer,” giving enterprises the ability to integrate patches directly into their existing software supply chains.

Now in the design phase with a group of 11 financial partners, Project Lightwell will eventually be offered as a commercial subscription.

“The advancement in AI tools has broken the patching map, which is the ability to discover vulnerabilities in software without losing the speed of remediation,” Ashesh Badani, Red Hat SVP and CPO, told CSOonline. “Everyone’s running open source software, and the challenge is not being able to fix vulnerabilities quickly enough.”

Closing the remediation gap

Open source security issues have been well documented: Almost 50,000 common vulnerabilities and exposures (CVEs) were published in 2025, and Anthropic’s Project Glasswing, powered by its Mythos Preview model, found roughly 3,900 previously undiscovered high or critical severity vulnerabilities in open source software shortly after launch.

IBM is considered one of the broadest commercial open source ecosystems, using more than 62,000 packages and operating across Linux, Kubernetes, Kafka, Terraform, Java and other platforms, and providing lifecycle management, validation, and patching for elements within those environments.

The company says Project Lightwell will now apply those same engineering principles to broader AI frameworks, independent libraries, language toolchains, and data streaming platforms, to deliver validated fixes to open-source code already in use in enterprise environments. This can support remediation without disruption of stability, certification, or compliance.

No upgrades or access to source code are required; Project Lightwell will backport fixes to exact dependency versions that have already been tested and deployed. It operates on fundamental configuration manifests like pom.xml so code remains in controlled enterprise environments when patched artifacts are rolled out. Initial focus will be on Java/Maven, but the project will eventually expand to PyPI, npm, Go, and others.

Enterprises will have the ability to share sensitive vulnerabilities under embargo through a “secure intermediary model” and receive validated patches spanning Red Hat platforms and independent community code. They will also be able to deliver fixes across dependency chains; report and address issues across active production environments; and share fixes upstream so the wider open-source community can incorporate them.

“We want to make sure that whatever fixes we provide to the enterprises through the clearinghouse also find their way back into the open source community that developed [the code],” Badani explained. For instance, if a piece of Python code was patched, the fix should be quickly delivered back to the Python community. With Project Lightwell, that process can be achieved through a “secure map.”

Using advanced AI, and working with leading open source contributors, IBM and Red Hat engineers will focus on connecting upstream and downstream environments so fixes are enterprise-ready. They will also develop patches and perform “high volume” vulnerability review and triage, and dependency hardening.

The network of 20,000 engineers will come from IBM’s and Red Hat’s existing pools of talent, and the companies will augment those teams as needed, Badani explained. The companies will take advantage of foundation models coming out of frontier labs, as well as their own internally-built AI tools and frameworks. The $5 billion will be used to equip teams with AI tools and build out internal operational infrastructure.

Early Project Lightwell adopters include Bank of America, BNY, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa, and Wells Fargo. Following the initial design period, IBM and Red Hat will phase more customers onto Project Lightwell via a subscription model.

A call to action?

This type of initiative is “desperately needed” if enterprise is to save open source, noted David Shipley of Beauceron Security.

The days of trillions in wealth depending on volunteers “ended violently” with Mythos, he noted, and the bill has ultimately come due for open source. Enterprises will need to pay up, or lose it.

“If we don’t find a way to invest in open source, which will close a long-standing equity issue, the alternative is everyone building their own bespoke code using AI,” Shipley said. That would be “massively wasteful” from a compute and environmental perspective.

“I hope this drives others to act,” he said.

Keeping humans in the loop for an ongoing battle

Badani emphasized that, while AI is great at discovering security issues in open-source code, the patching process can still be cumbersome. Fixes have to be sent upstream, distributed to the open source community, then flow back to customers and users.

“Finding the bug is one thing,” said Badani. “The other is all the steps that it takes to actually go and remediate it. That extra amount of time is the gap that we’re trying to help close.”

Underscoring the severity of the problem, IBM and Red Hat have already had an “onslaught of incoming requests” since Project Lightwell was announced.

“This isn’t going to stop any time soon,” Badani said. “Even if we were to very successfully solve the initial set of challenges that come to us, this will be something that companies are going to need on an ongoing or recurring basis.”

And, while the narrative has focused on cutting human engineers in favor of AI, Project Lightwell is focused on the opposite: “We can address [the problem] with a mixture of AI tools and human knowledge and expertise,” Badani said. “Coupling the two gives you a better outcome than just using one or the other.”

IBM and Red Hat want to become the ‘security clearinghouse’ for open source applications in the enterprise

Fri, 29 May 2026 03:07:03 +0200

IBM and Red Hat are betting that a new initiative, Project Lightwell, can help accelerate this process.

Now in the design phase with a group of 11 financial partners, Project Lightwell will eventually be offered as a commercial subscription.

Closing the remediation gap

A call to action?

This type of initiative is “desperately needed” if enterprise is to save open source, noted David Shipley of Beauceron Security.

The days of trillions in wealth depending on volunteers “ended violently” with Mythos, he noted, and the bill has ultimately come due for open source. Enterprises will need to pay up, or lose it.

“I hope this drives others to act,” he said.

Keeping humans in the loop for an ongoing battle

Underscoring the severity of the problem, IBM and Red Hat have already had an “onslaught of incoming requests” since Project Lightwell was announced.

This article originally appeared on InfoWorld.

Supply Chain Compromises Impact Nx Console and GitHub Repositories

Thu, 28 May 2026 22:07:43 +0200

CISA is prioritizing the response to multiple emerging software supply chain intrusion campaigns targeting developer ecosystems Continuous Integration/Continuous Development (CI/CD) pipelines. These recent incidents, including the GitHub compromise via a malicious Nx Console Visual Studio Code (VS Code) extension and the “Megalodon” supply chain intrusion campaign, demonstrate how cyber threat actors are abusing tools and processes that support enterprise, cloud, and DevOps environments—specifically CI/CD pipelines, code extensions and workflows.

Threat actors leveraged a prior compromise of Nx developer systems to compromise a GitHub employee’s device through a poisoned third-party VS Code extension, resulting in unauthorized access and exfiltration of internal GitHub repositories. The malicious extension version (18.95.0) was distributed through VS Code’s automatic update mechanism, meaning systems with Nx Console previously installed may have received the malicious build without developers taking any manual installation action. GitHub released a security advisory on this activity, and CVE-2026-48027 has been assigned to the malicious version of Nx Console and added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog.

Additionally, in a campaign known as “Megalodon,” a cyber threat actor injected malicious GitHub Action workflows to harvest CI/CD secrets, cloud credentials, and tokens, impacting both development and deployment pipelines in public GitHub repositories.

CISA urges organizations to implement the following recommendations to detect and remediate a potential compromise:

Monitor and audit workflow files and contributor activity for suspicious pull requests and direct commits, particularly those authored by automated accounts.
Revert unauthorized changes, especially from automated accounts, e.g., build-bot, auto-ci, ci-bot, pipeline-bot and especially those made after May 18, 2026.

If your organization discovers a compromise resulting from previously compromised GitHub or Nx Console software, CISA recommends the following steps:

Conduct a forensics review of CI/CD logs, cloud audit trails, and affected developer machines.
Rotate/revoke all secrets including: all credentials, tokens, and secrets accessible to CI/CD pipelines, including API keys, cloud provider credentials (Amazon Web Services, Google Cloud Platform, Microsoft Azure), SSH keys, Docker/npm/PyPI/Vault/Terraform/Kubernetes tokens, GitHub/GitLab/Bitbucket tokens, and developer or pipeline secrets.
Notify proper stakeholders if necessary.

CISA recommends the following best practices for using package repos:

Wait at least three hours before pulling a new package. This gives the software community time to identify suspicious or malicious packages before they are widely downloaded.
Pin software to specific trusted versions. Pinning software prevents pulling a malicious or unscreened package during the build process.
Only pull packages from known and trusted sources. Relying on known and trusted sources reduces the likelihood of downloading a package that has been maliciously forked.

See the following resources for additional guidance on these compromises:

GitHub: Investigating unauthorized access to GitHub-owned repositories
Nx: Postmortem: Nx Console v18.95.0 supply-chain compromise
Ox Security: Megalodon: CI/CD Malware Spreading Across GitHub Repositories
StepSecurity: Nx Console VS Code Extension Compromised
SafeDep: Megalodon: Mass GitHub Repo Backdooring via CI Workflows

Disclaimer

The information in this report is being provided “as is” for informational purposes only. CISA does not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA. 

v0.379.0

Thu, 28 May 2026 19:19:05 +0200

What's Changed

Fix duplicate updated dependencies in multi-directory group refresh by @markhallen in #15098
Recategorise lockfile generation errors as known types by @brrygrdn in #15084
[Graph Job] Do not treat Dependabot::UnexpectedExternalCode as a hard failure by @brrygrdn in #15075
[Graph] Fix handling of multiple version resolution by @brrygrdn in #15099
Bun: Upgrade to Node JS 24 by @yeikel in #14964
Add API integration to fetch blocked versions at job construction by @kbukum1 in #14917
Fix go modules error in package details fetcher due to subpath issue by @AbhishekBhaskar in #15096
add common pattern for directory specification by @brettfo in #15108
raise generic error without path information by @brettfo in #15088
Add HasNoWarnNU1701 merge logic in project discovery by @brettfo in #15090
NuGet: Auto-patch NuGet.Config to allow insecure HTTP feeds by @brettfo in #15092
NuGet: Filter out submodule paths during discovery by @brettfo in #15093
Implement a "dealias_packages" flag for npm file parsing by @brrygrdn in #15070
fix(docker_compose): support folded scalar and docker.io-prefixed image values by @thavaahariharangit in #15100
Suppress Docker digest-only updates when tag version is unchanged by @markhallen in #15103
generate and submit dependency graphs by @brettfo in #14956
Revert "Add API integration to fetch blocked versions at job construction" by @robaiken in #15120
change test for file path to account for empty string by @brettfo in #15109
NuGet: Add circular dependency detection to MSBuildHelper.ThrowOnError by @brettfo in #15116
Catch FatalProtocolException from source repository initialization by @brettfo in #15117
NuGet: Remove redundant GetPackageGraphForDependencies and use discovery DependencyGraph by @brettfo in #15122
Add API integration to fetch blocked versions at job updates by @kbukum1 in #15123
Fix yarn berry security updates resolving to latest instead of target version by @kbukum1 in #15091
Fix misleading Terraform registry error when TLS certificate verification fails by @yeikel in #15131
Fix cooldown ignored in additional_dependencies issue by @AbhishekBhaskar in #15124
Remove beta ecosystems feature flag for sbt by @AbhishekBhaskar in #15151
NuGet: Fix binding redirect XML parse error to report unparseable file by @brettfo in #15147
fix(npm_and_yarn): handle engines OR constraints and split caret-expanded bounds by @thavaahariharangit in #15144
Pass --min-release-age=0 for npm security updates to bypass .npmrc by @yeikel in #15139
Add deno lockfile support by @sbs44 in #15153
NuGet: Fix version range double-wrapping in temp project creation by @brettfo in #15152
Check ProjectAssetsFile exists before reading by @brettfo in #15160
fix: use configured github source when checking GitHub Actions pre-release status by @yeikel in #15004
ERR_PNPM_INVALID_DEPENDENCY_NAME handler in PnpmLockfileUpdater by @Copilot in #15165
Read npm min-release-age from .npmrc and apply as cooldown by @yeikel in #15132
v0.379.0 by @dependabot-core-action-automation[bot] in #15162

Special Thanks

Big thanks to @yeikel for driving the min-release-age support for the JavaScript ecosystems!

Full Changelog: v0.378.0...v0.379.0

Merck and Mastercard are seeing real agentic AI results. Both say the plumbing came first.

Wed, 27 May 2026 21:32:08 +0200

Merck is using AI agents to cut drug discovery cycles by a third and ship compliant marketing materials up to 80% faster — but VP of Digital Platforms Sean Finnerty says the only reason it's working is because they built the infrastructure first.

And the pharmaceutical manufacturer is seeing promising early results: AI is generating marketing drafts that are “99% right” when it comes to compliance, shrinking review cycles from months to days and accelerating delivery by 70% to 80%. In the company’s medical research, meanwhile, one AI-assisted discovery cycle was reduced by 33%.

Still, agentic AI only works if companies first build the underlying “plumbing,” Finnerty said of digital platforms and services at a recent AI Impact Series event.

“If we do one-offs, we're gonna end up with thousands and thousands of things that are ultimately just gonna be debt that we'll have to deal with later,” he said. “And that's gonna be a drag on any further innovation.”

Starting with the plumbing

Merck’s plumbing-first strategy comes from lessons learned during the early days of cloud in the 2010s “when nobody knew what the heck was going on,” Finnerty said.

Getting the cloud right meant building from the ground up; at Merck, that infrastructure now supports 2,500 AWS accounts, numerous Microsoft Azure subscriptions, and new Google Cloud Platform (GCP) integrations.

“AI is gonna be the same exact thing,” Finnerty said. “We're going to have thousands and thousands of agents.” The questions then pile up: How do you register them? How do you secure them? How do you ensure they're connected to the right tools, and have access to the right data and the right context?

Context delivery is also critical; Merck works with three hyperscalers and has forty-seven edge locations and hundreds of databases. “Many, many petabytes” of structured and unstructured data are stored in Oracle databases, SQL databases, Excel spreadsheets, phone transcripts, and other repositories, Finnerty said.

His team is building scaffolding to deliver meaningful context in various situations, he explained. Data must be organized and ingested into various platforms, because “there’s no one solution to solve every single problem.” Sometimes it's Databricks, other times it's Amazon Redshift, “plus four other things.”

The goal is: “Let's make that easy and frictionless for people to do, and secure it, and make sure it's well integrated with MCP [model context protocol], and A2A [Agent2Agent], and upstream compute,” Finnerty said. “If you wanna run stuff on GCP or you wanna run stuff on AWS, we've got the plumbing in place so you can run your adjacent workloads wherever you want.”

How Merck is using agents

As it builds out its technical plumbing, Merck is experimenting with agents across regulated enterprise operations, scientific discovery workflows, and app modernization.

Notably, AI is accelerating drug discovery. Finnerty explained that scientists look at molecular structures and disease states to determine if a given condition is druggable. But even if a disease state is known, developing a drug to target it can take years.

Now with AI, teams are starting to see “very promising things,” such as cutting one particular research cycle down by one-third. “That's a year off of the life of the discovery cycle,” Finnerty said. “Which means, theoretically, we can get it to a patient who needs that therapy a year faster.”

Once developed and approved, these products are regulated and marketing materials around them must be clearly and explicitly articulated. “The way you communicate that information per market, per country, per state, per region, is all very carefully governed and regulated,” Finnerty said. It’s also variable: An ad campaign for a vaccine in the state of Georgia looks much different from one launched in Canada.

Historically, humans did the due diligence to make sure the company complied with various laws. Draft materials go through iterations of reviews; when a mistake is discovered, it gets “kicked back to the beginning, and it goes through it again, and then it takes another however many weeks and months,” Finnerty said.

But now, AI can do that “much, much more effectively,” and the process is increasingly evolving from a human-in-the-loop to essentially a "human-as-governor." With human oversight, AI can deliver a first draft in a day or week that is 99% there, allowing teams to ship materials up to 80% faster.

Meanwhile, when it comes to app modernization, AI can discover architecture, document data interactions, APIs, network paths, and do authentication checks and authorization; it can also write code for Terraform for deployment and refactor JavaScript into Python.

Where the company would have previously spent weeks and months and hundreds of thousands of dollars to update one application, Finnerty said, agents are now handling the work through prompts.

Running into "wackiness"

That’s not to say there aren’t significant challenges; Finnerty noted that his team has run into some “wackiness”; for example in automated code and scenario testing. AI has blatantly made up scenarios, whether due to incorrect context, infrastructure, “or if it was just getting creative with, ‘You should be testing these three functions that don't even exist in the code that you're trying to test.’”

“That surprised me a little bit because I thought we were further past some of the hallucination challenges in these later models,” he said.

To address this, his team has engineered guardrails to keep hallucinations to a minimum, essentially using AI to supervise AI and applying confidence scores. So if Claude created the first output, they’ll instruct Microsoft Copilot to assess it.

“So if you ask something once, have AI check it, then ask it a third time, the confidence increases every time, and it minimizes some of the garbage that gets created in the early runs,” Finnerty said.

Use cases for agentic AI in financial services

Meanwhile, at Mastercard, Chief Data Officer Andrew Reiskind and his team are focusing agentic experimentation on highly orchestrated transaction and dispute workflows. As he noted, a chargeback or fraud dispute is not a single event.

When a consumer disputes a charge (typically online), that “kicks off an entire other process on the back-end that tends to be very labor-intensive,” Reiskind said.

Mastercard has to collect specifics about the actual dispute; then the merchant has its own investigations (Was the card reported as lost or stolen? Does the consumer dispute charges often?). Further, the network sitting in the middle has its own rules for timing and information submission.

“You have each and every one of these steps, many of which are unstructured, but there are also structured data elements to this,” Reiskind said. Whether a card was lost or stolen tends to be structured, but the consumer complaint is “unstructured data of questionable reliability.”

“So you're sitting there with a decisioning system that has deterministic decisions, but also probabilistic decisions,” he said.

This problem can be sped up and potentially solved by AI agents, but that can be a complex process: Which tasks are you handing off to agents? When are they kicking things back to human reps? How many agents are you ultimately using? What are the cost implications?

Then there are reputational questions and costs: Have you just called a consumer potentially a liar when they weren't lying?

“It's an exact problem where you want to, as a bank, maintain trust with your consumer,” Reiskind said. “But you also wanna make this efficient and take costs out of the system.”

The PB&J versus turkey mistake: Determine what risks are acceptable

There’s always going to be risk with AI, and enterprises should assess it from the beginning of product design, Reiskind said. There’s also the question of acceptable risk.

As an example: Did you serve a customer a peanut butter jelly sandwich instead of a turkey sandwich (a minor inconvenience)? Or did you serve gluten to someone with celiac disease?

“Is it an acceptable risk if one percent of the time it makes the mistake? If it is, let's go to the next stage of how you're mitigating that risk,” Reiskind said.

Leaders must perform cost-benefit analysis, break problems down to their “constituent pieces,” and calculate cost for each one. But these are estimates; it’s near-impossible to forecast real usage, Reiskind said. “It is not a simple process to get to the cost,” he said. “But it is doable.”

AI at scale: What engineering teams are confronting

Thu, 21 May 2026 11:03:42 +0200

For the past few years, enterprise AI conversations have been dominated by optimism: bigger models, more pilots, faster automation. The prevailing assumption was simple — pick the right AI platform and progress would follow.

Reality has been far less forgiving.

Most IT leaders have discovered that production AI is significantly harder than early experimentation suggested. The real work begins not when a model performs well in isolation, but when it must operate inside environments that are secure, observable, and operationally durable.

Recent research my company conducted with enterprise cloud architects and IT decision-makers confirms what many engineering teams already know instinctively: experimentation is easy. Operationalizing AI reliably, repeatedly, and at scale is the hard part.

Once AI begins influencing real workflows, recommending decisions or triggering actions, the model quickly becomes the least interesting part of the system. The pressure shifts to everything around it.

Agentic AI is scaling faster than the environment around it

The data leaves little room for debate: AI has already moved into operational territory. Nearly three-quarters of respondents report actively training machine learning models, and 76% are running GPU workloads in production. More than 70% are investing in AI reasoning, decision optimization and AI assistants designed to execute tasks.

These are not exploratory use cases. They shape workflows, customer experiences, and internal decision-making.

Yet many of these systems are being deployed into cloud environments that predate agentic AI entirely. Nearly all organizations report that their machine learning pipelines require migrating more than 25% of their data — an early warning signal that existing infrastructure was never designed for reproducible model operations, standardized feature pipelines, or consistent policy enforcement.

In practice, agentic AI is being layered onto platforms optimized for application deployment, not governed execution-level intelligence. That architectural mismatch is where friction begins.

Governance gaps become visible under execution pressure

Governance gaps are easy to overlook during experimentation. In execution environments, they surface immediately.

Nearly all organizations store and process personally identifiable information, and most operate under regulatory regimes such as HIPAA or GDPR. At the same time, roughly half rely on public AI tools, while fewer than a quarter report enterprise-wide, governed AI deployments built on a shared framework.

This creates structural tension. AI systems are influencing production decisions inside environments where governance is inconsistent by design. Data flows through models without uniform audit controls. Policy enforcement varies across cloud accounts, teams, and regions.

This is not a tooling failure. It is a systems design failure.

When agentic AI participates directly in execution paths, it inherits the enterprise’s regulatory and operational obligations. If the underlying cloud architecture was not designed with AI-native governance in mind, teams are forced to retrofit controls into systems that were never meant to carry that load.

Multicloud complexity amplifies the challenge

Very few enterprises operate in a single cloud. Many manage between six and 20 cloud accounts across providers, with infrastructure-as-code practices that vary by platform and teams running AWS CloudFormation and HashiCorp Terraform side by side.

Devops organizations already shoulder significant operational burden, particularly around monitoring and reliability across distributed systems. Introducing agentic AI adds new stateful components, data dependencies, and life-cycle requirements. Model retraining, feature store updates, and inference endpoints must now align with identity, logging, and compliance controls across environments.

The friction teams experience rarely comes from any single AI system. It emerges from the interaction between agentic workloads and cloud estates assembled incrementally over years of modernization. The more fragmented the environment, the harder it becomes to enforce consistent governance at the AI layer.

It’s not just build vs. buy, but architectural fit

Much of the industry still frames agentic AI adoption as a build-versus-buy decision. The survey reflects heavy reliance on vendors and service providers, driven by skills scarcity and compressed timelines. But that framing misses the real issue.

The decisive question is architectural fit.

External platforms can accelerate delivery. Internal teams bring deep system and data context. What determines success is how AI initiatives integrate into the surrounding cloud environment.

When third-party capabilities are introduced without alignment to internal standards, fragmentation accelerates. But when AI systems are developed in isolation from core governance frameworks, architectural drift compounds quietly over time.

In response, many organizations are converging on a different model. Instead of isolating AI projects in silos, they are embedding external AI expertise directly inside internal delivery environments. Models are built and tested against production-grade governance from day one. Infrastructure, compliance, and observability are treated as first-class requirements, not cleanup work.

This approach recognizes that few enterprises have every AI capability fully staffed in-house, while preserving the architectural coherence required to scale sustainably.

Execution-level AI requires execution-level environment design

Agentic AI has decisively crossed into execution. Enterprises are training models, running GPU workloads, and embedding intelligent systems directly into operational workflows. At the same time, many are still modernizing pipelines, closing security gaps, and working toward consistent governance across increasingly distributed cloud estates.

The friction organizations encounter is rarely algorithmic. It is architectural.

Cloud environments built for application deployment are now being asked to support governed, reproducible, execution-level AI systems. That transition does not happen accidentally. It requires deliberate environment design.

Models unlock potential. Architecture determines whether that potential survives contact with production. As AI continues to influence real decisions and real workflows, the durability of the surrounding platform, not model novelty, will determine who scales successfully and who stalls.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Your NPM Package Is Stealing Secrets

Sat, 16 May 2026 00:17:40 +0200

Author: Security Weekly - A CRA Resource - Bewertung: 0x - Views:9

Malicious versions of the Node IPC NPM package contained heavily obfuscated payloads designed to steal developer and cloud credentials. The malware targeted AWS, Azure, GCP, GitHub, Kubernetes, Terraform, SSH keys, and dozens of other secret categories while disguising outbound traffic as a legitimate Azure-related domain.

This is what modern supply chain compromise looks like. Attackers no longer need to breach your infrastructure directly if they can poison a trusted dependency upstream. A single compromised package can silently expose cloud environments, CI/CD pipelines, and developer accounts at massive scale.

For defenders, vetting code is no longer enough. The maintainers, update chain, and dependency ecosystem all become part of the attack surface.

How do organizations realistically secure software dependencies at this scale?

Subscribe to our podcasts: https://securityweekly.com/subscribe

#SupplyChainSecurity #NPM #SecurityWeekly #Cybersecurity #InformationSecurity #AI #InfoSec

Expired domain leads to supply chain attack on node-ipc npm package

Fri, 15 May 2026 23:07:55 +0200

A popular npm package called node-ipc has been compromised, with hackers publishing malicious versions that bundle credential stealing malware. The root cause of the compromise was an expired domain name that attackers managed to register in order to hijack a maintainer’s account.

The node-ipc package has had malware added to its code in the past. In March 2022, following Russia’s invasion of Ukraine, the project’s creator intentionally added malicious code to the program to wipe files on systems with Russian or Belarusian IP addresses.

Node-ipc is a Node.js module that implements support for local and remote Inter-Process Communication over various types of socket across all major platforms. One use case is in implementing complex multi-process neural networks in JavaScript, but the module is also used as a dependency for 424 other projects, and receives almost 700K weekly downloads.

On Thursday, attackers managed to publish three trojanized versions across three different branches of the project: 9.1.6, 9.2.3 and 12.0.1. All new versions contained an 80KB obfuscated credential-stealing payload inside the node-ipc.cjs file.

The malicious code searches for and steals a wide range of credentials for CI/CD tools, cloud services and infrastructure, Kubernetes, SSH, and AI coding agents. The data is exfiltrated through DNS TXT queries rather than HTTP connections.

Since node-ipc is a dependency for hundreds of other packages, which in turn could be dependencies for even more packages, this attack could have a large blast radius. Users should immediately scan their systems to determine if they have any of the compromised versions installed, and if they do, treat the machine and any access token, environment variable, and API key stored on it as compromised.

Exhaustive credential collection and sneaky exfiltration

The malicious payload is decrypted and executed whenever other applications load the package through require(‘node-ipc’). The trojanized versions were designed to remain fully functional to avoid immediate detection, which together with other decisions attackers took, such as data exfiltration via DNS TXT, suggest stealthiness was a top priority.

Once executed, the malicious code collects information about the host system, including operating system version, hostname, and environment variables. It then starts looking for credentials in various locations based on the detected OS.

“The payload chooses between separate decoded target lists for macOS and Linux/default platforms,” researchers from Socket.dev said in their analysis. “The lists are not identical. In the analyzed payload, the macOS list contains 113 patterns and the Linux/default list contains 127 patterns.”

The target lists are extensive and include:

Configuration files for AWS, Azure, GCP, OCI, DigitalOcean, Scaleway, Hetzner, Fly, Vercel, Railway, Alibaba Cloud, IBM Cloud, Linode, MinIO, Snowflake, Doppler, and Salesforce;
SSH keys and SSH configuration;
Kubernetes, Docker, Helm, Rancher, and service-account material;
npm, Yarn, Netrc, Git, GitHub CLI, GitLab CLI, and Hub credentials;
Terraform credentials and tfvars files;
.env, .env.local, .env.production, database configuration files, shell histories, and database CLI histories;
macOS Keychain database files;
Firefox profile key database files on macOS;
Linux keyrings and KWallet files;
FileZilla, Remmina, OpenVPN, and related connection profiles;
Microsoft Teams local storage and IndexedDB paths.

While browser credential stores are not targeted directly, macOS keychain databases can contain system and browser credentials, so those credentials should be considered compromised as well and rotated.

All the collected data is archived in a GZIP file, which is then split into chunks and exfiltrated by making DNS TXT queries on an attacker-controlled domain whose name is similar to that of Microsoft’s legitimate Azure Static Web Apps domain.

Since the attackers control the DNS server for their domain name, they can see the TXT record queries made by the infected systems and can reconstruct the archives on their end from the leaked bytes. The Socket researchers estimate that a 500KB file would require around 29,400 TXT queries to exfiltrate in this way.

“The payload does not establish persistence in the decoded sample,” the researchers said. “There is no observed cron, launchd, rc.d, service installation, or second-stage download. The operational impact is concentrated in the execution window: collection, archive creation, DNS TXT exfiltration, and attempted cleanup.”

Expired domain led to email takeover

The malicious node-ipc versions were published from an npm account called atiertant, which belongs to one of the several developers with maintainer access to the package. Atiertant had never used his access to publish new node-ipc versions before, and has had no activity on node-ipc or any other npm package he has access to since 2022.

Security researchers noticed that the email address for atiertant’s account was hosted on a domain called atlantis-software.net that had expired in January 2025 and was re-registered earlier this month, most likely by the attackers. It was then just a matter of setting up an email server, recreating atiertant’s email address and performing a password reset on the account.

This highlights some of the security challenges open-source software projects face. While periodically reviewing access lists for dormant and unused accounts is a general security recommendation for companies, open-source projects are maintained by groups of volunteers, and it’s not unusual for people to take long breaks from contributing to projects, especially if those projects have reached a high level of maturity and feature completeness so they no longer get frequent updates.

It’s also likely that the attackers did not target node-ipc from the start, they just searched npm for accounts with email addresses on custom domain names, then checked if any of those domain names had expired. This means there might be other dormant accounts out there susceptible to email takeover using the same method.

The Socket.dev report contains additional recommendations for both users and developers, as well as file hashes and other indicators of compromise that can be used by security teams to create detections.

Azure Meetup Stuttgart an der HFT Stuttgart – Infrastructure as Code: Terraform und Bicep

Fri, 15 May 2026 19:02:04 +0200

Am Abend des 3. Juni 2026 findet das Azure Meetup Stuttgart zum Thema Azure Infrastructure as Code: Terraform und Bicep an der HFT Stuttgart statt. Der Event ist kostenfrei … eine Registrierung über die Meetup-Plattform ist zur Planung notwendig. Weitere spannende Events finden Sie auf der Event-Übersicht. Um keine News mehr zu verpassen, am Besten … weiterlesen

Solar Expanse - Space Exploration Manager Preview (PC)

Fri, 15 May 2026 12:35:47 +0200

I’ve always enjoyed the idea of exploring the Solar System, its planets and conquering places that no one ever visited before. And with Solar Expanse, you can easily do that. The game allows you to enter a space race where you’re competing with other corporations in order to mine asteroids, colonize other planets and terraform. It’s all a sandbox, so the focus is on trying to colonize the system and prevent losing. And there are plenty of loss conditions. You can run out of money, for starters. Or you don’t tackle the asteroid heading towards Earth. But the true appeal of the game is certainly the experience, the ability to immerse yourself in a sandbox and customize stuff as you go along. For newcomers, Solar Expanse’s menus can feel rather overwhelming, but in a good way. A lot of the gameplay relies on planning and then executing spaceship missions. It’s interesting to browse ships and see their pros and cons, then choose the best ones. Some of them are great fo...

Malicious node-ipc npm Packages Trigger New Supply Chain Security Alarm

Fri, 15 May 2026 08:20:49 +0200

A fresh supply chain attack targeting the widely used node-ipc npm package has raised new concerns across the JavaScript ecosystem after researchers uncovered multiple malicious releases containing an obfuscated credential stealer and backdoor functionality. Security analysts confirmed that several recently published package tarballs were infected with malware capable of harvesting sensitive data from developer systems and CI environments. The compromised versions identified as malicious include:

node-ipc@9.1.6
node-ipc@9.2.3
node-ipc@12.0.1

Researchers at Socket reported that the suspicious versions were flagged within approximately three minutes of publication, classifying the activity as malware almost immediately. Their investigation found that the malicious node-ipc releases contained heavily obfuscated code designed to fingerprint systems, collect local files, compress stolen data, encrypt the payload, and exfiltrate information through DNS-based communication channels. The incident marks another major security issue involving the long-running npm package, which was previously linked to one of the most discussed software supply chain incidents in the Node.js community.

Malicious node-ipc Versions Revive Earlier Supply Chain Concerns

The latest attack does not appear to be a typosquatting campaign. Instead, analysts believe the threat actor republished or reintroduced malicious functionality directly into legitimate node-ipc package versions. Researchers also pointed to earlier compromises connected to the package. In 2022, versions 10.1.1 and 10.1.2 contained geo-targeted destructive malware that checked whether systems were located in Russia or Belarus before recursively overwriting files. Versions 11.0.0 and 11.1.0 included the controversial “peacenotwar” dependency associated with unauthorized file-writing behavior. The newly discovered malware specifically affects the CommonJS implementation of the npm package. According to the technical analysis, the malicious payload exists only in the node-ipc.cjs file. The ESM wrapper, node-ipc.js, remained clean in the reviewed package artifacts and simply imported source files without containing the injected payload. Investigators also identified an unusual forensic indicator across the infected tarballs. Every file within the reviewed archives carried the timestamp “Oct. 26, 1985.” Researchers noted that this timestamp appeared consistently across all analyzed malicious package artifacts and may help investigators identify infected caches or registry mirrors.

Dormant Maintainer Account Allegedly Hijacked

The investigation suggests the attack may have originated through the takeover of a dormant maintainer account. The node-ipc project reportedly has 12 npm maintainers, including an account named “atiertant,” which still retains publishing privileges despite years of inactivity. Independent researcher Ian Ahl, also known online as @TekDefense and CTO at Permiso, publicly identified what he described as the likely attack vector: an expired email domain linked to the maintainer account. According to the published timeline:

Atlantis-software[.]net was originally registered on Jan. 10, 2001.
The domain expired on Jan. 10, 2025, after reportedly not being renewed.
An attacker allegedly re-registered the domain through NameCheap on May 7, 2026.
The attacker may then have configured mail servers and initiated an npm password reset.
Three malicious node-ipc versions were subsequently published on May 14, 2026, between 14:25 and 14:26 UTC.

Researchers believe that if the npm recovery email address was still associated with the expired domain, the new domain owner could have intercepted password reset emails and regained publishing access without directly compromising the maintainer’s infrastructure.

Credential Stealer Activated Through CommonJS Loading

The malware embedded inside the node-ipc npm package relied on runtime execution rather than installation scripts. When applications used require("node-ipc"), the malicious node-ipc.cjs file executed an appended obfuscated IIFE during module loading. The payload exposed an internal runner function named __ntRun, creating additional execution paths beyond the initial automatic activation. Analysts noted that any downstream code invoking require("node-ipc").__ntRun() could trigger another round of data collection and exfiltration. The malware used an environment variable called __ntw to distinguish execution paths. In most cases, the parent process spawned a detached child process that handled credential harvesting independently. If the child process failed, the malware executed within the current process instead.

Extensive Data Collection Targeted Developer Environments

The malicious node-ipc code performed extensive reconnaissance using Node.js operating system APIs. The malware gathered details including:

Operating system platform
System architecture
Hostname
Kernel version
Environment variables

The payload also attempted to execute uname -a and stored results inside uname.txt. Additional harvested files included /etc/hosts and envs.txt, which contained sorted environment variables formatted as KEY=value. Researchers warned that the environment collection process was not selective. Any secrets stored in environment variables—including cloud credentials, CI tokens, registry credentials, API keys, and database secrets—could be captured by the credential stealer. The malware reportedly targeted a wide range of developer and infrastructure assets, including:

AWS, Azure, GCP, OCI, and DigitalOcean configuration files
SSH keys and SSH configurations
Kubernetes, Docker, Helm, and Rancher credentials
npm, Yarn, GitHub CLI, GitLab CLI, and Netrc credentials
Terraform credential files and .tfvars data
.env files and database configuration files
Shell history files and database CLI histories
macOS Keychain databases
Firefox key database files on macOS
Linux keyrings and KWallet files
Microsoft Teams local storage and IndexedDB data
The payload skipped files larger than 4 MiB and intentionally avoided recursively scanning node_modules and .git directories.

DNS TXT Queries Used for Data Exfiltration

One of the more unusual aspects of the attack involved the malware’s exfiltration mechanism. Instead of using traditional HTTP or HTTPS communication, the credential stealer relied on DNS TXT queries. The malware attempted to communicate with the bootstrap resolver:

sh[.]azurestaticprovider[.]net:443

Researchers described the domain as a deliberate lookalike of Microsoft’s legitimate Azure Static Web Apps infrastructure. At the time of analysis, the domain resolved to IP address 37.16[.]75.69. Exfiltrated data was transmitted under the DNS zone:

bt[.]node[.]js

The malware generated TXT query prefixes using:

For a compressed archive of roughly 500 KiB, analysts estimated the malware could generate approximately 29,400 DNS TXT queries during exfiltration. The payload created compressed gzip archives from collected files, temporarily storing them in:

/nt-/.tar.gz

Although the malware attempted to delete the archive afterward using unlinkSync(), interrupted executions could leave the malicious tarballs on disk for forensic recovery.

Impact and Indicators of Compromise

Security researchers confirmed that the malicious node-ipc npm package versions were capable of stealing credentials and configuration files from systems loading the CommonJS entrypoint. The reviewed samples did not establish persistence mechanisms such as cron jobs, launchd services, or secondary malware downloads. The primary operational window focused on credential collection, archive creation, DNS exfiltration, and cleanup. Investigators identified several indicators of compromise tied to the malicious tarballs, including:

Malicious Packages

node-ipc@9.1.6

node-ipc@9.2.3

node-ipc@12.0.1

File Hashes

node-ipc.cjs SHA-256: 96097e0612d9575cb133021017fb1a5c68a03b60f9f3d24ebdc0e628d9034144
node-ipc-9.1.6.tgz SHA-256: 449e4265979b5fdb2d3446c021af437e815debd66de7da2fe54f1ad93cbcc75e
node-ipc-9.2.3.tgz SHA-256: c2f4dc64aec4631540a568e88932b61daebbfb7e8281b812fa01b7215f9be9ea
node-ipc-12.0.1.tar.gz SHA-256: 78a82d93b4f580835f5823b85a3d9ee1f03a15ee6f0e01b4eac86252a7002981

Security Recommendations

Researchers advised developers and organizations to immediately remove the compromised node-ipc npm package versions and reinstall verified clean releases. They also recommended auditing package-lock files, Yarn lockfiles, build caches, and local npm caches for malicious artifacts. Organizations whose systems loaded the infected CommonJS versions were urged to treat local credentials and environment secrets as compromised. Recommended remediation steps included rotating SSH keys, npm tokens, cloud provider credentials, GitHub and GitLab tokens, Kubernetes credentials, Docker registry secrets, Terraform credentials, and database access keys. Security teams were additionally encouraged to monitor DNS traffic for TXT query patterns beginning with xh, xd, or xf under the bt[.]node[.]js domain, as well as unusual bursts of high-volume DNS TXT traffic that could indicate active exfiltration attempts involving the malicious tarballs.

Security updates for Monday

Mon, 11 May 2026 15:14:36 +0200

Security updates have been issued by AlmaLinux (corosync, freeipmi, kernel, and kernel-rt), Debian (corosync, firefox-esr, kernel, lcms2, libpng1.6, linux-6.1, php8.2, php8.4, postorius, pyjwt, and tor), Fedora (dotnet10.0, exim, gnutls, kernel, nextcloud, nodejs22, php, proftpd, prosody, python-pulp-glue, python-requests, rclone, and SDL3_image), Mageia (firefox, nss, rootcerts, openvpn, thunderbird, and vim), Oracle (corosync, freeipmi, gstreamer1-plugins-bad-free, gstreamer1-plugins-base, and gstreamer1-plugins-good, kernel, libpng, and mingw-libtiff), Slackware (kernel and mozilla), SUSE (build, product-composer, c-ares, cairo, copacetic, distribution, firefox, firefox-esr, frr, glibc, go1.25, google-cloud-sap-agent, iproute2, java-11-openj9, java-17-openj9, java-17-openjdk, java-1_8_0-openj9, java-21-openj9, java-21-openjdk, java-25-openjdk, kernel, libexif-devel, libpcp-devel, libtpms, libtree-sitter0_26, Mesa, micropython, mozjs128, nginx, opencc, openCryptoki, php-composer2, podman, postfix, python-pytest, python311-Django, python311-Django4, redis, semaphore, strongswan, terraform-provider-aws, terraform-provider-azurerm, terraform-provider-external, terraform-provider-google, terraform-provider-helm, terraform-provider-kubernetes, terraform-provid, tor, valkey, vim, and wireshark), and Ubuntu (linux-nvidia-tegra, linux-raspi, linux-raspi-5.4, and nasm).

Security: Denial of Service in terraform (SUSE)

Sat, 09 May 2026 00:17:32 +0200

Zero Chaos: Scaling Detection Engineering at the Speed of Software, with Detection As Code

Fri, 08 May 2026 15:25:25 +0200

Every engineering team in your organization ships code through a pipeline. They branch, test, review, and deploy. If something breaks, they roll back. If someone asks "what changed?", the answer is in the commit history. This isn't heroic discipline to process; it's just how software gets built.

Now think about how your detection engineering team works.

Rules get written in a UI. Maybe copied and pasted from a wiki. There's no peer review; someone clicks "save," and it's live. No test cases validate the logic before deployment. No rollback if something breaks. When an alert suddenly floods your SOC, good luck figuring out what changed and when. When a detection stops firing, you might not notice for weeks.

This is, by definition, a process gap. And it's one that the rest of engineering solved years ago. The gap becomes manageable through the five custom rules, listed below. As your detections grow, you need the same discipline that every other engineering team already has.

Process Stage	How it works in software engineering	How it works in detection engineering
Storage	Git / Version Control	UI / Wiki / "Tribal Knowledge"
Validation	Automated CI/CD Tests	"Wait and see if it fires"
Review	Peer-reviewed Pull Requests	Single-user "Save" button
Rollback	One-click git revert	Manual query deletion

How does this help my security team?

Detection as Code gives your team a structured, repeatable way to build and manage detections with confidence. Instead of relying on manual updates and guesswork, every change is tested, reviewed, and tracked before it reaches production. Before we get into the how, here's why Detection as Code changes the way your team works:

A more reliable process. Every change goes through version control and peer review before it goes live. When something goes wrong, you know exactly what changed, when it changed, and who approved it. Roll back in seconds if needed.
A safety net of tests. Inline test cases validate detection logic before deployment. Positive tests prove it catches the threat; negative tests prove it doesn't fire on legitimate activity.
Confidence in what's deployed. terraform plan previews every change before anything touches production. Terraform state is the authoritative record of your detection estate, not some spreadsheet.

The result is a detection workflow your team can trust. Changes are predictable, validated, and fully traceable, so security teams don’t get caught up in troubleshooting and can focus on improving coverage and overall posture.

The anatomy of a detection

Here is what a detection rule looks like using Rapid7’s Terraform provider. It offers a practical view of how detection engineering teams can use Detection as Code in practice:

resource "rapid7_siem_detection_rule" "encoded_powershell" {
  name        = "Encoded PowerShell Command Execution"
description = "Detects PowerShell launched with base64-encoded commands"
techniques  = ["T1059.001"]
  action   = "CREATES_ALERTS"
priority = "HIGH"
logic = {
    leql = <<-LEQL
      from(event_type = process_start_event)
      where(
        (process.exe_path = /.*\\powershell\.exe$/i
         OR process.exe_path = /.*\\pwsh\.exe$/i)
        AND process.cmd_line ICONTAINS " -e"
AND process.cmd_line ICONTAINS-ANY [
" JAB", " SUVYI", " SQBFAFgA", " aWV4I"
]
      )
    LEQL
    testcases = [
      {
        matches = true
        payload = jsonencode({
          process = {
            exe_path = "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
cmd_line = "powershell.exe -ep bypass -e JABjAGwAaQBlAG4AdAA="
}
        })
      },
      {
        matches = false
        payload = jsonencode({
          process = {
            exe_path = "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
cmd_line = "powershell.exe -File C:\\Scripts\\backup.ps1"
}
        })
      }
    ]
  }
}

Why this works:

Version-controlled logic: The LEQL query defines the threat logic in a text format that Git can track.
MITRE ATT&CK^® untegration: The techniques field ensures your coverage map updates automatically.
Inline testing: We aren't just deploying a query, but a validated unit of logic. The pipeline won't let this reach production if the logic fails to fire on the matching" payload or accidentally fires on the un-matching payload.

Why Terraform?

Because it's the industry standard for managing infrastructure as code. We didn't invent a proprietary CLI; we built on the tool that thousands of platform teams already run daily. If your organization uses Terraform for cloud infrastructure, your detection engineers now use the same tool, the same workflow, and the same review process.

Governance happens naturally in this model. Open a pull request. Your team sees the logic, the test cases, and the expected behavior. They comment, suggest improvements, and approve. Every change is traceable in your commit history. This isn't a separate compliance exercise bolted onto your workflow. It is the workflow.

Already have rules built in the UI? One command imports them all:

terraform query -generate-config-out imports.tf

AI-assisted detection writing

The quick-start repo ships with IDE configurations for Claude Code, Cursor, VS Code Copilot, and Kiro. These configs give your AI assistant full context on the Terraform provider schema, LEQL syntax, and MITRE ATT&CK mappings.

In practice: open your editor, describe a threat in plain English, such as ‘write me a detection for lateral movement via RDP from non-admin workstations,’ and get back a complete Terraform resource ready for review. The AI accelerates the engineer; it doesn't replace them. The time from "I need a detection" to "this is ready for review" drops from hours to minutes.

Start building detections as code today

Rapid7’s Terraform provider for Detection as Code is now available across all Incident Command and InsightIDR tiers.

To get to work, use the Getting Started guide for a walkthrough as you setup, authenticate, and run your first deployment. Clone the quick-start template, run terraform plan, and see your detection estate as code.
For more information on Incident Command, visit Our hub page for SIEM.

v0.374.0

Thu, 07 May 2026 19:50:06 +0200

What's Changed

Force all invocations of dotnet msbuild to ignore response files by @brettfo in #14868
Implement sbt version and requirement classes by @AbhishekBhaskar in #14871
Fix 'Sourced from' link formatting for scoped packages #13972 by @v-HaripriyaC in #14833
Implement sbt file fetcher by @AbhishekBhaskar in #14874
[npm] Add dependency relationships to graphs produced for npm, pnpm and yarn by @brrygrdn in #14876
Fix uv workspace dependency updating by @andre-dsm in #14627
Use GitHub Repo Activity API to fetch Nix branch tips by @JamieMagee in #14840
Implement sbt file parser by @AbhishekBhaskar in #14890
go_modules: Add go.work workspace support by @casey-robertson-paypal in #14909
Add Deno ecosystem support by @sbs44 in #14364
[bun] Implement a first pass on graphing the bun package manager by @brrygrdn in #14881
Consolidate docker_compose into docker directory by @Copilot in #13834
add type for package management method by @brettfo in #14880
Fix Poetry git dependencies with extras losing extras during freeze by @markhallen in #14887
Fix security_update_not_possible when a dependency is hoisted during the update by @jasonpaulos in #14884
opentofu: support OCI modules end-to-end by @diofeher in #14858
fix: builtin/terraform error while updating OpenTofu by @diofeher in #13628
v0.374.0 by @dependabot-core-action-automation[bot] in #14931

New Contributors

@andre-dsm made their first contribution in #14627
@casey-robertson-paypal made their first contribution in #14909
@sbs44 made their first contribution in #14364

Full Changelog: v0.373.0...v0.374.0

IBM unveils its blueprint to help enterprises run AI at the core of their business

Tue, 05 May 2026 06:21:22 +0200

At its Think conference on Monday night, IBM announced what it calls a new operating model for the agentic enterprise.

It encompasses coordinated AI agents that execute across the business, real-time connected data, end-to-end automated workflows, and hybrid, including IBM Sovereign Core.

“Your AI is only as good as your data, which informs everything that we’ve been doing across both AI and hybrid cloud,” said Rob Thomas, IBM’s SVP of software. “We are talking this week about an AI operating model, which is how do companies leverage AI to become one of the winners in the AI era? It’s about how they do their intelligence, how they do automation, how they create AI for their operations, and ultimately trusted AI.”

Each of the four components of the model, although integrated, is a separate priority, IBM said in its announcement. “Together, they represent a fundamental shift from improving parts of the business to changing how the business operates.”

Product announcements to further the shift included the next generation of watsonx Orchestrate, which becomes an agentic control plane for the multi-agent era. It is now in private preview.

On the data side, the company is leveraging its recent acquisition of Confluent for real-time data streaming built on Kafka and Flink technologies, and the addition of a real-time context layer for AI to upcoming capabilities in watsonx.data.

IBM is also offering private previews of Context in watsonx.data that adds an open, federated context layer to help enterprise AI reason over business data, watsonx.data GPU-accelerated Presto that, the company said, “showed the potential to significantly reduce the cost of running certain workloads and processing time on large enterprise datasets in internal benchmark testing with Nvidia.” In addition, an IBM Z Database Assistant provides an AI-powered workspace to monitor performance, provide automation, and optimize configurations for Db2 and IMS databases across IBM Z environments.

In public preview, IBM announced HCP Terraform powered by Infragraph to offer unified infrastructure visibility.

The IBM Concert platform, also available in public preview, will serve the automation arm of the strategy. It provides a single view across applications, infrastructure, and networks without forcing companies to replace existing tools.

Finally, on the hybrid front, the company announced the general availability of its Sovereign Core.

Sanchit Vir Gogia, chief analyst at Greyhound Research, sees the new focus not so much as a group of products but as an “accountability architecture”.

“IBM’s AI Operating Model should be read less as another AI product bundle and more as IBM naming the problem now sitting at the centre of enterprise AI: accountability,” he said. “Large organizations are not short of AI tools. They are short of ways to govern what those tools do once they begin acting across data, workflows, applications, infrastructure and regulated environments. That is the real shift here. The market has spent two years proving that AI can be useful. The next test is whether AI can be made auditable, costed, secured, reversible and trusted inside the messy estates where enterprise technology actually lives.”

He noted, “IBM’s framing around Data, Agents, Automation and Hybrid is useful because those are not four neat product buckets. They are dependencies. Agents without trusted data become improvisation machines. Automation without governance becomes operational gambling. Hybrid without runtime policy becomes compliance theatre. Data without real-time context becomes yesterday’s truth wearing today’s clothes. The strength of IBM’s argument is that enterprise AI no longer scales as a collection of pilots. It has to operate as a connected system.”

Mark Tauschek, VP of Research Fellowships at Info-Tech Research Group, added, “Agentic orchestration and governance are quickly becoming table stakes as organizations start to see agent sprawl, inconsistent policy applied across agents, increased risk and exposure due to a lack of auditability, and ‘shadow’ AI. watsonx Orchestrate is IBM’s answer to the growing agent sprawl, and an answer to several similar solutions hitting the market in the last couple of weeks alone.”

Overall, “IBM has named the right problem. Now it has to prove the architecture holds under enterprise pressure,” Gogia said. “The future of enterprise AI belongs to those who can govern the action, not merely generate it.”

IBM unveils its blueprint to help enterprises run AI at the core of their business

Tue, 05 May 2026 06:16:53 +0200

At its Think conference on Monday night, IBM announced what it calls a new operating model for the agentic enterprise.

It encompasses coordinated AI agents that execute across the business, real-time connected data, end-to-end automated workflows, and hybrid, including IBM Sovereign Core.

Product announcements to further the shift included the next generation of watsonx Orchestrate, which becomes an agentic control plane for the multi-agent era. It is now in private preview.

In public preview, IBM announced HCP Terraform powered by Infragraph to offer unified infrastructure visibility.

Finally, on the hybrid front, the company announced the general availability of its Sovereign Core.

Sanchit Vir Gogia, chief analyst at Greyhound Research, sees the new focus not so much as a group of products but as an “accountability architecture”.

The article originally appeared on NetworkWorld.

v0.366.0

Tue, 05 May 2026 02:32:51 +0200

What's Changed

Add scanned_manifests_path metadata to snapshots by @brrygrdn in #14406
Fix regex pattern in pre-commit file parser and file-updater by @AbhishekBhaskar in #14429
Handle unhandled uv errors prefixed with CPython interpreter info by @thavaahariharangit in #14433
Handle Docker API version mismatch in script/build by @thavaahariharangit in #14436
Remove avoid_duplicate_updates_package_json FF from dependabot-core by @Copilot in #14428
Avoid sheering off directories by using manifest_file.directory by @brrygrdn in #14439
Fix: Bundler ignore rules now suppress path_dependencies_not_reachable errors during file fetching by @Copilot in #14435
Extend Swift UpdateChecker to support Xcode-managed SwiftPM projects by @AbhishekBhaskar in #14411
Extend Swift file updater to support xcode swiftpm dependency update by @AbhishekBhaskar in #14394
strip extras from Python PURLs in DG payload by @jakecoffman in #14462
only try to create pr if update operations were performed by @brettfo in #14463
additional unparseable file message by @brettfo in #14464
fix(github_actions): use most specific version tag when updating comments by @jeffwidman in #14461
fix(uv): strip extras from dependency names in PURL generation by @Copilot in #14468
Update corepack to 0.34.6 by @yeikel in #14371
Bump maven from 3.9.12 to 3.9.14 in /maven by @dependabot[bot] in #14446
honor update-types in grouped/ungrouped updater by @brettfo in #14475
feat: add .xcworkspace support for xcode swiftpm by @markhallen in #14459
fix(hex): correct tuple order for Hex.Repo.get_public_key response by @georgeguimaraes in #14380
Bump patch-package from 8.0.0 to 8.0.1 in /npm_and_yarn/helpers by @dependabot[bot] in #14445
Fix "Multiple sources!" error for case-variant Terraform/OpenTofu provider declarations by @Copilot in #14434
v0.366.0 by @dependabot-core-action-automation[bot] in #14481

New Contributors

@georgeguimaraes made their first contribution in #14380

Full Changelog: v0.365.0...v0.366.0

v0.368.0

Tue, 05 May 2026 02:32:30 +0200

What's Changed

Add package manager detection and enhance NoChangeError logging by @robaiken in #14539
Fix Incorrect Compare Link in Generated PR Body by @thavaahariharangit in #14531
Include PR title and body in update_pull_request API calls by @Copilot in #14492
Load nix ecosystem in updater setup by @JamieMagee in #14548
Fix invalid update to Pre-Commit dependencies with mixed versioning schemes by @AbhishekBhaskar in #14538
Fix crash with terraform modules using host:port sources by @jurre in #14541
Upgrade Erlang OTP major version to 27 by @vbalazs in #14485
fix broken pip-compile test by @jakecoffman in #14562
fix python fetching when environment markers present by @jakecoffman in #14559
Preserve npm workspace manifest updates in PR files by @thavaahariharangit in #14542
bundler cooldown feature; Remove GPR special-casing, add fallback for registries that don't support the necessary API endpoint by @jeffwidman in #14551
Bump brace-expansion from 1.1.11 to 1.1.13 in /bun/helpers/test/yarn/fixtures/conflicting-dependency-parser/deeply-nested by @dependabot[bot] in #14565
Bump brace-expansion in /npm_and_yarn/helpers by @dependabot[bot] in #14558
Bump brace-expansion from 1.1.12 to 1.1.13 in /npm_and_yarn/helpers/test/yarn/fixtures/conflicting-dependency-parser/deeply-nested by @dependabot[bot] in #14564
Bump brace-expansion from 1.1.11 to 1.1.13 in /npm_and_yarn/helpers/test/npm6/fixtures/conflicting-dependency-parser/deeply-nested by @dependabot[bot] in #14563
nix: fix permission denied on /nix/var/nix/db/big-lock by @JamieMagee in #14568
fix: Handle Excon::Error::Socket in RegistryClient and PackageDetailsFetcher by @markhallen in #14557
hex: add regression test for Hex.Repo.get_public_key/1 tuple order by @Copilot in #14407
fix Python update when the same dependency appears multiple times with different extras by @jakecoffman in #14578
feat: update Xcode pbxproj for Swift SPM by @markhallen in #14587
fix(conda): don't treat compound version constraints as fully qualified specs by @thavaahariharangit in #14586
[python][pip-compile] Fix constraint files (-c) in .in files not being fetched by @Copilot in #14588
Fix pre-commit tag prefix matching for monorepos with mixed tag prefixes by @AbhishekBhaskar in #14582
Add support for update-types in allow block by @Copilot in #12925
pip: Warn when ownership changes by @martincostello in #14235
terraform: handle private/unresolvable providers during lockfile updates by @jurre in #14585
Fix Python MetadataFinder leaking private package names to public PyPI by @jurre in #14590
Promote Nix ecosystem from beta to GA by @JamieMagee in #14597
Fix allow update-types filtering for individual dependency updates by @kbukum1 in #14598
v0.368.0 by @dependabot-core-action-automation[bot] in #14604

New Contributors

@vbalazs made their first contribution in #14485

Full Changelog: v0.367.0...v0.368.0

v0.369.0

Tue, 05 May 2026 02:32:26 +0200

What's Changed

Allow updates for sub-dependencies in XCode SwiftPM projects by @AbhishekBhaskar in #14619
bun: Add --ignore-scripts to bun install/update commands by @RyPeck in #14373
feat: centralize semver-aware cooldown calculation by @markhallen in #14600
Add tests for Pythons Native Helpers by @robaiken in #14646
Bump nix from 2.34.1 to 2.34.5 by @JamieMagee in #14657
Fix corepack fallback for private npm registries by @thavaahariharangit in #14654
Regression added to bun --ignore scripts changes by @thavaahariharangit in #14641
Handle terraform registry 404s gracefully by @jurre in #14556
Add support for JSR (jsr.io) registry in npm_and_yarn by @Copilot in #14647
feat: handle hybrid Poetry v2 dependency updates by @markhallen in #14658
feat: add cooldown filter for github_actions using existing git_commit_checker and available_latest_version_tag by @v-HaripriyaC in #14621
v0.369.0 by @dependabot-core-action-automation[bot] in #14663

New Contributors

@RyPeck made their first contribution in #14373
@v-HaripriyaC made their first contribution in #14621

Full Changelog: v0.368.0...v0.369.0

The $570K canary: What AI coding agents reveal about enterprise AI’s real gaps

Mon, 04 May 2026 12:07:26 +0200

Boris Cherny, creator of Anthropic’s Claude Code, says he hasn’t written a line of code by hand in months. He shipped 22 pull requests one day, 27 the next, all AI-generated. Company-wide, Anthropic reports that 70 to 90% of its code is now written by AI. CEO Dario Amodei has predicted that AI could handle “most, maybe all” of what software engineers do within months.

And yet Anthropic typically has dozens of software engineering openings, one reportedly carrying $570K in total compensation. As one observer noted, the company is simultaneously predicting the end of the profession and paying top dollar to hire into it.

Meanwhile, during his GTC 2026 keynote, NVIDIA CEO Jensen Huang said that 100% of NVIDIA now uses AI coding tools, including Claude Code, Codex and Cursor, often all three. Then, in a conversation on the All-In Podcast during GTC week, Huang sharpened the point: A $500,000 engineer who doesn’t consume at least $250,000 in AI tokens annually is like “one of our chip designers who says, guess what, I’m just going to use paper and pencil.”

This isn’t cognitive dissonance. It’s a signal. And CIOs who look past the headlines will find a pattern that explains not just where AI coding is going, but where all of enterprise AI is headed.

Tellers, not toll booth workers

The instinct is to see this as an extinction event. AI writes all the code; engineers become toll booth workers, replaced entirely by automation with no complementary role left behind. But the data tells a different story, one I explored in a recent CIO.com article on AGI skepticism.

When ATMs rolled out, bank teller employment didn’t collapse. It doubled, from 268,000 in 1970 to 608,000 in 2006. The machines eliminated the routine transaction. But cheaper branch operations meant banks opened more locations, which created demand for tellers who could handle complex financial conversations. Economists call this Jevons Paradox: When technology makes something more efficient, demand expands rather than contracts.

Software engineers are bank tellers, not toll booth workers. AI agents are eliminating routine implementation: The boilerplate, the CRUD endpoints, the standard test scaffolding. But that efficiency is expanding the total surface area of what “engineering” means. Anthropic isn’t paying $570K for someone to type code. They’re paying for the judgment to orchestrate AI agents that type code: Deciding what to build, evaluating whether the output is correct, governing what gets deployed and maintaining systems that are increasingly written by machines.

Cherny confirmed this shift directly. His team now hires generalists over specialists, because traditional programming specialties are less relevant when AI handles implementation details. The skill premium has moved from writing code to supervising it, from production to orchestration.

The reason AI coding agents work

Here’s the question CIOs should be asking: Why are AI agents succeeding in software development faster than in any other enterprise function?

It’s not because coding models are better than models for customer service, legal review or financial analysis. The underlying LLMs are the same. The difference is that software development already had the infrastructure that every other enterprise function lacks.

Developers didn’t build this infrastructure for AI. They built it for themselves, over decades. But it maps almost perfectly to the six infrastructure gaps that are currently blocking AI agents from moving beyond employee-facing pilots into customer-facing production.

6 gaps the SDLC already solved

1. Governance: Right data, right users, right permissions

In software development, governance is built into the workflow. Branch protection, code review policies and role-based access controls create a clear chain of permission from draft to deploy, whether the author is human or agent.

Most enterprise functions have nothing equivalent. When an AI agent drafts a customer response, accesses a patient record or modifies a financial model, the governance layer (who approved this action, what data was it allowed to see, which policies constrain its output) is either ad hoc or absent. Microsoft’s 2026 Cyber Pulse survey found that while 80% of Fortune 500 companies have deployed AI agents, only 47% have agent-specific security policies in place.

2. Observability: Trace and audit the decision trail

Every line of AI-generated code has a paper trail. Git blame shows who (or what) wrote it. CI/CD pipelines log every build, test and deployment. When something breaks in production, engineers can trace the failure from alert to commit to the specific agent session that produced the change.

Outside of engineering, AI agent decisions are largely opaque. A customer-facing agent that denies a claim or escalates a complaint leaves no audit trail. Without observability, enterprises can’t debug bad outcomes, satisfy regulators or build the trust necessary to expand agent autonomy.

3. Evaluation: Measure correctness at scale

Unit tests, integration tests, type checking, linting and automated QA give software engineering something no other enterprise function has: Continuous, objective measurement of whether AI-generated output is correct. That provides a foundation for proving an agent gets it right.

This is the gap other enterprise functions feel most acutely. DigitalOcean’s 2026 survey of 1,100 technology leaders found that 41% cite reliability as their number one barrier to scaling AI agents. Reliability is an evaluation problem: Without automated, continuous measurement of agent output quality, organizations can’t trust agents enough to put them in front of customers.

4. Memory: Persistent context beyond the context window

Developers take persistent context for granted. Version control, documentation and architectural decision records provide context that survives across sessions, teams and years. An AI coding agent can read the commit history, understand why a design choice was made in 2019, and factor it into today’s implementation.

Most enterprise AI agents operate in a memoryless state. Each customer interaction starts from scratch. Each agent session has no awareness of prior decisions, escalations or context beyond what fits in the context window. This is why employee-facing agents (IT help desks, NOC ticketing) succeed where customer-facing agents stall: Internal users tolerate repeating context. Customers do not.

5. Cost controls: Manage LLM spend across providers

Jensen Huang’s $250K-per-engineer token budget isn’t an abstraction. It’s a real cost management challenge that engineering teams are already navigating. Smart teams route differently depending on the task: Use a lightweight model for boilerplate generation, a reasoning model for architectural decisions and a code-specific model for refactoring. They set token budgets per agent session. They measure cost-per-PR and cost-per-feature, not just cost-per-token.

Enterprises deploying AI agents in other functions rarely have this granularity. When Goldman Sachs stated AI near-zero GDP impact in 2025, the missing variable was cost discipline at the workflow level. Without the ability to route, throttle and measure LLM spend per agent task, scaling agents means scaling costs linearly, which eventually kills ROI.

6. Deployment flexibility: Any cloud, on-prem, no lock-in

In software development, the runtime has always been portable. Code that runs on AWS today can run on Azure tomorrow, or on bare metal in your own data center. Containerization, Kubernetes and infrastructure-as-code tools like Terraform mean that engineering teams can change their minds about where workloads run without rewriting the application. Software has had this mindset for decades.

We’re early enough in this agentic development game that it’s tempting to take short cuts. Organizations that build on a single hyperscaler’s agent framework find themselves locked into that provider’s model ecosystem, observability tooling and pricing structure. As agentic AI matures, deployment flexibility (the ability to run agents on any cloud, on-prem or across hybrid environments without vendor lock-in) will separate organizations that scale from those that stall.

Sometimes you’ll want agents to run close to your data. Other times, you’ll want agents close to the users. And you’ll want your developers to be able to move back and forth between different agent code bases without having to learn a different framework between them.

What CIOs should watch at Build and I/O

Google I/O and Microsoft Build will dominate May with dueling AI coding announcements. The temptation will be to compare model benchmarks. That’s the wrong lens. The models are converging. The real competition is one layer down, in the infrastructure that makes AI agents viable outside of software development.

CIOs watching these conferences should evaluate each announcement against the six gaps: Is Microsoft closing the governance gap with Azure AI Foundry? Is Google advancing observability through Vertex AI? Which platform is making it easier to evaluate agent output at scale, maintain persistent memory across sessions, control costs at the workflow level and deploy without lock-in?

The company that wins the AI coding war will be the one that builds the infrastructure layer that transfers to every other enterprise function. That’s the real stakes of May’s developer conferences, and it’s the real reason CIOs should be paying attention.

The canary’s message

Software engineers are the first knowledge workers to live inside a fully agentic workflow. They’re the canary in the coal mine for every other enterprise function. And right now, the canary is singing, not dying.

The lesson isn’t that AI coding agents have made engineers obsolete. It’s that AI coding agents work because engineers already built the infrastructure that makes agents trustworthy. Governance, observability, evaluation, memory, cost controls and deployment flexibility: These aren’t nice-to-haves. They’re the reason Anthropic can ship 27 AI-generated pull requests in a day and sleep at night.

Every other enterprise function will need to build its own version of that infrastructure before AI agents can move from employee-facing pilots to customer-facing production. The models aren’t the bottleneck. The scaffolding around them is.

Anthropic paying $570K for a software engineer whose job might not exist in a year isn’t a contradiction. It’s Jevons Paradox. And it’s the most expensive leading indicator in enterprise AI.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

From Infrastructure to Agents: A Hands-On Guide to Secure Private AI with Broadcom – Part 2

Thu, 30 Apr 2026 15:31:16 +0200

In Part 2 of our blog series, we close the critical lateral security gap that exists inside the k8s cluster, which is not solved by standard perimeter security. We detail how to use VMware vDefend Distributed Firewall, enforced through Antrea CNI, to implement Zero Trust microsegmentation for GPU-accelerated AI workloads. Specifically, we walk through defining identity-based firewall rules as Terraform code for the NVIDIA NIM RAG Blueprint and demonstrate how Antrea Egress preserves pod identity to block unauthorized access to sensitive external assets, like the Elasticsearch vector database, using packet-by-packet Antrea Traceflow verification

The post From Infrastructure to Agents: A Hands-On Guide to Secure Private AI with Broadcom – Part 2 appeared first on VMware Cloud Foundation (VCF) Blog.

OpenTofu vs Terraform: The Open-Source Infrastructure Tool for Linux Admins

Mon, 27 Apr 2026 05:07:21 +0200

OpenTofu is the open-source fork of Terraform under the Linux Foundation. I explain the licensing split, walk through a safe migration from an existing Terraform project, and cover the unique features OpenTofu now has that Terraform does not.

CLI that diffs code at the entity level (functions, classes, structs) for better structural awareness

Fri, 24 Apr 2026 05:37:27 +0200

git diff is beautiful and is optimized for showing you changed lines. I have been recently working and researching on a CLI tool that diffs code at the entity level (functions, classes, structs) instead of raw lines.

most of the time what you actually want to know is, which functions changed? Was it a real logic change or just formatting? What depends on the thing I'm about to modify?

sem extracts entities using tree-sitter and diffs at that level. Instead of scrolling through hunks of +/- lines, you get the actual changes: which struct changed, which function was added, which ones were modified.

It also does impact analysis. sem impact shows everything that depends on that function, transitively, across the whole repo. Useful when you're about to change something and want to know what might break before you break it.

Commands:

- sem diff - entity-level diff with word-level inline highlights
- sem entities - list all entities in a file with their line ranges
- sem impact - show what breaks if an entity changes
- sem blame - git blame at the entity level
- sem log - track how an entity evolved over time
- sem context - token-budgeted context for feeding diffs to LLMs (fewer tokens, more signal)

25 language parsers: Rust, Python, TypeScript, JavaScript, Go, Java, C, C++, C#, Ruby, PHP, Swift, Kotlin, Dart, Scala, Zig, OCaml, Elixir, Perl, Fortran, Bash, HCL/Terraform, plus Vue, Svelte, ERB, XML, JSON, YAML, TOML, Markdown, CSV.

Written in Rust. Single binary. Open source.

GitHub: https://github.com/Ataraxy-Labs/sem

submitted by /u/Wise_Reflection_8340
[link] [comments]

Security updates for Friday

Fri, 17 Apr 2026 15:45:35 +0200

Security updates have been issued by AlmaLinux (.NET 8.0, .NET 9.0, freerdp, libarchive, and thunderbird), Debian (chromium, openssh, and thunderbird), Fedora (aurorae, bluedevil, breeze-gtk, buildah, cockpit, extra-cmake-modules, flatpak-kcm, grub2-breeze-theme, kactivitymanagerd, kcm_wacomtablet, kde-cli-tools, kde-gtk-config, kdecoration, kdeplasma-addons, kf6, kf6-attica, kf6-baloo, kf6-bluez-qt, kf6-breeze-icons, kf6-frameworkintegration, kf6-kapidox, kf6-karchive, kf6-kauth, kf6-kbookmarks, kf6-kcalendarcore, kf6-kcmutils, kf6-kcodecs, kf6-kcolorscheme, kf6-kcompletion, kf6-kconfig, kf6-kconfigwidgets, kf6-kcontacts, kf6-kcoreaddons, kf6-kcrash, kf6-kdav, kf6-kdbusaddons, kf6-kdeclarative, kf6-kded, kf6-kdesu, kf6-kdnssd, kf6-kdoctools, kf6-kfilemetadata, kf6-kglobalaccel, kf6-kguiaddons, kf6-kholidays, kf6-ki18n, kf6-kiconthemes, kf6-kidletime, kf6-kimageformats, kf6-kio, kf6-kirigami, kf6-kitemmodels, kf6-kitemviews, kf6-kjobwidgets, kf6-knewstuff, kf6-knotifications, kf6-knotifyconfig, kf6-kpackage, kf6-kparts, kf6-kpeople, kf6-kplotting, kf6-kpty, kf6-kquickcharts, kf6-krunner, kf6-kservice, kf6-kstatusnotifieritem, kf6-ksvg, kf6-ktexteditor, kf6-ktexttemplate, kf6-ktextwidgets, kf6-kunitconversion, kf6-kuserfeedback, kf6-kwallet, kf6-kwidgetsaddons, kf6-kwindowsystem, kf6-kxmlgui, kf6-modemmanager-qt, kf6-networkmanager-qt, kf6-prison, kf6-purpose, kf6-qqc2-desktop-style, kf6-solid, kf6-sonnet, kf6-syndication, kf6-syntax-highlighting, kf6-threadweaver, kgamma, kglobalacceld, kinfocenter, kmenuedit, knighttime, kpipewire, krdp, kscreen, kscreenlocker, ksshaskpass, ksystemstats, kwayland, kwayland-integration, kwin, kwin-x11, kwrited, layer-shell-qt, libexif, libkscreen, libksysguard, libplasma, nix, ocean-sound-theme, oxygen-sounds, pam-kwallet, plasma-activities, plasma-activities-stats, plasma-breeze, plasma-browser-integration, plasma-desktop, plasma-dialer, plasma-discover, plasma-disks, plasma-drkonqi, plasma-firewall, plasma-integration, plasma-keyboard, plasma-login-manager, plasma-milou, plasma-mobile, plasma-nano, plasma-nm, plasma-oxygen, plasma-pa, plasma-print-manager, plasma-sdk, plasma-setup, plasma-systemmonitor, plasma-systemsettings, plasma-thunderbolt, plasma-vault, plasma-welcome, plasma-workspace, plasma-workspace-wallpapers, plasma-workspace-x11, plasma5support, plymouth-kcm, plymouth-theme-breeze, podman, polkit-kde, powerdevil, qqc2-breeze-style, sddm-kcm, skopeo, spacebar, spectacle, thunderbird, and xdg-desktop-portal-kde), Mageia (cockpit-338), Oracle (capstone, cockpit, firefox, fontforge, freerdp, golang-github-openprinting-ipp-usb, kernel, nghttp2, nodejs:20, nodejs:24, openexr, and squid), Red Hat (gnutls, libarchive, libpng, libpng12, libpng15, libtiff, libvpx, libxslt, multiple packages, python, python3, python3.11, python3.12, and python3.9), Slackware (libxml2), SUSE (apache-pdfbox, azure-storage-azcopy, corosync, cups, freerdp, iproute2, libsdb2_4_2, libtpms, NetworkManager, openssl-1_1, ovmf, plexus-utils, python, python-CairoSVG, python-jwcrypto, python-PyJWT, python-pyOpenSSL, python-urllib3, python3, python314, rust1.93, shim, smc-tools, terraform-provider-local, terraform-provider-random, terraform-provider-tls, thunderbird, tiff, util-linux, and vim), and Ubuntu (libowasp-esapi-java, linux, linux-aws, linux-aws-5.15, linux-gcp, linux-gke, linux-gkeop, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-oracle, linux, linux-aws, linux-aws-6.8, linux-gcp, linux-gke, linux-gkeop, linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.8, linux, linux-realtime, linux-aws-fips, linux-fips, linux-gcp-fips, linux-fips, linux-gcp-fips, linux-gcp, linux-gcp-6.17, linux-hwe-5.15, linux-intel-iot-realtime, linux-realtime, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, linux-nvidia-tegra, linux-nvidia-tegra, linux-nvidia-tegra-igx, linux-realtime, linux-realtime-6.8, linux-realtime-6.17, ofono, and ruby-rack).

Security: Zwei Probleme in terraform-provider-local, terraform-provider-random und terraform-provider-tls (SUSE)

Thu, 16 Apr 2026 23:46:16 +0200

GitLab Security Update Fixes High-Severity CVE-2026-5173, 11 Other Flaws

Fri, 10 Apr 2026 08:37:24 +0200

GitLab has rolled out a major security update to address a series of vulnerabilities impacting both its Community Edition (CE) and Enterprise Edition (EE) platforms. The GitLab security update resolves multiple flaws, including high-severity issues that could be exploited to disrupt services or gain unintended access to system functionality. This update is particularly critical for organizations operating in self-managed GitLab environments, where administrators are responsible for applying patches and maintaining system security. Delaying the deployment of this GitLab security update could leave systems exposed to known threats, including the actively addressed CVE-2026-5173 vulnerability. The patch release not only strengthens access controls but also mitigates risks tied to denial-of-service attacks, data exposure, and improper authorization checks. As a result, GitLab is strongly urging all affected users to upgrade to the latest versions immediately to ensure their environments remain protected against potential exploitation.

Critical GitLab Security Update Targets High-Severity Flaws

GitLab security update covers a high-severity vulnerability tracked as CVE-2026-5173, which impacts websocket connections. This flaw could allow an authenticated attacker to bypass access controls and invoke unintended server-side methods. With a CVSS score of 8.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N), the issue represents a serious risk to affected environments. The vulnerability was discovered internally by GitLab team member Simon Tomlinson. It affects GitLab CE/EE versions from 16.9.6 prior to 18.8.9, version 18.9 before 18.9.5, and version 18.10 before 18.10.3. The latest security patch resolves this issue along with several others.

Patch Releases and Affected Versions

The GitLab security update includes patched versions 18.10.3, 18.9.5, and 18.8.9. According to the official release statement: “Today, we are releasing versions 18.10.3, 18.9.5, 18.8.9 for GitLab Community Edition (CE) and Enterprise Edition (EE). These versions contain important bug and security fixes, and we strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately.” GitLab confirmed that users of GitLab.com and GitLab Dedicated services are already protected and do not need to take action.

Twelve Vulnerabilities Addressed

This GitLab security update resolves a total of twelve vulnerabilities, ranging from high to low severity. Alongside CVE-2026-5173, several denial-of-service (DoS) vulnerabilities were identified:

CVE-2026-1092: A DoS issue in the Terraform state lock API caused by improper JSON validation (CVSS 7.5).
CVE-2025-12664: A DoS vulnerability in the GraphQL API that could be triggered through repeated queries (CVSS 7.5).
CVE-2026-1403: A CSV import flaw allowing authenticated users to disrupt Sidekiq workers (CVSS 6.5).
CVE-2026-1101: A GraphQL SBOM API issue affecting GitLab EE, also enabling DoS attacks (CVSS 6.5).

In addition to these, multiple medium-severity flaws were patched:

CVE-2026-1516: A code injection issue in Code Quality reports that could expose user IP addresses (CVSS 5.7).
CVE-2026-4332: A cross-site scripting vulnerability in analytics dashboards (CVSS 5.4).
CVE-2026-2619: Incorrect authorization in the vulnerability flags AI detection API (CVSS 4.3).
CVE-2025-9484: Information disclosure via GraphQL queries (CVSS 4.3).
CVE-2026-1752: Improper access control in the Environments API (CVSS 4.3).
CVE-2026-2104: Information disclosure through CSV export (CVSS 4.3).

A low-severity issue, CVE-2026-4916, was also addressed, involving missing authorization checks in custom role permissions (CVSS 2.7). Many of these vulnerabilities were reported through GitLab’s HackerOne bug bounty program, highlighting contributions from researchers such as a92847865, foxribeye, sim4n6, maksyche, go7f0, and others.

Bug Fixes and Stability Improvements

Beyond security fixes, the update also includes a wide range of bug fixes across all three versions. These improvements address issues such as failed Git operations for deploy keys on Geo sites, performance optimizations in migration helpers, and compatibility fixes for Amazon Linux 2023. Other fixes include resolving flaky test cases, improving dependency proxy access, and addressing regressions in project archiving and deletion workflows. These updates aim to enhance overall platform stability alongside the security patch.

Upgrade Guidance and Deployment Notes

GitLab emphasized that no new migrations are included in these releases, meaning multi-node deployments should not require downtime. However, by default, Omnibus packages will stop services, run migrations, and restart during upgrades unless configured otherwise via the /etc/gitlab/skip-auto-reconfigure file. The company also noted that certain package builds, such as SLES 12.5 for versions 18.10.3 and 18.9.5, are not included in this release. Additionally, GitLab confirmed that version numbers 18.10.2, 18.9.4, and 18.8.8 were skipped, with no patches issued under those versions.

The Terraform scaling problem: When infrastructure-as-code becomes infrastructure-as-complexity

Tue, 07 Apr 2026 15:03:34 +0200

Terraform promised us a better world. Define your infrastructure in code, version it, review it, and deploy it with confidence. For small teams running a handful of services, that promise holds up beautifully.

Then your organization grows. Teams multiply. Modules branch and fork. State files balloon. And suddenly, that clean declarative vision starts looking a lot like a sprawling monolith that nobody fully understands and everyone is afraid to touch.

If you’ve ever watched a Terraform plan run for 20 minutes, encountered a corrupted state file at 2 a.m. or inherited a Terraform codebase where half the resources are undocumented and a quarter are unmanaged, you know exactly what we’re talking about. This is the Terraform scaling problem, and it’s affecting engineering organizations of every size.

The numbers confirm it isn’t a niche concern. The 2023 State of IaC Report found that 90% of cloud users are already using infrastructure-as-code, with Terraform commanding 76% market share according to the CNCF 2024 Annual Survey. Yet the HashiCorp State of Cloud Strategy Survey 2024 showed that 64% of organizations report a shortage of skilled cloud and automation staff, creating a dangerous gap between Terraform’s adoption and the expertise required to operate it well at scale.

In this post, we break down where Terraform breaks down, why traditional solutions fall short, and how AI-assisted IaC management is offering a credible path forward.

The root causes of Terraform complexity at scale

Terraform’s design philosophy is fundamentally sound: Declarative infrastructure, idempotent operations and a provider ecosystem that covers nearly every cloud service imaginable. The problem isn’t the tool; it’s the gap between how Terraform was designed to work and how large engineering organizations actually operate.

State management becomes a full-time job

Terraform’s state file is both its greatest strength and its biggest liability at scale. State gives Terraform the ability to track what it has deployed and calculate diffs — but as infrastructure grows, that state file becomes a critical shared resource with no native support for distributed access patterns.

Teams running a monolithic state end up with a single point of contention. Engineers queue up to run plans and apply. Locking mechanisms in backends like S3 with DynamoDB help, but they don’t solve the underlying architectural issue: Everyone is competing for the same resource.

The HashiCorp State of Cloud Strategy Survey consistently places state management issues, corruption, drift and locking failures among the top pain points for Terraform users in organizations with more than 50 engineers. When a state file gets corrupted mid-apply, recovery can take hours and require deep expertise. The problem compounds as infrastructure grows: Organizations running more than 500 managed resources in a single workspace routinely report 15–30 minute plan times, turning what should be a fast feedback loop into a deployment bottleneck.

Module sprawl and dependency hell

Terraform modules are the right answer to code reuse. They’re also the source of some of the most painful debugging sessions in platform engineering.

As organizations scale, module libraries grow organically. Teams fork modules to meet specific requirements. Version pinning gets inconsistent. A security patch in a root module requires coordinated updates across dozens of dependent modules — a task that sounds simple until you’re dealing with circular dependencies, incompatible provider versions and module registries that weren’t designed for enterprise governance.

Adopting semantic versioning for Terraform modules has a measurable impact: According to a Moldstud IaC case study (June 2025), approximately 60% of organizations that enforce semantic versioning on module releases report a decrease in deployment failures over six months. Yet most teams don’t adopt this practice until after they’ve experienced the failure modes firsthand. The same research found that teams using peer reviews for Terraform code experience a 30% improvement in code quality but this requires process investment that most fast-moving platform teams skip in the early stages.

The pattern is consistent: What starts as a tidy module hierarchy becomes a tangled dependency graph that requires tribal knowledge to navigate.

Plan times and blast radius

At a certain scale, the Terraform plan stops being a quick feedback loop and starts being a liability. Teams managing thousands of resources in a single workspace can wait 15–30 minutes for a plan to complete. More critically, the blast radius of a single application expands proportionally.

A misconfigured security group rule in a small workspace affects a handful of resources. The same mistake in a large monolithic workspace can cascade across hundreds of resources before anyone can intervene. Terraform’s own declarative model means that configuration errors can trigger resource destruction, a risk that grows with workspace size. This reality pushes teams toward increasingly conservative change management processes, which defeats the core value proposition of IaC in the first place.

There’s a meaningful ROI case for solving this. The Moldstud IaC case study indicates that implementing automated IaC solutions can lead to a 70% reduction in deployment times. But capturing that return requires architectural decisions that prevent plan-time bottlenecks before they compound.

Drift: The silent killer

Infrastructure drift — where the actual state of your cloud environment diverges from what Terraform believes it to be — is among the most insidious challenges at scale. It accumulates slowly, through emergency console changes, partially applied runs and resources created outside of Terraform entirely.

The causes are well-documented: An on-call engineer hotfixes a security group at 3 a.m. and forgets to update the code; an autoscaling event modifies a resource configuration that Terraform manages; a third-party integration quietly changes a setting that Terraform has no visibility into. Each of these is a small divergence. Collectively, they erode the reliability of your entire IaC foundation. Terraform Drift Detection Guide documents how teams across industries are consistently caught off guard by drift accumulation in environments they believed were fully under IaC control.

By the time drift becomes visible, it’s often embedded deep enough to make remediation genuinely risky. The DORA 2023 State of DevOps Report found that teams dealing with frequent configuration drift had 2.3× higher change failure rates than teams maintaining consistent IaC hygiene. The compounding effect is significant: Drift erodes confidence in your IaC, which leads to more manual changes, which causes more drift.

Why traditional approaches fall short

The conventional responses to Terraform scaling challenges are well-documented: Workspace decomposition, remote state backends, CI/CD pipelines with policy enforcement and module registries with semantic versioning. These are all necessary practices. They’re also insufficient on their own.

Workspace decomposition reduces blast radius but multiplies operational overhead. You’re trading one large problem for many smaller ones, each requiring its own state management, access controls and pipeline configuration. Managing 200 workspaces is a full-time engineering effort.
CI/CD enforcement catches policy violations after the fact. By the time a plan hits your pipeline, an engineer has already spent time writing code that may get rejected. Feedback loops are slow, and the root cause — the complexity of authoring correct IaC at scale — remains unsolved.
Manual code reviews don’t scale. Platform teams can become bottlenecks when every Terraform change requires expert review to validate correctness, security posture and compliance. The cognitive load required to review infrastructure changes accurately is substantial, and reviewers burn out. This bottleneck is only sharpened by the talent shortage: With 64% of organizations reporting a shortage of skilled cloud and automation staff, the supply of qualified reviewers isn’t growing fast enough to match Terraform’s adoption curve.

The honest assessment: These solutions manage Terraform complexity rather than resolving it. They require ongoing investment in tooling, process and expertise that many organizations struggle to maintain.

This is exactly the friction that StackGen’s Intent-to-Infrastructure Platform was designed to address. Rather than adding more manual process overhead, it introduces an intelligent layer that helps teams author, validate and govern Terraform configurations from the point of intent before complexity accumulates.

Emerging solutions: Where the industry is moving

The Terraform ecosystem is evolving rapidly in response to these challenges. The global IaC market reflects this urgency: Valued at $847 million in 2023, it’s projected to reach $3.76 billion by 2030 at a 24.4% compound annual growth rate, according to Grand View Research’s IaC Market Report. That growth isn’t just adoption — it’s investment in solving the complexity problems that widespread adoption creates.

Workspace automation and orchestration

Tools like Atlantis, Stackgen, Terraform Cloud, are moving toward intelligent workspace orchestration, automatically managing dependencies between workspaces, ordering applies correctly and providing better visibility into cross-workspace impact. This reduces the manual coordination overhead that plagues large-scale Terraform operations.

The key shift is treating your collection of workspaces as a managed system rather than a set of independent units. When a shared networking module changes, an orchestration layer should automatically identify affected workspaces, calculate the propagation order and manage the apply sequence — rather than requiring a human to track and coordinate each dependency manually.

Policy-as-code with earlier enforcement

Open Policy Agent (OPA) and HashiCorp Sentinel have matured significantly. More importantly, teams are learning to push policy enforcement left — validating Terraform plans against organizational policies before they hit a CI/CD pipeline, and ideally before they’re even submitted for review.

HashiCorp has reported that teams using Sentinel with pre-plan validation see a 45% reduction in policy violation-related build failures compared to teams running post-plan enforcement only. Earlier feedback means faster iteration and lower engineer frustration.

AI-assisted IaC management: The emerging frontier

This is where the most significant innovation is happening. AI-assisted infrastructure management addresses the problems that automation alone can’t solve: The cognitive complexity of understanding large IaC codebases, identifying drift patterns before they become critical and translating high-level intent into correct, compliant Terraform code.

Platforms like StackGen’s Intent-to-Infrastructure Platform represent a new paradigm here. Rather than requiring platform engineers to manually author and review every Terraform resource definition, StackGen interprets infrastructure intent — expressed in natural language or high-level policy- and generates compliant Terraform configurations, validates them against organizational standards and surfaces potential issues before they reach production. This directly addresses the bottleneck where expert review becomes a constraint on velocity.

The practical applications are concrete:

Drift detection and remediation: AI models trained on infrastructure patterns can identify anomalous drift, distinguishing between expected configuration changes and unauthorized modifications, and surface remediation recommendations with context about impact and risk. This is particularly powerful for teams managing hundreds of workspaces where manual drift monitoring isn’t practical.
Intelligent module recommendations: Rather than requiring engineers to navigate sprawling module registries manually, AI-assisted tooling can analyse an infrastructure request, identify the most appropriate existing modules and flag where new module development is needed. This reduces the “reinvent the wheel” pattern that causes module sprawl.
Natural language to IaC: For platform teams managing self-service infrastructure portals, AI translation layers allow development teams to request infrastructure in natural language and receive validated Terraform configurations that conform to organizational standards — without requiring deep Terraform expertise from every team consuming platform services.
Proactive complexity warnings: AI analysis of Terraform codebases can identify emerging complexity patterns before they become critical — detecting circular dependencies forming, state files approaching problematic size thresholds or module versioning patterns that suggest future compatibility issues.

Gartner predicts that by 2026, more than 40% of organizations will be using AI-augmented IaC tooling for some portion of their infrastructure management workflow — up from under 10% in 2023. The trajectory is clear, and the window for early-mover advantage is still open.

Practical guidance: Scaling terraform without losing your mind

While AI-assisted tooling continues to mature, there are concrete architectural and process changes your team can adopt today.

Decompose by domain, not by team. Workspace boundaries should reflect infrastructure domains (networking, compute, data) rather than organizational team boundaries. Teams change; infrastructure domains are more stable. This reduces the reorganization tax you pay when teams restructure.
Treat state as infrastructure. Your state backend deserves the same reliability engineering as production systems. Remote state with versioning, automated backup verification and clear recovery runbooks should be non-negotiable before you’re managing more than a few dozen resources. The HashiCorp State of Cloud Strategy Survey shows that over 80% of enterprises already integrate IaC into their CI/CD pipelines — but pipeline integration doesn’t substitute for state backend reliability.
Invest in a private module registry early. Whether you use Terraform Cloud’s built-in registry, a self-hosted solution or a structured module registry with enforced semantic versioning pays compounding dividends as your module library grows. The cost of retrofitting governance onto an ungoverned module library is significantly higher than building in governance from the start.
Automate drift detection, not just drift remediation. Drift remediation is expensive; drift detection is cheap. Scheduled Terraform plan runs in CI/CD, combined with alerting on detected drift, give you an early warning system that prevents drift from compounding silently. For teams managing large environments where manual detection becomes impractical, automated drift tooling, whether native to HCP Terraform or third-party solutions, becomes essential infrastructure in its own right.
Build a paved road for Terraform consumers. If every application team needs to become a Terraform expert to consume platform services, your platform won’t scale. Build opinionated, simplified interfaces, whether that’s a service catalogue, a self-service portal or an AI-assisted request layer that allows development teams to get the infrastructure they need without requiring deep IaC expertise.

The strategic inflection point

We’re at an inflection point in how the industry thinks about infrastructure-as-code. The original vision of IaC infrastructure defined, versioned and managed like software was correct. The execution, for large-scale organizations, has accumulated significant complexity debt.

The next wave of IaC tooling isn’t about replacing Terraform. Terraform’s declarative model, provider ecosystem and community are genuine strengths that won’t be supplanted quickly. The opportunity is in the layer above Terraform: Intelligent orchestration, AI-assisted authoring, proactive complexity management and intent-driven infrastructure interfaces that make IaC accessible to the full organization rather than just a specialized subset of platform engineers.

Teams that invest in this layer now, whether through emerging platforms, internal tooling or AI-assisted workflows, will build a meaningful operational advantage. Teams that continue fighting Terraform complexity with more Terraform will find themselves spending an increasing proportion of engineering capacity on infrastructure maintenance rather than product development.

The IaC market’s 24.4% CAGR reflects growing awareness that the tools and processes managing this complexity need to evolve as fast as the infrastructure they govern.

Key takeaways

The Terraform scaling problem is real, but it’s solvable. The path forward involves three parallel tracks: Architectural decisions that manage blast radius and reduce state contention; process investments in policy-as-code and module governance; and tooling that uses AI to address the cognitive complexity that has always been the hardest part of IaC at scale.

Your infrastructure code should accelerate your engineering organization, not constrain it. If it’s doing the latter, the problem isn’t your engineers; it’s the layer of tooling and process sitting between intent and deployed infrastructure.

Ready to explore how AI-assisted IaC management can reduce the complexity overhead in your Terraform workflows?

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Using Azure Copilot for migration and modernization

Wed, 01 Apr 2026 00:32:39 +0200

Microsoft has given Azure many hats: a serverless platform for distributed applications, a host for security and identity services, a place for big data, and an alternative to running your own data centers and infrastructure.

It’s this last one that’s often forgotten since much of the thinking about cloud platforms focuses on new tools and technologies instead of the old faithful applications that have been lifted and shifted to the cloud. The lift-and-shift process has become increasingly important as a tool to help get rid of servers and also make some headway against the perennial problem of technical debt.

Solving technical debt

Building new applications is easy, but it’s hard to keep them up-to-date. The budget for maintenance never quite covers the necessary work, so applications and servers keep running until it’s impossible to keep them going. Historically that’s meant aged mainframes running for more than 50 years, or a nuclear power plant being controlled from an emulation running in another emulation on top of a stack of virtual machines.

That’s the extreme end of technical debt—software archaeology rather than software engineering. Day-to-day technical debt is perhaps better thought of as a drag on business, code that doesn’t quite fit the current state of a business process, requiring manual workarounds that slow things down but allow the applications to keep running. There’s associated compounding risk as applications, operating systems, storage, and networks drift away from security baselines, dropping out of support, unpatched because any updates could stop the business from operating.

Migrating to the cloud can help, but too often it’s a matter of simply replicating a physical infrastructure in virtual machines on an IaaS platform. Yes, hyperscale cloud PaaS features could solve problems, as well as using automated updates and upgrades to deploy the latest features and keep applications more secure.

Automating cloud migrations

Microsoft has offered several generations of tools to migrate applications to the cloud, mostly focused on finding the right-size Azure virtual machines and the right virtual network appliances and topography, as well as importing data into cloud storage. Microsoft has provided useful ways to move applications to the cloud, but the company hasn’t helped you modernize code or infrastructure. Enterprises are just replicating technical debt in Azure instead of on their own servers.

Even if you use these tools, a migration can take months of planning and testing, and the disconnect between IT teams focusing on infrastructure and development teams focusing on the code means there’s no shared view of the entire task.

How then can Microsoft break down the barriers between teams and use migration as an opportunity to help modernize software and reduce technical debt?

Azure Copilot for migration and modernization

The latest version of the Azure Copilot recently launched, building on earlier releases and the agent model implemented in the closely related GitHub Copilot. It includes a new migration agent as part of its library of tools, using grounded AI to guide you through a simultaneous process of migrating and upgrading applications. The intent is to speed up the process by using your current environment and the capabilities of the Azure platform to define and implement the IT strategies to deliver a modern cloud infrastructure.

With the Azure Copilot handling infrastructure, the modernization tools in GitHub Copilot’s agents can help work through the necessary steps to update the code, adding support for Azure capabilities and modern cloud-native architectures.

Key to both approaches is a process of fine-tuning and grounding that uses Azure’s well-defined APIs and the constraints of domain-specific, software-defined infrastructure through tools like Bicep, Terraform, and the older but still critical Azure Resource Manager. Defining and implementing an IT strategy is one of the things an AI agent should be good at. Working alongside infrastructure and application architects, the agent defines the current state of an application, the target, where the modernized version will run, and what tools it will need. It then uses spec-driven development methodology to treat that gap as a directed graph that will first define an infrastructure and then update the code.

Having a known state at both ends of the process keeps risk to a minimum, though of course you need to always keep humans in the loop. It’s not a process that can be fully automated; instead, it’s an approach that speeds up tasks and reduces the necessary effort. In one early test, a customer was able to reduce this by 70%.

Working with cooperating agents

Microsoft is using migration as an example of how agents can cooperate and help different disciplines communicate effectively. Reports generated by GitHub Copilot can be used by Azure Copilot to identify possible issues and bridge the gaps between software modernization and migration plans. The resulting insights help teams prioritize necessary work and improve the specifications and strategy that guide the work.

Using the migration agent from Azure Copilot is straightforward, as it builds on existing best practices and processes. However, don’t expect it to support all the possible migration scenarios from day one. The current preview release is designed to help move specific infrastructures to Azure by analyzing data from the existing Azure Migrate tools.

Two key scenarios are supported in this first version: moving VMware infrastructures, and working with existing environments that use Hyper-V and physical servers. In both cases, you’ll need to run the existing Azure Migrate tools to collect the data the agent will use to plan a migration. This will require installing Azure Migrate collectors or the free RVTools utility. Microsoft provides an Azure Migrate appliance that can be deployed inside either VMware or Hyper-V environments (or on bare-metal servers) to handle discovery, which helps gather and process this data.

The migration agent will run discovery for you or work with your own discovery data. Once you have data, you can use prompts to assess your infrastructure, check for servers that need upgrades, and build a plan for a lift-and-shift exercise. You can even get cost analysis and ROI reports. Other options help add modernization options, for example, moving data to Azure servers. Then you can start building the base infrastructure for a migration and start deploying Azure resources.

Agents connect ops and dev teams

A conversational approach to working with the agent through Azure Copilot can help financial and business team members understand the effectiveness of a migration, as they can get access to costs and timescales through familiar tools. System administrators will be able to quickly get the information they need, while development teams will be able to understand what code changes might be needed to support a new infrastructure. Having Azure Copilot as a hub for these conversations can help reduce risks and keep projects on track. The information needed for good decisions is now easily accessible.

At the same time, you can have the GitHub modernization agent from the GitHub CLI update the code you’re running on those servers, using the tool to guide updates to .NET and Java. The agent will analyze code and produce a modernization plan to guide development teams, or it can automate the process of updating and testing your code. The migration agent is designed to look for issues that might arise when migrating to the cloud, so it’s an important component of a suite of migration tools.

With these new AI-powered tools, you’re able to speed up the process of moving complete applications to the cloud, with an ROI assessment, a migration plan, and the necessary updates to what may be outdated code. With new infrastructure and code, you’re able to start dealing with long-term technical debt and adding new features that can improve business performance and offer new services both inside and outside your organization.

Change Intelligence and Deployment Connectors for Liquibase Secure

Tue, 31 Mar 2026 12:52:25 +0200

Liquibase Secure introduces Change Intelligence and Deployment Connectors for ServiceNow, GitHub, Harness, and Terraform to improve database change governance and visibility. The post Change Intelligence and Deployment Connectors for Liquibase Secure appeared first on Security Boulevard. This article has been…

The post Change Intelligence and Deployment Connectors for Liquibase Secure appeared first on IT Security News.

Azure’s new AI modernization tools

Tue, 31 Mar 2026 11:17:42 +0200

Solving technical debt

Building new applications is easy, but it’s hard to keep them up to date. The budget for maintenance never quite covers the necessary work, so applications and servers keep running until it’s impossible to keep them going. Historically that’s meant aged mainframes running for more than 50 years, or a nuclear power plant being controlled from an emulation running in another emulation on top of a stack of virtual machines.

Automating cloud migrations

Microsoft has offered several generations of tools to migrate applications to the cloud, mostly focused on finding the right size Azure virtual machines and the right virtual network appliances and topography, as well as importing data into cloud storage. Microsoft has provided useful ways to move applications to the cloud, but the company hasn’t helped you modernize code or infrastructure. Enterprises are just replicating technical debt in Azure instead of on their own servers.

How then can Microsoft break down the barriers between teams and use migration as an opportunity to help modernize software and reduce technical debt?

Azure Copilot for migration and modernization

Key to both approaches is a process of fine-tuning and grounding that uses Azure’s well-defined APIs and the constraints of domain-specific, software-defined infrastructure through tools like Bicep, Terraform, and the older but still critical Azure Resource Manager. Defining and implementing an IT strategy is one of the things an AI agent should be good at. Working alongside infrastructure and application architects, it defines the current state of an application, the target, where the modernized version will run, and what tools it will need. It then uses spec-driven development methodology to treat that gap as a directed graph that will first define an infrastructure and then update the code.

Having a known state at both ends of the process keeps risk to a minimum, though of course you need to always keep humans in the loop. It’s not a process that can be fully automated; instead, it’s an approach that speeds tasks up and reduces the necessary effort. In one early test, a customer was able to reduce this by 70%.

Working with cooperating agents

Microsoft is using this as an example of how agents can cooperate and help different disciplines communicate effectively. Reports generated by GitHub Copilot can be used by Azure Copilot to identify possible issues and bridge the gaps between software modernization and migration plans. The resulting insights help teams prioritize necessary work and improve the specifications and strategy that guide the work.

Using the migration agent from Azure Copilot is straightforward, as it builds on existing best practices and processes. However, don’t expect it to support all the possible migration scenarios from day 1. The current preview release is designed to help move specific infrastructures to Azure by analyzing data from the existing Azure Migrate tools.

Agents connect ops and dev teams

Seit 8 Jahren Infrastructure-as-Code – ein Erfahrungsbericht (clt26)

Sun, 29 Mar 2026 16:33:32 +0200

Seit über 10 Jahren betreuen wir den Betrieb der Smart-Home-Cloud-Plattform myBuildings/myBUSCH-JAEGER. Die Plattform ermöglicht es den Kunden, diverse Smart-Home-Produkte komfortabel und remote zu steuern. Durch das stetige Wachstum der Plattform ist es notwendig, die eingesetzten Cloud-Ressourcen effizient orchestrieren zu können. Hierbei unterstützt der Einsatz von Infrastructure-as-Code (IaC) Werkzeugen und Automatisierung, die eigene Infrastruktur – insbesondere im Team – unter Kontrolle zu halten. In diesem Vortrag stellen wir unseren seit 2017 genutzten IaC-Ansatz basierend auf Terraform/OpenTofu und GitOps Techniken vor und zeigen auf, wie sich dieser Ansatz im Laufe der Zeit entwickelt hat. Insbesondere wird auf die Probleme eingegangen, die sich im Laufe des Betriebs ergeben haben und wie sie überwunden werden können. Hierzu gehören beispielsweise: • Verwaltung von State-Dateien, sowie State- und Stack-Orchestrierung • Zuverlässige, gesicherte und skalierbare Automatisierung von Deployment-Abläufen • Review- und Governance-Prozesse • Modularisierung von Infrastrukturkomponenten Licensed to the public under http://creativecommons.org/licenses/by/4.0 about this event: https://chemnitzer.linux-tage.de/2026/de/programm/beitrag/265

Meshery 1.0 debuts, offering new layer of control for cloud-native infrastructure

Wed, 25 Mar 2026 19:36:11 +0100

Managing Kubernetes infrastructure across multi-cloud environments has long produced YAML sprawl, configuration drift, and tribal knowledge that lives in individuals rather than systems. AI tools that generate infrastructure configurations faster than teams can review them have made that issue harder to contain. It’s a problem that the open-source Meshery technology was built to solve. Meshery v1.0 is now out, providing a visual management and governance platform for cloud native infrastructure.

Meshery began six years ago as an effort led by Layer5, with a service mesh focus, but it has since expanded well beyond it. Today the platform supports more than 300 integrations across AWS, Azure, GCP and open-source projects. The project ranks as the sixth highest-velocity project in the Cloud Native Computing Foundation (CNCF), with a 350% increase in code commits over the past year, 3,000 contributors, and 10,000 GitHub stars.

“It’s a multi-layer visual designer and visual operator,” Lee Calcote, Layer5 founder and Meshery creator, told Network World.

What Meshery does

Despite its name, Meshery is not a service mesh tool. Calcote said the project has spent years trying to shake “that explicit and restrictive connotation.” Service mesh was one early use case handled through adapters, but the platform was always built to manage anything that can be described in Kubernetes terms. Calcote said the intent from the start is to be something of a cloud management platform.

In practical terms, Meshery gives engineering teams a shared workspace to design, visualize, and operate Kubernetes-based infrastructure. Rather than working directly against YAML files or Helm charts, teams work with visual representations of their infrastructure inside a component called Kanvas. The visual layout is semantically meaningful: components, their relationships and their configurations are all represented as a connected diagram rather than disconnected text files.

The core unit is a design, a YAML or JSON document representing declarative infrastructure intent. It functions similarly to a shared document in a collaborative editing tool. Teams can leave comments and record architectural decisions inside a design, giving new team members context on why particular configuration choices were made. Kanvas shipped in two forms with v1.0. Kanvas Designer, now generally available, is a drag-and-drop interface for building and modifying infrastructure designs. Kanvas Operator, currently in beta, provides a real-time live view of running clusters for SRE and platform teams.

Meshery is Kubernetes-centric but does not require Kubernetes to run. It does more when Kubernetes is present, but it can also be used to stand up greenfield infrastructure or to discover and document what is already running in a brownfield environment.

Validation runs automatically through an embedded Open Policy Agent (OPA) policy engine on every design change. The engine applies a deterministic rule set across thousands of components and cloud services, identifying relationships between components and flagging configuration issues before changes are applied.

Where Meshery fits against IaC and infrastructure management tools

There are a lot of different tools in the infrastructure space, including Infrastructure-as-Code (IaC). Tools like Terraform, Pulumi, Spacelift and Crossplane are common points of comparison for Meshery.

Meshery does not replace IaC tooling. Calcote explained that Meshery uses the Helm package manager internally for deployments and can consume Crossplane composite resource definitions, sitting above those tools rather than alongside them.

Where IaC tools manage infrastructure state through code and pipelines, Meshery adds the visual governance layer on top: showing teams what their infrastructure looks like, how components relate, where configurations conflict, and what a proposed change will actually do before it is applied.

Calcote described it as an abstraction on top of Kubernetes custom resource definitions (CRDs), similar in concept to how Crossplane manages them but operating at a higher level across the full stack.

Networking capabilities

Managing and understanding cloud-native network configuration is part of Meshery.

Meshery includes a built-in load generator called Nighthawk, a C++ tool developed in collaboration with the Envoy project. Nighthawk generates HTTP and gRPC traffic against target infrastructure, measures latency percentiles and throughput and renders results as visual graphs inside Meshery.

Calcote cited Intel as a user that applied the tool to iteratively deploy infrastructure configurations, run performance tests, adjust settings and retest in successive cycles.

A GitHub Action integrates Meshery into GitOps pipelines. When a configuration change is committed, the action can deploy the infrastructure change, run a defined performance test against specified endpoints and return results plus a visual diagram snapshot directly in the pull request. Teams can set throughput and latency thresholds to gate deployments automatically based on the results.

Meshery is also being used to help organizations migrate from the nginx ingress controller, which is no longer supported in Kubernetes. That technology had been widely deployed to help manage network traffic. Calcote noted that getting senior SREs and junior DevOps engineers aligned on what a configuration change actually involves is as much a coordination problem as a technical one.

Teams are also turning to LLMs for quick answers on how to handle the migration, and in environments where AI tooling is built into pipelines, configuration recommendations are arriving faster than teams can meaningfully review them. The visual rendering that Meshery provides addresses that directly.

What changed in v1.0

Calcote described v1.0 as a maturity milestone rather than a feature release. “It’s a polishing of the work that we’ve been doing for years,” he said.

Two structural changes accompany the v1.0 release. Meshery restructured its GitHub footprint into two organizations: github.com/meshery for the core platform, including Meshery Operator and MeshSync, and github.com/meshery-extensions for the 300-plus integrations and adapters. The separation allows the extension community to iterate independently without affecting core platform stability.

Layer5 also launched the Certified Meshery Contributor program alongside v1.0, which the project describes as the first contributor certification in the CNCF. The free program includes five exams covering Meshery’s server, CLI, UI, models and extensibility domains. It is aimed at practitioners working in Go, React and OpenAPI.

What comes next

The primary post-1.0 roadmap item is a bring-your-own LLM integration. Currently the OPA policy engine operates deterministically. The planned integration will let users direct infrastructure queries to an LLM of their choice.

“Since Meshery is looking at your actively running infrastructure, you may want to ask any number of questions about optimization, about configuration changes that you might like to do,” Calcote said.

A parallel workstream will give users the option to choose between the existing deterministic ruleset and LLM-based assessment for the same governance tasks the policy engine handles today, including evaluating cost, security and resiliency tradeoffs.

Looking further ahead, Calcote described a vision for Meshery becoming a standard format for sharing and presenting infrastructure designs. “It becomes the canonical way of expressing these concepts, with the added benefit that whatever architecture you’re trying to promote, that it’s also deployable,” Calcote said.

The multi-billion dollar mistake: Why cloud misconfigurations are your biggest security threat

Thu, 19 Mar 2026 11:05:59 +0100

Last year, most businesses faced a cloud security incident. Here’s what stands out — it wasn’t sophisticated cybercriminals behind these events. Instead, basic errors opened the door. According to the Cloud Security Alliance’s 2024 report on risks in cloud computing, misconfigured settings caused nearly every single breach. Just one wrong switch — that’s all it took.

Imagine a closet left swinging open, keys hanging on the knob. Not every login needs extra checks — some skip them entirely. Barriers at entrances often allow free passage, like welcome mats rolled out. Code sometimes holds passwords in plain sight, exposed by oversight. None of this happens once in a blue moon. This is how fortunes slip away, reputations crumble, records spill into the wild and teams are stuck playing catch-up for weeks.

Far from fancy digital theft, this mess lives in corners left unvisited. Each gap feeds the problem — no oversight, just open doors.

The scale of the crisis

What stands out first? The scale feels unreal. According to IBM’s 2025 report on data breach expenses, breaches globally now cost an average of 4.44 million dollars. Yet within the United States, each event costs 10.22 million. Still, beyond these shocking totals lies something deeper, harder to capture fully through stats alone.

Take the 2024 Snowflake incident — dozens of companies caught in it, half a billion lives touched. AT&T saw 109 million client files slip away. Then there’s Ticketmaster, where nearly 560 million entries vanished into hacker hands. Even Santander exposed details of 190 million individuals.

Yet how did they break through? Logging in was enough. Real credentials gave them access to profiles missing extra login safeguards.

What stands out is how old issues still cause harm. A faulty web app firewall opened the door for Capital One’s 2019 incident. Over 100 million customers were affected by that slip, followed by an $80 million penalty, then another $190 million paid later. For close to two years, Football Australia had live API keys visible in their site’s code — no protection at all. As a result, 127 data stores became reachable. Toyota kept customer files in a public cloud setup for nine years, maybe ten. Around 260,000 accounts slipped out during that time

A further deep dive paints the real picture:

Most cloud setup errors — 8 out of 10 — happen because people slip up, not because code fails.
One out of three cloud setups sits empty, ignored by any oversight. A third of online storage spaces get zero attention from monitors.
Almost one out of every two hundred storage units on Amazon’s cloud sits open, per a 2024 report by monitoring firm Datadog. Their findings spotlight how common loose settings remain across web-based file systems.
50% of the time, fixing leaks runs about ninety-four days long. What comes after discovery drags on for nearly three months.

Strange how often this happens. It shouldn’t take long for stolen logins to cause harm — yet here, hackers had over three months just waiting. The Snowflake incident relied on old data pulled years ago, sitting untouched since 2020. No new passwords were issued, no extra login steps added and zero checks on odd activity. A pattern returns, messy and ignored.

Why this keeps happening

Strange how something so clear stays unsolved — misconfigurations stick around despite being easy to spot. From chats with several CISOs and cloud experts, similar reasons pop up each time. One thing leads to another, then patterns emerge.

Imagine trying to keep track of it all — modern cloud environments are packed with endless pieces working at once. Juggle this: resources spread through countless accounts, scattered across regions and platforms. Think about AWS — with its 200-plus tools, every one loaded with settings you can tweak. Then there’s Azure, where the count climbs past six hundred offerings. Finding a single person who could handle all of that manually — while staying accurate — is impossible. Numbers simply refuse to cooperate in that situation.
Folks move fast these days. While developers ship updates constantly, old security steps — meant for monthly rollouts — get in the way. What once worked now drags things behind. Folks on teams walk past these issues, saying they’ll return down the line to sort it out. Truth? That future moment slips away every time.
Out of sight, out of mind — that’s how it often goes. Hidden tech pops up in every department. Workers set up online tools without asking anyone first, slipping past checks. When coders build trial setups, they sometimes leave them running. Those unnoticed spots? Perfect nests for errors. Eventually, something gives — rarely does a friendly face catch it first.
Owning things brings trouble, too. When cloud companies manage hardware, users still need to secure settings and information themselves. Sounds straightforward until you try it. Think back to the Snowflake incident. People assumed Snowflake would catch dangers before they spread. What happened at Snowflake? Customers were supposed to enable MFA. Yet somehow, every team assumed someone else had handled it. With no one verifying setup completion, hackers entered without resistance.

Right then, complexity hits hard when speed piles on top. Blind spots grow where clarity should be. Unclear boundaries mix in with too few skilled hands around. Missteps return — no surprise there.

The path forward

Good news? This situation isn’t hopeless. While zero-day flaws leave you idle, waiting on updates, misconfigurations aren’t like that. They sit in your hands. The power to resolve lies with you.

Quick wins:

Flip the switch on multi-factor authentication wherever you can. Honestly. Following the Snowflake incident, investigators looked back — nearly all break-ins could’ve been stopped cold by MFA. Treat it like a rule with no exceptions. Go through each cloud service within the month ahead. Wherever that extra login step is gone, put it in place.
Start poking around each S3 bucket, then slide into Azure Blobs, and later hop over to Google Cloud Storage spots. Check that none of them are sitting out in the open without meaning to be. Flip the switch on public access blockers right at the account root — keeps things locked down. Turn on notifications so a warning lands in your lap whenever something sneaks into public view, no matter how it got there.
Start with logs. Without clear records, spotting problems becomes guesswork. When something goes wrong, answers come from entries made earlier. Turn on AWS CloudTrail across every login. Include Azure Activity Log too — no gaps allowed. GCP Cloud Audit Logs need activation just the same. Each system must record actions taken. Skip none. Miss nothing.
Might want to glance at your network settings while you’re at it. Rules letting everything in through 0.0.0.0/0? Those are best removed. Admin entry should come only from IPs you know and expect.

Strategic move:

Cloud Security Posture Management tools help spot problems quickly. Always watching, they catch mistakes in how systems are set up. One study from 2025 found firms using these tools dropped exposure time from weeks to less than two days. Mistakes linger much shorter now. Fewer openings exist for those trying to break in.
Start treating infrastructure as code like real code — with real risks. Before anything hits the cloud, check every Terraform file or CloudFormation setup you’ve got. Errors found early skip the chaos of live systems later. Build security checks right into how things get built, step by step. That way, flawed setups never slip through to where they run.
When done right, trusting nothing by default works in your favor. A misconfigured setting might slip through, yet damage stays contained. Rely on minimal permissions instead of broad ones, slice systems apart like layers, and each check happens fresh, even if the request arrives familiar. Confirm every entry point without exception.

Last thing — put energy into your team. Everyone handling cloud systems should have actual hands-on security learning. Push them toward official certifications. Help security folks understand development work, while developers learn what security needs — balance builds better talk.

You’ve got a lot of control here. Take it.

The culture question

Most problems won’t vanish just because tools are added. Getting cloud safety right takes effort from every corner — security people can’t carry it solo. When coders pick shortcuts, risks grow — that truth needs to land early. Training for system managers must match the cloud world, not recycled advice from older systems. Support from top leaders shows up best when budgets shift, and decisions include risk checks.

Not everything has to move fast. Slowing down can mean doing it right, especially when safety is involved. This isn’t failure — this is how solid systems grow. Clever groups figure out how to weave protection into tools, so progress keeps flowing.

The stakes are real

Out here, moving to the cloud doesn’t simply shift tech — it reshapes how fast companies grow and what they’re able to try. Getting security right opens doors most never reach. Slip up, though, and risk swallows everything. Speed without safety turns into danger.

Few thought weak login steps could unravel so fast. Snowflake’s lapse exposed over 165 groups, touching half a billion lives. Bills pile high — likely hundreds of millions — fed by ransoms, penalties, court fights and shattered trust. Weak shields opened doors; missing extra checks on logins made it worse.

This moment is real, not a distant threat. What unfolds today hits hard when cloud safety takes a back seat. Cyber intruders shift focus steadily toward online infrastructure. Rules tighten across regions; an example stands clear: CISA’s recent order pushes government bodies to secure digital environments firmly.

A realistic optimism

Most cloud security problems come from mistakes in setup. The good part is that these are simpler to solve than other issues. Instead of hoping it works, run checks using CSPM software. Policies stick better when written directly into the system code. People pay attention if they understand what’s at stake. When safety becomes normal talk, fewer errors slip through. Risk drops once habits shift toward caution.

The tools are out there. Clear methods stand proven. Case after case shows what actually moves the needle. Right now, the hurdle sits inside — getting everyone on board together. Facing facts comes first. Funding follows. Then understanding settles: how you set up systems shapes everything in cloud safety.

Here’s the truth: Misconfigured settings spark every cloud breach. Get set up right, and security follows. Errors costing millions? Entirely avoidable.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Switching from Windows to Linux. Which distro for a cloud/backend dev stack?

Sun, 15 Mar 2026 07:34:46 +0100

🐧 Early Sunday morning poll. Let’s see who’s already awake…

My desktop PC running Windows is in bad shape and I need to reformat it. I’ll spare you the list of problems trust me, it’s better that way!

I’ve been thinking about switching to Linux, and from what I’ve read, my whole stack is fully supported:

∙ C# ∙ JetBrains suite ∙ VS Code ∙ Docker ∙ Terraform ∙ Cloud projects (Azure/AWS) ∙ Virtual machines

From what I read before posting this poll, everything should be covered. My big dilemma is the Jabra software. I’ve seen mixed opinions on that one.

I know it’s not great to say (and probably painful for Linux users to read), but I want things to just work without complications. Laziness has officially taken over my life at this point.

My shortlist is Ubuntu or Fedora. LinkedIn crowd said Ubuntu, but let’s see if Reddit agrees.

Which distro do you recommend? I already have my own idea, but I’d love to hear from people with more hands-on experience.

submitted by /u/devandreacarratta
[link] [comments]

FluidCloud’s Large Infrastructure Model targets the multicloud networking gap

Thu, 12 Mar 2026 20:04:39 +0100

Migrating entire workloads from one cloud to another is not a trivial matter.

Terraform, the de facto standard for Infrastructure-as-Code (IaC) technology, was designed to make infrastructure portable across cloud providers. The reality is more nuanced and often painful. Each cloud provider uses its own resource dialects, migrations stretch into months of manual rewrites, and AI tools that claim to generate production-ready IaC still fail on networking, IAM, and service dependencies.

FluidCloud, a Pleasanton, Calif.-based startup that emerged from stealth in July 2025 with $8.1 million in seed funding, is launching what it calls a Large Infrastructure Model (LIM). LIM is a purpose-built AI engine for generating, translating, and validating Terraform across multicloud environments. The company argues that scanning a cloud environment and generating IaC is not the same as actually being able to move that infrastructure to another provider.

“Most of the companies that are out there in the market, when they scan cloud environments and generate an IaC, they call it resilience,” Sharad Kumar, co-founder and CEO of FluidCloud, told Network World. “The real resilience is if you have the power to move that somewhere else. You can move that into another region. You can move that into another cloud provider. Then I can call it true resilience.”

LIM is not a fine-tuned LLM

The idea of using a Large Language Model (LLM) and then fine-tuning it for a specific use case is not a new idea; that’s how all kinds of industries are now getting advanced AI with applicable domain knowledge to work.

The architecture behind LIM differs from how most AI infrastructure tools are built. Harshit Omar, co-founder and CTO, said the system is not built on a base model like Llama or a standard fine-tuned LLM.

“It’s a mixture of multiple models,” Omar told Network World. “The conversion and the core capability are not an LLM; it’s our own conditional model.”

A standard LLM sits at the front end to parse user intent. The Terraform generation and cloud-to-cloud conversion work runs on custom foundation models trained on infrastructure patterns. The training data is entirely synthetic. FluidCloud generated its own Terraform configurations and used its own conversion technology to build the training corpus.

“We have generated a lot of Terraform, and we use our own technology to generate more and more Terraform,” Omar said. “That’s what is powering the LIM.”

FluidCloud benchmarked LIM using BLEU score, a standard metric for evaluating generated output accuracy against reference results. Omar said the model currently scores 0.58. A score of 0.60 represents human-level performance on Terraform generation tasks.

What LIM adds to the platform

Before LIM, FluidCloud’s platform required a direct cloud scan as input and covered roughly 25 to 30 resource types. Coverage has since expanded to 150-plus resources across cloud providers.

The input model has also changed. Previously, the platform required a controlled scan to produce output. LIM accepts existing GitHub repositories containing Terraform code. It handles multiple Terraform syntax styles, including module-based, workspace-based, and variable configurations. It also supports custom mapping overrides.

LIM adds a compatibility scoring layer that runs before a migration begins. Given an existing infrastructure, it estimates what percentage of workloads will fail on a target platform. LIM also introduces outage prediction. The engine analyzes cloud provider release cycles, public network latency data between regions, and scheduled OS upgrade windows. The company is planning a public community page to publish upcoming outage predictions so enterprises can subscribe for advance notice.

The platform includes 1,800 compliance policies out of the box. Those policies cover major hyperscalers, as well as neocloud providers such as Vultr, OVH, and Hetzner.

Network stack translation and optimization

Cross-cloud networking is one of the harder translation problems in multi-cloud migrations. VPC configurations, private tunnels, security groups, and firewall rules are all expressed differently across providers, and moving them manually is where migrations typically stall.

LIM replicates the full network stack when translating infrastructure between clouds. “We replicate the whole network stack as well in the other cloud, so you really don’t lose anything,” Omar said. “All the cloud providers provide the same functionality. It’s just different ways of computing it.”

LIM is trained on cross-provider DevOps and infrastructure patterns, so it handles the translation without requiring the engineering team to learn each cloud’s networking dialect from scratch.

Beyond migration, LIM also functions as an optimization layer. Omar explained that every infrastructure change a DevOps engineer makes falls into one of three categories: cost, security, or performance. LIM models those variables and weights them based on the intent it detects.

“If you give different weightage to each of them, it produces a new infrastructure,” Omar said. “LIM understands DevOps intent. What it is trying to look for, if it is reducing cost, if it is improving the performance, and then balances out the configuration.”

On outage prediction, Omar said upstream fiber providers are a minimal factor in cloud outages. The bigger driver is release cycle pressure. “The majority of the times it’s either some bad release or something on the release cycle,” he said. “With pressure on each of those cloud providers to provide newer and newer services, and also with AI and vibe coding, the quality controls, the outages are becoming more and more.”

Omar said the next development priorities include an agent builder for creating custom infrastructure workflows via MCP, and portable SDKs that abstract cloud provider APIs. With those SDKs, switching a cloud deployment would require changing an environment variable rather than rewriting API calls.

“There are a lot of agentic workflows which we are coming up with, which are almost going to give superpowers to the users,” Kumar said.

CVE-2026-27900 | linode terraform-provider-linode up to 3.8.x log file (GHSA-5rc7-2jj6-mp64)

Thu, 12 Mar 2026 02:06:18 +0100

A vulnerability labeled as problematic has been found in linode terraform-provider-linode up to 3.8.x. Affected by this vulnerability is an unknown functionality. The manipulation results in sensitive information in log files. This vulnerability is reported as CVE-2026-27900. The attack can be launched remotely. No exploit exists. The affected component should be upgraded.

Open source isn’t altruism. It’s how you avoid getting surprised

Tue, 03 Mar 2026 11:07:26 +0100

For a long time, I thought I understood what open source was about.

Like many engineers, my early understanding was shaped by its origin story: the hacker ethic, academic collaboration, the idea that software should be shared because it was the right thing to do. I read the books. I absorbed the culture. Open source felt like an ideological movement, and participation felt almost moral in nature.

That story isn’t wrong. But it’s incomplete.

Over time, and across different roles, I’ve learned that open source endures not because of altruism alone, but because it’s one of the few reliable ways to reduce surprise in complex technology ecosystems. When it works well, it doesn’t just distribute code. It distributes power, context and options.

I didn’t fully appreciate that until the rules changed.

When the ground shifted

When HashiCorp announced a license change for Terraform, my first reaction was disbelief.

At the time, Terraform underpinned a significant portion of modern cloud infrastructure. It wasn’t just another tool. It was foundational. Many organizations — vendors and users alike — had quietly assumed that its openness was a constant. The possibility of a sudden shift had been discussed in abstract terms but not seriously anticipated.

When it happened, I expected chaos. Fragmentation. Months of argument before anything meaningful emerged.

Instead, the community responded with something closer to calm urgency. A fork appeared. Governance took shape. Contributors showed up. OpenTofu came into existence far faster and more coherently than most people expected. [Disclaimer: Marcin is the co-founder of the OpenTofu project.]

What struck me wasn’t the fork itself. Forks are easy. What mattered was how prepared the ecosystem turned out to be. The response revealed a latent consensus: many people had already internalized the risk of depending on a project whose direction and decision-making lived behind closed doors.

The episode forced me to confront an uncomfortable truth. The license was technically open, but much of the project’s evolution had not been. It was what we’d today call a vendor-led open source project. Contributions were gated by one organization, and pull request decisions happened privately. When the moment came, there were very few structural barriers to a unilateral change.

In hindsight, the surprise wasn’t that the license changed. It was that we were surprised at all.

Good intentions, hard incentives

It’s tempting to frame these moments as morality plays. Vendor greed versus community values. Control versus freedom.

Reality is messier.

Companies are run by people with principles, but also by boards with incentives. Decisions that feel abrupt or hostile from the outside often emerge from long-running internal tensions: monetization pressure, market expectations, growth targets that never quite feel sufficient.

Watching this play out reshaped how I think about trust. Not trust as a feeling, but as a system property. As ecosystems grow more interconnected, trust can’t rely solely on intent. It has to be supported by structure: transparency, shared ownership and real participation. Without those, even well-meaning decisions can destabilize entire communities.

The Terraform episode didn’t convince me that vendors are bad actors. It convinced me that relying on goodwill alone is a fragile strategy.

Learning by being wrong in public

Another shift in my thinking came from building things in the open and then discovering how often my confidence was misplaced.

More than once, I was convinced a system was finished. Elegant. Complete. Ready.

Then someone from the outside would ask a question or propose a use case that reframed the problem entirely. Not an edge case, but a fundamentally different way of thinking about what the system should enable.

Those moments were uncomfortable. They also accelerated learning in a way no internal roadmap ever could.

When development happens in public, assumptions don’t get to hide. Feedback arrives early, often bluntly, and sometimes from directions you didn’t know existed. Users imagine possibilities builders haven’t yet considered. They stress the design in ways internal teams rarely can.

Over time, that experience changed how I evaluate confidence. A closed roadmap can feel reassuring. An open one feels exposed. But exposure is often where the most valuable corrections occur.

Ecosystems aren’t platforms

One lesson that emerged repeatedly is the difference between platforms and ecosystems.

Platforms centralize control. Ecosystems distribute it.

Healthy ecosystems show certain signals over time: multiple serious contributors, transparent governance, public decision-making and standards that outlast any single tool or vendor. No single entity gets to dictate direction unilaterally. Checks and balances exist not because participants distrust one another, but because they understand how quickly incentives can diverge.

Letting go of control is hard. It slows things down. Consensus takes time. Decisions feel less crisp.

But I’ve seen the alternative up close. When control is concentrated, resilience depends on the continued alignment of one organization’s interests with everyone else’s. That’s a narrow margin for something so many people depend on.

What open source didn’t guarantee

In hindsight, the Terraform moment also clarified something else: openness is not binary.

A permissive license alone doesn’t create a durable ecosystem. Process matters. Participation matters. Design matters.

Only later did I encounter language that articulated what I had been circling. It was the idea of open design: not just open code, but open planning, open decision-making and real community ownership of a project’s direction. Looking back, it was obvious what had been missing. (One framework for this that’s worth reading up on is the Four Opens.)

Naming the concept didn’t change the lesson. It just gave it shape.

The lens I use now

I no longer think of open source as charity, or even primarily as ideology. I think of it as long-term risk management.

Open ecosystems don’t eliminate uncertainty, but they make it legible. They surface tensions earlier. They give participants options when incentives shift. They reduce the blast radius of surprises that are inevitable in fast-moving markets.

That doesn’t mean open source is always the right answer. It comes with tradeoffs: slower consensus, public disagreement and the messy reality of human communities. It requires patience and a willingness to live with ambiguity.

This is simply the lens I use now, a lens shaped by watching systems bend, communities respond and assumptions fail in real time. I’m certain it will keep evolving. Experience has taught me that certainty rarely survives contact with reality.

What I’m confident about is this: In an industry defined by rapid change, fewer surprises are worth a lot. And openness, when practiced fully, remains one of the best ways I know to earn that resilience.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Stadt-Miete vs Land-Besitz. Was uns Wohnen über digitale Souveränität lehrt (dgwk2026)

Mon, 02 Mar 2026 07:33:41 +0100

Die Entscheidung zwischen Eigenheim auf dem Land und Mietwohnung in der Stadt spiegelt perfekt das Dilemma zwischen selbstgehosteter IT Infrastruktur und Cloud-Hyperscalern wider. In beiden Fällen geht es um fundamentale Fragen von Kontrolle, Freiheit und Abhängigkeit, aber auch um die Lasten der Verantwortung und die Grenzen der Autonomie. Eine Analyse wie Vendor Lock-in und Plattform-Monopole unsere digitale und physische Souveränität bedrohen und ein kritischer Blick auf Eigentum, Macht, Freiheit und Verantwortung im 21. Jahrhundert durch die Linse eines Menschen mit Hackerethik im Herzen. In den letzten Jahren hat sich sowohl auf dem Wohnungsmarkt als auch in der IT-Infrastruktur ein besorgniserregender Trend verstärkt: die schleichende Enteignung von Kontrolle und Souveränität zugunsten großer Konzerne und Plattformen. Während in Zürich, Berlin und anderen Europäischen Großstädten Wohnraum zunehmend in den Händen internationaler Investmentfonds landet und Mieterinnen und Mieter ihre Gestaltungsfreiheit verlieren, wandern parallel dazu kritische IT-Infrastrukturen in die Clouds der US Hyperscaler. In beiden Fällen lockt zunächst das Versprechen von Convenience und Sorglosigkeit, doch der Preis erweist sich als hoch: Abhängigkeit, Kontrollverlust und die schleichende Erosion fundamentaler Freiheitsrechte. Doch die Gegenbewegung, der Ruf nach Eigenverantwortung und Selbsthosting, birgt eigene Herausforderungen, die oft unterschätzt oder romantisiert werden. Das Eigenheim mag Freiheit versprechen, aber es bindet auch durch Verpflichtungen: Die Heizung, die mitten im Winter ausfällt und deren Reparatur nicht mehr in der Verantwortung des Vermieters liegt. Das undichte Dach, das dringend saniert werden muss. Die Grundsteuer, die Gebäudeversicherung, die ständige Instandhaltung, die Zeit und Geld verschlingt. Die eigene IT-Infrastruktur mag Kontrolle versprechen, aber sie fordert auch ihren Tribut: Der Server, der um drei Uhr nachts ausfällt und sofortige Intervention erfordert. Die Sicherheitslücke, die gepatcht werden muss, bevor sie ausgenutzt wird. Die Compliance-Anforderungen, die professionelles Know-how erfordern. Die Backup-Systeme, die gewartet werden wollen. Die Skalierungsprobleme, wenn das Geschäft plötzlich wächst. Dieser Talk zieht bewusst provokante Parallelen zwischen zwei scheinbar getrennten Lebensbereichen und zeigt auf, wie die gleichen ökonomischen und machtpolitischen Mechanismen in beiden Sphären wirken, aber auch, wie die gleichen Dilemmata zwischen Autonomie und Verantwortung, zwischen Freiheit und Last auftreten. Das Eigenheim mit Garten entspricht dabei der selbstgehosteten Infrastruktur oder dem klassischen On-Premises-Rechenzentrum, während die zentral gelegene Mietwohnung das Cloud-Services-Modell repräsentiert. Die großen Vermietungskonzerne und Immobilienfonds finden ihr digitales Pendant in den Hyperscalern, und die Mechanismen des Vendor Lock-in ähneln verblüffend den unkündbaren Mietverträgen und strukturellen Abhängigkeiten, die moderne Wohnungsmärkte prägen. Besonders interessant wird diese Analogie, wenn man die grundrechtliche Dimension betrachtet. Das Grundgesetz garantiert in Artikel 13 die Unverletzlichkeit der Wohnung als fundamentales Freiheitsrecht. Dieser Schutz der Privatsphäre im physischen Raum findet seine digitale Entsprechung im Recht auf informationelle Selbstbestimmung und Datenschutz. Doch während der Staat beim Betreten einer Wohnung strenge rechtliche Hürden überwinden muss, öffnen wir beim Cloud-Computing bereitwillig die Türen zu unseren digitalen Wohnräumen für private Konzerne. Das Hausrecht, das uns im physischen Raum zusteht, haben wir im digitalen Raum faktisch an die Hyperscaler abgetreten. Gleichzeitig bedeutet das Hausrecht aber auch: Wer das Haus besitzt, muss es auch instand halten. Die Freiheit, niemanden hereinlassen zu müssen, geht einher mit der Pflicht, selbst für Ordnung und Sicherheit zu sorgen. Die zentrale These dieses Vortrags lautet nicht einfach, dass Eigenverantwortung immer besser sei als Abhängigkeit. Vielmehr geht es darum, die wahren Kosten und Konsequenzen beider Modelle sichtbar zu machen. Sowohl bei Wohnraum als auch bei IT-Infrastruktur verspricht kurzfristige Bequemlichkeit langfristige Abhängigkeit und Entmachtung, doch totale Eigenverantwortung kann zur erdrückenden Last werden, die nur mit erheblichen Ressourcen zu stemmen ist. Die Versprechen von Managed Services und Full-Service-Wohnen verschleiern systematisch die Aufgabe von Kontrolle und Selbstbestimmung, aber sie nehmen auch reale Lasten ab, die nicht jeder tragen kann oder will. Die Konzentration von Wohnraum und Computing-Ressourcen in den Händen weniger Akteure gefährdet demokratische Strukturen und individuelle Freiheitsrechte, aber die Alternative einer vollständig atomisierten Infrastruktur, in der jeder für sich selbst verantwortlich ist, schafft neue Ungerechtigkeiten zwischen denen, die die Ressourcen haben, und denen, die sie nicht haben. Exit-Strategien, sowohl in Form von Kündigungsfreiheit als auch von Datenportabilität, müssen als fundamentale Rechte begriffen und durchgesetzt werden. Doch ebenso wichtig ist die Erkenntnis, dass nicht jeder die Kapazität hat, jederzeit den Exit zu vollziehen. Ein alleinerziehender Elternteil mit zwei Jobs kann nicht einfach umziehen, auch wenn der Mietvertrag theoretisch kündbar ist. Ein kleines Startup kann nicht einfach seine gesamte Infrastruktur migrieren, auch wenn die APIs theoretisch offen sind. Die Freiheit zur Wahl setzt voraus, dass die Wahl auch praktisch möglich ist. Der Vortrag gliedert sich in drei Hauptteile, die jeweils konkrete Bezüge zur Hackerethik herstellen und die rechtlichen, technischen sowie gesellschaftspolitischen Dimensionen des Themas beleuchten. Dabei wird bewusst eine dialektische Herangehensweise gewählt, die Vor- und Nachteile beider Extreme beleuchtet und nach synthetischen Lösungen sucht. Im ersten Teil, der Anatomie der Abhängigkeit, untersuchen wir die Mechanismen, durch die Lock-in-Effekte entstehen, aber auch die “Freiheitsfallen”, in die man als Eigenheimbesitzer oder Betreiber eigener IT-Systeme geraten kann. Dabei zeigt sich, dass sowohl technische als auch soziale und ökonomische Faktoren eine Rolle spielen. Der Prozess des Vendor Lock-in vollzieht sich typischerweise in drei Stufen: Zunächst lockt die pure Convenience, die niedrigen Einstiegshürden und die Versprechen der Sorglosigkeit. In der zweiten Phase folgt die Integration, bei der immer mehr Funktionen und Abhängigkeiten aufgebaut werden. Schließlich erreicht man die dritte Stufe der faktischen Gefangenschaft, in der ein Wechsel technisch zwar möglich, aber praktisch und ökonomisch kaum noch durchführbar ist. Konkrete Beispiele machen diese Mechanismen greifbar: Die proprietäre AWS Lambda-Funktion, die sich nicht einfach zu Azure Functions portieren lässt, entspricht der vom Vermieter installierten Einbauküche, die man bei einem Umzug zurücklassen muss. Die astronomischen Egress-Gebühren, die Cloud-Provider für das Herunterladen großer Datenmengen verlangen, spiegeln die hohen Umzugskosten wider, die einen Wohnungswechsel so belastend machen. Die langfristigen Reserved Instances mit Preisnachlässen funktionieren nach demselben Prinzip wie Zwei-Jahres-Mietverträge, die kurzfristig attraktiv erscheinen, aber langfristig binden. Doch die Gegenposition verdient ebenfalls genaue Betrachtung. Das Eigenheim bindet auf seine eigene Weise: Die Heizungsanlage, die nach fünfzehn Jahren erneuert werden muss und deren Kosten sich auf fünfstellige Beträge belaufen können. Das Dach, das alle dreißig Jahre neu gedeckt werden muss. Die Fassade, die verwittert und saniert werden will. Der Garten, der nicht sich selbst überlassen werden kann, sondern ständige Pflege erfordert. Die Grundsteuer, die Gebäudeversicherung, die Rücklagen für unvorhergesehene Reparaturen. Studien zeigen, dass Eigenheimbesitzer durchschnittlich ein bis zwei Prozent des Gebäudewerts jährlich für Instandhaltung aufwenden müssen. Bei einem Haus im Wert von 400.000 Euro sind das 4.000 bis 8.000 Euro pro Jahr, zusätzlich zur Tilgung eines eventuellen Kredits. Die eigene IT-Infrastruktur fordert ähnliche Tribute. Ein selbstbetriebenes Rechenzentrum oder auch nur eine größere On-Premises-Installation erfordert qualifiziertes Personal, das rund um die Uhr verfügbar sein muss. Die Bereitschaftsdienste, die Nachtschichten, wenn kritische Updates eingespielt werden müssen. Die Sicherheitspatches, die nicht warten können. Die Hardware, die nach drei bis fünf Jahren erneuert werden muss, weil sie entweder veraltet ist oder aus dem Support läuft. Die Backup-Systeme, die regelmäßig getestet werden müssen, um sicherzustellen, dass sie im Ernstfall auch funktionieren. Die Compliance-Anforderungen, die bei DSGVO, ISO-Zertifizierungen und branchenspezifischen Regulierungen schnell komplex werden. Die Klimatisierung des Serverraums, die Stromversorgung mit USV und Notstromaggregat, die physische Sicherheit. Ein kleines Unternehmen, das seine eigene Infrastruktur betreibt, muss mit mindestens zwei bis drei Vollzeit-IT-Mitarbeitern rechnen, dazu kommen die Hardware-Kosten, die Räumlichkeiten, die Energiekosten. Die Skalierung stellt eine besondere Herausforderung dar. Wenn das Geschäft plötzlich wächst, etwa weil ein Produkt viral geht oder eine Marketing-Kampagne unerwartet erfolgreich ist, muss die Infrastruktur mitwachsen. In der Cloud bedeutet das ein paar Klicks oder automatische Skalierung. Im eigenen Rechenzentrum bedeutet es Hardware-Beschaffung mit Lieferzeiten von Wochen bis Monaten, Rack-Space, Installation, Konfiguration. Umgekehrt, wenn das Geschäft schrumpft, stehen die Server nutzlos herum, verbrauchen aber weiterhin Strom und binden Kapital. Das Eigenheim hat das gleiche Problem: Wenn die Kinder ausziehen, bleiben die Zimmer leer, aber die Heizkosten, die Instandhaltung, die Grundsteuer bleiben gleich. Downsizing ist schwierig und verlustreich. Dieser erste Teil bezieht sich besonders auf die Hackerethik-Prinzipien “Misstraue Autoritäten” und “Fördere Dezentralisierung”, muss aber auch das Prinzip “Beurteile Hacker nach ihrem Tun und nicht nach Kriterien wie Aussehen, Alter, Herkunft, Geschlecht oder gesellschaftliche Stellung” einbeziehen. Die Frage ist: Haben alle die gleichen Möglichkeiten, Eigenverantwortung zu übernehmen? Ein gut finanziertes Unternehmen mit eigenem IT-Team hat andere Optionen als ein Ein-Personen-Startup. Eine wohlhabende Familie kann sich ein Eigenheim leisten und hat Zeit und Mittel für dessen Instandhaltung, eine prekär beschäftigte Einzelperson hat diese Optionen nicht. Dezentralisierung darf nicht zu neuen Hierarchien führen, bei denen nur die Privilegierten echte Autonomie haben. Der zweite Teil widmet sich der politischen Ökonomie der Kontrolle und stellt die Frage: Wem gehört die Infrastruktur, und wem gehört damit die Macht? Hier zeigen sich beunruhigende Parallelen zwischen dem, was man als Datenkolonialismus bezeichnen könnte, und der digitalen Gentrifizierung auf der einen Seite und den realen Prozessen der Verdrängung und Enteignung auf Wohnungsmärkten auf der anderen Seite. Der Surveillance Capitalism, den Shoshana Zuboff beschrieben hat, trifft auf klassisches Rent-Seeking-Verhalten, bei dem Monopolisten ihre Marktmacht zur Extraktion von Renten nutzen. Die Illusion der Sharing Economy erweist sich in beiden Bereichen als trügerisch. Plattformen wie Airbnb haben Wohnraum nicht demokratisiert, sondern ihn weiter kommerzialisiert und verknappt. Cloud-Computing hat die IT-Infrastruktur nicht wirklich geteilt, sondern sie in den Händen weniger Tech-Giganten konzentriert. Die versprochene “Demokratisierung des Zugangs” entpuppt sich als neue Form der Abhängigkeit. Doch auch hier gilt: Die Alternative des totalen Eigentums ist nicht für jeden zugänglich. Die Demokratisierung kann nicht darin bestehen, dass jeder sein eigenes Haus und sein eigenes Rechenzentrum betreibt, denn das setzt Ressourcen voraus, die nicht gleichverteilt sind. Besonders brisant wird die Situation bei der Betrachtung der rechtlichen Rahmenbedingungen. Der US-amerikanische CLOUD Act gibt US-Behörden weitreichende Zugriffsmöglichkeiten auf Daten, die bei US-Unternehmen gespeichert sind, unabhängig vom physischen Standort der Server. Dies steht in direktem Widerspruch zur europäischen Datenschutz-Grundverordnung und stellt die digitale Souveränität europäischer Nutzer infrage. Während das Grundgesetz die Unverletzlichkeit der Wohnung garantiert und staatliche Durchsuchungen nur unter strengen rechtsstaatlichen Bedingungen erlaubt, haben wir im digitalen Raum faktisch die Türen zu unseren Daten weit geöffnet. Das Hausrecht, das jedem Wohnungsinhaber zusteht, existiert im Cloud-Computing nur noch nominell. Wer entscheidet darüber, wer Zugang zu unseren Daten hat? Nicht wir als Nutzer, sondern die Terms of Service der Cloud-Provider. Während ein Vermieter ohne richterliche Anordnung nicht einfach die Wohnung betreten darf, können Cloud-Provider nach ihren eigenen Richtlinien auf unsere Daten zugreifen, sie analysieren und unter Umständen auch an Dritte weitergeben. Das Recht auf Unverletzlichkeit, das im physischen Raum selbstverständlich ist, muss im digitalen Raum erst noch erkämpft und durchgesetzt werden. Doch das Hausrecht bringt auch Pflichten mit sich. Der Eigentümer einer Wohnung muss dafür sorgen, dass keine Gefahren von seinem Eigentum ausgehen. Wenn im Winter der Gehweg vor seinem Haus nicht geräumt ist und jemand stürzt, haftet der Eigentümer. Wenn die Elektrik veraltet ist und es zu einem Brand kommt, trägt er die Verantwortung. Ebenso trägt der Betreiber eigener IT-Systeme die Verantwortung für deren Sicherheit. Wenn durch mangelnde Sicherheitsvorkehrungen Kundendaten gestohlen werden, wenn Server für DDoS-Attacken missbraucht werden, wenn Malware sich von den eigenen Systemen aus verbreitet, dann liegt die Verantwortung beim Betreiber. Diese Verantwortung ist nicht trivial und erfordert kontinuierliche Aufmerksamkeit und Expertise. Die Verkehrssicherungspflicht im physischen Raum findet ihre Entsprechung in der IT-Sicherheitspflicht im digitalen Raum. Cloud-Provider haben professionelle Teams, die sich ausschließlich um Security kümmern, die über aktuelle Bedrohungen informiert sind, die 24/7 überwachen. Kann ein kleines Unternehmen das leisten? Kann eine Privatperson, die ihren eigenen Nextcloud-Server betreibt, wirklich sicherstellen, dass sie alle Sicherheitsupdates rechtzeitig einspielt, dass ihre Konfiguration sicher ist, dass sie nicht zur Angriffsfläche wird? Die Freiheit, seine eigene Infrastruktur zu betreiben, muss einhergehen mit der Fähigkeit, diese Verantwortung auch zu tragen. Dieser zweite Teil steht im Zeichen der Hackerethik-Prinzipien “Alle Informationen müssen frei sein” und “Öffentliche Daten nützen, private Daten schützen”. Diese scheinbar widersprüchlichen Forderungen ergeben erst in ihrer Zusammenschau Sinn: Öffentliche Infrastruktur, Standards und Protokolle müssen offen und zugänglich sein, während private Daten und persönliche Informationen geschützt werden müssen. Die aktuelle Situation verkehrt dies ins Gegenteil: Proprietäre Cloud-Services verschließen Standards und schaffen geschlossene Ökosysteme, während gleichzeitig private Daten der umfassenden Überwachung und Kommerzialisierung unterworfen werden. Doch auch die Lösung durch reines Selbsthosting greift zu kurz: Wenn die Standards zwar offen sind, aber nur eine technische Elite sie tatsächlich nutzen kann, entsteht eine neue digitale Kluft. Der dritte und abschließende Teil des Vortrags beschäftigt sich mit konkreten Wegen zur digitalen und physischen Selbstbestimmung, wobei der Fokus auf realistischen, mehrstufigen und gemeinschaftlichen Lösungen liegt statt auf binären Entweder-Oder-Entscheidungen. Technische Lösungsansätze wie Self-Hosting, Federation und Peer-to-Peer-Architekturen bieten Alternativen zur zentralisierten Cloud-Infrastruktur, aber sie müssen so gestaltet sein, dass sie nicht nur für Experten zugänglich sind. Projekte wie Nextcloud für File-Sharing und Collaboration, Matrix für Kommunikation und Mastodon für soziale Netzwerke zeigen, dass dezentrale, interoperable Systeme funktionieren können. Entscheidend ist dabei, dass diese Projekte niedrigschwellige Einstiegsmöglichkeiten bieten: Managed Nextcloud-Instanzen bei vertrauenswürdigen, kleinen Providern können ein Mittelweg sein zwischen Hyperscaler-Abhängigkeit und komplettem Selbstbetrieb. Tools wie Kubernetes ermöglichen eine gewisse Cloud-Portabilität, erfordern aber erhebliche Expertise. Infrastructure-as-Code-Ansätze wie Terraform helfen, die Abhängigkeit von einzelnen Providern zu reduzieren, setzen aber voraus, dass man die Ressourcen hat, diese Tools zu nutzen. Die Lösung kann nicht sein, dass jeder zum DevOps-Experten werden muss. Vielmehr brauchen wir abgestufte Modelle, bei denen unterschiedliche Level von Kontrolle und Verantwortung möglich sind. Gesellschaftliche Alternativen finden sich in genossenschaftlichen Modellen, Commons-Ansätzen und kollektiven Organisationsformen. Wohnungsgenossenschaften haben bewiesen, dass gemeinschaftlich organisierter Wohnraum nicht nur möglich, sondern oft auch sozial nachhaltiger ist als privatwirtschaftlich verwaltete Immobilien. Das Genossenschaftsmodell verteilt sowohl die Lasten als auch die Kontrolle: Nicht jedes Mitglied muss selbst das Dach reparieren, aber alle haben Mitspracherecht bei wichtigen Entscheidungen. Ähnliche Modelle ließen sich auf IT-Infrastruktur übertragen: Genossenschaftlich betriebene Server, kommunale Cloud-Infrastruktur und solidarische Netzwerke könnten Alternativen zu den Hyperscalern bieten. Projekte wie die deutsche Initiative “Sovereign Cloud Stack” oder genossenschaftlich organisierte Hosting-Provider zeigen, dass dies nicht nur Theorie ist. Das Modell der Verwaltungsgenossenschaften ist hier besonders instruktiv: Die Mitglieder einer Wohnungsgenossenschaft sind gemeinsam Eigentümer, müssen sich aber nicht selbst um jede Reparatur kümmern. Sie beschäftigen professionelles Personal, das sich um die Instandhaltung kümmert, behalten aber die demokratische Kontrolle über grundsätzliche Entscheidungen. Übertragen auf IT-Infrastruktur könnte das bedeuten: Eine Gemeinschaft von Nutzern finanziert gemeinsam die Anstellung von Systemadministratoren und Security-Experten, behält aber die Kontrolle über die grundsätzliche Ausrichtung, über Datenschutz-Policies, über die Wahl der Software. Dies wäre ein Mittelweg zwischen der totalen Abhängigkeit von Hyperscalern und der überfordernden Verantwortung des kompletten Selbstbetriebs. Praktische Strategien gegen Vendor Lock-in umfassen die konsequente Nutzung offener Standards, die Vermeidung proprietärer Services wo möglich, die Implementierung von Multi-Cloud-Architekturen und die regelmäßige Überprüfung der Exit-Möglichkeiten. Ebenso wie man als Mieter darauf achten sollte, keine allzu individuellen Einbauten vorzunehmen, die einen Umzug erschweren, sollte man in der IT darauf achten, keine zu tiefen Abhängigkeiten von provider-spezifischen Services aufzubauen. Aber auch hier gilt: Diese Strategien erfordern Expertise und Ressourcen. Ein realistischer Ansatz muss berücksichtigen, dass nicht jeder diese Strategien umsetzen kann. Hybrid-Ansätze verdienen besondere Beachtung. Nicht alles muss entweder komplett in der Cloud oder komplett on-premises sein. Sensible Daten und kritische Kernsysteme können selbst gehostet werden, während weniger kritische Workloads oder temporäre Lastspitzen in die Cloud ausgelagert werden. Entwicklungs- und Testumgebungen können in der Cloud laufen, während Produktion on-premises bleibt. Edge-Computing-Ansätze kombinieren lokale Kontrolle mit Cloud-Anbindung. Im Wohnbereich entspricht das vielleicht dem Modell für Kollektive, ein kleines Eigenheim auf dem Land zu besitzen, aber auch eine kleine Wohnung in der Stadt zu mieten für die Tage, an denen man dort arbeiten muss. Oder umgekehrt: In der Stadt zur Miete wohnen, aber ein Wochenendhaus besitzen. Interessanterweise lassen sich auch in der physischen Welt alternative Bewegungen beobachten, die das klassische Wohnmodell hinterfragen: Die Tiny-House-Bewegung, Van Life und kommunale Wohnprojekte experimentieren mit neuen Formen des Zusammenlebens, die mehr Autonomie und Flexibilität versprechen, aber auch neue Formen der gegenseitigen Unterstützung etablieren. Diese Experimente können als Inspiration für alternative digitale Infrastrukturen dienen. Nicht das isolierte Eigenheim ist die Lösung, sondern gemeinschaftliche Modelle, die Autonomie und Solidarität verbinden. Politische Forderungen müssen auf gesetzlich verankerte Interoperabilität, verpflichtende Datenportabilität und offene Standards abzielen. Der Digital Markets Act der EU ist ein Schritt in die richtige Richtung, reicht aber nicht weit genug. Ebenso wie das Mietrecht Mieter schützt und Kündigungsfristen regelt, brauchen wir digitale Grundrechte, die Nutzer vor willkürlicher Sperrung schützen und echte Wechselmöglichkeiten garantieren. Das Recht auf Wohnung, das in vielen Verfassungen verankert ist, braucht ein digitales Pendant: das Recht auf digitale Infrastruktur und Teilhabe. Gleichzeitig müssen wir aber auch über neue Modelle der Infrastrukturbereitstellung nachdenken. Public Money, Public Code ist ein wichtiger Ansatz: Wenn öffentliche Gelder in Software-Entwicklung fließen, sollte die Software auch öffentlich zugänglich sein. Ähnlich könnte man argumentieren: Wenn kritische digitale Infrastruktur zum Funktionieren der Gesellschaft notwendig ist, sollte sie nicht vollständig in privater Hand liegen. Kommunale Cloud-Infrastruktur, öffentlich-rechtlich organisierte Hosting-Services, staatlich geförderte Genossenschaften könnten Modelle sein, die den Zugang demokratisieren ohne die Verantwortung auf das Individuum abzuwälzen. Dieser dritte Teil bezieht sich auf die Hackerethik-Prinzipien “Zugang zu Computern sollte unbegrenzt und vollständig sein” und “Computer können dein Leben zum Besseren verändern”. Der Zugang zu digitaler Infrastruktur darf nicht vom Wohlwollen einiger weniger Tech-Konzerne abhängen, aber er darf auch nicht vom individuellen technischen Können oder den finanziellen Ressourcen abhängen. Nur wenn wir Modelle entwickeln, die echten Zugang für alle ermöglichen, können Computer ihr emanzipatorisches Potenzial entfalten. Die Kontrolle über unsere digitale Infrastruktur zurückzugewinnen kann nicht bedeuten, dass jeder Einzelne sein eigenes Rechenzentrum betreibt, sondern dass wir gemeinschaftliche, demokratisch kontrollierte Alternativen aufbauen. Der Winterkongress der Digitalen Gesellschaft Schweiz steht auch für die kritische Auseinandersetzung mit Machtverhältnissen in technischen Systemen. Die Hackerethik, wie sie der Chaos Computer Club formuliert hat, bildet dabei den ethischen Kompass. Sie lehrt uns, Autoritäten zu misstrauen und Dezentralisierung zu fördern. Die großen Cloud-Provider und Vermietungskonzerne stellen genau solche Autoritäten dar, deren strukturelle Macht es zu hinterfragen und zu brechen gilt. Die Hackerethik fordert, dass der Zugang zu Computern unbegrenzt und vollständig sein sollte. Wer jedoch seine Infrastruktur in fremde Hände gibt, verliert faktisch den vollständigen Zugang und die Kontrolle. Doch wer zum vollständigen Selbstbetrieb gezwungen wird ohne die notwendigen Ressourcen, verliert ebenfalls den Zugang, weil die technischen und finanziellen Hürden zu hoch sind. Die Lösung liegt in der Schaffung von kollektiven Infrastrukturen, die echte Wahlmöglichkeiten bieten. Die Hackerethik betont, dass Computer das Leben zum Besseren verändern können. Doch diese transformative Kraft kann sich nur entfalten, wenn wir die Kontrolle über die Technologie in einer Weise zurückgewinnen, die inklusiv ist und nicht exklusiv. Vendor Lock-in und Plattform-Monopole beschneiden diese Möglichkeiten und reduzieren uns zu passiven Konsumenten. Doch eine Lösung, die nur für technische Eliten funktioniert, ist ebenfalls keine Verbesserung. Wir brauchen Ansätze, die Autonomie ermöglichen ohne Überforderung zu erzeugen. Dieser Vortrag entstand aus den aktuellen Ereignissen einer privaten Ereignisfeldkarte: Die Analogie zum Wohnungsmarkt macht die abstrakten Gefahren von Vendor Lock-in greifbar und emotional zugänglich, aber sie zeigt auch die Komplexität der Probleme und die Notwendigkeit differenzierter Lösungen. Jede Person im Publikum kennt das Gefühl, ausgeliefert zu sein, sei es gegenüber dem Vermieter oder dem Cloud-Provider. Aber viele kennen auch das Gefühl der Überforderung, wenn plötzlich alles in der eigenen Verantwortung liegt. Diese gemeinsamen Erfahrungen nutzen wir als Ausgangspunkt für tiefgreifende technische und politische Diskussionen über Souveränität, Freiheit, Verantwortung und Solidarität in der digitalen Gesellschaft. about this event: https://winterkongress.ch/2026/talks/stadt_miete_vs_land_besitz_was_uns_wohnen_uber_digitale_souveranitat_lehrt/

Shadow Steps Understanding and Detecting User Impersonation and Lateral Movement in Active Directory

Thu, 26 Feb 2026 20:46:33 +0100

Author: SANS Offensive Operations - Bewertung: 1x - Views:6

This hands-on, scenario-driven workshop delves into how attackers move stealthily through Active Directory environments using user impersonation and lateral movement techniques. Participants will explore how attackers exploit credentials and trust relationships to expand their access, and how defenders can detect, prevent, and respond to such threats.

Through simulated exercises and guided labs, participants will walk through real-world attack paths such as (over)Pass-the-Hash, Kerberoasting, and token impersonation.

This hands-on workshop is ideal for Penetration Testers with limited knowledge about AD internals.

LEARNING OBJECTIVES:
- Understand the key mechanisms behind user impersonation in Active Directory.
- Demonstrate how attackers perform lateral movement via tools and techniques such as:
- Pass-the-Hash
- Pass-the-Ticket/Overpass-the-Hash
- Remote Services Abuse (SMB, WMI, RDP, WinRM)\
- SOCKS PTH
- Kerberoasting
- Token Impersonation
- Token Creation

PREREQUISITES:
- Basic understanding of Windows networks and Active Directory
- Familiarity with common cybersecurity concepts
- Participants should have an AWS account with appropriate payment methods associated.
- Participants will need an Ubuntu VM with Terraform and Empire Installed.

This workshop supports content and knowledge from SEC565: Red Team Operations and Adversary Emulation. To learn more about this course, explore upcoming sessions, and access your FREE preview, visit https://www.sans.org/sec565

Watch this session unedited and access the presentation slides: https://www.sans.org/webcasts/understanding-detecting-user-impersonation-lateral-movement

Learn more about Jean-François Maes: https://www.sans.org/profiles/jeanfrancois-maes

To check out more from the Offensive Operations curriculum and discover additional free resources, please visit: https://www.sans.org/offensive-operations

From lab to launch: Structuring ML operations for maximum velocity

Thu, 26 Feb 2026 12:04:29 +0100

Hiring data scientists has become the easy part of the AI equation. Every major enterprise now has a brilliant team of PhDs capable of building sophisticated recommendation engines, churn predictors and propensity models in their local environments.

But deploying those models? That is where the ROI goes to die.

In my experience leading engineering for global streaming platforms, I have seen a consistent, painful pattern: A data scientist builds a model that works perfectly in a Jupyter notebook. It has high accuracy, great recall and fits the training data perfectly. Then they hand it off to a machine learning engineer or DevOps team to productionize it.

Suddenly, velocity hits a wall. The code is not modular — the dependencies conflict with the production environment. The inference latency is too high for real-time traffic. What should be a one-day release turns into a 10-day slog of tickets, meetings and refactoring.

This throw-it-over-the-wall mentality creates a bottleneck that stifles innovation. In the streaming wars, where user preferences shift by the hour, a 10-day deployment cycle is unacceptable.

To solve this, we moved away from the service-bureau model and adopted a self-service architecture. By decoupling data engineering from model training and automating non-functional testing, we successfully reduced model deployment times from weeks to days (often a ~70% gain) and tripled our experiment velocity.

Here is the blueprint for how we did it.

The hidden cost of the full-stack myth

Many organizations try to solve the deployment gap by hiring full-stack data scientists, unicorns expected to know statistical modeling, Kubernetes, Terraform and CI/CD pipelines.

In practice, this rarely works. When you force a data scientist to manage infrastructure, you are paying a premium salary for someone to wrestle with YAML files rather than improve algorithms. I have watched brilliant mathematicians spend days debugging Docker container networking issues rather than optimizing hyperparameters. This is a waste of talent.

The solution is not to force scientists to become engineers. It is to build a platform that abstracts the engineering complexity away from them.

I have architected a golden path for deployment. This is a standardized, paved road that allows a data scientist to deploy a model without ever touching the underlying cloud infrastructure. We provide pre-baked templates that handle the scaffolding: standardizing input/output schemas, logging formats and error handling.

If a scientist stays on the path (using approved libraries and templates), the deployment is automated. They commit code and the platform handles the containerization, orchestration and scaling. If they veer off the path (using a custom, unverified library), they enter the manual review queue. This incentive structure naturally pushes the team toward standardization without micromanagement.

Decoupling features from models

The friction in ML operations often stems from data availability. A model requires specific features (e.g. “users who watched an action movie in the last 7 days”) to function.

In a siloed environment, the data scientist writes SQL to extract these features for training. When it is time to deploy, the data engineer must rewrite that logic for the production pipeline to ensure it runs at scale. This duplication is a breeding ground for training-serving skew, where the data used to train the model differs slightly from the live data, destroying accuracy.

To fix this, we implemented a centralized feature store.

The feature store acts as the single source of truth and solves the complex engineering problem of point-in-time correctness. Data engineers build the pipelines that populate the store once. Data scientists then just shop for features using a standardized SDK. They pull a feature set for training and the same feature definition is used for real-time inference.

By decoupling the feature engineering from the model training, we removed the dependency on data engineers for every single experiment. A scientist can mix and match existing features to test a new hypothesis without waiting for a new ETL pipeline to be built.

Automating the non-functional tests

In traditional software development, we have unit tests. In ML, we usually focus on functional metrics: accuracy, F1 score or AUC.

But in a high-scale streaming environment, a model can have 99% accuracy and still be a disaster. Why? Because of non-functional requirements.

Latency: If the model takes 200 ms to return a recommendation, the homepage load times out.
Cost: If the model requires massive GPU instances to run, it might cost more to operate than the revenue it generates.
Bias: The model might inadvertently stop recommending content to a specific demographic.

We shifted these checks left, moving them earlier in the pipeline. We built an automated evaluation harness that runs before a human ever reviews the deployment.

When a scientist commits code, the CI/CD pipeline spins up a shadow environment. It replays a sample of live traffic against the new model to measure latency and resource consumption. This shadow traffic is crucial because it mimics the unpredictability of the real world without impacting actual users.

If the model is too slow or too expensive, the build fails automatically. The scientist gets immediate feedback: “Your model is accurate, but it is 50 ms too slow. Optimize it.”

This prevents the 10-day loop where a model reaches production only to be rolled back due to performance issues.

The culture of experimentation

The ultimate goal of these technical changes is cultural. When deployment is hard, teams become risk-averse. They spend months perfecting a single megamodel because they are afraid of the pain of deploying it.

When deployment is easy (low cost, low risk and highly automated), teams shift to a culture of high-velocity experimentation. They test small changes daily. They try counterintuitive ideas because the cost of failure is low.

By structuring ML operations around self-service and automated guardrails, we didn’t just ship code faster. We fundamentally changed how we innovate. We moved from a culture of launch and pray to a culture of launch, learn and iterate.

In the era of AI, velocity is the only competitive moat that matters. If your data scientists are spending their days waiting for infrastructure tickets, you have already lost.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

ControlMonkey extends configuration disaster recovery to cloud network vendors

Wed, 25 Feb 2026 20:49:50 +0100

Network resiliency is about more than just DNS redundancy and using multiple regions and providers. It also requires extending resiliency to network configuration. That’s the challenge that cloud infrastructure automation startup ControlMonkey is now taking on.

ControlMonkey launched its Cloud Configuration Disaster Recovery capability in 2025, targeting AWS, Azure and GCP infrastructure. Today the company is expanding its configuration-level disaster recovery platform to the network control plane—specifically to the CDN configurations, firewall rules, DNS records, route tables and edge routing policies that sit outside the major cloud providers but are critical to production uptime. That support brings configuration backup capabilities for Cloudflare, Akamai, Fastly, and F5.

The goal is to close what is likely a gap in the resilience and disaster recovery posture for many organizations.

“Everybody backs up their data, right? You have to be crazy not to back up your data,” Aharon Twizer, CEO and co-founder of ControlMonkey, told Network World. “What about your networking configuration? If your networking is down, it’s amazing that you have data, but you’re not going to get any traffic.”

How ControlMonkey addresses the network configuration gap

The expansion came from customer requests for coverage beyond AWS, Azure, and Google Cloud Platform. Twizer, citing his own customer conversations, said the gap for third-party network vendors is larger than it is for cloud infrastructure

“If you look at the third party, like 90% of the people I talk to, they don’t manage their Cloudflare with Terraform, they don’t manage their Akamai with Terraform, they don’t manage their F5 with Terraform,” Twizer noted. “So, they have zero coverage.”

ControlMonkey uses the Terraform Infrastructure-as-Code (IaC) technology to define the environment. The platform connects to each supported vendor and reverse engineers live configurations into Terraform HCL code. It then creates versioned snapshots on a daily basis.

The workflow has three phases. First, the platform performs a full asset inventory after connecting a vendor. Second, it identifies which resources have no code coverage and flags them for the operator. Third, it enables daily configuration snapshots so teams have a known-good state to recover from.

“The way to back up your configuration is with infrastructure as code,” Twizer explained. “We specifically do that with Terraform, and our core technology, our secret sauce, is to take providers or vendors of infrastructure and reverse engineer existing configuration, live configuration, to code.”

Recovery is executed through a one-click restore. When an incident occurs, the platform uses Terraform automation to provision the last known-good configuration into a second tenant. Customers can also use ControlMonkey APIs to build automated recovery playbooks triggered from external alerting tools such as PagerDuty or Datadog.

Scope: Configuration recovery, not vendor availability

To be clear, ControlMonkey isn’t a solution that will solve the issue of provider outages. The platform addresses configuration recovery, not vendor availability monitoring.

The primary scenario ControlMonkey is designed for is a ransomware attack that deletes or corrupts network configurations rather than data. In that situation, workloads and data may be intact but the network control plane is gone and applications become unreachable.

If there’s an outage for the vendor in general, “there’s nothing we can do about it, really,” Twizer said. “We’re looking more at ransomware, we’re looking more at cyberattacks, we’re looking more at AI agents that make mistakes and honest mistakes by employees.”

The platform also does not provide multi-vendor failover recommendations. It shows recovery posture for existing vendor configurations, not routing guidance to alternative providers.

Roadmap points beyond networking

Network vendors are not the end of the expansion. Twizer said customer requests are driving coverage into additional vendor categories beyond cloud and networking, with the platform eventually targeting any third-party service that enterprises rely on for production operations. Compliance is also a factor. SOC 2 and ISO 27001 both address disaster recovery and business continuity planning, and ControlMonkey positions configuration recovery as part of that cycle alongside data protection.

Twizer said the thinking behind the expansion comes back to a straightforward gap in how most organizations define resilience today.

“Cyber resilience in 2026 is about data, about infrastructure, and about your network control plane,” Twizer said. “You need to have all three of them. If you just have one or two, basically, you’re not resilient.”

Serious About Learning Linux? Get 15 O'Reilly Linux and DevOps eBooks for Under $25

Sun, 22 Feb 2026 05:00:41 +0100

From command line to Kubernetes and Terraform, this bundle covers a lot!

Future-proof tech skills for the evolving AI job market

Fri, 20 Feb 2026 12:04:16 +0100

I started in technology at a time when writing clean code, managing infrastructure and mastering a specific programming language could sustain a decades-long career. Each major shift — from client-server computing to the internet and from virtualization to the cloud — brought both disruption and opportunity. The professionals who stayed curious, adaptable and grounded in business outcomes didn’t disappear. They evolved.

Today, artificial intelligence feels different to many people. I hear and speak it every day in conversations with CIOs, CHROs and technologists at every level of their careers. There’s a real fear that AI will hollow out tech jobs — especially at the entry level — and concentrate value in a smaller number of elite roles. I understand that concern: AI is already automating routine coding, testing and data-processing work at a pace we haven’t seen before.

But after decades of watching technology reshape work and after countless conversations with clients navigating this shift, I don’t believe we’re heading toward a jobless future. We are heading toward a skills transformation. Some roles will decline. Others will grow. Entirely new roles will emerge. The organizations that succeed will be the ones that act now to align talent strategies with how AI is actually changing work, not how headlines suggest it is.

How AI is reshaping tech roles in practice

When I talk with CIOs across industries, a few consistent patterns emerge.

First, roles centered on routine execution are shrinking. Tasks like basic application maintenance, repetitive coding, manual data preparation and simple QA are increasingly handled by AI-enabled tools. This shift disproportionately affects early-career technologists, who historically learned through repetition and exposure to foundational tasks. That’s a real challenge we must acknowledge and address through better onboarding, mentoring and structured upskilling.

At the same time, demand is rising sharply for roles that sit closer to decision-making and system design. Machine learning and AI engineers, data and analytics professionals, cloud and DevOps specialists, cybersecurity leaders and UX/UI designers are all seeing sustained growth. These roles require people who can frame problems, work across domains and evaluate outcomes, not just execute instructions.

We’re also seeing the creation of entirely new positions. Titles like “AI ethics officer,” “responsible AI lead,” and “human-AI strategist” didn’t exist in most organizations five years ago. Today, they’re becoming essential as enterprises grapple with governance, trust, bias and the human impact of automation.

The throughline here is simple: AI isn’t eliminating the need for technologists. It’s raising the bar on what technologists need to know and how they add value.

The future-proof technical skills CIOs should prioritize

From my perspective, CIOs should focus less on chasing individual tools and more on building capability clusters — combinations of skills that remain valuable even as platforms change. Here are the technical skill sets I believe will matter most over the next several years.

Machine learning and applied AI

While AI fluency is no longer optional, I want to be clear: Not everyone needs to be training large language models from scratch. What organizations need are professionals who can frame the right problems for AI, manage data pipelines, evaluate model outputs and explain results to non-technical stakeholders.

Skills like prompt engineering, vector search and responsible AI practices are becoming foundational. On the tooling side, familiarity with Python, TensorFlow, PyTorch and cloud-based AI services across major platforms is critical. Certifications can help, but hands-on experience applying AI to real business problems matters far more.

Data and analytics

AI is only as good as the data behind it. That’s why data and analytics skills continue to grow in importance. The most valuable professionals are those who can take large, messy datasets, apply advanced analytics or machine learning and translate insights into action.

Visualization tools such as Power BI, Tableau and Looker Studio remain important, as do core languages like SQL, Python and R. But the differentiator is the ability to connect insights to business decisions. Data literacy across the organization — not just in analytics teams — will increasingly separate leaders from laggards.

Cloud computing and DevOps

AI accelerates everything, including the need for scalable, resilient infrastructure. Managing hybrid and multicloud environments, automating deployments and ensuring security at scale are no longer niche skills.

Proficiency in platforms like AWS, Azure and Google Cloud, combined with tools such as Kubernetes and Terraform, is table stakes. What’s emerging as even more valuable is the ability to design architectures that balance speed, cost, compliance and sustainability. DevOps is no longer just about faster releases; it’s about operational intelligence.

Cybersecurity

As AI expands the attack surface, cybersecurity skills are evolving rapidly. We’re seeing growing demand for professionals who understand AI-enabled threats, automated defense mechanisms and identity-centric security models.

CIOs should invest in continuous training here, not just point-in-time certifications. The threat landscape is changing too fast for static skill sets.

Upskilling: Turning displacement into opportunity

One of the biggest mistakes organizations make is believing they can hire their way out of a skills gap. Today’s talent market doesn’t work that way. Competition is fierce, roles are evolving quickly and specialized expertise is harder to find than ever. Across industries, leaders are increasingly aligned on this reality: Solving hiring challenges requires investing in the people they already have, not just competing for the same limited talent pool.

I’ve seen the most success when companies create clear pathways from declining roles into growing ones. That means pairing technical training with real project experience, mentorship and time to learn. It also means rethinking how early-career talent gains exposure when entry-level tasks are automated. Rotational programs, apprenticeships and supervised AI-augmented work can fill those gaps.

Why human skills matter more than ever

As AI takes on more technical execution, human-centered skills become a competitive advantage. This is something we emphasize heavily at Dexian and it’s echoed by what we hear from employers and employees alike. For example, 85% of business leaders and 87% of workers agree that their organizations are putting more emphasis on human skills alongside technical expertise.

UX and UI designers are great examples. Designing inclusive, intuitive experiences requires empathy, creativity and cultural awareness — capabilities AI can assist with but not replicate. The same is true for roles like product managers, change leaders and human-AI strategists who sit at the intersection of technology, ethics and business execution.

These professionals ensure AI enhances human interaction rather than eroding it. They ask questions like: How does this system affect trust? How do we keep humans in the loop? How do we measure success beyond efficiency?

Creativity, communication, emotional intelligence, resilience and lifelong learning are no longer soft skills. They are core skills in an AI-centric organization.

What the future holds — and what CIOs should do now

If there’s one lesson my career has reinforced, it’s that technology never stands still and neither can we. AI will continue to reshape the tech workforce in ways we can’t fully predict. But the direction is clear. Fewer highly specialized roles, more multifaceted ones. Less emphasis on rote execution, more on judgment, integration and impact.

My advice to CIOs is straightforward. Start with an honest assessment of how AI is already changing work inside your organization. Identify which roles are at risk of becoming obsolete and which capabilities will matter most in three to five years. Invest aggressively in upskilling, especially early-career talent. And don’t underestimate the power of human skills to differentiate your organization in a world where technology is increasingly commoditized.

AI isn’t the end of tech careers; it’s the next chapter. The leaders who embrace that reality and prepare their people accordingly will shape not just the future of IT, but the future of work itself.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

CVE-2026-25499 | bpg terraform-provider-proxmox up to 0.93.0 SSH Configuration insecure default initialization of resource (GHSA-gwch-7m8v-7544)

Thu, 12 Feb 2026 08:53:13 +0100

A vulnerability classified as problematic was found in bpg terraform-provider-proxmox up to 0.93.0. Affected is an unknown function of the component SSH Configuration Handler. The manipulation results in insecure default initialization of resource. This vulnerability is reported as CVE-2026-25499. The attack can be launched remotely. No exploit exists. Upgrading the affected component is advised.

Cybersecurity jobs available right now: February 10, 2026

Tue, 10 Feb 2026 06:50:58 +0100

Cloud Security Engineer KPMG | Israel | On-site – View job details As a Cloud Security Engineer, you will establish, secure, and support critical Azure cloud infrastructure, with a strong focus on sensitive and regulated environments. You will design and implement secure cloud architectures using infrastructure-as-code practices, maintain and operate cloud systems and servers, and use tools such as Terraform, Bicep, and ARM templates for automation and standardization. Cloud Security Researcher Pentera | Israel | … More →

The post Cybersecurity jobs available right now: February 10, 2026 appeared first on Help Net Security.

MEDUSA Security Testing Tool With 74 Scanners and 180+ AI Agent Security Rules

Tue, 27 Jan 2026 17:06:27 +0100

MEDUSA, an AI-first Static Application Security Testing (SAST) tool boasting 74 specialized scanners and over 180 AI agent security rules. This open-source CLI scanner targets modern development challenges like false positives and multi-language coverage. MEDUSA consolidates security scanning across 42+ languages and file types, including Python, JavaScript, Go, Rust, Java, Dockerfiles, Terraform, and Kubernetes manifests. […]

The post MEDUSA Security Testing Tool With 74 Scanners and 180+ AI Agent Security Rules appeared first on Cyber Security News.

Secure, Reliable Terraform At Scale With Sonatype Nexus Repository

Mon, 26 Jan 2026 19:20:23 +0100

Terraform has become the de facto standard for infrastructure as code (IaC). From cloud-native startups to global enterprises, teams rely on Terraform to define, provision, and manage infrastructure with speed and consistency across cloud and on-prem environments. The post Secure,…

The post Secure, Reliable Terraform At Scale With Sonatype Nexus Repository appeared first on IT Security News.

What Wacky Projects do y'all build to stay relevant & build a career??

Sat, 24 Jan 2026 03:06:33 +0100

I started a new role as a Linux Endpoint Admin managing Ubuntu Desktops & RHEL servers in academia. Things are very slow waiting on other teams that I'm dyin to stop boredom & just build some random projects like socket programming, making a client/server app that phones home using FastAPI, building a BASH script that can recreate our ansible layout as DR, and even pullin out my trusty macbook to VPN home and play with my homelab AD with Ubuntu. Might even yank out some Kubernetes & terraform if I get bored enough. Hell I'm even going so far to play with my in-progress raspberry pi weather station at home.

Just curious what y'all are doing to stay relevant and fight boredom during these times of recession. Using Copilot/ChatGPT to my advantage while its still cheap enough and to learn new programming languages but Java is dead & tryna learn C, what else??

submitted by /u/electrowiz64
[link] [comments]

Build AI agents with Amazon Bedrock AgentCore using AWS CloudFormation

Fri, 23 Jan 2026 19:02:20 +0100

Amazon Bedrock AgentCore services are now being supported by various IaC frameworks such as AWS Cloud Development Kit (AWS CDK), Terraform and AWS CloudFormation Templates. This integration brings the power of IaC directly to AgentCore so developers can provision, configure, and manage their AI agent infrastructure. In this post, we use CloudFormation templates to build an end-to-end application for a weather activity planner.

Akamai Block Storage Makes Block Disk Encryption the Default in Terraform

Fri, 23 Jan 2026 16:20:50 +0100

Learn about the early 2026 Terraform update, how the change will affect your workflow, and how to successfully navigate any issues that may arise. This article has been indexed from Blog Read the original article: Akamai Block Storage Makes Block…

The post Akamai Block Storage Makes Block Disk Encryption the Default in Terraform appeared first on IT Security News.

heise+ | Virtualisierung: Wie man eine Proxmox-Infrastruktur mit Terraform bereitstellt

Tue, 20 Jan 2026 15:16:20 +0100

Mit Terraform definiert man komplexe Proxmox-Infrastrukturen und automatisiert Abläufe. Dabei arbeiten Proxmox-API, Templates und Terraform-Provider zusammen.

European Space Agency Acknowledges Another Breach as Criminals Claim 200 GB Data Haul

Thu, 01 Jan 2026 17:19:04 +0100

The European Space Agency has acknowledged yet another security incident after a cybercriminal posted an offer on BreachForums the day after Christmas claiming to have stolen over 20GB of data including source code, confidential documents, API tokens and credentials. The attacker claims they gained access to ESA-linked external servers on December 18 and remained connected for about a week, during which they allegedly exfiltrated private Bitbucket repositories, CI/CD pipelines, Terraform files and hardcoded credentials. ESA said that the breach may have affected only "a very small number of external servers" used for unclassified engineering and scientific collaboration, and that it has initiated a forensic security analysis.

Read more of this story at Slashdot.

CVE-2025-68922 | OpenOps up to 0.6.10 Terraform Block os command injection (EUVD-2025-205358)

Thu, 25 Dec 2025 06:43:13 +0100

A vulnerability was found in OpenOps up to 0.6.10 and classified as critical. Impacted is an unknown function of the component Terraform Block. Executing manipulation can lead to os command injection. This vulnerability appears as CVE-2025-68922. The attack requires local access. There is no available exploit. It is suggested to upgrade the affected component.

TerraUSD Creator Do Kwon Sentenced To 15 Years Over $40 Billion Crypto Collapse

Fri, 12 Dec 2025 04:48:43 +0100

An anonymous reader quotes a report from Reuters: Do Kwon, the South Korean cryptocurrency entrepreneur behind two digital currencies that lost an estimated $40 billion in 2022, was sentenced in New York federal court on Thursday to 15 years in prison for fraud and conspiracy. Kwon, 34, who co-founded Singapore-based Terraform Labs and developed the TerraUSD and Luna currencies, previously pleaded guilty and admitted to misleading investors about a coin that was supposed to maintain a steady price during periods of crypto market volatility. Kwon was one of several cryptocurrency moguls to face federal charges after a slump in digital token prices in 2022 prompted the collapse of a number of companies. [...] Kwon was accused of misleading investors in 2021 about TerraUSD, a so-called stablecoin designed to maintain a value of $1. Prosecutors alleged that when TerraUSD slipped below its $1 peg in May 2021, Kwon told investors a computer algorithm known as "Terra Protocol" had restored the coin's value. Instead, Kwon arranged for a high-frequency trading firm to secretly buy millions of dollars of the token to artificially prop up its price, according to charging documents. "I made false and misleading statements about why it regained its peg by failing to disclose a trading firm's role in restoring that peg," Kwon said in court. "What I did was wrong." He also faces charges in South Korea, and under his plea deal, prosecutors won't oppose his transfer abroad after he serves half of his U.S. sentence.

Read more of this story at Slashdot.

Crypto-crasher Do Kwon jailed for 15 years over $40bn UST bust

Fri, 12 Dec 2025 03:05:57 +0100

Judge said his fraud was on 'epic, generational scale'

Terraform Labs founder Do Kwon will spend 15 years in jail after pleading guilty to committing fraud.…

Crypto-crasher Do Kwon jailed for 15 years over $40bn UST bust

Fri, 12 Dec 2025 03:05:48 +0100

Judge said his fraud was on ‘epic, generational scale’ Terraform Labs founder Do Kwon will spend 15 years in jail after pleading guilty to committing fraud.… This article has been indexed from The Register – Security Read the original article:…

The post Crypto-crasher Do Kwon jailed for 15 years over $40bn UST bust appeared first on IT Security News.

“AI에 맞춰 재편되는 네트워크 인프라” 2025년 가장 주목할 만한 네트워킹 인수합병

Thu, 11 Dec 2025 09:35:54 +0100

2025년은 인수 합병이 활발한 한해였다. 로이터의 보도에 따르면, 골드만 삭스는 2025년 발표 기준 인수·합병 규모가 역사상 두 번째로 클 것이라고 전망했다.

네트워킹 분야에서는 2025년 성사된 대형 딜 상당수가 오래전부터 예고된 것이었다. 예를 들어, HPE가 주니퍼 네트웍스 인수를 최종 마무리하는 데만 18개월이 넘는 시간이 걸렸다. 팔로알토 네트웍스의 사이버아크(CyberArk) 인수처럼 250억 달러 규모의 큰 거래가 있는 반면, 규모는 작지만 영향력이 큰 인수합병도 있다. 여러 인수합병이 AI 역량을 중심에 두고 분산 자원 접근과 보안을 위한 더 강력한 시스템을 구축하려는 전략과 맞물려 있다.

엔터프라이즈 네트워킹의 미래를 좌우할 10여 건의 인수합병을 알파벳 순으로 정리했다.

아카마이, 퍼미온 인수

아카마이는 엣지 역량 강화를 목표로 웹어셈블리 스타트업 퍼미온(Fermyon)을 인수할 계획이라고 발표했다. 퍼미온은 웹어셈블리를 브라우저 영역에서 서버 사이드와 엣지 배포 영역으로 확장하는 데 기여했다. WASI(WebAssembly System Interface) 표준화가 임박하면서 이번 거래는 웹어셈블리 사용자 확대에 힘을 보탤 수 있다는 분석이 나온다.

아리스타, 벨로클라우드 인수

아리스타 네트웍스(Arista Networks)는 7월 브로드컴의 벨로클라우드(VeloCloud) SD-WAN 사업부를 인수했다. 인수 금액은 밝히지 않았다. 아리스타 입장에서 SD-WAN 기술을 인수해 부족했던 네트워킹 퍼즐 한 조각을 메우고, SD-WAN과 SASE, 지사 네트워킹 전략을 강화하는 계기가 됐다. 아리스타 CEO 제이슈리 울랄은 아리스타의 캠퍼스 및 광역 네트워크 사업 규모가 현재 7억 5,000만 달러에서 2026년 말까지 12억 5,000만 달러로 성장할 것이라고 전망했다.

AT&T, 루멘 광섬유 사업 인수

AT&T는 5월 루멘(Lumen)의 매스 마켓(Mass Market) 광섬유 사업 인수 계획을 발표했다. 57억 5,000만 달러 규모인 이번 거래는 통신사가 특히 인공지능 확산에 따른 트래픽 증가에 대응하면서 광섬유 기술을 얼마나 중시하는지를 보여준다. AT&T에 따르면, 루멘 매스 마켓 광섬유 자산에는 약 100만 명 광섬유 가입자와 400만 곳이 넘는 광섬유 서비스 제공 위치가 포함되어 있다.

시스코, 에즈더브스와 뉴럴패브릭 인수

시스코는 지난달 음성 간 통번역 기술을 보유한 비상장 AI 소프트웨어 업체 에즈더브스(EzDubs) 인수를 완료했다고 발표했다. 시스코는 자사 협업 솔루션에서 말투와 억양까지 보존하는 실시간 음성 번역 등 차세대 기능을 제공하는 데 에즈더브스의 기술을 활용할 계획이다. 11월에는 자체 데이터를 활용해 도메인 특화 SLM을 구축할 수 있는 생성형 AI 플랫폼을 제공하는 AI 플랫폼 기업 뉴럴패브릭(NeuralFabric)도 인수했다.

코어위브, 코어 사이언티픽 인수

엔비디아의 투자를 받은 AI 클라우드 서비스 업체 코어위브(CoreWeave)는 암호화폐 채굴 업체 코어 사이언티픽(Core Scientific)을 약 90억 달러에 인수했다. 코어위브는 이번 인수로 AI 및 고성능 컴퓨팅(HPC) 워크로드 수요 증가에 대응하기 위해 계약된 1.3기가와트 규모 전력을 확보하게 됐다고 밝혔다. 코어위브는 이번 거래로 직접 보유·운영하는 데이터센터 자산이 확대돼 수직 통합 구조가 강화되고, 엔터프라이즈 및 연구 기관 고객을 위한 GPU 기반 서비스 확장에 속도를 낼 수 있다고 설명했다.

F5, 칼립소AI, 플레치, 맨티스넷 인수

F5는 아일랜드 더블린에 본사를 둔 칼립소AI(CalypsoAI)를 1억 8,000만 달러에 인수했다. 칼립소AI의 플랫폼은 서로 다른 모델과 업체, 환경 전반을 보호하는 ‘추론 경계(Inference Perimeter)’를 구축하는 기능을 제공한다. F5는 칼립소AI의 적응형 AI 보안 역량을 자사의 애플리케이션 딜리버리 및 시큐리티 플랫폼(ADSP)에 통합할 계획이라고 밝혔다.

F5는 또 에이전틱 AI 및 위협 관리 스타트업 플레치(Fletch)를 인수해, 외부 위협 인텔리전스와 내부 로그를 실시간 우선순위 인사이트로 전환하는 플레치의 기술과 에이전틱 AI 기능을 ADSP에 더할 예정이다.

마지막으로 클라우드 네이티브 가시성 강화를 위해 스타트업 맨티스넷(MantisNet)을 인수했다. F5 블로그에 따르면, 맨티스넷은 eBPF 기반 커널 레벨 텔레메트리를 활용해 암호화 프로토콜 트래픽 활동에 대한 실시간 인사이트를 제공하고, 성능 저하 없이 가장 파악하기 어려운 트래픽까지 가시성을 확보하도록 지원한다.

HPE, 주니퍼 인수 마무리

7월에 최종 마무리된 134억 달러 규모의 이번 거래로 HPE의 네트워킹 사업 규모는 사실상 두 배가 됐고 AI 기술 역량도 대폭 강화됐다. 퓨처럼 그룹(Futurum Group)은 거래 종결 직후 발표한 보고서에서 이번 인수가 엔터프라이즈 캠퍼스, 데이터센터, 통신사업자, 클라우드 네트워킹을 아우르는 통합 포트폴리오를 구성하는 토대를 마련했다고 평가했다.

퓨처럼 그룹은 “이번 인수로 방화벽, 서비스 엣지, 제로 트러스트 아키텍처 전반을 아우르는 통합 네트워크 보안 제품을 제공할 수 있는 기회가 생겼다”라며, “통합 회사는 ‘네트워크를 위한 AI’와 ‘AI를 위한 네트워크’라는 두 시장 기회를 모두 공략하게 될 것”이라고 분석했다.

IBM, 하시코프 인수 최종 완료

IBM은 지난 2월 64억 달러에 인수한 하시코프(HashiCorp)를 전 세계 데이터센터에 자동화 및 보안 기술을 확산하는 데 활용할 것이라고 밝혔다. IBM은 하시코프의 자동화 기술을 레드햇, 왓슨엑스, 데이터 보안, IT 자동화, 컨설팅 사업 전반에 통합할 계획이다. 하시코프의 대표 제품에는 여러 클라우드와 온프레미스 환경에 걸쳐 인프라·네트워크·가상 컴포넌트를 프로비저닝할 수 있게 해주는 테라폼(Terraform) 패키지가 포함되어 있다.

넷기어, 엑시엄 인수

넷기어(Netgear)는 2025년 6월 SASE 포트폴리오 확대를 위해 비상장 보안 전문업체 엑시엄(Exium)을 인수했다. 소비자용 네트워킹 하드웨어로 잘 알려진 넷기어는 중견·중소기업을 위한 엔터프라이즈급 보안 솔루션으로 무게 중심으로 옮기고 있다. 넷기어 포 비즈니스(Netgear for Business) 부문 사장 겸 총괄 책임자인 프라모드 바드자테는 네트워크월드와의 인터뷰에서 “넷기어의 기반을 고려할 때, 중소·중견 기업 고객의 요구를 해결할 수 있는 넷기어만의 기회가 있다고 본다”라고 말했다. 또, “중소·중견 기업 고객은 대기업과 동일한 수준의 신뢰성을 원하면서도 그에 걸맞은 지원까지 기대하는 독특한 요구를 갖고 있다”라고 덧붙였다.

노키아, 인피네라 인수

노키아는 23억 달러 규모의 인피네라(Infinera) 인수를 통해 DWDM 기술 역량을 대폭 확대했고, 이를 기반으로 하이퍼스케일러 및 통신사업자급 솔루션을 강화할 계획이다.

팔로알토 네트웍스, 사이버아크 인수

팔로알토 네트웍스는 7월 250억 달러 규모의 사이버아크(CyberArk) 인수 계획을 발표해 네트워크 액세스 및 ID 관리 포트폴리오를 확장했다. 에베레스트 그룹(Everest Group)은 “팔로알토는 이번 인수를 머신·에이전트 ID 보호를 위한 궁극적인 도약의 기회로 삼고 있다. AI 기반 위협 시대에 가장 뜨거운 영역 중 하나다”라고 평가했다. 또, “이번 인수는 주요 사이버보안 업체가 AI 기반 엔터프라이즈의 필수 파트너로 자리매김하기 위해 어떤 방향으로 스스로를 재정의하려 하는지를 보여주는 지각 변동급 신호”라고 분석했다.

퀄컴, 알파웨이브 세미 인수

퀄컴은 데이터센터 네트워킹 및 컴퓨트 포트폴리오 확대를 위해 영국 하드웨어 제조사 알파웨이브 세미(Alphawave Semi)를 24억 달러에 인수했다. 알파웨이브 세미는 맞춤형 실리콘, 칩렛, ASIC, 반도체 지식재산(IP)을 포함해 다양한 유선 연결 및 컴퓨트 기술을 보유하고 있다. 퀄컴의 목표는 점점 더 고도화되는 AI 워크로드를 지원하기 위해 퀄컴 프로세서와 알파웨이브의 고속 연결·컴퓨트 기술을 결합하는 것이다. 무어 인사이츠 앤 스트래티지의 대표 애널리스트 맷 킴벌은 6월 인수 발표 당시 “퀄컴이 데이터센터 CPU 시장에 얼마나 진지하게 뛰어들고 있는지 보여주는 가장 강력한 증거가 바로 이번 인수”라고 평가했다.
dl-ciokorea@foundryco.com

Most significant networking acquisitions of 2025

Wed, 10 Dec 2025 16:20:49 +0100

This year is shaping up to be an active one for mergers and acquisitions. Goldman Sachs says 2025 is on pace to become the second-biggest in history for announced M&As, Reuters reports.

In the networking arena, some of the biggest deals of 2025 were a long time coming — it took more than 18 months for HPE to finally close the Juniper Networks deal, for example. Some come with blockbuster price tags (like Palo Alto Networks’ $25 billion CyberArk buy), while others are less costly but still impactful. Many of the deals revolve around AI capabilities and enabling vendors to develop more robust systems for accessing and securing distributed resources.

Here are more than a dozen of this year’s acquisitions, organized alphabetically by acquirer, that will help shape the future of enterprise networking.

Akamai acquires Fermyon

This month Akamai announced plans to acquire WebAssembly startup Fermyon for an undisclosed sum as the company looks to expand its own edge capabilities. Fermyon helped to develop Wasm beyond its browser foundation for server-side and edge deployments. The deal could bring more users to Wasm, which is gaining momentum as the WebAssembly System Interface (WASI) specification nears standardization.

Arista buys VeloCloud

Arista Networks acquired Broadcom’s VeloCloud SD-WAN business in July for an undisclosed sum. For Arista, the SD-WAN buy fills one of the few networking gaps the company had and boosts its SD-WAN, SASE and branch networking plans. And those plans are big: CEO Jayshree Ullal said Arista’s campus and WAN business is expected to grow from the current $750 million to $1.25 billion by the end of 2026.

AT&T buys Lumen

AT&T in May announced plans to acquire Lumen’s Mass Markets fiber business. This deal, worth $5.75 billion, is an example of how important carriers see fiber optic technology, particularly as they look to handle the expected traffic increases spurred by AI. The Lumen Mass Markets fiber assets included in the deal total about 1 million fiber subscribers across more than 4 million fiber locations, according to AT&T.

Cisco makes two AI deals: EzDubs and NeuralFabric

Last month Cisco completed its acquisition of EzDubs, a privately held AI software company with speech-to-speech translation technology. EzDubs translates conversations across 31 languages and will accelerate Cisco’s delivery of next-generation features, such as live voice translation that preserves the characteristics of speech, the vendor stated. Cisco plans to incorporate EzDubs’ technology in its Cisco Collaboration portfolio. Also in November, Cisco bought AI platform company NeuralFabric, which offers a generative AI platform that lets organizations develop domain-specific small language models using their own proprietary data.

Coreweave buys Core Scientific

Nvidia-backed AI cloud provider CoreWeave acquired crypto miner Core Scientific for about $9 billion, giving it access to 1.3 gigawatts of contracted power to support growing demand for AI and high-performance computing workloads. CoreWeave said the deal augments its vertical integration by expanding its owned and operated data center footprint, allowing it to scale GPU-powered services for enterprise and research customers.

F5 picks up three: CalypsoAI, Fletch and MantisNet

F5 acquired Dublin, Ireland-based CalypsoAI for $180 million. CalypsoAI’s platform creates what the company calls an Inference Perimeter that protects across models, vendors, and environments. F5 says it will integrate CalypsoAI’s adaptive AI security capabilities into its F5 Application Delivery and Security Platform (ADSP).

F5’s ADSP also stands to gain from F5’s acquisition of agentic AI and threat management startup Fletch. Fletch’s technology turns external threat intelligence and internal logs into real-time, prioritized insights; its agentic AI capabilities will be integrated into ADSP, according to F5.

Lastly, F5 grabbed startup MantisNet to enhance cloud-native observability in F5’s ADSP. MantisNet leverages extended Berkeley Packet Filer (eBPF)-powered, kernel-level telemetry to provide real-time insights into encrypted protocol activity and allow organizations “to gain visibility into even the most elusive traffic, all without performance overhead,” according to an F5 blog post.

HPE makes it official with Juniper

Finalized in July, this $13.4 billion deal basically doubled HPE’s networking business while bolstering its AI technologies. The transaction set the stage for offering a combined portfolio spanning enterprise campus, data center, service provider, and cloud networking segments, according to the Futurum Group. “The deal creates opportunities for integrated network security offerings spanning firewall, service edge, and zero-trust architectures,” the analyst firm wrote after the close of the deal. “The combined entity will compete in both ‘AI for networks’ and ‘networks for AI’ market opportunities.”

IBM finalizes HashiCorp deal

IBM’s $6.4 billion buy of HashiCorp, finalized in February, will infuse HashiCorp automation and security technology in every data center possible, Big Blue said. IBM plans to integrate HashiCorp’s automation technology into its Red Hat, watsonx, data security, IT automation, and consulting businesses. HashiCorp’s products include its flagship Terraform package, which lets customers provision infrastructure, network, and virtual components across multiple cloud providers and on-premises environments.

Netgear acquires Exium

In June 2025, Netgear acquired the privately held security vendor Exium to expand its SASE offerings. Known as a networking hardware vendor for consumers, Netgear is increasingly focused on delivering enterprise-grade security solutions for SMEs. “What I see as an opportunity, uniquely for Netgear, given what our roots are, is to address the needs of small and medium enterprise customers,” Pramod Badjate, president and general manager of Netgear for Business,told Network World. “They have a unique need where they want the same level of reliability as a large enterprise expects [and] they also expect support.”

Nokia purchases Infinera

This $2.3 billion deal brought Nokia a ton more optical and dense wavelength-division multiplexing (DWDM) technology that it will use to bolster its hyperscaler and carrier class offerings.

Palo Alto Networks grabs CyberArk

Announced in July, this $25 billion deal gives Palo Alto a significant boost for its network access and identity management portfolio. “Palo Alto is positioning this acquisition as the ultimate leap toward securing machine and agent identities – one of the hottest frontiers in the rapidly emerging era of AI-driven threats,” the Everest Group wrote in a blog post about the acquisition. “It signals a seismic shift in how the biggest cybersecurity providers hope to position themselves as indispensable partners for the AI-powered enterprise.”

Qualcomm takes Alphawave Semi

Looking to expand its data center networking and compute offerings, Qualcomm grabbed British hardware maker Alphwave Semi for $2.4 billion. Alphawave Semi has a variety of wired connectivity and compute technologies, including custom silicon, chiplets, ASIC, and semiconductor intellectual property. The goal is to pair Qualcomm processors with Alphawave’s high-speed connectivity and compute technologies to support increasingly intense AI workloads. “If you wanted a super strong indicator that Qualcomm was serious about playing in the datacenter CPU market, this is it,” said Matt Kimball, vice president and principal analyst at Moor Insights & Strategy, when the deal was announced in June.

IBM to buy Confluent to extend its data and automation portfolio

Mon, 08 Dec 2025 20:05:51 +0100

IBM has agreed to acquire cloud-native enterprise data streaming platform Confluent in a move designed to expand its portfolio of tools for building AI applications

The company said Monday in a release that it sees Confluent as a natural fit for its hybrid cloud and AI strategy, adding that the acquisition is expected to “drive substantial product synergies” across its portfolio.

Confluent connects data sources and cleans up data. It built its service on Apache Kafka, an open-source distributed event streaming platform, sparing its customers the hassle of buying and managing their own server clusters in return for a monthly fee per cluster, plus additional fees for data stored and data moved in or out.

IBM expects the deal, which it valued at $11 billion, to close by the middle of next year.

Confluent CEO and co-founder Jay Kreps stated in an email sent internally to staff about the acquisition, “IBM sees the same future we do: one in which enterprises run on continuous, event-driven intelligence, with data moving freely and reliably across every part of the business.”

It’s a good move for IBM, noted Scott Bickley, an advisory fellow at Info-Tech Research Group. “[Confluent] fills a critical gap within the watsonx platform, IBM’s next-gen AI platform, by providing the ability to monitor real-time data,” he said, and is based on the industry standard for managing and processing real-time data streams.

He added, “IBM already has the pieces of the puzzle required to build and train AI models; Confluent provides the connective tissue to saturate those models with continuous live data from across an organization’s entire operation, regardless of the source. This capability should pave the road ahead for more complex AI agents and applications that will be able to react to data in real time.”

He also pointed out that the company is playing the long game with this acquisition, which is its largest in recent history. “IBM effectively positions itself proactively to compete against the AI-native big data companies like Snowflake and Databricks, who are all racing towards the same ‘holy grail’ of realizing AI agents that can consume, process, and react to real-time data within the context of their clients’ trained models and operating parameters,” he said, adding that IBM is betting that a full-stack vertical AI platform, watsonx, will be more appealing to enterprise buyers than a composable solution comprised of various independent components.

The move, he noted, also complements previous acquisitions such as the $34.5 billion acquisition of Red Hat and the more recent $6.4 billion acquisition of Hashicorp, all of which are built upon dominant open source standards including Linux, Terraform/Vault, and Kafka. This allows IBM to offer a stand-alone vertical, hybrid cloud strategy with full-stack AI capabilities apart from the ERP vendor space and the point solutions currently available.

In addition, he said, the timing was right; Confluent has been experiencing a slowing of revenue growth and was reportedly shopping itself already.

“At the end of the day, this deal works for both parties. IBM is now playing a high-stakes game and has placed its bet that having the best AI models is not enough; it is the control of the data flow that will matter,” he said.

LHB Linux Digest #25.36: 2 New Courses - Terraform (FREE) and Kubernetes, Disk Space Management and More

Fri, 28 Nov 2025 14:38:15 +0100

Two new courses!

Chapter 10: Terraform Functions: Your Code’s Swiss Army Knife

Fri, 28 Nov 2025 11:51:12 +0100

Use the function feature to manipulate data, strings, numbers, and collections.

Chapter 11: Workspaces, Null Resources, and Lifecycle Rules

Fri, 28 Nov 2025 11:51:11 +0100

You’ve learned the basics. Now let’s talk about three advanced patterns that separate beginners from practitioners: managing multiple environments elegantly, running actions that aren’t tied to resources, and controlling how Terraform handles resource changes.

Chapter 12: Terraform Best Practices and Standards

Fri, 28 Nov 2025 11:51:10 +0100

Time to upgrade from a Terraform user to a Terraform practitioner.

Chapter 7: Dynamic Blocks in Terraform

Fri, 28 Nov 2025 11:38:19 +0100

Create flexible and advanced configurations using dynamic blocks.

Chapter 8: Terraform Modules: Building Blocks You Can Reuse Everywhere

Fri, 28 Nov 2025 11:38:17 +0100

Learn how to design, use, and structure modules like real production setups. Reuse isb the key here.

Chapter 4: Terraform State and Providers

Fri, 28 Nov 2025 11:22:04 +0100

Dive deep into state files, provider configuration, remote state, and dangers of bad state handling.

Chapter 5: Resources, Data Sources, and Dependencies

Fri, 28 Nov 2025 11:22:02 +0100

Understand how Terraform actually builds infrastructure graphs and manages dependencies.

Learn Infrastructure as Code with Terraform

Fri, 28 Nov 2025 11:08:25 +0100

Learn Terraform from scratch with a Linux-first approach. Master Infrastructure as Code concepts, modules, state, best practices, and real-world workflows.

Chapter 1: Infrastructure as Code - Here We Go

Fri, 28 Nov 2025 11:08:24 +0100

Before we get to Terraform, let me take you back in time so we understand why Terraform exist at first place.

Chapter 2: Getting Started - Your First Steps

Fri, 28 Nov 2025 11:08:23 +0100

Ready to jump in? Here’s how to get started with Terraform

Chapter 3: Terraform Variables and Locals

Fri, 28 Nov 2025 11:08:21 +0100

Hardcoding values works for demos, not production. Variables make your code flexible. Locals make it DRY (Don’t Repeat Yourself).

(g+) Cloudinfrastruktur programmieren: Warum CDK für Terraform mein Lieblings-IaC-Tool ist

Wed, 26 Nov 2025 13:46:32 +0100

Mit CDKTF lässt sich Cloudinfrastruktur programmieren statt konfigurieren. Alle modernen Infrastrukturprojekte sollten damit gebaut werden. Von Michael Lohr (Cloud Computing, JSON)

HashiCorp Vault Vulnerability Allow Attackers to Authenticate to Vault Without Valid Credentials

Tue, 25 Nov 2025 10:06:01 +0100

The post HashiCorp Vault Vulnerability Allow Attackers to Authenticate to Vault Without Valid Credentials appeared first on IT Security News.

HashiCorp Vault Vulnerability Allow Attackers to Authenticate to Vault Without Valid Credentials

Tue, 25 Nov 2025 09:50:55 +0100

A critical security flaw has been discovered in HashiCorp’s Vault Terraform Provider that could allow attackers to bypass authentication and access Vault without valid credentials. The vulnerability, tracked as CVE-2025-13357, affects organizations using LDAP authentication with Vault. The security issue stems from an incorrect default configuration in Vault’s Terraform Provider. Specifically, the provider set the deny_null_bind parameter […]

The post HashiCorp Vault Vulnerability Allow Attackers to Authenticate to Vault Without Valid Credentials appeared first on Cyber Security News.

(g+) Systemadministration: Ein Kubernetes-Cluster mit Kube-Hetzner erstellen

Mon, 24 Nov 2025 13:32:34 +0100

Mit Terraform und Kube-Hetzner lässt sich ein Kubernetes-Cluster in der Hetzner-Cloud erstellen. Wir zeigen, wie das geht. Eine Anleitung von Dominik Robert (Kubernetes, Server)

[NEU] [mittel] Hashicorp Terraform (Enterprise, Vault Provider): Mehrere Schwachstellen

Mon, 24 Nov 2025 10:06:20 +0100

Ein entfernter, anonymer oder authentisierter Angreifer kann mehrere Schwachstellen in Hashicorp Terraform ausnutzen, um Sicherheitsvorkehrungen zu umgehen und Daten zu manipulieren.

SREcon25 Europe/Middle East/Africa - Speeding Up Terraform Caching with OverlayFS

Wed, 19 Nov 2025 01:34:29 +0100

Author: USENIX - Bewertung: 5x - Views:106

Speeding Up Terraform Caching with OverlayFS

Ricard Bejarano, Cisco

The Terraform plugin cache, unfortunately, does not support concurrent Terraform inits. This leaves us no other choices than disabling caching or serializing our inits, both of which would significantly slow down our Terraform pipelines, which are expected to make hundreds of plans in single-digit minutes.

In this talk we go over how we solved that with OverlayFS, a tool we rarely see outside of its niche, but so powerful that it helped us cut our plan times by 90%!

View the full SREcon25 EMEA program at https://www.usenix.org/conference/srecon25emea/program

Infrastructure-as-Code: Die neue Plattform formae soll Terraform & Co. ablösen

Tue, 28 Oct 2025 15:30:49 +0100

Die Open-Source-Plattform formae will bestehende IaC-Ansätze reformieren und vereinfachen. Platform Engineering Labs tritt damit in Konkurrenz zu Terraform.

Implement a secure MLOps platform based on Terraform and GitHub

Wed, 08 Oct 2025 18:05:43 +0200

Machine learning operations (MLOps) is the combination of people, processes, and technology to productionize ML use cases efficiently. To achieve this, enterprise customers must develop MLOps platforms to support reproducibility, robustness, and end-to-end observability of the ML use case’s lifecycle. Those platforms are based on a multi-account setup by adopting strict security constraints, development best […]

Chekov: Open-source static code analysis tool

Thu, 02 Oct 2025 08:04:07 +0200

Checkov is an open-source tool designed to help teams secure their cloud infrastructure and code. At its core, it’s a static code analysis tool for infrastructure as code (IaC), but it also goes a step further by providing software composition analysis (SCA) for container images and open source packages. With Checkov, you can scan just about any cloud infrastructure setup, whether you’re using Terraform, CloudFormation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfiles, Serverless, Bicep, OpenAPI, … More →

The post Chekov: Open-source static code analysis tool appeared first on Help Net Security.

Security folks, which would you feel more comfortable with?

Wed, 01 Oct 2025 03:50:06 +0200

Hi all,

I work at a SaaS company that needs to securely connect our cloud control plane to customer on-premise infrastructure in order to run orchestration and automation tasks. We’re trying to avoid requiring customers to open inbound firewall rules or stand up full VPNs.

We’ve narrowed it down to two models:

Agent-based HTTPS/mTLS connector

Customer deploys a small VM/Pod (our agent) inside their environment.
The agent makes an outbound TLS connection (443) to our SaaS, authenticates with mTLS, polls for jobs, and executes them locally.
Simple setup (firewall-friendly, “just outbound HTTPS”), similar to how Datadog agents, GitHub Actions runners, or Terraform Cloud Agents work.

WireGuard-based connector

Customer deploys the same kind of connector, but instead of plain HTTPS, it establishes a WireGuard tunnel back to our cloud.
Provides a stable overlay /32 per connector, potentially lower latency, and allows us to send jobs and receive results over a secure tunnel.
Requires outbound UDP (or TCP fallback with something like Tailscale/Netbird).
More networking moving parts, but possibly a more robust transport.

We want to balance security posture, customer comfort during security review, and ease of deployment. From your perspective (especially those who review SaaS vendors for security), which approach would give you more confidence, and why?

Thanks!

submitted by /u/hellomello988765
[link] [comments]

Why versioning AI agents is the CIO’s next big challenge

Mon, 15 Sep 2025 15:19:45 +0200

As artificial intelligence continues its rapid evolution, a new paradigm is emerging, one where autonomous, goal-driven agents operate with increasing independence, adaptability and contextual awareness. These agentic AI systems are not just executing tasks; they are reasoning, planning and orchestrating actions across complex environments. With this shift comes a new challenge: how do we version agentic AI agents?

In my previous article, A practical guide to agentic AI deployment, I talked about moving to a software development lifecycle consisting of experiment and build, evaluate and test, adapt, transition to the deployment environment, continue to test, version and repeat. Add to that that, on average, the AI model lifecycle is less than 18 months, so it becomes imperative to create an agent versioning strategy.

Traditional software versioning strategies, anchored in static codebases and predictable release cycles, fall short when applied to agentic systems. These agents may learn from experience, update their internal models or even reconfigure their toolchains in response to dynamic goals. Their behavior is shaped not only by code but by memory, context and interaction history. As a result, versioning an agent is no longer just about tracking code changes. It’s about capturing the evolution of behavior, intent and capability. An AI implementation strategy is no longer optional but essential for organizations, and the most critical component of this strategy is a comprehensive approach to agent versioning and rollback capabilities. These systems act as safety nets, allowing organizations to quickly revert to stable versions when new deployments cause unforeseen issues.

This article explores the emerging discipline of agent versioning: how to define, manage and govern the lifecycle of AI agents. We’ll examine the unique challenges posed by agentic systems, outline practical versioning strategies and processes that align with your enterprise needs. Whether you’re building agents for customer support, operations or innovation, understanding how to version them effectively is key to ensuring trust, traceability and continuous improvement.

What makes agent versioning different

To start with, we need to understand what makes agent versioning different. Versioning in traditional software (and machine learning systems) is predominantly deterministic. It is anchored in static codebases and predictable release cycles. Agentic AI, by contrast, introduces a new level of complexity. These agents are not just executing instructions; they are reasoning, adapting and evolving in response to dynamic environments. This shift requires a rethinking of how we define and manage versions. We need to be thinking about and planning for the following:

Agent behavior

Agentic agents’ behavior is affected through the model used and its version, the prompt and system context, and tool availability through model context protocol (MCP) calls. This introduces variability, and new versions may be required when developers continue to tweak the prompts for optimal responses. It is essential that, when versioning agents, you are comparing multiple versions side by side, ensuring a comparison to a measured baseline.

Stateful and contextual behavior

Agentic AI agents often maintain memory across interactions, enabling them to build context, learn user preferences and refine strategies over time. This state means that versioning must account for code and model changes as well as memory snapshots and contextual embeddings. A new version may behave differently, not because of a code change, but because of accumulated experience. It is important to remember that AI systems are non-deterministic, and the outputs can vary even with the same prompts.

Autonomy and self-modification

Unlike static models, agentic systems may modify their own behavior through reflection, planning or tool selection. This introduces the possibility of agents evolving independently of their original design. Versioning must capture not just what the agent was built to do, but what it has become through interaction. We also need to capture version changes to tool calls through MCP endpoints, as well as functions called from the function calling capabilities of the model.

Tool and API dependencies

Agentic agents often rely on external tools, APIs or plugins to complete tasks. These dependencies may change independently of the agent itself, which will create versioning challenges around compatibility, observability and rollback. A minor API update could significantly alter an agent’s behavior, even if the agent’s core logic remains unchanged.

Multi-agent coordination

In many enterprise scenarios, agents do not operate in isolation. Multi-agent systems collaborate, delegate and orchestrate tasks across a network of other agents. Versioning in this context must account for inter-agent dependencies and inter-agent communication, ensuring that updates to one agent do not break the behavior of the collective group of agents. We need to be thinking about whether all the agents for the solution are getting updated as a group or individually. We also need to consider which team in the organization owns the agents, if they are being shared across the enterprise. Will the new version of the shared agent interfere with other systems calling those agents?

Behavioral drift and emergence

Because agentic systems are non-deterministic and adaptive, their behavior can drift over time. This makes it difficult to define a “version” purely in terms of code or configuration. Instead, versioning must include behavioral baselines, test trajectories and performance metrics that reflect how the agent behaves in everyday activities. You need to include automated tests for evaluations, performance and comparison to baselines to identify any drift.

Now that we have covered the ways that versioning agents are different than traditional versioning, we can look at strategies that can be implemented.

Strategies for agent versioning

Versioning agentic AI agents requires more than tagging releases with a version number. It requires a thoughtful approach to managing behavioral evolution, memory and orchestration logic. The items below are strategies that organizations can adopt to ensure safe, traceable and scalable agent versioning.

Immutable agents. Freezing agents at deployment for auditability and rollback. This strategy has you treat each deployed agent as immutable. Once released, it cannot be altered. This guarantees that behavior can be traced and reproduced as it occurred and works in environments where regulatory or compliance is required, with the ability for reproducibility and auditability.
Semantic versioning for agents. Applying major/minor/patch logic to behavioral and architectural changes. This provides a consistent framework to communicate the scope and impact of any changes. It also allows consumers of the agent to understand the scope and impact of any changes as they incorporate the agent into their solution. This provides the ability to track compatibility of agents with tools and their versions, as well as track each version to a risk level, test coverage and known limitations. This metadata should be stored in an agent registry and linked to the deployment pipeline.
Forking and branching. Create forks of agents for experimentation, A/B testing or domain-specific adaptations. This enables experimentation and parallel development of agent variants without disrupting production agents. The forking strategy provides an additional benefit of splitting agent usage for different customer segments or business units, such as V1.1 enterprise and V1.1 retail.
Shadow agents. This strategy has you deploy a new agent version in a shadow mode alongside the production agent in order to observe the new agent version’s behavior without affecting any outcomes. This reduces risks by validating changes in a live environment and running the new versions in parallel for A/B testing and safety validation.
Rollback protocols. Create a process to revert to a known-good state if the new version introduces a regression or compliance issue. This is designed for graceful degradation and recovery for continuity in business-critical solutions.

Putting these strategies into place requires tooling for implementation and automation. The tools need to extend beyond the traditional deployment pipelines. Tooling must also support traceability, observability and governance at every stage of the lifecycle. The tools below focus on three areas: agent registries, CI/CD for agents and observability.

Tooling infrastructure

Implement an agent registry. This is a centralized registry that acts as the source of truth for all agents, their purpose, version, limitations and more. Registries also help enable traceability and facilitate collaboration across teams. There are several agent registries, but here are two options for those who want something turnkey or a custom implementation.

Azure AI Foundry. This provides a framework for building and managing an agentic AI system and includes many tools, including an agent registry that supports dynamic discovery, version control and policy enforcement, as well as integration with MCP endpoints and interfaces, along with governance integration.
Build your own implementation using a FastAPI-based agent registry server. This implementation uses FastAPI, which allows teams to build custom agent registries utilizing agent-to-agent (A2A) discovery and collaboration. This process utilizes the A2A agent cards that describe agent capabilities.

Incorporate tooling to create and automate CI/CD pipelines for the agents. These pipelines must be adapted for an agentic system and need to provide automated testing of agent behavior, validating toolchain compatibility and API dependencies, provide a controlled rollout mechanism (such as shadow agents or canary deployments), and must integrate with observability and rollback processes you put in place. Listed are three tools that provide these capabilities.

Azure DevOps Pipelines. Azure DevOps pipelines support agent pools and build orchestration for scalable deployments. Managed identity integration as well as the ability to treat the pipelines configuration and settings as Infrastructure-as-Code (IaC) with support for Terraform, Bicep and ARM templates, allowing you to check the code into your code repositories.
GitHub Actions. GitHub Actions are very useful for agentic workflows that include native support for containerized deployments using Docker and integration with Kubernetes for scalable agent hosting. It also provides version control of prompts, model configuration and dependencies as part of the CI/CD flow.
Jenkins. Jenkins is also a flexible platform that provides custom pipeline scripting as well as integration with legacy systems and uses a plug-in-based extensibility for AI-specific workflows.

Place observability and telemetry capabilities everywhere. Monitoring the agent behavior across versions is essential to detect drift, regression and any emergent risks. The system should monitor real-time telemetry on agent decisions, tool usage, performance metrics, as well as compare versions to the behavioral baseline and provide alerts and anomaly detection.

Azure Monitor and AI Foundry Observability. Azure Monitor provides the core telemetry backend while AI Foundry provides a scenario-optimized dashboard for both generative AI and agentic workloads. OpenTelemetry is also supported. The combination of these services enables unified tracing, cost tracking and safety evaluations across agent runs.
Langfuse. Langfuse is a specialized observability tool for LLM-based agents that track performance, cost, user interaction and decision traces. It integrates with frameworks like LangChain & LangGraph, Flowise and OpenAI agents.

As with any activity, we measure where we currently are and put a plan together for further growth. The tools listed above will help you on that path. As you evaluate where you are and where you want to go, it can be helpful to utilize a maturity model.

A maturity model for agent versioning

Many AI maturity models have been created, and I encourage you to evaluate those. However, as you plan your agentic implementations, you will want something focused specifically on agent versioning. This section is specifically focused on versioning. In the previous section, I mentioned that some strategies will overlap, and you may implement aspects over time. Every organization will adapt as it continues to implement agentic AI, and the versioning practices will evolve through distinct stages of maturity. This model will help you and your technical leaders assess where you are today and what capabilities are needed next to ensure safe, scalable and purpose-built agent lifecycle management.

Level	Stage	Characteristics	Risks	Next Steps
1	Ad Hoc	Agents are deployed without formal versioning. Updates are manual and commonly undocumented.	High risk of regressions, compliance gaps and lack of traceability.	Establish basic versioning policies and agent registries.
2	Scripted	Versioning is partially automated via scripts or through manual tagging.	Limited rollback capability and inconsistent metadata.	Introduce semantic versioning and behavioral snapshots.
3	Managed	CI/CD pipelines support agent versioning. Metadata, memory and dependencies tracked.	Improved reliability, but limited support for behavioral drift or orchestration.	Integrate observability and governance guardrails.
4	Autonomous Governance	Agents participate in their own lifecycle management (e.g., self-versioning proposals).	Requires robust oversight to prevent unintended evolution.	Implement policy engines, human-in-the-loop controls and risk-aware routing.

As you use this model, assess your current practices across agent types and business units. Align versioning maturity with the criticality and autonomy of each agent. Advance through the model incrementally by investing in tooling, governance and cross-functional collaboration. Also realize that you may not need to level in all your agentic solutions. Different teams and implementations may adhere to different levels of maturity, and you may decide going beyond level 3 doesn’t provide the business value. Therefore, getting to a level where agentic solutions need to have agents participating in their own lifecycle management may be reserved for select teams or implementations.

In following the maturity model, guidance and practices consistently, your AI agents will move from “usually works” to “never breaks.” When regressions occur, you’ll instantly know where, why and how to fix them with one-click rollbacks ready and waiting.

10 recommendations for CIOs

As Agentic AI agents become integral to enterprise operations, CIOs must lead the charge in establishing robust versioning practices that balance innovation with governance. I have listed below a set of strategic recommendations to guide CIOs in shaping agent versioning policies and activities:

1. Treat agent versioning as a first-class discipline

Elevate agent versioning to the same level of importance as software release management and model lifecycle governance.
Establish dedicated policies and frameworks for agent versioning that span development, deployment and retirement.
Version everything, including training code, test cases, configuration and dependencies together

2. Define clear versioning boundaries

Clarify what constitutes a new version: changes in behavior or new features, memory, toolchain or environment.
Be careful to avoid ambiguous versioning by enforcing semantic versioning standards tailored to each agentic system.

3. Invest in agent registries and metadata management

Implement centralized registries to track agent versions, lineage, dependencies and governance metadata.
Ensure each version and each agent includes audit trails, approval records and risk classifications.

4. Enable safe experimentation through forking and shadowing

Support parallel development of agent variants via branching and forking strategies.
Use shadow agents to validate new behaviors in production environments without impacting outcomes.
Perform unit tests systematically for targeted improvements and integration tests regularly to maintain end-to-end integrity.

5. Build rollback-ready infrastructure

Maintain rollback snapshots that include behavioral logic, memory state and tool configurations.
Automate rollback protocols to ensure resilience in case of regressions or compliance violations.
Establish rollback triggers and rules that include rollback thresholds based on business and technical KPI’s.

6. Align versioning with risk and compliance

Classify agent versions by risk level and apply version-aware guardrails.
Ensure that high-risk agents undergo rigorous testing and human-in-the-loop oversight before deployment.

7. Monitor behavioral drift and performance across versions

Deploy observability pipelines to detect drift, regressions and non-expected behaviors.
Use telemetry to compare agent performance across versions and quantify deployment to automate approval through metrics collected.
Ensure that you are preventing log contamination by including the agent version in logs to understand which version produced which response.

8. Prepare for any regulatory scrutiny

Align versioning practices with emerging AI regulations (e.g., EU AI Act, industry-specific standards).
Maintain documentation and behavioral baselines to demonstrate compliance and readiness.

9. Foster cross-functional collaboration

Engage stakeholders from engineering, compliance, product and legal teams in versioning governance.
Promote shared understanding of agent capabilities, risks and lifecycle responsibilities.
Embrace resilience and celebrate deployments, near misses and continual learning.

10. Transitioning to your deployment environment

Deploy through a multi-layered environment strategy that includes a ring deployment model consisting of:
- An inner ring to test the deployment and behavior of the new version.
- A middle ring that includes trusted users to exercise the solution with real-world data and processes to ensure the solution behaves correctly before turning the solution over to the full user base.
- An outer ring that consists of the full rollout continuing with monitoring, continual testing and comparing to baseline functionality.
Lastly, keep the previous deployment active for a duration if you need to perform a quick revert. Or keep automated rollback triggers active for redeployment, if needed, after the previous deployment is removed.

Agent versioning is a must-have, not a nice-to-have

Agentic AI agents represent a transformative shift in enterprise technology, and as agentic AI agents become more autonomous, adaptive and embedded in enterprise workflows, versioning emerges as a cornerstone of responsible innovation. Unlike traditional software or static models, agentic systems evolve through interaction, memory and orchestration, making their lifecycle management uniquely complex and critically important.

Effective versioning is not just about tracking changes; it’s about ensuring continuity, accountability and trust. From defining agent identity and behavioral snapshots to implementing rollback protocols and governance guardrails, organizations must adopt multidimensional strategies that reflect the dynamic nature of these systems. Versioning and rollbacks are must-haves in your environment, not nice-to-haves.

For CIOs and technical leaders, the path forward is clear: treat agent versioning as a first-class discipline, invest in the strategies to support it and align practices with business goals. By doing so, enterprises can unlock the full potential of agentic AI and be confident that every version is not only better but safer.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Harnessing GitOps on Linux for Seamless, Git-First Infrastructure Management

Sat, 06 Sep 2025 23:36:32 +0200

by George Whittaker

Introduction

Imagine a world where every server, application, and network configuration is meticulously orchestrated via Git, where updates, audits, and recoveries happen with a single commit. This is the realm GitOps unlocks, especially potent when paired with the versatility of Linux environments. In this article, we'll dive deep into how Git-driven workflows can transform the way you manage Linux infrastructure, offering clarity, control, and confidence in every change.

GitOps Demystified: A New Infrastructure Paradigm

GitOps isn't just a catchy buzzword, it's a methodical rethink of how infrastructure should be managed.

It treats Git as the definitive blueprint for your live systems, everything from server settings to application deployments is declared, versioned, and stored in repositories.
With Git as the single source of truth, every adjustment is tracked, reversible, and auditable, turning ops into a transparent, code-centric process.
Beyond simple CI/CD, GitOps introduces a continuous reconciliation model: specialized agents continuously compare the actual state of systems against the desired state in Git and correct any discrepancies automatically.

Why Linux and GitOps Are a Natural Pair

Linux stands at the heart of infrastructure, servers, containers, edge systems, you name it. When GitOps is layered onto that:

You'll leverage Linux’s scripting capabilities (like bash) to craft powerful, domain-specific automation that dovetails perfectly with GitOps agents.
The transparency of Git coupled with Linux’s flexible architecture simplifies debugging, auditing, and recovery.
The combination gives infrastructure teams the agility to iterate faster while keeping control rigorous and secure.

Architecting GitOps Pipelines for Linux Environments

Structuring Repositories Deliberately

A well-organized Git setup is crucial:

Use separate repositories or disciplined directory structures for:
- Infrastructure modules (e.g., Terraform, networking, VMs),
- Platform components (monitoring, ingress controllers, certificates),
- Application-level configurations (Helm overrides, container versions).
This separation helps ensure access controls align with responsibilities and limits risks from misconfiguration or accidental cross-impact.

Go to Full Article

Deploy Amazon Bedrock Knowledge Bases using Terraform for RAG-based generative AI applications

Sat, 06 Sep 2025 23:35:29 +0200

In this post, we demonstrated how to automate the deployment of Amazon Knowledge Bases for RAG applications using Terraform.

Plan B: Terraform Review (PC)

Sat, 06 Sep 2025 23:33:06 +0200

The transport question is becoming a little too complex for my liking. Trains are clearly superior to trucks, but they still move from one point to another, with no way to place any intermediate stops and no commands to keep the flow just right across long distances. Moving large quantities of anything, from basic concrete and iron bars to complex nano tubes, requires multiple connections and careful use of the depots that move everything across short distances. The long-term plan is to re-create the optimal conditions for life present on Earth. That involves releasing enough water to have oceans and developing forests so that animals get to run around. The short-term plan is to create an atmosphere and make sure that our three cities keep growing by getting all the resources the citizens are demanding from the conveniently placed supply hubs. With the game set to the lowest speed, I get to work re-making the most transportation routes that lead from manufacturing ...

Plan B: Terraform: Mischung aus Surviving Mars und Factorio geht in Version 1.0

Mon, 25 Aug 2025 17:30:42 +0200

Nach rund zweieinhalb Jahren verlässt Plan B: Terraform den Early Access. Ab dem 29. August 2025 ist Version 1.0 auf Steam verfügbar. Entwickelt wird der Titel von Nicolas Gadenne alias Gaddy Games aus Frankreich. Das Konzept: Spieler sollen einen kargen roten Planeten Schritt für Schritt in eine bewohnbare Welt verwandeln.

CVE-2025-2180 | Palo Alto Checkov by Prisma Cloud prior 3.2.415 Terraform File deserialization (WID-SEC-2025-1821)

Sun, 17 Aug 2025 20:05:47 +0200

A vulnerability identified as critical has been detected in Palo Alto Checkov by Prisma Cloud. This vulnerability affects unknown code of the component Terraform File Handler. The manipulation leads to deserialization. This vulnerability was named CVE-2025-2180. The attack can be initiated remotely. There is no exploit available. It is recommended to upgrade the affected component.

Mittwoch: McDonald's-Verschwendung wegen Pokémon, Perplexity-Interesse an Chrome

Wed, 13 Aug 2025 06:45:41 +0200

Missglückte Pokémon-Aktion in Japan + Milliarden-Angebot für Google-Browser + Terraform-Gründer bekennt Schuld + Übernahme bei Lieferdiensten + Bit-Rauschen

Crypto crasher Do Kwon admits guilt over failed not-so-stablecoin that erased $41 billion

Wed, 13 Aug 2025 04:48:34 +0200

Tells court 'What I did was wrong and I want to apologize for my conduct'

Terraform Labs founder Do Kwon has pled guilty to committing fraud when promoting the so-called "stablecoin" Terra USD and now faces time in jail.…

Do Kwon Pleads Guilty to US Fraud Charges In $40 Billion Crypto Collapse

Wed, 13 Aug 2025 03:03:36 +0200

Terraform Labs founder Do Kwon pleaded guilty in U.S. federal court to conspiracy to defraud and wire fraud over the $40 billion collapse of TerraUSD and Luna in 2022. Reuters reports: Kwon, 33, who co-founded Singapore-based Terraform Labs and developed the TerraUSD and Luna currencies, entered the plea at a court hearing in New York before U.S. District Judge Paul Engelmayer. He had pleaded not guilty in January to a nine-count indictment charging him with securities fraud, wire fraud, commodities fraud and money laundering conspiracy. Accused of misleading investors in 2021 about TerraUSD - a so-called stablecoin designed to maintain a value of $1 - Kwon pleaded guilty to the two counts under an agreement with the Manhattan U.S. Attorney's office, which brought the charges. He faces up to 25 years in prison when Engelmayer sentences him on December 11, though prosecutor Kimberly Ravener said the government had agreed to advocate for a prison term of no more than 12 years provided he accepts responsibility for his crimes. "I made false and misleading statements about why it regained its peg by failing to disclose a trading firm's role in restoring that peg," Kwon said in court. "What I did was wrong."

Read more of this story at Slashdot.

Stablecoin Terra: CEO Do Kwon trifft Vereinbarung mit US-Justiz

Tue, 12 Aug 2025 21:00:47 +0200

Terraform-Mitgründer Do Kwon drohen nach dem Milliarden-Crash von Terra/Luna und einem Handel mit dem Staatsanwalt wohl nur noch zwölf Jahre Haft.

Buyer’s guide: Top 20 cloud cost management tools — and how to choose

Thu, 07 Aug 2025 12:18:45 +0200

Cloud cost management tools explained

For years, the story has been the same: The cloud is cheaper than DIY. Then the bills come. The price tags are denominated in pennies, but by the end of the month all those pennies add up. Often to sums that give the CFOs a heart attack. Cloud cost management tools are an answer.

Cloud cost management is a business discipline aimed at monitoring, analyzing, and optimizing an organization’s cloud computing spend. It gives organizations greater visibility into how cloud resources are being used and can also help identify and maybe eliminate unused or overprovisioned services. When usage is stable, they will predict future cloud costs to provide more fine-tuned forecast budgets.

Cloud cost management tools aid organizations in this practice by tracking all the bills associated with an organization’s deployments, allocating them to the various teams responsible for their accumulation. That way the group that added too many fancy features that need too much storage and server time will have to account for their profligacy. The good programmers who don’t use too much RAM and disk space can be rewarded.

[ Download our editors’ PDF cloud cost management tools buyer’s guide today! ]

What to look for in cloud cost management tools

Smaller teams with simple configurations can probably get by with the stock cloud cost management services provided by their cloud vendor of choice. Cost containment is a big issue for many CIOs now and the cloud companies know it. They’ve started adding better accounting tools and alarms that are triggered before the bills reach the stratosphere. See Azure Cost Management, Google Cloud Cost Management, and AWS Cloud Financial Management tools for the big three clouds.

Once your cloud commitment gets bigger or maybe spread between several vendors’ clouds, stand-alone cost management tools start to become attractive. They’re designed to work with multiple clouds and build reports that unify the data for easy consumption. Some even track the machines that run on premises so you can compare the cost of renting versus building out your own server room.

A big role can be allocating costs to specific projects or business units. Good tools will let you tag or label collections of machines so the bill can be split up accurately. Then the business units can defend their spending.

In many cases, cloud cost managers are part of a larger suite designed to not just watch the bottom line but also enforce other rules such as security or governance. Some are not marketed directly as cloud control tools but have grown to help solve this problem. Some tools for surveying enterprise architectures or managing software governance now track costs at the same time. They can offer the same opportunities for savings that purpose-built cloud cost tools do — and they help with other management chores as well.

Can AI make a difference?

AI is everywhere and it’s no surprise that cloud management companies are incorporating new features into their stack. Their value depends on your workflow. If the goal is to build a big table with all the machines and daily charges, there’s no need for large language models (LLMs) or any of the modern solutions.

But some vendors use the term AI to include more sophisticated algorithms for tasks such as predicting future usage. These can look at past performance and adjust hardware allocations in advance. They can also offer financial forecasts so the CFO will know what bills will look like in advance. Is that true artificial intelligence or just a clever statistical algorithm? It doesn’t matter once it’s running successfully.

A few vendors are using LLMs to enable users to ask open-ended questions about their data. These approaches may be useful for nontechnical users or teams exploring new ways to analyze their cloud costs.

Leading vendors for cloud cost management tools

Cloud cost management tools come in a wide variety, from components in broader cloud platforms to standalone tools. CIOs should check with their existing cloud providers such as Amazon Web Services, Google, and Microsoft to see what cost management capabilities they offer. But be sure to also look at independent tools because, after all, it’s not much in cloud providers’ interests for you to spend less on their platforms.

What follows is an alphabetical list of the best cloud cost tracking and analysis tools. The market is rapidly expanding as enterprise managers recognize the need to get a grip on their cloud spend. All these tools can help govern the burgeoning empire of server instances that your organization relies on for its cloud operations, which may stretch around the world.

CAST AI: DevOps teams tasked with managing Kubernetes clusters can turn to CAST AI for a collection of tools that optimize usage across multiple clouds, hybrid deployments, and on-prem architectures. The endless cycle of capacity prediction and node allocation is handled by the product so that the clusters grow and shrink as needed. Integration with other essential tools like Terraform, Grafana, Prometheus, and Jira help DevOps teams ensure that the clusters are performing optimally. Its standout features include:

Kubernetes users get a tool aimed at delivering smooth support for containers
Integration with other popular tools provides for a simple but powerful workflows

CloudAdmin: Dashboards created by CloudAdmin are simple and direct. The tool tracks cloud usage and offers suggestions for rightsizing your servers or converting them to reserved instances. Server instances can be allocated to teams and then tracked with a budget. If spending crosses a defined line, alerts are integrated with email or other common communication tools to notify personnel of the need for attention. Its standout features include:

Carefully filtered data feeds extract the key details about spending to save time wading through too much information
Automated alerts can stop runaway spending when it crosses thresholds

CloudZero: The platform from CloudZero was designed from the beginning to make it easy to compare cloud costs to business metrics. That is not just tabulating the costs per machine, but connecting those costs to the business operations by computing values such as cost per customer or cost per feature. Providing granular insights enables business decisions about feature sets or services rendered to be made mathematically instead of emotionally. Its standout features include:

Anomaly detection for moments when key metrics diverge
Automatic cost allocation and normalization to simplify comparisons

Datadog: Watching over cloud machines, networks, serverless platforms, and other applications is the first job for Datadog’s collection of tools. Tracking cloud costs is just one part of the workload that also includes network monitoring and security. Its telemetry gathers data about performance and cost, and Datadog builds this into a sophisticated dashboard to help organizations understand both application cost and performance. Its standout features include:

Broad suite for infrastructure monitoring across multiple clouds
Monitoring of not just spending but all tasks for responsible cloud curation

Densify: Densify wants to help DevOps teams manage Kubernetes clusters juggling containers and VMware instances. The best way to run your clusters, according to Densify, is to keep precise, meticulous records of load and then use this data to scale up and down quickly. Densify’s optimizers focus on containers, pods, deployments, ReplicaSets, nodes, node groups up to full clusters. Careful attention to deployment improves scaling by 50% or more. Densify’s FinOps tool generates extensive reports to help keep application developers and bean counters happy. Its standout features include:

A focus on container-level deployment provides direct control over the resource usage that leads to cost savings
Reporting identifies cost problems and gamifies savings identification

Finout: The center of the Finout experience is one feature called “Megabill,” a single dashboard that tabulates all the costs, past and future, to produce a bottom-line number. The tool consolidates costs across the major clouds and offers virtual tagging to track operational subsets. The tool’s waste detection is said to be “codeless,” and it watches over the deployments and generates Jira tickets when overspending appears. Its standout features include:

Costguard tracks spending and identifies opportunities for saving
Integrations with major platforms such as Databricks, Datadog, Snowflake, and soon Confluent provide long-term record keeping

Flexera One: The Flexera One cloud management suite tackles many cloud management tasks, such as tracking assets, managing licenses, and organizing governance to orchestrate control. An important section of the suite is devoted to controlling the budget. The tool offers multicloud accounting for tracking spending with elaborate reporting broken down by team and project. Flexera One also offers suggestions for optimizing consumption by targeting wasteful allocations, and it provides automated systems to put these observations into practice. The tool is not just focused on cloud hardware but also license costs and audit defense. Its standout features include:

Integrates cost tracking across hardware and services to support all levels of management
Supports larger management roles like audit defense

Flexera Spot: Teams working on planning resources for AI workflow can turn to Flexera’s Spot to optimize usage of often costly GPU hardware. At the core of the Spot stack is a set of tools like CloudCheckr, a product that focuses on controlling cloud costs and security and Spot Eco, a tool that will optimize deployment. The stack will constantly balance usage demands with the price for both reserved instances and spot machines. Its RI Marketplace, for instance, will constantly look for extra machines available at bargain prices. Its standout features include:

Monitor compliance with privacy regulations by tracking security configuration
Right-size reserved instances by tracking baseline consumption

Harness: The AI-managed platform orchestrates deployment across multiple clouds and Kubernetes clusters by tracking usage and executing on the plans to minimize unneeded consumption. The long-term commitment manager balances the cost-savings of reserved instances with the ability to terminate unneeded spot instances. Harness’s cost management features watch for anomalies compared to historic spending, generating alerts for teams. The platform also manages governance and access policies to maximize security. The tight integration with the CI/CD pipelines makes development teams full partners in long-term management. Its standout features include:

Deep integration with the development pipeline to make cost savings part of the software creation process
New features such as Database DevOps and an Artifact registry prompt long-term integration with development workflows

IBM Cloudability: Big Blue’s Apptio subsidiary makes a large collection of tools for managing IT shops, and Cloudability is its tool for handling cloud costs. The tool breaks down the various cloud instances in use, allocating them to your teams for accounting purposes. Ideally, teams can control their own costs and predict future usage with the reports and dashboards. Cloudability wants to nurture collaborative response by opening data to managers, accountants, and developers. Integration with other tools such as IBM Kubecost help ensure the clusters minimize their budget. Integration with many other tools such as Jira and PagerDuty help speed response to spending anomalies. Its standout features include:

Planning future purchasing of reserved instances to lock in savings for the constant demand
Focus on cost management balances labor with product feature set

IBM Kubecost: Teams that rely on Kubernetes to deploy pods of containers can install Kubecost to track spending. It will work across all major (and minor) clouds as well as pods hosted on premises. Costs are tracked as Kubernetes adjusts to handle loads and are presented in a unified set of reports. Large jumps or unexpected deployments can trigger alerts for human intervention. Its standout features include:

Optimized for tracking how Kubernetes deployments affect costs
Dynamic recommendations track opportunities for lowering spending

IBM Turbonomic: IBM uses Turbonomic to deliver an AI-powered solution for managing deployment to match application demand with infrastructure. The tool will automatically start, stop, and move applications in response to demand. The data driving these decisions is stored in a warehouse to train the AI that will be making future decisions. All these changes and predictions for future usage are reported on dashboards for all stakeholders. Its standout features include:

Full-stack integrated graphics to understand demand and cost across an application
Designed to automate resource allocation to save engineering teams from the chore

nOps: The nOps platform has three major roles (inform, operate, optimize) and mainly works with AWS and its forms of resource allocation. Granular data about usage is collected and displayed as dashboards or reports by the features under the “inform” umbrella. Details about day-to-day use such as data of business unit economics or anomaly detection are gathered under the “operate” umbrella. Finally, the real value for the platform comes when the “optimize” features balance the long-term commitment for reserved instances with the savings that can come from the spot market. The automated commitment algorithms can ensure that there’s little waste from locking in a commitment. Its standout features include:

A focus on AWS ensures that the algorithms are tuned for that cloud’s idiosyncrasies
ML-driven optimization routines ensure close to complete utilization

Nutanix: Organizations with large multicloud deployments can use Nutanix as an abstraction layer to deploy apps. While much of the layer handles chores such as storage or resource management, one part called Cost Governance (formerly Beam) tracks costs across a range of installations, including private cloud machines hosted on premises. The tool can be customized to generate accurate cost estimates of private installations by accounting for heating and cooling costs, hardware, and data center rent. This makes it easier to make accurate decisions about allocating workloads to the lowest-cost deployment. The process can be automated to optimize and rightsize hardware to simplify management. Its standout features include:

Metering of private clouds builds direct insight into the costs of on-premises hardware
Budget alerting and dynamic optimization help rightsize consumption to minimize costs

ServiceNow: Teams running extensive collections of microservices rely on ServiceNow to manage some or even all the stack through its constellation of products such as AppEngine or Integration Hub. Many of the tools are customer-facing solutions like IT automation, but there are more backend tools for optimizing IT operations by intelligently managing performance. It offers several dashboards that offer a high-level view of costs and a detailed breakdown. The Cloud Spend Analytics tracks past performance and offers forecasts for future budgets. Its standout features include:

Broad selection of tools for tracking and optimizing IT assets
Risk management well integrated with governance tools

Splunk AppDynamics: Tracking and reining in containers across a multicloud, hybrid, and on-prem environment is the goal for AppDynamics. It was formerly known as Replex and is now part of the Splunk Observability Portfolio. The cost management job is just one part of a larger system that tracks performance and log files looking for anomalies and making predictions for the future. Splunk’s AIOps, for instance, can watch for security violations and overspending. A policy control layer offers granular restrictions to ensure teams have access to what they need but are locked out of what they don’t. Its standout features include:

Integrates cost management with general application monitoring
Integrated with Open Telemetry as part of a goal of unifying data across local, on-prem machines with a multicloud environment

Umbrella (formerly Anodot): The first job for Umbrella’s collection of cloud monitoring tools is to track the flow of data through the various services and applications. If there’s an anomaly or hiccup that will affect users, it will raise a flag. Umbrella deploys a machine learning algorithm that compares the current spending to the past so that unusual spending spikes stand out. Tracking the cost of instances and pods across your multiple clouds is part of this larger job. The dashboard produces a collection of infographics that make it possible to study each microservice or API and determine just how much it costs to keep it running in times of high demand and low. This granular detail gives you the ability to spot the expensive workloads and find a way to prune them. Its standout features include:

Integrated multicloud analytics provides normalized and actionable data for both detecting unusual spending while also providing accurate planning for regular deployments
A generative AI called COST GPT offers an opportunity to dive into spending data and explore it with a natural language interface.

VMware Aria CloudHealth: VMware, the Broadcom subsidiary, built Tanzu CloudHealth (formerly called Aria Cost and Aria Automation) to manage deployments across all major cloud platforms as well as hybrid clouds. The cost accounting module tracks spending, allocating it to business teams while optimizing deployments to minimize costs. The modeling layer can build out amortization and consumption schedules to forecast future demand. Financial managers and development teams can drill down into these forecasts to focus on specific applications or constellations of services. The larger product line integrates the cost management with automated deployment and security enforcement. Its standout features include:

Spending governance ensures that teams are following individual budgets for resource consumption
Integrate cloud costs with business metrics and key performance indicators to understand the connection between computational costs and the bottom line

Yotascale: Much of the responsibility for cloud costs comes from the engineers who write and deploy the code. They make the granular decisions to startup more instances and store more data. Yotascale wants to put more information in their hands to enable them to optimize their hardware consumption with tools designed to track machines and allocate their costs directly to the teams responsible. The forecasting tools can also spot anomalies, raising alerts to prevent any surprise bills at the end of the month. The dashboards promise to replace static spreadsheets with dynamic, responsive and accurate “single pane of glass.” Its standout features include:

Engineer-targeted tools deliver budget information directly to the teams building the software and starting up the machines
Automated tracking delivers forecasts and flags problems and overconsumption

Zesty: While many cloud managers offer insights through sophisticated reports, Zesty is designed to automate the work of spinning up and shutting down extra instances. A key feature enables it to watch the reserved market for deeply discounted instances with excess capacity on the cloud. It offers a tool informed by artificial intelligence algorithms that can work with AWS’s API to make decisions that keep just enough machines running to satisfy users without breaking the budget. The tool can even control the amount of disk space allocated to individual machines while buying and selling processor time on the spot from reserved instance marketplaces. Its standout features include:

Deep management of details such as storage space allocation to minimize costs
Integration with the spot market to take advantage of the lowest possible costs

Essential reading

Anzeige: Cloudinfrastrukturen automatisieren mit Terraform

Wed, 30 Jul 2025 18:15:51 +0200

Dieser Workshop vermittelt, wie Cloudumgebungen mit Terraform automatisiert werden - mit Fokus auf Openstack und übertragbaren Konzepten für AWS, Azure und GCP. (Golem Karrierewelt, Cloud Computing)

Multi-cloud migration startup FluidCloud emerges from stealth

Tue, 29 Jul 2025 16:48:43 +0200

Infrastructure-as-Code (IaC) tools have been used by IT professionals for over a decade to help define and deploy cloud infrastructure.

The promise of IaC is that infrastructure can be declaratively defined in code, enabling an organization to deploy the same infrastructure again and again. In the modern cloud world, however, the complexity of different cloud providers’ services has made it difficult to define infrastructure in a way that’s portable across providers. It’s a challenge that new startup FluidCloud is aiming to solve. The company is launching out of stealth today with $8.1 million in seed funding led by Unusual Ventures.

“We’re actually translating the infrastructure as code from one dialect on one cloud, and being able to port it and transform it into a dialect of another cloud,” James Bayer, co-founder and CPO of FluidCloud, explained to Network World.

Where existing IaC tools fell short

The startup’s genesis came from real-world frustrations.

Bayer had previously been at IaC pioneer Hashicorp, which was acquired by IBM for $6.4 billion earlier this year. Bayer recounted that after Hashicorp completed an acquisition in 2023, it took time and money before they were able to port the technology from Google to AWS.

“We spent tens of millions of dollars on an acquisition, and we couldn’t sell it for six months because we had to wait for porting to happen,” Bayer said.

Harshit Omar, co-founder and CTO of FluidCloud, said that while IaC is widely adopted, every cloud provider has its own rules about how things can be deployed. “The way you work and deploy things in AWS, the way you deploy things in Azure, that is totally different,” Omar said.

Patented algorithm solves factorial scaling challenge

Cross-cloud infrastructure mapping traditionally creates what Bayer referred to as factorial complexity.

Each cloud provider requires unique translation paths to every other provider. Six clouds demand 30 distinct mappings. Adding a seventh cloud requires six additional translation paths.

FluidCloud developed a patented approach that converts factorial scaling into linear complexity. The system creates universal intermediate representations that translate to any supported cloud dialect. The platform currently supports AWS, Azure, GCP, VMware, Vultr and Nutanix with additional providers under development.

FluidCloud’s discovery system calls cloud APIs directly to inventory existing infrastructure across all supported platforms. The engine can scan 50,000 resources in 15 seconds compared to hours required by competing tools that perform similar functions, FluidCloud asserts.

Real-time translation preserves network architecture

FluidCloud’s core engine translates infrastructure between cloud-specific resource dialects while maintaining network topology and security relationships.

In a demo, Bayer showed how the FluidCloud system was able to map an AWS to Vultr translation, converting EC2 instances, VPCs and security groups. The translation system handles complex resource mappings automatically. AWS t3.small instances become equivalent Vultr compute configurations based on CPU and memory specifications. Security groups translate to firewall rules with identical port protocols and source restrictions.

Network isolation transfers intact across cloud boundaries. Private address ranges and security group rules permitting port 5000 access replicated precisely from AWS to Vultr during the demo as well.

It’s important to note that FluidCloud is not actually building its own IaC technology; rather it is using existing technology, specifically Hashicorp Terraform.

“We are using Terraform as the lingua franca of DevOps. We are not trying to introduce our own proprietary language,” Bayer said. “What we do have is proprietary capabilities of translations for TerraForm.”

AI integration extends platform capabilities

Future development includes AI-powered automation agents for failover scenarios and outage response.

The team also will be working on a multi-cloud MCP (Model Context Protocol) server providing natural language infrastructure management across providers. The multi-cloud MCP server will differentiate from single-provider solutions by offering cross-cloud capabilities through natural language interfaces.

The big source of traction for the company, at least initially, is expected to come from existing VMware users.

“Our core focus is the desperate buyers, which are primarily the VMware customers, which are planning to come out of VMware and trying to move to other cloud providers,” Sharad Kumar, co-founder and CEO of FluidCloud, said.

VCF 9.0 for Edge: Automating App Deployment at Scale with GitOps using Argo CD

Tue, 29 Jul 2025 13:30:09 +0200

Manually deploying applications at scale especially across distributed edge sites can be time consuming, prone to manual error and difficult to standardize. Traditional automation tools like Terraform or Ansible help reduce manual effort. However, they often require coordinating updates in batches, scheduling change windows, and managing state from a central location. GitOps with VCF Edge … Continued

The post VCF 9.0 for Edge: Automating App Deployment at Scale with GitOps using Argo CD appeared first on VMware Cloud Foundation (VCF) Blog.

End-to-End AWS RDS Setup with Bastion Host Using Terraform

Mon, 28 Jul 2025 17:35:02 +0200

Learn how to automate secure AWS infrastructure using Terraform — including VPC, public/private subnets, a MySQL RDS database, and a Bastion host for secure access.

The post End-to-End AWS RDS Setup with Bastion Host Using Terraform appeared first on Towards Data Science.

Anzeige: Cloudinfrastrukturen automatisieren mit Terraform

Wed, 23 Jul 2025 07:15:34 +0200

Build an AI-powered automated summarization system with Amazon Bedrock and Amazon Transcribe using Terraform

Mon, 21 Jul 2025 19:34:49 +0200

This post introduces a serverless meeting summarization system that harnesses the advanced capabilities of Amazon Bedrock and Amazon Transcribe to transform audio recordings into concise, structured, and actionable summaries. By automating this process, organizations can reclaim countless hours while making sure key insights, action items, and decisions are systematically captured and made accessible to stakeholders.

Dedicated Server einfach erklärt

Wed, 16 Jul 2025 14:51:06 +0200

Dedicated Server gelten als leistungsstarke Hosting-Lösung für anspruchsvolle Anwendungen. Doch was ist ein dedizierter Server eigentlich und worin unterscheidet er sich von anderen Server-Modellen? In diesem Artikel erfahren Sie, wie ein dedizierter Server funktioniert, welche Vorteile er bietet und für wen sich der Einsatz lohnt. Außerdem werfen wir einen Blick auf typische Anwendungsbereiche, technische Merkmale und sinnvolle Alternativen.

Anzeige: Cloud-Infrastrukturen mit Terraform automatisieren

Mon, 14 Jul 2025 18:15:28 +0200

Terraform zur Skalierung und Verwaltung von Cloud-Infrastrukturen nutzen? Dieser Workshop bietet praxisnahe Einblicke in die Integration und Automatisierung mit Openstack. (Golem Karrierewelt, Cloud Computing)

Anzeige: Cloud-Infrastrukturen mit Terraform automatisieren

Thu, 03 Jul 2025 07:15:48 +0200

TD Synnex vertreibt IBMs Hashicorp-Lösungen in der DACH-Region | IT-Markt

Fri, 27 Jun 2025 19:03:51 +0200

Der Distributor TD Synnex nimmt die Hashicorp-Lösungen Terraform und Vault von IBM in seine Hybrid-Cloud- und Security-Portfolios in der DACH-Region ...

툴 난립 줄이고 보안 효율 높이는 멀티클라우드 운영법

Fri, 27 Jun 2025 10:18:40 +0200

클라우드와 온프레미스 중 어디에 서버를 두는 것이 더 나은가에 대한 논쟁은 이제 과거의 일이 됐다. 최근 기업들은 보안과 운영의 단순화를 중요하게 여기며 워크로드를 재배치하고 있다.

그러나 현대의 멀티클라우드 컴퓨팅 환경은 워낙 다양하고 복잡하기 때문에 이 같은 움직임이 일률적으로 나타나지는 않는다. 일부 기업은 AWS나 애저와 같은 단일 클라우드 서비스 제공업체로 여러 플랫폼(PaaS)에서 운영하던 워크로드를 통합하고 있다. 반면 일부는 클라우드 사용 범위를 축소하며 벤더 수를 줄이고 있다. 과거에는 다양한 클라우드 제공업체를 병행해 사용하는 것이 어느 정도 용인됐지만, 최근에는 기술적 부담이 커지며 이를 유지하는 것이 점점 어려워지고 있다.

포레스터애널리스트 안드라스 체르는 파운드리 산하 보안 매체 CSO와의 인터뷰에서 “여러 클라우드 제공업체를 통합하려는 움직임이 있다”라며 “이는 기술적 부채와 벤더 종속성을 줄이기 위한 노력”이라고 설명했다.

이러한 통합은 일관된 아키텍처 전략이라기보다는 기업 인수합병에 따른 중복 정리나 여러 개발팀 간의 일관성 확보를 위한 실용적 선택인 경우가 많다. 일부 기업은 워크로드를 온프레미스로 되돌리거나 퍼블릭 클라우드에서 하이브리드 또는 프라이빗 클라우드로 이전하고 있다.

다음은 멀티클라우드 보안에서 발생하는 주요 과제와 복잡성을 살펴보고, 이를 해결하기 위한 실질적인 방안을 제시한다. 보안의 목적성을 강화하고 도구의 중복 사용을 줄이기 위한 실행 전략이 중심이다.

비용 관리의 중요성

기업에서 겪는 핵심 과제는 클라우드마다 별도로 개발팀을 운영해야 해 전체 운영비용이 크게 증가한다는 점이다. 클라우드마다 도구와 구현 방식이 달라 다양한 서비스와 프로토콜, 시스템을 이해하고 유지할 수 있는 전문 인력이 필요하다.

인프라플랫폼 기업 피보탈(Pvotal)의 CTO 애슐리 만라즈는 CSO에 “엔지니어들은 여러 클라우드를 동시에 다룰 만큼의 전문 지식을 갖추기 어렵다. 대부분 한두 개의 클라우드에 집중하고 가능한 한 많은 보안 자동화를 활용해 관리한다”라며 “한 가지 클라우드에 집중하고 이를 잘 운영하는 것이 효율적이다. 모든 워크로드를 모든 클라우드에 일관되게 복제하는 것은 불가능하다”라고 전했다.

보안 컨설팅 기업 제나시티(Zenaciti) 설립자인 앤드루 플래토는 멀티클라우드 접근 방식이 그 매력을 잃고 있다고 분석했다. 그는 “예를 들어 AWS에서 애저로 워크로드를 옮기는 것은 비용도 많이 들고 기술적으로도 매우 어렵다”며 “대부분의 기업이 클라우드 서버를 온프레미스로 대거 이전하고 있는 건 아니지만, 퍼블릭 클라우드를 동시에 여러 개 운영하는 전략에서는 점점 물러나고 있다”라고 말했다.

결과적으로 비용 절감은 주요 동인이지만, 이 비용을 정확히 파악하는 일은 여전히 어렵다. 클라우드 비용 예측 도구는 지난 10년간 눈에 띄게 발전하지 않았으며, 사용량 기반 과금 구조와 제공업체의 가격 정책 변화로 인해 월별 청구 금액은 크게 달라질 수 있다. 앞서 보도된 바에 따르면 “월별 클라우드 청구서를 분석하려면 공인회계사, 소프트웨어 엔지니어, 상품 트레이더에 버금가는 분석 능력이 필요하다”고도 전해졌다.

보안 플랫폼 업체 시큐리티스코어카드(SecurityScorecard) CISO 스티브 콥은 “클라우드 요금 충격은 새 애플리케이션을 클라우드에 올리고 첫 요금 고지서를 받았을 때 자주 발생한다”라며 “트래픽 패턴은 실제 데이터를 투입해 운영을 시작하기 전까지는 예측하기 어렵고, 특히 클라우드 리전을 넘나드는 대용량 데이터 이동이나 다중 클라우드 간 페일오버 구성을 할 경우 그 충격은 더 크다”라고 분석했다.

줌(Zoom)과 같은 일부 조직은 실시간 애플리케이션의 성능 요구를 보다 안정적으로 충족하기 위해 일부 워크로드를 온프레미스로 이전했다. 과거 줌에서 근무했고 현재는 보안 기업 애비에이트릭스(Aviatrix)의 CISO인 존 치안은 CSO에 “줌은 급격한 수요 증가에 대응하기 위해 주요 3대 플랫폼(PaaS) 모두를 활용하고 있다”고 설명했다. 이어 “클라우드와 온프레미스의 장점을 모두 취해야 한다. 예를 들어, 자체 AI 클러스터를 구성할 수 있을 만큼의 GPU 대역폭을 확보할 수 있다면 데이터센터를 사용하는 것이 합리적”이라고 덧붙였다. 현재 애비에이트릭스는 두 개의 PaaS만을 사용하고 있다.

또한 AI 기반 대형 언어모델(LLM)과 같은 워크로드에서 저장 용량이 커질수록 온프레미스 스토리지가 더 경제적이고 예측 가능하다는 인식도 확산되고 있다. 특히 PaaS 간에 대규모 데이터를 전송해야 할 경우 온프레미스 방식이 유리하다는 분석이다.

앤드루 플래토는 “꼭 클라우드에 올릴 필요가 없다면, 올리지 마라”라는 원칙을 제않했다.

해법으로 떠오른 컨테이너

많은 전문가들이 공통적으로 언급한 흐름은 컨테이너 기반으로 워크로드를 전환하는 추세다. 치안은 “컨테이너는 추상화 계층을 제공하기 때문에 클라우드 간 혹은 클라우드와 온프레미스 간 전환을 쉽게 만든다. 다만 개발자는 컨테이너 간 보안 문제도 함께 고려해야 한다”라고 설명했다.

플래토는 “VM에서 컨테이너로 워크로드를 옮기는 것이 훨씬 쉽고, 여러 VM보다 컨테이너 클러스터를 보안 측면에서 더 효율적으로 관리할 수 있다”고 강조했다. 포레스터의 체르는 “컨테이너는 사실상 클라우드 위의 클라우드이기 때문에 클라우드 전환을 더 유연하게 만든다”고 평가했다.

보안 정책의 중앙화

모든 클라우드 환경에 걸쳐 공통되고 일관된 보안 정책을 수립하는 것이 이상적이다. 그런 다음 테라폼(Terraform)이나 통합개발환경(IDE)과 연동 가능한 기타 IaC(Infrastructure as Code) 도구로 자동 배포할 수 있다. 여기에 클라우드 네이티브 애플리케이션 보호 플랫폼(CNAPP)도 큰 도움이 된다. CNAPP는 다양한 보안 도구를 통합해 복잡한 환경에서도 일관된 정책 적용을 쉽게 한다. 다만, 이미 많은 자동화 도구를 자체 구축해 운용 중이라면 CNAPP 도입이 적절하지 않을 수도 있다.

플래토는 “이런 도구를 활용하면 강력하고 안전한 인프라를 구축할 수 있다”라고 말했다.

시큐리티스코어카드의 CISO 스티브 콥은 “멀티클라우드 환경 전반에 변경이 필요한 신규 애플리케이션을 배포할 경우, 자동화 없이 대응한다면 예산과 전문성, 시간 면에서 모두 감당하기 어려워진다”고 지적했다.

해결해야 할 보안 과제를 명확히 파악하라

일부 상황에서는 데브섹옵스(DevSecOps) 팀이 기술적으로 CISO보다 앞서 있는 경우가 있다. 이럴 경우 CISO는 팀이 어떤 보안 문제를 해결하려 하는지, 해당 기술이 실제로 해결책이 되는지 파악하지 못할 수 있다. 플래토는 “결국 특정 보안 요구를 충족시키는 도구를 선정하기보다는 도구 중심의 접근으로 변질되고 만다”며 “이로 인해 보안 데이터가 여러 곳으로 흩어지는 도구 난립 현상이 발생할 수 있다”고 지적했다.

또한 개발자 역시 모든 클라우드에 걸쳐 보안이 어떻게 작동하는지를 명확히 이해하지 못하는 경우가 있다. 만라즈는 “PaaS 제공업체들이 서로 다른 CPU, 서버리스, 애플리케이션 지원 모델을 제공하면서 각자의 고유 기능이 갈수록 차별화되고 있다. 이 때문에 모든 클라우드에 동일한 보안 정책을 적용하기가 더욱 어려워지고 있다”고 설명했다.

권장 사항

멀티클라우드 보안을 강화하기 위한 추가적인 방법들도 있다. 애슐리 만라즈는 “워크로드가 실제 인프라 요구에 최대한 근접하게 배치돼 있는지 점검하라”며 “이렇게 하면 비용 절감은 물론 데이터 입출력 수수료도 줄일 수 있다”고 조언했다.

또한 여러 전문가들은 기업이 전체 애플리케이션 스택을 자사 데이터센터 내에서 관리하는 것이 바람직하다고 제안했다. 은퇴한 엔터프라이즈 IT 아키텍트 존 크로닌은 CSO에 “사내에 프라이빗 클라우드 환경을 먼저 구축하고, 데이터베이스, 스토리지, 애플리케이션, API 등 사용하는 모든 소프트웨어 기술을 스스로 통제할 수 있어야 한다”라고 조언했다. 이어 “외부 클라우드는 처리 용량 확대나 이중화, 복원력을 확보하는 보조 수단으로 활용해야 한다”라고 밝혔다.

플래토는 “보안 도구를 도입하기 전에는 반드시 명확한 우선순위와 철저한 리스크 분석이 선행돼야 한다”라며 “위협에 대한 이해 없이 도구부터 적용해서는 안 된다”라고 설명했다. 이어 “각 PaaS 제공업체가 제공하는 기본 보안 도구를 우선적으로 검토하라. 대부분의 경우 제3자 솔루션보다 저렴하면서도 충분한 기능을 제공한다”라고 밝혔다.
dl-ciokorea@foundryco.com

Cisco capitalizes on Isovalent buy, unveils new load balancer

Mon, 16 Jun 2025 22:48:37 +0200

Since it acquired open-source software developer Isovalent in January 2024, Cisco has been busy integrating its technology into some core products. In particular, Cisco has elevated the use of Isovalent’s core container communications technology, Kubernetes-native networking and security platform eBPF (extended Berkeley Packet Filter).

eBPF is an open-source Linux operating-system kernel technology that lets programs run securely in a sandbox within the kernel of the OS. This allows customers to incorporate security, observability and networking features quickly and easily without requiring them to modify kernel source code or deal with network overlays or other tedious programming tasks. The technology’s open-source development occurs under the Cloud Native Computing Foundation (CNCF) and includes industry input and support from Google, Microsoft, Red Hat, Intel and others.

Isovalent’s technology is being leveraged in a variety of different ways, and it plays a key role in Cisco’s strategy of developing programmable, AI-augmented, cloud-native technologies for enterprise customers, said Thomas Graf, co-founder and CTO of Isovalent at Cisco.

Most recently, at the Cisco Live customer event, Cisco released the Isovalent Load Balancer for customers looking to better manage and control workloads being shared across multiple backend servers.

Isovalent Load Balancer can run in any virtualized environment as well as natively in Kubernetes environments, including OpenShift. It can distribute ingress traffic across multiple backends, enabling health-checking, self-healing, and other configurable traffic-load-balancing patterns, according to Graf.

The package works by load balancing based on IP address, TCP/UDP ports, HTTP headers, cookies, or URLs. It ensures high application availability by enabling traffic to flow, even if communications are lost with a backend server, by distributing the traffic to other servers as per the defined load-balancing algorithm, Graf said.

The customer deploys the Isovalent Load Balancer control plane via automation and configures the desired number of virtual load-balancer appliances, Graf said. “The control plane automatically deploys virtual load-balancing appliances via the virtualization or Kubernetes platform. The load-balancing layer is self-healing and supports auto-scaling, which means that I can replace unhealthy instances and scale out as needed. The load balancer supports powerful L3-L7 load balancing with enterprise capabilities,” he said.

Depending on the infrastructure the load balancer is deployed into, the operator will deploy the load balancer using familiar deployment methods. In a data center, this will be done using a standard virtualization automation installation such as Terraform or Ansible. In the public cloud, the load balancer is deployed as a public cloud service. In Kubernetes and OpenShift, the load balancer is deployed as a Kubernetes Deployment/Operator, Graf said.

“In the future, the Isovalent Load Balancer will also be able to run on top of Cisco Nexus smart switches,” Graf said. “This means that the Isovalent Load Balancer can run in any environment, from data center, public cloud, to Kubernetes while providing a consistent load-balancing layer with a frictionless cloud-native developer experience.”

Cisco has announced a variety of smart switches over the past couple of months on the vendor’s 4.8T capacity Silicon One chip. But the N9300, where Isovalent would run, includes a built-in programmable data processing unit (DPU) from AMD to offload complex data processing work and free up the switches for AI and large workload processing.

For customers, the Isovalent Load Balancer provides consistent load balancing across infrastructure while being aligned with Kubernetes as the future for infrastructure. “A single load-balancing solution that can run in the data center, in public cloud, and modern Kubernetes environments. This removes operational complexity, lowers cost, while modernizing the load-balancing infrastructure in preparation for cloud native and AI,” Graf said.

In addition, it’s aligned with modern application development principles. “It removes ‘ticket ops’ style load-balancing configuration where application teams have to file tickets to get a load-balancing service. Instead, it allows application teams to leverage modern CI/CD deployment practices and accelerates deployment and time to market for new applications,” Graf said.

The package can also be targeted at those customers looking to move on from VMware.

“Load balancing is a crucial requirement for customers that are looking to shift their virtualization stack to a new virtualization platform. For example, from VMware to Nutanix or from VMware to OpenShift virtualization,” Graf said.

Beyond load balancing

In addition to the load balancer, Isovalent’s technology is being used in a variety of other capacities within the Cisco portfolio. For example, also at Cisco Live, the vendor announced a real-time, live patching system that applies security controls at the kernel level to defend against newly spotted CVEs without requiring switch or router reboots. The Cisco Live Protect feature bring a significant improvement to the reliability of switching infrastructure, Graf said.

“Customers no longer have to apply software patches and restart switches in order to address new security vulnerabilities. Instead a compensating control is deployed without requiring a restart of the switch. This capability is coming to Cisco Nexus switches first and is then expanded onto more and more Cisco device categories,” Graf said.

Isovalent’s technology is also part of Cisco’s Hypershield platform, which supports automated microsegmentation, distributed exploit protection and zone-firewalling based on smart switches all controlled using a single control plane that can span infrastructure from data center, cloud, to modern Kubernetes environments, Graf said.

In addition, Isovalent’s eBPF technology will become a highly efficient and optimized data collection mechanism for Cisco’s Splunk, providing customers with better control of what data is being fed into Splunk.

“eBPF’s capabilities allow for the ideal combination of deeper observability while providing better aggregation and summarization leading to a much-improved signal to noise ratio. Less data in Splunk but with an increased information density,” Graf said.

Build once. Build right. The enduring power of Azure Landing Zones.

Wed, 04 Jun 2025 06:48:59 +0200

Now that the rush to adopt the cloud has passed, many organisations are facing the consequences of that pace. Fragmented environments, inconsistent governance, and platforms that weren’t designed to scale are common. Technical debt is slowing teams down and driving up operational costs. Every new workload introduces risk and friction.

The root cause? It’s rarely the technology itself. More often than not, it’s the absence of a defined platform model balancing speed with control. This is where Azure Landing Zones come in. While the term may sound technical, the concept is simple: establish the foundations first.

What is an Azure Landing Zone?

Much like the slab, wiring, and plumbing of a new home, an Azure Landing Zone provides the foundation and core infrastructure. Each team can customise the interior to suit their needs, but the building codes, safety standards, and compliance requirements are built in and consistently enforced, setting the groundwork for controlled and efficient operations.

To build that foundation properly, Microsoft’s Cloud Adoption Framework (CAF) defines eight core design areas that every Landing Zone should address:

Identity and access management
Azure and Entra billing
Resource organisation
Network topology and connectivity
Security
Management
Governance
Platform automation and DevOps

Rather than recreating these controls for every team or retrofitting them when problems arise, a Landing Zone provides a consistent starting point. It reduces duplication, enforces standards, and prevents the slow accumulation of risk and complexity that occurs when cloud environments grow without clear boundaries.

These design areas serve as a field-tested reference architecture, helping organisations align technical implementation with broader business goals.

Why should IT leaders care?

The early phases of cloud adoption often prioritise speed. But without clear guardrails, the same agility enabling innovation can also introduce risk and prevent organisations from realising the transformation they were promised.

Security, compliance, cost visibility, and operational performance: they all suffer when cloud environments are inconsistent or grow organically.

Common signs of trouble include:

Subscription sprawl with unclear ownership
Workloads bypassing security controls
Poor visibility of cloud spend and resource usage
Long lead times to provision environments
Limited telemetry, monitoring, and support readiness
Teams blocked from delivery due to shared environments or dependencies

Once embedded, these problems are difficult to unwind. Landing Zones address them by shifting the model: define the platform first, plan for future scale, and establish governance and guardrails across the environment. Then let teams build and move quickly within that framework.

For technology leaders, this is about enabling secure, scalable, and sustainable innovation.

The strategic value of getting it right

A well-implemented Landing Zone strategy delivers long-term value across multiple dimensions. By providing speed with structure, teams can onboard applications, projects, or regions without delay. When teams work within environments that are ready to go, with core services and controls already in place, time-to-market improves, and rework is reduced.

More importantly, teams gain visibility into their own workloads, costs, and security posture. Cost management becomes more precise, with top-down governance that includes tagging, budgets, and chargeback models.

Security and compliance are applied from the start, with access, encryption, monitoring, and alerting consistently enforced. Operational consistency improves as telemetry, backup, and incident response patterns are built into the platform.

Most importantly, Landing Zones support scale. Defined as code, they can be replicated, adapted, documented, change-controlled, and improved over time. This allows organisations to expand confidently, meet new business demands, and mature their cloud estate without starting over.

Why It’s worth the investment

The cloud is not a one-off project. It’s an operating model. That means the costs of getting it wrong are cumulative: every manually provisioned resource, undocumented or inconsistent configuration. It all adds friction, risk, or technical debt.

Building Landing Zones may seem like overhead early on. In reality, they lay the groundwork that allows everything else to move quickly. With the foundations in place, teams avoid rework and operate within safe boundaries that support autonomy and scale.

How landing zones are built in practice

There is no one-size-fits-all implementation. Organisations vary in size, structure, and cloud maturity. But a typical approach includes:

Initial planning and assessment
Align cloud strategy (and Landing Zone design) with business goals, regulatory requirements, and existing platforms. Determine what can be reused and what must be rebuilt.

Reference architectures and templates
Use Microsoft’s CAF and tooling as a baseline. This includes Terraform and Bicep accelerators, Azure Verified Modules, and policy libraries aligning to NIST, ISM, and more.

Platform as code
Deploy the Landing Zone using infrastructure as code. This ensures repeatability, version control, and automation.

Incremental adoption
Apply the model to greenfield workloads first. Then bring existing resources under management, using tagging, policies, and monitoring to enforce consistency that might have been missing.

Operational alignment
Integrate monitoring, security operations, and cost management into the platform. Make sure the operating model supports the Landing Zone from day one.

Organisations with strong internal cloud capabilities can build this themselves. Others adopt pre-built accelerators or work with partners who specialise in platform design. But the unifying factor is to focus on the outcomes: speed, safety, and simplicity at scale.

Closing thoughts

Cloud success is not defined by what you can deploy, but by what you can operate, govern, and grow with confidence. And the organisations that will thrive are the ones that build the right foundation first, making deliberate choices early to reduce complexity, enable scale, and support their teams.

For more on how to unleash the full potential of Azure in your organisation, visit Brennan.

IBMs-Werkzeugkasten für die Cloud: Das wird aus Ansible und Terraform

Tue, 03 Jun 2025 13:31:10 +0200

Red Hat gehört seit 2019 zu IBM, HashiCorp seit Februar 2025. IBM hat damit Ansible und Terraform gekauft. Jetzt wird klar, wie die Werkzeuge zusammenarbeiten.

Deploy Amazon SageMaker Projects with Terraform Cloud

Fri, 30 May 2025 19:34:04 +0200

In this post you define, deploy, and provision a SageMaker Project custom template purely in Terraform. With no dependencies on other IaC tools, you can now enable SageMaker Projects strictly within your Terraform Enterprise infrastructure.

Jetzt Plätze sichern: Intensivseminar Infrastructure-as-Code mit Terraform

Mon, 26 May 2025 08:20:08 +0200

Jetzt Plätze sichern: Intensivseminar Infrastructure-as-Code mit Terraform

Lars Nitsch Mo., 26.05.2025 - 07:00

Wer IT-Infrastrukturen zuverlässig und wiederholbar aufbauen will, kommt an Infrastructure-as-Code nicht vorbei. Unser zweitägiges Online-Intensivseminar zu Terraform Ende Juli richtet sich an Admins, die einen fundierten Einstieg in die deklarative Beschreibung von IT-Umgebungen suchen. Dabei lernen Sie, wie Sie mit Terraform plattformunabhängig und effizient arbeiten – von der ersten Installation bis zur Nutzung fortgeschrittener Automatisierungstechniken.

Tipps & Tools

Weiterlesen über Jetzt Plätze sichern: Intensivseminar Infrastructure-as-Code mit Terraform

Agentic AI, LLMs and standards big focus of Red Hat Summit

Fri, 23 May 2025 02:32:39 +0200

Red Hat, announced a number of improvements in its core enterprise Linux product, including better security, better support for containers, better support for edge devices. But the one topic that dominated the conversation was AI.

Companies that don’t want to be stuck with just one cloud provider, or one AI vendor, but are instead beginning to operationalize AI across all their environments need a platform to do it on — and there’s a window of opportunity right now for that platform to emerge and become, in effect, the operating system of enterprise AI.

This week, Red Hat threw its considerable weight into the ring to be that platform. At least that was the big take-away for Forrester analyst Devin Dickerson.

“Red Hat continues to position itself as an enterprise-grade alternative for deploying modern workloads—now including AI—in environments that extend far beyond the public cloud,” he said.

And generative AI and agentic AI were front and center in Red Hat’s messaging this week. “Red Hat is offering a path to do AI in an open, portable, and secure way — on your terms,” he says. This is especially important in regulated industries with high compliance demands, Dickerson said.

“Red Hat is now positioning AI as a key pillar of its value proposition, alongside Linux, OpenShift and Ansible,” said Dimitris Mavrakis, senior research director at ABI Research.

For example, Red Hat announced that RHEL 10 was now an “AI native” operating system, he says. AI payloads are now treated as a core workload class, not an add-on like before.

“It is also a clear signal for enterprises that want to adopt AI for on-premise implementation, that Red Hat is becoming a key enabler for this journey,” Mavrakis added

Some enterprises opt for letting vendors handle their inferencing, via API calls to OpenAI’s ChatGPT or Anthropic’s Claude. It’s an easier and quicker approach, but can get expensive at scale. Plus, for security or compliance reasons, companies might want to run their AI on their own infrastructure.

“Many enterprises — especially ones that deal in business or mission-critical verticals — require AI to be deployed on-premise or in very tightly controlled environments,” said ABI’s Mavrakis. “However the implementation of these systems has been lacking,”

“Moreover, a large part of the market was previously served by VMWare, who has alienated a large part of the market,” he added.

Broadcom acquired VMware in 2023 and, since then, there have been some unpopular changes to license terms, pricing, and support. “These companies are looking at alternatives and Red Hat is a viable contender,” Mavrakis said.

Red Hat isn’t a generative AI company. Its parent, IBM, does have its own family of LLMs, but Red Hat is focusing on managing AI rather than building it themselves.

To do this, Red Hat has launched its AI Inference Server, a platform that supports a wide range of hardware accelerators and models. That includes chips from Nvidia, AMD, Google, AWS, Intel and IBM, and models from IBM, Google, Mistral, Microsoft, Qwen, DeepSeek, among others.

Plus, Red Hat now has an AI model library of more than three dozen validated models. Hosted on Hugging Face, it includes several flavors of Llama, Mistral, Granite and other leading edge open source models.

“The buzzy aspects of AI are giving way to more practical conversations about where and how it can deliver value,” said Eric Hanselman, an analyst at S&P Global Market Intelligence. That leads to a focus on inferencing capabilities and scaling, he says.

AI models can be used to answer questions — but they can also be used to power agents. Agentic AI gives enterprises the power to automate entire business processes. But deploying an agentic system is extremely complicated. In addition to the models that power the agents, enterprises also need to add layers of security, orchestration, and monitoring.

In addition, agents need to be able to access tools, data, and other resources.

To make that happen, Red Hat is betting on a couple of new technologies, both released in the latter half of last year by commercial vendors — but are both open source and have the potential of becoming industry standards.

One was obvious — MCP, or model context protocol, allows AI systems and agents to communicate with resources, tools, and data sources.

Since it was open-sourced by Anthropic late last year it has been adopted by a number of big tech vendors, including Google and Microsoft, as well as by its biggest rival, ChatGPT maker OpenAI.

The other one wasn’t as obvious. Llama Stack, released by Meta in September of 2024, is a set of tools for building, scaling and deploying AI applications and agentic systems.

A more popular alternative, the open source project LangChain, dates back to 2022. As of last October, LangChain reported more than 130 million downloads and 132,000 apps built using the technology, but it doesn’t exactly have the weight of a giant like Meta behind it. It’s too early to call MCP and Llama Stacks the new standards for agentic AI. But, says Forrester’s Dickerson, “Red Hat’s support along with others does lend credibility and momentum.”

In addition to helping enterprises deploy their own AI, Red Hat is also integrating AI into its own products. Big announcements in this area included AI assistants and AI-driven automation for setting up IT environments inside the Linux operating systems, said Walid Negm, US software-defined vehicle CTO at Deloitte Consulting.

Outside AI, the Red Hat news he was most excited about was the certification of the Red Hat In-Vehicle Operating System.

“Linux appears ready to reimagine the automotive industry, as developers may now be able to simplify processes along the vehicle development lifecycle both in the cloud and in the car itself,” he says.

For S&P’s Hanselman, the biggest surprise was the formal integration of HashiCorp and Red Hat. There’s a bit of overlap in their offerings, since HashiCorp’s Terraform automates cloud management, and so does Red Hat’s Ansible.

“There are natural connections across IBM’s portfolio, but there are fundamental differences across the automation products, Terraform and Ansible,” he said.

But HashiCorp also has its Vault product, used for identity-based authentication. “Tying Vault into the Red Hat world, given the challenges many face with secrets management, is a much more natural union,” Hanselman said.

Apple Swift Now Runs Things 3 Cloud Sync System

Wed, 21 May 2025 12:51:50 +0200

Things Cloud, the synchronization backbone of the award-winning Things 3 task manager, has undergone a complete rewrite, now powered entirely by Apple’s Swift programming language. Cultured Code, the company behind Things, has transitioned its server-side infrastructure from legacy systems to a Swift-based architecture, delivering faster performance, reduced compute costs, and improved maintainability. According to Cultured Code, the entire transformation was executed silently, without any service disruption. The new system has been in production for over a year, processing real-world data under the hood while the legacy Python 2 and Google App Engine-based stack continued to serve users. Once the new Swift-based infrastructure was validated in parallel, the switch was flipped seamlessly. Why Swift Took Over the Cloud Cultured Code initially faced mounting issues with its aging backend: slow response times, high memory usage, and fragile, untyped Python code. Even push notifications had to be managed by a separate C-based service to meet performance demands. These limitations, coupled with upcoming deprecations, prompted the team to consider a full rebuild. Swift emerged as the ideal solution. Already used for the Things app across Apple platforms, Swift offered strong typing, modern language features, automatic memory management, and excellent performance. Despite limited server-side maturity at the time, Swift’s ecosystem, including SwiftNIO, Vapor, and community-backed efforts like the Swift Server Workgroup, provided the foundational tools needed. Over three years, Cultured Code rewrote its entire cloud system in Swift. The new backend compiles into a single monolithic binary that runs multiple services via runtime parameters. The infrastructure is hosted on AWS and managed via Terraform, with deployments orchestrated through Kubernetes and Docker. Key services include MySQL (via MySQLKit), Redis (via RediStack), and Apple Push Notification service integration (via APNSwift). Performance and Reliability As reported by Swift.org, the new cloud system reduced compute costs by more than threefold and significantly shortened response times. A Kubernetes cluster of just four instances now handles traffic peaks of 500 requests per second with ease. The old C-based notification service has been replaced with Swift, streamlining both operations and the codebase. For resilience, the team introduced daily chaos testing, randomly disrupting services to ensure robust system recovery. Metrics and logs are monitored using Amazon CloudWatch and Swift Prometheus, with alerts triggered through PagerDuty. The multi-year overhaul signals Cultured Code’s long-term commitment to reliability and innovation. With Swift now running both client and server code, the Things ecosystem is more unified and future-proof than ever.

OSU's Open Source Lab Eyes Infrastructure Upgrades and Sustainability After Recent Funding Success

Sun, 18 May 2025 16:48:20 +0200

It's a nonprofit that's provide hosting for the Linux Foundation, the Apache Software Foundation, Drupal, Firefox, and 160 other projects — delivering nearly 430 terabytes of information every month. (It's currently hosting Debian, Fedora, and Gentoo Linux.) But hosting only provides about 20% of its income, with the rest coming from individual and corporate donors (including Google and IBM). "Over the past several years, we have been operating at a deficit due to a decline in corporate donations," the Open Source Lab's director announced in late April. It's part of the CS/electrical engineering department at Oregon State University, and while the department "has generously filled this gap, recent changes in university funding makes our current funding model no longer sustainable. Unless we secure $250,000 in committed funds, the OSL will shut down later this year." But "Thankfully, the call for support worked, paving the way for the OSU Open Source Lab to look ahead, into what the future holds for them," reports the blog It's FOSS. "Following our OSL Future post, the community response has been incredible!" posted director Lance Albertson. "Thanks to your amazing support, our team is funded for the next year. This is a huge relief and lets us focus on building a truly self-sustaining OSL." To get there, we're tackling two big interconnected goals: 1. Finding a new, cost-effective physical home for our core infrastructure, ideally with more modern hardware. 2. Securing multi-year funding commitments to cover all our operations, including potential new infrastructure costs and hardware refreshes. Our current data center is over 20 years old and needs to be replaced soon. With Oregon State University evaluating the future of this facility, it's very likely we'll need to relocate in the near future. While migrating to the State of Oregon's data center is one option, it comes with significant new costs. This makes finding free or very low-cost hosting (ideally between Eugene and Portland for ~13-20 racks) a huge opportunity for our long-term sustainability. More power-efficient hardware would also help us shrink our footprint. Speaking of hardware, refreshing some of our older gear during a move would be a game-changer. We don't need brand new, but even a few-generations-old refurbished systems would boost performance and efficiency. (Huge thanks to the Yocto Project and Intel for a recent hardware donation that showed just how impactful this is!) The dream? A data center partner donating space and cycled-out hardware. Our overall infrastructure strategy is flexible. We're enhancing our OpenStack/Ceph platforms and exploring public cloud credits and other donated compute capacity. But whatever the resource, it needs to fit our goals and come with multi-year commitments for stability. And, a physical space still offers unique value, especially the invaluable hands-on data center experience for our students.... [O]ur big focus this next year is locking in ongoing support — think annualized pledges, different kinds of regular income, and other recurring help. This is vital, especially with potential new data center costs and hardware needs. Getting this right means we can stop worrying about short-term funding and plan for the future: investing in our tech and people, growing our awesome student programs, and serving the FOSS community. We're looking for partners, big and small, who get why foundational open source infrastructure matters and want to help us build this sustainable future together. The It's FOSS blog adds that "With these prerequisites in place, the OSUOSL intends to expand their student program, strengthen their managed services portfolio for open source projects, introduce modern tooling like Kubernetes and Terraform, and encourage more community volunteers to actively contribute." Thanks to long-time Slashdot reader I'm just joshin for suggesting the story.

Read more of this story at Slashdot.

(g+) Admin-Tools: Warum sich Ansible und Terraform perfekt ergänzen

Sat, 10 May 2025 10:15:34 +0200

Ansible oder Terraform? Das ist hier die falsche Frage! Am besten nutzt man für Aufbau und Betrieb einer IT-Infrastruktur beide - wir erklären im Detail, wie. Eine Anleitung von Philip Lorenz (Ansible vs Terraform, Virtualisierung)

Anzeige: So geht Terraform

Wed, 07 May 2025 18:15:57 +0200

Terraform automatisiert Cloudumgebungen durch deklarative Konfiguration. Wie Openstack-Ressourcen strukturiert erstellt, verwaltet und versioniert werden, zeigt dieser Workshop. (Golem Karrierewelt, Cloud Computing)

Terraform-Konkurrent OpenTofu tritt im Sandbox-Status der CNCF bei

Wed, 30 Apr 2025 13:31:04 +0200

Das Open-Source-IaC-Tool OpenTofu tritt der Cloud Native Computing Foundation bei. Dafür hat sich die OpenTofu-Community mehrheitlich entschieden.

Kommentar: Droht die Spaltung? – Synadia fordert NATS von der CNCF zurück

Wed, 30 Apr 2025 09:45:47 +0200

Mit der Forderung von Derek Collison, NATS aus der CNCF wieder zu lösen, riskiert er juristischen Dauerstreit oder sogar einen Fork wie bei Terraform.

Anzeige: So geht Terraform

Wed, 30 Apr 2025 07:15:39 +0200

(g+) Terraform: Infrastructure as Code für moderne Umgebungen

Fri, 25 Apr 2025 13:45:33 +0200

Terraform ist ein IaC-Tool, das ganze Umgebungen bereitstellen kann. Was es speziell macht, wo es eingesetzt wird und wie es sich mit Ansible verträgt. Eine Anleitung von Philip Lorenz (Softwareentwicklung, Virtualisierung)

Dehnen hält fit: Aber 7 Fehler macht dabei fast jeder

Fri, 18 Apr 2025 07:15:27 +0200

Regelmäßiges Dehnen ist für die Flexibilität und Muskelgesundheit extrem wichtig. Allerdings machen dabei viele die immergleichen Fehler. Worauf Sie beim Stretching künftig achten sollten.

KI generiertes Nachrichten Update

Verwendetes künstliches Intelligenz Model: gemma-3-12b-it

Der Artikel richtet sich an ein technisch versiertes Publikum im IT-Bereich (z.B. Systemadministratoren, Security Engineers, Entwickler). Achte auf Fachterminologie und vermeide unnötigen Jargon. Der Ton ist informativ und professionell.

Dehnen hält fit: Aber 7 Fehler macht dabei fast jeder – Eine Analogie zur IT-Sicherheit

Der Artikel von tsecurity.de und Chip.de beleuchtet die häufigen Fehler beim Dehnen, die zu Verletzungen und Ineffektivität führen können. Auf den ersten Blick scheint das wenig mit der IT-Sicherheit zu tun haben. Doch bei genauerer Betrachtung offenbaren sich überraschende Parallelen: Sowohl im physischen als auch im digitalen Bereich ist eine sorgfältige Vorbereitung, ein methodischer Ansatz und die Vermeidung typischer Fehler entscheidend für Stabilität, Performance und langfristige Sicherheit.

Dieser Artikel wird die sieben genannten Dehnfehler (Überdehnung, falsche Technik, Vernachlässigung der Aufwärmphase, fehlende Variation, unregelmäßiges Training, Ignorieren von Warnsignalen des Körpers und mangelnde Konzentration) analysieren und sie mit entsprechenden Konzepten in der IT-Sicherheit vergleichen. Ziel ist es, das Bewusstsein für potenzielle Risiken zu schärfen und Best Practices abzuleiten – nicht nur für den Körper, sondern auch für die digitale Infrastruktur.

1. Überdehnung: Die Gefahr des ungezügelten Wachstums

Beim Dehnen bedeutet Überdehnung eine Verletzungsgefahr. In der IT-Sicherheit entspricht dies dem unkontrollierten Wachstum von Systemen ohne ausreichende Ressourcenplanung und Sicherheitsüberprüfungen. Denken wir an Cloud-Umgebungen, in denen die Skalierung oft auf Knopfdruck möglich ist. Ein ungezügeltes Wachstum kann zu Performance-Engpässen, Sicherheitslücken (z.B. unpatchte Systeme) und einer unübersichtlichen Architektur führen. Die DevSecOps-Philosophie versucht, Sicherheit von Anfang an in den Entwicklungsprozess zu integrieren, um dieses Risiko zu minimieren. Ähnlich wie beim Dehnen ist ein kontrolliertes, schrittweises Wachstum essenziell – "Slow and Steady Wins the Race".

2. Falsche Technik: Fehlkonfigurationen und Schwachstellen

Eine falsche Dehntechnik kann den gewünschten Effekt zunichte machen oder sogar Schaden anrichten. In der IT sind das Fehlkonfigurationen, die zu Sicherheitslücken führen. Ein häufiges Beispiel ist das Standardpasswort auf Netzwerkgeräten oder die Verwendung unsicherer Protokolle (z.B. Telnet). Die Implementierung von Infrastructure-as-Code (IaC) und Konfigurationsmanagementtools wie Ansible oder Terraform kann helfen, diese Fehler zu vermeiden, indem standardisierte, sichere Konfigurationen durchgesetzt werden. Regelmäßige Security Audits sind unerlässlich, um potenzielle Schwachstellen aufzudecken – vergleichbar mit der Überprüfung der korrekten Ausführung einer Dehnübung.

3. Vernachlässigung der Aufwärmphase: Ungeeignete Vorbereitung

Beim Dehnen bereitet die Aufwärmphase die Muskeln und Sehnen auf die Belastung vor. In der IT entspricht dies dem Testen von Änderungen in einer kontrollierten Umgebung (z.B. Staging-Umgebung) bevor sie in die Produktion übernommen werden. Ein direkter "Push to Production" ohne vorherige Validierung kann zu unerwarteten Problemen, Ausfällen und Sicherheitsvorfällen führen. Continuous Integration/Continuous Delivery (CI/CD) Pipelines sollten daher immer Testphasen beinhalten, um die Stabilität und Sicherheit des Systems sicherzustellen.

4. Fehlende Variation: Monotonie und Vorhersagbarkeit

Wiederholungen derselben Dehnübungen können zu Ungleichgewichten führen. In der IT bedeutet dies, sich auf eine einzige Sicherheitsmaßnahme oder Technologie zu verlassen. Ein Angreifer kann diese Monotonie ausnutzen. Diversifizierung ist hier der Schlüssel: Mehrfaktorauthentifizierung (MFA), Intrusion Detection Systems (IDS), Web Application Firewalls (WAF) und Penetrationstests sind nur einige Beispiele für die notwendige Vielfalt im Sicherheitsarsenal.

5. Unregelmäßiges Training: Inkonsistente Sicherheitspraktiken

Unregelmäßiges Dehnen führt zu Muskelverkrämpfungen und einer geringeren Flexibilität. In der IT bedeutet unregelmäßige Anwendung von Sicherheitsmaßnahmen ein erhöhtes Risiko für Angriffe. Security Awareness Trainings sollten regelmäßig durchgeführt werden, um Mitarbeiter über aktuelle Bedrohungen aufzuklären und sicherzustellen, dass sie die notwendigen Vorsichtsmaßnahmen treffen. Auch Patch-Management und Schwachstellenmanagement müssen kontinuierlich erfolgen.

6. Ignorieren von Warnsignalen des Körpers: Das Overlooken von Alerts

Schmerzen beim Dehnen sind ein Signal für eine Überlastung oder falsche Technik. In der IT sind das Security Alerts, die ignoriert werden – sei es aufgrund von Fehlkonfigurationen, mangelnder Expertise oder schlichtweg aus Zeitmangel. Ein Security Information and Event Management (SIEM) System kann dabei helfen, diese Alerts zu zentralisieren und zu analysieren, um schnell auf Vorfälle reagieren zu können.

7. Mangelnde Konzentration: Unachtsamkeit in kritischen Bereichen

Beim Dehnen ist Konzentration erforderlich, um die richtige Technik anzuwenden und Verletzungen zu vermeiden. In der IT bedeutet mangelnde Konzentration beim Programmieren oder bei der Systemadministration oft unsicheren Code oder Fehlkonfigurationen. "Pair Programming", Code Reviews und statische Analyse Tools können helfen, Fehler zu minimieren und die Qualität des Codes zu verbessern – ähnlich wie eine fokussierte Ausführung von Dehnübungen.

Fazit: Prävention ist besser als Heilung - in Körper und IT

Die Parallelen zwischen dem Dehnen und der IT-Sicherheit sind überraschend deutlich. Beide Bereiche erfordern einen methodischen Ansatz, die Beachtung grundlegender Prinzipien und die ständige Bereitschaft zur Verbesserung. Indem wir aus den Fehlern beim Dehnen lernen, können wir unsere Herangehensweise an die IT-Sicherheit schärfen und ein robusteres, widerstandsfähigeres digitales Ökosystem schaffen – für einen gesunden Körper und eine sichere digitale Welt.

Disclaimer: Dieser Artikel dient der Unterhaltung und Illustration. Er ersetzt keine professionelle medizinische oder IT-Beratung. Bei gesundheitlichen Problemen konsultieren Sie bitte einen Arzt; bei IT-Sicherheitsfragen wenden Sie sich an einen qualifizierten Experten.

New hands-on lab makes it easy to explore cloud configurations and workload migrations

Wed, 09 Apr 2025 20:48:50 +0200

For those that attended VMware Explore in Las Vegas and Barcelona, there was a new self-paced hands-on lab released exclusively for the attendees to experience Google Cloud VMware Engine while at the events.

I am happy to announce that this lab has now been made publicly available through the VMware Lab Platform website for anyone to enroll and try. I thought it may be worth taking a moment to briefly discuss the new modules and content as well as provide you a direct link to access it easily.

Hands-on lab summary

Since last year, there have been many interface changes and product enhancements that have changed the look and feel of Google Cloud VMware Engine. These refreshed modules capture the latest changes and features, and even let you experience some of the adjacent services.

The lab modules start with deploying your first private cloud, as well as configuring the initial VMware Engine networking. The follow-on modules walk you through everything from using Terraform, to migrating workloads with HCX, to external storage options, configuring backup, and using other Google Cloud services.

Figure 1: The Google Cloud VMware Engine hands-on lab landing page

Takeaway

All-in-all, there is a lot here to give you a taste of what using Google Cloud VMware Engine has to offer. Best of all, the lab modules are formatted into reasonable time chunks, usually 30 minutes or less, so that they can be done at your convenience.

About the author:
Darin Schmitz is a Senior Technical Marketing Architect in the VMware Cloud Foundation division at Broadcom focused on Google Cloud VMware Engine. Prior to Broadcom, he worked across multiple disciplines in the information technology industry, most notably within enterprise storage, cloud computing, and even as a systems administrator for some of the nation’s largest private sector and government organizations.

IBM z17 mainframe gains AI accelerator, massive workload support

Tue, 08 Apr 2025 19:03:39 +0200

The Big Iron evolution continues. IBM has rolled out the latest iteration of its mainframe, replete with AI technology designed to take data-intensive application support well into the future.

At the heart of the new z17 mainframe, available in June, is the 5.5 GHz IBM Telum II processor, which includes a built-in AI accelerator that IBM says will let customers run more than 450 billion inferencing operations in a day with one millisecond response time. The processor supports eight CPU cores per chip, 32 cores per system, and 36MB L2 cache memory, and it can run 24 trillion operations per second – a 40% increase in system throughput and fourfold reduction in overall latency compared to the existing Telum, IBM stated.

In addition, a 32-core AI accelerator called Spyre will be available in the fourth quarter as an optional PCIe card, and additional cards can be added depending on requirements. The Spyre accelerator is designed to handle emerging AI workloads such as generative and agentic AI.

“While AI models have mostly gotten larger over the past decade, the world is now also moving toward smaller, fit-for-purpose models. At the same time, the industry is seeing a rise in mixture of expert models and state space models, whose ideal uses and full capabilities are still being explored. Spyre has these capabilities baked in,” IBM stated. AI use cases are growing, says IBM, which counts more than 250 for IBM Z including financial fraud detection, medical image analysis, and credit risk scoring.

srcset="https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?quality=50&strip=all 9504w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=300%2C200&quality=50&strip=all 300w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=768%2C512&quality=50&strip=all 768w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=1024%2C683&quality=50&strip=all 1024w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=1536%2C1024&quality=50&strip=all 1536w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=2048%2C1365&quality=50&strip=all 2048w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=1240%2C826&quality=50&strip=all 1240w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=150%2C100&quality=50&strip=all 150w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=1046%2C697&quality=50&strip=all 1046w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=252%2C168&quality=50&strip=all 252w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=126%2C84&quality=50&strip=all 126w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=720%2C480&quality=50&strip=all 720w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=540%2C360&quality=50&strip=all 540w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-3-1.jpg?resize=375%2C250&quality=50&strip=all 375w" width="1024" height="683" sizes="(max-width: 1024px) 100vw, 1024px">

IBM Telum II processor with on-chip AI acceleration

IBM

“Our customers who have high volume transactional workloads were very interested in being able, in real time… to score their transactions for fraud, for example, whether those were debit card transactions or credit card transactions or core payments. They wanted to be able to embed AI in each transaction without slowing down those transactions,” said Elpida Tzortzatos, IBM Fellow and CTO of AI on IBM Z. “So what that translated into, from an AI infrastructure perspective, was having the ability to have hardware acceleration that can deliver, in the single-digit millisecond response times, a very high throughput.”

IBM has seen customers struggle to easily integrate AI into their existing environments, Tzortzatos said. “So we made sure that we not only delivered hardware acceleration, but also we built a very robust AI ecosystem of top of that hardware acceleration to help our clients really embed AI into their existing workloads and applications.”

Both predictive AI and generative AI are going to play a critical role in enterprise use cases and the type of AI models clients use, Tzortzatos said. Predictive AI models will continue to be the best fit for implementing use cases such as demand forecasting and anti-money laundering and fraud detection.

“Gen AI opens up the apertures for a whole set of new use cases around providing assistance, around being able to do document summarization, around being able to extract key insights of unstructured data,” Tzortzatos said.

Industry analysts weigh in on z17

Tech industry analysts say the z17’s ability to handle seriously high transactional workloads – such as AI inferencing, very specific AI applications, and traditional workloads – will allow the new Big Iron to play an important role in enterprise computing.

“This is cutting-edge server technology, kind of at its best, and I hope they get the credit for it,” said Steven Dickens, CEO and principal analyst with HyperFRAME Research. “At 5.5Ghz, when the rest of the industry is around 3Ghz combined with huge cache, it’s just an absolute beast of a machine, obviously specifically designed for the types of AI or heavy transactional applications and workloads that need it.”

“I think obvious use cases for AI, given the transactional nature of the workloads on the platform, [include] fraud management, for example, being able to run IBM Granite AI, small language models in transaction. [That] is the interesting story, and [how] that’s going to unlock applications at some of the biggest banks, telcos, retailers, government departments,” Dickens said.

The new system will be a draw for some specific AI use cases, notes Patrick Moorhead, founder, CEO and chief analyst with Moor Insights & Strategy.

“For the kind of customers that Z attracts – the banks, governments, and manufacturers – the AI will become important. Today, a lot of AI is offloaded off the mainframe, which is slow, costly and adds security risks. Applying AI at the point of data origin just makes sense,” Moorhead said.

“Many IBM customers are already doing this, but off the mainframe, which, for the reasons stated, aren’t optimal. I’m not saying all AI inference should be run on the mainframe, but very specific AI-enhanced use cases like fraud detection,” Moorhead said.

srcset="https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?quality=50&strip=all 9498w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=300%2C200&quality=50&strip=all 300w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=768%2C512&quality=50&strip=all 768w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=1024%2C683&quality=50&strip=all 1024w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=1536%2C1024&quality=50&strip=all 1536w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=2048%2C1365&quality=50&strip=all 2048w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=1240%2C826&quality=50&strip=all 1240w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=150%2C100&quality=50&strip=all 150w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=1046%2C697&quality=50&strip=all 1046w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=252%2C168&quality=50&strip=all 252w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=126%2C84&quality=50&strip=all 126w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=720%2C480&quality=50&strip=all 720w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=540%2C360&quality=50&strip=all 540w, https://b2b-contenthub.com/wp-content/uploads/2025/04/Image-2-1.jpg?resize=375%2C250&quality=50&strip=all 375w" width="1024" height="683" sizes="(max-width: 1024px) 100vw, 1024px">

IBM engineer in Poughkeepsie, N.Y., tests components on the new z17 mainframe.

IBM

z/OS 3.2 preview and watson X code assistance

In addition to the hardware, IBM previewed z/OS 3.2, the next version of its flagship IBM Z operating system, expected in the third quarter. z/OS 3.2 is planned to provide support for the hardware-accelerated AI capabilities delivered with IBM z17’s full stack optimization across the Telum II Data Processing Unit (DPU), Artificial Intelligence Unit (AIU), and IBM Spyre AI accelerator, IBM stated.

This next release will offer more support for industry-standard technologies, languages, and application workloads so clients can grow and enhance their mission critical, core business applications while still retaining the cyber-resiliency, data locality, and the unique hardware benefits of IBM Z, the vendor says. Improvements are planned to enhance out-of-the-box support for Linux and z/OS container-based applications, as well as IBM Open Enterprise SDK for Python and hybrid cloud data processing, according to IBM.

IBM will also add a new version of its watson X Code Assistant for Z to help developers modernize mainframe applications. Watson X is IBM’s AI development studio and platform. New enhancements will include chat-style explanations, the ability to improve code understanding and business agility for PL/I applications, and AI code optimization support for COBOL to improve application performance, IBM stated.

Some other new interesting features of the z17 package include:

A new mainframe observability package called IBM Z Operations Unite, which from a single interface will let customers collect event and metrics from various IBM Z data sources to provide a complete view of the infrastructure and more easily isolate and diagnose operational issues. According to IBM, the package, which reports data in the OpenTelemetry standard form, is designed to accelerate the time to detect anomalies and promises to reduce alert investigations.
New capabilities from IBM’s recent purchase of HashiCorp will help standardize secrets management across hybrid cloud, IBM stated. The features will be part of IBM Vault, which offers identity-based security to manage access to secrets and help protect sensitive data.
Tools to discover and classify sensitive data on the Z platform. When available, this capability will tap into Telum II for natural language processing and other newly created AI techniques so crown jewel data can be identified and protected before using in the AI data pipeline, IBM stated.

우리도 있다! 매니지드 쿠버네티스 플랫폼 14종

Wed, 02 Apr 2025 11:18:59 +0200

쿠버네티스는 매우 강력하지만 매우 복잡하기도 하다. 이 때문에 많은 조직들이 자체 호스팅 솔루션을 버리고 관리형 쿠버네티스 플랫폼으로 이동하고 있다. 2021년 데이터독의 보고서에 따르면, 쿠버네티스 사용자의 거의 90%가 클라우드 관리형 서비스를 이용하고 있다.

주요 클라우드 하이퍼스케일러들 모두 자체 관리형 쿠버네티스 플랫폼을 보유하고 있습니다. 각각 아마존 엘락스틱쿠버네티스 서비스(EKS), 애저 쿠버네티스 서비스(AKS), 구글 쿠버네티스 엔진(GKE)이다. 그러나 이들은 시작일 뿐이다. 관리형 쿠버네티스 서비스는 여러 기성 기술 회사와 신생 스타트업 다수가 제공 중이다. 클라우드 네이티브 컴퓨팅 재단(CNCF)가 인증한 벤더가 100곳이 넘을 정도다.

실제로 주요 3사를 제외한 대안형 관리형 쿠버네티스 플랫폼에 대한 관심도 증가하고 있다. 많은 플랫폼이 엣지, 온프레미스 또는 소규모 컨테이너 배포와 같은 고유한 환경에 특화되어 있다. 일부 서비스는 대규모 클라우드 업체보다 훨씬 저렴한 비용으로 관리형 인프라를 제공한다.

기존의 대형 업체들이 정체 상태에 빠진 채 가격을 인상하는 동안, 신생 업체들이 빠르게 혁신하고 있다. 특히 여러 퍼블릭 클라우드 또는 프라이빗 클라우드에서 클러스터를 관리하는 독립적인 레이어에 중점을 둔 솔루션이 풍부하다. 주목할 만한 관리형 쿠버네티스 플랫폼들을 살펴본다.

알리바바 컨테이너 서비스 포 쿠버네티스 (ACK)

알리바바 클라우드 콘테이너 서비스 포 쿠버네티스(ACK)는 클러스터 관리와 컨테이너화된 애플리케이션 배포를 간소화하기 위한 다양한 추가 기능을 제공한다. 이를 통해 알리바바 클라우드 인프라에서 높은 확장성을 구현한다.

주요 특징으로는 안전한 네트워킹을 위한 네이티브 VPC과 더불어 GPU 가속 인스턴스에 대한 인스턴트 액세스가 있다. 이를 통해 개발자는 여러 지리적 영역에 걸쳐 쉽게 배포할 수 있으며, 내장 카나리아 및 블루-그린 배포 전략을 사용하여 릴리스를 테스트할 수 있다. ACK는 쿠버네티스 규격에 부합하며 전문적인 지원 서비스를 포함한다.

ACK는 VPC 네트워킹을 우선시하며, 실리엄(Cilium)과 같은 현대적인 eBPF 기반 CNI에 대한 기본 지원 측면에서는 다소 부족하다(플러그인을 제공하긴 하지만). 또한 로깅, 저장, RBAC(역할 기반 액세스 제어)에 대해 알리바바 클라우드 서비스에 의존한다. 알리바바 클라우드 사용자에게는 좋지만, 오픈 스 유연성을 추구하는 사람들에게는 감점 요인이다.

아시아 태평양 지역에서 사업을 운영하거나 이미 알리바바 클라우드와 관련이 있는 경우, ACK는 확실한 고려 대상이다.

D2iQ 쿠버네티스 플랫폼(DKP)

현재 뉴타닉스가 소유하고 있는 D2iQ 쿠버네티스 플랫폼(DKP)은 메조스피어(Mesosphere)에서 진화한 서비스다. 메조스피어는 컨테이너 전쟁에서 그다지 좋은 성적을 거두지 못한 오케스트레이터인 아파치 메조스(Apache Mesos ; 현재는 사라짐)와 함께 제공됐던 바 있다. 쿠버네티스로 전환한 후, DKP는 클라우드 전반에 걸친 클러스터 관리를 위한 자동화 기능을 도입했다.

DKP의 컨트롤 플레인은 클러스터 전반에 걸친 가시성을 중앙집중화하여 문제 해결과 근본 원인 분석을 지원한다. 또 선언적 API와 표준 kubectl 명령에 부응하는 CNCF 준수성을 갖췄다. DKP는 또한 NSA/CISA 지침을 충족하고 에어갭 배포를 지원한다.

대부분의 사용자들은 DKP가 생산 등급 클러스터 관리를 위한 강력하고 신뢰할 수 있는 플랫폼이며, 데이터베이스 프로비저닝, CI/CD, 백업, 취약성 스캐닝, 모니터링을 단순화한다고 평가한다. 그러나 일부 사용자들은 문서화가 부족하고, 지원이 느리고, 초기 설정에 대한 학습 곡선이 가파르다고 말하기도 한다. 이 밖에 영업 사원들이 제품에 대한 지식이 부족하다는 지적도 있다.

DKP는 다양한 배포 환경에서 여러 클러스터를 실행하는 더 간단한 방법을 찾고 있는 강력한 깃옵스(GitOps) 문화를 가진 크로스 클라우드 조직에 적합한 선택이다.

디지털오션 쿠버네티스(DOKS)

디지털오션 쿠버네티스(DOKS)는 UI, API, CLI를 통해 액세스할 수 있는 완전 관리형 제어 평면을 갖춘 관리형 쿠버네티스 플랫폼이다. 이 플랫폼은 스냅슈터(SnapShooter)를 이용해 자동화된 고가용성, 자동 확장, 백업을 제공함으 인프라 관리를 추상화한다.

사용자들은 직관적인 웹 인터페이스, 간소화된 CLI, 쉬운 온보딩을 높이 평가한다. 몇 가지 명령어로만 업데이트가 이뤄지며, 네이티브 로드 밸런서와 볼륨이 원활하게 통합된다. 노드당 비용은 하이퍼스케일러보다 낮은 경향을 보인다. GPU 워크로드는 수동으로 배포되는 엔비디아 지원 드롭릿을 통해 지원된다.

공개적으로 노출된 etcd와 같은 초기 보안 문제는 해결됐다. 그러나 DOKS는 분산 스토리지를 위한 내장형 NFS(Network File System) 지원이 부족하다. 이에 대해 일부 플랫폼은 네이티브 옵션을 제공하기도 한다. 이 밖에 가상 사설 클라우드(VPC) 네트워킹을 사용할 수 있지만, AWS나 GCP보다 유연성이 떨어진다.

DOKS는 계속해서 개선되고 있으며, API, 워커 노드 또는 로그 처리와 같은 소규모 쿠버네티스 워크로드에 적합한 선택이다.

IBM 클라우드 쿠버네티스 서비스(IKS)

IBM 클라우드 쿠버네티스 서비스(IKS)는 IBM 클라우드에 컨테이너화된 애플리케이션을 배치하기 위한 관리형 쿠버네티스 플랫폼이다. 고급 스케줄링, 치유, 모니터링, 사용자 친화적인 배치 도구를 제공한다.

사용자들은 IKS의 핵심 장점으로 작업량 확장성과 높은 가용성을 꼽는다. 또한, IKS의 리소스 격리 기능은 규제가 엄격한 환경에서 유용하다. CNCF 인증을 받은 IKS는 예측 가능한 쿠버네티스 API 동작, 네이티브 컨테이너 레지스트리, 그리고 왓슨을 포함한 다른 IBM 서비스와의 통합을 제공한다.

멀티 클라우드에 초점을 맞춘 플랫폼과 달리, IKS는 IBM 클라우드 전용 서비스다. 즉 독립적인 컨테이너 오케스트레이션에서의 역할이 제한적이다. IBM 클라우드에 대해 개발자들은 높은 비용, 문제 해결의 어려움, 문서화의 부족 등을 지적하곤 한다. IKS에 대해서는 호불호가 엇갈리는 경향을 보인다.

이미 IBM 클라우드를 사용하고 있고 IBM 서비스와의 긴밀한 통합이 필요한 경우, IKS가 좋은 선택일 수 있다. IBM 클라우드에 대한 엇갈린 의견에도 불구하고, 여러 리뷰에서는 IKS가 역할을 잘 수행한다고 평가하곤 한다.

쿠버매틱 쿠버네티스 플랫폼

쿠버매틱 쿠버네티스 플랫폼(Kubermatic Kubernetes Platform ; KKP)은 낮은 대역폭이나 낮은 처리 능력과 같은 엣지 제약 조건에 최적화된 관리형 쿠버네티스 배포판이다. 이 플랫폼은 이식성이 뛰어나다. 하이브리드 멀티 클라우드, 데이터 센터, 멀티 테넌트 환경을 지원한다.

KKP에는 스케일링, 치유, 프로비저닝, 업데이트, 백업 등을 위한 자동화 기능이 내장되어 있다. CNCF 인증을 받았기 때문에 쿠버네티스 네이티브 명령어를 따르며, 자체 관리형 오픈소스 커뮤니티 버전은 아파치 라이선스 2.0에 따라 제공된다.

KKP의 컨테이너 네트워크 인터페이스(CNI) 지원은 원래 커낼(Canal)로 제한되어 있었지만, 지금은 실리엄 등의 다른 것들도 지원한다. KKP는 주요 관리형 쿠버네티스 서비스에 비해 사용자 기반이 작지만, 상당한 업스트림 쿠버네티스 기여자다.

KKP 클러스터는 관리형 플랫폼으로서는 무난하다. 엣지에서 컨테이너에 대한 높은 수준의 커스터마이제이션을 제공하는 쿠버네티스 네이티브 관리형 플랫폼을 원한다면, KKP가 좋은 옵션이다.

리노드 쿠버네티스 엔진 (LKE)

아카마이의 리노드 쿠버네티스 엔진(LKE)은 쿠버네티스 클러스터를 유지 관리하지 않고도 컨테이너화된 애플리케이션을 배포할 수 있게 하는 관리형 플랫폼이다. 이 플랫폼은 완전한 관리형 제어 플레인과 클러스터 프로비저닝을 위한 프로그래밍 방식을 특징으로 한다.

사용자들은 LKE의 사용 편의성, 고품질 고객 지원, 투명한 가격 정책(작업자 노드에 대해서만 비용을 지불하고, 인바운드 전송은 무료)을 호평한다. LKE는 99.99%의 가동 시간을 보장하고, 여러 가지 쿠버네티스 버전을 지원하며, 신속한 애드온 도구를 가능하게 한다.

그러나 LKE에는 주요 플랫폼에서 볼 수 있는 몇 가지 고급 기능이 없다. 특히, 개인 컨테이너 레지스트리를 제공하지 않으며, 대시보드가 관리되기는 하지만 사용자가 배포 구성을 처리해야 한다. (참고로 아카마이 앱 플랫폼의 기능성은 우수하지만 아직 베타 버전이다.) GPU 워크로드에 대해서는 추가 제품 구독이 필요하다.

스왑닐 바르티야가 TFiR.io에 쓴 글에 따르면, LKE는 일반적인 클라우드 사용자를 위해 설계된 서비스로, 소규모 팀과 대기업 모두를 대상으로 한다. 그러나, 그 단순성 때문에 많은 사람들이 이 서비스를 소규모 업체의 것으로 간주한다. 엘리엇 그래버트는 LKE를 “스타트업에 가장 적합한” 서비스라고 설명한 바 있다.

미란티스 쿠버네티스 엔진(MKE)

미란티스 쿠버네티스 엔진(MKE)은 이전의 도커 엔터프라이즈다. 베어 메탈, 퍼블릭 클라우드, 그리고 그 사이의 모든 곳에서 구동되는 쿠버네티스 기반 컨테이너 오케스트레이션 플랫폼이다. 오픈소스를 기반으로 구축된 이 플랫폼에는 네트워킹을 위한 캘리코(Calico)와 컨테이너와 VM을 모두 관리하는 쿠베버트(KubeVirt)가 포함되어 있다.

CNCF 인증을 받은 MKE는 웹 UI, CLI 또는 API를 통해 유연한 액세스를 제공한다. 사용자들은 사용의 용이성, 강력한 보안 제어, 무제한 작업자 노드, 컨테이너 이미지를 위한 내부 트러스티드 레지스트리를 높이 평가한다.

그러나 일부 사람들은 미란티스의 오픈소스 약속을 의심한다. 인기 있는 쿠버네티스 대시보드인 렌즈(Lens)를 사유화하고 무료 도커 관련 도구를 제품화한 이력 때문이다. 여러 리뷰에서는 고객 지원 문제와 불투명한 문서화도 언급하고 있다.

완전한 유연성보다 단순성을 중요하게 생각하는 도커 생태계 내의 사람들에게 MKE는 여전히 확실한 선택이다.

오라클 쿠버네티스 엔진(OKE)

오라클 쿠버네티스 엔진(OKE)은 오라클 클라우드 인프라스트럭처(OCI)를 기반으로 구축된 쿠버네티스 관리 플랫폼이다. 유지보수, 패치, 수리를 자동화하는 것 외에도 OKE는 자동 확장 및 효율적인 자원 활용을 지원한다.

OKE는 확장성이 준수하다. 서비스 메시, 클러스터 자동 확장, 메트릭, 인그레스 컨트롤러, 로드 밸런싱 등과 같은 영역에 여러 클러스터 애드온을 제공하여 오라클 생태계와 연계된 조직에 적합하다. 오라클은 일반적으로 엔터프라이즈 사용자를 대상으로 하지만, 일부 인디 개발자들도 자체 호스팅 프로젝트를 위해 OCI의 올웨이즈 프리 티어를 이용하고 있다.

일부 오라클 클라우드 사용자들은 무료 계정에서 계정이 갑자기 폐쇄되는 문제를 보고하고 있다. OCI 사용자 인터페이스 사용 시의 불편한 경험을 보고하는 목소리도 있다. 닥크테이프 테크놀로지스의 공동 설립자이자 CEO인 아놀드 갈로비치는 “오라클 클라우드 콘솔 인터페이스는 큰 퇴보다”라고 표현하기도 했다.

그러나 넉넉한 무료 계정을 제공하는 기업 중심의 쿠버네티스 관리 계층을 찾고 있다면, OKE가 적합하다.

플랫폼9 매니지드 쿠버네티스

플랫폼9 매니지드 쿠버네티스(PMK)는 배포, 모니터링, 치유, 업그레이드와 같은 클러스터 운영을 자동화하는 완전 관리형 쿠버네티스 서비스다. 클라우드에 구애받지 않는 PMK는 온-프레미스, 엣지, 퍼블릭 클라우드에서 실행된다.

사용자들은 PMK를 통해 성공적으로 확장할 수 있었다고 보고한다. 여기에는 멀티 클러스터 관리, 멀티 테넌시, 세분화된 RBAC 정책이 포함된다. 플랫폼9의 ‘Always On Assurance’가 고가용성을 보장한다. 경쟁사보다 업스트림 쿠버네티스에 더 가까운 PMK는 견고한 개발자 경험을 제공한다.

그러나 PMK에는 내장된 개인 레지스트리가 없고, CNI 지원이 제한적이다(플러그인을 통해 사용자 정의할 수 있음). 클라우드 호스팅 제어 평면은 엄격한 온-프레미스 규정 준수 요구 사항에 적합하지 않을 수 있다. 사용자들이 비용 절감을 보고하고 있지만, 정확한 가격 세부 사항은 불투명하다.

프라이빗 클라우드 쿠버네티스를 찾는 기업에게 PMK는 레드햇 오픈시프트, 또는 VM웨어 탄주의 강력한 대안이다.

랙스페이스 매니지드 쿠버네티스(MPK)

랙스페이스 매니지드 플랫폼 포 쿠버네티스(MPK)는 플랫폼9에 의해 구동되며, 클러스터 배치, 모니터링, 사고 대응, 업그레이드 등을 위한 통합 제어 평면을 제공한다.
MPK는 랙스페이스 베어 메탈, AKS, EKS 등 세 가지 환경을 지원한다. 고유한 장점으로는 수명 종료 후 120일 이내에 쿠버네티스 업그레이드를 보장하는 SLA와 전용 지원이 있다. 쿠버네티스 인증 엔지니어의 포드가 각 고객을 지원한다.

쿠버네티스 호환성이 매우 높은 MPK는 프로메테우스, 플루엔트드, 헬름, 이스티오와 같은 CNCF 지원 도구를 통합한다. 그러나 MPK에는 네이티브 컨테이너 레지스트리, IAM, 스토리지가 부족하기 때문에 퍼블릭 클라우드 또는 자체 솔루션이 필요하다.

AWS와 애저의 쿠버네티스 서비스를 관리하기 위한 직접적인 지원과 중앙집중식 플랫폼을 원하는 랙스페이스의 베어메탈 호스팅을 사용하는 팀에게 MPK는 확실한 선택이다.

랜처

수세의 랜처(Rancher)는 온프레미스와 클라우드를 위한 서비스형 쿠버네티스 솔루션이다. 랜처는 랜처 쿠버네티스 엔진(RKE), K3s, AKS, EKS, GKE를 포함한 여러 쿠버네티스 플랫폼 상의 클러스터를 관리할 수 있다.

몇몇 개발자들은 랜처의 통합 웹 UI가 사용하기 쉽다고 평가한다. API와 CLI도 제공한다. 자체 깃옵스 슬라이스를 통해 테라폼(Terraform)도 지원한다. 오쓰(OAuth)나 다른 로그인 옵션을 포함한 안전한 관리 제어 기능도 있다. 대규모 사용자 기반과 슬랙 그룹이 있어서 커뮤니티나 지원을 찾기 쉽다.

단 수세가 최근 몇 년 동안 가격을 올렸다. 일부 엔지니어들은 롱혼이라는 기본 스토리지 솔루션의 성능과 확장성 문제를 지적하며 백업 스토리지로 다른 대안을 추천한다. 랜처는 K3k라는 쿠버네티스 안의 쿠버네티스도 지원한다. 더 큰 환경에서 격리된 K3s 클러스터를 돌릴 수 있다.

전체적으로 랜처는 오픈시프트와 비슷하다. 근데 덜 독단적이고 더 모듈화되어 있다. 멀티 테넌트 접근 방식도 다르다. 공급업체 제약 없는 멀티 클라우드, 멀티 클러스터 관리가 필요하면 랜처가 좋은 선택이다. 포테이너(Portainer)도 비슷한 대안이다.

레드햇 오픈시프트 쿠버네티스 엔진

레드햇 오픈시프트는 개발자 도구 체인으로 쿠버네티스를 간소화한다. 클러스터 관리를 쉽게 해주는 하이브리드 클라우드 플랫폼이다. 가시성, 네트워킹, 보안, 깃옵스가 내장되어 있다. 독립형 쿠버네티스보다 업그레이드나 패치가 편하다. 클라우드 전용 서비스와 달리 온-프레미스, 데이터 센터, 클라우드 어디서든 실행할 수 있는 이식성이 있다.

오픈시프트 쿠버네티스 엔진은 오픈시프트의 간소화된 버전이다. 상위 PaaS 레이어 없이 관리형 쿠버네티스 환경을 제공한다. 컨테이너와 가상 머신을 같이 돌릴 수 있다.

단점은 오픈시프트가 AKS 같은 다른 서비스보다 훨씬 독단적이라는 점이다. 자체 oc CLI를 kubectl보다 선호한다. 일부 헬름 차트나 오퍼레이터는 보안 모델이 엄격해서 조정이 필요할 수 있다.

오픈시프트는 온프레미스 배포나 VM과 컨테이너를 관리하는 하이브리드 팀, 레드햇 고객에게 잘 맞는다. 내장 보안과 자동화가 있는 휴대용 엔터프라이즈급 쿠버네티스를 찾으면 오픈시프트가 강력한 선택지다.

스케일웨이 쿠버네티스 캡슐

유럽 연합에 기반을 둔 클라우드 제공업체인 스케일웨이(Scaleway)는 오토스케일링과 복원력에 중점을 둔 관리형 쿠버네티스 서비스인 쿠버네티스 캡슐(Kubernetes Kapsule)을 제공한다. 멀티 클라우드 배포를 위한 코스모스(Kosmos)도 있다.

캡슐은 세련된 UX, 좋은 고객 지원, API, CLI, 테라폼으로 유연하게 클러스터를 관리할 수 있다. 노드 사용량만큼만 비용을 낸다. 개인 클러스터나 실험용으로 저렴하다. 애플리케이션 라이브러리에 일반 추가 기능용 사전 구성 이미지도 포함되어 있다. CNCF 인증도 받았다. 표준 쿠버네티스 API를 따른다.

단점은 지원 지역이 프랑스, 네덜란드, 폴란드 정도로 한정돼 있다는 점이다. 글로벌 서비스로는 부족하다. 고급 로드 밸런싱이나 DNS 같은 기능이 없다는 점도 아쉽다. 프로비저닝이 느리다. 중단이나 안정성 문제도 보고된다.

기능과 지역이 제한적이어서 유럽 데이터 규제를 지켜야 하는 부수적인 프로젝트나 유럽 스타트업에 적합하다.

VM웨어 탄주 쿠버네티스 그리드(TKG)

VM웨어의 탄주 쿠버네티스 그리드(TKG)는 네트워킹, 인증, 모니터링, 로깅, 인그레스 제어를 간소화하는 쿠버네티스 플랫폼이다. 오픈소스를 일부 기반으로 한다. 클러스터 API로 여러 클러스터를 관리한다. 성능이 좋다. CLI와 UI 옵션도 제공한다.

단 TKG는 이제 멀티 클라우드가 아니다. v2.5 이후로 AWS와 Azure 워크로드 지원을 끊었다. 지금은 거의 v스피어에만 집중한다. 독립적인 쿠버네티스 컨트롤 플레인으로는 적절하지 않다. 클라우드 전반에 걸쳐 관리하려면 EKS, AKS, GKE 같은 네이티브 서비스와 탄주 미션 콘트롤(TMC)이 필요하다.

문제는 탄주의 복잡한 브랜딩과 문서화다. VM웨어 직원들도 SKU 설명하기 힘들다. 브로드컴이 VM웨어를 인수하면서 가격도 많이 올랐다. 몇몇 탄주 패키지 지원도 중단됐다. 장기적인 생존 가능성에 의문이 제기되고 있다..

v스피어와 가상 머신에 깊이 투자했다면, 또 비용 부담을 감내할 만하고 멀티 클라우드가 필요 없으면 TKG가 괜찮은 선택이다. 아니면 더 유연하고 미래 지향적인 대안이 낫다.

이 밖의 플랫폼들

그 외에도 수많은 관리형 쿠버네티스 플랫폼이 있다. 헤츠너(Hetzner)나 스펙트로 클라우드(Spectro Cloud) 같은 니치 클라우드와 함께 계속해서 등장한다. 비슷한 완전한 기능을 갖춘 쿠버네티스 관리형 플랫폼으로는 OVHCloud 매니지드 쿠버네티스와 시보(Civo) 쿠버네티스가 있다.

텐센트 쿠버네티스 엔진(TKE)과 화웨이 클라우드 컨테이너 엔진(CCE)는 아시아 태평양 지역 사람들에게 또 다른 옵션이다.

대기업들도 쿠버네티스 관리의 간소화된 버전을 제공한다. 예를 들어, AKS 오토매틱과 EKS 오토 모드는 클러스터 배포와 운영을 자동화하기 위한 원활한 개발자 경험을 제공한다. 구글 클라우드 안토스는 하이브리드 멀티 클라우드 솔루션으로 부상했다.

다른 많은 솔루션은 틈새 시장인 쿠버네티스 관리 기능에 특화되어 있다. 예를 들어, 포테이너(Portainer), 라파이(Rafay), 옴니(Omni), 리쿼(Liquo), 쿠베 클러스터스(Kube Clusters) 같은 관리 서비스는 멀티 클러스터, 멀티 클라우드 관리를 위한 범용 제어에 중점을 둔다.

엣지나 소형 컨테이너 배포의 경우, 슬림 옵션으로 MicroK8s, K3s, K0s가 있다. 벌처 쿠버네티스 엔진은 관리가 더 용이한 환경을 제공한다. 개발자들이 선호하는 쿠베스프레이(Kubespray)는 슬림 구성으로 쿠버네티스 클러스터를 배포하기 위한 오픈소스 도구 세트를 제공한다.

작업별 적합한 도구

플러그 앤 플레이 방식의 쿠버네티스 서비스는 클러스터 관리의 많은 번거로움을 덜어준다. 하지만 규모에 따라 다르다. 여러 클러스터를 동시에 실행하지 않으면 관리형 서비스가 필요 없을 수도 있다. 소규모 배포의 경우, 도커 컴포즈(Docker Compose)나 노마드(Nomad) 같은 더 간단한 컨테이너 런타임을 선택할 수 있다. 다른 사람들은 헤로쿠(Heroku), 플라이.io(Fly.io), 클라우드 런(Cloud Run) 같은 서비스형 플랫폼(Platform-as-a-Service)을 선택할 만하다.

필요에 따라 특정 도구만 필요할 수도 있다. 예를 들어, 카펜터(Karpenter)는 클러스터 노드의 자동 확장 전용으로 널리 사용되는 오픈소스 도구다. 데브트론(Devtron)같은 대시보드나 앱타큐브(Aptakube), 옥탄트(Octant) 같은 UI만 필요할 수도 있다.

인프라 수준에서 더 세밀한 제어가 필요할 거라 예상하고 여력이 있으면 구매보다 구축이 더 나을 수도 있다. 적절한 기술적 역량이 있으면 궁극적인 제어를 위해 내장된 kubeadm을 유지하고 쿠버네티스를 직접 호스팅하는 걸 고려할 만하다.

관리형 쿠버네티스 서비스를 평가하려면 두 가지 주요 요소에 집중해야 한다. 수석 컨설턴트 마이클 레반은 자동화된 서비스가 인프라 관리를 제거할 수 있지만, 특정 타사 도구와 잘 통합되지 않을 수도 있다고 지적했다. 그는 “클라우드에서처럼, 얼마나 많은 권한을 포기할 건지에 따라 결정된다”라고 말했다.
dl-ciokorea@foundryco.com

Anzeige: Terraform und Openstack für strukturierte Cloudautomation

Tue, 01 Apr 2025 18:15:45 +0200

Mit Terraform lassen sich Cloudumgebungen deklarativ verwalten und automatisieren. Ein zweitägiger Workshop vermittelt DevOps-Teams den strukturierten Einsatz in Openstack-Umgebungen. (Golem Karrierewelt, Cloud Computing)

(g+) Agentenlos, flexibel, skalierbar: Warum Ansible in der IT-Automatisierung glänzt

Tue, 01 Apr 2025 13:45:59 +0200

Ansible und Terraform sind bekannte Admin-Tools. In einer dreiteiligen Reihe sehen wir uns beide an und vergleichen sie. Teil 1 startet mit Ansible. Eine Anleitung von Philip Lorenz (Softwareentwicklung, Git)

heise+ | Tutorial GitOps mit Crossplane, Teil 1: Beyond CI/CD

Mon, 31 Mar 2025 12:16:04 +0200

Crossplane orchestriert Ressourcen cloudübergreifend und bietet zugleich eine Implementierung der GitOps-Prinzipien. Damit kann es Tools wie Terraform ablösen.

Infrastructure-as-Code: Erweiterte Security und Kontrolle in der Pulumi Cloud

Wed, 26 Mar 2025 18:00:35 +0100

Role-Based Access Control und die Integration von GitHub Actions sollen die Zugangskontrolle und das Secrets-Management auf der IaC-Plattform verbessern.

KI generiertes Nachrichten Update

Verwendetes künstliches Intelligenz Model: gemma-3-12b-it

Infrastructure-as-Code: Erweiterte Security und Kontrolle in der Pulumi Cloud

Ein Beitrag von [Dein Name], Senior IT Sicherheitsforscher/Experte/Consultant

Die Transformation von IT-Infrastrukturen hin zu cloudbasierten Modellen hat die Agilität, Skalierbarkeit und Kosteneffizienz erheblich verbessert. Gleichzeitig birgt diese Verlagerung aber auch neue Herausforderungen im Bereich der Sicherheit und Compliance. Traditionelle manuelle Konfigurationsmethoden sind unübersichtlich, fehleranfällig und schwer nachvollziehbar. Infrastructure-as-Code (IaC) bietet hier eine elegante Lösung, die durch Automatisierung und Codebasierte Definition von Infrastrukturkomponenten die Konsistenz, Reproduzierbarkeit und Sicherheit erhöht. Dieser Artikel beleuchtet die Vorteile der IaC-Philosophie im Kontext der Pulumi Cloud, insbesondere in Bezug auf erweiterte Sicherheitsfunktionen und verbesserte Kontrolle über komplexe Infrastrukturen. Die URL https://tsecurity.de/de/2688568/IT+Nachrichten/Infrastructure-as-Code%3A+Erweiterte+Security+und+Kontrolle+in+der+Pulumi+Cloud/ bietet bereits eine erste Einführung in das Thema, die wir hier vertiefen und mit aktuellen Entwicklungen ergänzen.

Was ist Infrastructure-as-Code?

IaC beschreibt den Ansatz, IT-Infrastruktur (Netzwerke, Server, Datenbanken, etc.) wie Software zu definieren und zu verwalten. Dies geschieht durch Code, der in Versionskontrollsystemen gespeichert und automatisiert angewendet werden kann. Im Gegensatz zu manuellen Konfigurationen ermöglicht IaC:

Reproduzierbarkeit: Infrastruktur wird konsistent bereitgestellt und aktualisiert.

Automatisierung: Reduzierung manueller Fehlerquellen und Beschleunigung von Deployment-Prozessen.

Versionskontrolle: Änderungen an der Infrastruktur sind nachvollziehbar und können rückgängig gemacht werden.

Zusammenarbeit: Teams können gemeinsam an Infrastrukturdefinitionen arbeiten.

Pulumi Cloud: Mehr als nur IaC – Ein Sicherheitsfokus

Während verschiedene Tools wie Terraform, Ansible oder AWS CloudFormation IaC ermöglichen, zeichnet sich die Pulumi Cloud durch einen besonderen Fokus auf Sicherheit und Kontrolle aus. Sie bietet eine umfassende Plattform für das Design, die Bereitstellung und die Verwaltung von Cloud-Infrastruktur in Multi-Cloud-Umgebungen. Im Vergleich zu einigen konkurrierenden Lösungen (siehe z.B. https://www.pulumi.com/terraform-vs-pulumi/) bietet Pulumi eine flexiblere Programmierschnittstelle und verbesserte Unterstützung für komplexere Anwendungsfälle.

Erweiterte Sicherheitsfunktionen der Pulumi Cloud:

Policy-as-Code (PaC): Pulumi integriert Policy-as-Code, um sicherzustellen, dass die bereitgestellte Infrastruktur den definierten Richtlinien und Compliance-Anforderungen entspricht. Dies ermöglicht die Durchsetzung von Best Practices und minimiert das Risiko von Fehlkonfigurationen, die zu Sicherheitslücken führen können. Tools wie Open Policy Agent (OPA) können in Pulumi integriert werden, um detaillierte Governance-Regeln durchzusetzen (siehe z.B. https://www.openpolicyagent.org/).

Secrets Management: Pulumi bietet integrierte Funktionen zur sicheren Verwaltung von Secrets wie Passwörtern, API-Schlüsseln und Zertifikaten. Diese werden nicht im Code gespeichert, sondern zentral verwaltet und bei der Bereitstellung sicher injiziert. Die Integration mit Vault (siehe https://www.hashicorp.com/vault) ist ebenfalls möglich, um ein noch robusteres Secrets Management zu gewährleisten.

Role-Based Access Control (RBAC): Detaillierte Zugriffsrechte können auf Benutzer und Teams basierend auf ihren Rollen definiert werden. Dies schränkt den Zugriff auf sensible Infrastrukturkomponenten ein und minimiert das Risiko von unbefugten Änderungen.

Drift Detection: Pulumi überwacht kontinuierlich die bereitgestellte Infrastruktur auf Abweichungen vom definierten Code (Drift). Dies ermöglicht die frühzeitige Erkennung von nicht autorisierten Änderungen oder Konfigurationsabweichungen und erleichtert die Wiederherstellung in einen konsistenten Zustand.

Audit Logging: Umfassende Protokollierung aller Aktivitäten im Zusammenhang mit der Infrastrukturverwaltung, einschließlich Bereitstellungen, Änderungen und Zugriffsversuchen. Dies unterstützt forensische Analysen und Compliance-Audits.

Security Scanning Integration: Die Pulumi Cloud ermöglicht die Integration mit externen Security Scanning Tools (z.B. Snyk, SonarQube) um den Code auf Sicherheitslücken zu überprüfen bevor er in Produktion eingesetzt wird.

Kontrolle und Transparenz durch IaC mit Pulumi Cloud:

Versionskontrollierte Infrastruktur: Der gesamte Infrastructure-Code ist in einem Versionskontrollsystem (z.B. Git) gespeichert, was eine vollständige Nachverfolgung von Änderungen ermöglicht.

Testautomatisierung: IaC ermöglicht die Integration von Testverfahren in den Deployment-Prozess, um sicherzustellen, dass die Infrastruktur korrekt konfiguriert ist und den Anforderungen entspricht. Dies umfasst Unit-Tests für einzelne Komponenten sowie Integrationstests für das gesamte System.

Rollback-Fähigkeit: Im Falle eines Fehlers können Änderungen einfach rückgängig gemacht werden, was Ausfallzeiten minimiert und die Stabilität der Infrastruktur gewährleistet.

Zentrale Steuerungsebene: Die Pulumi Cloud bietet eine zentrale Übersicht über alle Infrastrukturen, was die Überwachung, das Management und die Compliance vereinfacht.

Herausforderungen und Best Practices:

Obwohl IaC mit Pulumi Cloud erhebliche Vorteile bietet, gibt es auch einige Herausforderungen:

Lernkurve: Die Erstellung und Verwaltung von Infrastructure-Code erfordert ein gewisses Maß an technischem Know-how.

Komplexität: Die Definition komplexer Infrastrukturen kann schnell unübersichtlich werden. Eine modulare Architektur und die Verwendung von Abstraktionen sind daher entscheidend.

Sicherheit des Codes: Der Infrastructure-Code selbst muss sicher sein, um Angriffe zu verhindern. Dies erfordert regelmäßige Sicherheitsüberprüfungen und Penetrationstests.

Best Practices für eine sichere IaC Implementierung mit Pulumi Cloud:

Implementieren Sie Policy-as-Code, um die Einhaltung von Sicherheitsrichtlinien zu gewährleisten.

Verwenden Sie ein Secrets Management System zur sicheren Verwaltung sensibler Daten.

Definieren Sie detaillierte Rollen und Berechtigungen für den Zugriff auf die Infrastruktur.

Integrieren Sie Security Scanning Tools in den Deployment-Prozess.

Automatisieren Sie Tests, um Fehler frühzeitig zu erkennen.

Schulen Sie Ihre Mitarbeiter im Umgang mit IaC und den damit verbundenen Sicherheitsrisiken.

Fazit:

Infrastructure-as-Code in Kombination mit der Pulumi Cloud bietet eine leistungsstarke Lösung für die sichere und kontrollierte Verwaltung von Cloud-Infrastrukturen. Durch Automatisierung, Versionskontrolle und integrierte Sicherheitsfunktionen ermöglicht IaC eine höhere Agilität, Skalierbarkeit und Compliance. Die kontinuierliche Weiterentwicklung der Plattform und die Integration neuer Sicherheitstechnologien machen Pulumi zu einer attraktiven Option für Unternehmen, die ihre IT-Infrastruktur modernisieren und gleichzeitig das Sicherheitsniveau erhöhen möchten. Zukünftige Entwicklungen werden sich voraussichtlich auf eine noch tiefere Integration von Security Intelligence und Machine Learning konzentrieren, um proaktive Bedrohungserkennung und automatisierte Reaktionsmaßnahmen zu ermöglichen.

Referenzen:

https://tsecurity.de/de/2688568/IT+Nachrichten/Infrastructure-as-Code%3A+Erweiterte+Security+und+Kontrolle+in+der+Pulumi+Cloud/

https://www.pulumi.com/terraform-vs-pulumi/

https://www.openpolicyagent.org/

https://www.hashicorp.com/vault

Snyk: https://snyk.io/

SonarQube: https://www.sonarqube.org/

Hinweis: Dieser Artikel dient zu Informationszwecken und stellt keine umfassende Anleitung zur Implementierung von IaC mit Pulumi Cloud dar. Es wird empfohlen, die offizielle Dokumentation und Schulungsmaterialien von Pulumi zu konsultieren.

ControlMonkey aims to bring order to cloud disaster recovery chaos

Tue, 25 Mar 2025 19:47:45 +0100

There are a lot of different components that make up a cloud deployment. How many of those components, across multiple cloud environments, is the typical enterprise actually backing up for proper disaster recovery? That’s a question that cloud infrastructure automation startup ControlMonkey is helping enterprises to help answer.

ControlMonkey is in the business of helping to improve cloud automation. Today the company launched its automated disaster recovery technology specifically engineered for cloud infrastructure configurations, addressing a common blind spot in enterprise disaster recovery strategies that typically focus primarily on data or application protection. The new capability provides automated backup and one-click recovery for network configurations, DNS settings, CDN configurations, firewalls, security groups and other infrastructure components that are essential for application delivery but frequently overlooked in traditional disaster recovery planning.

ControlMonkey, whose name deliberately contrasts with Netflix’s infamous “Chaos Monkey” resiliency testing tool, takes the opposite approach to its primate cousins.

“Chaos Monkey brings chaos to your cloud and ControlMonkey brings control,” Aharon Twizer, CEO and co-founder of ControlMonkey, told Network World.

How ControlMonkey uses infrastructure-as-code for disaster recovery

A key best practice for any enterprise deployment today is to use infrastructure-as-code (IaC) tools, such as Terraform to define the environment. Terraform was originally developed by Hashicorp, which was recently acquired by IBM for $6.4 billion.

ControlMonkey isn’t looking to replace Terraform, rather it’s trying to augment it for disaster recovery.

“Most companies don’t have full coverage of everything in their infrastructure within infrastructure as code, so there are a lot of blind spots—you don’t know what you don’t know,” Twizer emphasized.

On top of that he noted that keeping IaC in a state that always represents the existing configuration can be difficult. There are things like drift, people changing stuff directly in the console, and other real world scenarios that impact infrastructure.

To help solve that issue ControlMonkey uses deterministic AI algorithms to generate Terraform code, known as Hashicorp Configuration Language (HCL), for existing cloud environments, helping customers achieve 100% infrastructure as code coverage.

An increasingly common approach to IaC is known as GitOps, where configuration changes are made in the Git version control repository and then put into operation. ControlMonkey is also able to integrate with Git repositories to help provide more control of IaC changes and backup capabilities.

ControlMonkey

One-click restoration is the goal

With the complexity of cloud configurations, especially in distributed multi-cloud environments with complicated network topologies, restoration of service is often a non-trivial exercise for disaster recovery.

Twizer claims that ControlMonkey can do it in one-click. “The way it works is that ControlMonkey basically scans your entire real-world configuration, generates Terraform code out of it and then provides you one-click restoration for configuration,” he explained. “You can research, you can pinpoint what configuration was changed and when, and you can also restore it with one click.”

According to Twizer, this approach reduces recovery time by 90% compared to manual reconstruction efforts, a critical metric for network operations teams measured on minimizing downtime.

Compliance and governance integration

Disaster recovery isn’t just a ‘nice to have’ type of technology, it’s also often part of regulatory compliance.

“Part of SOC 2 and ISO 27001 talk about having disaster recovery and business continuity plans,” Twizer noted. “Infrastructure configuration is overlooked, and most solutions focus on data, but we see infrastructure as code becoming part of the compliance cycle.”

Anzeige: Terraform und Openstack für strukturierte Cloudautomation

Tue, 25 Mar 2025 07:15:50 +0100

Multicloud: Tips for getting it right

Wed, 12 Mar 2025 13:19:19 +0100

More and more companies are adopting a multicloud strategy. The goal? To maximize the flexibility and performance of their IT landscapes. They combine cloud services from different providers in a targeted way to exploit the advantages of different platforms. But without the right planning, complexity increases and can quickly lead to chaos. How do you strike the right balance between flexibility and efficiency?

For years, outsourcing IT processes to the cloud has been considered an essential step in the digitalization of companies. In addition to flexible and quickly available computing and storage infrastructure, the cloud promises a wide range of services that make it easy to set up and operate digital business processes.

However, competition among providers has led to an immense range of cloud services with a wide variety of characteristics and conditions being available on the market. At the same time, user companies are often insufficiently aware of the requirements for their own digital service that is to be operated with the cloud infrastructure. The following applies: the more precisely and in detail these requirements are defined, the better the potential that a multicloud strategy offers can be exploited.

IT conglomerates from many data sources and services

This has a huge impact on players in highly complex environments, such as the development of systems for autonomous driving or the energy networks of the future. Their business model stands and falls with the interaction of many data sources and services that are located in different clouds. But even the IT environments of companies in less complex industries often now resemble a conglomeration of local data centers, virtual machines, mobile devices and cloud services.

To manage their IT processes, many companies now work with a hybrid cloud concept that combines public and private variants as well as traditional on-premises systems. This raises the next logical step: multicloud. On the one hand, because the situation simply demands it. On the other hand, the simultaneous use of cloud services from multiple providers makes it possible to combine the advantages of the different offerings. In this way, user companies work with the solution that is best suited to their specific requirements.

Nine out of ten companies are pursuing multicloud

An approach that is catching on: nine out of ten companies surveyed worldwide already pursue a multicloud strategy, according to the Flexera 2024 State of the Cloud Report. They combine public cloud services from AWS, Microsoft Azure or Google Cloud, for example. Often, private cloud offerings from external service providers are also integrated or services are used that continue to run in the company’s own data center.

For example, when it comes to complicated calculations that are frequently executed in succession, AWS Lambda proves to be more efficient and economical than Azure Functions. However, if you work with Office 365 and other Windows-based applications, Microsoft’s Azure is the better choice. Workloads running on virtual Windows machines can be processed faster with it.

In the product development scenario mentioned above, for example, a Windows application in Azure triggers a Lambda service in AWS that performs the desired calculations. The results are stored in a database and accessed by the Azure application as needed. The database itself also runs in Azure so as not to slow down the application unnecessarily with long response times. The geographic region in which the services run also plays a role, as it can affect the performance, access times and costs of the respective application.

Growing complexity in the multicloud

It’s obvious that a multicloud strategy — regardless of what it actually looks like — will further increase complexity. This is simply because each cloud platform works with its own management tools, security protocols and performance metrics. Anyone who wants to integrate multicloud into their IT landscape needs a robust management system that can handle the specific requirements of the different environments while ensuring an overview and control across all platforms.

This is necessary not only for reasons of handling and performance but also to be as free as possible when choosing the optimal provider for the respective application scenario. This requires cross-platform technologies and tools. The large hyperscalers do provide interfaces for data exchange with other platforms as standard. However, to plan and control processes end-to-end in multicloud infrastructures, a unified interface for all applications is needed that is based on a cloud abstraction layer. This allows a company to move its workloads relatively easily, regardless of the specific requirements of individual cloud environments.

Benchmark autonomous driving

Anyone who wants to combine data from a wide variety of sources in IoT processes and analyze it quickly, as in the case of autonomous driving, for example, will not get very far without such flexibility, as the following example illustrates.

A supplier is developing an application to control the braking behavior of autonomous vehicles. To develop, test and validate the algorithms for this, terabytes and petabytes of data from a wide variety of sources are used. These include databases with images and videos of traffic lights in different countries, at different times of day and in different weather conditions, combined with data on the nature of the road surface and the tires of virtual test vehicles.

All this information has to be brought together from different clouds. The system must also be able to integrate further data sources as and when required, or to continue to use existing databases even if they are moved.

All this data must be analyzed extremely quickly in order to optimally adjust the braking force. Short latency times are therefore critical to success. An on-premises infrastructure is recommended for this. However, to accommodate the ever-increasing amounts of data, the project team is integrating AWS S3 and Azure Blob Storage.

Tools support multicloud strategy

Kubernetes

At the heart of every multicloud strategy today is Kubernetes, the de facto standard for container orchestration. It allows applications to be scaled, managed and deployed automatically — regardless of the cloud platform on which they are running. The open-source system is available in practically every public cloud, and most local cloud providers also offer Kubernetes.

There are several advantages to using Kubernetes: it ensures a high degree of flexibility when it comes to selecting the right cloud for the respective application. And it increases the availability and reliability of services. For example, Kubernetes can automatically redirect workloads to other providers if a provider fails or the connection is poor — or to make optimal use of flat-rate data volumes.

Terraform

Terraform, an open-source tool for Infrastructure as Code (IaC), is recommended for building an infrastructure for application environments. It allows you to define and manage resources such as virtual machines, networks and databases using declarative configuration files. Instead of manually creating and managing infrastructure resources, the IT or cloud architects merely describe the desired end state of their infrastructure and save it as configuration files. The configuration language HashiCorp Configuration Language (HCL) is used for the description.

Terraform then independently generates the desired state by creating, modifying or deleting the necessary resources. The whole thing can be set up as often as you like. A short command is all it takes to automatically copy an environment once it has been created. This is useful, for example, when setting up staging environments that are needed at different stages in the software development process. It is useful, for example, when developing cloud applications in highly regulated industries such as banking and insurance, aerospace, utilities and automotive.

At the same time, the declarative configuration files created with Terraform serve as a complete documentation of the infrastructure. What’s more, Terraform also monitors the status of the infrastructure and automatically detects and corrects deviations between the target and actual states.

Ansible

Ansible is another useful tool for efficient multicloud management. This open-source tool supports advanced infrastructure configuration and automation. It combines software distribution, ad-hoc command execution, and software configuration management.

Multicloud requires security

In general, anyone pursuing a multicloud strategy should take steps in advance to ensure that complexity does not lead to chaos but to more efficient IT processes. Security is one of the main issues. And it is twofold: on the one hand, the networked services must be protected in themselves and within their respective platforms. On the other hand, the entire construct with its various architectures and systems must be secure. It is well known that the interfaces are potential gateways for unwelcome “guests”.

To ensure security and performance, companies need a dedicated API concept and management for their multicloud, as well as a holistic view to identify weak points.

In addition to developing the specific skills needed for this, the use of a platform engineering team is recommended. Its task is to plan the architectures, select the technologies and choose the platform services that best suit the company’s applications. As a rule, it is also advisable to call in external multicloud experts, at least at the beginning.

AWS vs. Azure: Which platform is best for which application?

The following example of Microsoft Azure and Amazon Web Services (AWS) shows which cloud platform is best suited for which application. Both providers have almost identical pricing models and both offer services and functions as a service (FaaS) for practically every application. Nevertheless, some criteria can be used to make a qualified assessment and decision as to which platform is best suited for which application.

This involves questions such as: Do requests tend to arrive with a long time lag? Are there many or rather few requests to process? Do they arrive in a concentrated manner within a short interval? Are requests that arrive at the same time to be handled?

To compare both platforms in a well-founded manner, the use of a benchmark platform such as SeBS (Serverless Benchmarking Suite) is recommended. It offers the load scenarios cold & warm and sequential & burst — here is what they involve:

Cold & warm: When the user accesses the FaaS service, the cloud provider selects an execution spot for the function, typically a container or a virtual machine. If no execution spot exists yet, the provider generates a new one (cold). If one is already available to process the request, it is used (warm).
Sequential & Burst: Sequential sends one request after another. Burst always sends several requests simultaneously.

From the results of the benchmark tests: the average response time with Azure depends on whether many requests arrive at the same time and whether the function is warm. With AWS, on the other hand, it falls with increasing RAM — but is initially significantly higher. This makes it clear: as long as it is possible to keep the Lambda warm, AWS wins, otherwise Azure wins. Depending on the scale, the Lambda cools down again after about ten minutes.

For the application, this means if requests are to be processed at intervals of more than ten minutes, Azure has the advantage. If the requests arrive at intervals of less than ten minutes and the resource size can be estimated, AWS should be the choice.

The burst tests show that Azure is ahead for short load peaks and cold starts. However, if high loads are to be expected, the AWS Lambda is more performant. In general, the AWS results show greater consistency. So if you have strict requirements in terms of consistency of response times, you should go with AWS.

The detailed requirements and results of the benchmark test can be found in a white paper doubleSlash offers for download here: Amazon Web Services vs. Microsoft Azure.

Konrad Krafft is founder and CEO of the consulting and software company doubleSlash Net-Business GmbH. He studied general computer science with a focus on artificial intelligence and has been involved in the development of digital services for over 20 years, particularly in the area of business processes and software products. As an expert, he deals with the industrialization of software development and new digital business models.

heise-Angebot: iX-Workshop für Entwickler und Architekten: IT-Management mit Terraform

Fri, 07 Mar 2025 14:30:48 +0100

Erstellen und verwalten Sie IT- und Cloud-Infrastrukturen als Code – Grundlagen, Installation und Nutzung von Terraform.

IBM, 하시코프 인수 절차 완료··· “멀티클라우드 지원 및 AI 자동화 강화”

Fri, 28 Feb 2025 04:33:47 +0100

IBM은 하시코프 인수 완료 발표와 함께, 가능한 모든 데이터센터에 하시코프의 자동화 및 보안 기술을 도입하는 것이 목표라고 설명했다.

약 10개월에 걸쳐 진행된 이번 인수를 통해 IBM은 하시코프의 자동화 기술을 레드햇(Red Hat), 왓슨엑스(watsonx), 데이터 보안, IT 자동화 및 컨설팅 사업에 통합할 계획이다. IBM은 이미 클라우드 서비스에 하시코프 기술을 사용하고 있다.

하시코프의 주력 제품에는 고객이 여러 클라우드 서비스 업체와 온프레미스 환경에서 인프라, 네트워크 및 가상 구성 요소를 자동으로 프로비저닝할 수 있게 해주는 ‘테라폼(Terraform)’이 있다. 이 외에도 ID 기반 인증과 민감한 데이터에 대한 접근 권한 부여를 지원하는 볼트(Vault), 워크로드 오케스트레이션을 위한 노마드(Nomad), 안전한 원격 접속을 위한 바운더리(Boundary), 서비스 기반 네트워킹을 지원하는 콘술(Consul) 등의 제품군을 보유하고 있다.

하시코프가 IBM 및 레드햇과 결합하면, 고객에게 퍼블릭 클라우드 서비스 업체, 프라이빗 클라우드, 온프레미스 환경 등 진화하는 인프라 전반에 걸쳐 워크로드 배포와 오케스트레이션을 자동화할 수 있는 플랫폼을 제공할 수 있다. IBM은 이 같은 인프라 위에 레드햇 앤서블(Ansible)이 애플리케이션 구성과 미들웨어 배포를 자동화할 수 있다고 언급했다.

IBM 소프트웨어 부문 수석 부사장인 롭 토마스는 성명에서 “기업들은 초기 계획과 설계부터 클라우드 인프라와 보안 작업을 더 효율적으로 관리하고 현대화할 방법을 찾고 있다”라고 말했다.

그는 이어 “2028년까지 생성형 AI를 통해 10억 개의 새로운 클라우드 네이티브 애플리케이션이 등장할 전망이다. 이런 규모를 지원하려면 인력만으로는 불가능한 수준의 인프라 자동화가 필요하다”라고 설명했다.

하시코프의 CTO이자 공동 설립자인 아몬 다드가는 인수 완료에 관한 블로그에서 “IBM과 레드햇 포트폴리오에는 더 나은 사용자 경험을 제공하기 위해 통합할 수 있는 많은 제품이 있다”라고 설명했다.

그는 “프로비저닝을 위한 테라폼과 구성 관리를 위한 앤서블을 통합하면 인프라 자동화에 대한 엔드-투-엔드 접근 방식을 코드로 구현할 수 있고, 테라폼과 클라우더빌리티(Cloudability)를 통합하면 대규모로 비용을 관리하고 최적화하기 위한 네이티브 핀옵스(FinOps) 기능을 제공할 수 있다. 볼트를 오픈시프트(OpenShift), 앤서블, 가디움(Guardium)과 통합하면 이런 플랫폼에 높은 수준의 기밀 관리 기능을 제공하고 최종 사용자의 통합 부담을 줄일 것”이라고 말했다.
dl-ciokorea@foundryco.com

IBM closes Hashicorp buy, looks to boost enterprise multicloud and AI automation technology

Thu, 27 Feb 2025 19:49:01 +0100

In announcing the closure of its $6.4 billion buy of Hashicorp, IBM said its goal is to infuse HashiCorp automation and security technology in every data center possible.

With the deal, which was 10 months in the making, IBM plans to further integrate HashiCorp’s automation technology into its Red Hat, watsonx, data security, IT automation and consulting businesses. IBM uses Hashicorp technology in its cloud offerings already.

HashiCorp’s products include its flagship Terraform package, which lets customers automatically provision infrastructure, network, and virtual components across multiple cloud providers and on-premises environments. The company also offers Vault for identity-based authentication and to authorize access to sensitive data; Nomad for workload orchestration; Boundary for secure remote access; and Consul for service-based networking.

When combined with IBM and Red Hat, HashiCorp will give customers a platform capable of automating the deployment and orchestration of workloads across evolving infrastructure, including hyperscale cloud service providers, private clouds, and on-premises environments. Ansible could then automate application configurations and middleware deployments on top of that infrastructure, IBM stated.

Enterprises are looking for ways to more efficiently manage and modernize cloud infrastructure and security tasks from initial planning and design, according to Rob Thomas, senior vice president, IBM Software said in a statement.

“By 2028, it is projected that generative AI will lead to the creation of 1 billion new cloud-native applications. Supporting this scale requires infrastructure automation far beyond the capacity of the workforce alone,” Thomas stated.

The IBM and Red Hat portfolio also has many products we can integrate with to deliver a better user experience, wrote Armon Dadgar, CTO and cofounder of HashiCorp in a blog about the deal closure.

“Integrating Terraform for provisioning with Ansible for configuration management will enable an end-to-end approach to infrastructure automation as code, while integrating Terraform with Cloudability will bring native FinOps capabilities to manage and optimize cost at scale,” Dadgar wrote.

Vault integration with OpenShift, Ansible, and Guardium will bring world-class secrets management to those platforms and reduce the integration burden on end users, Dadgar wrote.

Accelerate IaC troubleshooting with Amazon Bedrock Agents

Tue, 25 Feb 2025 17:33:17 +0100

This post demonstrates how Amazon Bedrock Agents, combined with action groups and generative AI models, streamlines and accelerates the resolution of Terraform errors while maintaining compliance with environment security and operational guidelines.

Orbit: Open-source Nuclei security scanning and automation platform

Mon, 17 Feb 2025 06:34:04 +0100

Orbit is an open-source platform built to streamline large-scale Nuclei scans, enabling teams to manage, analyze, and collaborate on security findings. It features a SvelteKit-based web frontend and a Go-powered backend, with Terraform and Ansible handling infrastructure and automation. “I built Orbit to address the challenges of scalable and efficient security scanning. Traditional tools can be rigid and difficult to integrate into dynamic environments. Orbit was designed as a flexible, self-hosted, open-source platform that gives … More →

The post Orbit: Open-source Nuclei security scanning and automation platform appeared first on Help Net Security.

whoAMI Attack Lets Hackers Gain Code Execution in AWS Accounts via AMI Name Confusion

Fri, 14 Feb 2025 11:18:55 +0100

whoAMI Attack Lets Hackers Gain Code Execution in AWS Accounts via AMI Name Confusion

Post Views: 1

Join our Patreon Channel and Gain access to 70+ Exclusive Walkthrough Videos.

Reading Time: 3 Minutes

Security researchers have uncovered a name confusion attack that allows unauthorized access to Amazon Web Services (AWS) accounts through the manipulation of Amazon Machine Images (AMIs). The attack, dubbed “whoAMI”, was developed by DataDog researchers in August 2024 and demonstrates how attackers can gain code execution within AWS accounts by exploiting flawed AMI retrieval processes.

While Amazon addressed the issue in September 2024, the risk remains for organizations that have not updated their code or security configurations.

Exploiting AWS AMI Selection

AMIs are preconfigured virtual machines used to create AWS Elastic Compute Cloud (EC2) instances. Users typically search AWS’s catalog for the AMI ID of their desired instance. However, if the AMI search fails to specify a trusted owner, AWS may return AMIs from any public source, including malicious ones.

The whoAMI attack exploits common misconfigurations in AWS environments, such as:

Using the ec2:DescribeImages API without specifying an AMI owner, allowing AWS to return all publicly available AMIs.
Employing wildcards in AMI selection scripts rather than referencing specific AMI IDs.
Infrastructure-as-code tools (e.g., Terraform) using most_recent = true, which automatically selects the latest AMI that matches a given name—potentially choosing a malicious AMI instead of a legitimate one.

Demonstrating the retrieval of a malicious instead of a trusted AMI
Source: DataDog

See Also: So, you want to be a hacker?
Offensive Security, Bug Bounty Courses

Discover your weakest link. Be proactive, not reactive. Cybercriminals need just one flaw to strike.

How Attackers Leverage Name Confusion

By publishing an AMI with a name similar to a trusted resource, attackers can trick AWS environments into selecting their malicious AMI. If an organization’s system fetches AMIs using wildcards or improper filtering, it may unknowingly launch an EC2 instance using the attacker’s backdoored AMI.

Unlike traditional AWS account takeovers, this attack does not require breaching the victim’s account. Instead, attackers create a public AMI, name it strategically, and wait for vulnerable systems to pull and deploy it automatically.

AWS Response and Mitigation

After being alerted by DataDog, Amazon confirmed that some of its internal non-production systems were vulnerable to whoAMI attacks.

AWS released a fix on September 19, 2024, followed by a new security feature called “Allowed AMIs” in December. This feature lets customers create a whitelist of trusted AMI providers, preventing unauthorized AMI selection.

Protecting Your AWS Environment

Amazon advises all AWS users to:

Specify AMI owners when using the ec2:DescribeImages API to ensure that only trusted AMIs are retrieved.
Enable the “Allowed AMIs” feature via AWS Console → EC2 → Account Attributes → Allowed AMIs to block untrusted AMIs.
Audit and update infrastructure code (e.g., Terraform, AWS CLI, Python Boto3, Go AWS SDK) to safely retrieve AMIs.
Check for unauthorized AMIs in use by enabling AWS Audit Mode in ‘Allowed AMIs’ and switching to Enforcement Mode to block them.

Additionally, Terraform version 5.77 (released in November 2024) now warns users when "most_recent = true" is used without an owner filter, with stricter enforcement coming in Terraform 6.0.

For organizations concerned about existing risks, DataDog has released an AWS scanner to detect EC2 instances running untrusted AMIs, available on GitHub.

With attackers actively exploiting misconfigured AMI selection, AWS users must review their AMI retrieval processes to avoid falling victim to whoAMI attacks.

Are u a security researcher? Or a company that writes articles about Cyber Security, Offensive Security (related to information security in general) that match with our specific audience and is worth sharing? If you want to express your idea in an article contact us here for a quote: info@blackhatethicalhacking.com

Source: bleepingcomputer.com

Source Link

EXPLORE OUR STORE

Offensive Security & Ethical Hacking Course

Begin the learning curve of hacking now!

Information Security Solutions

Find out how Pentesting Services can help you.

Join our Community

The post whoAMI Attack Lets Hackers Gain Code Execution in AWS Accounts via AMI Name Confusion first appeared on Black Hat Ethical Hacking.

Active-Directory-Konfigurationen mit Terraform automatisieren - Computer Weekly

Thu, 13 Feb 2025 07:05:27 +0100

... server = JOOS.INT .joos.int = JOOS.INT joos.int = JOOS.INT. Copy ... So legen Sie Gruppenrichtlinien-Backups in Windows Server an. Damon Garn.

heise-Angebot: iX-Workshop für Entwickler und Architekten: IT-Management mit Terraform

Wed, 12 Feb 2025 10:15:38 +0100

Erstellen und verwalten Sie IT- und Cloud-Infrastrukturen als Code – Grundlagen, Installation und Nutzung von Terraform.

AI-powered automation set for gains in 2025

Wed, 29 Jan 2025 23:33:32 +0100

Automation technology has long been a part of IT’s arsenal, as enterprises work to simplify increasingly complex networking and operational environments. Looking ahead, the more AI is added to the automation mix, the more enterprise operations teams stand to gain.

“2025 will be the year for AI initiatives, where AI-powered automation has reached a tipping point from being a nice-to-have to a requirement,” said Bill Lobig, vice president, product management, with IBM Automation.

“Automation is needed to solve AI’s complexity. Organizations can now confidently advance and scale their AI initiatives using automation, moving from spending time managing and maintaining AI applications and IT environments, to proactively detecting and resolving issues. Automating these tasks will be critical for competitive advantage,” Lobig said.

“Next year, you won’t be able to have an AI conversation without talking about automation, and vice versa,” Lobig said.

[Read more: 5 network automation startups to watch]

Customers will be able to apply AI to data to see patterns and trends, and AI will improve the signal-to-noise ratio as companies try to sift through the metrics, logs, events, and traces that are spewing out of customer systems, Lobig said. “Most of these systems are now more complicated than ever, with hybrid cloud becoming the way many organizations operate,” Lobig said.

AI-driven automation could help close staffing gaps

Research firm Enterprise Management Associates (EMA), too, cites the infrastructure complexity that has resulted from hybrid and multi-cloud networks and the need for more advanced automation.

“EMA research finds that hybrid clouds are particularly problematic for network operations teams today. They’re struggling with complexity there. Better automation could help,” said Shamus McGillicuddy, vice president of research at EMA.

Today’s vendors are developing AI and ML algorithms that can detect anomalies, identify the root causes of problems, and predict changes in network utilization, McGillicuddy said.

“By integrating these AI insights with network automation tools, IT organizations can trigger automated workflows that resolve problems, adjust capacity, and make other proactive changes to ensure infrastructure resilience.”

That’s more important than ever, especially given that IT organizations are often understaffed, particularly in network engineering, McGillicuddy said. “They’re also tasked with supporting new initiatives and reducing costs. AI-driven automation can help them close staffing gaps, reduce costs, and be more responsive to changing business need,” McGillicuddy said.

There are dozens of automation tools available today – including Yang, Ansible, Terraform and Puppet, to name just a few – and vendors are in different stages of development in terms of AI-enabled capabilities.

“There are many companies leveraging AI-driven automation today. However, vendors vary in their level of maturity with AI today,” McGillicuddy said. “Some are just getting started. Others have been delivering solutions for a couple years. EMA research shows that only 42% of organizations trust the AI-driven capabilities of their network observability tools today.”

Network teams are happy to leverage AI insights, but they’re not ready to remove humans from the equation. Closed-loop, AI-driven automation will not be mainstream in 2025, McGillicuddy added.

AI-driven tools will slash network configuration errors, Cisco predicts

More than 40% of network outages are caused by misconfigurations, and those outages can cost businesses 9% of their annual revenue, stated Liz Centoni, Cisco’s executive vice president and chief customer experience officer.

“As such, one of the most promising developments on the horizon is the potential for AI to virtually eliminate these manual misconfiguration mishaps,” Centoni wrote in a blog about 2025 technology trends.

“Intelligent, automated tools can execute automated workflows throughout the network lifecycle and provide traceability for every action. AI-driven tools are set to revolutionize network management and assurance, learning and benchmarking from each configuration to reduce errors and ensure uninterrupted operations,” Centoni wrote. “We will see misconfigurations decline rapidly as AI adoption grows, making automation accessible to more organizations, and we expect to see network downtime caused by human error rapidly approach zero.”

Just as vendors are at different stages of AI-driven automation, so, too, are enterprises.

The ultimate impact of AI and automation really depends on where customers are in their digital journey, with some still managing networks manually and others more advanced, said Matt Gillies, Cisco Fellow, vice president, and chief architect, global solutions.

“Any time there’s a manual operation, it’s an opportunity to automate,” Gillies said. Hyperscalers such as Microsoft and Meta have built their own automation tools, “and they’ve done that for a long period of time because of the velocity of that business – they need to scale rapidly,” Gillies said. “But we have a lot of customers that still manage their networks with spreadsheets and swivel chairs.”

“But the cost of outages related to misconfiguration, in particular, has just become too risky for many businesses, and so I would say there’s a renewed focus on automation,” Gillies said.

Network observability boosted by AI

Another area where automation can potentially make a big impact is network observability.

Cisco ThousandEyes provides digital experience monitoring to give customers greater insight into their network operations. ThousandEyes network intelligence agents are software probes placed throughout the enterprise network infrastructure, including data center endpoints, routers and switches, cloud-based resources and branches.

Cisco says there are tens of thousands of ThousandEyes agents spread across the internet and enterprise networks, and the platform is powered by more than 650 billion daily measurements globally.

“Being able to automate network performance management and respond to trouble spots quickly will help organizations solve problems quickly, so customers won’t be waiting for help desk calls. [The] pace of response will be so much faster than it ever was before,” Gillies said.

Adding AI to the ThousandEyes package will improve the software’s ability to spot the source of a problem and prioritize which incidents require immediate attention, Gillies added.

A need for greater network and system visibility is also an important driver for enterprises to consolidate some of their myriad management tools.

“Many NetOps teams will replace and/or consolidate the tools they use to monitor, troubleshoot, and optimize their networks,” said EMA’s McGillicuddy.

“They’ll look for solutions that can collect large and diverse data set and apply AI and advanced analytics to deliver advanced event correlation, intelligent alerting, and automated root cause analysis. Much of this consolidation will occur in the network management tools, but many IT organizations will try to consolidate across IT teams to enable a cross-domain observability portfolio,” McGillicuddy said.

AI, automation and high-performance workloads

AI-driven automation gains could also be directed at making AI workloads easier to deploy, run and manage, IBM’s Lobig said.

One example is in Kubernetes environments, which are becoming the default runtime choice for AI workloads and LLMs.

“Kubernetes automatically scales up and down, but it does so by spawning and or destroying nodes. And nodes have a fixed, defined configuration [with] memory, storage, compute and GPUs attached. And so, customers could have a situation where they need more memory, spawn up a new node, and that new node definition has like eight GPUs attached to it, because that’s a statically defined thing. And suddenly they are paying for all these GPUs that they are not using,” Lobig said.

“AI and automation can bring intelligence to how workloads are scheduled and scaled across large environments,” Lobig said.

heise+ | IaC für Bare Metal-Systeme mit Terraform-Foreman-Provider verwalten

Thu, 23 Jan 2025 15:15:43 +0100

Bare Metal in der Multicloud: Der Terraform Foreman Provider integriert die Fähigkeiten des Lifecycle-Managers Foreman in das Multi-Cloud-Werkzeug Terraform.

Designing, Building & Deploying an AI Chat App from Scratch (Part 2)

Mon, 20 Jan 2025 11:04:37 +0100

Cloud Deployment and Scaling

Photo by Alex wong on Unsplash

1. Introduction

In the previous post, we built an AI-powered chat application on our local computer using microservices. Our stack included FastAPI, Docker, Postgres, Nginx and llama.cpp. The goal of this post is to learn more about the fundamentals of cloud deployment and scaling by deploying our app to Azure, making it available to real users. We’ll use Azure because they offer a free education account, but the process is similar for other platforms like AWS and GCP.

You can check a live demo of the app at chat.jorisbaan.nl. Now, obviously, this demo isn’t very large-scale, because the costs ramp up very quickly. With the tight scaling limits I configured I reckon it can handle about 10–40 concurrent users until I run out of Azure credits. However, I do hope it demonstrates the principles behind a scalable production system. We could easily configure it to scale to many more users with a higher budget.

I give a complete breakdown of our infrastructure and the costs at the end. The codebase is at https://github.com/jsbaan/ai-app-from-scratch.

A quick demo of the app at chat.jorisbaan.nl. We start a new chat, come back to that same chat, and start another chat.

1.1. Recap: local application

Let’s recap how we built our local app: A user can start or continue a chat with a language model by sending an HTTP request to http://localhost. An Nginx reverse proxy receives and forwards the request to a UI over a private Docker network. The UI stores a session cookie to identify the user, and sends requests to the backend: the language model API that generates text, and the database API that queries the database server.

Local architecture of the app. See part 1 for more details. Made by author in draw.io.

Introduction
1.1 Recap: local application
Cloud architecture
2.1 Scaling
2.2 Kubernetes Concepts
2.3 Azure Container Apps
2.4 Azure architecture: putting it all together
Deployment
3.1 Setting up
3.2 PostgreSQL server deployment
3.3 Azure Container App Environment deployment
3.4 Azure Container Apps deployment
3.5 Scaling our Container Apps
3.6 Custom domain name & HTTPS
Resources & costs overview
Roadmap
Final thoughts
Acknowledgements
AI usage

2. Cloud architecture

Conceptually, our cloud architecture will not be too different from our local application: a bunch of containers in a private network with a gateway to the outside world, our users.

However, instead of running containers on our local computer with Docker Compose, we will deploy them to a computing environment that automatically scales across virtual or psychical machines to many concurrent users.

2.1 Scaling

Scaling is a central concept in cloud architectures. It means being able to dynamically handle varying numbers of users (i.e., HTTP requests). Uvicorn, the web server running our UI and database API, can already handle about 40 concurrent requests. It’s even possible to use another web server called Gunicorn as a process manager that employs multiple Uvicorn workers in the same container, further increasing concurrency.

Now, if we want to support even more concurrent request, we could give each container more resources, like CPUs or memory (vertical scaling). However, a more reliable approach is to dynamically create copies (replicas) of a container based on the number of incoming HTTP requests or memory/CPU usage, and distribute the incoming traffic across replicas (horizontal scaling). Each replica container will be assigned an IP address, so we also need to think about networking: how to centrally receive all requests and distribute them over the container replicas.

This “prism” pattern is important: requests arrive centrally in some server (a load balancer) and fan out for parallel processing to multiple other servers (e.g., several identical UI containers).

Photo of two prisms by Fernando @cferdophotography on Unsplash

2.2 Kubernetes Concepts

Kubernetes is the industry standard system for automating deployment, scaling and management of containerized applications. Its core concepts are crucial to understand modern cloud architectures, including ours, so let’s quickly review the basics.

Node: A physical or virtual machine to run containerized app or manage the cluster.
Cluster: A set of Nodes managed by Kubernetes.
Pod: The smallest deployable unit in Kubernetes. Runs one main app container with optional secondary containers that share storage and networking.
Deployment: An abstraction that manages the desired state of a set of Pod replicas by deploying, scaling and updating them.
Service: An abstraction that manages a stable entrypoint (the service’s DNS name) to expose a set of Pods by distributing incoming traffic over the various dynamic Pod IP addresses. A Service has multiple types:
- A ClusterIP Service exposes Pods within the Cluster
- A LoadBalancer Service exposes Pods to outside the Cluster. It triggers the cloud provider to provision an external public IP and load balancer outside the cluster that can be used to reach the cluster. These external requests are then routed via the Service to individual Pods.
Ingress: An abstraction that defines more complex rules for a cluster’s entrypoint. It can route traffic to multiple Services; give Services externally-reachable URLs; load balance traffic; and handle secure HTTPS.
Ingress Controller: Implements the Ingress rules. For example, an Nginx-based controller runs an Nginx server (like in our local app) under the hood that is dynamically configured to route traffic according to Ingress rules. To expose the Ingress Controller itself to the outside world, you can use a LoadBalancer Service. This architecture is often used.

2.3 Azure Container Apps

Armed with these concepts, instead of deploying our app with Kubernetes directly, I wanted to experiment a little by using Azure Container Apps (ACA). This is a serverless platform built on top of Kubernetes that abstracts away some of its complexity.

With a single command, we can create a Container App Environment, which, under the hood, is an invisible Kubernetes Cluster managed by Azure. Within this Environment, we can run a container as a Container App that Azure internally manages as Kubernetes Deployments, Services, and Pods. See article 1 and article 2 for detailed comparisons.

A Container App Environment also auto-creates:

An invisible Envoy Ingress Controller that routes requests to internal Apps and handles HTTPS and App auto-scaling based on request volume.
An external Public IP address and Azure Load Balancer that routes external traffic to the Ingress Controller that in turn routes it to Apps (sounds similar to a Kubernetes LoadBalancer Service, eh?).
An Azure-generated URL for each Container App that is publicly accessible over the internet or internal, based on its Ingress config.

This gives us everything we need to run our containers at scale. The only thing missing is a database. We will use an Azure-managed PostgreSQL server instead of deploying our own container, because it’s easier, more reliable and scalable. Our local Nginx reverse proxy container is also obsolete because ACA automatically deploys an Envoy Ingress Controller.

It’s interesting to note that we literally don’t have to change a single line of code in our local application, we can just treat it as a bunch of containers!

2.4 Azure architecture: putting it all together

Here is a diagram of the full cloud architecture for our chat application that contains all our Azure resources. Let’s take a high level look at how a user request flows through the system.

Azure architecture diagram. Made by author in draw.io.

User sends HTTPS request to chat.jorisbaan.nl.
A Public DNS server like Google DNS resolves this domain name to an Azure Public IP address.
The Azure Load Balancer on this IP address routes the request to the (for us invisible) Envoy Ingress Controller.
The Ingress Controller routes the request to UI Container App, who routes it to one of its Replicas where a UI web server is running.
The UI web server makes requests to the database API and language model API Apps, who both route it to one of their Replicas.
A database API replica queries the PostgreSQL server hostname. The Azure Private DNS Zone resolves the hostname to the PostgreSQL server’s IP address.

3. Deployment

So, how do we actually create all this? Rather than clicking around in the Azure Portal, infrastructure-as-code tools like Terraform are best to create and manage cloud resources. However, for simplicity, I will instead use the Azure CLI to create a bash script that deploys our entire application step by step. You can find the full deployment script including environment variables here 🤖. We will go through it step by step now.

3.1 Setting up

We need an Azure account (I’m using a free education account), a clone of the https://github.com/jsbaan/ai-app-from-scratch repo, Docker to build and push the container images, the downloaded model, and the Azure CLI to start creating cloud resources.

We first create a resource group so our resources are easier to find, manage and delete. The --location parameter refers to the physical datacenter we’ll use to deploy our app’s infrastructure. Ideally, it is close to our users. We then create a private virtual network with 256 IP addresses to isolate, secure and connect our database server and Container Apps.

brew update && brew install azure-cli # for macos

echo "Create resource group"
az group create \
  --name $RESOURCE_GROUP \
  --location "$LOCATION"
  
echo "Create VNET with 256 IP addresses"
az network vnet create \
  --resource-group $RESOURCE_GROUP \
  --name $VNET \
  --address-prefix 10.0.0.0/24 \
  --location $LOCATION

3.2 PostgreSQL server deployment

Depending on the hardware, an Azure-managed PostgreSQL database server costs about $13 to $7000 a month. To communicate with Container Apps, we put the DB server within the same private virtual network but in its own subnet. A subnet is a dedicated range of IP addresses that can have its own security and routing rules.

We create the Azure PostgreSQL Flexible Server with private access. This means only resources within the same virtual network can reach it. Azure automatically creates a Private DNS Zone that manages a hostname for the database that resolves to its IP address. The database API will later use this hostname to connect to the database server.

We will randomly generate the database credentials and store them in a secure place: Azure KeyVault.

echo "Create subnet for DB with 128 IP addresses"
az network vnet subnet create \
  --resource-group $RESOURCE_GROUP \
  --name $DB_SUBNET \
  --vnet-name $VNET \
  --address-prefix 10.0.0.128/25

echo "Create a key vault to securely store and retrieve secrets, \
like the db password"
az keyvault create \
  --name $KEYVAULT \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION

echo "Give myself access to the key vault so I can store and retrieve \
the db password"
az role assignment create \
  --role "Key Vault Secrets Officer" \
  --assignee $EMAIL \
  --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$KEYVAULT"

echo "Store random db username and password in the key vault"
az keyvault secret set \
  --name postgres-username \
  --vault-name $KEYVAULT  \
  --value $(openssl rand -base64 12 | tr -dc 'a-zA-Z' | head -c 12)
az keyvault secret set \
  --name postgres-password \
  --vault-name $KEYVAULT  \
  --value $(openssl rand -base64 16)

echo "While we're at it, let's already store a secret session key for the UI"
az keyvault secret set \
  --name session-key \
  --vault-name $KEYVAULT  \
  --value $(openssl rand -base64 16)
 
echo "Create PostgreSQL flexible server in our VNET in its own subnet. \
Auto-creates Private DS Zone."
POSTGRES_USERNAME=$(az keyvault secret show --name postgres-username --vault-name $KEYVAULT --query "value" --output tsv)
POSTGRES_PASSWORD=$(az keyvault secret show --name postgres-password --vault-name $KEYVAULT --query "value" --output tsv)
az postgres flexible-server create \
  --resource-group $RESOURCE_GROUP \
  --name $DB_SERVER \
  --vnet $VNET \
  --subnet $DB_SUBNET \
  --location $LOCATION \
  --admin-user $POSTGRES_USERNAME \
  --admin-password $POSTGRES_PASSWORD \
  --sku-name Standard_B1ms \
  --tier Burstable \
  --storage-size 32 \
  --version 16 \
  --yes

3.3 Azure Container App Environment deployment

With the network and database in place, let’s deploy the infrastructure to run containers — the Container App Environment (recall, this is a Kubernetes cluster under the hood).

We create another subnet with 128 IP addresses and delegate its management to the Container App Environment. The subnet should be big enough for every ten new replicas to get a new IP address in the subrange. We can then create the Environment. This is just a single command without much configuration.

echo "Create subnet for ACA with 128 IP addresses."
az network vnet subnet create \
  --resource-group $RESOURCE_GROUP \
  --name $ACA_SUBNET \
  --vnet-name $VNET \
  --address-prefix 10.0.0.0/25

echo "Delegate the subnet to ACA"
az network vnet subnet update \
  --resource-group $RESOURCE_GROUP \
  --vnet-name $VNET \
  --name $ACA_SUBNET \
  --delegations Microsoft.App/environments
  
echo "Obtain the ID of our subnet"
ACA_SUBNET_ID=$(az network vnet subnet show \
  --resource-group $RESOURCE_GROUP \
  --name $ACA_SUBNET \
  --vnet-name $VNET \
  --query id --output tsv)
  
echo "Create Container Apps Environment in our custom subnet.\\
By default, it has a Workload profile with Consumption plan."
az containerapp env create \
  --resource-group $RESOURCE_GROUP \
  --name $ACA_ENVIRONMENT \
  --infrastructure-subnet-resource-id $ACA_SUBNET_ID \
  --location $LOCATION

3.4 Azure Container Apps deployment

Each Container App needs a Docker image to run. Let’s first setup a Container Registry, and then build all our images locally and push them to the registry. Note that we simply copied the model file into the language model image using its Dockerfile, so we don’t need to mount external storage like we did for local deployment in part 1.

echo "Create container registry (ACR)"
az acr create \\
  --resource-group $RESOURCE_GROUP \\
  --name $ACR \\
  --sku Standard \\
  --admin-enabled true
  
echo "Login to ACR and push local images"
az acr login --name $ACR
docker build --tag $ACR.azurecr.io/$DB_API $DB_API
docker push $ACR.azurecr.io/$DB_API
docker build --tag $ACR.azurecr.io/$LM_API $LM_API
docker push $ACR.azurecr.io/$LM_API
docker build --tag $ACR.azurecr.io/$UI $UI
docker push $ACR.azurecr.io/$UI

Now, onto deployment. To create Container Apps we specify their Environment, container registry, image, and the port they will listen to for requests. The ingress parameter regulates whether Container Apps can be reached from the outside world. Our two APIs are internal and therefore completely isolated, with no public URL and no traffic ever routed from the Envoy Ingress Controller. The UI is external and has a public URL, but sends internal HTTP requests over the virtual network to our APIs. We pass these internal hostnames and db credentials as environment variables.

echo "Deploy DB API on Container Apps with the db credentials from the key \
vault as env vars. More secure is to use a managed identity that allows the \
container itself to retrieve them from the key vault. But for simplicity we \
simply fetch it ourselves using the CLI."
POSTGRES_USERNAME=$(az keyvault secret show --name postgres-username --vault-name $KEYVAULT --query "value" --output tsv)
POSTGRES_PASSWORD=$(az keyvault secret show --name postgres-password --vault-name $KEYVAULT --query "value" --output tsv)
az containerapp create --name $DB_API \
  --resource-group $RESOURCE_GROUP \
  --environment $ACA_ENVIRONMENT \
  --registry-server $ACR.azurecr.io \
  --image $ACR.azurecr.io/$DB_API \
  --target-port 80 \
  --ingress internal \
  --env-vars "POSTGRES_HOST=$DB_SERVER.postgres.database.azure.com" "POSTGRES_USERNAME=$POSTGRES_USERNAME" "POSTGRES_PASSWORD=$POSTGRES_PASSWORD" \
  --min-replicas 1 \
  --max-replicas 5 \
  --cpu 0.5 \
  --memory 1

echo "Deploy UI on Container Apps, and retrieve the secret random session \
key the UI uses to encrypt session cookies"
SESSION_KEY=$(az keyvault secret show --name session-key --vault-name $KEYVAULT --query "value" --output tsv)
az containerapp create --name $UI \
  --resource-group $RESOURCE_GROUP \
  --environment $ACA_ENVIRONMENT \
  --registry-server $ACR.azurecr.io \
  --image $ACR.azurecr.io/$UI \
  --target-port 80 \
  --ingress external \
  --env-vars "db_api_url=http://$DB_API" "lm_api_url=http://$LM_API" "session_key=$SESSION_KEY" \
  --min-replicas 1 \
  --max-replicas 5 \
  --cpu 0.5 \
  --memory 1 
  
echo "Deploy LM API on Container Apps"
az containerapp create --name $LM_API \
  --resource-group $RESOURCE_GROUP \
  --environment $ACA_ENVIRONMENT \
  --registry-server $ACR.azurecr.io \
  --image $ACR.azurecr.io/$LM_API \
  --target-port 80 \
  --ingress internal \
  --min-replicas 1 \
  --max-replicas 5 \
  --cpu 2 \
  --memory 4 \
  --scale-rule-name my-http-rule \
  --scale-rule-http-concurrency 2

3.5 Scaling our Container Apps

Let’s take a look at how our Container Apps they scale. Container Apps can scale to zero, which means they have zero replicas and stop running (and stop incurring costs). This is a feature of the serverless paradigm, where infrastructure is provisioned on demand. The invisible Envoy proxy handles scaling based on triggers, like concurrent HTTP requests. Spawning new replicas may take some time, which is called cold-start. We set the minimum number of replicas to 1 to avoid cold starts and the resulting timeout errors for first requests.

The default scaling rule creates a new replica whenever an existing replica receives 10 concurrent HTTP requests. This applies to the UI and the database API. To test whether this scaling rule makes sense, we would have to perform load testing to simulate real user traffic and see what each Container App replica can handle individually. My guess is that they can handle a lot more concurrent request than 10, and we could relax the rule.

3.5.1 Scaling language model inference.

Even with our small, quantized language model, inference requires much more compute than a simple FastAPI app. The inference server handles incoming requests sequentially, and the default Container App resources of 0.5 virtual CPU cores and 1GB memory result in very slow response times: up to 30 seconds for generating 128 tokens with a context window of 1024 (these parameters are defined in the LM API’s Dockerfile).

Increasing vCPU to 2 and memory to 4GB gives much better inference speed, and handles about 10 requests within 30 seconds. I configured the http scaling rule very tightly at 2 concurrent requests, so whenever 2 users chat at the same time, the LM API will scale out.

With 5 maximum replicas, I think this will allow for roughly 10–40 concurrent users, depending on the length of the chat histories. Now, obviously, this isn’t very large-scale, but with a higher budget, we could increase vCPUs, memory and the number of replicas. Ultimately we would need to move to GPU-based inference. More on that later.

3.6 Custom domain name & HTTPS

The automatically generated URL from the UI App looks like https://chat-ui.purplepebble-ac46ada4.germanywestcentral.azurecontainerapps.io/. This isn’t very memorable, so I want to make our app available as subdomain on my website: chat.jorisbaan.nl.

I simply add two DNS records on my domain registrar portal (like GoDaddy). A CNAME record that links my chat subdomain to the UI’s URL, and TXT record to prove ownership of the subdomain to Azure and obtain a TLS certificate.

# Obtain UI URL and verification code
URL=$(az containerapp show -n $UI -g $RESOURCE_GROUP -o tsv --query "properties.configuration.ingress.fqdn")
VERIFICATION_CODE=$(az containerapp show -n $UI -g $RESOURCE_GROUP -o tsv --query "properties.customDomainVerificationId")

# Add a CNAME record with the URL and a TXT record with the verification code to domain registrar
# (Do this manually)

# Add custom domain name to UI App
az containerapp hostname add --hostname chat.jorisbaan.nl -g $RESOURCE_GROUP -n $UI
# Configure managed certificate for HTTPS
az containerapp hostname bind --hostname chat.jorisbaan.nl -g $RESOURCE_GROUP -n $UI --environment $ACA_ENVIRONMENT --validation-method CNAME

Container Apps manages a free TLS certificate for my subdomain as long as the CNAME record points directly to the container’s domain name.

The public URL for the UI changes whenever I tear down and redeploy an Environment. We could use a fancier service like Azure Front Door or Application Gateway to get a stable URL and act as reverse proxy with additional security, global availability, and edge caching.

4. Resources & costs overview

Now that the app is deployed, let’s look at an overview of all the Azure resources it app uses. We created most of them ourselves, but Azure also automatically created a Load balancer, Public IP, Private DNS Zone, Network Watcher and Log Analytics workspace.

Screenshot of all resources from Azure Portal.

Some resources are free, others are free up to a certain time or compute budget, which is part of the reason I chose them. The following resources incur the highest costs:

Load Balancer (standard Tier): free for 1 month, then $18/month.
Container Registry (standard Tier): free for 12 months, then $19/month.
PostgreSQL Flexible Server (Burstable B1MS Compute Tier): free for 12 months, then at least $13/month.
Container App: Free for 50 CPU hours/month or 2M requests/month, then $10/month for an App with a single replica, 0.5 vCPUs and 1GB memory. The LM API with 2vCPUs, 4GB memory costs about $50 per month for a single replica.

You can see that the costs of this small (but scalable) app can quickly add up to hundreds of dollars per month, even without a GPU server to run a stronger language model! That’s the reason why the app probably won’t be up when you’re reading this.

It also becomes clear that Azure Container Apps is more expensive then I initially thought: it requires a standard-Tier Load balancer for automatic external ingress, HTTPS and auto-scaling. We could get around this by disabling external ingress and deploying a cheaper alternative — like a VM with a custom reverse proxy, or a basic-Tier Load balancer. Still, a standard-tier Kubernetes cluster would have cost at least $150/month, so ACA can be cheaper at small scale.

5. Roadmap

Now, before we wrap up, let’s look at just a few of the many directions to improve this deployment.

Continuous Integration & Continuous Deployment. I would set up a CI/CD pipeline that runs unit and integration tests and redeploys the app upon code changes. It might be triggered by a new git commit or merged pull request. This will also make it easier to see when a service isn’t deployed properly. I would also set up monitoring and alerting to be aware of issues quickly (like a crashing Container App instance).

Lower latency: the language model server. I would load test the whole app — simulating real-world user traffic — with something like Locust or Azure Load Testing. Even without load testing, we have an obvious bottleneck: the LM server. Small and quantized as it is, it can still take up quite a while for lengthy answers, with no concurrency. For more users it would be faster and more efficient to run a GPU inference server with a batching mechanism that collects multiple generation requests in a queue — perhaps with Kafka — and runs batch inference on chunks.

With even more users, we might want several GPU-based LM servers that consume from the same queue. For GPU infrastructure I’d look into Azure Virtual Machines or something more fancy like Azure Machine Learning.

The llama.cpp inference engine is good for single-user CPU-based inference. When moving to a GPU-server, I would look into inference engines more suitable to batch inference, like vLLM or Huggingface TGI. And, obviously, a better (bigger) model for increased response quality — depending on the use case.

6. Final thoughts

I hope this project offers a glimpse of what an AI-powered web app in production may look like. I tried to balance realistic engineering with cutting about every corner to keep it simple, cheap, understandable, and limit my time and compute budget. Sadly, I cannot keep the app live for long since it would quickly cost hundreds of dollars per month. If someone can help with Azure credits to keep the app running, let me know!

Some closing thoughts about using managed services: Although Azure Container Apps abstracts away some of the Kubernetes complexity, it’s still extremely useful to have an understanding of the lower-level Kubernetes concepts. The automatically created invisible infrastructure like Public IPs, Load balancers and ingress controllers add unforeseen costs and make it difficult to understand what’s going on. Also, ACA documentation is limited compared to Kubernetes. However, if you know what you’re doing, you can set something up very quickly.

Acknowledgements

I heavily relied on the Azure docs, and the ACA docs in particular. Thanks to Dennis Ulmer for proofreading and Lucas de Haas for useful discussion.

AI usage

I experimented a bit more with AI tools compared to part 1. I used Pycharm’s CoPilot plugin for code completion and had quite some back-and-forth with ChatGPT to learn about the Azure or Kubernetes ecosystem, and to spar about bugs. I double-checked everything in the docs and most of the information was solid. Like part 1, I did not use AI to write this post, though I did use ChatGPT to paraphrase some bad-running sentences.

Designing, Building & Deploying an AI Chat App from Scratch (Part 2) was originally published in Towards Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.

El laberinto de la nube: un enfoque de cinco fases para optimizar la estrategia

Wed, 08 Jan 2025 11:19:10 +0100

En el acelerado panorama digital actual, la nube se ha convertido en una piedra angular de la infraestructura empresarial moderna, ofreciendo una escalabilidad, agilidad y rentabilidad incomparables. Sin embargo, a medida que las organizaciones migran cada vez más a la nube, los CIO se enfrentan al enorme desafío de navegar por un ecosistema de nube complejo y en rápida evolución. Con la revolución de la IA en marcha, que ha dado inicio a la ola de transformación digital, es imperativo que las empresas construyan su infraestructura en la nube sobre bases sólidas que les permitan escalar las soluciones de IA/ML de manera eficaz y eficiente. De lo contrario, las empresas tendrán dificultades para obtener valor comercial con capacidades de IA/ML que soportarán los altos costes de la nube, como ha sucedido para muchas empresas en 2024 con las soluciones de IA.

Para emprender con éxito su viaje a la nube, las empresas y los CIO deben seguir un proceso de cinco pasos a través de un marco de trabajo de rastreo, recorrido y ejecución. Este proceso los guiará en:

Seleccionar el proveedor de nube adecuado: elegir el proveedor que mejor se adapte a sus necesidades específicas y objetivos estratégicos.
Garantizar una base sólida: construir la infraestructura de la nube correctamente desde el principio para evitar reparaciones costosas y que consumen mucho tiempo más adelante.
Fomentar una mentalidad orientada a los ingresos: cultivar una cultura que aproveche la nube para generar nuevas fuentes de ingresos y aumentar la rentabilidad.
Promoción de la conciencia y la educación sobre la nube: capacitación de equipos comerciales y de TI sobre modelos financieros y mejores prácticas en la nube.
Impulsar la rentabilidad y la escalabilidad: desarrollar una cultura que priorice la arquitectura de soluciones en la nube que sean rentables y escalables, y que en última instancia se conviertan en parte integral del ADN de la organización.

1. CRAWL: Diseñe una estrategia de nube sólida y aborde la modernización con la mentalidad adecuada

Las empresas modernas deben ser extremadamente ágiles en su capacidad de responder rápidamente a mercados, eventos, economías basadas en suscripciones y clientes que exigen una “excelente experiencia” que cambian rápidamente para crecer y mantenerse en el mundo competitivo y despiadado del consumismo. La capacidad de la infraestructura en la nube para adaptarse, escalar y ser maleable para satisfacer las necesidades comerciales en el lugar donde se encuentran y luego permitirles expandirse la convierte en la opción predeterminada. Con la llegada de la creciente adopción de la IA, una base sólida en la nube es un requisito previo.

Consideraciones clave para la estrategia y modernización de la nube

El “qué”: El equipo de liderazgo ejecutivo de negocios y TI en conjunto debe evaluar las necesidades del negocio y sus desafíos comerciales actuales, su presencia global y el panorama tecnológico actual, y definir la “estrella del norte” de la empresa (es decir, el “qué”, la visión).
El “por qué”: Establezca principios empresariales claros que expliquen por qué está haciendo esto. Por ejemplo, para ofrecer un servicio más rápido y de mejor calidad a los clientes, una implementación más rápida de nuevos productos y servicios, para aumentar los ingresos y los márgenes de ganancia mientras se controlan los costos, la sostenibilidad o la expansión del mercado, por nombrar algunos.
Una empresa con una fuerte presencia global se beneficia más si sigue una estrategia multicloud. Evita la dependencia de un proveedor, ofrece una herramienta para una negociación sólida, permite flexibilidad empresarial en la ejecución de la estrategia debido a una arquitectura complicada o limitaciones regionales en términos de seguridad y cumplimiento legal, si es que surgen, y promueve la portabilidad desde una perspectiva de arquitectura de aplicaciones. En algunos casos, el dominio empresarial en el que opera la organización (es decir, atención médica, finanzas, seguros) conduce comprensiblemente a la decisión de elegir un único proveedor de nube para simplificar la logística, la privacidad de los datos, el cumplimiento y las operaciones.
Estrategia de modernización tecnológica: evaluar el panorama general de TI a través de la perspectiva de la arquitectura empresarial y evaluar las aplicaciones de TI a través de un marco de 7R (reubicación, reubicación y traslado, reorganización, reemplazo, refactorización, rediseño, retiro, retención). La evaluación brinda información sobre el estado actual de la arquitectura y las cargas de trabajo, y relaciona las necesidades tecnológicas con los objetivos comerciales.

Las tres primeras consideraciones están impulsadas por el negocio, y la última por las TI. La arquitectura empresarial es el puente capaz de unir los dos cabos sueltos, derribando los silos e impulsando la transformación de la nube y la estrategia de ejecución de manera efectiva. Este nuevo paradigma del modelo operativo es el sello distintivo de una transformación organizacional exitosa. Todos los principales proveedores de la nube de América del Norte (AWS, Google, Microsoft Azure, Oracle Cloud) están a la par entre sí, y la mayoría de sus servicios y capacidades están preparados para abordar las necesidades de cualquier empresa.

Dicho esto, hay un par de aspectos que me gustaría destacar. En primer lugar, el aprovisionamiento en la nube a través de la automatización es mejor en AWS (CloudFormation) y Azure (Azure Resource Manager) en comparación con otros proveedores de servicios en la nube. Para las empresas más grandes con una estrategia multicloud, Terraform es la mejor manera de solucionar esa deficiencia.

En segundo lugar, desde una perspectiva de seguridad en la nube, Azure tiene una herramienta de seguridad en la nube integral que viene como un paquete y puede integrarse perfectamente con sus servicios, mejorando así la postura de seguridad en la nube sin la necesidad de comprar una herramienta externa.

2. WALK: Establecer un sólido marco técnico y modelo de gobernanza de la nube

Una vez que se ha decidido por un proveedor de servicios en la nube, ¿cómo empieza una empresa a trabajar en la nube? Se sorprendería, pero muchas empresas siguen empezando sin tener un plan. Después de todo, ¿qué tan difícil puede ser? Se obtiene una suscripción y se empiezan a implementar recursos. Probablemente eso funcione bien con entornos muy pequeños, pero pronto se descubrirá que crece más allá de su capacidad. Se está preparando para un shock de nubes. No es broma.

A partir de entonces, se inventaron marcos bien diseñados para ayudar a los clientes a crear entornos en nubes públicas proporcionándoles las mejores prácticas. La buena noticia es que todos los marcos de los principales proveedores de la nube hacen lo mismo:

Excelencia operativa
Seguridad
Optimización de costes
Fiabilidad
Eficiencia en el rendimiento
Sostenibilidad

El marco ayuda a implementar los controles financieros (FinOps) que analizaremos por separado, la gestión de cargas de trabajo (BaseOps) y los controles de seguridad (SecOps). En este punto del proceso, es el momento adecuado para establecer una práctica de Centro de excelencia (CoE) en la nube, colaborar con ingenieros, arquitectos y la comunidad DevSecOps y publicar la versión personalizada de un marco bien diseñado que se adapte a las necesidades de cada empresa y establezca un artefacto estándar. Esto sirve como base para impulsar la adopción de la nube y comenzar con un cambio de mentalidad sobre cómo “ganar dinero con la nube” y no solo ahorrar costes.

Es una buena idea establecer una política de gobernanza que respalde el marco. Esto incluye la creación de zonas de aterrizaje, la definición de la VPN, las conexiones de puerta de enlace, las políticas de red, las políticas de almacenamiento, el alojamiento de servicios clave dentro de una subred privada y la configuración de las políticas de IAM adecuadas (políticas de recursos, configuración de la organización, políticas de eliminación). Crear conciencia sobre la política de privilegios mínimos y abordar las frustraciones cuando los usuarios de la nube piden más con qué jugar, y como equipo de CoE en la nube, usted está defendiendo su postura.

El equipo de CoE en la nube debe recopilar comentarios de los usuarios y ajustar las políticas a lo largo del camino según lo considere necesario. A medida que la comunidad de usuarios empresariales madura a través de esta curva de aprendizaje, el equipo de CoE tiene un papel fundamental que desempeñar al involucrarlos de manera proactiva, brindarles apoyo, satisfacer sus necesidades y ayudarlos a abordar sus puntos débiles para sentar una base sólida para construir una infraestructura de nube sólida que sea escalable para brindar valor comercial.

La colaboración con el equipo de arquitectura empresarial en esta etapa del proceso de transición a la nube puede acelerar la madurez de la nube y reforzar aún más la base sobre cimientos sólidos. El equipo de arquitectos del centro de excelencia en la nube debe trabajar con el EA para alinearse con los patrones de arquitectura de referencia que el equipo del centro de excelencia desea que sigan los equipos de aplicaciones y productos en el diseño de sus soluciones. Este trabajo estratégico y colaborativo sirve como modelo para que los arquitectos “muestren y cuenten” el concepto de diseñar soluciones eficaces en la nube y moldeen la mentalidad hacia la visión de “ganar dinero con la nube”. Toda empresa que quiera tener éxito en la ampliación de las soluciones y capacidades de IA en la actualidad debe lograr que este pensamiento de diseño funcione para ella. De lo contrario, es como la historia de las “uvas agrias” con altas facturas de costes de la nube que se avecinan con poco valor agregado en el dominio de la IA, como ha sido para muchas empresas en 2024.

Santhosh Gottigere

3. CAMINA MÁS RÁPIDO: Desarrolla un plan de adopción de la nube y una hoja de ruta de migración

Con los equipos de CoE y EA trabajando en conjunto, es momento de involucrar a las partes interesadas del negocio/propietarios de productos y desarrollar el plan y la hoja de ruta. Comprender las limitaciones y prioridades del negocio y evaluar los dominios que tienen oportunidades de expandir sus ingresos y crecer exponencialmente al migrar a la nube son los parámetros clave que se deben tener en cuenta. Recomiendo un enfoque estructurado para esta fase del proceso.

Evaluación de la arquitectura de la aplicación: la evaluación de la arquitectura de la aplicación es el primer paso para migrar a la nube. Esto implica identificar qué componentes se pueden trasladar directamente a la nube y cuáles podrían requerir una nueva arquitectura para optimizar la nube. El marco de adopción de la nube (CAF) de AWS es una herramienta eficaz que ayuda a evaluar la preparación para la nube.
Identificación de estrategias y herramientas de migración: identificar la estrategia y las herramientas de migración adecuadas es fundamental para la transición de aplicaciones heredadas a la nube. Las 7R de la migración a la nube, que significan reubicar, realojar, cambiar de plataforma, refactorizar, recomprar y retirar, incluyen los patrones estándar para la migración a la nube. La elección de la estrategia depende del estado de la carga de trabajo.
Planificación y ejecución: planificar meticulosamente y ejecutar el proceso de migración con precisión es fundamental para que la migración sea exitosa. Esto implica seleccionar las estrategias y herramientas de migración más adecuadas, planificar para garantizar una interrupción mínima y ejecutar el proceso de migración con precisión.
Modernización: la modernización modifica la aplicación existente para que funcione mejor en la nube. Esto puede implicar la refactorización o rediseño de la aplicación para aprovechar los servicios nativos de la nube.
Mejores prácticas: se recomienda aprovechar las mejores prácticas para lograr una transición fluida, el cumplimiento normativo y las herramientas del proveedor de la nube correspondiente, adoptando un enfoque gradual con el apoyo de los socios de la nube. La inversión en capacitación y gestión de cambios es fundamental para el éxito.

4. EJECUTAR: Configurar y establecer un modelo financiero de nube sólido

La pieza central para configurar la nube de la manera correcta por primera vez y comprender el verdadero significado de “ganar dinero con la nube” depende del desarrollo de un modelo financiero sólido. La eficacia del centro de excelencia de la nube entra en juego en esta fase. El equipo del centro de excelencia de la nube debe asociarse con el equipo de finanzas y diseñar una estructura organizativa general dentro de la nube que se alinee con la configuración de informes financieros de la empresa. Luego deben explicar claramente el modelo de “pago por uso” y los puntos ciegos que lo acompañan, ya que el costo de la infraestructura ahora pasa de gastos de capital a gastos operativos en su mayor parte desde una perspectiva de gestión de cartera.

En mi opinión personal, el modelo de “pago por uso” es un arma de doble filo que puede generar demoras en las finanzas de la nube o, si se hace bien, generar “ganar dinero con la nube”. En esta fase, el centro de excelencia debe involucrar de manera proactiva a todas las partes interesadas, haciéndoles conscientes del cambio en el modo de operación y guiando al equipo a través de capacitaciones, charlas informales y sesiones del centro de excelencia durante este período de transformación.

La visibilidad de los costes de la nube, la información sobre los costes, la gobernanza de los costes, la definición de una infraestructura de base de la nube y la gestión de proveedores son componentes esenciales de una estrategia integral de gestión financiera de la nube. La visibilidad de los costes de la nube implica establecer procesos y herramientas sólidos para obtener una visibilidad integral de los costes de la nube, mientras que la información sobre los costes implica extraer información significativa de los datos de costes de la nube para identificar tendencias y patrones, y establecer una infraestructura de base que se pueda enjuagar y repetir. La infraestructura de base sirve como una estimación aproximada del costo financiero que se puede modelar para el resto del uso.

Un proceso crítico que es imprescindible para que las empresas comiencen con el pie derecho es que el centro de excelencia de la nube se asocie con arquitectos de la nube para desarrollar una infraestructura de base para los servicios de computación, almacenamiento, base de datos, transferencia de datos, monitoreo de aplicaciones y registro que se proporcionarán para todas las solicitudes. El mensaje tiene que ser lo suficientemente claro para las partes interesadas de que el aprovisionamiento de la nube no es un cheque en blanco. Este proceso de gobernanza permite al equipo del centro de excelencia involucrar a aquellas partes interesadas particulares que necesitan más que la infraestructura de base proporcionada, hacer que justifiquen la necesidad de más y luego aprobar los cambios a su solicitud después de la evaluación.

Esta regla de compromiso sienta las bases para construir una cultura de FinOps inherente y sólida dentro de los equipos de TI y de negocios de manera preventiva, en lugar de estar expuestos después de la puesta en marcha a una costosa factura de la nube. Se ha identificado que los servicios de computación, almacenamiento, base de datos, monitoreo y registro de aplicaciones generan el 75% de la factura de la nube y son los principales valores atípicos de los costos de la nube que se están descontrolando para las organizaciones.

5. CORRER MÁS RÁPIDO: madure el uso y la optimización de la nube empresarial a través de una sólida cultura FinOps

La belleza del uso de la nube es que siempre hay oportunidades para aprovechar los servicios en la nube de forma eficiente y eficaz. En primer lugar, la parte “eficiente”. Debido a la competitividad inherente de los distintos proveedores de la nube para expandirse sin piedad, trabajan constantemente en mejoras de vanguardia y funciones de optimización para sus servicios que estarán disponibles para sus clientes. Es realmente una tarea abrumadora estar al tanto de las nuevas mejoras que se presentan. Sin embargo, las empresas que están perfectamente en sintonía con una sólida cultura de FinOps están preparadas para aprovechar esos “regalos” que se les ofrecen y satisfacen sus necesidades, por lo que rápidamente se dan cuenta de sus beneficios.

Debido a este aspecto de aprovechar los servicios de optimización de la nube adecuados o las “ventajas” que se ofrecen a los clientes, la escalabilidad de las soluciones es muy posible de manera rentable, y eso cubre la parte “lean“. Descifrar este código o aspecto de la optimización de la nube es la pieza más crítica para que las empresas encuentren oro con la escalabilidad de las soluciones de IA. Las empresas deben resolver este rompecabezas correctamente para evitar el decepcionante retorno de la inversión que muchas han experimentado en 2024 relacionado con sus capacidades de IA.

La optimización de los costes de la nube implica identificar áreas de gasto excesivo, redimensionar los recursos, comprender cómo usar de manera eficaz las técnicas de ingeniería rápida y los modelos LLM adecuados dentro de la IA, y aprovechar los modelos de precios y los descuentos que ofrecen los proveedores de servicios en la nube (CSP). Se deben establecer métricas y criterios estratégicos para incorporar objetivos de sostenibilidad en varias capacidades de FinOps, y los equipos de ingeniería y productos deben asumir la responsabilidad del uso de la nube, tomando decisiones adecuadas en cuanto a arquitectura, diseño de sistemas, uso de licencias y características operativas.

El cambio fundamental en la mentalidad es que la “gestión de costes de la nube” es una responsabilidad compartida de los arquitectos de la nube, los propietarios de productos, los socios comerciales, los desarrolladores de aplicaciones que aprovechan DevSecOps y los canales de automatización, y los equipos de datos, todos involucrados con el uso de la nube para una aplicación en particular.

En este punto del camino, las empresas han logrado lo que considero la verdadera esencia de “ganar dinero con la nube”. Las empresas tienen la capacidad de trabajar más rápido y hacer grandes innovaciones, y no alarmarse por recibir sorpresas a fin de mes con facturas exorbitantes que disuaden a los CIO de seguir adelante, porque cuentan con las herramientas y prácticas adecuadas que les permiten detectar anomalías de forma proactiva, alterar configuraciones y corregir el rumbo rápidamente en su infraestructura de nube o tomar una decisión sobre si vale la pena seguir adelante con el caso de uso comercial.

Navigating the cloud maze: A 5-phase approach to optimizing cloud strategies

Tue, 07 Jan 2025 13:21:35 +0100

In today’s fast-paced digital landscape, the cloud has emerged as a cornerstone of modern business infrastructure, offering unparalleled scalability, agility, and cost-efficiency. As organizations increasingly migrate to the cloud, however, CIOs face the daunting challenge of navigating a complex and rapidly evolving cloud ecosystem. With the AI revolution underway — which has kicked the wave of digital transformation into high gear — it is imperative for enterprises to have their cloud infrastructure built on firm foundations that can enable them to scale AI/ML solutions effectively and efficiently. Otherwise, companies will struggle to realize business value with AI/ML capabilities left to endure high cloud cost expenses, as it has been for many companies in 2024 for AI solutions.

The five-step process explained below will help enterprises and CIOs to embark on the cloud journey, which is strategic with the right provider that fits their needs, build it right the first time not go back and fix it later, inculcate the mindset of how to make money with cloud, drive awareness and train business and IT on cloud financials that should overall drive a culture of architecting cloud cost-effective and scalable solution designs that becomes a organizations’ DNA.

The journey I propose is in five phases through the lens of a crawl-walk-run framework.

1. CRAWL: Design a robust cloud strategy and approach modernization with the right mindset

Modern businesses must be extremely agile in their ability to respond quickly to rapidly changing markets, events, subscriptions-based economy and ‘excellent experience’ demanding customers to grow and sustain in the ever-ruthless competitive world of consumerism. The ability of cloud infrastructure to adapt, scale and be malleable to meet business needs right where they are and then enable them to expand makes it the default choice. With the advent of growing AI adoption, a strong cloud foundation pillar is a prerequisite.

Key considerations for cloud strategy and modernization

The ‘what’: The executive leadership team of business and IT together need to evaluate business needs and their current business challenges, global footprint and current technology landscape and define the company’s “Northstar,” (aka, the “what,” the vision).
The ‘why’: Establish clear business principles to address why you’re doing this. For instance, to deliver faster and improved quality of service to customers, faster deployment of new products and services, to increase revenue and profit margins while controlling costs, sustainability or market expansion, to name a few.
An enterprise with a strong global footprint is better off pursuing a multi-cloud strategy. It prevents vendor lock-in, gives a lever for strong negotiation, enables business flexibility in strategy execution owing to complicated architecture or regional limitations in terms of security and legal compliance if and when they rise and promotes portability from an application architecture perspective. In some cases, the business domain in which the organization operates (ie, healthcare, finance, insurance) understandably steers the decision toward a single cloud provider to simplify the logistics, data privacy, compliance and operations.
Technology modernization strategy: Evaluate the overall IT landscape through the lens of enterprise architecture and assess IT applications through a 7R framework. (rehost/lift & shift, replatform, replace, refactor, rearchitect, retire, retain). The assessment provides insights into the current state of architecture and workloads and maps technology needs to the business objectives.

The first three considerations are driven by business, and the last one by IT. Enterprise architecture is the bridge capable of tying the two loose ends, breaking down silos and driving cloud transformation and execution strategy effectively. This new paradigm of the operating model is the hallmark of successful organizational transformation. All the major cloud providers from North America — AWS, Google, Microsoft Azure, Oracle Cloud — are on par with each other, with most of their services and capabilities are primed to address the needs of any enterprise.

Having said that, there are a couple of standouts I would like to point out. First, cloud provisioning through automation is better in AWS — CloudFormation and Azure — Azure Resource Manager compared to the other cloud providers. For larger enterprises with a multi-cloud strategy, Terraform is the best way to go to close that shortcoming.

Second, from a cloud security perspective, Azure has a comprehensive cloud security tool that comes as a package and can seamlessly be integrated with its services, thus enhancing the cloud security posture without the need to buy an external tool.

2. WALK: Establish a strong cloud technical framework and governance model

After finalizing the cloud provider, how does a business start in the cloud? You would be surprised, but a lot of companies still just start without having a plan. How difficult can it be, after all? You get a subscription and begin deploying resources. That probably works fine with really small environments, but you will soon discover that it grows over your head. You are heading for a cloudshock. No joke.

Well-architected frameworks were henceforth invented to help customers build environments in public clouds by providing them with best practices. The good news is all major cloud providers frameworks do the same thing:

Operational excellence
Security
Cost optimization
Reliability
Performance efficiency
Sustainability

The framework helps in implementing the financial controls (FinOps) that we will discuss separately, management of workloads (BaseOps) and security controls (SecOps). At this point in the journey, the timing is right to set up a cloud Center of Excellence (CoE) practice, join hands with cloud engineers, architects and the DevSecOps community and publish the customized version of a well-architected framework that fits the individual company needs and establishes a standard artifact. This serves as a baseline to drive cloud adoption and getting started with a shifting mindset on how to ‘make money with cloud’ and not just cost savings alone.

It’s a good idea to establish a governance policy supporting the framework. This includes the creation of landing zones, defining the VPN, gateway connections, network policies, storage policies, hosting key services within a private subnet and setting up the right IAM policies (resource policies, setting up the organization, deletion policies). Creating awareness of the policy of least privilege and addressing frustrations when cloud users ask for more to play with, and as a cloud CoE team, you are rightfully holding your ground that comes with it. The cloud CoE team should collect feedback from the users and tweak policies along the way as they deem fit. As the enterprise user community matures through this learning curve, the CoE team has a pivotal role to play in engaging them proactively, supporting them, meeting their needs and helping them address their pain points to lay a strong foundation for building a robust cloud infrastructure that is scalable to deliver business value.

Partnering with the enterprise architecture team in this stage of the cloud journey can speed up cloud maturity and buttress the foundation further on solid bearings. The cloud CoE team of architects should work with the EA to align with the reference architecture patterns that the CoE team would like the application teams/product teams to follow in their solution design. This strategic and collaborative work serves as a blueprint for the architects to ‘show and tell’ the concept of designing cloud-effective solutions and shape mindsets towards the ‘making money with the cloud’ vision. Every company that wants to succeed in scaling AI solutions and capabilities today needs to get this design thinking working for them. Otherwise, it’s like the story of ‘sour grapes’ with high cloud cost bills coming their way with little value added in the AI domain as it has been for a lot of companies in 2024.

3. WALK FASTER: Develop cloud adoption planning and migration roadmap

With the CoE and EA teams working in tandem, it’s time to engage the business stakeholders/product owners and develop the plan and roadmap. Understanding business constraints and priorities, and evaluating domains that have opportunities to expand their revenue and grow exponentially upon moving to the cloud are the key parameters to keep in mind. I recommend a structured approach for this phase of the journey.

Assessing application architecture: Assessing application architecture is the first step in migrating to the cloud. This involves identifying which components can be lifted and shifted directly to the cloud and which might require re-architecture for cloud optimization. The AWS Cloud Adoption Framework (CAF) is an effective tool that helps to evaluate cloud readiness.
Identifying migration strategies and tools: Identifying the right migration strategy and tools is pivotal for transitioning legacy applications into the cloud. The 7Rs of cloud migration, which stand for relocate, re-host, re-platform, refactor, repurchase, and retire, include the standard patterns for cloud migration. The choice of strategy depends on the state of the workload.
Planning and execution: Planning meticulously and executing the migration process with precision is crucial for a successful migration. This involves selecting the most suitable migration strategies and tools, planning to ensure minimal disruption, and executing the migration process with precision.
Modernization: Modernization modifies the existing application to make it work better in the cloud. This can involve refactoring or re-architecting the application to take advantage of cloud-native services.
Best practices: Leveraging the best practices for smooth transition, compliance and tools of the respective cloud provider adopting a phased approach with the support of cloud partners is recommended. Investment in training and change management is critical to the success.

4. RUN: Configure and establish a strong cloud financial model

The centerpiece for setting up the cloud the right way for the first time and realizing the true meaning of ‘making money with the cloud’ hinges on developing a strong cloud financial model. The effectiveness of the cloud CoE comes into play in this phase. The cloud CoE team must partner with the finance team and design an overarching organizational structure within the cloud that aligns with the company’s financial reporting setup. They must then explain the ‘Pay as you go’ model clearly and the blind spots that come along with it, as the infrastructure cost now shifts from capex to opex for the most part from a portfolio management perspective.

In my personal opinion, the “Pay as you go” model is a double-edged sword that can lead to tardiness around cloud financials, or if done right, lead to ‘making money with the cloud’. The CoE in this phase has to proactively engage ALL stakeholders, making them aware of the change in the mode of operation and guiding the team through training, coffee chats, and CoE sessions during this period of transformation.

Cloud cost visibility, cost insights, cost governance, defining a cloud baseline infrastructure and vendor management are essential components of a comprehensive cloud financial management strategy. Cloud cost visibility involves establishing robust processes and tools to gain comprehensive visibility into cloud costs, while cost insights involve extracting meaningful insights from cloud cost data to identify trends and patterns, setting up a baseline infrastructure that can be rinsed and repeated. The baseline infrastructure serves as a ballpark estimate of the financial cost that can be modeled for the rest of the usage.

A critical process that is a must for companies to get started on the right footing is having the cloud CoE partner with cloud architects to develop a baseline infrastructure for compute, storage, database, data transfer, application monitoring and logging services that shall be provisioned for all requests. The message has to be clear enough to the stakeholders that cloud provisioning is not a blank check. This process of governance empowers the CoE team to engage those particular stakeholders who need more than the baseline infrastructure provisioned, have them justify the need for more, and then approve changes to their request upon evaluation.

This rule of engagement lays the foundation for building a strong inherent FinOps culture within the IT and business teams preemptively, rather than being exposed post-go-live to an expensive cloud bill. It has been identified that compute, storage, database, application monitoring and logging services drive up 75% of the cloud bill and are major outliers of cloud cost spiraling out of control for organizations.

5. RUN FASTER: Mature the enterprise cloud usage and optimization through a strong FinOps culture

The beauty of cloud usage is that there are always opportunities to leverage cloud services lean and mean. First, the ‘mean’ part. Due to the inherent competitiveness of various cloud providers to expand ruthlessly, they are constantly working on cutting-edge improvements and optimization features for their services that will be made available to their customers. It is indeed an overwhelming affair to keep track of new embellishments coming your way. However, the enterprises that are perfectly attuned to a strong FinOps culture are poised to take advantage of which of those ‘freebies’ thrown at them serve their needs and quickly realize their benefits.

Because of this aspect of taking advantage of the right cloud optimization services or ‘perks’ thrown at customers, the scalability of solutions is very much possible cost-effectively, and that covers the ‘lean’ part. Cracking this code or aspect of cloud optimization is the most critical piece for enterprises to strike gold with the scalability of AI solutions. Companies must get this puzzle solved right to avoid the disappointing ROI that many have experienced in 2024 related to their AI capabilities.

Cloud cost optimization involves identifying areas of overspending, rightsizing resources, understanding how to effectively use prompt engineering techniques and the right LLM models within AI, and leveraging pricing models and discounts that cloud service providers (CSPs) offer. Strategic metrics and criteria should be established to incorporate sustainability goals into various FinOps capabilities, and engineering and product teams should take responsibility for cloud usage, making appropriate choices in architecture, system design, license use and operational features.

The fundamental shift in the mindset is that ‘cloud cost management’ is a shared responsibility of cloud architects, product owners, business partners, application developers leveraging DevSecOps and automation pipelines, and data teams all involved with cloud usage for a particular application.

This point in the journey is where enterprises have achieved what I feel is the true essence of ‘making money with the cloud’. Enterprises are empowered to run faster and go big with their innovations, and not be alarmed to receive cloud shocks at the month-end with outrageous cloud bills that dissuade CIOs from moving forward because they are firmly footed with the right tools and practices that enable them to catch anomalies proactively, alter configurations, and course-correct swiftly in their cloud infrastructure or make a decision if the business use case is worth pursuing.

Santhosh Gottigere is an IT Technology leader, who has led major business and IT transformations in enterprise architecture, service operations, human resources, coud migrations, and SAP ERP spanning across multiple vertical industries such as healthcare, pharmaceuticals, energy and gas, retail and manufacturing, consumer goods, and transportation and freight management across the US, Europe and Canada. He is a global information technology leader with broad experience from multinational IT consulting organizations and leading independent software vendors.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

Crypto Boss Extradited to Face $40bn Fraud Charges

Fri, 03 Jan 2025 13:33:37 +0100

Former Terraform CEO Do Hyeong Kwon is now in the US facing federal fraud charges

Terraform-Chef Do Kwon plädiert vor US-Gericht auf nicht schuldig

Fri, 03 Jan 2025 09:00:39 +0100

Terraform-Kryptowährungsboss Do Kwon steht wegen Betrugs vor einem US-Gericht. Er legte zwar ein Geständnis ab, sieht jedoch keine Schuld bei sich.

SEC Writes Off $10 Billion in Fines It Can't Collect

Wed, 01 Jan 2025 17:19:01 +0100

The Securities and Exchange Commission wrote off nearly $10 billion in uncollected fines over the past decade, with $1.4 billion written off in 2023 alone, WSJ reported, citing internal data. While the agency reported $4.9 billion in sanctions last year, it typically collects only two-thirds of imposed penalties. The SEC stopped disclosing collection rates in 2019. In fiscal 2024, it collected just 23% of $8.2 billion in reported sanctions, including a $4.4 billion judgment against cryptocurrency firm Terraform Labs that will likely go unpaid due to bankruptcy proceedings.

Read more of this story at Slashdot.

SEC Writes Off $10 Billion in Fines It Can't Collect

Wed, 01 Jan 2025 17:18:59 +0100

Read more of this story at Slashdot.

HPR4281: My ridiculously complicated DHCP setup at home

Mon, 30 Dec 2024 09:19:04 +0100

This show has been flagged as Clean by the host.

Hello, this is Jon The Nice Guy, and after 10 years of knowing about Hacker Public Radio, here is my first podcast for the network.

Firstly, I want to give a shout out to my Admin Admin Podcast co-host Al, who I heard just a week-or-so ago talking about Proxmox! Glad to hear you're over here too!

I wanted to record an episode on my ridiculously complicated DHCP setup at home. I'm not saying this is the right or even a good idea for anyone else, but it's something you might want to do.

Firstly, a little about why I have a complicated DHCP setup, and it starts with the router my previous ISP gave me.

My router could just about cope with serving DHCP, but at the time when I was experimenting with running services on my home lab, the DNS server on the router wouldn't return addresses for hosts on my network, just those on the public internet. This wasn't a great experience! So, I installed PiHole [1] - initially because I'd heard good things about it's ad blocking capabilities, but later because it was just a pretty and sensible DHCP and DNS server that I could do things with.

Under the covers, PiHole is running DNSMasq [2], which means that all the configuration is plain text files that I can overwrite with Ansible [3].

My PiHole was running on a Raspberry Pi 2 [4], in a lego-style case [5] plugged into the back of my router. And this was fine for a few months. And then it ran out of storage space, I changed jobs, my wife complained one too many times, and I reverted back to using the router's DHCPd and DNS. I also picked up either Nebula [6] or Tailscale [7] at around that time too, so I didn't need internal DNS to resolve to home services any more, and anything public I setup external DNS records pointing to the internal addresses. Job done.

Scrub forward a couple of years, and when I changed jobs, I got a joining bonus which paid for me to get wired network around my house. I also setup my own Proxmox [8] cluster, which I documented on a post [9] on my blog [10]. Again, everything was peachy. I setup home assistant [11], which I expose on to the internet via a proxy on my VPS, and everything was still good... but things are a little more complicated now - I've got more stuff to keep track of and the router's DHCP server was struggling a little... but it was all OK.

And then I changed ISP. My new ISP shipped a router running a customized version of OpenWRT [12], and I thought, finally, a good router! And then I realised I couldn't do *anything* sensible with it. It was so locked down, I couldn't even change the admin password without factory resetting it! Ugh. Within a couple of weeks my wife was complaining about random intermittent DNS requests failing, and I was seeing it too. So, I found on the Proxmox Helper Scripts [13] website that someone had put a script to setup a PiHole instance... So naturally, as I had two Proxmox Servers by this point, I ran two PiHole servers. This lasted a few months until I performed a system upgrade to the proxmox cluster and it took down both Proxmox cluster members at the same time and DNS fell off the network! I revived the Raspberry Pi 2 which now sits attached to the router again! Yes!

Meanwhile, I was now getting more into IoT and I had several Tuya IoT devices connected over Wifi, and the 254 network addresses available in the /24 sized network [14] to me at home didn't seem enough, so I decided to expand my network to a /22, giving me enough address space for 1022 devices. Plus, I have kids, who each have computers and phones and games devices, my wife and I both work from home, so we both have computers from work and our own devices too... so I decided, now is the time to plan out my network.

I decided to use PHPIPAM [15] having been asked to look at it at work, and found it was a good fit for what I wanted to do with it.

PHPIPAM is really designed for owners of large-scale networks, people who allocate chunks of public IP scopes and IPv6 address ranges, but it will subdivide smaller network blocks, and so I could carve up my network.

I decided to split my /22 into four /24 networks. One was dedicated to DHCP addressed items, with one smaller subnet in there allocated to the Proxmox hosted PiHole and another to the Raspberry Pi hosted PiHole, and both are basically a catch-all for anything I've not yet allocated. One was for end-user devices, like phones, computers, TVs and Games Consoles separated into smaller subnets per-person and one additional subnet for room-shared devices like TVs and Games Consoles. One subnet was separated into smaller subnets for IoT devices and core network things, like mains and network switches, light bulbs, cameras and printers. The last /24 subnet was undivided, but was for servers, both physical and virtual.

Great, I've now got a lovely network map [IMAGE1], but *ugh* I've got to transfer all those DHCP and static IP allocations to the PiHoles. And, while I'd been using Gravity Sync [15] to synchronize between the two PiHole devices, sometimes it took a while for Gravity Sync to sync.

And over time, I wanted to expose some of those services I was running at home, to my family, at home.

So, I turned to Ansible.

A few years ago, I'd helped write some Ansible modules which were used to interact with a cloud service my employer at the time was running, so I had a kind of idea on how Ansible works under the surface, the documentation for writing a new set of lookups was OK, and ChatGPT helped where I lost my way.

I knew that there was a Terraform [17] Provider [18] for PHPIPAM, so there was a working API... and so I knew I could look up data in PHPIPAM. I wrote some Ansible lookups [19] to confirm the data was accessible from PHPIPAM, and it was! Great, now all I needed to do was to drop files into PiHole.

I'd heard Alex [20] from the Self Hosting Podcast [21] talking about how he wrote some Ansible to automate his PiHole management [22], but it assumed a lot about how your network was setup and integrated a lot with other things he did - no complaints there! It's his network after all! But so I knew I needed to do 5 things.

1. Create a list of static DHCP allocations on both PiHole devices.

2. Create a list of DNS names to resolve in the internal network to addresses via A records

3. Create a list of DNS names to resolve to other DNS names via CNAME records

4. Create a list of DNS wildcards, so anything ending in that name would appear in my network.

5. If anything changed, restart DNSMasq.

I wrote this code and ran it. Well, ran it and it didn't work, so I fixed it and ran it again... and again and again until it did work.

I've just added that to my Github today, so feel free to take a look [23].

You've spent a while listening to this, so what is my "too long, didn't listen"?

I have two pihole devices, I run a phpipam service under docker on a LXC container on my proxmox server. On the same LXC container I have a cron job which triggers the ansible playbook every 5 minutes to push any updates to PHPIPAM to the pihole hosts.

Every few days I check to see what hosts have turned up in the DHCP pools on the PiHole hosts, map those to hosts I want to track in the future, and allocate them addresses in PHPIPAM so that those hosts will get managed IP addresses after 5 minutes, the next time they renew their DHCP addresses...

Tada!

For more over engineered solutions like this, feel free to take a look at the content on my blog, or maybe I'll appear again, on Hacker... Public... Radio.

Take care, 73.

[1] PiHole: https://pi-hole.net/

[2] DNSMasq: https://thekelleys.org.uk/dnsmasq/doc.html

[3] Ansible: https://ansible.com

[4] Raspberry Pi: https://www.raspberrypi.com/products/

[5] Lego style case: https://www.amazon.co.uk/gp/product/B015WVR5BS

[6] Nebula: https://www.defined.net/

[7] Tailscale: https://tailscale.com/

[8] Proxmox: https://www.proxmox.com

[9] Proxmox post: https://jon.sprig.gs/blog/post/2885

[10] My blog: https://jon.sprig.gs

[11] Home Assistant: https://www.home-assistant.io/

[12] OpenWRT: https://openwrt.org/

[13] Helper Scripts: https://community-scripts.github.io/ProxmoxVE/

[14] Network address spreadsheet: https://gist.github.com/JonTheNiceGuy/a847aa4faf878d7d6cee5c069e1d66d6

[15] PHPIPAM: https://phpipam.net/

[16] Gravity Sync: https://github.com/vmstan/gravity-sync

[17] Terraform: https://www.terraform.io/

[18] PHPIPAM Terraform Provider: https://registry.terraform.io/providers/lord-kyron/phpipam/latest

[19] Ansible Lookup: https://gist.github.com/JonTheNiceGuy/289a8a2e0233e730f0fbc8f958ec4bc6

[20] Alex Kretzschmar: https://alex.ktz.me/

[21] Self Hosted Podcast: https://selfhosted.show/

[22] Fully Automated DNS and DHCP with PiHole and DNSMasq: https://blog.ktz.me/fully-automated-dns-and-dhcp-with-pihole-and-dnsmasq/

[23] ansible-pihole: https://github.com/JonTheNiceGuy/ansible-pihole

[IMAGE1] https://jon.sprig.gs/blog/wp-content/uploads/2024/12/Screenshot-from-2024-12-20-19-29-22.png

Provide feedback on this episode.

What Happens to Relicensed Open Source Projects and Their Forks?

Sat, 28 Dec 2024 21:48:39 +0100

A Linux Foundation project focused on understanding the health of the open source community just studied the outcomes for three projects that switched to "more restrictive" licenses and then faced community forks. The data science director for the project — known as Community Health Analytics in Open Source Software (or CHAOSS) — is also an OpenUK board member, and describes the outcomes for OpenSearch, Redis with fork Valkey, and Terraform: The relicensed project (Redis) had significant numbers of contributors who were not employed by the company, and the fork (Valkey) was created by those existing contributors as a foundation project... The Redis project differs from Elasticsearch and Terraform in the number of contributions to the Redis repository from people who were not employees of Redis. In the year leading up to the relicense, when Redis was still open source, there were substantial contributions from employees of other companies: Twice as many non-Redis employees made five or more commits, and about a dozen employees of other companies made almost twice as many commits as Redis employees made. In the six months after the relicense, all of the external contributors from companies (including Amazon, Alibaba, Tencent, Huawei and Ericsson) who contributed over five commits to the Redis project in the year prior to the relicense stopped contributing. In sum, Redis had strong organizational diversity before the relicense, but only Redis employees made significant contributions afterward. Valkey was forked from Redis 7.2.4 on March 28, 2024, as a Linux Foundation project under the BSD-3 license. The fork was driven by a group of people who previously contributed to Redis with public support from their employers. Within its first six months, the Valkey repository had 29 contributors employed at 10 companies, and 18 of those people previously contributed to Redis. Valkey has a diverse set of contributors from various companies, with Amazon having the most contributors. The results weren't always so clear-cut. Because Terraform always had very few contributors outside of the company, "there was no substantial impact on the contributor community from the relicensing event..." (Although the OpenTofu fork — a Linux Foundation project — had 31 people at 11 organizations who made five or more contributions.) And both before and after Elasticsearch's relicensing, most contributors were Elastic employees, so "the 2021 relicense had little to no impact on contributors." (But the OpenSearch fork — transferred in September to the Linux Foundation — shows a more varied contributor base, with just 63% of additions and 64% of deletions coming from Amazon employees who made 10 or more commits. Six people who didn't work for Amazon made 10 or more commits, making up 11% of additions and 13% of deletions.") So "Looking at all of these projects together, we see that the forks from relicensed projects tend to have more organizational diversity than the original projects," they conclude, adding that in general "projects with greater organizational diversity tend to be more sustainable..." "You can dive into the details about these six projects in the paper, presentation and data we shared at the recent OpenForum Academy Symposium.

Read more of this story at Slashdot.

What Happens to Relicensed Open Source Projects and Their Forks?

Sat, 28 Dec 2024 21:48:38 +0100

Read more of this story at Slashdot.

South Korean Crypto-Boss Do Kwon To Be Extradited To US

Fri, 27 Dec 2024 21:48:28 +0100

Montenegro has approved the extradition of cryptocurrency entrepreneur Do Kwon to the United States over his role in the collapse of TerraUSD and Luna tokens, which wiped out $40 billion from investors and destabilized global crypto markets. The BBC reports: "The Minister of Justice, Bojan Bozovic, issued a decision approving the extradition of the accused, Kwon Do Hyung, to the United States of America," the Ministry of Justice announced said in a statement. "It was concluded that the majority of the criteria prescribed by law favor the extradition request from the competent authorities of the United States of America," the statement said. It added that Kwon had consented to be extradited to both South Korea and the United States. In February, US regulators charged Kwon and his company Terraform Labs with "orchestrating a multi-billion dollar crypto asset securities fraud." "We allege that Terraform and Do Kwon failed to provide the public with full, fair, and truthful disclosure as required for a host of crypto asset securities, most notably for Luna and TerraUSD," US Securities and Exchange Commission (SEC) chairman Gary Gensler said in a statement at the time. The US alleged that Kwon repeatedly claimed that the tokens would increase in value, and misled investors about the stability of TerraUSD.

Read more of this story at Slashdot.

What is an IT consultant? Roles, types, salaries, and how to become one

Thu, 26 Dec 2024 11:18:39 +0100

The IT function within organizations has become far more complex in recent years. Enterprise infrastructures have expanded far beyond the traditional ones focused on company-owned and -operated data centers.

Among the recent trends impacting IT are the heavy shift into the cloud, the emergence of hybrid work, increased reliance on mobility, growing use of artificial intelligence, and ongoing efforts to build digital businesses.

This increased complexity means more companies will be relying on IT consultants to help navigate the changes and develop short-term and long-term strategies. As a result, making the shift to IT consulting can be a lucrative path to a fulfilling IT career.

What is an IT consultant?

An IT consultant is a technology professional who advises and supports business clients in designing, developing, and executing technology projects in service of business goals.

IT consultants are often hired to provide companies guidance on what technologies they should use to achieve their aims, according to career website Indeed. IT consultants can find work by joining IT consultancy firms or by operating as independent contractors, developing their own client rosters and selecting the projects they want to work on.

Because technology is continuously changing, IT consultants can provide clients with the latest information about new technologies as they become available, recommending implementation strategies based on their clients’ needs. As a result, for IT consultants, keeping the pulse of the technology market is essential.

“Being a successful IT consultant requires knowing how to walk in the shoes of your IT clients and their business leaders,” says Scott Buchholz, CTO of the government and public services sector practice at consulting firm Deloitte.

A consultant’s job is to assess the whole situation, the challenges, and the opportunities at an organization, Buchholz says. As an outsider, the consultant can see things clients can’t.

What does an IT consultant do?

IT consultants are responsible for helping organizations design and develop strategic IT projects and manage their technology use. This can involve assessing a company’s IT infrastructure, including its computer systems, cybersecurity profile, software performance, and data and analytics operations, to help determine ways a business might better benefit from the technology it uses.

“IT consultants spend a large portion of their job meeting with clients to discuss the next steps they plan to take in updating and maintaining their technology, where they can offer advice about which new technological developments might contribute to their success,” according to career website Indeed.

An IT consultant might also perform repairs on IT systems and technological devices that companies need to conduct business.

IT consultants’ work environment typically depends on the clients they serve, according to Indeed. IT consultants who are independent contractors might complete some work from home. An IT consultant might also work at a consulting firm with teams of other IT consultants.

Types of IT consultants

Given that there are many facets of IT, it’s not surprising that there are various types of IT consultants to meet enterprise needs.

These include strategy consultants, systems consultants, and security consultants, among others, says Paul Farnsworth, CTO at technology careers site Dice.

“We’re seeing the most in-demand types of consultants being those who specialize in cybersecurity and digital transformation, largely due to increased reliance on remote work and increased risk of cyberattacks,” he says.

In addition, consultants with program management skills are valuable for supporting technology projects, assessing technology strategies, and helping organizations compare and make informed decisions about their technology investments, Farnsworth says.

Indeed notes a demand for IT consultants who are familiar with AI and AI governance; how to use and incorporate prompt engineering; data analysis; and specific applications such as Jira, Salesforce, ServiceNow, etc.

IT consultant salaries

The average salary for an IT consultant is $105,500, according to Dice’s 2024 Tech Salary Report. This can vary based on geographic location and skill level, Farnsworth says.

The Dice research data shows that IT consultants at the C-suite or vice president level are likely to make closer to $163,500, Farnsworth says.
“IT consultants who specialize in large-scale IT change programs, such as mergers and acquisitions, can command even higher compensation, often in line with the pay of consulting company partners due to the complexity and impact of their expertise,” he says.

Indeed lists various salaries for IT consultants. Many IT consultants also qualify for benefits outside of their competitive salaries, such as health insurance, paid time off, and a flexible spending account, the firm notes. Here are a few national average annual salaries for IT consultants in the United States, based on Indeed data as of September 2024:

IT analyst: $103,581
Implementation consultant: $85,376
Salesforce consultant: $114,433
IT security consultant: $96,242
Maintenance and repair consultant: $76,499

IT consultant job outlook

The job outlook for IT consultants remains strong, “as technology is continually being implemented to improve business operations, security, create new products, and drive change,” Farnsworth says. “Consultants with the experience and specialized skills are always going to be required to help drive this change.”

One important thing to remember is that even with specialized technical skills, the most successful IT consultants will need to have a balanced skill set of high emotional intelligence and soft skills as well, Farnsworth says.

[ Related: How to get a job in IT consulting ]

“Consultants are a key part of the strategy of virtually every organization due to the flexibility it gives the organization to bring in expertise quickly and to be able to staff up for a short-term but large effort,” says Tamara Larsen, director of IT infrastructure and platforms at Indeed.

“I do not see this changing, though the amount of people will flex up and down depending on the economy and the industry at any given time,” Larsen says.

How to become an IT consultant

“Successful IT consultants need to have a mix of hard and soft skills, from coding and data analysis to critical thinking and communication,” Deloitte’s Buchholz says. “All these skills are crucial for consultants. The goal is to be able to compellingly communicate the right answer with facts and analysis.”

Skills that an IT consultant needs include proficiency in technical repairs, current knowledge of technological advancements, attention to detail, problem solving, critical thinking, effective time management, and interpersonal and communication.

Students and technology professionals who want to pursue a career in IT consulting must demonstrate technical expertise across areas such as business operations, security, product development, and change management, Farnsworth says.

“This can be developed through certifications like those that CompTIA or AWS [Amazon Web Services] provide,” he says. While previously many technology jobs demanded formal certifications, especially in industries such as cybersecurity and networking, today’s high demand for technology talent means many employers have become more lenient in their education requirements, he says.

“Now, those hiring for tech talent are more willing to forgo their degree and certification requirements if candidates can demonstrate they have the necessary skills and experience to do the job,” Farnsworth says. “Candidates can showcase these by highlighting their previous relevant roles and projects, freelance work, skills and/or knowledge of specific tools or programs the role requires, or testimonials from their former employers or connections.”

Larsen recommends obtaining and staying up to date on relevant certifications, such as those related to the major cloud providers. It’s a good idea to be familiar with common tools such as Git, Kubernetes, and Terraform, as well as Agile practices, she says. But ultimately, success in IT is about having the skills and the ability to perform the work, not necessarily having a particular formal education in IT, she says.

Indeed says candidates for IT consulting roles should earn a degree from an accredited college or university. Most companies require IT consultants to have at least a bachelor’s degree, and many aspiring IT consultants choose to major in computer science, IT, or software engineering so that they can gain the skills and training they need to succeed in the field, the company says.

Top certifications for IT consultants

Earning certifications that cover specific areas of IT can help consultants land engagements with clients. Not surprisingly, some of the most in-demand certifications today are related to cloud services and cybersecurity.

For example, top certifications include:

AWS Certified Solutions Architect—Professional
Google Certified Professional Cloud Architect
Microsoft Certified: Azure Solutions Architect Expert
Certified Information Systems Security Professional (CISSP)
Certified Cloud Security Professional (CCSP)
Certified Information Security Manager (CISM)
Project Management Professional (PMP)

Indeed recommends obtaining certifications to demonstrate expertise in certain areas. Certification is often voluntary for IT consultants, but having a certification can make a consultant stand out among other candidates who are not certified, and might increase chances of being hired.

Most certifications in IT involve completing coursework and training, and many require candidates to have a certain number of years of professional experience before they apply, Indeed says.

“Successful IT consultants understand that certifications are useful to get in the door because they demonstrate that you know what you know, but once you’re in the door getting the work done and staying informed becomes more important,” Buchholz says.

“Different areas of consulting may need different certifications, and some may need none,” Buchholz says. “But ultimately, keeping up with your skills long term is most important. Whether you’re working on soft skills or hard skills, there are a myriad of free and paid resources available today.”

More on IT consultants:

What is an IT consultant? Roles, types, salaries, and how to become one

Thu, 26 Dec 2024 11:18:38 +0100

What is an IT consultant?

An IT consultant is a technology professional who advises and supports business clients in designing, developing, and executing technology projects in service of business goals.

A consultant’s job is to assess the whole situation, the challenges, and the opportunities at an organization, Buchholz says. As an outsider, the consultant can see things clients can’t.

What does an IT consultant do?

An IT consultant might also perform repairs on IT systems and technological devices that companies need to conduct business.

Types of IT consultants

Given that there are many facets of IT, it’s not surprising that there are various types of IT consultants to meet enterprise needs.

These include strategy consultants, systems consultants, and security consultants, among others, says Paul Farnsworth, CTO at technology careers site Dice.

IT consultant salaries

The average salary for an IT consultant is $105,500, according to Dice’s 2024 Tech Salary Report. This can vary based on geographic location and skill level, Farnsworth says.

IT analyst: $103,581
Implementation consultant: $85,376
Salesforce consultant: $114,433
IT security consultant: $96,242
Maintenance and repair consultant: $76,499

IT consultant job outlook

[ Related: How to get a job in IT consulting ]

“I do not see this changing, though the amount of people will flex up and down depending on the economy and the industry at any given time,” Larsen says.

How to become an IT consultant

Top certifications for IT consultants

For example, top certifications include:

AWS Certified Solutions Architect—Professional
Google Certified Professional Cloud Architect
Microsoft Certified: Azure Solutions Architect Expert
Certified Information Systems Security Professional (CISSP)
Certified Cloud Security Professional (CCSP)
Certified Information Security Manager (CISM)
Project Management Professional (PMP)

Most certifications in IT involve completing coursework and training, and many require candidates to have a certain number of years of professional experience before they apply, Indeed says.

More on IT consultants:

Generate Random Password with Terraform

Mon, 23 Dec 2024 13:40:07 +0100

Generating random passwords with Terraform is a simple yet powerful way to enhance the security of your infrastructure.

Generate Random Password with Terraform

Mon, 23 Dec 2024 13:40:04 +0100

Generating random passwords with Terraform is a simple yet powerful way to enhance the security of your infrastructure.

Mastering Azure management: A comparative analysis of leading cloud platforms

Sat, 21 Dec 2024 01:18:23 +0100

Azure’s growing adoption among companies leveraging cloud platforms highlights the increasing need for effective cloud resource management. With a wide range of services, including virtual machines, Kubernetes clusters, and serverless computing, Azure requires advanced management strategies to ensure optimal performance, enhanced security, and cost efficiency.

Enterprises must focus on resource provisioning, automation, and monitoring to optimize cloud environments. Leveraging Infrastructure as Code (IaC) solutions allow for programmatic resource management, while automation and real-time monitoring are essential to maintaining consistency and minimizing operational risks. Furthermore, robust security management is critical for safeguarding identity and ensuring compliance across cloud operations.

Given the complexities of these tasks, a range of platforms has emerged to assist businesses simplify Azure management by addressing common challenges.

Core components of effective Azure management

Managing Azure environments requires a holistic approach encompassing several key components to ensure smooth and efficient operations. These components form how businesses can scale, optimize and secure their cloud infrastructure.

Resource provisioning and management

Azure management fundamentally revolves around efficient resource provisioning, which includes deploying, configuring and scaling essential cloud components. Organizations can automate and standardize resource management by leveraging Infrastructure as Code (IaC), streamlining deployment processes across multiple regions. This ensures consistent infrastructure setups and reduces the need for manual intervention. Automation helps optimize resource allocation and minimize operational inefficiencies. A well-managed provisioning strategy is vital to avoid over-provisioning, which can incur unnecessary costs, or under-provisioning, which can hinder system performance and reliability. This balance allows enterprises to maintain high availability and cost efficiency while scaling operations.

Tools like Azure Resource Manager (ARM) or Terraform can help organizations achieve this balance seamlessly.

Cost management and optimization

In 2023, 80% of companies reported that cloud cost management is their top concern, surpassing security concerns.

As Azure environments grow, managing and optimizing costs becomes paramount. Azure Cost Management tools provide detailed insights into resource usage, allowing businesses to identify inefficiencies and rightsize their resources to align with actual demand. Budgeting tools enable setting cost limits with alerts triggered when spending exceeds thresholds. Automated shutdown of idle resources, proper instance sizing, and leveraging Reserved Instances for long-term workloads are all essential practices for controlling cloud costs.

Azure offers native tools such as Azure Cost Management to monitor resource consumption, predict future spending and optimize overall cost. Resource right-sizing is a significant part of cost optimization without affecting the system’s efficiency or performance. This involves monitoring the historical performance of the application and database to ensure that resources are not over-provisioned, which can lead to overhead costs.

Additionally, organizations can leverage reserved instances to commit to long-term workloads at reduced cost compared to pay-as-you-go pricing. Cost optimization also benefits from identifying idle or unused resources. Features such as Auto Shutdown for non-production environments and detection of unused resources help avoid billing for unnecessary components. Combining cost visibility tools with automation can help organizations maintain financial efficiency without affecting the performance or scalability of Azure environments.

Monitoring and performance optimization

It is reported that 29% of organizations find cost optimization the most challenging aspect of managing Azure, highlighting the importance of automation tools.

Continuous monitoring of Azure resources is essential to ensure optimal performance and availability. Monitoring resources with analytics helps obtain real-time insights into the health of the applications. It captures metrics, logs, and traces to help identify performance bottlenecks, detect failures, and forecast resource needs. Additionally, setting up automated alerts allows administrators to respond proactively to potential issues before they impact business operations.

Automation for efficiency

Automation is a core element in managing Azure environments efficiently. Azure services like Azure Automation and Azure DevOps Pipeline help with automation that can carry out repetitive tasks such as resource provisioning, scaling and patching. Automation reduces the need for manual intervention, decreasing the likelihood of human errors and minimizing downtime. On top of the advantages mentioned above, automating also enables continuous integration and continuous deployment (CI/CD), allowing teams to push updates or new features while maintaining consistency across environments and reducing time-to-market (TTM).

Automation is also crucial for cost optimization. Automating the start and stop of non-production virtual machines during off-hours can significantly reduce cloud expenditure, as VMs are billed by the hour. Further, implementing automation for right-sizing underutilized resources ensures workloads run on appropriate infrastructure without over-allocating resources, which can save budget. For example, setting policies to right-size virtual machines (VMs) and databases based on historical performance data ensures that resources are scaled to match actual workload demands. Incorporating automation into cloud operations enhances resource management, security, and governance. Automated enforcement of compliance policies through tools like Azure Policy ensures that the entire Azure environment adheres to industry regulations and internal governance standards.

Comparative analysis of Azure management platforms

Azure is one of the most widely adopted cloud platforms. Several organizations have developed solutions to manage the environments effectively in terms of cost optimization, automation, and monitoring, each serving distinct needs for cloud management. Below is the list of top Azure management solution providers who excel at managing and optimizing an environment.

1. Turbo360

Turbo360 is a comprehensive cloud management solution built to enhance Azure operations by offering deep insights into resource usage and providing automation and cost control tools. It allows businesses to monitor, manage, and optimize their cloud environments in real time, focusing on improving operational efficiency. With minimal manual intervention, Turbo360 helps automate key tasks such as scaling, deployment, and compliance checks. This solution can also seamlessly integrate with Azure’s native services.

The platform offers a centralized dashboard with visibility into multiple cloud environments, enabling IT teams to track performance, address issues proactively, and ensure resources are used efficiently. Turbo360 aims to make cloud management scalable, secure, and cost-effective for organizations of any size and stage of their cloud adoption journey.

2. CloudHealth by VMware

VMware’s CloudHealth platform excels in multi-cloud cost management and governance, giving businesses real-time insights into their Azure spending. By centralizing cost visibility across environments, organizations can optimize their cloud infrastructure, manage resource allocation and ensure compliance. This solution is beneficial for organizations operating complex, hybrid cloud systems that need continuous cost control and efficiency.

3. HashiCorp Terraform

HashiCorp is a leading industry in providing Infrastructure as Code (IaC). Terraform allows organizations to automate Azure resource provisioning using a declarative configuration language. This automation eliminates manual processes and ensures consistency in infrastructure deployment across multiple environments.

Terraform’s robust integration with Azure simplifies the management of complex infrastructures by supporting hybrid and multi-cloud architectures. It is an ideal choice for enterprises looking to streamline their infrastructure management while maintaining control over their cloud resources.

4. Datadog

Datadog is known for its powerful monitoring and observability capabilities. Datadog provides real-time performance metrics, logs, and security insights across Azure environments. Its integration with Azure enables organizations to monitor their cloud applications, services, and infrastructure, helping them proactively detect performance issues, reduce downtime, and enhance operational efficiency. Datadog is especially suited for companies that need detailed, continuous monitoring to optimize performance and troubleshoot issues before they escalate.

Each platform enhances Azure management, enabling businesses to scale operations, reduce cost, and maintain security across their cloud environment. Choosing the best Azure management platform depends on your organization’s specific needs and objectives. The optimal choice will also depend on your business’s focus: cost control, automation, or performance monitoring.

I reverse engineered how to write Terraform providers in ANY language (not just Go) and I want to teach you. Every day of the advent, you can open a new box and improve your own provider until you have a working one by Christmas

Mon, 25 Nov 2024 17:06:39 +0100

submitted by /u/caske33
[link] [comments]

Cybersecurity Blind Spots in IaC and PaC Tools Expose Cloud Platforms to New Attacks

Mon, 25 Nov 2024 13:32:52 +0100

Cybersecurity researchers have disclosed two new attack techniques against infrastructure-as-code (IaC) and policy-as-code (PaC) tools like HashiCorp's Terraform and Open Policy Agent (OPA) that leverage dedicated, domain-specific languages (DSLs) to breach cloud platforms and exfiltrate data. "Since these are hardened languages with limited capabilities, they're supposed to be more secure than

Anzeige: Infrastrukturautomatisierung mit Terraform und Openstack

Tue, 05 Nov 2024 07:15:42 +0100

Mit Terraform lassen sich Cloudinfrastrukturen effizient verwalten und automatisieren. Ein zweitägiger Workshop vermittelt praxisnah die Konfiguration von Openstack-Umgebungen. (Golem Karrierewelt, Cloud Computing)

Classify Jira Tickets with GenAI On Amazon Bedrock

Mon, 04 Nov 2024 20:50:04 +0100

Replace traditional NLP approaches with prompt engineering and Large Language Models (LLMS) for Jira ticket text classification. A code sample walkthrough

Photo by Annie Spratt on Unsplash

Remember the days when classifying text meant embarking on a machine learning journey? If you’ve been in the ML space long enough, you’ve probably witnessed at least one team disappear down the rabbit hole of building the “perfect” text classification system. The story usually goes something like this:

Month 1: “We’ll just quickly train a NLP model!”
Month 2: “We need more training data…”
Month 3: “This is good enough”

For years, text classification has fallen into the realm of classic ML. Early in my career, I remember training a support vector machine (SVM) for email classification. Lots of preprocessing, iteration, data collection, and labeling.

But here’s the twist: it’s 2024, and generative AI models can “generally” classify text out of the box! You can build a robust ticket classification system without, collecting thousands of labeled training examples, managing ML training pipelines, or maintaining custom models.

In this post, we’ll go over how to setup a Jira ticket classification system using large language models on Amazon Bedrock and other AWS services.

DISCLAIMER: I am a GenAI Architect at AWS and my opinions are my own.

Why Classify Jira Tickets?

A common ask from companies is to understand how teams spend their time. Jira has tagging features, but it can sometimes fall short through human error or lack of granularity. By doing this exercise, organizations can get better insights into their team activities, enabling data-driven decisions about resource allocation, project investment, and deprecation.

Why Not Use Other NLP Approaches?

Traditional ML models and smaller transformers like BERT need hundreds (or thousands) of labeled examples, while LLMs can classify text out of the box. In our Jira ticket classification tests, a prompt-engineering approach matched or beat traditional ML models, processing 10k+ annual tickets for ~$10/year using Claude Haiku (excluding other AWS Service costs). Also, prompts are easier to update than retraining models.

Code Sample

This github repo contains a sample application that connects to Jira Cloud, classifies tickets, and outputs them in a format that can be consumed by your favorite dashboarding tool (Tableu, Quicksight, or any other tool that supports CSVs).

Important Notice: This project deploys resources in your AWS environment using Terraform. You will incur costs for the AWS resources used. Please be aware of the pricing for services like Lambda, Bedrock, Glue, and S3 in your AWS region.

Pre Requisites

You’ll need to have terraform installed and the AWS CLI installed in the environment you want to deploy this code from

Architecture

The architecture is pretty straight forward. You can find details below.

Image by the author

Step 1: An AWS Lambda function is triggered on a cron job to fetch jira tickets based on a time window. Those tickets are then formatted and pushed to an S3 bucket under the /unprocessed prefix.

Step 2: A Glue job is triggered off /unprocessed object puts. This runs a PySpark deduplication task to ensure no duplicate tickets make their way to the dashboard. The deduplicated tickets are then put to the /staged prefix. This is useful for cases where you manually upload tickets as well as rely on the automatic fetch. If you can ensure no duplicates, you can remove this step.

Step 3: A classification task is kicked off on the new tickets by calling Amazon Bedrock to classify the tickets based on a prompt to a large language model (LLM). After classification, the finished results are pushed to the /processed prefix. From here, you can pick up the processed CSV using any dashboarding tool you’d like that can consume a CSV.

Getting Started

To get started, clone the github repo above and move to the /terraform directory

$ git clone https://github.com/aws-samples/jira-ticket-classification.git

$ cd jira-ticket-classification/terraform

Run terraform init, plan, & apply. Make sure you have terraform installed on your computer and the AWS CLI configured.

$ terraform init

$ terraform plan

$ terraform apply

Once the infrastructure is deployed into your account, you can navigate to AWS Secrets Manager and update the secret with your Jira Cloud credentials. You’ll need an API key, base url, and email to enable the automatic pull

Image by the author

And that’s it!

You can (1) wait for the Cron to kick off an automatic fetch, (2) export the tickets to CSV and upload them to the /unprocessed S3 bucket prefix, or (3) manually trigger the Lambda function using a test.

How Does It Work?

Jira Fetch:

Jira fetch uses a Lambda function with a Cloudwatch cron event to trigger it. The Lambda pulls in the AWS Secret and uses a get request in a while loop to retrieve paginated results until the JQL query completes:

def fetch_jira_issues(base_url, project_id, email, api_key):
    url = f"{base_url}/rest/api/3/search"

    # Calculate the date 8 days ago
    eight_days_ago = (datetime.now() - timedelta(days=8)).strftime("%Y-%m-%d")
    
    # Create JQL
    jql = f"project = {project_id} AND created >= '{eight_days_ago}' ORDER BY created DESC"

    # Pass into params of request.
    params = {
        "jql": jql,
        "startAt": 0
    }
    all_issues = []

    auth = HTTPBasicAuth(email, api_key)
    headers = {"Accept": "application/json"}

    while True:
        response = requests.get(url, headers=headers, params=params, auth=auth)
        if response.status_code != 200:
            raise Exception(f"Failed to fetch issues for project {project_id}: {response.text}")
        
        data = json.loads(response.text)
        issues = data['issues']
        all_issues.extend(issues)
        
        if len(all_issues) >= data['total']:
            break
        
        params['startAt'] = len(all_issues)

    return all_issues

It then creates a string representation of a CSV and uploads it into S3:

def upload_to_s3(csv_string, bucket, key):
    try:
        s3_client.put_object(
            Bucket=bucket,
            Key=key,
            Body=csv_string,
            ContentType='text/csv'
        )
    except Exception as e:
        raise Exception(f"Failed to upload CSV to S3: {str(e)}")

Glue Job

An S3 event on the /unprocessed prefix kicks off a second lambda that starts an AWS Glue job. This is useful when there’s multiple entry points that Jira tickets can enter the system through. For example, if you want to do a backfill.

import boto3 

# Initialize Boto3 Glue client
glue_client = boto3.client('glue')

def handler(event, context):
    # Print event for debugging
    print(f"Received event: {json.dumps(event)}")

    # Get bucket name and object key (file name) from the S3 event
    try:
        s3_event = event['Records'][0]['s3']
        s3_bucket = s3_event['bucket']['name']
        s3_key = s3_event['object']['key']
    except KeyError as e:
        print(f"Error parsing S3 event: {str(e)}")
        raise

    response = glue_client.start_job_run(
        JobName=glue_job_name,
        Arguments={
            '--S3_BUCKET': s3_bucket,
            '--NEW_CSV_FILE': s3_key
        }
    )

The Glue job itself is written in PySpark and can be found in the code repo here. The important take away is that it does a leftanti join using the issue Ids on the items in the new CSV against all the Ids in the /staged CSVs.

The results are then pushed to the /staged prefix.

Classify Jira Tickets:

This is where it it gets interesting. As it turns out, using prompt engineering can perform on par, if not better, than a text classification model using a couple techniques.

You can define the classifications and their descriptions in a prompt,
Ask the model to think step-by-step (Chain of Thought).
And then output the classification without having to train a single model. See the prompt below:

Note: It’s important to validate your prompt using a human curated subset of classified / labelled tickets. You should run this prompt through the validation dataset to make sure it aligns with how you expect the tickets to be classified

SYSTEM_PROMPT = '''
You are a support ticket assistant. You are given fields of a Jira ticket and your task is to classify the ticket based on those fields

Below is the list of potential classifications along with descriptions of those classifications.

ACCESS_PERMISSIONS_REQUEST: Used when someone doesn't have the write permissions or can't log in to something or they can't get the correct IAM credentials to make a service work.
BUG_FIXING: Used when something is failing or a bug is found. Often times the descriptions include logs or technical information.
CREATING_UPDATING_OR_DEPRECATING_DOCUMENTATION: Used when documentation is out of date. Usually references documentation in the text.
MINOR_REQUEST: This is rarely used. Usually a bug fix but it's very minor. If it seems even remotely complicated use BUG_FIXING.
SUPPORT_TROUBLESHOOTING: Used when asking for support for some engineering event. Can also look like an automated ticket.
NEW_FEATURE_WORK: Usually describes a new feature ask or something that isn't operational.

The fields available and their descriptions are below.

Summmary: This is a summary or title of the ticket
Description: The description of the issue in natural language. The majority of context needed to classify the text will come from this field

* It is possible that some fields may be empty in which case ignore them when classifying the ticket
* Think through your reasoning before making the classification and place your thought process in tags. This is your space to think and reason about the ticket classificaiton.
* Once you have finished thinking, classify the ticket using ONLY the classifications listed above and place it in tags.
'''

USER_PROMPT = '''
Using only the ticket fields below:

{summary}

{description}

Classify the ticket using ONLY 1 of the classifications listed in the system prompt. Remember to think step-by-step before classifying the ticket and place your thoughts in tags.
When you are finished thinking, classify the ticket and place your answer in tags. ONLY place the classifaction in the answer tags. Nothing else.
'''

We’ve added a helper class that threads the calls to Bedrock to speed things up:

import boto3
from concurrent.futures import ThreadPoolExecutor, as_completed
import re
from typing import List, Dict
from prompts import USER_PROMPT, SYSTEM_PROMPT

class TicketClassifier:
    SONNET_ID = "anthropic.claude-3-sonnet-20240229-v1:0"
    HAIKU_ID = "anthropic.claude-3-haiku-20240307-v1:0"
    HYPER_PARAMS = {"temperature": 0.35, "topP": .3}
    REASONING_PATTERN = r'(.*?)'
    CORRECTNESS_PATTERN = r'(.*?)'

    def __init__(self):
        self.bedrock = boto3.client('bedrock-runtime')

    def classify_tickets(self, tickets: List[Dict[str, str]]) -> List[Dict[str, str]]:
        prompts = [self._create_chat_payload(t) for t in tickets]
        responses = self._call_threaded(prompts, self._call_bedrock)
        formatted_responses = [self._format_results(r) for r in responses]
        return [{**d1, **d2} for d1, d2 in zip(tickets, formatted_responses)]

    def _call_bedrock(self, message_list: list[dict]) -> str:
        response = self.bedrock.converse(
            modelId=self.HAIKU_ID,
            messages=message_list,
            inferenceConfig=self.HYPER_PARAMS,
            system=[{"text": SYSTEM_PROMPT}]
        )
        return response['output']['message']['content'][0]['text']

    def _call_threaded(self, requests, function):
        future_to_position = {}
        with ThreadPoolExecutor(max_workers=5) as executor:
            for i, request in enumerate(requests):
                future = executor.submit(function, request)
                future_to_position[future] = i
            responses = [None] * len(requests)
            for future in as_completed(future_to_position):
                position = future_to_position[future]
                try:
                    response = future.result()
                    responses[position] = response
                except Exception as exc:
                    print(f"Request at position {position} generated an exception: {exc}")
                    responses[position] = None
        return responses

    def _create_chat_payload(self, ticket: dict) -> dict:
        user_prompt = USER_PROMPT.format(summary=ticket['Summary'], description=ticket['Description'])
        user_msg = {"role": "user", "content": [{"text": user_prompt}]}
        return [user_msg]

    def _format_results(self, model_response: str) -> dict:
        reasoning = self._extract_with_regex(model_response, self.REASONING_PATTERN)
        correctness = self._extract_with_regex(model_response, self.CORRECTNESS_PATTERN)
        return {'Model Answer': correctness, 'Reasoning': reasoning}

    @staticmethod
    def _extract_with_regex(response, regex):
        matches = re.search(regex, response, re.DOTALL)
        return matches.group(1).strip() if matches else None

Lastly, the classified tickets are converted to a CSV and uploaded to S3

import boto3
import io
import csv

s3 = boto3.client('s3')

def upload_csv(data: List[Dict[str, str]]) -> None:
      csv_buffer = io.StringIO()
      writer = csv.DictWriter(csv_buffer, fieldnames=data[0].keys())
      writer.writeheader()
      writer.writerows(data)

      current_time = datetime.now().strftime("%Y%m%d_%H%M%S")
      filename = f"processed/processed_{current_time}.csv"

      s3.put_object(
          Bucket=self.bucket_name,
          Key=filename,
          Body=csv_buffer.getvalue()
      )

Dashboarding

The project is dashboard agnostic. Any popular tool/service will work as long as it can consume a CSV. Amazon Quicksight, Tableu or anything in between will do.

Conclusion

In this blog we discussed using Bedrock to automatically classify Jira tickets. These enriched tickets can then be used to create dashboards using various AWS Services or 3P tools. The takeaway, is that classifying text has become much simpler since the adoption of LLMs and what would have taken weeks can now be done in days.

If you enjoyed this article feel free to connect with me on LinkedIn

Classify Jira Tickets with GenAI On Amazon Bedrock was originally published in Towards Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.

LHB Linux Digest #24.19: Firewalld, Terraform Merge List, Pygtail Log Viewer and More

Wed, 30 Oct 2024 15:50:02 +0100

Get your firewall up.

Product-Oriented ML: A Guide for Data Scientists

Wed, 23 Oct 2024 00:18:55 +0200

How to build ML products users love.

Photo by Pavel Danilyuk: https://www.pexels.com/photo/a-robot-holding-a-flower-8438979/

Data science offers rich opportunities to explore new concepts and demonstrate their viability, all towards building the ‘intelligence’ behind features and products. However, most machine learning (ML) projects fail! And this isn’t just because of the inherently experimental nature of the work. Projects may lack purpose or grounding in real-world problems, while integration of ML into products requires a commitment to long-term problem-solving, investment in data infrastructure, and the involvement of multiple technical experts. This post is about mitigating these risks at the planning stage, fail here, fast, while developing into a product-oriented data scientist.

This article provides a structured approach to planning ML products, by walking through the key areas of a product design document. We’ll cover clarifying requirements, understanding data constraints and defining what success looks like, all of which dictates your approach to building successful ML products. These documents should be flexible, use them to figure out what works for your team.

I’ve been fortunate to work in startups, part of small scrappy teams where roles and ownership become blended. I mention this because the topics covered below crossover traditional boundaries, into project management, product, UI/UX, marketing and more. I’ve found that people who can cross these boundaries and approach collaboration with empathy make great products and better colleagues.

To illustrate the process, we will work through a feature request, set out by a hypothetical courier company:

“As a courier company, we’d like to improve our ability to provide users with advanced warning if their package delivery is expected to be delayed.”

Problem Definition

This section is about writing a concise description of the problem and the project’s motivation. As development spans months or years, not only does this start everyone on the same page, but unique to ML, it serves to anchor you as challenges arise and experiments fail. Start with a project kickoff. Encourage open collaboration and aim to surface the assumptions present in all cross-functional teams, ensuring alignment on product strategy and vision from day one.

Actually writing the statement starts with reiterating the problem in your own words. For me, making this long form and then whittling it down makes it easier to narrow down on the specifics. In our example, we are starting with a feature request. It provides some direction but leaves room for ambiguity around specific requirements. For instance, “improve our ability” suggests an existing system — do we have access to an existing dataset? “Advanced warning” is vague on information but tells us customers will be actively prompted in the event of a delayed delivery. These all have implications for how we build the system, and provides an opportunity to assess the feasibility of the project.

We also need to understand the motivation behind the project. While we can assume the new feature will provide a better user experience, what’s the business opportunity? When defining the problem, always tie it back to the larger business strategy. For example, improving delivery delay notifications isn’t just about building a better product — it’s about reducing customer churn and increasing satisfaction, which can boost brand loyalty and lower support costs. This is your real measure of success for the project.

Working within a team to unpack a problem is a skill all engineers should develop — not only is it commonly tested as part of an interview processes, but, as discussed, it sets expectations for a project and strategy that everyone, top-down can buy into. A lack of alignment from the start can be disastrous for a project, even years later. Unfortunately, this was the fate of a health chatbot developed by Babylon. Babylon set out with the ambitious goal of revolutionising healthcare by using AI to deliver accurate diagnostics. To its detriment, the company oversimplified the complexity of healthcare, especially across different regions and patient populations. For example, symptoms like fever might indicate a minor cold in the UK, but could signal something far more serious in Southeast Asia. This lack of clarity and overpromising on AI capabilities led to a major mismatch between what the system could actually do and what was needed in real-world healthcare environments (https://sifted.eu/articles/the-rise-and-fall-of-babylon).

Requirements and Constraints

With your problem defined and why it matters, we can now document the requirements for delivering the project and set the scope. These typically fall into two categories:

Functional requirements, which define what the system should do from the user’s perspective. These are directly tied to the features and interactions the user expects.
Non-functional requirements, which address how the system operates — performance, security, scalability, and usability.

If you’ve worked with agile frameworks, you’ll be familiar with user stories — short, simple descriptions of a feature told from the user’s perspective. I’ve found defining these as a team is a great way to align, this starts with documenting functional requirements from a user perspective. Then, map them across the user journey, and identify key moments your ML model will add value. This approach helps establish clear boundaries early on, reducing the likelihood of “scope creep”. If your project doesn’t have traditional end-users, perhaps you’re replacing an existing process? Talk to people with boots on the ground — be that operational staff or process engineers, they are your domain experts.

From a simple set of stories we can build actionable model requirements:

What information is being sent to users?

As a customer awaiting delivery, I want to receive clear and timely notifications about whether my package is delayed or on time, so that I can plan my day accordingly.

How will users be sent the warnings?

As a customer awaiting delivery, I want to receive notifications via my preferred communication channel (SMS or native app) about the delay of my package, so that I can take action without constantly checking the app.

What user-specific data can the system use?

As a customer concerned about privacy, I only want essential information like my address to be used to predict whether my package is delayed.

Done right, these requirements should constrain your decisions regarding data, models and training evaluation. If you find conflicts, balance them based on user impact and feasibility. Let’s unpack the user stories above to find how our ML strategy will be constrained:

What information is being sent to users?

The model can remain simple (binary classification) if only a delay notification is needed; more detailed outputs require more complex model and additional data.

How will users be sent the warnings?

Real-time warnings necessitate low-latency systems, this creates constraints around model and preprocessing complexity.

What user-specific data can the system use?

If we can only use limited user-specific information, our model accuracy might suffer. Alternatively, using more detailed user-specific data requires consent from users and increased complexity around how data is stored in order to adhere to data privacy best practices and regulations.

Thinking about users prompts us to embed ethics and privacy into our design while building products people trust. Does our training data result in outputs that contain bias, discriminating against certain user groups? For instance, low-income areas may have worse infrastructure affecting delivery times — is this represented fairly in the data? We need to ensure the model does not perpetuate or amplify existing biases. Unfortunately, there are a litany of such cases, take the ML based recidivism tool COMPAS, used across the US that was shown to overestimated the recidivism risk for Black defendants while underestimating it for white defendants (https://www.propublica.org/article/how-we-analyzed-the-compas-recidivism-algorithm).

In addition to ethics, we also need to consider other non-functional requirements such as performance and explainability:

Transparency and Explainability: How much of a “black-box” do we present the model as? What are the implications of a wrong prediction or bug? These aren’t easy questions to answer. Showing more information about how a model arrives at its decisions requires robust models and the use of explainable models like decision trees. Techniques like SHAP (SHapley Additive exPlanations) and LIME (Local Interpretable Model-agnostic Explanations) can help explain how different features contribute to a prediction, at the risk of overwhelming users. For our example would telling users why a package is delayed build trust? Generally model explainability increases buy in from internal stakeholders.
Real-time or Batch Processing: Real-time predictions require low-latency infrastructure and streaming data pipelines. Batch predictions can be processed at regular intervals, which might be sufficient for less time-sensitive needs. Choosing between real-time or batch predictions affects the complexity of the solution and influences which models are feasible to deploy. For instance, simpler models or optimisation techniques reduce latency. More on this later.

A tip borrowed from marketing is the creation of user personas. This typically builds on market research collected through formal interviews and surveys to understand the needs, behaviours, and motivations of users. It’s then segmented based on common characteristics like demographics, goals and challenges. From this we can develop detailed profiles for each segment, giving them names and backstories. Durning planning, personas helps us empathise with how model predictions will be received and the actions they elicit in various contexts.

Take Sarah, a “Busy Parent” persona. She prioritises speed and simplicity. Hence, she values timely, concise notifications about package delays. This means our model should focus on quick, binary predictions (delayed or on-time) rather than detailed outputs. Finally, since Sarah prefers real-time notifications via her mobile, the model needs to integrate seamlessly with low-latency systems to deliver instant updates.

By documenting functional and non-functional requirements, we define “What” we are building to meet the needs of users combine with “Why” this aligns with business objectives.

Modelling Approach

It’s now time to think about “How” we meet our requirements. This starts with framing the problem in ML terms by documenting the type of inputs (features), outputs (predictions) and a strategy for learning the relationship between them. At least something to get us started, we know it’s going to be experimental.

For our example, the input features could include traffic data, weather reports or package details while a binary prediction is required: “delayed” or “on-time”. It’s clear that our problem requires a binary classification model. For us this was simple, but for other product contexts a range of approaches exist:

Supervised Learning Models: Requires a labeled dataset to train.

Classification Models: Binary classification is simple to implement and interpret for stakeholders, making it ideal for a MVP. This comes at the cost of more nuanced insights provided by multi-class classification, like a reason for delay in our case. However, this often requires more data, meaning higher costs and development time.
Regression Models: If the target is a continuous value, like the exact time a package will be delayed (e.g., “Your package will be delayed by 20 minutes”), a regression model would be the appropriate choice. These outputs are also subject to more uncertainty.

Unsupervised Learning Models: Works with unlabelled data.

Clustering Models: In the context of delivery delays, clustering could be used during the exploratory phase to group deliveries based on similar characteristics, such as region or recurring traffic issues. Discovering patterns can inform product improvements or guide user segmentation for personalising features/notifications.
Dimensionality Reduction: For noisy datasets with a large feature space dimensional reduction techniques like Principal Component Analysis (PCA) or autoencoders can be used to reduce computational costs and overfitting by allowing for smaller models at the cost of some loss in feature context.

Generative Models: Generates new data by training on either labelled and unlabelled data.

Generative Adversarial Networks (GANs): For us, GANs could be used sparingly to simulate rare but impactful delivery delay scenarios, such as extreme weather conditions or unforeseen traffic events, if a tolerance to edge cases is required. However, these are notoriously difficult to train with high computational costs and car must be taken that generated data is realistic. This isn’t typically appropriate for early-stage products.
Variational Autoencoders (VAEs): VAEs have a similar use case to GANs, with the added benefit of more control over the range of outputs generated.
Large Language Models (LLMs): If we wanted to incorporate text-based data like customer feedback or driver notes into our predictions, LLMs could help generate summaries or insights. But, real-time processing is a challenge with heavy computational loads.

Reinforcement Learning Models: These models learn by interacting with an environment, receiving feedback through rewards or penalties. For a delivery company, reinforcement learning could be used to optimise the system based on the real outcome of the delivery. Again, this isn’t really appropriate for an MVP.

It’s normal for the initial framing of a problem to evolve as we gain insights from data exploration and early model training. Therefore, start with a simple, interpretable model, to test feasibility. Then, incrementally increase complexity by adding more features, tuning hyperparameters, and then explore more complex models like ensemble methods or deep learning architectures. This keeps costs and development time low while making for a quick go to market.

ML differs significantly from traditional software development when it comes to estimating development time, with a large chunk of the work being made up of experiments. Where the outcome is always unknown, and so is the number required. This means any estimate you provide should have a large contingency baked in, or the expectation that it’s subject to change. If the product feature isn’t critical we can afford to give tighter time estimates by starting with simple models while planning for incremental improvements later.

The time taken to develop your model is a significant cost to any project. In my experience, getting results from even a simple model fast, will be massively beneficial downstream, allowing you to handover to frontend developers and ops teams. To help, I have a few tips. First, fail fast and prioritise experiments by least effort, and maximum likelihood of success. Then adjust your plan on the go based on what you learn. Although obvious, people do struggle to embrace failure. So, be supportive of your team, it’s part of the process. My second tip is, do your research! Find examples of similar problems and how they were solved, or not. Despite the recent boom in popularity of ML, the field has been around for a long time, and 9 times out of 10 someone has solved a problem at least marginally related to yours. Keep up with the literature, use sites like Papers with Code, daily papers from Hugging Face or AlphaSignal, which provides a nice email newsletter. For databases try, Google Scholar, Web of Science or ResearchGate. Frustratingly, the cost of accessing major journals is a significant barrier to a comprehensive literature review. Sci-Hub…

Data Requirements

Now that we know what our “black box” will do, what shall we put in it? It’s time for data, and from my experience this is the most critical part of the design with respect to mitigating risk. The goal is to create an early roadmap for sourcing sufficient, relevant, high-quality data. This covers training data, potential internal or external sources, and evaluating data relevance, quality, completeness, and coverage. Address privacy concerns and plan for data collection, storage, and preprocessing, while considering strategies for limitations like class imbalances.

Without proper accounting for the data requirements of a project, you risk exploding budgets and never fully delivering, take Tesla AutoPilot as one such example. Their challenge with data collection highlights the risks of underestimating real-world data needs. From the start, the system was limited by the data captured from early adopters vehicles, which to date, has lacked the sensor depth required for true autonomy (https://spectrum.ieee.org/tesla-autopilot-data-deluge).

Data sourcing is made significantly easier if the feature you’re developing is already part of a manual process. If so, you’ll likely have existing datasets and a performance benchmark. If not, look internally. Most organisations capture vast amounts of data, this could be system logs, CRM data or user analytics. Remember though, garbage in, garbage out! Datasets not built for ML from the beginning often lack the quality required for training. They might not be rich enough, or fully representative of the task at hand.

If unsuccessful, you’ll have to look externally. Start with high-quality public repositories specifically designed for ML, such as Kaggle, UCI ML Repository and Google Dataset Search.

If problem-specific data isn’t available, try more general publicly available datasets. Look through data leaks like the Enron email dataset (for text analysis and natural language processing), government census data (for population-based studies), or commercially released datasets like the IMDb movie review dataset (for sentiment analysis). If that fails, you can start to aggregate from multiple sources to create an enriched dataset. This might involve pulling data from spreadsheets, APIs, or even scraping the web. The challenge for both cases is to ensure your data is clean, consistent, and appropriately formatted for ML purposes.

Worst case, you’re starting from scratch and need to collect your own raw data. This will be expensive and time-consuming, especially when dealing with unstructured data like video, images, or text. For some cases data collection can automated by conducting surveys, setting up sensors or IoT devices or even launching crowd sourced labelling challenges.

Regardless, manual labelling is almost always necessary. There are many highly recommended, off the shelf solutions here, including LabelBox, Amazon SageMaker Ground Truth and Label Studio. Each of these can speed up labelling and help maintain quality, even across large datasets with random sampling.

If it’s not clear already, as you move from internal sources to manual collection; the cost and complexity of building a dataset appropriate for ML grows significantly, and so does the risk for your project. While this isn’t a project-killer, it’s important to take into account what your timelines and budgets allow. If you can only collect a small dataset you’ll likely be restricted to smaller model solutions, or the fine tuning of foundation models from platforms like Hugging Face and Ollama. In addition, ensure you have a costed contingency for obtaining more data later in the project. This is important because understanding how much data is required for your project can only be answered by solving the ML problem. Therefore, mitigate the risk upfront by ensuring you have a route to gathering more. It’s common to see back-of-the-napkin calculations quoted as a reasonable estimate for how much data is required. But, this really only applies to very well understood problems like image classification and classical ML problems.

If it becomes clear you won’t be able to gather enough data, there has been some limited success with generative models for producing synthetic training data. Fraud detection systems developed by American Express have used this technique to simulate card numbers and transactions in order to detect discrepancies or similarities with actual fraud (https://masterofcode.com/blog/generative-ai-for-fraud-detection).

Once a basic dataset has been established you’ll need to understand the quality. I have found manually working the problem to be very effective. Providing insight into useful features and future challenges, while setting realistic expectations for model performance. All while uncovering data quality issues and gaps in coverage early on. Get hands on with the data and build up domain knowledge while taking note of the following:

Data relevance: Ensure the available data reflects your attempts to solve the problem. For our example, traffic reports and delivery distances are useful, but customer purchase history may be irrelevant. Identifying the relevance of data helps reduce noise, while allowing smaller data sets and models to be more effective.
Data quality: Pay attention to any biases, missing data, or anomalies that you find, this will be useful when building data preprocessing pipelines later on.
Data completeness and coverage: Check the data sufficiently covers all relevant scenarios. For our example, data might be required for both city centres and more rural areas, failing to account for this impacts the model’s ability to generalise.
Class imbalance: Understand the distribution of classes or the target variable so that you can collect more data if possible. Hopefully for our case, “delayed” packages will be a rare event. While training we can implement cost-sensitive learning to counter this. Personally, I have always had more success oversampling minority classes with techniques like SMOTE (Synthetic Minority Over-sampling Technique) or Adaptive Synthetic (ADASYN) sampling.
Timeliness of data: Consider how up-to-date the data needs to be for accurate predictions. For instance, it might be that real-time traffic data is required for the most accurate predictions.

When it comes to a more comprehensive look at quality, Exploratory Data Analysis (EDA) is the way to uncover patterns, spot anomalies, and better understand data distributions. I will cover EDA in more detail in a separate post, but visualising data trends, using correlation matrices, and understanding outliers can reveal potential feature importance or challenges.

Finally, think beyond just solving the immediate problem — consider the long-term value of the data. Can it be reused for future projects or scaled for other models? For example, traffic and delivery data could eventually help optimise delivery routes across the whole logistics chain, improving efficiency and cutting costs in the long run.

Success Metrics — Finding Good Enough

When training models, quick performance gains are often followed by a phase of diminishing returns. This can lead to directionless trial-and-error while killing morale. The solution? Define “good enough” training metrics from the start, such that you meet the minimum threshold to deliver the business goals for the project.

Setting acceptable thresholds for these metrics requires a broad understanding of the product and soft skills to communicate the gap between technical and business perspectives. Within agile methodologies, we call these acceptance criteria. Doing so allows us to ship quick to the minimum spec and then iterate.

What are business metrics? Business metrics are the real measure of success for any project. These could be reducing customer support costs or increasing user engagement, and are measured once the product is live, hence referred to as online metrics. For our example, 80% accuracy might be acceptable if it reduces customer service costs by 15%. In practice, you should track a single model with a single business metric, this keeps the project focused and avoids ambiguity about when you have successfully delivered. You’ll also want to establish how you track this metrics, look for internal dashboards and analytics that business teams should have available, if they’re not, maybe it’s not a driver for the business.

Balancing business and technical metrics: Finding a “good enough” performance starts with understanding the distribution of events in the real world, and then relating this to how it impacts users (and hence the business). Take our courier example, we expect delayed packages to be a rare event, and so for our binary classifier there is a class imbalance. This makes accuracy alone inappropriate and we need to factor in how our users respond to predictions:

False positives (predicting a delay when there isn’t one) could generate annoying notifications for customers, but when a package subsequently arrives on time, the inconvenience is minor. Avoiding false positives means prioritising high precision.
False negatives (failing to predict a delay) are likely to cause much higher frustration when customers don’t receive a package without warning, reducing the chance of repeat business and increasing customer support costs. Avoiding false negatives means prioritising high recall.

For our example, it’s likely the business values high recall models. Still, for models less than 100% accurate, a balance between precision and recall is still necessary (we can’t notify every customer their package is delayed). This trade off is best illustrated with an ROC curve. For all classification problems, we measure a balance of precision and recall with the F1 score, and for imbalanced classes we can extend this to a weighted F1 score.

Balancing precision and recall is a fine art, and can lead to unintended consequences for your users. To illustrate this point consider a services like Google calendar that offers both company and personal user accounts. In order to reduce the burden on businesses that frequently receive fake meeting requests, engineers might prioritise high precision spam filtering. This ensures most fake meetings are correctly flagged as spam, at the cost of lower recall, where some legitimate meetings will be mislabeled as spam. However, for personal accounts, receiving fake meeting requests is far less common. Over the lifetime of the account, the risk of a legitimate meeting being flagged becomes significant due to the trade-off of a lower recall model. Here, the negative impact on the user’s perception of the service is significant.

If we consider our courier example as a regression tasks, with the aim of predicting a delay time, metrics like MAE and MSE are the choices, with slightly different implications for your product:

Mean Absolute Error (MAE): This is fairly intuitive measure of how close the average prediction is to the actual value. Therefore a simple indicator for the accuracy of delay estimates sent to users.
Mean Squared Error (MSE): This penalises larger errors more heavily due to the squaring of differences, and therefore important if significant errors in delay predictions are deemed more costly to user satisfaction. However, this does mean the metric is more sensitive to outliers.

As stated above, this is about translating model metrics into terms everyone can understand and communicating trade-offs. This is a collaborative process, as team members closer to the users and product will have a better understanding of the business metrics to drive. Find the single model metric that points the project in the same direction.

One final point, I have seen a tendency for projects involving ML to overpromise on what can be delivered. Generally this comes from the top of an organisation, where hype is generated for a product or amongst investors. This is detrimental to a project and your sanity. Your best chance to counter this is by communicating in your design realistic expectations that match the complexity of the problem. It’s always better to underpromise and overdeliver.

High Level System Design

At this point, we’ve covered data, models, and metrics, and addresses how we will approach our functional requirements. Now, it’s time to focus on non-functional requirements, specifically scalability, performance, security, and deployment strategies. For ML systems, this involves documenting the system architecture with system-context or data-flow diagrams. These diagrams represent key components as blocks, with defined inputs, transformations, and outputs. Illustrating how different parts of the system interact, including data ingestion, processing pipelines, model serving, and user interfaces. This approach ensures a modular system, allowing teams to isolate and address issues without affecting the entire pipeline, as data volume or user demand grows. Therefore, minimising risks related to bottlenecks or escalating costs.

Once our models are trained we need a plan for deploying the model into production, allowing it to be accessible to users or downstream systems. A common method is to expose your model through a REST API that other services or front-end can request. For real-time applications, serverless platforms like AWS Lambda or Google Cloud Functions are ideal for low latency (just manage your cold starts). If high-throughput is a requirement then use batch processing with scalable data pipelines like AWS Batch or Apache Spark. We can breakdown the considerations for ML system design into the following:

Infrastructure and Scalability:

Firstly, we need to make a choice about system infrastructure. Specifically, where will we deploy our system: on-premise, in the cloud, or as a hybrid solution. Cloud platforms, such as AWS or Google Cloud offer automated scaling in response to demand both vertically (bigger machines) and horizontally (adding more machines). Think about how the system would handle 10x or 100x the data volume. Netflix provides excellent insight via there technical blog for how they operate at scale. For instance, they have open sourced there container orchestration platform Titus, which automates deployment of thousands of containers across AWS EC2 instances using Autoscaling groups (https://netflixtechblog.com/auto-scaling-production-services-on-titus-1f3cd49f5cd7). Sometimes on-premises infrastructure is required if you’re handling sensitive data. This provides more control over security while being costly to maintain and scale. Regardless, prepare to version control your infrastructure with infrastructure-as-code tools like Terraform and AWS CloudFormation and automate deployment.

Performance (Throughput and Latency):

For real-time predictions, performance is critical. Two key metrics to consider, throughput measuring how many requests your system can handle per second (i.e., requests per second), and latency, measuring long how long it takes to return a prediction. If you expect to make repeated predictions with the same inputs then consider adding caching for either part or all the pipeline to reduce latency. In general, horizontal scaling is preferred in order to respond to spikes in traffic at peak times, and reducing single point bottlenecks. This highlights how key decisions taken during your system design process will have direct implications on performance. Take Uber, who built their core service around Cassandra database specifically to optimise for low latency real-time data replication, ensuring quick access to relevant data. (https://www.uber.com/en-GB/blog/how-uber-optimized-cassandra-operations-at-scale/).

Security:

For ML systems security applies to API authentication for user requests. This is relatively standard with methods like OAuth2, and protecting endpoints with rate limiting, blocked IP address lists and following OWASP standards. Additionally, ensure that any stored user data is encrypted at rest and flight with strict access control polices for both internal and external users is in place.

Monitoring and Alerts:

It’s also key to consider monitoring for maintaining system health. Track key performance indicators (KPIs) like throughput, latency, and error rates, while alerts are setup to notify engineers if any of these metrics fall below acceptable thresholds. This can be done server-side (e.g., your model endpoint) or client-side (e.g., the users end) to include network latency.

Cost Considerations:

In return for simple infrastructure management the cost of cloud-based systems can quickly spiral. Start by estimating the number of instances required for data processing, model training, and serving, and balance these against project budgets and growing user demands. Most cloud platforms provide cost-management tools to help you keep track of spending and optimise resources.

MLOps:

From the beginning include a plan to efficiently manage model lifecycle. The goal is to accelerate model iteration, automate deployment, and maintain robust monitoring for metrics and data drift. This allows you to start simple and iterate fast! Implement version control with Git for code and DVC (Data Version Control) for tracking data model artefact changes. Tools like MLFlow or Weights & Biases track experiments, while CI/CD pipelines automate testing and deployment. Once deployed, models require real-time monitoring with tools like Promethes and Grafana to detect issues like data drift.

A high-level system design mitigates risks and ensures your team can adapt and evolve as the system grows. This means designing a system that is model agnostic and ready to scale by breaking down the system into modular components for a robust architecture that supports rapid trail and error, scalable deployment, and effective monitoring.

Prototyping By Mocking the ML

We now have an approach for delivering the project requirements, at least from an ML perspective. To round our design off, we can now outline a product prototype, focusing on the user interface and experience (UI/UX). Where possible, this should be interactive, validating whether the feature provides real value to users, ready to iterate on the UX. Since we know ML to be time-consuming and resource-intensive, you can set aside your model design and prototype without a working ML component. Document how you’ll simulate these outputs and test the end-to-end system, detailing the tools and methods used for prototyping in your design document. This is important, as the prototype will likely be your first chance to gather feedback and refine the design, likely evolving into V1.

To mock our ML we replace predictions with a simple placeholder and simulate outputs. This can be as simple as generating random predictions or building a rule-based system. Prototyping the UI/UX involves creating mockups with design tools like Figma, or prototyping APIs with Postman and Swagger.

Once your prototype is ready, put it in the hands of people, no matter how embarrassed you are of it. Larger companies often have resources for this, but smaller teams can create their own user panels. I’ve had great success with local universities — students love to engage with something new, Amazon vouchers also help! Gather feedback, iterate, and start basic A/B testing. As you approach a live product, consider more advanced methods like multi-armed bandit testing.

There is an excellent write up by Apple as an example of mocking ML in this way. During user testing of a conversational digital assistant similar to Siri, they used human operators to impersonate a prototype assistant, varying responses between a conversational style — chatty, non-chatty, or mirror the user’s own style. With this approach they showed users preferred assistants that mirror their own level of chattiness, improving trustworthiness and likability. All without investing in extensive ML development to test UX (https://arxiv.org/abs/1904.01664).

From this we see that mocking the ML component puts the emphasis on outcomes, allowing us to change output formats, test positive and negative flows and find edge cases. We can also gauge the limits of perceived performance and how we manage user frustration, this has implications for the complexity of models we can build and infrastructure costs. All without concern for model accuracy. Finally, sharing prototypes internally helps get buy in from business leaders, nothing sparks support and commitment for a project more than putting it people’s hands.

Gather Feedback and Iterate

As you move into development and deployment, you’ll inevitably find that requirements evolve and your experiments will throw up the unexpected. You’ll need to iterate! Document changes with version control, incorporate feedback loops by revisiting the problem definition, re-evaluating data quality, and re-assessing user needs. This starts with continuous monitoring, as your product matures look for performance degradation by applying statistical tests to detect shifts in prediction distributions (data drift). Implement online learning to counter this or if possible bake into the UI feedback methods from users to help reveal real bias and build trust, so called human-in-the-loop. Actively seek feedback internally first, then from users, through interviews and panels understand how they interact with the product and how this causes new problems. Use A/B testing to compare select versions of your model to understand the impact on user behaviour and the relevant product/business metrics.

ML projects benefit from adopting agile methodologies across the model life cycle, allowing us to manage the uncertainty and change that is inherent in ML, this starts with the planning process. Start small, test quickly, and don’t be afraid to fail fast. Applying this to the planning and discovery phase, will reduce risk, while delivering a product that not only works but resonates with your users.

Product-Oriented ML: A Guide for Data Scientists was originally published in Towards Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using Terraform Merge Lists

Tue, 22 Oct 2024 12:21:29 +0200

Terraform provides a way to manage the structure code with the merge lists. Learn more about it with some practical examples.

CVE-2023-4782 | Hashicorp Terraform up to 1.5.6 path traversal (Nessus ID 209262)

Fri, 18 Oct 2024 16:23:16 +0200

A vulnerability, which was classified as problematic, has been found in Hashicorp Terraform up to 1.5.6. This issue affects some unknown processing. The manipulation leads to path traversal. The identification of this vulnerability is CVE-2023-4782. Local access is required to approach this attack. There is no exploit available. It is recommended to upgrade the affected component.

Juniper extends security platform to streamline threat detection, incident response

Wed, 09 Oct 2024 18:18:47 +0200

Juniper Networks is working to integrate more of its security services under one AI-centric roof. The vendor’s new Secure AI-Native Edge offering and cloud-based Security Assurance service are designed to deliver a cohesive view of network health, performance, and security metrics with a goal of resolving problems quickly and centrally enforcing enterprise security policies.

Secure AI-Native Edge is part of Juniper’s AI-Native Networking Platform, which is aimed at unifying the vendor’s campus, branch and data center networking products under a common AI engine. Secure AI-Native Edge defines the security tools and designs to protect those enterprise environments.

Central to the platform are the firm’s cloud-based, natural language Mist AI and Marvis virtual network assistant (VNA) technology. Juniper’s Mist AI engine analyzes data from networked access points and devices so it can detect anomalies and offer actionable resolutions. Marvis can detect and describe countless network problems, including persistently failing wired or wireless clients, bad cables, access-point coverage holes, problematic WAN links, and insufficient radio-frequency capacity.

Secure AI-Native Edge uses Mist’s AI-based features and now offers the Security Assurance software subscription, which pulls together network information as well as security details from the company’s SRX firewalls.

By creating procedures for threat detection and incident response that integrate both networking and security teams, companies can ensure real-time communication and informed decision making when issues arise—whether network- or security-related, wrote Mike Spanbauer, technology evangelist for Juniper Security, in a blog about the new offering.

“Given the depth and scope of telemetry from network edge to data center, core threats are blocked, anomalies are rapidly assessed and either reported on, or automatic action can be taken by Marvis,” Spanbauer wrote.

Another benefit of Security Assurance is that it gives customers consistency in security policies across network and application layers, Spanbauer wrote.

“Without uniform policies, organizations can find themselves grappling with security gaps that cybercriminals eagerly exploit. Juniper has incorporated a security policy engine that empowers network security across its entire portfolio,” Spanbauer wrote.

“This means that previous configurations and security standards apply across all platforms and in all locations from edge to data center. This engine ensures that policies are applied consistently, from the point of connection through to the application in support of zero trust principles,” Spanbauer wrote.

The overall operational benefits of fostering collaboration between networking and security teams are immense, Spanbauer wrote.

“With a unified approach, not only do organizations enhance their security efficacy, but they also streamline operations. Instead of running duplicate processes or allowing miscommunication to result in network outages or security lapses, the teams can work together efficiently,” Spanbauer wrote.

CVE-2024-47083 | Microsoft Power Platform Terraform Provider up to 2.7.0 client_secret neutralization for logs (GHSA-7w3w-pjm5-m36c)

Fri, 04 Oct 2024 04:36:36 +0200

A vulnerability classified as problematic has been found in Microsoft Power Platform Terraform Provider up to 2.7.0. Affected is an unknown function. The manipulation of the argument client_secret leads to improper output neutralization for logs. This vulnerability is traded as CVE-2024-47083. It is possible to launch the attack on the local host. There is no exploit available. It is recommended to upgrade the affected component.

heise-Angebot: iX-Workshop für Entwickler und Architekten: IT-Management mit Terraform

Fri, 27 Sep 2024 08:30:49 +0200

Erstellen und verwalten Sie IT- und Cloud-Infrastrukturen als Code – Grundlagen, Installation und Nutzung von Terraform.

An Ode to FOSS. It Took Me 7 Years To Craft a Game Using Only FOSS And It Just Reached Almost 600 Players

Thu, 26 Sep 2024 18:20:36 +0200

Hey folks!

I'm Xavier and a solo game dev since 2017. I use Godot, Inkscape, Blender and Krita. I'm used to this subreddit, and I like to read it! I'm more of a lurker usually, but as I'm making games I have to talk about my games, so I post quite often on reddit but here! Because I know you folks, I know you're not looking for some shiny stuff, but for something that respect your privacy, because I'm one of you using Librewolf on Debian for example.

Anyway, my journey started in 2017, and my first game released in 2019, while the second one didn't went well. I'm about to release my third game (april 7th 2025).

I have a spare laptop that runs windows for some testing, and a VM that runs MacOS just in case, but all of my computers run either Debian or Raspbian. I host my code on a raspberry pi using Gitea, and I share most of the code I write on github/gitlab. I also contribute to some tools that I use (godot and terraform for example).

Today is a really big day to me since Steam accepted to put one of my game on their front-page. From a game that had around 5 to 20 players, it went to almost 600! Selling over 5000 copies within 24h. That's crazy and I really want to thank you all for making this happen!

Of course I work my ass off to make it happen, but I don't have enough time to make an OS as solid as Linux. I don't have enough time to make a game engine as great as Godot. I don't have enough time to make a tool as AWESOME as Inkscape (I really love this one). I don't have enough time to make a 3D tool/VCE/... as incredible as Blender! I'm just talking about those tools, but I could have talked about Librewolf, KDEPlasma, Terminator, nano, ssh, git, gitea ... all of those tools/libs are great and I'm glad they exist.

Anyway, I'm sure this post is going to get buried but I really wanted to thank you all for making all of this to happen.

Ask me anything (if you're still here obviously)

submitted by /u/binogure
[link] [comments]

HPE Aruba boosts observability, third-party management capabilities

Tue, 24 Sep 2024 19:19:36 +0200

HPE Aruba is expanding the capabilities of Networking Central, its cloud-based management platform for administering and managing all aspects of an Aruba wired and wireless customer infrastructure. Among the upgrades are an improved network device configuration engine, expanded network observability features, and a broader menu of AI-generated, network trained and tuned optimization models.

To ease the often tedious job of network and device configuration, the device management package in HPE Aruba Networking Central now includes a common configuration model that simplifies Aruba’s wired, wireless, and gateway configuration tasks by letting customers build tools with Python, Ansible, or Terraform, according to Alan Ni, senior director of edge marketing for HPE Aruba. It also includes a menu of more than 90 new APIs customers can organize from a single console, Ni said.

“We support tons of different network components, from switches and routers to IoT devices, and that requires customers to configure each family of devices separately, which means three different APIs to write to and three different pushes to update and provision those device classes across the network,” Ni said. “Now we’ve collapsed that down [so users can update] those devices from a single API. And now, from a single push, we can provision everything, which reduces configuration errors and eases management of different device types across the enterprise.”

In the observability arena, Aruba has expanded Networking Central so that it can see beyond the Aruba-based networking world and gain visibility into third-party network equipment from Cisco, Juniper, Palo Alto and other vendors.

The technology that enables this service came from HPE’s 2023 acquisition of IT operations management vendor OpsRamp, which specializes in monitoring, automating and managing IT infrastructure, cloud resources, workloads and applications for hybrid and multicloud environments.

Within the native Networking Central interface, users can now monitor elements that they couldn’t before, such as third-party switches, access points, firewalls, and routers, Ni said. “Basically, we are removing any blind spots that customers had when it comes to managing and troubleshooting heterogeneous networks,” Ni said.

In addition, Networking Central now includes support for Aruba’s digital experience monitoring (DEM) capabilities, which will allow users to continuously monitor service level agreement (SLA) adherence from a single pane of glass, Ni said.

In addition, Ni said Networking Central’s AI-based support has been enhanced with three times as many trained models as it had six months ago.

“We have seen exponential growth and now have a data lake that features telemetry from more than 4.6 million network-managed devices and more than 1.6 billion unique customer endpoints,” Ni said. “Ultimately, this increased detail can help customers significantly reduce the time and effort to plan, deploy, manage, troubleshoot and optimize networks.”

HPE Aruba customers will have access to the new capabilities through a public preview starting in October.

Building on recent upgrades

HPE Aruba has added a number of AI-based features to its Networking Central platform over the past year.

In May, the vendor announced plans to build new AI-powered security observability and monitoring features into Networking Central to help customers protect both AI-based and traditional resources from IoT security risks.

A month prior, HPE Aruba added genAI-driven search tools to its management platform to help customers access detailed responses to queries about network configurations, documentation, and other IT operational issues.

Startups Are Going 'Fair Source' To Avoid Pitfalls of Open Source Licensing

Tue, 24 Sep 2024 02:33:30 +0200

An anonymous reader quotes a report from TechCrunch: With the perennial tensions between proprietary and open source software (OSS) unlikely to end anytime soon, a $3 billion startup is throwing its weight behind a new licensing paradigm -- one that's designed to bridge the open and proprietary worlds, replete with new definition, terminology, and governance model. Developer software company Sentry recently introduced a new license category dubbed "fair source." Sentry is an initial adopter, as are some half dozen others, including GitButler, a developer tooling company from one of GitHub's founders. The fair source concept is designed to help companies align themselves with the "open" software development sphere, without encroaching into existing licensing landscapes, be that open source, open core, or source-available, and while avoiding any negative associations that exist with "proprietary." However, fair source is also a response to the growing sense that open source isn't working out commercially. "Open source isn't a business model -- open source is a distribution model, it's a software development model, primarily," Chad Whitacre, Sentry's head of open source, told TechCrunch. "And in fact, it places severe limits on what business models are available, because of the licensing terms." Sure, there are hugely successful open source projects, but they are generally components of larger proprietary products. Businesses that have flown the open source flag have mostly retreated to protect their hard work, moving either from fully permissive to a more restrictive "copyleft" license, as the likes of Element did last year and Grafana before it, or ditched open source altogether as HashiCorp did with Terraform. "Most of the world's software is still closed source," Whitacre added. "Kubernetes is open source, but Google Search is closed. React is open source, but Facebook Newsfeed is closed. With fair source, we're carving a space for companies to safely share not just these lower-level infrastructure components, but share access to their core product." Further reading: As Companies Try 'Open Source Rug Pull', Open Source Foundations Considered Helpful

Read more of this story at Slashdot.

Startups Are Going 'Fair Source' To Avoid Pitfalls of Open Source Licensing

Tue, 24 Sep 2024 02:33:28 +0200

Read more of this story at Slashdot.